Loading article…
Scrum は、ソフトウェア開発やその他の業界 で一般的に使用されているアジャイルチーム コラボレーション フレームワークです。
スクラムでは、チームが作業をスプリントと呼ばれる時間制限のある反復内で完了する目標に分割することを規定しています。各スプリントは1か月以内で、通常は2週間続きます。スクラムチームは、デイリースクラムと呼ばれる最大15分間の時間制限のあるスタンドアップミーティングで進捗状況を評価します。スプリントの終了時に、チームはさらに2つのミーティングを開催します。1つは関係者に作業を説明してフィードバックを求めるスプリントレビューで、もう1つは内部スプリントの振り返りです。スクラムチームの責任者は通常、スクラムマスターと呼ばれます。[2]
スクラムの製品開発へのアプローチは、意思決定権限を運用レベルにまで引き上げることです。[3]製品開発へのシーケンシャルなアプローチとは異なり、スクラムは反復的かつ増分的な製品開発フレームワークです。[4]スクラムは継続的なフィードバックと柔軟性を可能にし、物理的な共同作業やオンラインでの密接なコラボレーションを奨励し、チームメンバー全員の間で頻繁なコミュニケーションを義務付けることで、チームの自己組織化を要求します。スクラムの柔軟なアプローチは、プロジェクトの進化に伴って利害関係者が要件を変更するという要件変動性の概念に一部基づいています。[5]
歴史
ソフトウェア開発におけるスクラムという用語の使用は、1986 年のハーバード ビジネス レビューの論文「新製品開発ゲーム」で竹内弘高氏と野中郁次郎氏が発表した論文に由来しています。著者らは、自動車、コピー機、プリンター業界の製造企業のケース スタディに基づいて、スピードと柔軟性を向上させるための新しい製品開発アプローチを概説しました。著者らはこれをラグビーアプローチと呼びました。これは、このプロセスでは、複数の重複するフェーズにわたって単一の部門横断的なチームが活動し、チームが「ボールを前後にパスしながら、ユニットとして最後までやり遂げようとする」ためです。[6]著者らは後に、著書「知識創造企業」でスクラムを発展させました。[7]
1990 年代初頭、ケン・シュワバーは彼の会社である Advanced Development Methods で、後にスクラムとなる手法を採用しました。ジェフ・サザーランド、ジョン・スカムニオタレス、ジェフ・マッケナはイーゼル・コーポレーションで同様のアプローチを開発し、その手法をスクラムと呼んでいました。[8]サザーランドとシュワバーは後に協力して、自分たちのアイデアを 1 つのフレームワークに統合し、正式にはスクラムと呼ばれました。シュワバーとサザーランドはスクラムをテストし、継続的に改良した結果、1995 年に研究論文[9]と2001 年にアジャイル ソフトウェア開発宣言[10]を発表しました。シュワバーはまた、デュポン研究所とデラウェア大学のババトゥンデ・オグンナイケと協力してスクラムを開発しました。オグンナイケは、製品管理が経験的な実践に根ざしていないと、初期条件が変わったときにソフトウェア開発プロジェクトが失敗することが多いと考えていました。[3]
2002年、シュワバーは他のメンバーとともにスクラムアライアンスを設立し、認定スクラム認定シリーズを立ち上げました。 [11]シュワバーは2009年後半にスクラムアライアンスを離れ、その後、並行してプロフェッショナルスクラム認定シリーズを監督するScrum.orgを設立しました。 [12] 2009年以来、シュワバーとサザーランドによって「スクラムガイド」[13]と呼ばれる公開文書が発行および更新されてきました。このガイドは6回改訂されており、最新バージョンは2020年11月に発行されています。
スクラムチーム
スクラムチームは、少なくともプロダクトオーナー、開発者、スクラムマスターの3つのカテゴリーに分かれています。プロダクトオーナーは、プロジェクトの結果に関心を持つステークホルダーと連携し、開発者にタスクと期待を伝えます。[14]スクラムチームの開発者は、スクラムマスターの支援を受けて、自分たちで作業を整理します。[15]
プロダクトオーナー
各スクラムチームには1人のプロダクトオーナーがいます。[16]プロダクトオーナーは製品開発のビジネス面に焦点を当て、ほとんどの時間を利害関係者やチームとの連絡に費やします。その役割は主に製品の利害関係者、顧客の声、または委員会の要望を代表することを目的としており、ビジネス成果の提供に責任を負います。[17] [18] [19] [20]プロダクトオーナーは製品バックログを管理し、チームが提供する価値を最大化する責任があります。[18]チームの技術的ソリューションを指示することはありませんが、代わりにチームメンバー間の合意形成を図ろうとする場合があります。[21] [22]
スクラムチームとステークホルダーの主な連絡役として、プロダクトオーナーはアナウンス、プロジェクトの定義と進捗、RIDA（リスク、障害、依存関係、前提条件）、資金調達とスケジュールの変更、製品バックログ、プロジェクトガバナンスなどの責任を負います。[23] [より良い情報源が必要]プロダクトオーナーは必要に応じてチームメンバーの意見を聞かずにスプリントをキャンセルすることもできます。[13]
開発者
スクラムでは、開発者またはチームメンバーという用語は、製品の開発とサポートに役割を果たす人を指し、研究者、建築家、デザイナー、プログラマーなどが含まれます。 [13] [24]
スクラムマスター
スクラムはスクラムマスターによって促進され、その役割はスクラムの理論と実践についてチームを教育し、指導することです。[1]スクラムマスターは、従来のチームリーダーやプロジェクトマネージャーとは異なる役割と責任を持ちます。スクラムマスターの責任には、コーチング、目標設定、問題解決、監督、計画、バックログ管理、コミュニケーション促進などがあります。[1]一方、従来のプロジェクトマネージャーは人材管理の責任を負っていることがよくありますが、スクラムマスターはそうではありません。スクラムチームにはプロジェクトマネージャーが関与せず、開発者間の自己組織化を最大化します。[25]
ワークフロー
スプリント
スプリント（デザインスプリント、イテレーション、タイムボックスとも呼ばれる）は、チームメンバーが特定の目標に取り組む固定期間です。各スプリントは通常1週間から1か月ですが、2週間が最も一般的です。[3]スプリントの結果は機能的な成果物、つまり段階的に開発が進められた製品です。スプリントが異常終了した場合、次のステップは新しいスプリントの計画を実行することです。そこでは終了の理由が確認されます。
各スプリントはスプリント計画イベントから始まり、スプリントの目標が定義されます。計画されたスプリントの優先順位はバックログから選択されます。各スプリントは2つのイベントで終了します。[8]
- スプリントレビュー（関係者に進捗状況を示し、フィードバックを得る）
- スプリントの振り返り（次のスプリントに向けた教訓と改善点の特定）
スプリント計画の推奨最大期間は、4週間のスプリントの場合8時間です。[13]
デイリースクラム
スプリント中の毎日、開発者は特定のガイドラインに沿ってデイリースクラム（多くの場合は立ちながら実施）を開催し、スクラムマスターが進行役を務めることもあります。[3] [26]デイリースクラムミーティングは15分未満で、毎日同じ時間と場所で開催されます。ミーティングの目的は、スプリントの目標に向けた進捗状況と、目標達成の妨げとなっている可能性のある問題を発表することであり、詳細な議論には立ち入りません。ミーティングが終わると、個々のメンバーは「ブレイクアウトセッション」または「アフターパーティー」に参加し、さらに議論やコラボレーションを行うことができます。[27]スクラムマスターは、チームメンバーがデイリースクラムを効果的に使用できるようにし、チームメンバーがデイリースクラムを使用できない場合は、同様の結果を達成するための代替手段を提供する責任があります。[28] [29]
スプリント後のイベント
スプリントレビューはスプリントの最後に実施され、チームが完了した作業を関係者と共有し、フィードバック、期待、今後の計画について連絡を取り合う会議です。スプリントレビューでは、完了した成果物が関係者に示されます。スプリントレビューの推奨期間は、スプリントの週ごとに1時間です。[13]
スプリントの振り返りは、チームメンバーがスプリントの長所と短所、将来の改善領域、継続的なプロセス改善アクションを内部的に分析できる別の会議です。[30]
バックログの改善
バックログの洗練とは、チームメンバーが将来のスプリントのためにバックログを修正し、優先順位を付けるプロセスです。[31]これは、新しいスプリントの開始前に行う独立したステージとして行うことも、チームメンバーが独自に取り組む継続的なプロセスとして行うこともできます。バックログの洗練には、大きなタスクをより小さく明確なタスクに分割すること、成功基準を明確にすること、変化する優先順位とリターンを修正することなどが含まれます。
遺物
成果物はスクラムチームがプロジェクトに向けて行われた作業を文書化することで製品開発を管理する手段です。スクラム成果物は7つあり、そのうち最も一般的なものは製品バックログ、スプリントバックログ、増分です。[32]
製品バックログ
プロダクトバックログは、実行すべき作業の内訳であり、チームが製品に対して維持する製品要件（機能、バグ修正、非機能要件など）の順序付きリストが含まれています。プロダクトバックログの順序は、タスクの緊急性に対応しています。バックログ項目の一般的な形式には、ユーザーストーリーとユースケースがあります。[25]プロダクトバックログには、プロダクトオーナーのビジネス価値の評価と、チームの製品の労力または複雑さの評価も含まれる場合があります。これらは、丸められたフィボナッチスケールを使用してストーリーポイントで表すことができます。これらの見積もりは、プロダクトオーナーがタイムラインを判断するのに役立ち、プロダクトバックログ項目の順序に影響を与える可能性があります。[33]
プロダクトオーナーは、リスク、ビジネス価値、依存関係、サイズ、タイミングなどの考慮事項に基づいて、プロダクトバックログ項目を管理し、優先順位を付けます。バックログの先頭にある優先度の高い項目は、開発者が作業できるように詳細に細分化されますが、バックログの下位にあるタスクはより漠然としている場合があります。[3]
スプリントバックログ
スプリントバックログは、開発者が特定のスプリントで取り組むことを目的とした製品バックログの項目のサブセットです。[34]開発者は、過去のパフォーマンスを使用して各スプリントのキャパシティを評価し、スプリントを埋めるのに適切と思われるタスクでこのバックログを埋めます。スクラムアプローチでは、スプリントバックログのタスクは、特定の個人またはリーダーによって開発者に割り当てられるものではありません。チームメンバーは、バックログの優先度と自分の能力とキャパシティに応じて、必要に応じて作業を引き出すことで自己組織化します。[35]
インクリメント
増分は、スプリントの目標を達成する、リリース可能なスプリントの出力です。これは、完了したすべてのスプリント バックログ項目から形成され、以前のすべてのスプリントの作業と統合されます。
その他の遺物
バーンダウンチャート
スクラムでよく使われるバーンダウンチャートは、残りの作業を示す公開チャートです。[36]参照用に素早く視覚化できます。バーンダウンチャートの横軸は残り日数を示し、縦軸は各日の残りの作業量を示します。スプリントの計画中に、理想的なバーンダウンチャートがプロットされます。その後、スプリント中に、開発者は残りの作業でチャートを更新します。
リリースバーンアップチャート
各スプリントの終了時に更新されるリリース バーンアップ チャートは、予測範囲の達成に向けた進捗状況を示します。リリース バーンアップ チャートの横軸はリリース内のスプリントを示し、縦軸は各スプリントの終了時に完了した作業量を示します。
速度
一部のプロジェクト マネージャーは、チームの 1 回のスプリントでの総能力努力は、最後のスプリントで完了した作業を評価することで得られると考えています。過去の「速度」データの収集は、チームが能力を理解するのに役立つガイドラインです。
制限事項
デイリースクラムやスクラムレビューなどのスクラムイベントは生産性を低下させ、実際の生産的なタスクに費やした方がよい時間を無駄にすると主張する人もいます。[37] [38]また、スクラムは、パートタイムまたは地理的に離れたチーム、個人または作業グループで作業したほうがよい高度に専門化されたメンバーがいるチーム、および増分テストや開発テストに適さないチームにとって困難をもたらすことが観察されています。[39] [40]
適応
スクラムは、さまざまな目的を達成するために、さまざまなコンテキストに合わせて調整または適応されることがよくあります。[41]スクラムを適応させる一般的なアプローチは、スクラムを他のソフトウェア開発方法論と組み合わせることです。スクラムは製品開発ライフサイクル全体をカバーしていないためです。[42]また、さまざまなスクラム実践者が、特定の問題や組織にスクラムを適用または適応させる方法について、より詳細な手法を提案しています。多くの人は、これらの手法を「パターン」と呼んでいます。これは、アーキテクチャとソフトウェアのデザインパターンに類似した用途です。 [43] [44]
スクラムバン
スクラムバンはスクラムとカンバンに基づいたソフトウェア生産モデルです。作業の各段階を説明するために、同じスペースで作業するチームはポストイットや大きなホワイトボードを使用することが多いです。[45]カンバンモデルにより、チームは作業段階と制限を視覚化できます。[46]
スクラム・オブ・スクラム
スクラム・オブ・スクラムは、同じ製品で調整する複数のチームのために、スクラムを大規模に運用する手法です。スクラム・オブ・スクラムの毎日のスクラム会議には、各チームから選ばれたアンバサダーが参加します。アンバサダーは開発者またはスクラムマスターのいずれかです。調整ツールとして、スクラム・オブ・スクラムは、チームがチーム全体のリスク、障害、依存関係、および仮定 (RIDA) に共同で取り組むことを可能にし、それらは独自のバックログで追跡できます。[47] [48]
大規模スクラム
大規模スクラムは、Bas VoddeとCraig Larmanによって開発された、さまざまなルールとガイドラインでスクラムを拡張する製品開発フレームワークです。[49] [50]このフレームワークには2つのレベルがあります。最初のレベルは最大8チーム向けに設計されており、2番目のレベルは「LeSS Huge」と呼ばれ、数百人の開発者が関与する開発に対応できます。[51]
批判
体系的なレビューでは、分散ソフトウェア開発において「分散スクラムはプロジェクト全体の成功にプラスにもマイナスにも影響を与えない」ことが判明した。[52]
アジャイルソフトウェア開発宣言の著者の一人であるマーティン・ファウラーは、いわゆる「偽アジャイル」の実践を批判している。これは「アジャイルの価値と原則を無視している」[53]ものであり、「プロセスやツールよりも個人と相互作用を重視する」 [10]アジャイルの原則に反し、「アジャイル産業複合体が人々に方法を押し付けている」ものであり、作業を行う個人が作業のやり方を決定し、ニーズに合わせてプロセスを変更できるとしている。
2016年9月、アジャイル宣言の署名者であるロン・ジェフリーズ氏[10]は、「ダークスクラム」と名付けた手法について説明し、「スクラムはプログラマーにとって非常に危険な場合がある」と述べた[54] 。
参照
引用
- ^ abc Ken Schwaber ; Jeff Sutherland . 「スクラムガイド」(PDF) . Scrum.org . 2023年6月15日閲覧。
- ^ 「スクラムマスターとは何か？知っておくべきすべてのこと – Forbes Advisor」www.forbes.com 。 2023年11月16日閲覧。
- ^ abcde Schwaber, Ken ( 2004年 2 月 1 日)。アジャイル プロジェクト管理とScrum。Microsoft Press。ISBN 978-0-7356-1993-7。
- ^ 「スクラムとは何か？」。スクラムとは何か？複雑なプロジェクトを完了するためのアジャイルフレームワーク - スクラムアライアンス。スクラムアライアンス。 2016年2月24日閲覧。
- ^ J. Henry および S. Henry。ソフトウェア保守プロセスと要件の変動性の定量的評価。ACM コンピュータサイエンス会議論文集、346 ～ 351 ページ、1993 年。
- ^ 竹内弘高、野中郁次郎 (1986 年 1 月 1 日)。「新しい新製品開発ゲーム」。ハーバード ビジネス レビュー。2010年6 月 9 日閲覧。
スクラムのダウンフィールドへの展開
- ^ 知識創造企業。オックスフォード大学出版局。1995年、p.3。ISBN 978-0-19-976233-0. 2013年3月12日閲覧。
- ^ ab Sutherland, Jeff (2004 年 10 月). 「アジャイル開発: 最初の Scrum から学んだ教訓」。2014年 6 月 30 日時点のオリジナル(PDF)からアーカイブ。2008年9 月 26 日閲覧。
- ^ Sutherland, Jeffrey Victor ; Schwaber, Ken (1995).ビジネスオブジェクトの設計と実装: OOPSLA '95 ワークショップ議事録.ミシガン大学. p. 118. ISBN 978-3-540-76096-2。
- ^ abc 「アジャイルソフトウェア開発宣言」。2019年10月17日閲覧。
- ^ Maximini, Dominik (2015 年 1 月 8 日)。スクラム文化: 組織におけるアジャイル手法の導入。マネジメント フォー プロフェッショナル。Cham: Springer (2015 年発行)。p. 26。ISBN 978-3-319-11827-7. 2016 年8 月 25 日閲覧。
ケン・シュワバーとジェフ・サザーランドは、1995 年にテキサス州オースティンで開催された OOPSLA カンファレンスで初めてスクラムを発表しました。[...] 2001 年には、スクラムに関する最初の本が出版されました。[...] 1 年後 (2002 年)、ケンは世界中でスクラムのトレーニングと認定を提供することを目的とした Scrum Alliance を設立しました。
- ^ “ホーム”. Scrum.org . 2020年1月6日閲覧。
- ^ ジェフ・サザーランド;ケン・シュヴァーバー(2013)。 「スクラムガイド」。 ScrumGuides.org 。2023 年6 月 15 日に取得。
- ^ モリス、デビッド（2017）。スクラム：アジャイルプロジェクトのための理想的なフレームワーク。In Easy Steps。pp. 178–179。ISBN 978-1-84078-731-3. OCLC 951453155.
- ^ Cobb, Charles G. (2015).プロジェクトマネージャーのためのアジャイル習得ガイド: 適応型アプローチの原則と実践. ホーボーケン、ニュージャージー: John Wiley & Sons. p. 37. ISBN 978-1-118-99104-6。
- ^ コーン、マイク(2010)。アジャイルで成功する: スクラムを使用したソフトウェア開発。アッパーサドルリバー、ニュージャージー: アディソンウェスリー。ISBN 978-0-321-57936-2。
- ^ ルビン、ケネス（2013）、エッセンシャルスクラム。最も人気のあるアジャイルプロセスの実践ガイド、アディソンウェズリー、p. 173、ISBN 978-0-13-704329-3
- ^ ab McGreal, Don; Jocham, Ralph (2018 年 6 月 4 日)。プロフェッショナル プロダクト オーナー: スクラムを競争優位性として活用する。Addison-Wesley Professional。ISBN 978-0-13-468665-3。
- ^ Pichler, Roman (2010 年 3 月 11 日)。アジャイル製品管理と Scrum: 顧客に愛される製品の作成。Addison -Wesley Professional。ISBN 978-0-321-68413-4。
- ^ Ambler, Scott. 「プロダクトオーナーの役割: アジャイルチームのステークホルダーの代理人」。agilemodeling.com 。2016年7 月 22 日閲覧。
[...] 実際には、この役割には 2 つの重要な側面があることがわかります。1 つ目は、開発チーム内のステークホルダーの代理人としての役割、2 つ目は、ステークホルダー コミュニティ全体に対するプロジェクト チームの代表者としての役割です。
- ^ 「スクラムガイド」（PDF） . Scrum.org. p. 6 . 2023年6月15日閲覧。
- ^ 「プロダクトオーナーの役割」。Scrum Alliance 。 2018年5月26日閲覧。
- ^ 「プロダクトオーナーの役割」。スクラムマスターテスト準備。 2017年2月3日閲覧。
- ^ ラッド、ネーダー K.;フランク・ターリー（2018）。アジャイル スクラム財団コースウェア、第 2 版。オランダ、スヘルトーヘンボス：ヴァン・ハーレン。 p. 26.ISBN 978-94-018-0279-6。
- ^ ab ピート・ディーマー;ガブリエル・ベネフィールド;クレイグ・ラーマン。 Bas Vodde (2012 年 12 月 17 日)。 「スクラム入門: スクラムの理論と実践への軽量ガイド (バージョン 2.0)」。情報Q.
- ^ 「デイリースクラムとは何か？」Scrum.org 。 2020年1月6日閲覧。
- ^ Flewelling, Paul (2018).アジャイル開発者ハンドブック: ソフトウェア開発からより多くの価値を得る: アジャイル手法を最大限に活用するイギリス、バーミンガム: Packt Publishing Ltd. p. 91. ISBN 978-1-78728-020-5。
- ^ McKenna, Dave (2016). The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility . Aliquippa, PA: CA Press. p. 126. ISBN 978-1-4842-2276-8。
- ^ Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Lean Mobile App Development: Apply Lean startup methodologies to development successful iOS and Android apps . バーミンガム、イギリス: Packt Publishing Ltd. p. 43. ISBN 978-1-78646-704-1。
- ^ ルビン、ケネス（2012）、エッセンシャルスクラム。最も人気のあるアジャイルプロセスの実践ガイド、アディソンウェズリー（2013年出版）、375ページ、ISBN 978-0-13-704329-3
- ^ Project Management Institute 2021、用語集§3 定義。
- ^ 「スクラム アーティファクトとは? | 究極ガイド | Miro」miro.com/ 。 2024 年11 月 29 日閲覧。
- ^ Higgins, Tony (2009 年 3 月 31 日)。「アジャイルの世界における要件の作成」。BA Times。
- ^ Russ J. Martinelli、Dragan Z. Milosevic (2016 年 1 月 5 日)。プロジェクト管理ツールボックス: 実践的なプロジェクト マネージャーのためのツールとテクニック。Wiley。p. 304。ISBN 978-1-118-97320-2。
- ^ Ken Schwaber、Jeff Sutherland。「The Scrum Guide」（PDF）。Scrum.org 。 2018年5月25日閲覧。
- ^ Charles G. Cobb (2015 年 1 月 27 日)。アジャイルをマスターするためのプロジェクト マネージャー ガイド: 適応型アプローチの原則と実践。John Wiley & Sons。378 ページ。ISBN 978-1-118-99104-6。
- ^ Jenson, John (2019年3月8日). 「会議：開発者の生産性を低下させる要因」. TandemSeven – The Experience Innovation Company . 2020年6月5日時点のオリジナルよりアーカイブ。 2020年6月5日閲覧。
- ^ 「すべての開発者がアジャイルを好むわけではありません。その理由を 5 つ挙げます」。Business Matters。2019年 12 月 4 日。2020年6 月 5 日閲覧。
- ^ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. 「アジャイルソフトウェアプロセスの限界」。ソフトウェアエンジニアリングにおけるエクストリームプログラミングと柔軟なプロセスに関する第3回国際会議の議事録: 43–46。arXiv : 1409.6600。
- ^ 「スクラム実装における問題と課題」(PDF)。International Journal of Scientific & Engineering Research。3 (8)。2012 年 8 月。2015 年12 月 10 日に閲覧。
- ^ Hron, Michal; Obwegeser, Nikolaus (2022年1月1日). 「なぜ、そしてどのようにスクラムが実践に適応されているのか：体系的なレビュー」.システムとソフトウェアジャーナル. 183 : 111110. doi :10.1016/j.jss.2021.111110. ISSN 0164-1212. S2CID 240950847.
- ^ Hron, M.; Obwegeser, N. (2018 年 1 月)。「Scrum の実践: Scrum の適応の概要」(PDF)。2018年 1 月 3 ～ 6 日に開催された 2018 年 51 回ハワイ国際システム科学会議 (HICSS) の議事録。
- ^ ビョルンヴィグ、ゲルトルート;ジム・コプリエン（2008年6月21日）。 「組織パターンとしてのスクラム」。ガートルード＆コープ。
- ^ 「Scrum Pattern Community」。ScrumPLoP.org 。2016年7月22日閲覧。
- ^ Ladas, Corey (2007 年 10 月 27 日). 「scrum-ban」. Lean Software Engineering. 2018 年 8 月 23 日時点のオリジナルよりアーカイブ。 2012 年9 月 13 日閲覧。
- ^ クニーベルク、ヘンリック;スカリン、マティアス（2009年12月21日）。 「カンバンとスクラム – 両方を最大限に活用する」(PDF)。 InfoQ 。2016 年7 月 22 日に取得。
- ^ 「リスク管理 – リスクがプロジェクトを台無しにしないようにする方法」。ケリー・ウォーターズ。
- ^ 「Scrum of Scrums」。Agile Alliance。2015年12月17日。2014年2月9日時点のオリジナルよりアーカイブ。 2013年12月17日閲覧。
- ^ 「大規模スクラム (LeSS)」 2014年。
- ^ Grgic (2015). 「LeSS による組織のスケール除去 (ブログ)」
- ^ Larman, Craig; Bas Vodde (2013 年 5 月～6 月)。「Scaling Agile Development」(PDF)。クロストーク。
- ^ サントス、ロニー・デ・ソウザ;ラルフ、ポール。アルシャド、アルハム。シュトル、クラース＝ヤン（2023年10月5日）。 「分散スクラム: ケースのメタ分析」。ACM コンピューティング調査。56 (4): 1-37。土井：10.1145/3626519。S2CID 263672588。
- ^ Fowler, Martin (2018年8月25日). 「2018年のアジャイルソフトウェアの現状」. martinfowler.com . 2023年9月14日時点のオリジナルよりアーカイブ。2023年9月14日閲覧。
- ^ Jeffries, Ron (2016年9月8日). 「Dark Scrum」. ronjeffries.com . 2024年5月6日閲覧。
一般的な参考文献
- ディーマー、ピート。ベネフィールド、ガブリエル。ラーマン、クレイグ。ヴォッデ、バス (2009)。 「スクラム入門」。2009 年6 月 1 日に取得。
- Janoff, NS; Rising, L. (2000). 「小規模チーム向けの Scrum ソフトウェア開発プロセス」(PDF)。2015 年 11 月 6 日時点のオリジナル(PDF)からアーカイブ。2015年2 月 26 日閲覧。
- ミュンヒ、ユルゲン。オーヴェ、アームブラスト。ソト、マルティン。コワルチク、マーティン (2012)。ソフトウェアプロセスの定義と管理。スプリンガー。ISBN 978-3-642-24291-5。
- プロジェクトマネジメント知識体系ガイド（PMBOKガイド）（第7版）。ニュータウンスクエア、ペンシルバニア州：プロジェクトマネジメント協会。2021年。ISBN 978-1-62825-664-2。
- ルビン、ケネス (2013)。エッセンシャル スクラム: 最も人気のあるアジャイル プロセスの実践ガイド。アディソン ウェズリー。p. 173。ISBN 978-0-13-704329-3。
- Vacaniti , Daniel (2018 年 2 月)。「スクラム チーム向けカンバン ガイド」(PDF)。scrum.org。2018年3 月 12 日閲覧。
- Verheyen, Gunther (2013). Scrum – ポケットガイド (賢い旅行のお供) . ISBN 978-90-8753-720-3 .
外部リンク
ウィキメディア・コモンズには、スクラム (開発)に関連するメディアがあります。
Wikisource にはこの記事に関連する原文があります:
スクラムガイド
- Agile Alliance の Scrum ライブラリ
- Eclipse プロセス フレームワーク(EPF) プロジェクトによるスクラム プロセスの説明