Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。2019でこのように述べて、旧来のリスクベースのテストをスプリントの一部として取り入れ、その完了状態を定義することによって、自分たちのアジャイル実践に適合させた方法について説明した。Szökőcs氏が最初に示したのは、テスト活動をイテレーションの最終段階から最初に移すために、氏がチームをサポートした方法についてだった。shippable)"の意味も理解していなかった。当時のチームは、年に1回か2回のリリースを実施していたが、"システムテスト"フェーズ(別名"バグ修正")に数か月を要していた。現在はスクラムを使用してバグのないストーリのデリバリにトライしており、新たに形成されたスクラムチームでは、より多くのテストアクティビティを導入している。スプリントの最初に小さな設計を作成して実装し、終了後にそれをテストする、という方法だ。Szökőcs氏の説明によれば、これはスプリント内における小さなウォーターフォールモデルであり、一般的なウォーターフォールと同じ欠点を持っていた。テスト中に大きな問題が発見されると、ほとんどの場合、それを正しく修正するにはすでに遅すぎるため、その結果を受け入れざるを得ませんでした。バグを容認して後日修正する、ストーリの範囲を縮小する、あるいは技術的負債のコストを伴う短期的なソリューションを導入する、といった方法です。いずれも望ましいものではありません。そこでSzökőcs氏は、当時アーキテクチャワークショップで学んだリスクベースのテストが、氏らのスクラムチームに役立つのではないか、と考えたという。それを試みるため、スプリント内でユーザストーリを計画する前に、各ストーリのリスクを収集することにした。これにより、ストーリが実装される前にテストアクティビティについて検討することや、多くの問題を事前に回避することが可能になった。この経験を活かすため、氏らは、極めて早い段階からシステムテスタ担当の同僚を関与させることにした。リスクベースのテストは、スプリント中のストーリの処理方法を劇的に変更し、デリバリするストーリの品質を改善したが、それだけではなく、システムテスタ役の同僚に大きなモチベーションを持たせることも可能にした。これについて氏は、ストーリの最終的な実現方法に影響を与えることができるようになったからだ、と説明している。これらのシステムテスタの多くは、現在ではスクラムチームの一員となっている。"一部のスクラムチームではリスクベースのテストを使用していますが、すべてではありません。それにトライして、すでに長く使用しているチームもありますが、そうでないチームもあるのです"、とSzökőcs氏は述べている。それらのチームは、従来のリスクベースのテストをスクラムプロセスに適応させることで、自分たちのアジャイル実践により適合するものにしている、と氏は言う。Szökőcs氏によると、一般的なリスクベースのテストは、短いテスト期間において最も価値のあるテストを見つけることを目的として、テストチーム内で実施されるものだ。これに対して、氏らのスクラムチームでは、ほぼすべてのユーザーストーリあるいはエピックを対象として、個別に独立したリスクベースのテストを行っている。ストーリのリスクを収集して優先順位を付けることは、その準備完了の定義のひとつである。特定のトピックには数人の専門家(システムテスタ、アーキテクト、製品所有者)が関与して、リファインメントの一部としてリスク収集を行う。システム内にすでに存在するバグを見つけることもあれば、ユーザストーリの変更が必要な場合もある。特別なシナリオで受け入れ基準を拡張したり、極めてトリッキーなシナリオについては分割することもある。リスクの収集後、2人の同僚がリスクに優先順位を付けて、各リスクの確率とダメージを、1から5までの数字で評価する。2つの数値を乗算することで、リスクエクスポージャ(exposure)が明らかになる。Szökőcs氏によると、エクスポージャの高いリスクは、すべて、何らかの方法で処理する必要があるものだ。経験豊富なテスタが各リスクのテスト有効性を推定し、テストでこのリスクを処理するのはどの程度簡単か、という質問に回答する。これも1から5の範囲で評価する。1が"テスト不可"で、5は"自明"だ。この数値にエクスポージャを乗じたものが、テスト優先度番号(1~125の範囲)になる。数値が大きいほど、影響が大きく、テストが容易なリスクであることを示しているため、優先して対処する価値がある。低い数値は、テストが困難で影響の少ないリスクであることを示している。したがって実質的な価値はなく、無視した方がよい、と、Szökőcs氏は主張する。優先順位を付けることによって、ハッピーデイシナリオのみをテストするのではなく、最も影響の大きいリスクを対象とした、価値あるテストによるテスト戦略の策定が可能になる。テストするリスクのレベルを特定するために、優先順位を使用することも可能だ、とSzökőcs氏は述べている。Szökőcs氏に話を聞いた。最初に、優先順位付けは必須ではありません。それを完全に省略すると場合でも、リスク収集には大きな価値があります。一部のチームはこの方法で作業していますが、十分な成果をあげています。第二に、優先順位を深く考え過ぎないことです。最低のリスクを見つけて1を設定し、次に最高のリスクを見つけて、それに5を設定します。他のリスクはすべて、すぐにその間で優先順位を付けることができます。第三に、テストの優先度は、ストーリにおいて最も価値のあるテストを見つける上で本当に役立ちます。それにより、デリバリするユーザストーリの品質が全体的に向上します。私たちは、"このストーリで何が問題になるのか?"という問いに答えることで、ユーザストーリのコンテキストにおいてリスクを収集しています。同時に、新しい機能がすでに動作している状況を想像しながら、さまざまなシナリオについて、それがどのように使用されるか、あるいは誤用されるかを考えます。新機能を他の既存機能とを組み合わせることによって、うまくいかなくなる可能性についても検討します。このストーリによって問題が発生しないか。システムの負荷が高い場合、問題になる可能性があるのは何か。システムに何らかの矛盾が生じた場合はどうなるのか。(可能性のあるシナリオというだけではなく)価値のあるリスクを見つけるために、私たちはいつも、そのドメインの専門家(他チームのシステムテスタやアーキテクトやプロダクトオーナ)の支援を求めています。チームが何かを実装する前にストーリに影響を与えることができるという面で、これは、彼らにとってもやりがいのある仕事です。チームの誰かが病気になった時や予算を使い果たした時に何が起こるか、といったような、プロジェクトのリスクを対象にしていない点も重要です。テストケースも収集していません。ひとつのテストケースだけで複数のリスクをカバーできる場合もあれば、ひとつのリスクのために複数のテストが必要な場合もあります。テストケースはもっと後で、最も重要なリスクから割り出します。シンプルに始めて、段階的に改善してください。最初は、洗練プロセスの一部として各ユーザストーリのリスクをいくつか収集し、それらを単純なリストに文書化するだけで十分です。することで、チームがストーリの問題点を感じ、それらに集中することが可能になります。その後で、経験豊富な同僚をその会議に招待して、リスクを収集するのです。それに慣れたならば、次に優先順位付けも試してみてください。チームがよりよい、あるいはより価値のあるテストケースを定義する上で、これが役立っているかどうかを確認しましょう。リスク収集会議を必須にしたり、長過ぎるものにしないでください。チームはすでに、会議で過負荷になっている可能性があります。それ以上のものは必要ありません。興味を持っているチームメンバと一緒に実施して、他の人にはすべて省略してしまいましょう。結果は後で確認することができます。最後に、シンプルさを維持しましょう。価値があるのは、リスクに関する議論です。その事を忘れてはなりません。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。