品質の折り込み
- パターン：品質の折り込み（原題Fold-out Qualities , 原著 Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar）[1]
「今やストーリーの残りがわかっている」――Paul Harvey（アメリカのブロードキャスター）
ユーザーストーリーまたはフィーチャは、プロダクトオーナーの期待を満たし、もともと合意していた品質特性を備えている場合、出荷可能と見なされます。通常、プロダクトオーナーが期待することは、技術非依存な形で大まかな受け入れ基準として表現されます（例：「ユーザーは、ラジオボタンをクリックしてクレジットカードによる支払いを選択できる」ではなく、「ユーザーは、クレジットカードによる支払いを選択できる」）。
しかし、実装されたストーリーによって示されなければならない合意されたシステムの品質特性を、どのように定義して記述すればよいでしょうか？
＊＊＊
一部のユーザーストーリーには、完成にあたってのシステム品質に関する明確な基準があります。それらのストーリーが受け入れられるためには、特定の性能、使いやすさ、国際化、信頼性、またはその他の非機能要件を満たす必要があります。
スプリント中は主に、機能要件に焦点を当てることになり、多くの場合、システムの品質特性の推定に多くの時間は与えられません。また、特定の機能要件が実装されるまで、一部の品質特性やシステムのさまざまな部分への影響は明らかになりません。
＊＊＊
したがって、これらの状況では、具体的な品質受け入れ基準を作成し、ユーザーストーリーに添付します。
これらの品質は、ユーザーストーリーの受け入れに不可欠であるため、折り込み品質と呼ばれますが、必ずしも最初に特定できる受け入れ基準とは限りません。システムがどのように振る舞うべきか、どのような性質を示すべきかについて、より深く対話を交わしながら展開します。最初の関心事はその機能を正しく実装することですが、折り込み品質を満足させることで、設計と実装の選択に大きく影響する可能性があります。したがって、議論して合意に達することが重要です。多くの場合、完成の定義（DoD）を説明するのに役立つ重要な品質特性となります。
たとえば、「ユーザーとしてクレジットカードを用いて注文の支払いをする」というストーリーを満たすには、「システムは1分間につき100,000回VISAクレジットカード支払いトランザクションを処理できる」という性能上の品質を指定するかもしれません。
このストーリーにシステムの必要な品質特性に関する追加の受け入れ基準を明らかにするために、いくつかの品質関連の質問をすることができます。
- 使いやすさ：クレジットカードを使用して行った注文をキャンセルできるか？ その場合、いつか？
- セキュリティ：システムはクレジット情報を保持するか？ その場合、保持方法を制御できるか？
- セキュリティ：クレジット情報は不正アクセスから保護され、安全に送信されるか？
- 性能：注文して確認を受け取るまでにどのくらいの時間がかかるか？ 多くのユーザーがいるのはいつか？
- 可用性：クレジットカードサービスが利用できない場合はどうなるか？
通常、これらの質問に答えることで、クレジット情報を安全に送信したり、特定の性能目標を達成したりするなど、ストーリーの受け入れ基準に対して品質受け入れ基準を明示的に付加することにつながります。様々な品質特性が同時に複数特定される場合もあります。たとえば、クレジットカード情報を安全に送信するだけでなく、すべての個人情報や財務情報も安全に送信する必要があります。この場合、特定の品質受け入れ基準を当該ストーリーに添付することに加えて、バックログに追加されるいくつかの品質関連のストーリーを特定し、いくつかの特定の品質シナリオを作成することもできます。
品質関連の質問をすることで、新しい機能が特定される場合もあります。たとえば、注文に関する使いやすさの関心事により、注文をキャンセルして追跡する必要性を特定できます。この場合、キャンセルおよび注文の追跡に関する新しいユーザーストーリーを作成し、バックログに追加できます。
