スクラムは、複雑な問題を解決し、その過程で進捗状況を公開するためのアジャイルフレームワークです。 より具体的には、スクラムは経験的なプロセス制御フレームワークです。 フレームワークの各部分は、次のうち少なくとも 1 つを実行します。
- 自由な 透明性を確保し、…
- 進捗状況と品質の頻繁な 検査 により、…
- 現実に応じて即座に 適応 することができます
複雑なシステムでは、物事を間違えるのは簡単です。 物事を正しく行うには、規律、継続的な検査、適応が必要です。 欠陥、またはバグは、スクラムで大幅に低くなります。 適切に実践すれば、バグの概念は存在しないはずです。
スクラムは、スクラムの 3 つの役割、3 つのアーティファクト、5 つのイベントを通じて、ソリューションまたは製品開発サイクル全体に品質が組み込まれるようにします。
「完了」の定義:出荷可能性に焦点を当てる
スクラムチームが開発を行う前に、作成する機能にとって品質が何を意味するかについて具体的に合意します。 高品質の製品を提供するための基礎となるのは、チームの “完了” の定義、 つまり、開発した機能がスプリントの最後に出荷可能であることの意味に関するチームの品質基準です。 スクラム チームは、価値のある機能の次に優先度の高いチャネルが完成して出荷可能になるまで一度に作業し、次に優先度の高い項目が完成して出荷可能になるまで開始します。 作成される新しい機能はそれぞれ、以前に実装されたものに対して増分されます。 スクラムチームは、これまでに開発したものが機能し、顧客が望んでおり、最も望んでいるものであることをいつでも知っています。
従来、開発者は「自分のコンピューターで動作します」と言うでしょう。 これは一般的に使用される完了の定義でしたが、恐ろしい定義です。 また、今日の急速に変化する技術環境や市場では機能しません。
スクラム チームの完了の定義は、製品またはソリューションの開発の次の側面に具体的に、少なくとも対処します。
- 環境： 新しく実装された機能が十分にテストされ、大規模に統合され、十分な顧客価値があれば、顧客に出荷できると確信できる開発環境はどの開発環境ですか?
- テスティング： 欠陥がなく、新しく作成された機能が顧客のニーズを満たしていることを確認するには、どのような種類のテストが必要ですか? テストは手動ではなく自動化する必要があることに注意してください。 自動化がなければ、製品またはソリューション全体のテストカバレッジを定期的なサイクルで確信することはできません。 また、顧客の競争上の優位性に影響を与える市場の状況に迅速に適応するために機敏であることも困難になります。
- ドキュメンテーション： 新しく作成された機能を効果的かつ効率的に展開およびサポートできるようにするために、どのような種類のドキュメントが有用で必要ですか? スクラムチームは価値のあるドキュメントを作成しますが、それは有用で 、ほとんど十分ではありません。 他のチームがあなたのチームの仕事を見逃すことなく拾うことができますか? 他の人はあなたの直接の支援なしで顧客をサポートできますか? ドキュメントが不明瞭または肥大化していると、顧客に悪影響を与える可能性があります。
スクラムチームは、完了の定義に従うことで、スプリントごとに完了し、機能し、出荷可能な機能を構築します。
受け入れ基準:望ましい結果に焦点を当てる
受け入れ基準は、顧客またはエンドユーザーの問題を解決するための結果と期待を説明することにより、高品質の製品を開発するための鍵です。 スクラム チームは、ユーザー ストーリーの実装を開始する前に、明確な受け入れ基準を通じて成功とはどのようなものかについて共通の理解に到達します。 「私がXを行うと、Yが起こる」という形式の明確なステートメントは、あいまいさを排除し、アイデアを吟味するのに役立ちます。
受け入れ基準は、製品開発とテスト・ケース作成の間の調整も可能にします。実際、受け入れ基準はテスト・ケース・スクリプトの概要を示しています。 アジャイルチームは、受け入れ基準と「完了」の定義を満たすまで、繰り返し構築、テスト、検査、適応します。
スクラムチームは、明確な受け入れ基準がある場合、範囲も明確です。 これにより、製品所有者が完成したユーザー ストーリーの機能をレビューし、「実際には、これを実行したいと思います」と言って、追加のスコープを要求する必要がなくなります。 受け入れ基準は、1 つのユーザー ストーリーが終了し、新しく検出されたユーザー ストーリーが開始される場所を明確に示すものです。 新しいユーザーストーリーは、将来のスプリントで優先順位を付けるために製品バックログに表示されます。
プロダクトオーナーと協力してプロダクトバックログに新しいアイデアを載せることは、欠陥を繰り返し除去するための効果的なアプローチでありながら、チームは当面のスプリントとリリースの目標に集中し続けることができます。 少なくとも、毎日のスクラムは、受け入れ基準から逸脱した作業に関する透明性を提供するのに役立ちます。
スクラムの役割は品質に重点を置いています
スクラムの各役割 (プロダクトオーナー、開発チーム、スクラムマスター) は、製品品質の鍵となります。
製品所有者は品質保証に重点を置いています
プロダクトオーナー は、品質への期待値を設定することで、顧客と利害関係者を代表します。 彼らはスクラムチームの「顧客の声」であり、「新機能は顧客のニーズを満たすか」と絶えず尋ねます。 開発チームへの継続的なアクセス、明確化、ガイダンスは、適切な視点を提供します。 毎日、製品所有者は完了した各ユーザーストーリーを検査して承認または拒否し、高品質の製品増分を保証します。 開発チームが品質管理(下記参照)を保証する一方で、製品所有者は品質保証を保証します。
製品所有者は、完成した機能をいつユーザーにリリースする準備ができているかについて、顧客、利害関係者、および開発チームと協力して決定します。 すべてのスプリントレビューに顧客が関与することで、製品所有者は、リリースされたものが顧客を満足させるという自信を得ることができます。 スクラム チームの完了の定義と各ユーザー ストーリーの受け入れ基準により、製品所有者は、リリースされるものが技術的に堅実であるという確信を得ることができます。 リリースされると、顧客からのフィードバックは、優先順位付けされる新製品のバックログ項目になります。
すべてのユーザーストーリーは 整列する各スプリントを選択しました スプリント目標 (出荷可能な具体的で価値のある機能のデモンストレーション)、リリース目標 (顧客が以前には持っていなかった新機能を使用できるようにする) と一致し、範囲と目的の外側の境界を提供する製品ビジョンと製品ロードマップと一致します。
製品所有者は、 製品バックログ とその優先順位付けを所有します。 製品のバックログをすべての利害関係者に公開し、その内容と順序に関する早期のフィードバックの機会を作成します。 このフィードバックと所有権により、チームは常に次に高い価値と次に高いリスクの機能に取り組んでいます。 バックログを慎重に調整することで、チームが間違った製品機能を構築するのを防ぐことができます。 スプリントレビュー中に利害関係者とこれらの今後のバックログの優先順位を確認することも、顧客のニーズに合わせた製品の重要なアクティビティです。
品質管理に注力する開発チーム
プロダクトオーナーは開発チームが提供する価値を最適化する責任がありますが、 開発チームは 提供されるものの技術的な品質に責任があります。
効果的な開発チームは、一度に 1 つのユーザー ストーリー (一般に “スウォーミング” と呼ばれます) で共同作業を行い、進行中の作業 (WIP) を制限します。 WIP を制限すると、作業フローが最適化されるため、スクラム チームは、一度に多くの項目を開始するチームよりも頻繁に作業を行うことができます。 WIP が高いと、コンテキストの切り替えが頻繁に行われ (“スラッシング” とも呼ばれます)、開発サイクルの最後に開始されたが完了していない多くの作業が発生し、サイロで非共同作業で作業し、知識とスキルの単一障害点につながります。
スウォーミングにより、各ユーザーストーリーは精緻化、設計、開発、テスト、統合、文書化、承認され、完全に焼き付けられます。 各ユーザー ストーリーはより速く完了します。 配信される価値の量が増えます。 テストは後まで延期されず、複雑さとエラーを最小限に抑えるために、小さくて管理しやすいチャンクで行われます。 開発チームのメンバーは、一日中タスクに群がりながら、分刻みで品質フィードバックを提供します。
スクラムの一部ではありませんが、開発チームは他の優れた技術的プラクティスを使用して品質を構築し、その過程でリスクを前倒しします。 エクストリーム プログラミング (XP) プラクティスはソフトウェア開発で最も一般的に使用され、他の種類の製品開発に固有の同等のプラクティスも使用する必要があります。 一般的に使用されるXPプラクティスは次のとおりです。
- テスト駆動開発 (TDD)
- 継続的インテグレーション (CI)
- コーディング標準
- 共有コードの所有権
- リファクタリング
- シンプルなデザイン
行動駆動開発 (BDD) など、他のデザイン思考やリーン製品開発アプローチは、開発チームが無駄で不必要に複雑なアーキテクチャと実装を減らすのに役立ちます。
スプリントバックログを慎重に所有する開発チームは、品質を保証します。 スプリント 計画中にスプリント バックログを構築するために使用される方法により、高品質の製品を作成できます。 最初にスプリントの目標がどうあるべきかに焦点を当て、目標を達成するために必要なストーリーを特定するというスプリント計画の議題を通じて、チームは顧客のニーズに集中するのに役立ちます。 次に、チームがスプリントの目標を達成する方法を計画することで、チームの全員が事前に品質の期待事項を調整できます。 多くのチームは、品質を確保するために、各ストーリーに必要な明示的なタスクとして「完了」の定義を使用しています。 スプリント計画の最後にコンセンサスを求めることで、チームは、スプリント中に高品質の製品インクリメントを構築するのに十分な時間を持って、製品バックログから適切に引き出されたかどうかを理解できます。 スプリント自体のタイムボックスは、開発リズムを生み出し、集中力を高め、緊張の健全なバランスを提供して、高品質基準で顧客に適したものを構築します。
スクラムマスターが質の高い成果を実現
スクラムマスター も製品の品質を確保する上で重要な役割を果たしますが、チームの有効性の向上に重点を置いているため、より影響力のある立場から。 スクラムマスターは、特にスプリント計画、製品バックログの改良、スプリントレビュー、ふりかえり、さらには製品所有者のサインオフ中に、完了の定義をチームに継続的に思い出させます。 また、製品所有者に、早期かつ頻繁に価値を提供することに焦点を当てたバックログを管理するように指導します。 彼らはチームに、「顧客の競争上の優位性のために変化を活用するために、開発の後半であっても変化を歓迎する」ことと、 他の11のアジャイル原則を思い出させます。 スプリントの 振り返りは、スクラムマスターにとって、チームが高品質の製品を提供するために使用しているプラクティスを振り返るのに役立つ重要な機会です。
スクラムマスターは、時間区切りの使用を容易にし、イベントの目的に関する明確なガイダンスを提供し、すべての参加者が望ましい結果を理解し、望ましい結果に到達することを保証するために質問をします。 また、プロジェクトチーム全体(スクラムチームと利害関係者)に、迅速なフィードバックサイクルを可能にするための透明性の使用と提供について指導します。 効果的な個人と相互作用がなければ、チームが使用する開発プロセスは継続的に改善されません。 促進されたふりかえりから生じる改善は、より質の高い、より早く、より頻繁に提供するより効果的なチームにつながります。
利害関係者は質の高いフィードバックを提供します
各スプリントの最後に、スクラムチームは、すべての利害関係者がスプリントレビュー中に製品の増分を検査する機会を利用できるようにします。 利害関係者からのフィードバックは、製品開発を通じて早期かつ一貫して提供する必要があり、高品質の製品を確保するための鍵です。 スクラムチームの優先順位と価値に関する彼らの視点は、高品質の製品を提供するのに非常に役立ちます。
スプリントレビュー中の製品の増加に関する利害関係者のフィードバックは、次のスプリントの方向性を導くこともできます。 フィードバックは、行われたことと現実が示したことに基づいています。 製品の増分が完了の定義に達し、機能している場合でも、利害関係者のフィードバックは、次に何を作成または調査する必要があるかを通知します。
リリースされると、実際のユーザーや顧客からさらに質の高いフィードバックが寄せられます。
スクラムでは、品質は分単位で、毎日、各スプリントの終了時、およびリリースごとに検査されます。 3 つのスクラムの役割 (プロダクト所有者、開発チーム、スクラム マスター) と利害関係者はすべて品質を保証します。 3 つのスクラム アーティファクト (製品バックログ、スプリント バックログ、製品インクリメント) と 5 つのスクラム イベント (スプリント、スプリント計画、デイリー スクラム、スプリント レビュー、スプリント レトロスペクティブ) はそれぞれ、自由な 透明性、頻繁な 検査、 および即時 の適応を通じて経験的なプロセス制御を可能にします。 スクラムフレームワークの使用を規律すれば、バグ、欠陥、および「生産の中断」の時代はなくなるはずです。 本当に、「動作するソフトウェアが進歩の主要な尺度です」。
欠陥を減らし、私たちの助けを借りて品質を向上させます
製品の品質を向上させるための機敏な人材をお探しですか? 10,000人以上のアジャイルプロフェッショナルをトレーニングしてきました。 アジャイルジャーニーでどのように支援できるかをお尋ねください。
