スクラムを使って欠陥を大幅に削減する

スクラムは、複雑な問題を解決し、進捗状況がプロジェクトを通して常に明らかなアジャイルフレームワークです。より具体的には、スクラムは経験的な工程管理のフレームワークです。フレームワークの各部分では、次のうち少なくとも１つを行います：

自由な 透明性を確保し、…
進捗状況と品質の頻繁な検査により、…
現実に応じて即座に適応することができます

複雑なシステムでは、簡単に間違いが起こります。物事を正しく行うには、規律、継続的な検査、適応が必要です。欠陥、またはバグは、スクラムで大幅に低くなります。適切に実践すれば、バグの概念は存在しないはずです。

スクラムは、スクラムの３つの役割、３つのアーティファクト、５つのイベントを通じて、ソリューションまたは製品開発サイクル全体に品質が組み込まれるようにします。

「完了」の定義：出荷可能性に焦点を当てる

スクラムチームが開発を行う前に、作成する機能にとって品質が何を意味するかについて具体的に合意形成をします。高品質の製品を提供するための基礎となるのは、チームの “完了” の定義、つまり、開発した機能がスプリントの最後に出荷可能であることの意味に関するチームの品質基準です。スクラムチームは、最も優先順位の高い、価値ある機能のチャンネルを、それが完成して出荷可能になるまで一度に取り組み、次に、それが完成して出荷可能になるまで、次に優先順位の高いアイテムに取りかかる、といった具合です。新しい機能が生まれるたびに、以前に実装されたものから少しずつ増えていきます。スクラムチームは、これまでに開発したものが機能し、顧客が望んでおり、最も望んでいるものであることをいつでも知っています。

従来であれば、開発者は「自分のコンピューターでは動きます」と言うでしょう。これは一般的な「完了の定義」でしたが、恐ろしい定義です。また、今日の急速に変化する技術環境や市場には適していません。

スクラムチームの完了の定義は、製品やソリューションの開発において、具体的に、少なくとも次のような側面に取り組むことになります：

環境：どのような開発環境であれば、新しく実装した機能が十分にテストされ、大規模に統合され、さらには十分な顧客価値があった場合に顧客に出荷できると確信できるのだろうか？
テスト： 欠陥がなく、新しく作成された機能が顧客のニーズを満たしていることを確認するには、どのような種類のテストが必要だろうか？テストは手動ではなく自動化する必要があることに注意してください。自動化がなければ、製品またはソリューション全体のテストカバレッジを定期的なサイクルで確信することはできません。また、顧客の競争上の優位性に影響を与える市場の状況に迅速に適応するためにアジャイルであることも困難になります。
文書化： 新しく作成された機能を効果的かつ効率的に展開およびサポートできるようにするために、どのような種類の文書が有用で、必要だろうか？スクラムチーム文書を重要視することは確かですが、それは有用で かろうじて十分である必要があります。他のチームが、あなたのチームの作業を、滞りなく引き継ぐことはできますか？他のメンバーは、あなたの直接の支援なしで顧客をサポートできますか？文書が不明瞭または過度に分厚いと、顧客に悪影響を与える可能性があります。

スクラムチームは、完了の定義に従うことで、スプリントごとに完了し、機能し、出荷可能な機能を構築します。

受け入れ基準：望ましい結果に焦点を当てる

受け入れ基準は、顧客やエンドユーザーの問題を解決するための結果と期待を記述することにより、高品質の製品を開発するための鍵となります。スクラムチームは、ユーザーストーリーの実装を開始する前に、明確な受け入れ基準を通じて、成功とはどのようなものかについて共通の理解に到達します。「私がXを行うと、Yが起こる」という形式の明確なステートメントは、あいまいさを排除し、アイデアを吟味するのに役立ちます。

受け入れ基準は、製品開発とテストケース作成の間の調整も可能にします。実際、受け入れ基準はテストケーススクリプトの概要を示しています。アジャイルチームは、受け入れ基準と「完了」の定義を満たすまで、繰り返し構築、テスト、検査、適応します。

スクラムチームは、明確な受け入れ基準がある場合、範囲も明確です。これにより、プロダクトオーナーが、完成したユーザーストーリーの機能をレビューし、「実際には、これを実行してもらいたいと思います」と言って、追加のスコープを要求する必要がなくなります。受け入れ基準は、１つのユーザーストーリーが終了し、新しく発見されたユーザーストーリーが開始される点を明確に示すものです。新しいユーザーストーリーは、将来のスプリントで優先順位を付けるために製品バックログに入れます。

プロダクトオーナーと協力してプロダクトバックログに新しいアイデアを追加することは、欠陥を繰り返し除去するための効果的なアプローチでありながら、チームは当面のスプリントとリリースの目標に集中し続けることができます。少なくとも、毎日のスクラムは、受け入れ基準から逸脱した作業に関する透明性を提供するのに役立ちます。

スクラムの役割は品質に焦点を当てるもの

スクラムの各役割（プロダクトオーナー、開発チーム、スクラムマスター）は、製品品質の鍵となります。

プロダクトオーナーは品質保証に重点を置く

プロダクトオーナーは、品質への期待値を設定することで、顧客とステークホルダー代表します。彼らはスクラムチームにとっての「顧客の声」であり、「新機能は顧客のニーズを満たすか」ということを絶えず考えています。開発チームへの継続的なアクセス、明確化、ガイダンスは、適切な視点を提供します。毎日、プロダクトオーナーは完了した各ユーザーストーリーを検査して承認または拒否し、高品質の製品増分を保証します。開発チームが品質管理（下記参照）を保証する一方で、プロダクトオーナーは品質保証を保証します。

プロダクトオーナーは、完成した機能をいつユーザーにリリースする準備ができているかについて、顧客、ステークホルダー、および開発チームと協力して決定します。すべてのスプリントレビューに顧客が関与することで、プロダクトオーナーは、リリースされたものが顧客を満足させるという自信を得ることができます。スクラムチームの完了の定義と各ユーザーストーリーの受け入れ基準により、プロダクトオーナーは、リリースされるものが技術的に堅実であるという確信を得ることができます。リリースされると、顧客からのフィードバックは、優先順位付けされる新製品のバックログ項目になります。

すべてのユーザーストーリーはスプリント目標（出荷可能な、具体的で価値のある機能を示す）に沿うように、スプリントごとに選ばれます。このゴールは、リリース目標（顧客が以前持っていなかった新しい機能を使用できるようにする）に沿っています。

プロダクトオーナーは、プロダクトバックログとその優先順位付けに責任があります。彼らは、プロダクトバックログをすべてのステークホルダーに公開し、その内容や順序について早期にフィードバックを得る機会を作ります。このフィードバックと責任により、チームは常に最も価値とリスクの高い機能に取り組んでいます。バックログを慎重に調整することで、チームが間違った製品機能を構築するのを防ぐことができます。スプリントレビュー中にステークホルダーと、後続のバックログの優先順位を確認することも、顧客のニーズに合わせた製品にとって重要なアクティビティです。

品質管理に注力する開発チーム

プロダクトオーナーは開発チームが提供する価値を最適化する責任がありますが、開発チームは提供されるものの技術的な品質に責任があります。

効果的な開発チームは、一度に１つのユーザーストーリーで共同作業を行い（一般に“スウォーミング”と呼ばれます) 、進行中の作業（WIP）を制限します。 WIP を制限すると、作業フローが最適化されるため、スクラムチームは、一度に多くの項目を開始するチームよりも頻繁に作業を行うことができます。 WIP が多いと、コンテキストスイッチが頻繁に行われ（”スラッシング” とも呼ばれます）、開発サイクルの最後に、着手したものの完了していない多くの作業が残り、サイロ化された状況での作業をすることになり、知識とスキルの単一障害点につながります。

スウォーミングにより、各ユーザーストーリーは精緻化、設計、開発、テスト、統合、文書化、承認され、すみずみまで行き届きます。各ユーザーストーリーの完了もより速くなります。提供された価値の量が増えます。テストを延期することもなく、複雑さとエラーを最小限に抑えるために、小さくて管理しやすい塊でテストをします。開発チームのメンバーは、一日中タスクにスウォーミングしながら、分刻みで品質フィードバックを提供します。

スクラムの一部ではありませんが、開発チームは他の優れた技術的プラクティスを使用して品質を構築し、その過程でリスクを前倒しします。エクストリームプログラミング（XP）プラクティスはソフトウェア開発で最も一般的に使用され、他の種類の製品開発に固有の、同等のプラクティスも使用する必要があります。一般的に使用されるXPプラクティスは次のとおりです。

テスト駆動開発（TDD）
継続的インテグレーション（CI）
コーディング標準
共有コードのオーナーシップ
リファクタリング
シンプルなデザイン

行動駆動開発（BDD）など、他のデザイン思考やリーン製品開発アプローチは、開発チームが無駄で不必要に複雑なアーキテクチャと実装を減らすのに役立ちます。

スプリントバックログに注意深い責任を持つ開発チームは、品質を保証します。スプリント計画中にスプリントバックログを構築するために使用される方法により、高品質の製品を作成できます。最初にスプリントの目標がどうあるべきかに焦点を当て、目標を達成するために必要なストーリーを特定するというスプリント計画の議題を通じて、チームは顧客のニーズに集中するのに役立ちます。次に、チームがスプリントの目標を達成する方法を計画することで、チームの全員が事前に品質の期待事項を調整できます。多くのチームは、品質を確保するために、各ストーリーに必要な明示的なタスクとして「完了」の定義を使用しています。スプリント計画の最後にコンセンサスを求めることで、チームは、スプリント中に高品質の製品インクリメントを構築するのに十分な時間を持って、製品バックログから適切に引き出されたかどうかを理解できます。スプリントの時間区切りは、開発リズムを生み出し、集中力を高め、健全な緊張感をもたらし、高品質基準で顧客に適したものを構築します。

スクラムマスターが質の高い成果を実現

スクラムマスターも製品の品質を確保する上で重要な役割を果たしますが、チームの有効性の向上に重点を置いているため、より影響力のある立場にあります。スクラムマスターは、特にスプリント計画、プロダクトバックログの絞り込み、スプリントレビュー、レトロスペクティブ、そしてプロダクトオーナーが承認する際に、チームに対して「完了」の定義を思い出させます。また、プロダクトオーナーに、早期かつ頻繁に価値を提供することに焦点を当てたバックログを管理するように指導します。彼らはチームに、「顧客の競争上の優位性のために変化を活用するために、開発の後半であっても変化を歓迎する」ことと、他の11のアジャイル原則を思い出させます。スプリントレトロスペクティブは、スクラムマスターにとって、チームが高品質の製品を提供するために使用しているプラクティスを振り返るのに役立つ重要な機会です。

スクラムマスターは、時間区切りの活用を促し、イベントの目的に関する明確なガイダンスを提供し、すべての参加者が望ましい結果を理解し、望ましい結果に到達することを保証するために熟考します。また、プロジェクトチーム全体（スクラムチームとステークホルダー）に、迅速なフィードバックサイクルを可能にするための透明性の使用と提供について指導します。効果的な個人と相互作用がなければ、チームが使用する開発プロセスは継続的に改善されません。レトロスペクティブから生まれる改善は、より質の高い、より早く、より頻繁に提供するより効果的なチームにつながります。

ステークホルダーは質の高いフィードバックを提供します

各スプリントの最後に、スクラムチームは、すべてのステークホルダーがスプリントレビュー中に製品のインクリメントを検査する機会を利用できるようにします。ステークホルダーからのフィードバックは、製品開発を通じて早期かつ一貫して提供される必要があり、高品質の製品を確保するための鍵です。スクラムチームの優先順位と価値に関する彼らの視点は、高品質の製品を提供するのに非常に役立ちます。

スプリントレビュー中の製品インクリメントに関するステークホルダーのフィードバックは、次のスプリントの方向性を導くこともできます。フィードバックは、行われたことと現実が示していることに基づいています。製品インクリメントが完了の定義に達し、機能している場合でも、ステークホルダーのフィードバックは、次に何を作成または調査する必要があるかを知る機会になります。

リリースされると、実際のユーザーや顧客から、さらに質の高いフィードバックが寄せられます。

スクラムでは、品質は分単位で、毎日、各スプリントの終了時、およびリリースごとに検査されます。３つのスクラムの役割（プロダクトオーナー、開発チーム、スクラムマスター）とステークホルダーの全員が品質を保証します。３つのスクラムアーティファクト（製品バックログ、スプリントバックログ、製品インクリメント）と５つのスクラムイベント（スプリント、スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ）はそれぞれ、自由な 透明性、頻繁な 検査、 および即時 の適応を通じて経験的な工程管理を可能にします。スクラムフレームワークの正しく使用すれば、バグ、欠陥、および「生産の中断」の日々とはおさらばできます。「動くソフトウェアが、進歩の主要な尺度です」とは、本当のことです。