| 分類 | 概要 | パターン名 |
|---|---|---|
| 中核 | 他のパターンを用いるうえでの基礎となるパターン |
|
| 品質のアジャイルなあり方 | アジャイルプロセスにおける品質保証のあり方や役割のパターン |
|
| 品質の特定 | 重要な品質を特定するためのパターン |
|
| 品質の可視化 | 重要な品質を可視化しチームメンバーに気付かせるパターン |
|
重要な品質の発見
- パターン：重要な品質の発見（原題Find Essential Qualities , 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]
「単純化する能力とは、不必要なものを排除して、必要なものを話せるようにすることである」――Hans Hofmann（ドイツの芸術家）
非常に多くの場合、システムの重要な品質特性は、開発プロセスの後期まで見過ごされたり簡素化されたりすることがあります。これにより、品質の欠陥を修正するために、ソフトウェア設計の大規模なリファクタリングとやり直しによる遅延を引き起こす可能性があります。大規模なやり直しを回避するには、アジャイルチームがこれらの基本的な品質特性を特定し、それらの品質特性をチームにタイムリーに可視化することが重要です。
アジャイルチームは、進化するシステムにとって重要な品質特性をどのようにすれば理解できるでしょうか？
＊＊＊
基本的な品質特性に十分早く焦点を合わせないと、重大な問題、遅延、手直しを引き起こす可能性があります。機能的な欠陥の修正には時間がかかる場合があります。パフォーマンスやスケーラビリティの欠陥を改善するには、システムのアーキテクチャに大幅な変更と修正が必要になる場合があります。
初期の取り組み中にシステムの重要な品質特性が特定され、対処された場合、重要なアーキテクチャ検証を早期に実行して、アーキテクチャの欠陥による重大な混乱または遅延を防ぐことができます。
システムの品質特性に焦点を合わせ過ぎると、重要な機能要件から注意が逸れることがあります。難しい点は、機能性とシステム品質の両面に適切なバランスで注意を払うことです。
一方では、すべてのシステムの品質特性に対するテストを開発し自動化できるとよいと思います。システムの品質特性を毎日テストできるとすると素晴らしいことです。ただし、たとえば、使いやすさといったものをテストするのは費用がかかり、頻繁にテストするのは現実的ではありません。テストが実行される頻度と、テストの実行コストとの間の合理的なバランスを見つけることは、困難な場合があります。
＊＊＊
そのため、重要な利害関係者と適切な時期にチーム会議を開催して、システムで考慮する必要がある最も重要な品質特性についてブレインストーミングすることが必要です。
プロジェクトの開始時は、プロジェクトの成功に不可欠な重要な品質特性を特定することが重要です。これは、基本的な品質特性に同意し、それらをチームに対して可視化するアジャイル品質属性ワークショップを介して行うことができます。これらのワークショップには、プロダクトオーナー、開発者、アーキテクト、品質保証担当、顧客などの主要メンバーを含める必要があります。アジャイル品質属性ワークショップは、時間を長く掛ける必要はなく、問題点を引き出せればよいです。
ロードマップに大きな変更があった場合、または新しいシステムの品質特性が明らかになった場合はいつでも、チームは、別の品質ワークショップを開催することを選択できます。
1～2時間続くことのある品質ワークショップでは、シンプルなコラボレーション手法を用いて、システムの品質特性を特定し、特徴付けることができます。品質チャートは、チームメンバーが特定の品質の懸念事項を記録するために、ホワイトボード上に懸念事項を提示するものです。懸念事項を特定し、特定のシステム品質（パフォーマンスや信頼性など）に関連付けた付箋に書き留めることができます。チームは、最も重要かつ緊急と考えるものに投票し、それらのアジャイル品質シナリオを作成できます。チームは、品質シートまたはテンプレートを使用して品質シナリオを記録することができます。
主要な機能とそれらを提供する順序を概説する、プロダクトまたはプロジェクトのロードマップを策定した後、潜在的なアーキテクチャ上のリスクを特定できます。これらのリスクに基づき、品質固有の懸念事項を特定し、ロードマップ上の機能に関連付けることができます。特定のフィーチャーを有効にするために必要な特定の品質特性とアーキテクチャの機能を、いつ提供する必要があるかの大まかなタイムラインを描き、バックログに含めることができます。
また、スプリント計画またはリリース計画の期間は、新しいシステム品質の問題を再検討して対処するのに適したタイミングです。チームメンバーは、リリースで提供する必要のあるシステムの品質特性を特定し、品質ストーリーを作成し、それらを達成するために必要なアクティビティを特定できます。
システム品質ダッシュボードを使用して、プロジェクト全体でシステムの重要な品質特性を監視することができます。
