要件定義の不安をなくす。要件定義の不安をなくす。ユニファのバックエンド分割に学ぶイノベーションメタバース開発に必要な技術の基本知識をおさらい。Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。Quality』(以下、QA2AQ)の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いします。Barriers)」の和訳を提供します。2障壁の解体おわりに参考文献アジャイル品質保証とQA2AQの背景アジャイル開発における品質保証は、特定の段階で特定の人々のみが取り組むというよりも、専門家を交えつつロードマップ策定から日々のモニタリングに至るあらゆる段階でチーム全体となって取り組む活動となります。QA2AQは、アジャイル品質の考え方と推奨される実証された活動のエッセンスを、問題と解決をペアにしたパターンのカタログとしてまとめたものです。QA2AQとの名称には、「伝統的な品質保証からアジャイル品質へと変わっていこう」「昔ながらの品質保証の考え方から脱却し、アジャイル開発に適合する形でよりアジャイルな方法で品質保証を進めよう」といったメッセージが込められています。Aguilarの3氏により、2014年のアジア地域におけるパターン国際会議AsianPLoP’14において、6つのパターン(Pattern)と15のパトレット(Patlet、問題・解決の対のみを記述したパターンのモト、小さなパターンのようなもの)のまとまりとして発表されました[1]。6[6]の発表へと至っています。本稿の筆者・鷲崎は[1]についてシェパード(投稿論文を改善させるための助言役)を務め、[3][4][5][6]について共著者としてパターンの執筆や洗練に加わっています。日本におけるアジャイル開発の進展を受けて、QA2AQを紹介することで、日本のアジャイル開発における品質保証の実践をお手伝いしたいと思い、有志が集い翻訳するに至りました。Barriers)の和訳を提供します。QA2AQの全体像ウォータフォールプロセスとアジャイルプロセスとでは、そのプロセスモデルの違いに起因して、品質保証への取り組みも自ずと異なってきます。具体的には、アジャイルプロセスの主要な特徴としてインクリメンタルな出荷とチーム全体による取り組みがあります。その特徴からアジャイルプロセスにおいて、品質保証の取り組みを早期から随時実施することでその時に必要な機能と品質を達成すること、そして、品質保証の取り組みにチーム全体として関わることが重要です。その円滑な実現に向けてQA2AQでは、本稿の執筆時点において23のパターンを、表1に示す4つの分類で整理してまとめています。[4]においては、今後追加記述の可能性のある複数のパターン候補をパトレットとして挙げています。Aguilar)[1]「品質は決して偶然に得られるものではない。それは常に、強い意志、誠実な努力、スマートな指示、および巧みな実行の結果である。Foster一般的に、QA(品質保証の活動)は、多くのスプリントの後まで、あるいは開発プロセスの後半まで行われることはありません。多くのスプリントが完了するまでQAテストを遅らせると、当初は十分と考えていた作業項目が、あとで多くの問題を引き起こしてしまう可能性や、プロセスの後半まで対処されなかった性能やセキュリティなどのシステム品質属性によって、アーキテクチャに混乱が引き起こされる可能性があります。重要なシステム品質を早期のスプリント中に認識し検討していれば、それらの品質は早い時期に組み込まれ、再作業が少なくなる可能性があるでしょう。重要なシステム品質の検査をアジャイルプロセスにどのように組み込み、QA担当者はプロセスのどこへ入ればよいでしょうか?***多くの場合、QA担当者は酷使されており、別のチームの一部になっています。QA担当者は多くの場合、上流側の実力者から非難され、常にそれに応答しなければならない状態にあります。QA担当者としてはもっと助けたいと思っていますが、時間も人も十分ではありません。QA担当者は、製品をリリースするにあたっての障害物と見なされる可能性があり、多くの場合、QA担当者と開発チームの間に「我々と(我々とは異なる)あいつら」というメンタリティをもたらします。アジャイルチームがフィーチャーと重要な機能に集中することは重要です。システム品質によっては、エンドユーザーにとって有益なものを示してすぐに満足させることができないため、重要ではないように思われる場合があります。多くのチームメンバーは品質を重視しておらず、また多くの場合、さまざまなシステム品質を理解しておりません。開発者は、ユーザーストーリーの製品要求に基づいてシステムを実装することが得意です。対してQA担当者は、システムの品質を理解し検証することについて多くの専門知識を持っています。***そこで、アジャイルプロセスの一環として、システムの品質を理解し、記述し、開発およびテストする方法を構築します。これは、プロジェクトにとって重要なシステム品質を高いレベルで理解し、品質シナリオを使ってそれを記述する手段を提供することで実現できます。品質に関する作業は、プロダクトバックログタスクに含めることができ、最終的に、システム品質の識別、テスト、検証に役立つ品質ストーリーを作成できます。これには、重要な品質を特定し、スプリントに含めるためのバックログへ確実に含まれるように、プロダクトオーナー(PO)とQA担当者を引き込むことが含まれます。アジャイルチームがこれを行うには、さまざまな方法があります。重要な考え方は、QA担当者をチームに組み入れてOneチームとしてあたり、品質の考え方をアジャイルマインドセットに統合することです。スクラムを実践している際、こういったシステム品質へ注目する考え方が、計画やテストを含む通常のスプリントに組み込まれていることを確認します。図1に、品質に関する活動をスクラムプロセスに追加して重点的に取り組む方法の例を示します。構想段階では、重要な品質属性を考慮して理解する必要があります。次に、プロダクトオーナーと協力して、スプリントの中で扱っていけるように、品質属性を優先順位付けしてバックログに含めます。スプリント中に、関連するすべての品質上のタスクが含まれ、QA担当者は、品質ストーリーの作成を支援し、特定のユーザーストーリーに対して品質の折り込みのための品質基準を識別できます。通常の機能テストや受け入れテストに加えて、スクラムチームは、システム品質の妥当性を確認するためのテストや、ダッシュボードを通して品質をモニタリングする方法も開発します。取締役(監査等委員)。