品質スプリント
- パターン：品質スプリント（(原題 Quality Focused Sprints 原著 Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar）[1]
「品質は行為ではなく、習慣である」――アリストテレス
機能だけでは実行可能なシステムにはなりません。むしろ、実行可能なシステムは、システムの品質に注意を払いながら機能に焦点を当てることによって達成されます。
あなたは機能を実装することに集中してきました。動くソフトウェアを各スプリントで届けています。しかしあなたは、より多くのユーザー、より多くのデータ、より多くのトランザクション、その他が存在する本番環境の要件を満たしていないことを心配しています。
どうすればこれらの非機能要件を必要なタイミングでシステムに組み込むことができるでしょうか？
＊＊＊
必要な機能に優先順位を付けて実装することで、プロジェクトは前進し続け、顧客から肯定的なフィードバックが得られます。ただし、重要なセキュリティ、パフォーマンス、およびまだ対処されていないその他の品質特性がある場合、機能に焦点を合わせただけではリリースできるほど十分に優れたシステムは生まれません。
一方で、特定の非機能要件に集中しすぎると、早すぎる段階で抽象化と最適化を行ってしまう可能性が生じます。各スプリント期間で、どのシステム品質特性に焦点を当てるべきかを知るのは難しい場合があります。
＊＊＊
そこで、ソフトウェアの非機能品質に集中することに時間をかけ、1つないしはそれ以上のシステム品質特性の測定と改善に特化したスプリントを設けます。
このスプリントの目的は、新機能を届けることではなく、達成すべき結果へ向けてより良いシステムを届けることに集中することであることを、関係者に理解させます。
パフォーマンスに重点を置いている場合、スプリントの目標は、具体的な改善領域を特定することです。他のスプリントと同様に、作業を特定して優先順位を付け、バックログを作成する必要があります。ただし、品質スプリントでの作業の特性は異なります。機能に関するストーリーの代わりに、改善しようとしている品質特性に関するストーリーを特定して優先順位を付ける必要があります。
作業している品質特性に応じて、実行するタスクは異なります。また、これらのタスクの一部は、他のタスクよりも簡単に見積もることができます。
パフォーマンスが心配な場合は、システムの重要な部分をチューニングする前に現在のパフォーマンスを測定する必要があります。パフォーマンス改善の程度を正確に予測することは困難ですが、品質のストーリーを、現在のパフォーマンスの測定、負荷テスト、システムのホットスポットの分析、設計のやり直しといった見積もり可能なタスクに分割する必要があります。
1つの品質特性を改善すると、他のシステム品質特性に影響を与える可能性があります。ユーザビリティの改善を行うと、ユーザーとシステムの相互作用を修正し、システムAPIを作り直すことになるかもしれません。また、ユーザビリティの実験またはA/Bテストを実行するまで、「より良い」ユーザーインタラクションアプローチが明確でない場合があります。
したがって、品質スプリントの「完成（Done）」の定義には、改善の実装と検証以上のものが含まれます。品質改善が既存のシステム機能に与える影響を測定し、場合によっては品質受け入れ基準または着陸ゾーンを改定することも必要になるかもしれません。
