スクラム（プロジェクト管理）
管理フレームワーク

Scrum Agileイベント（ 2020 Scrum Guide [1]に基づく）

Scrumは、ソフトウェア開発やその他の業界 で一般的に使用されているアジャイルチーム コラボレーション フレームワークです。

スクラムでは、チームが作業をスプリントと呼ばれる時間制限のある反復期間内に完了すべき目標に分割することが規定されています。各スプリントは1ヶ月以内で、通常は2週間続きます。スクラムチームは、デイリースクラムと呼ばれる、最大15分間の時間制限のあるスタンドアップミーティングで進捗状況を評価します。スプリントの終了時には、チームはさらに2つのミーティングを開催します。1つは関係者に作業を説明してフィードバックを求めるスプリントレビュー、もう1つは社内スプリントの振り返りです。スクラムチームの責任者は通常、スクラムマスターと呼ばれます。[2]

スクラムチームは、部門横断的かつ自己管理型であるべきです。シーケンシャルなアプローチとは異なり、スクラムは反復的かつ漸進的な製品開発フレームワークです。[3]スクラムは継続的なフィードバックと柔軟性を可能にし、物理的な共同作業や緊密なオンラインコラボレーションを奨励し、チームメンバー全員間の頻繁なコミュニケーションを義務付けることで、チームの自己組織化を促します。スクラムの柔軟なアプローチは、プロジェクトの進展に伴ってステークホルダーが要件を変更するという要件変動性の概念に基づいています。[4]

歴史

ソフトウェア開発におけるスクラムという用語の使用は、 1986年にハーバード・ビジネス・レビューに掲載された竹内弘高氏と野中郁次郎氏による論文「新製品開発ゲーム」に由来する。著者らは、自動車、複写機、プリンター業界の製造企業のケーススタディに基づき、製品開発のスピードと柔軟性を向上させる新しいアプローチを概説した。彼らはこれを「ラグビー・アプローチ」と呼んだ。これは、単一のクロスファンクショナルチームが複数の重複するフェーズにまたがって活動し、「ボールをパスし合いながら、チームとして最後までやり遂げようとする」プロセスである。[5]著者らは後に、著書『知識創造企業』の中でスクラムを展開した。[6]

1990年代初頭、ケン・シュワバーは自身の会社であるAdvanced Development Methodsで、のちにスクラムとなる手法を用いていた。ジェフ・サザーランド、ジョン・スカムニオタレス、ジェフ・マッケナはイーゼル社で同様の手法を開発し、その手法を「スクラム」と呼んだ。[7]サザーランドとシュワバーは後に協力して、それぞれのアイデアを統合した単一のフレームワーク、正式にはスクラムとして知られるようになった。シュワバーとサザーランドはスクラムをテストし、継続的に改良を重ね、1995年には研究論文を、[8] 2001年にはアジャイルソフトウェア開発宣言を発表した。[9]シュワバーはデュポン研究所とデラウェア大学のババトゥンデ・オグンナイケとも協力してスクラムを開発した。オグンナイケは、製品管理が実証的な実践に根ざしていなければ、初期条件の変化時にソフトウェア開発プロジェクトが失敗することが多いと考えていた。 [10]

2002年、シュワバーは他のメンバーと共にスクラムアライアンスを設立し、認定スクラム認定シリーズを立ち上げました。[11]シュワバーは2009年末にスクラムアライアンスを離れ、その後、並行してプロフェッショナルスクラム認定シリーズを監督するScrum.orgを設立しました。[12] 2009年以降、シュワバーとサザーランドによって「スクラムガイド」[13]と呼ばれる公開文書が発行・更新されてきました。このガイドは6回改訂されており、最新版は2020年11月に発行されています。

スクラムチーム

スクラムチームは、少なくとも3つのカテゴリー、すなわちプロダクトオーナー、開発者、そしてスクラムマスターで構成されます。プロダクトオーナーは、プロジェクトの成果に関心を持つステークホルダーと連携し、開発者にタスクと期待を伝えます。[14]スクラムチームの開発者は、スクラムマスターの支援を受けながら、自ら作業を組織します。[15]

プロダクトオーナー

各スクラムチームには1人のプロダクトオーナーがいます。[16]プロダクトオーナーは製品開発のビジネス面に焦点を当て、ほとんどの時間をステークホルダーやチームとの連携に費やします。その役割は主に製品のステークホルダー、顧客の声、または委員会の要望を代表することを目的としており、ビジネス成果の提供に責任を負います。[17] [18] [19]プロダクトオーナーは製品バックログを管理し、チームが提供する価値を最大化する責任を負います。[18]ただし、各スプリントでどれだけの作業を行うか、どのように達成するかを決定するのは、プロダクトオーナーではなく開発者です。[3]

開発者

スクラムでは、開発者またはチームメンバーという用語は、製品の開発とサポートに役割を果たす人を指し、研究者、建築家、デザイナー、プログラマーなどが含まれます。 [13] [20]

スクラムマスター

スクラムはスクラムマスターによって推進され、その役割はスクラムの理論と実践についてチームを教育し、指導することです。スクラムマスターはチームリーダーやプロジェクトマネージャーとは異なる役割と責任を持ちます。プロジェクトマネージャーは多くの場合、人材管理の責任を負いますが、スクラムマスターはそうではありません。スクラムチームには、開発者間の自己組織化を最大化するためにプロジェクトマネージャーが関与することはありません。[3]

ワークフロー

スプリント

スクラムフレームワーク（図中のPBIはプロダクトバックログ項目を指します）
スクラムプロセス

スプリント（デザインスプリント、イテレーション、タイムボックスとも呼ばれる）とは、チームメンバーが特定の目標に向けて取り組むための一定期間のことです。各スプリントは通常1週間から1か月ですが、最も一般的なのは2週間です。スプリントの目標は、目に見える形で「完了」したものを生み出すことであり、チームに確実性を与えるために、目標は不変のものとして扱われます。外部の優先事項の変更により目標を変更する必要がある場合、プロダクトオーナーまたはチームはスプリントを終了し、新しい目標を設定した新しいスプリントを開始できます。

各スプリントは、スプリント計画イベントから始まります。このイベントでは、スプリントの目標が定義され、バックログから優先順位が決定されます。スプリント計画の推奨最大所要時間は、スプリントの各週につき2時間です。各スプリントは、スプリントレビューで終了します。スプリントレビューでは、ステークホルダーに進捗状況を示してフィードバックを得ます。また、スプリント振り返りでは、チームが今後のスプリントに向けた教訓と改善点を特定します。[3]

デイリースクラム

コンピューティングルームでの毎日のスクラム

スプリント中、開発者は毎日、特定のガイドラインに沿ってデイリースクラム（多くの場合、立ち会いのもとで実施）を開催し、スクラムマスターがファシリテートすることもある。[3]デイリースクラムミーティングは15分未満で、毎日同じ時間と場所で開催される。ミーティングの目的は、スプリントの目標に向けた進捗状況と、その達成を妨げている可能性のある問題について、詳細な議論には立ち入らずに発表することである。ミーティング終了後、個々のメンバーは「ブレイクアウトセッション」や「アフターパーティー」に参加し、より詳細な議論やコラボレーションを行うことができる。[21]スクラムマスターは、チームメンバーがデイリースクラムを効果的に活用できるようにし、チームメンバーが活用できない場合は、同様の結果を得るための代替案を提供する責任がある。[22] [23]

スプリント後のイベント

スプリントレビューは、スプリントの終了時に実施される会議で、チームが完了した作業をステークホルダーと共有し、フィードバック、期待値、今後の計画について協議します。スプリントレビューでは、完了した成果物がステークホルダーに提示されます。スプリントレビューの推奨時間は、スプリントの週ごとに1時間です。[3]

スプリントの振り返りは、チームメンバーがスプリントの長所と短所、将来の改善領域、継続的なプロセス改善アクションを内部的に分析できる別の会議です。[17]

バックログの洗練

バックログリファインメントとは、チームメンバーが将来のスプリントに向けてバックログを見直し、優先順位を付けるプロセスです。これは、新しいスプリントの開始前に独立した段階として行うことも、チームメンバーが単独で取り組む継続的なプロセスとして行うこともできます。バックログリファインメントには、大規模なタスクをより小さく明確なタスクに分割すること、成功基準を明確にすること、そして変更された優先順位とリターンを見直すことが含まれます。[24]このプロセスは以前は「グルーミング」と呼ばれていました。[25] [26] [27]

遺物

アーティファクトとは、スクラムチームがプロジェクトに向けた作業を文書化することで製品開発を管理する手段です。スクラムのアーティファクトには多くの種類がありますが、最も一般的なものはプロダクトバックログ、スプリントバックログ、インクリメントの3つです。[要出典]

製品バックログ

プロダクトバックログは、実行すべき作業を細分化したものであって、チームが製品に対して維持する製品要件（機能、バグ修正、非機能要件など）の順序付きリストを含んでいる。プロダクトバックログの順序は、タスクの緊急度に対応している。バックログ項目の一般的な形式としては、ユーザーストーリーやユースケースなどがある。[3]プロダクトバックログには、プロダクトオーナーのビジネス価値の評価や、チームの製品の労力や複雑さの評価も含まれる場合があり、これらは丸められたフィボナッチスケールを使ったストーリーポイントで表すことができる。これらの見積りは、プロダクトオーナーがタイムラインを判断するのに役立ち、プロダクトバックログ項目の順序付けにも影響を与える可能性がある。[ 28]バックログの先頭にある優先度の高い項目は、開発者が作業できるようにより詳細に細分化されているが、バックログの下位にあるタスクはより漠然としている可能性がある。[3]

スプリントバックログ

スプリントバックログとは、製品バックログから特定のスプリントで開発者が取り組む項目のサブセットです。[29]開発者は、過去の実績に基づき、各スプリントにおける自身のキャパシティを評価し、スプリントを埋めるのに適切と思われるタスクをこのバックログに詰めていきます。スクラムアプローチでは、スプリントバックログ上のタスクは、特定の個人やリーダーによって開発者に割り当てられるものではありません。開発者は、バックログの優先度、自身の能力、そして学習機会などの他の要因に応じて、必要に応じて作業をプルすることで、自己組織化を行います。[3]

インクリメント

インクリメントとは、スプリントの目標と完了の定義を満たす、リリース可能なスプリントの出力です。これは、完了したスプリントバックログ項目すべてと、それ以前のすべてのスプリントの作業内容が統合されたものです。[3]

その他の遺物

バーンダウンチャート

完了したスプリントのサンプルバーンダウンチャート。各日の終わりに残っている作業量を表示します。

スクラムでよく使われるバーンダウンチャートは、残りの作業を示す公開チャートです。[30]参照用に素早く視覚化できます。バーンダウンチャートの横軸は残り日数、縦軸は各日の残り作業量を示します。スプリント計画中に、理想的なバーンダウンチャートが作成されます。[31]そして、スプリント中に開発者は残りの作業量でチャートを更新します。

バーンアップチャート

各スプリントで完了したスコープを示す、リリースのサンプルバーンアップ チャート (MVP =最小限の実行可能な製品)

各スプリントの終了時に更新されるリリースバーンアップチャートは、予測スコープの達成に向けた進捗状況を示します。リリースバーンアップチャートの横軸はリリース内のスプリントを示し、縦軸は各スプリントの終了時に完了した作業量を示します。[32]

速度

チームの1スプリントにおける総能力努力は、前回のスプリントで完了した作業を評価することで推定できます。過去の「速度」データの収集は、チームが自らの能力を理解するためのガイドラインとなります。[要出典]

完了の定義

チームの「完了の定義」とは、作業が「完了」とみなされるために完了する必要がある事項を列挙したチェックリストです。[要出典]完了の定義は、必ずしも作業がリリース可能であることを保証するものではありません。開発の初期段階でリリースすることは現実的ではない場合もあるためです。これは、チームが既存の能力でどれだけ合理的に目標に近づけるかを表しています。チームが成長するにつれて、完了の定義は、作業のリリースに必要な要件に合わせて進化していく必要があります。[3]

関連する用語として「準備の定義」があり、これはある項目の作業を開始する前に完了する必要がある項目のチェックリストである。[33]

批判

デイリースクラムやスクラムレビューなどのスクラムイベントは生産性を低下させ、実際の生産的なタスクに費やすべき時間を無駄にすると主張する人もいます。[34]また、スクラムは、パートタイムまたは地理的に離れたチーム、個人または作業グループで作業する方が適している高度に専門化されたメンバーがいるチーム、および増分テストや開発テストに適さないチームにとって困難をもたらすことが観察されています。[35] [36]

体系的なレビューでは、分散ソフトウェア開発において「分散スクラムはプロジェクト全体の成功にプラスにもマイナスにも影響を与えない」ことが判明した。[37]

アジャイルソフトウェア開発宣言の著者の一人であるマーティン・ファウラーは、いわゆる「偽アジャイル」の実践を批判している。これは「アジャイルの価値と原則を無視している」[38]ものであり、「プロセスやツールよりも個人と相互作用を重視する」 [9]アジャイルの原則に反し、「アジャイル産業複合体が人々に方法を押し付けている」ものである。また、作業を行う個人が作業の進め方を決定し、プロセスを自分のニーズに合わせて変更できるとしている。

2016年9月、アジャイル宣言[ 9]の署名者であるロン・ジェフリーズは、 「ダークスクラム」と呼ばれるものについて説明し、「人々がスクラムの原則と価値を真に理解するまでは、悪用はほぼ避けられない」と述べました。彼は特に、自己組織化の普及が遅いことに注目しました。[39]

適応

スクラムは、様々な目的を達成するために、様々な状況に合わせて調整または適応されることが多い。[40]スクラムを適応させる一般的なアプローチは、スクラムを他のソフトウェア開発方法論と組み合わせることである。これは、スクラムが製品開発ライフサイクル全体をカバーしていないためである。[41]スクラム実践者の中には、特定の問題や組織にスクラムを適用または適応させる方法について、より詳細な手法を提案する者もいる。多くの人はこれらの手法を「パターン」と呼んでおり、これは建築やソフトウェアにおけるデザインパターンに類似した用法である。[42] [43]

スクラムバン

スクラムバンは、スクラムとカンバンに基づいたソフトウェア生産モデルです。作業の各段階を示すために、同じスペースで作業するチームは、付箋や大きなホワイトボードを使用することが多いです。[44]カンバンモデルにより、チームは作業段階と制限を視覚化できます。[45]

スクラム・オブ・スクラム

スクラム・オブ・スクラムとは、複数のチームが同一の製品を開発する際に、スクラムを大規模に運用するための手法です。スクラム・オブ・スクラムの毎日のスクラムミーティングには、各チームから選出されたアンバサダー（開発者またはスクラムマスター）が参加します。調整ツールとして、スクラム・オブ・スクラムは、チームがチーム全体のリスク、障害、依存関係、および前提条件（RIDA）に共同で取り組むことを可能にし、これらは各チーム独自のバックログで追跡できます。[46]

大規模スクラム

大規模スクラムは、Bas VoddeとCraig Larmanによって開発された、多様なルールとガイドラインを用いてスクラムを拡張する製品開発のための組織システムです。このフレームワークには2つのレベルがあります。第1レベルは最大8チーム向けに設計されており、第2レベルは「LeSS Huge」と呼ばれ、数百人の開発者が関わる開発に対応できます。[要出典]

参照

引用

  1. ^ Ken Schwaber、Jeff Sutherland . 「スクラムガイド」（PDF） . Scrum.org . 2023年6月15日閲覧。
  2. ^ 「スクラムマスターとは？ 知っておくべきことすべて – Forbes Advisor」www.forbes.com . 2021年12月27日. 2023年11月16日閲覧。
  3. ^ abcdefghijk ピート・ディーマー;ガブリエル・ベネフィールド;クレイグ・ラーマン。 Bas Vodde (2012 年 12 月 17 日)。 「スクラム入門: スクラムの理論と実践への軽量ガイド (バージョン 2.0)」。情報Q.
  4. ^ J. Henry、S. Henry. ソフトウェア保守プロセスと要件変動性の定量的評価. ACMコンピュータサイエンス会議論文集、346～351ページ、1993年。
  5. ^ 竹内弘高、野中郁次郎（1986年1月1日）「新たな製品開発ゲーム」ハーバード・ビジネス・レビュー。 2010年6月9日閲覧。スクラムダウンフィールドの推進
  6. ^ 知識創造企業. オックスフォード大学出版局. 1995年. p. 3. ISBN 978-0-19-976233-0. 2013年3月12日閲覧。
  7. ^ Sutherland, Jeff (2004年10月). 「アジャイル開発：最初のスクラムから学んだ教訓」. 2014年6月30日時点のオリジナル(PDF)からアーカイブ。 2008年9月26日閲覧。
  8. ^ Sutherland, Jeffrey Victor ; Schwaber, Ken (1995).ビジネスオブジェクトの設計と実装: OOPSLA '95 ワークショップ議事録.ミシガン大学. p. 118. ISBN 978-3-540-76096-2。
  9. ^ abc 「アジャイルソフトウェア開発宣言」 。 2019年10月17日閲覧。
  10. ^ Schwaber, Ken (2004年2月1日). 『アジャイル・プロジェクトマネジメント with Scrum』 . Microsoft Press . ISBN 978-0-7356-1993-7。
  11. ^ Maximini, Dominik (2015年1月8日). 『スクラム文化：組織におけるアジャイル手法の導入』. Management for Professionals. Cham: Springer (2015年出版). p. 26. ISBN 978-3-319-11827-72016年8月25日閲覧。ケン・シュワバーとジェフ・サザーランドは、1995年にテキサス州オースティンで開催されたOOPSLAカンファレンスで初めてスクラムを発表しました。[...] 2001年には、スクラムに関する最初の書籍が出版されました。[...] 1年後（2002年）、ケンは世界中でスクラムのトレーニングと認定を提供することを目的として、スクラムアライアンスを設立しました。
  12. ^ “ホーム”. Scrum.org . 2020年1月6日閲覧。
  13. ^ ab Sutherland, Jeff ; Schwaber, Ken (2013). 「Scrum Guides」. ScrumGuides.org . 2023年6月15日閲覧。
  14. ^ モリス、デイビッド (2017).スクラム：アジャイルプロジェクトのための理想的なフレームワーク. In Easy Steps. pp.  178– 179. ISBN 978-1-84078-731-3. OCLC  951453155.
  15. ^ Cobb, Charles G. (2015). 『アジャイルをマスターするためのプロジェクトマネージャーガイド：適応型アプローチの原則と実践』 ホーボーケン、ニュージャージー州: John Wiley & Sons. p. 37. ISBN 978-1-118-99104-6。
  16. ^ コーン、マイク（2010年）『アジャイルで成功する：スクラムを用いたソフトウェア開発』アッパーサドルリバー、ニュージャージー州：アディソン・ウェスリー、ISBN 978-0-321-57936-2。
  17. ^ ab ルビン、ケネス（2013）、エッセンシャルスクラム。最も人気のあるアジャイルプロセスの実践ガイド、アディソン・ウェズレー、pp. 173、375、ISBN 978-0-13-704329-3
  18. ^ ab McGreal, Don; Jocham, Ralph (2018年6月4日). 『プロフェッショナル・プロダクトオーナー：スクラムを競争優位性として活用する』Addison-Wesley Professional. ISBN 978-0-13-468665-3。
  19. ^ Pichler, Roman (2010年3月11日). 『スクラムによるアジャイル製品管理：顧客に愛される製品を作る』Addison-Wesley Professional. ISBN 978-0-321-68413-4。
  20. ^ ラッド、ネーダー K.;フランク・ターリー（2018）。アジャイル スクラム財団コースウェア、第 2 版。オランダ、スヘルトーヘンボス：ヴァン・ハーレン。 p. 26.ISBN​ 978-94-018-0279-6。
  21. ^ Flewelling, Paul (2018). 『アジャイル開発者ハンドブック：ソフトウェア開発からより多くの価値を引き出す：アジャイル手法を最大限に活用する』 英国バーミンガム：Packt Publishing Ltd. p. 91. ISBN 978-1-78728-020-5。
  22. ^ マッケナ、デイブ (2016). 『スクラムの芸術：スクラムマスターが開発チームを束ね、アジリティを解き放つ方法』 ペンシルベニア州アリキッパ：CA Press. p. 126. ISBN 978-1-4842-2276-8。
  23. ^ 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 . Birmingham, UK: Packt Publishing Ltd. p. 43. ISBN 978-1-78646-704-1。
  24. ^ Ken Schwaber、Jeff Sutherland (2020年11月18日). 「スクラムガイド」. scrumguides.org . scrumguides.org . 2025年1月10日閲覧.プロダクトバックログのリファインメントとは、プロダクトバックログの項目をより細かく、より正確な項目に細分化し、さらに定義する行為です。
  25. ^ Ken Schwaber、Jeff Sutherland (2020年11月18日). 「Official Scrum Guide Revisions」. scrumguides.org . scrumguides.org . 2025年1月10日閲覧。プロダクトバックログはグルーミングではなくリファインメントです。
  26. ^ Project Management Institute (PMI) と Agile Alliance. 「バックログリファインメントとは？」. agilealliance.org . agilealliance.org . 2025年1月10日閲覧。バックログリファインメント（旧称：バックロググルーミング）とは、プロダクトオーナーとチームメンバーの一部または全員がバックログの項目をレビューし、バックログに適切な項目が含まれているか、優先順位が付けられているか、バックログの先頭にある項目がデリバリーの準備ができているかを確認することです。
  27. ^ Atlassian Corporation. 「バックログリファインメントとは？」. atlassian.com . Atlassian . 2025年1月10日閲覧。「バックロググルーミング」という言葉を耳にすることもあるかもしれませんが、アジャイルバックログリファインメントは、プロセスの協調性と継続性をより適切に反映しているため、業界標準となっているようです。
  28. ^ Higgins, Tony (2009年3月31日). 「アジャイルの世界における要件定義」. BA Times.
  29. ^ Russ J. Martinelli、Dragan Z. Milosevic (2016年1月5日). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. p. 304. ISBN 978-1-118-97320-2。
  30. ^ Charles G. Cobb (2015年1月27日). 『アジャイルをマスターするためのプロジェクトマネージャーガイド：適応型アプローチの原則と実践』 John Wiley & Sons. p. 378. ISBN 978-1-118-99104-6。
  31. ^ 「Agile 101 – スプリントプランニング」Somar Digital . 2025年7月9日閲覧。
  32. ^ Arafeen, Junaid; Bose, Saugata (2009年9月). 「スプリントバーンダウンチャートの上下運動の分析によるスクラムモデルを用いたソフトウェア開発の改善：より良い代替案の提案」. International Journal of Digital Content Technology and its Applications . 3 (3) – CiteSeerX経由.
  33. ^ 「Readyの定義とその活用方法」プロジェクトマネジメント協会。 2025年12月22日閲覧。
  34. ^ 「すべての開発者がアジャイルを好むわけではない。その理由を5つ挙げよう」Business Matters、2019年12月4日。 2020年6月5日閲覧。
  35. ^ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. 「アジャイルソフトウェアプロセスの限界」.第3回国際エクストリームプログラミングおよびソフトウェアエンジニアリングにおける柔軟なプロセスに関する会議議事録: 43–46 . arXiv : 1409.6600 .
  36. ^ 「スクラム導入における課題と問題点」（PDF） . International Journal of Scientific & Engineering Research . 3 (8). 2012年8月. 2015年12月10日閲覧。
  37. ^ サントス、ロニー・デ・ソウザ;ラルフ、ポール。アルシャド、アルハム。シュトル、クラース＝ヤン（2023年10月5日）。 「分散スクラム: ケースのメタ分析」。ACM コンピューティング調査。56 (4): 1–37 .土井: 10.1145/3626519。S2CID  263672588。
  38. ^ Fowler, Martin (2018年8月25日). 「2018年のアジャイルソフトウェアの現状」. martinfowler.com . 2023年9月14日時点のオリジナルよりアーカイブ。 2023年9月14日閲覧。
  39. ^ Jeffries, Ron (2016年9月8日). 「Dark Scrum」. ronjeffries.com . 2024年5月6日閲覧。
  40. ^ ミハル・ホロン、ニコラウス・オブウェゲサー（2022年1月1日）「スクラムはなぜ、どのように実践に適応されているのか：体系的レビュー」『システムとソフトウェアジャーナル』183 111110. doi :10.1016/j.jss.2021.111110. ISSN  0164-1212. S2CID  240950847.
  41. ^ Hron, M.; Obwegeser, N. (2018年1月). 「スクラムの実践：スクラムの適応の概要」(PDF) . 2018年第51回ハワイ国際システム科学会議 (HICSS) 議事録, 2018年1月3日～6日.[リンク切れ]
  42. ^ Bjørnvig, Gertrud; Coplien, Jim (2008年6月21日). 「組織パターンとしてのスクラム」. Gertrude & Cope. 2012年11月6日時点のオリジナルよりアーカイブ。
  43. ^ 「Scrum Pattern Community」. ScrumPLoP.org . 2016年7月22日閲覧。
  44. ^ Ladas, Corey (2007年10月27日). 「scrum-ban」. Lean Software Engineering. 2018年8月23日時点のオリジナルよりアーカイブ。2012年9月13日閲覧。
  45. ^ クニーベルク、ヘンリック;スカリン、マティアス（2009年12月21日）。 「カンバンとスクラム – 両方を最大限に活用する」(PDF)。 InfoQ 。2016 年7 月 22 日に取得。
  46. ^ 「Scrum of Scrums」. Agile Alliance. 2015年12月17日. 2014年2月9日時点のオリジナルよりアーカイブ。 2013年12月17日閲覧。

一般的な参考文献と引用文献

  • Janoff, NS; Rising, L. (2000). 「小規模チームのためのスクラムソフトウェア開発プロセス」(PDF) . IEEE Software . 17 (4): 26– 32. doi :10.1109/52.854065.
  • ミュンヒ、ユルゲン。オーヴェ、アームブラスト。ソト、マルティン。コワルチク、マーティン (2012)。ソフトウェアプロセスの定義と管理。スプリンガー。ISBN 978-3-642-24291-5。
  • プロジェクトマネジメント知識体系ガイド（PMBOKガイド）（第7版）. ニュータウンスクエア、ペンシルバニア州:プロジェクトマネジメント協会. 2021年. ISBN 978-1-62825-664-2。
  • Vacaniti, Daniel (2018年2月). 「スクラムチームのためのカンバンガイド」(PDF) . scrum.org . 2018年3月12日閲覧.
ウィキメディア コモンズには、スクラム (開発)に関連するメディアがあります。
英語版ウィキソースにはこの記事に関連する原文があります:
スクラムガイド
Retrieved from "https://en.wikipedia.org/w/index.php?title=Scrum_(project_management)&oldid=1332314759"