Articles

The2020Scrum GuideTM

by admin 12月 3, 2021

スクラムガイドのこのHTMLバージョンは、PDFhereとして利用可能なNovember2020バージョンの直接ポートです。

スクラムガイドの目的

私たちは1990年代初頭にスクラムを開発し、2010年に世界の人々がスクラムを理解するのを助けるためにスクラムガイドの最初のバージョンを書いた。私たちは、小さな、機能的な更新を通じて、それ以来、ガイドをevolvedました。一緒に、私たちはそれの後ろに立っています。

スクラムガイドにはスクラムの定義が含まれています。 Theframeworkの各要素は、スクラムで実現されるoverallvalueと結果に不可欠な特定の目的を果たします。スクラムのコア設計やアイデアを変更したり、要素を除外したり、スクラムのルールに従わなかったりすると、問題をカバーし、スクラムの利点を制限し、潜在的に役に立たなくなる可能性があります。

私たちは、成長を続ける複雑な世界の中でスクラムの使用の増加に従います。私たちは、スクラムがそのルーツを持つソフトウェア製品開発を超えて、非常に複雑な作業を保持する多くの分野でスクラムが採用されているのを見て謙虚になっています。スクラムの使用が広がるにつれて、開発者、研究者、アナリスト、科学者、およびその他の専門家が作業を行います。私たちは、スクラムで”開発者”という言葉を除外するのではなく、単純化するために使用します。 Scrumからvaluefromを取得する場合は、自分自身を含めることを検討してください。

スクラムが使用されているように、このドキュメントで説明されているように、スクラムのフレームワークに合ったパターン、プロセス、および洞察が見それらの説明は、文脈依存であり、スクラムの使用間で大きく異なるため、スクラムガイドの目的を超えています。スクラムフレームワーク内で使用するためのこのような戦術は広く異なり、他の場所で説明されています。

スクラム定義

スクラムは、複雑な問題の適応ソリューションを通じて、人々、チーム、組織が価値を生み出すのを助ける軽量フレームワークです。

一言で言えば、スクラムは環境を育成するためにスクラムマスターを必要とします。

製品所有者は、複雑な問題の作業をProductBacklogに注文します。
スクラムチームは、スプリント中に作業の選択を増分ofvalueに変換します。
スクラムチームとその利害関係者は結果を検査し、次のスプリントに合わせて調整します。
繰り返し

スクラムは簡単です。そのままそれを試してみて、その哲学、理論、および構造が目標を達成し、価値を創造するのに役立つかどうかを判断します。 Scrumframeworkは意図的に不完全であり、スクラム理論を実装するために必要な部分を定義するだけです。スクラムは、それを使用する人々のcollectiveintelligenceによって構築されています。人々に詳細な指示を与えるのではなく、スクラムのルールは彼らの関係と相互作用を導きます。

さまざまなプロセス、技術および方法はtheframeworkの内で用いることができます。スクラムは、既存のプラクティスをラップしたり、不要なものをレンダーしたりします。スクラムは、改善を行うことができるように、現在の管理、環境、および作業技術の相対的な有効性を目に見えるようにします。

スクラム理論

スクラムは経験主義とリーン思考に基づいています。経験主義assertsthatの知識は経験から来、観察されるwhatisに基づいて決定をする。無駄のない思考は、無駄を減らし、必需品に焦点を当てています。

スクラムは、予測可能性を最適化し、リスクを制御するための反復的で増分的なアプローチを採用しています。スクラムは、仕事を行うためのすべてのスキルと専門知識を持っており、必要に応じてそのようなスキルを習得している人々のグループに従事しています。

スクラムは、イベント、スプリントをacontaining内の検査と適応のための四つの正式なイベントを兼ね備えています。これらのイベントは、透明性、検査、および適応の経験的スクラムの柱を実装するために機能します。

透明性

創発的なプロセスと作業は、作業を行う人だけでなく、作業を受ける人にも見える必要があります。スクラムでは、importantdecisionsは、その三つのformalartifactsの知覚された状態に基づいています。透明性の低い成果物は、価値を減少させ、リスクを増加させる意思決定につながる可能性があります。

透明性は、検査を可能にします。透明性のない検査は無駄で無駄です。

検査

潜在的に望ましくない変動や問題を検出するために、スクラム成果物と合意された目標に向けた進捗状況を頻繁かつ熱心に検査検査を支援するために、スクラムはケイデンスを提供しますその五つのイベントの形で。

検査は適応を可能にします。適応のない検査は無意味であると考えられています。スクラムイベントは、変化を誘発するように設計されています。

適応

プロセスのいずれかの側面が許容範囲外に逸脱した場合、または生成物が許容できない場合は、適用されるプロセスまたは生成される材料を調整する必要があります。調整を行う必要がありますさらなる偏差を最小限に抑えるために、できるだけ早く。

関係者が権限を与えられていないか、自己管理されていない場合、適応はより困難になります。スクラムチームは、検査を通じて新しいことを学ぶ瞬間を適応させることが期待されています。

スクラム値

スクラムの使用を成功させるには、人々が五つの値を生きることに熟練しているかどうかに依存します:

コミットメント、フォーカス、開放性、尊敬、勇気

スクラムチームは、目標を達成し、お互いをサポートすることにコミットします。彼らの主な焦点は、これらの目標に向かって最善の進歩を遂げるためのスプリントの仕事にあります。スクラムチームとそのステークホルダーは、仕事と課題について開いています。スクラムのチームメイトは、お互いが能力があり、独立した人々であることを尊重し、彼らが働く人々によってそのように評価されています。スクラムのチームメイトは、厳しい問題に取り組むために、正しいことをする勇気を持っています。

これらの値は、自分の仕事、行動、行動に関してスクラムチームに方向性を与えます。行われた決定、取られたステップ、およびスクラムの使用方法は、これらの値を強化し、それらを減少させたり、undermineしたりするべきではありません。スクラムチームのメンバーは、スクラムのイベントや成果物を扱うために、価値を学び、探求します。これらの価値観がスクラムチームと一緒に働く人々によって具現化されると、透明性、検査、適応の経験的なスクラムの柱が生命構築の信頼になります。

スクラムチーム

スクラムの基本的な単位は、人々の小さなチーム、スクラムチームです。スクラムチームは、スクラムマスター、プロダクトオーナー、開発者で構成されています。スクラムチーム内には、サブチームまたはサブチームはありません。hierarchies.It atimeで一つの目的、製品の目標に焦点を当てた専門家の凝集単位です。

スクラムチームは機能横断的であり、メンバーは各スプリントの価値を創造するために必要なすべてのスキルを持っていることを意味します。彼らはまた、自己管理であり、誰が何を、いつ、どのようにするかを内部的に決定することを意味します。

スクラムチームは、スプリント内で重要な作業を完了するのに十分な大きさ、通常は10以下の軽快なままにするのに十分な大きさですpeople.In 一般的に、私たちは小さなチームがより良い通信し、より生産的であることを発見しました。スクラムチームが大きすぎる場合は、それぞれが同じ製品に焦点を当てた複数の凝集スクラムチームに編成することを検討する必要があります。したがって、同じ製品目標、製品バックログ、および製品所有者を共有する必要があります。

スクラムチームは、stakeholderのコラボレーション、検証、保守、運用、実験、研究開発、および必要とされるその他のすべての製品関連の活動を担当しています。彼らは組織によって構造化され、権限を与えられています自分の仕事を管理する。持続可能なペースでスプリントで作業することで、スクラムチームの焦点と一貫性が向上します。

スクラムチーム全体が、スプリントごとに貴重で有用なインクリメントを作成する責任があります。スクラムは、スクラムチーム内の三つの特定のaccountabilitieswithを定義します: 開発者、製品所有者、およびスクラムマスター。

開発者

開発者は、各スプリントで使用可能なインクリメントの任意の側面を作成することを約束しているスクラムチームの人々です。

開発者が必要とする特定のスキルは、多くの場合、広く、仕事のドメインとwillvaryです。しかし、開発者は常に次のために責任があります：

スプリントの計画、スプリントバックログを作成する;
Doneの定義を遵守して品質を浸透させる;
スプリントの目標に向かって毎日計画を適応させる; そして、
お互いに専門家として責任を持っています。

プロダクトオーナー

プロダクトオーナーは、スクラムチームの作業からproductresultingの価値を最大化する責任があります。これがどのように行われるかは、組織、スクラムチーム、および個人によって異なる場合があります。

プロダクトオーナーは、効果的なプロダクトバックログ管理についても責任を負います。

プロダクト目標を開発し、明示的に伝える。
プロダクトバックログ項目を作成し、明確に伝える。;
プロダクトバックログ項目を注文し、
プロダクトバックログが透明で表示され、理解されていることを確認します。

製品所有者は、上記の作業を行うことができ、または他の人に責任を委任することができます。それにもかかわらず、製品の所有者は依然として責任があります。

製品所有者が成功するためには、組織全体が彼らの決定を尊重しなければなりません。これらの決定は、プロダクトバックログの内容と順序、およびプリントレビューでの検査可能な増分によって表示されます。

製品の所有者は一人であり、委員会ではありません。製品所有者は、製品バックログの多くの利害関係者のニーズを表す可能性があります。プロダクトバックログを変更することを望んでいる人は、製品所有者を説得しようとすることによってそうすることができます。

スクラムマスター

スクラムマスターは、スクラムガイドで定義されているようにスクラムを確立する責任があります。彼らは、スクラムチームと組織の両方の中で、誰もがスクラム理論と実践を理解するのを助けることによってこれを行います。

スクラムマスターは、スクラムチームの有効性について責任があります。彼らは、スクラムチームがtheScrumフレームワーク内でそのプラクティスを改善できるようにすることでこれを行います。

スクラムマスターは、スクラムチームとlargerorganizationに奉仕する真のリーダーです。

スクラムマスターは、次のようないくつかの方法でスクラムチームにサービスを提供します。

自己管理とクロス機能におけるチームメンバーのコーチング
スクラムチームが完了の定義を満たす価値の高い増分を作成することに焦点を当てるのを助ける。
スクラムチームの進捗に障害を取り除くこと。
スクラムチームの進捗に障害を取り除くこと。
すべてのスクラムイベントが行われ、肯定的で生産的で、タイムボックス内に保持されることを保証します。

スクラムマスターは、次のようないくつかの方法で製品所有者にサービスを提供します。

効果的な製品目標定義と製品バックログ管理のたli>
要求または必要に応じて利害関係者のコラボレーションを促進します。

スクラムマスターは、次のようないくつかの方法で組織にサービスを提供します:

Scrumadoptionにおける組織のリード、トレーニング、コーチング、
組織内のスクラム実装の計画とアドバイス、
従業員と利害関係者が複雑な作業のための経験的アプローチを理解し、制定するのを助けること、
ステークホルダーとスクラムチームの間の障壁を取り除くこと。

スクラムイベント

スプリントは、他のすべてのイベントのコンテナです。スクラム内の各イベントは、スクラム成果物を検査して適応させるための形式的な機会です。これらのeventsareはとりわけ必要な透明物を可能にするように設計した。 Failuretoは失われた機会のtoinspectおよび合わせることの規定された結果としてでき事を作動させます。イベントは、規則性を作成し、スクラムで定義されていない会議の必要性を最小限に抑えるためにスクラムで使用されます。

最適には、すべてのイベントが同時に開催され、複雑さ。

スプリント

スプリントはスクラムのハートビートであり、アイデアは価値に変わります。

これらは、一貫性を作成するために一ヶ月以下の固定長のイベントです。新しいスプリントは、前のスプリントの終了直後に開始されます。

SprintPlanning、Daily Scrums、Sprint Review、Sprint Retrospectiveなど、製品の目標を達成するために必要なすべての作業は、スプリント内で起こります。

スプリント中：

スプリントの目標を危険にさらすような変更は行われません。
品質は低下しません。
プロダクトバックログは必要に応じて洗練されます。
スコープを明確にし、製品所有者と再交渉することができます。

スプリントは、少なくとも暦月ごとに製品目標に向かって進捗の検査と適応を確実にすることにより、予測可能性を可能にします。 ASprintの地平線が長すぎると、スプリント目標が無効になり、複雑さが増し、リスクが増加する可能性があります。より短いスプリントはより多くの学習周期を発生させ、より小さい時間枠に費用のandeffortの危険を限るためにbeemployedできる。各スプリントはshortprojectと見なされることがあります。

バーンダウン、バーンアップ、累積フローなど、進捗を予測するためのさまざまなプラクティスが存在します。有用であることが証明されているが、これらは経験主義の重要性。複雑な環境では、何が起こるかは知られていない。すでに起こったことだけが、将来の見通しのために使用される可能性があります決断の作成。

スプリントの目標が廃止された場合、スプリントはキャンセルされる可能性があります。製品所有者のみがスプリントをキャンセルする権限を持っています。

Sprint Planning

Sprint Planningは、スプリントのために実行される作業をレイアウトすることによってスプリントを開始します。この結果として得られる計画は、スクラムチーム全体の協力的な作業によって作成されます。

製品所有者は、出席者が最も重要な製品バックログ項目とProductGoalへのマッピング方法について議論する準備ができていることを保証します。スクラムチームはまた、アドバイスを提供するためにSprintPlanningに出席するために他の人を招待することができます。

スプリント計画は、次のトピックに対処します。

トピックOne:このスプリントはなぜ価値があるのですか？

製品所有者は、製品が現在のスプリントでその価値をどのように高めることができるかを提案しています。その後、スクラムチーム全体がスプリントの目標を定義し、スプリントがなぜ価値があるのかを伝えることができます。スプリントの目標は、印刷計画の終了前に確定する必要があります。

トピック二：何がこのスプリントを行うことができますか？

プロダクト所有者との議論を通じて、開発者はプロダクトバックログからアイテムを選択して、現在のスプリントに含めることができます。 ScrumTeamは、このプロセス中にこれらの項目を洗練することができ、理解と自信を高めます。

スプリント内でどれだけ完了できるかを選択するのは難しいかもしれません。しかし、開発者が過去のパフォーマンス、今後の能力、およびDoneの定義について知るほど、スプリント予測に自信があります。

トピック3：選択された作業はどのように行われますか？

選択したプロダクトバックログ項目ごとに、開発者はDoneの定義を満たす増分を作成するために必要な作業を計画します。これは、多くの場合、プロダクトバックログ項目を一日以下の小さなworkitemsに分解することによって行われます。これがどのように行われるかは、開発者。製品バックログitemsinto値の増分を有効にする方法を誰も彼らに指示しません。

スプリントの目標、スプリントのために選択されたプロダクトバックログ項目、およびそれらを提供するための計画は、一緒にSprintBacklogと呼ばれます。

スプリント計画は、一ヶ月のプリントのための最大八時間にタイムボックスされます。短いスプリントの場合、イベントは通常短くなります。

Daily Scrum

Daily Scrumの目的は、SprintGoalへの進捗状況を検査し、必要に応じてSprint Backlogを適応させ、今後の計画された作業を調整することです。

毎日のスクラムは、ScrumTeamの開発者のための15分のイベントです。複雑さを軽減するために、それは同じ時間に開催され、毎日スプリントの作業日。プロダクト所有者またはスクラムマスターがSprint Backlogの項目に積極的に取り組んでいる場合、彼らは開発者として参加します。

開発者は、毎日のスクラムがスプリントの目標に向かって進歩に焦点を当て、翌日の作業のための実用的な計画を作成する限り、必要な構造とテクこれは、焦点を当て、自己管理を改善する。

毎日のスクラムは、コミュニケーションを改善し、障害を特定し、迅速な決定を促進し、その結果、他の会議の必要性を排除します。

毎日のスクラムは、開発者が彼らの計画を調整することが許可されている唯一の時間ではありません。彼らはしばしば、スプリントの残りの作業を適応または再計画することについてのより詳細な議論のために一日を通して会う。

Sprint Review

Sprint Reviewの目的は、Sprintの結果を検査し、将来の適応を決定することです。スクラムチームは、その作業の結果を主要な利害関係者に提示し、製品目標に向けた進捗状況を議論します。

イベント中、スクラムチームと利害関係者は、スプリントで何が完了したのか、環境で何が変更されたのかを確認します。この情報に基づいて、出席者は次に何をすべきかについて協力します。製品のバックログは、新しい機会を満たすために調整することもできます。スクラムチームはそれをプレゼンテーションに限定することを避けるべきです。

スプリントレビューは、スプリントの最後から二番目のイベントであり、一ヶ月のスプリントのための最大四時間にistimeboxed。 ShorterSprintsの場合、イベントは通常短くなります。

Sprint Retrospective

Sprint Retrospectiveの目的は、品質と有効性を高める方法を計画することです。

スクラムチームは、個人、インタラクション、プロセス、ツール、およびそれらの定義に関して、ラストスプリントがどのように行ったかを検査します。検査された要素は、多くの場合、作業の領域によって異なります。彼らを道に迷わせたという仮説が特定され、その起源が探求されています。 Thescrumチームは、スプリント中に何がうまくいったのか、どのような問題が発生したのか、それらの問題がどのように解決されたのか（または解決されなかったのか）について議論します。

スクラムチームは、itseffectivenessを改善するために最も有用な変更を特定します。最も影響力のある改善は、できるだけ早く対処されます可能です。これらは、nextSprintのスプリントバックログに追加することもできます。

スプリント回顧はスプリントを終了します。これは、一ヶ月のスプリントのための三時間の最大にタイムボックスされています。短いスプリントの場合、イベントは通常短くなります。

スクラム成果物

スクラムの成果物は、仕事または価値を表します。彼らは最大化するように設計されています重要な情報の透明性。したがって、それらを検査する誰もが適応のための同じ基礎。

各成果物には、情報を提供することを保証するコミットメントが含まれています。

プロダクトバックログの場合、それは製品目標です。
スプリントバックログの場合は、スプリントの目標です。
インクリメントについては、Doneの定義です。

これらのコミットメントは、スクラムチームとその利害関係者の経験主義とスクラムの価値を強化するために存在します。

プロダクトバックログ

プロダクトバックログは、製品を改善するために必要なものの緊急の順序付けられたリストです。それはtheScrumのチームによって引き受けられる仕事の単一の源である。

Onesprint内のスクラムチームが行うことができるプロダクトバックログ項目は、スプリント計画イベントで選択する準備ができているとみなされます。彼らは通常、活動を精製した後、この程度の透明性を獲得する。プロダクトバックログの絞り込みは、プロダクトバックログ項目をより正確な項目に分解し、さらに定義する行為です。これは、説明、注文、サイズなどの詳細を追加するための進行中のアクティビティです。属性は、多くの場合、作業のドメインによって異なります。

作業を行う開発者は、サイジングを担当します。製品所有者は、開発者がトレードオフを理解し、選択するのを助けることによって、開発者に影響を与える可能性があります。

Commitment:Product Goal

Product Goalは、スクラムチームが計画するターゲットとして役立つ製品の将来の状態を記述します。製品の目標は、プロダクトバックログです。製品バックログの残りの部分は、製品の目標を達成する”何”を定義するために現れます。

製品は、値を提供するための車両です。それは明確な境界、既知の利害関係者、明確に定義されたユーザーまたは顧客を持っています。製品は、サービス、物理的な製品、またはより抽象的な何かかもしれません。

製品の目標は、スクラムチームの長期的な目標です。次の目標を取る前に、一つの目標を達成（または放棄）しなければなりません。

Sprint Backlog

Sprint Backlogは、Sprint Goal(why)、Sprint用に選択された製品バックログ項目のセット(what)、および増分を配信するためのアクション可能な計画(how)で構成されます。

スプリントバックログは、開発者による計画であり、開発者のための計画です。これは、開発者がスプリントの目標を達成するためにスプリント中に完了することを計画している作業の可視性の高いリアルタイムの画像です。その結果、スプリントバックログは、より多くの学習が行われるにつれて、スプリント全体で更新されます。それは彼らが検査できる十分な詳細を持っている必要があります毎日のスクラムでの彼らの進歩。

コミットメント:スプリントゴール

スプリントゴールは、スプリントの単一の目標です。 TheSprintの目標は開発者によるコミットメントですが、それを達成するために必要な正確な作業の面で柔軟性を提供します。スプリントの目標はまた、一貫性と焦点を作成し、スクラムチームが別々のイニシアチブよりも一緒に働くことを奨励します。

スプリント目標は、スプリント計画イベント中に作成され、スプリントバックログに追加されます。開発者はスプリント中に作業するため、スプリントの目標を念頭に置いています。作業が予想とは異なることが判明した場合、彼らは製品所有者と協力して、スプリントの目標に影響を与えることなく、スプリント内のスプリントバックログの範囲を交渉します。

インクリメント

インクリメントは、製品の目標に向かって具体的な足がかりです。 EachIncrementはすべての前の増分に付加的、完全に確認され、すべての増分が一緒に働くことを保障する。値を提供するには、増分が使用可能である必要があります。

スプリント内で複数の増分を作成することができます。このように経験主義を支持するスプリントレビューでは、増加の合計が提示されています。ただし、インクリメントはスプリントの終了前に利害関係者に配信される場合があります。スプリントレビューは、決してゲート-トレイジング-バリューと見なされるべきではありません。

作業は、Doneの定義を満たさない限り、増分の一部とみなすことはできません。

コミットメント：完了の定義

完了の定義は、製品に必要な品質対策を満たしているときのincrementの状態の正式な説明です。

プロダクトバックログアイテムがDoneの定義を満たした瞬間、anIncrementが生まれます。

Doneの定義は、incrementの一部としてどのような作業が完了したかを誰もが理解できるようにすることによって、透明性を作成します。プロダクトバックログアイテムがdoneの定義を満たしていない場合は、Sprint Reviewでリリースまたは提示することはできません。代わりに、将来の検討のためにプロダクトバックログに戻ります。

インクリメントのDoneの定義が組織の標準の一部である場合、すべてのスクラムチームは最低限それに従わなければなりません。それが組織の標準ではない場合、スクラムチームは製品に適した定義を作成する必要があります。

開発者はDoneの定義に準拠する必要があります。複数のスクラムチームが製品で一緒に作業している場合は、同じDoneの定義をmutually定義し、遵守する必要があります。

エンドノート

スクラムは無料で、このガイドで提供されています。ここで説明したスクラムフレームワークは不変です。スクラムの一部のみを実装することは可能ですが、結果はスクラムではありません。スクラムは、その全体と機能だけでなく、他の技術、方法論、および実践のためのコンテナとして存在します。

謝辞

人々

スクラムに貢献してきた何千人もの人々のうち、私たちは最初に尽力した人たちを単一にする必要があります：Jeff SutherlandはJeff McKennaとJohn Scumniotalesと協力し、Ken SchwaberはMike SmithとChris Martinと協力し、それらのすべてが一緒に働いていました。多くの人がその後の年に貢献し、彼らの助けを借りずにスクラム今日のように洗練されることはできませんでした。

スクラムガイドの歴史

Ken SchwaberとJeff Sutherlandは、1995年にOOPSLAConferenceでスクラムを初めて共同発表しました。それは本質的にKen andJeffが過去数年間に得た学習を文書化し、スクラムの最初の形式的定義を公開しました。

スクラムガイドは、Jeff SutherlandとKen Schwaberによって30年以上にわたって開発され、進化し、維持されているスクラムを文書化しています。他のソースは、Scrumフレームワークを補完するパターン、プロセス、および洞察を提供します。これらは結果生産性、価値、創造性およびsatisfactionwithを高めるかもしれません。

スクラムの完全な歴史は他の場所で説明されています。それが試みられ、証明された最初の場所を称えるために、私達は個々の株式会社を確認します。、Newspage、フィデリティ-インベストメンツ、IDX（現GEメディカル）。©2020Ken Schwaber and Jeff Sutherlandこの出版物は、Creative CommonsのAttributionShare-Alike license、accessible athttps://creativecommons.org/licenses/by-sa/4.0/legalcodeの下でのライセンスのために提供されており、要約形式athttps://creativecommons.org/licenses/by-sa/4.0/でも説明されています。このScrumGuideを利用することにより、あなたはCreativeCommonsの帰属共有同様のライセンスの条件を読み、同意したことを認め、同意するものとします。

be settled