| 分類 | 概要 | パターン名 |
|---|---|---|
| 中核 | 他のパターンを用いるうえでの基礎となるパターン |
|
| 品質のアジャイルなあり方 | アジャイルプロセスにおける品質保証のあり方や役割のパターン |
|
| 品質の特定 | 重要な品質を特定するためのパターン |
|
| 品質の可視化 | 重要な品質を可視化しチームメンバーに気付かせるパターン |
|
QAを含むOneチーム
- パターン：QAを含むOneチーム (原題 Whole Team, 原著 Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar）[1]
「チームワークによって夢を実現する」――Bang Gae
「チーム全体のプレー方法が成功を決定付ける」――Babe Ruth
昔からQA担当者は開発グループとは別のグループに属していることが多いのですが、一般的に、ほとんどの組織のQA担当者はビジネスの利害関係者に十分にアクセスできていません。結果として、概してQA担当者は多くの文書を作成し、詳細な仕様書に基づいてテスト内容の明細を記述することを好むようになります。しかしながらQA担当者の作成した文書は、品質に一貫性がなかったり、内容が古かったりすることがあります。またテストには多大な労力がかかるため、昔からQA担当者は、再テストと再作業を最小限に抑えるために、システムが完成してからテストすることを好んでいました。また、通常、QA担当者はプロセスの後半まで関与しないため、市場投入までの時間遵守への圧力の下で、品質に関して妥協してしまう可能性があります。
QA担当者が開発チームの一部ではない場合には、多くの問題が発生する可能性があります（「我々」対「彼ら」シンドロームの発生）。QA担当者をアジャイルチームに組み込むにはどうすればよいのでしょうか？
＊＊＊
システム品質に偏りがないようにすることは非常に重要です。
多くの場合、QAに専念するリソースや人々は限られています。
QA担当者は、品質を理解し、問題をテストする多くの経験を持っています。
QA担当者は、チームを支援するのではなく、欠陥を見つけようとしているだけの敵と見なされる可能性があります。
QA担当者の専門知識と考え方がソフトウェアプロセスの後期まで利用されないことは、チームにとって大きな損失です。
＊＊＊
したがって、アジャイル品質チームでは、最初からQA担当者をアジャイルチームの一部として含めることが重要です。
最初からアジャイルチームの一部として含まれている場合には、QA担当者は、アジャイルチームの全員が要件を理解して検証することを支援できます。QA担当者は完成（Done）の定義付けも支援できるようになり、考慮すべき品質属性とそれらにいつ対処すべきかをプロダクトオーナーが理解できるように手助けすることが可能になります。
QA担当者の役割は、別のチームの部外者から、一体となった「アジャイルチーム」の一員へとシフトします。この「外部」から「チームメンバー」へのシフトにより、品質に関するチーム全体の知識が向上します。QA担当者が最初からチームの一員であると、多くの価値が生み出されます。QA担当者は、開発プロセス全体を通してシステムに品質を組み込む上で役立ちます。QA担当者は、最初からチームに参加し、重要な品質特性を可視化することにより、開発プロセスのどのタイミングで特定のシステム品質特性にとりかかるのが最適か（異なる品質特性に対していつ何を行うべきか）を判断する手助けをします。
QA担当者をアジャイルチームと一体化するためによく使われる方法は、QA担当者をチームに割り当てることです。割り当てられたQA担当者は、デイリースタンドアップに参加し、プロダクトオーナーと会い、テストの作業でチームをサポートし、重要な品質の特定と品質ロードマップの作成を支援します。
