スクラムする方法：実用ガイド - サイバーメディアン

エクストリームプログラミング（XP）、スクラム、クリスタルメソッド、適応型ソフトウェア開発（ASD）、機能駆動開発（FDD）、動的システム開発（DSDM）、軽量など、アジャイル開発の傘下にある多くの方法もあります。RUP、テスト駆動開発（TDD）など。多くのアジャイル開発手法の中で、スクラムの実装がより一般的です。

アジャイルまたはウォーターフォール？図を参照してください

Standish Groupからの最新のレポートは、2013年から2017年の間に調査したプロジェクトを対象としています。この期間のアジャイルとウォーターフォールの成功、チャレンジ、失敗の全体的な内訳を以下に示します。アジャイルプロジェクトは約2倍成功する可能性があります。失敗する可能性は1/3少なくなります。

（出典：vitalitychicago.com — ウォーターフォールとアジャイルプロジェクトの成功率の比較）

この記事では、主にスクラムの理解、スクラムの実装プロセス、およびスクラムの実装によってもたらされる変更について説明し、実行中のスクラムとは何かについて説明します。

スクラムとは何ですか？

スクラムは、複雑な製品を開発および保守するためのフレームワークであり、段階的で反復的な開発プロセスです。このフレームワークでは、開発プロセス全体がいくつかの短い反復サイクル、スプリントと呼ばれる短い反復サイクルで構成され、各スプリントの長さは2〜4週間です。

スクラムで、製品のバックログを使用して製品のニーズを管理します。製品バックログは、実装の優先順位に従ってソートされ、ソートの主な原則として商業的価値があります。スプリントでは、スクラムチームは、開発用の製品バックログから最も優先度の高い要件を選択しました。選択された要件は、スプリントバックログと呼ばれるタスクのリストを取得するために、スプリント計画会議で議論、分析、および推定されます。スクラムチームがスプリントバックログリストのすべてのタスクを完了すると、スプリントは終了し、次のスプリント反復サイクルに進みます。

一部の企業でスクラムが失敗した理由

スクラムには大きな価値があります。ただし、一部の企業ではスクラムを実装するのが困難です。スクラムは組織に実質的な影響を及ぼさないと言う人もいます。なぜ彼らはそのような結果をもたらすのですか？主な理由は次のとおりです。

アジャイルの方が速い —プロジェクトチームはアジャイルを正しく理解していません。敏捷性は速い、つまり進歩に追いつくと単純に考えており、システムの制約から解放されます。
アジャイルの方が速いか、残業する必要があります —一部の企業は新しい機能を開発する必要があると聞いています。スクラムの実施により、プロジェクトチームは残業する必要があり、2週間以上の開発作業は1週間以内に解除されます。スクラムを実装するということは、プロジェクトチームが残業していることを意味します。これは、プロジェクトチームの敏捷性に「恐れ」をもたらします。
製品バックログが適切に維持されていない — POは作業の資格がない、効果的なユーザーストーリーを分割できない、またはユーザーのストーリー分割が不合理である、増分世代開発を実現できない。
チーム形成の問題 —スクラムには自己組織化チームに対する高い需要がありますが、多くのチームメンバーは、自己組織化の基準に達していないと感じています。
アジャイル文化の欠如 —スクラムは、作業の透明性、プロジェクトのリアルタイムの完了、および各人のタスク認識を提唱しています。スプリントボードとプロジェクトのバーンダウンチャートは遮るものがなく、多くの人がそれに慣れていません。
検査と適応 が適切に行われていない—反復の過程で、問題を時間内に発見できないか、問題が発見され、問題を効果的に解決できないため、プロジェクトチームは不満を感じます。などなど。

スクラムの知識が固執しているだけの場合：

「私は午前中にアイデアを持っています。それは午後に実現され、夜にはオンラインになります。」

不適切です。私の意見では、スクラムは間違いなく価値があります。スクラムの主な機能は次のとおりです。

スクラムは、顧客にとって価値が高く、ユーザーのニーズをよりよく満たす製品バックログの開発に優先順位を付けることができます。
ウォーターフォールプロセスでの開発方法と比較して、スクラムを実装することにより、チームは開発効率を2倍にし、チームの役割を最大化することができます。
スクラムは、開発サイクルを短縮し、プロジェクトの実施効率を高めることができます。

ただし、スクラムを実装しても、ルールやプロジェクトの制約を受けないという意味ではありません。では、スクラムを実装するための正しい姿勢は何ですか？

スクラムを実装するための手順

1.POを割り当てます

POは役割である製品の所有者であり、POは管理製品のやることリストの唯一の所有者です。もちろん、一部の企業では、POはすでに組織として存在しています。たとえば、当社はスクラムの実装において組織としてPOを実装しています。

所有者として、それは全体像を持っている必要があります。業界の情報と方向性を深く理解する。製品の方向性を把握し、製品の短期および中期および長期の計画と管理を担当することができます。会社の戦略的要件に従ってユーザー調査と製品機能計画を実施し、絶えず変化するニーズを追跡し、製品を革新し続けることができます。

さらに、POを組織として使用する場合、ソフトウェア開発プロジェクトでは、POチームには、製品マネージャーやエンドユーザーなどの他の利害関係者が含まれる場合があります。

2.開発チームを編成する

チームは製品の実装者であり、各スプリントの最後に潜在的な出荷可能な増分と「完了した」製品の増分を提供する責任があります。

チームには主に開発およびテスト担当者が含まれ、チームは製品のPOのビジョンを実装できる必要があります。

チームのサイズは約5〜9人である必要があります。

スクラムチームもクロスファンクショナルである必要があり、ほとんどの企業で実装が難しい場合でも、「フルスタック」機能を備えたメンバーの方が望ましいです。

3.スクラムマスターを選択します

スクラムマスターはスクラムプロセスを担当し、POおよび開発チームにサービスを提供します。スクラムマスターは儀式の感覚を持っている必要があり、反復計画会議、毎日のスタンドアップ会議、機能デモンストレーション会議、および遡及的レビュー会議を効果的かつ効率的に開催できます。スクラムマスターは、チームを支援するために高度な実行力と信頼性を維持する必要があります。チームが高品質の製品を効率的に提供できるように、提供目標と品質目標に焦点を合わせます。チームを推進して効率的なプロセスを構築し、アジャイルの価値観、原則、アジャイルプラクティスについてチームを導きます。スクラムが正しく使用されるように、チームの他のメンバーをトレーニングする責任があります。コミュニケーション、問題管理、対立解決は、チームがすべての障害を取り除くのに役立ちます。

4.製品バックログを維持する

製品バックログは、すべてのバックログアイテムのコレクションであり、会社の戦略と製品ビジョンに基づいています。POは、製品バックログ内のすべてのアイテムをビジネス価値に応じた優先順位に従ってソートし、優先アイテムリストを形成します。製品バックログは、製品開発の「ロードマップ」として使用できます。 製品のコンテキストを理解するには、製品のバックログ項目が最適なリファレンスです。

毎日、新しい競合他社からの新しい要求に直面しています。つまり、POは製品設計を継続的に最適化し、新しい変更に対処するために製品バックログの優先順位を調整する必要があります。

このプロセスでは、POはすべての利害関係者およびチームと協議して、製品のバックログがユーザーの真の主張を反映していることを確認する必要があります。

5.ストーリーポイントを使用したアジャイル推定

比較的機敏な見積もりは、通常、スプリント計画またはスプリント中の修正で実行され、製品のバックログは、実際の開発およびテスト作業の責任者とともにチームによって評価されます。

実際にスプリント計画をより効率的に実施するために、POとスクラムマスターはスプリント計画会議の前に大まかな見積もりを行います。彼らは次のようなこの種の質問をする必要があります：

スプリント計画が実行可能かどうかを確認しますか？
これらの問題を完了するのに十分な情報はありますか？
製品バックログアイテムの分割は妥当ですか？

開発チームが見積もりを行うときは、従来の方法（つまり、タスクに割り当てられる時間）を放棄し、ストーリーポイントであるフィボナッチ数（1、2、3、5）を使用してアジャイル見積もりアプローチを使用することをお勧めします。、8、13、21…）アイテムの実装に必要な作業を評価するためのフォーム。

見積もりの時点で、チームは最初に、見積もりの参照としてユーザーストーリー形式である可能性のあるバックログアイテムを特定する必要があります。さらに、評価のシングルストーリーポイントが21より大きい場合、ユーザーストーリーを再度分割する必要があり、シングルユーザーストーリーポイントが8以下であることが理想的な状態であることに注意することが重要です。

6.スプリント計画会議

これは最初の実際のスクラムミーティングです。チーム、スクラムマスター、およびPOが協力して、スプリントの内容を計画します。ソフトウェア開発プロジェクトとして、計画スプリントのユーザーストーリーを入力すると、ユーザーストーリーが分割され、ビジュアルデザインが完成するはずです。

スプリントサイクルは一般的に固定されており、ほとんどの場合2〜4週間です。チームは、製品のやることリストで最も優先度の高いユーザーストーリーから始めて、スプリントでどれだけのことができるかを確認します。

チームがすでに複数のスプリントを実行している場合は、以下を参照してください。

前の反復で完了した「ストーリーポイント」、
チームは、この反復のおおよそのストーリーポイントを見積もることができます。
「ストーリーポイント」はチームのスピードに相当します。

スクラムマスターとチームは、スプリントの反復ごとにこの数を増やすように努力する必要があります。

すべてのチームメンバーは、スプリントの目標、つまり、スプリントの反復で達成する必要があることについてコンセンサスを形成する必要があります。スプリント計画会議で、POはチームにユーザーストーリーの実装の優先順位を伝える必要があります。チームは、次のスプリントの反復で完了することができるストーリーの数を約束します。スプリントの過程で、誰も許可なくスプリントの内容を一方的に変更することはできません。

7.毎日のスタンドアップミーティング

毎日のスタンドアップは、スクラムの活力の源です。参加者には通常、PO、スクラムマスター、およびチームが含まれます。チームは、毎日決まった場所と決まった時間に社内で連絡を取り合っています。時間は通常朝で、所要時間は15分以内で、立っています 。 スクラムマスターは、チームメンバーに次の質問をします。

昨日は何をしましたか？
今日はどんな仕事をする予定ですか？
障害と障害は何ですか？

これの重要性は、このスプリントサイクル中の各タスクの進捗状況と、すべてのタスクを時間どおりに完了できるかどうかをチーム全体に明確に知らせることです。

チームのタスクは上から下に割り当てられるのではなく、独自のイニシアチブと自発的に決定されます。前のタスクが完了していない場合、次のタスクに申し込むことはできません。また、同じ日に完了できない2つのタスクを請求することもできません。

スクラムマスターは、チームメンバーが直面する障害を取り除く責任があります。

8.スクラムタスクボードを使用してプロジェクトの進捗状況を追跡する

スクラムでは、作業は透過的である必要があり、最も一般的な方法はスクラムタスクボードを実装することです。

一部のチームは、ビジュアルパラダイムやJiraなどのサードパーティツールを使用して電子スクラムボードを使用するのが得意です。一部のチームは、大規模なオフラインの物理ホワイトボードを喜んで使用しています。

電子スクラムボードを使用するか物理ホワイトボードを使用するかに関係なく、かんばんの列には通常、やることリスト、進行中のアイテム、および完成したアイテムの3つの部分が含まれます。イテレーションの進行に伴い、チームは毎日、対応するスクラムかんばんの列に問題を迅速に更新します。

9.燃え尽き症候群チャートで進捗状況を追跡する

作業を透明にするためのもう1つのツールは、バーンアウトチャートです。次の図では、1つの軸がワークロードを表し、もう1つの軸が時間を表します。スクラムマスターは毎日、完了すべき残りのポイントを記録し、バーンアウトチャートに描画します。理想的には、グラフは下向きの曲線であり、残りの作業が完了するとゼロまで燃え尽きます。

10.製品のデモンストレーション

スクラムガイドのデモンストレーションセクションはスプリントレビューミーティングと呼ばれ、開発チームが製品の増分に関する質問に答えるために行った作業のデモンストレーションを含める必要があると述べています。会議は通常、このイテレーションのリリース前に開催されます。この会議の最も重要な作業は、完了した定義を満たすために、完了した各項目で評価を受け入れて、ユーザーストーリーの実装シナリオを検証することです。

この会議では、PO、スクラムマスター、チームだけでなく、利害関係者、ビジネス、マネージャー、さらには顧客まで、誰でも参加できます。

これは、PO、スクラムマスター、チームだけでなく、利害関係者、ビジネス、マネージャー、さらには顧客まで、誰でも参加できるオープンミーティングです。

チームは、完了の定義を満たすアイテム、つまり、これ以上作業を行わなくても提供できる結果のみを表示する必要があります。この結果は完全な製品ではない可能性がありますが、少なくともエンドユーザーにとっては完全で使用可能な機能です。

11.スプリントレトロスペクティブ

スプリント回顧会議は通常、このスプリントの終了後2日目に開催されます。

スプリント回顧会議では、次の質問を注意深く確認する必要があります。

何が改善されたのか。
なぜそれが起こったのですか？
なぜ当時それを無視したのですか。
どうすれば作業をスピードアップできますか。

チームとして、このスプリントの遡及的プロセスを効果的にするには、チームはお互いを信頼する必要があります。プロジェクトと技術的な問題に基づいた議論と議論を覚えておく必要があります。

絶対的な善悪、心配はありません、
技術的な衝突を助長します。
個人攻撃に関する議論を含めることはできません。
色付きの眼鏡をかけて人に会うのに抵抗し、
全員を合理的な議論に導きます。
他人の挑戦を勇気を持って受け入れ、
自分の欠点を受け入れます。
独自のプロセスと結果に責任を持ち、
ブレーンストーミングを行い、問題の解決策を探します。これは非常に重要です。

最後に、チームは最も価値のある改善の1つを特定し、それを次のスプリントの最優先事項として設定します。次のスプリントレビュー会議で改善が行われたかどうかをすばやく判断できるように、具体的かつ実用的な方法で「成功」したものを定義する必要があります。

最後のスプリントが終了したら、新しいスプリントの反復を開始します。

概要

スクラムは3355の組み合わせです。スクラムフレームワークのコアコンセプトは、次のように3.3.5.5として簡単に記憶できます。

3つの役割

3つの遺物

製品バックログ
スプリントバックログ —スプリントのやることリスト
製品の増分—潜在的な出荷可能な製品の増分

5つのイベント

5つの値

開ける
尊敬
勇気
集中
献身

3355の目標は、3つのスクラムピラーの背後にあります

透明
検査
適応

「完了」（DoD）の定義は、スクラムチームの5つのイベントを通じて3つの柱を実現することによって実現されます。

いくつかの中国語翻訳スクラム記事と参考文献