スクラム(ソフトウェア開発)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

プロジェクト管理においてスクラムは複雑な環境で製品を開発、提供、および維持するためのフレームワークであり[ 1 ] 最初はソフトウェア開発に重点を置いていますが、研究を含む他の分野で使用されています。販売、マーケティングおよび高度な技術[2] 10人以下のメンバーのチーム向けに設計されており、1か月以内、通常は2週間以内に、スプリントと呼ばれるタイムボックス化された反復内で完了できる目標に作業を分割します。スクラムチームは、タイムボックス化された進捗状況を評価します毎日のスクラム(スタンドアップミーティングの一種)と呼ばれる、15分以下の毎日のミーティング。スプリントの最後に、チームはさらに2つの会議を開催します。フィードバックを引き出すために利害関係者に行われた作業を示すスプリントレビューと、チームが反映して改善できるようにする スプリント回顧展です。

2020スクラムガイド[3]に基づくスクラムアジャイルイベント

名前

ソフトウェア開発用語のスクラムは、竹内弘高野中郁次郎による1986年の論文「新製品開発ゲーム」で最初に使用されました[4] [5]この論文は、ハーバードビジネスレビューの1986年1月号に掲載されました。この用語は、スクラムがプレーヤーのフォーメーションであるラグビーから借用されています。スクラムという用語は、チームワークを強調するため、論文の著者によって選択されました。[6]

スクラムは、 SCRUMのように、すべて大文字で書かれているのが見られることがあります[7]単語自体は頭字語ではありませんが、その大文字のスタイリングは、タイトルにSCRUMを大文字にしたKenSchwaber [8]による初期の論文に由来する可能性があります。[9] [10]

スクラムという用語自体商標は失効することが許可されていますが、現在では、個人ではなく、より広いコミュニティが所有する一般的な商標と見なされています。[11]

スクラムの文献で使用される用語の多くは、通常、先頭の大文字で書かれています(たとえば、スクラムマスターデイリースクラム)が、一般的な名詞である場合は、多くの場合、大文字にしないでください正しい文法を維持するために、この記事では、これらの用語(スクラムマスターデイリースクラムなど)に通常の文の大文字小文字を使用します。ただし、認識されたマーク(認定スクラムマスタープロフェッショナルスクラムマスターなど)は除きます。

重要なアイデア

スクラムは、複雑な製品を開発、提供、および維持するための軽量で反復型の増分フレームワークです。[12] [13]このフレームワークは、製品開発に対する従来の順次アプローチの前提に挑戦し、チームメンバーの物理的なコロケーションまたは緊密なオンラインコラボレーション、および毎日の対面を促進することにより、チームが自己組織化できるようにします。関係するすべてのチームメンバーと分野の間のコミュニケーションに直面します。

スクラムの重要な原則は、顧客が必要なものの範囲を変更し(多くの場合、要件の変動性[14]と呼ばれます)、予測できない課題が発生するという二重の認識です。これには、予測または計画されたアプローチは適していません。これらの変更はさまざまなソースから発生しますが、スクラムによると、理由を理解することは無関係であり、変更は単に受け入れられ、受け入れられ、利益について分析されるべきです。

そのため、スクラムは証拠に基づく経験的アプローチを採用しています。問題を事前に完全に理解または定義することはできないことを受け入れ、代わりに、チームが迅速に提供し、新たな要件に対応し、進化することに適応する能力を最大化する方法に焦点を当てます。技術と市況の変化。

歴史

竹内弘高と野中郁次郎は、1986年のハーバードビジネスレビューの記事「新製品開発ゲーム」で、製品開発の文脈でスクラムという用語を紹介しました。[15]竹内と野中は後に知識創造会社[16]で、それは「組織的知識創造、[...]イノベーションを継続的、漸進的、らせん状にもたらすのが特に得意」の一形態であると主張した。

著者は、自動車、コピー機、プリンター業界の製造会社の事例研究に基づいて、速度と柔軟性を向上させる商用製品開発への新しいアプローチについて説明しました[15]彼らはこれを全体論的またはラグビーのアプローチと呼びました。これは、プロセス全体複数の重複するフェーズにまたがる1つの部門横断的なチームによって実行され、チームが「ボールを前後に通過させて、ユニットとして距離を移動しようとする」ためです。 。[15]ラグビーフットボールでは、各チームのフォワードが頭を下げて連動し、ボールを手に入れようとするためスクラムを使用してプレーを再開します。 [17])。

スクラムフレームワークは、デュポン研究所とデラウェア大学でのババトゥンデオグンナイケとのシュヴァーバーによる研究に基づいていました。[9] Ogunnaikeは、経験論に基づかないソフトウェアなどの複雑な製品を開発する試みは、初期条件と仮定が変化するにつれて、より高いリスクと失敗率に運命づけられるとアドバイスしました。頻繁な検査と適応を使用し、柔軟性と透明性を備えた経験論が最も適切なアプローチです。

1990年代初頭、Ken Schwaberは、彼の会社であるAdvancedDevelopmentMethodsでスクラムになるものを使用しました。一方、Jeff Sutherland、John Scumniotales、Jeff McKennaは、Easel Corporationで同様のアプローチを開発し、スクラムという1つの単語を使用して参照しました。[18]

SutherlandとSchwaberは協力して、アイデアを単一のフレームワークであるスクラムに統合しました。彼らはスクラムをテストし、継続的に改善し、1995年の論文[19]、2001年のアジャイルソフトウェア開発マニフェストへの貢献[20]、および2002年以降のスクラムの世界的な普及と使用につながりました。

1995年、SutherlandとSchwaberは、テキサス州オースティンで開催されたオブジェクト指向プログラミング、システム、言語、アプリケーション'95 (OOPSLA '95)の一環として開催されたビジネスオブジェクト設計および実装ワークショップで、スクラムフレームワークについて説明する論文を共同で発表しました。[19]その後数年間、SchwaberとSutherlandは協力して、この資料を彼らの経験と進化する優れた実践と組み合わせて、スクラムとして知られるようになったものを開発しました。[3]

2001年、SchwaberはMike Beedleと協力して、本「アジャイルソフトウェア開発スクラム」でこの方法を説明しました[21]製品開発の計画と管理に対するスクラムのアプローチには、意思決定権限を運用特性と確実性のレベルに引き上げることが含まれます。[9]

2002年、Schwaberは他の人たちと一緒にスクラムアライアンス[22]を設立し、認定スクラム認定シリーズを設立しました。Schwaberは2009年後半にスクラムアライアンスを去り、並行するプロフェッショナルスクラム認定シリーズを監督するScrum.org [23]を設立しました。[24]

2009年以降、スクラムガイド[3]と呼ばれる公開ドキュメントが発行され、SchwaberとSutherlandによって更新されています。現在のバージョンは2020年11月で、6回改訂されています。

スクラムチーム

スクラムの基本単位は、製品所有者、スクラムマスター、および開発者で構成される小さなチームです。チームは自己管理型で部門の枠を超えており、一度に1つの目標である製品の目標に焦点を合わせています。

プロダクトオーナー

製品の利害関係者顧客の声を代表する(または委員会の要望を代表する可能性がある[25])製品所有者は、良好なビジネス結果を提供する責任があります。[26]したがって、製品の所有者は、製品のバックログと、チームが提供する価値を最大化する責任があります。[25]プロダクトオーナーは、顧客中心の結果(通常はユーザーストーリーに限定されません)の観点から製品を定義し、それらを製品バックログに追加し、重要性と依存関係に基づいて優先順位を付けます。[27]スクラムチームには1人の製品所有者のみが必要です(ただし、製品所有者は複数のチームをサポートできます)[28]。この役割とスクラムマスターの役割を組み合わせないことを強くお勧めします。製品の所有者は、製品開発のビジネス側に焦点を合わせ、利害関係者やチームとの連絡に大部分の時間を費やす必要があります。プロダクトオーナーは、チームが技術的な解決策に到達する方法を指示しませんが、チームメンバー間のコンセンサスを求めます。[29] [30] [31] [より良い情報源が必要]この役割は非常に重要であり、スクラムチームのビジネスとエンジニア(開発者)の両方を深く理解する必要があります。したがって、優れたプロダクトオーナーは、ビジネスに必要なものを伝え、なぜそれが必要なのかを尋ね(それを達成するためのより良い方法がある可能性があるため)、必要に応じて、技術用語を使用して開発者を含むすべての利害関係者にメッセージを伝えることができる必要があります。プロダクトオーナーは、スクラムの経験的ツールを使用して、リスクを管理し、価値を実現しながら、非常に複雑な作業を管理します。

コミュニケーションは製品所有者の中心的な責任です。優先順位を伝え、チームメンバーや利害関係者に共感する能力は、製品開発を正しい方向に導くために不可欠です。プロダクトオーナーの役割は、チームとその利害関係者の間のコミュニケーションのギャップを埋め、チームの利害関係者の代理として、また全体的な利害関係者コミュニティのチーム代表として機能します。[32] [33]

利害関係者に対するチームの顔として、以下は利害関係者に対する製品所有者のコミュニケーションタスクの一部です。[34]

  • リリースを定義して発表します。
  • 納品と製品の状態を伝えます。
  • ガバナンス会議中に進捗状況を共有します。
  • 重要なRIDA(リスク、障害、依存関係、および仮定)を利害関係者と共有します。
  • 優先順位、範囲、資金、およびスケジュールについて交渉します。
  • 製品のバックログが表示され、透明で、明確であることを確認してください。

関係を築く能力は、プロダクトオーナーが持つ重要な属性であり、自分自身を他人の立場に置く能力です。プロダクトオーナーは、さまざまな背景、職務、目的を持つさまざまな利害関係者と会話し、これらのさまざまな視点を理解できるはずです。効果的であるためには、製品所有者が聴衆が必要とする詳細のレベルを知ることが賢明です。開発者は、期待どおりに製品を構築できるように、徹底的なフィードバックと仕様が必要ですが、エグゼクティブスポンサーは、進捗状況の要約が必要な場合があります。必要以上の情報を提供すると、利害関係者の関心が失われ、時間が無駄になる可能性があります。経験豊富な製品所有者は、直接的なコミュニケーション手段を好みます。[28]

利害関係者のニーズを特定し、利害関係者の利益の間で優先順位を交渉し、開発者と協力して要件を効果的に実装する技術に熟練することにより、製品所有者の効果的なコミュニケーション能力も強化されます。

開発者

開発者は、スプリントごとに価値の増分を構築するために必要なすべての作業を実行します。[27]

開発者[3]という用語 は、システムまたは製品の開発とサポートで役割を果たすすべての人を指し、研究者、アーキテクト、設計者、データスペシャリスト、統計家、アナリスト、エンジニア、プログラマー、テスターなどが含まれます。[35]ただし、「開発者」という用語が自分に当てはまると感じない人がいると混乱が生じる可能性があるため、チームメンバーと呼ばれることがよくあります。

チームは自己組織的です。プロダクトオーナー以外の方法でチームに作業を行うことはできません。スクラムマスターはチームを気を散らすものから保護することが期待されますが、チームは顧客や利害関係者と直接対話して、フィードバックの最大限の理解と即時性を得ることが推奨されます。[27]

スクラムマスター

スクラムは、製品の目標と成果物を提供するチームの能力に対する障害を取り除く責任があるスクラムマスターによって促進されます。[36]スクラムマスターは、従来のチームリーダープロジェクトマネージャーではありませんが、チームと気を散らす影響との間の障壁として機能します。スクラムマスターは、スクラムフレームワークの後に、スクラムの理論と概念についてチームを指導し、多くの場合、主要なセッションを促進し、チームの成長と改善を促します。この役割は、これらの二重の視点を強化 するために、チームファシリテーターまたはサーヴァントリーダーとも呼ばれています。

スクラムマスターの主な責任は次のとおりです(ただし、これらに限定されません)。[37]

  • チームが継続的に前進できるように、必要な作業が十分に理解されるように、製品所有者が製品バックログを維持できるように支援します
  • 主要な利害関係者からの意見を取り入れて、チームが製品の完了の定義を決定するのを支援します
  • 製品に高品質の機能を提供するために、スクラムの原則の範囲内でチームを指導する[38]
  • 主要な利害関係者と組織の他のメンバーにスクラム(そしておそらくアジャイル)の原則について教育する
  • スクラムチームが、チームの内部または外部にかかわらず、進行の障害を回避または除去するのを支援します
  • チーム内での自己組織化とクロスファンクショナルの促進
  • 定期的な進捗を確保するためのチームイベントの促進

スクラムマスターは、人々や組織が経験的で無駄のない思考を採用するのを助け、確実性と予測可能性への希望を残します。

スクラムマスターの役割がプロジェクトマネージャーと異なる点の1つは、プロジェクトマネージャーには人事管理の責任があるかもしれませんが、スクラムマスターにはないということです。チームは権限を与えられ、自己組織化することが期待されているため、スクラムマスターは限られた量の指示を提供します。[39]従来の指揮統制傾向は困難を引き起こすため、スクラムはプロジェクトマネージャーの役​​割を正式に認識していません。[40]

ワークフロー

スプリント

スクラムフレームワーク
スクラムプロセス

スプリント(イテレーションまたはタイムボックスとも呼ばれます)は、スクラムの開発の基本単位です。スプリントはタイムボックス化された取り組みです。つまり、長さはスプリントごとに事前に合意および固定されており、通常は1週間から1か月の間であり、2週間が最も一般的です。[9]

各スプリントは、スプリントの目標が定義されているスプリント計画イベントから始まります。今後のスプリントの優先順位は、バックログから選択されます。各スプリントは2つのイベントで終了します。

  • スプリントレビュー(利害関係者にフィードバックを引き出すために示される進捗状況
  • スプリントの回顧展(次のスプリントのレッスンと改善点を特定します)。[18]

スクラムは、完了したばかりのスプリントの最後に、価値のある実用的な出力を強調します。ソフトウェアの場合、これには、製品が完全に統合され、テストされ、文書化されており、潜在的にリリース可能であることが含まれる可能性があります。[40]

スプリント計画

スプリントの開始時に、スクラムチームは次の目的でスプリント計画イベントを開催します。

  • プロダクトオーナーが設定した優先順位に基づいて、スプリントの目標、つまりスプリントの終わりまでに提供すると予測されるものの簡単な説明に同意します
  • この目標に貢献する製品バックログアイテムを選択します
  • そのスプリント中にどの項目が実行されることを意図しているかについて相互に話し合い、合意することにより、スプリントバックログを形成します

スプリント計画の最大期間は、4週間のスプリントで8時間です。[3]詳細な作業が詳細に説明されているため、チームが1回のスプリントでその作業を完了できないとチームが判断した場合、一部の製品バックログアイテムが分割されたり製品バックログに戻されたりすることがあります。

デイリースクラム

コンピューティングルームでの毎日のスクラム。この一元化された場所は、チームが時間どおりに開始するのに役立ちます。

スプリント中の毎日、開発者は特定のガイドラインを使用して毎日スクラムを行います(時には立ち上がって実施されます)。 [41] [9]

すべての開発者は準備ができています。毎日のスクラム:

  • スプリントの目標に向けた進捗状況の検査に焦点を当てています
  • 毎日同じ時間と場所で発生する必要があります
  • 15分に制限されています(タイムボックス)
  • 実施されますが、チームが決定します
  • 開発者だけが話す必要がありますが、他の人を含めることができます。
  • スクラムマスターによって促進される可能性があります
  • 進歩の障害を特定する可能性があります(例えば、つまずき、リスク、問題、依存の遅れ、仮定が根拠のないことが証明された)[42]
  • ディスカッションは含まれていません
  • 進捗チャートを更新する手段ではありません

毎日のスクラム中に詳細な議論を行うべきではありません。終わったら、個々のメンバーは、「ブレイクアウトセッション」または「アフターパーティー」としてよく知られている問題について詳細に話し合うことができます。[43]特定されたブロッカーは、解決に向けて取り組むために、毎日のスクラムの外で集合的に議論されるべきです。

チームがこのイベントで価値を認識していない場合、その理由を判断し[44]、スクラムの原則についてチームと利害関係者を教育する[38]か、チームに独自の維持方法を設計するように促すのは、スクラムマスターの責任です。チームはスプリントの進捗状況を完全に通知しました。

スプリントレビュー

スプリントの最後に実施されたチーム:

  • 完成した作業を関係者に提示します(別名デモ
  • 次のようなトピックについて利害関係者と協力します。
    • 完成した製品の増分に関するフィードバックを招待する
    • 不完全な作業の影響について話し合う(計画されているかどうかにかかわらず)
    • 今後の作業に関する提案を受け取る(次に何に取り組むべきかについてのガイダンス)

プロダクトオーナーは、このイベントを、利害関係者と一緒に製品のバックログを確認および改善するための貴重な機会と見なす必要があります。

スプリントレビューのガイドライン:

  • 不完全な作業は実証されるべきではありません。利害関係者には、受け取る製品の増分を提示する必要がありますが、必要に応じて進行中の作業を確認するように要求することもできます。ただし、チームは何が行われたかを示す準備をする必要があります。
  • 推奨される期間は、2週間のスプリントの場合は2時間です(他のスプリント期間に比例します)。[3]

スプリント回顧展

スプリントの回顧展で、チームは次のことを行いました。

  • 過去のスプリントを反映する
  • 最後のスプリントがどのように進んだかを検査します(個人、相互作用、プロセス、ツール、完了の定義)
  • 継続的なプロセス改善アクションを特定して合意する

スプリント回顧展のガイドライン:[要出典]

  • スプリントの回顧展で考慮すべき3つの提案された領域は次のとおりです。
    • スプリント中に何がうまくいったのですか?
    • 何がうまくいかなかったのですか?
    • 次のスプリントで何が違うのでしょうか?
  • 期間は、4週間のスプリントの場合は最大3時間で、他のスプリントの期間に比例します(たとえば、2週間のスプリントの場合は1時間半)。

スクラムマスターはこのイベントを促進するかもしれませんが、チームの一員として参加することもできます。

バックログの改良

元々はコアスクラムプラクティスではありませんでしたが、バックログの改良(以前はグルーミングと呼ばれていました)がスクラムガイドに追加され、スプリントに入る製品のバックログアイテムの品質を管理する方法として採用されました。これは、新しい情報に照らして、製品のバックログアイテムを確認および修正/更新/再注文する継続的なプロセスです。

バックログとその中のアイテムを変更する理由は次のとおりです。

  • 大きなアイテムは複数の小さなアイテムに分割される場合があります
  • 合格基準を明確にすることができます
  • 依存関係を特定して調査することができます
  • アイテムはさらに発見と分析が必要な場合があります
  • 優先順位が変更された可能性があります。期待される収益は今では異なります

洗練とは、スプリント計画のために開発者が明確かつ実行できるように、アイテムが適切に準備および順序付けされることを意味します。

バックログには、技術的負債(設計債務またはコード債務とも呼ばれます)も含まれる場合があります。これはソフトウェア開発の概念であり、より長い時間がかかるより良いアプローチを使用するのではなく、今すぐ簡単なソリューションを選択することによって引き起こされる追加のやり直しの暗黙のコストを反映しています。

バックログの改善時に、チームのスプリント容量の最大10%を投資することをお勧めします[3] 。より成熟したチームは、これをスケジュールされた定義済みのイベントとしてではなく、自然なワークフローの一部を形成し、必要に応じて製品のバックログを調整および調整するアドホックなアクティビティと見なします。

スプリントのキャンセル

プロダクトオーナーは、必要に応じてスプリントをキャンセルでき[3]、他の人(開発者、スクラムマスター、または管理者)からの入力によってキャンセルできます。たとえば、最近の外部の状況はスプリントの目標の価値を否定する可能性があるため、継続することは無意味です。

スプリントが異常終了した場合、次のステップは、終了の理由を検討する新しいスプリント計画を実施することです。

アーティファクト

アーティファクトとは、プロジェクトの作業を管理するために使用されるドキュメントを指します。

製品バックログ

製品バックログは、実行する作業の内訳であり、チームが製品に対して維持する製品要件の順序付きリストが含まれています。バックログアイテムの一般的な形式には、ユーザーストーリーユースケースが含まれます。[40]これらの要件は、機能バグ修正非機能要件などを定義します—実行可能な製品を提供するものは何でも。プロダクトオーナーは、リスク、ビジネス価値、依存関係、サイズ、必要な日付などの考慮事項に基づいて、プロダクトバックログアイテム(PBI)に優先順位を付けます。

製品バックログは「必要なもの、必要なときに注文する」であり、すべての人に表示されますが、製品バックログアイテムの管理と保守を担当する製品所有者の同意がある場合にのみ変更できます。

製品バックログには、製品所有者によるビジネス価値の評価が含まれ、チームによる労力または複雑さの評価が含まれる場合があります。多くの場合、常にではありませんが、丸められたフィボナッチスケールを使用してストーリーポイントで示されます。これらの見積もりは、製品所有者がタイムラインを測定するのに役立ち、製品バックログアイテムの注文に影響を与える可能性があります。たとえば、同じビジネス価値を持つ2つの機能の場合、製品所有者は、開発努力が少ない(投資収益率が高いため)または開発努力が高い(複雑またはリスクが高いため)作業の早期配信をスケジュールできます。 、そして彼らはそのリスクを早期に撤回したいと考えています)。[45]

製品バックログおよび各製品バックログアイテムのビジネス価値は、製品所有者の責任です。各アイテムを納品するための労力は、ストーリーポイントまたは時間で見積もることができます。ストーリーポイントで見積もることにより、チームは個々の開発者の依存を減らします。これは、開発者がスプリントの配信後に他の作業に割り当てられることが多い動的なチームに特に役立ちます。たとえば、ユーザーストーリーが(フィボナッチ数列を使用して)5の努力であると推定された場合、それに取り組んでいる開発者の数に関係なく、5のままです。

ストーリーポイントはタイムボックス内の作業を定義するため、時間とともに変化することはありません。たとえば、1時間で個人は歩いたり、走ったり、登ったりできますが、費やされる労力は明らかに異なります。フィボナッチ数列の用語間のギャップの進行により、チームは慎重に検討された見積もりを提供するようになります。1、2、または3の見積もりは、同様の取り組み(1は些細なことです)を意味しますが、チームが8または13(またはそれ以上)を見積もった場合、配信と予算の両方に大きな影響を与える可能性があります。ストーリーポイントを使用することの価値は、チームが以前のスプリントからの同様の作業を比較することによってストーリーポイントを再利用できることですが、見積もりはそのチームに関連していることを認識しておく必要があります。たとえば、あるチームの見積もりが5の場合、より高い能力を持つ経験豊富な開発者で構成される別のチームの見積もりは2になります。

多くの場合、製品の所有者は複数のチームと協力することができますが、すべてのチームには製品の所有者が必要です。[28]製品の所有者は、製品の価値を最大化する責任があります。プロダクトオーナーは、多くの人々から意見を収集し、フィードバックを受け取り、ロビー活動を行いますが、最終的には何を構築するかについて最終決定を下します。

製品のバックログ:

  • 新機能、古い機能の置き換え、機能の削除、問題の修正など、製品を変更するためのリクエストをキャプチャします
  • 開発者が製品のビジネス上の利益を最大化する作業を確実に行えるようにします

通常、チーム全体が協力して製品のバックログを改善します。このバックログは、製品とその顧客に関する新しい情報が表面化するにつれて進化するため、後のスプリントで新しい作業に対処する場合があります。

管理

最も単純な形式の製品バックログは、作業するアイテムのリストにすぎません。作業の追加、削除、および順序付けの方法について確立されたルールがあると、チーム全体が製品の変更方法についてより適切な決定を下すのに役立ちます。[46]

プロダクトオーナーは、最も早く必要とされるアイテムに基づいて、プロダクトバックログアイテムに優先順位を付けます。開発者は、スプリントの目標に影響を受けて、次のスプリントのアイテムを選択し、それらのアイテムを製品のバックログから、作成するアイテムのリストであるスプリントのバックログに移動します。概念的には、スプリントの目標はリストの一番上にある優先度の高いアイテムの影響を受けますが、スプリント内にさらに多くの作業に対応する時間が残っている場合、開発者が優先度の低いアイテムを取得するのは珍しいことではありません。

優先度の高いアイテム(バックログの上部)は、開発者が作業するのに適した詳細に分割する必要があります。バックログが下がるほど、詳細な項目は少なくなります。SchwaberとBeedleが述べているように、「優先度が低いほど、バックログ項目がほとんどわからなくなるまで詳細が少なくなります」。[9]

チームがバックログを処理するとき、変化は環境の外で発生することを想定する必要があります。チームは、利用する新しい市場機会、発生する競合他社の脅威、および製品の意図を変える可能性のある顧客からのフィードバックについて学ぶことができます。働くために。これらの新しいアイデアはすべて、チームが新しい知識を組み込むためにバックログを適応させるきっかけとなる傾向があります。これは、アジャイルチームの基本的な考え方の一部です。世界は変わり、バックログは決して終わらない。[47]

スプリントバックログ

スプリントバックログは、開発者が次のスプリントで対処することを目的とした製品バックログのアイテムのサブセットです。[48]開発者は、スプリントを埋めるのに十分な作業があると感じるまでこのバックログを埋め、過去のパフォーマンスを使用して次のスプリントの容量を評価し、これを完了できる「努力」のガイドラインとして使用します。

スプリントバックログの作業が開発者に割り当てられる(またはプッシュされる)ことはありません。チームメンバーは、バックログの優先順位と自分のスキルと能力に応じて、必要に応じて作業を引き出します。これにより、開発者の自己組織化が促進されます。

スプリントバックログは開発者の所有物であり、含まれているすべての見積もりは開発者によって提供されます。スクラムの一部ではありませんが、一部のチームは付属のボードを使用して、現在のスプリントでの作業の状態を視覚化します:ToDo、Doing、Done。

インクリメント

増分は、スプリントの目標を満たすスプリントの潜在的にリリース可能な出力ですこれは、完了したすべてのスプリントバックログアイテムから形成され、以前のすべてのスプリントの作業と統合されています。スクラムチームのdone(DoD)の定義に従って、増分は完了し、完全に機能し、製品の所有者が実際に展開して使用することを決定したかどうかに関係なく、使用可能な状態である必要があります。

拡張機能

次のアーティファクトとテクニックは、人々がスクラムを使用するのを助けるために使用できます。[3]

バーンダウンチャート

完了したスプリントのサンプルバーンダウンチャート。1日の終わりの残りの努力を示しています。

スクラム(スクラムの一部ではない)でよく使用されるバーンダウンチャートは、残りの作業を示す公開されたチャートです。[49]毎日更新され、参照用の迅速な視覚化を提供します。バーンダウンチャートの横軸は残り日数を示し、縦軸は1日あたりの残りの作業量を示します。

スプリント計画中に、理想的なバーンダウンチャートがプロットされます。次に、スプ​​リント中に、開発者は残りの作業でチャートを更新し、チャートが毎日更新されるようにして、実際と予測の比較を示します。

アーンドバリューチャートと混同しないでください

バーンアップチャートをリリース

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

リリースバーンアップチャートは、チームが可視性を提供し、リリースに向けた進捗状況を追跡するための方法です。各スプリントの最後に更新され、予測範囲の提供に向けた進捗状況を示します。リリースバーンアップチャートの横軸はリリース内のスプリントを示し、縦軸は各スプリントの終了時に完了した作業の量を示します(通常は完了した作業の累積ストーリーポイントを表します)。進捗状況は、予測範囲を表す水平線に一致するように成長する線としてプロットされます。多くの場合、これまでの進捗状況に基づいて、特定のリリース日までに完了する可能性のあるスコープの量、または特定のスコープを完了するために必要なスプリントの数を示す予測が表示されます。

リリースバーンアップチャートを使用すると、完了した作業の量、追加または削除された作業の量(水平スコープラインが移動した場合)、および残りの作業量を簡単に確認できます。

準備完了(DoR)の定義

仕様と入力が作業項目を開始するのに十分明確に設定されている かどうかを判断するための開始基準。

完了の定義(DoD)

スプリントバックログアイテムの作業が完了したかどうかを判断するための終了基準。たとえば、国防総省では、すべての回帰テストが成功する必要があります。完了の定義はチームごとに異なる場合がありますが、1つのチーム内で一貫している必要があります。[50]

ベロシティ

最後のスプリントで完了した作業を評価することによって導き出された、単一のスプリントに対するチームの総能力努力。過去の速度データの収集は、チームが能力を理解するのを支援するためのガイドラインです。つまり、チームが快適に達成できる作業量です。

このメトリックは、スクラムコミュニティで論争を呼んでいます。

  • 消費されたストーリーポイントは、提供された価値と等しくありません。チームは、作業が完了したことを確認し、利害関係者への提供可能なメリットを無視する可能性があります
  • 気を散らす慣行の導入:推定と実際、分散調査と再推定の方針が生じ始めます
  • 経営陣は速度をパフォーマンス指標と見なしているため、速度を上げようとしています。つまり、次のようになります。
    • 品質が低下します-チームは追加されたワークロードを含めるために「手抜き」を開始します
    • 士気が低下します-チームは快適で持続可能なペースで作業することができず、圧力の上昇は燃え尽き症候群を引き起こします
    • 見積もりが苦しむ-開発者は見積もりを膨らませてバッファを組み込み、「メトリクスをゲーム化」して、同じ努力を異なるスケールで測定します
    • 価値が損なわれる-最終的な影響は干渉であり、ビジネス価値の提供から焦点を切り替えた結果として、利害関係者の不満を引き起こします

チームの配信能力を理解することには価値がありますが、速度は、調整可能なダイヤルではなく、チームの指標と見なす必要があります。

スパイク

概念を調査したり、単純なプロトタイプを作成したりするために使用されるタイムボックス化された期間。スパイクはスプリントの間に発生するように計画することができます。または、大規模なチームの場合、スパイクは多くのスプリント配信目標の1つとして受け入れられる可能性があります。スパイクは、予算を確保したり、知識を拡大したり、概念実証を作成したりするために、大規模または複雑な製品バックログアイテムの配信前に導入されることがよくあります。スパイクの期間と目的は、開始前にチームによって合意されます。スプリントのコミットメントとは異なり、スパイクは具体的で出荷可能な価値のある機能を提供する場合と提供しない場合があります。たとえば、スパイクの目的は、行動方針の決定に成功することである可能性があります。時間切れになるとスパイクは終わりますが、必ずしも目的が達成されたときではありません。[51]

曳光弾

ドローンスパイクとも呼ばれるトレーサーの弾丸は、現在のアーキテクチャ、現在のテクノロジーセット、本番品質のコードをもたらす現在のベストプラクティスのセットを備えたスパイクです。これは機能の非常に狭い実装である可能性がありますが、使い捨てのコードではありません。これは本番品質であり、残りの反復はこのコードに基づいて構築できます。この名前は、弾丸の進路を見えるようにし、修正を可能にする弾薬としての軍事的起源を持っています。多くの場合、これらの実装は、単一のフォームの入力フィールドをバックエンドに接続するなど、アプリケーションのすべてのレイヤーを介した「クイックショット」であり、レイヤーが期待どおりに接続されていることを証明します。[52]

制限事項

スクラムの利点は、次の場合に達成するのがより難しい場合があります。[53] [54]

  • メンバーが地理的に分散しているチームまたはパートタイムのチーム:スクラムでは、開発者は緊密で継続的なやり取りを行う必要があります。理想的には、ほとんどの場合、同じスペースで一緒に作業します。テクノロジーの最近の改善により、これらの障壁の影響が軽減されましたが(たとえば、デジタルホワイトボードでのコラボレーションが可能になる)、アジャイルマニフェストは、最良のコミュニケーションは対面であると主張しています。[55]
  • メンバーが非常に専門的なスキルを持っているチーム:スクラムでは、開発者はT字型のスキルを持っている必要があり、専門外のタスクに取り組むことができます。これは、スクラムの優れたリーダーシップによって促進されます。非常に特殊なスキルを持つチームメンバーはうまく貢献できますが、他の分野についてもっと学び、協力するように奨励されるべきです。
  • 多くの外部依存関係を持つ製品:スクラムでは、製品開発を短いスプリントに分割するには、慎重な計画が必要です。ユーザーの受け入れテストや他のチームとの調整などの外部の依存関係は、個々のスプリントの遅延や失敗につながる可能性があります。
  • 成熟した製品、レガシー製品、または規制された品質管理を備えた製品:スクラムでは、製品の増分を完全に開発し、1回のスプリントでテストする必要があります。リリースごとに大量の回帰テストまたは安全性テスト(医療機器や車両制御など)を必要とする製品は、長いウォーターフォールリリースよりも短いスプリントには適していません。

利用可能なツール

他のアジャイルアプローチと同様に、スクラムの効果的な採用は、利用可能なさまざまなツールを通じてサポートできます(ただし、依存することはありません)。

多くの企業は、スプレッドシートなどのユニバーサルツールを使用して、スプリントバックログを作成および維持しています。製品開発にスクラム用語を使用したり、スクラムを含む複数の製品開発アプローチをサポートしたりするオープンソースのプロプライエタリソフトウェアパッケージもあります。

他の組織は、ソフトウェアツールを使用せずにスクラムを実装し、紙、ホワイトボード、付箋などのハードコピー形式でアーティファクトを維持しています。[56]

スクラム値

スクラムはフィードバック主導の経験的アプローチであり、すべての経験的プロセス制御と同様に、透明性、検査、および適応の3つの柱によって支えられています。スクラムフレームワーク内のすべての作業は、結果の責任者(プロセス、ワークフロー、進捗状況など)に表示される必要があります。これらを表示するには、スクラムチームは、開発中の製品とチームの状態を頻繁に検査する必要があります。働く。チームは頻繁に検査することで、作業が許容範囲を超えていることを発見し、プロセスまたは開発中の製品を適応させることができます。[27]

これらの3つの柱には、チームへの信頼と開放性が必要です。これにより、スクラムの次の5つの価値が可能になります。[3]

  1. コミットメント:チームメンバーは、すべてのスプリントでチームの目標を達成することを個別にコミットします。
  2. 勇気:チームメンバーは、自分たちが正しいことを行えるように、対立や課題を一緒に乗り越える勇気を持っていることを知っています。
  3. 焦点:チームメンバーは、チームの目標とスプリントのバックログにのみ焦点を合わせます。バックログ以外の作業は行わないでください。
  4. オープン性:チームメンバーとその利害関係者は、自分の仕事と直面する課題について透明性を保つことに同意します。
  5. 尊重:チームメンバーは、技術的に能力があり、善意を持って仕事をするためにお互いを尊重します。

適応

スクラムは、さまざまな目的を達成するためにさまざまな状況で使用されます。これらのさまざまな目的を達成するために、スクラムは頻繁に調整または適合されます。[57]スクラムは製品開発ライフサイクル全体をカバーしていないため、スクラムを適応させるための一般的なアプローチは、スクラムと他のソフトウェア開発方法論とのハイブリッド化です。したがって、組織は、より包括的な実装を作成するために、追加のプロセスを追加する必要があると考えています。たとえば、製品開発の開始時に、組織は通常、ビジネスケース、要件の収集と優先順位付け、初期の高レベルの設計、および予算とスケジュールの予測に関するプロセスガイダンスを追加します。[58]

スクラムを使用するさまざまな作成者やコミュニティも、特定の問題や組織にスクラムを適用または適応させる方法について、より詳細な手法を提案しています。多くの人が、これらの方法論的手法を「パターン」と呼んでいます。これは、アーキテクチャやソフトウェアのデザインパターンとの類推によるものです。[59] [60]

スクラムばん

スクラムバンは、スクラムとかんばんをベースにしたソフトウェア制作モデルですスクラムバンは、生産上の欠陥やプログラミングエラーなど、頻繁で予期しない作業項目を伴う製品のメンテナンスに特に適しています。このような場合、スクラムフレームワークの時間制限のあるスプリントは、チームや目の前の状況に応じて、スクラムの毎日のイベントやその他のプラクティスを適用できますが、あまりメリットがないと思われる場合があります。作業段階の視覚化と、未完成の作業と欠陥が同時に発生する場合の制限は、かんばんモデルでよく知られています。これらの方法を使用して、チームのワークフロー各作業項目またはプログラミングエラーの最小完了時間を可能にする方法で指示され、一方で、各チームメンバーが常に雇用されていることを保証します。[61]

作業の各段階を説明するために、同じスペースで作業するチームは、多くの場合、付箋紙または大きなホワイトボードを使用します。[62]分散型チームの場合、 AssemblaJiraAgiloなどのステージイラストソフトウェアを使用できます。

スクラムとかんばんの主な違いは、スクラムでは作業が一定時間続くスプリントに分割されるのに対し、かんばんでは作業の流れが継続することです。これは、各スプリントの後にスクラムで空になる作業段階のテーブルに表示されますが、かんばんでは、すべてのタスクが同じテーブルにマークされます。スクラムは多面的なノウハウを持つチームに焦点を当てていますが、かんばんは専門的で機能的なチームを可能にします。[61]

スクラムのスクラム

スクラムのスクラムは、同じ製品に取り組んでいる複数のチームのためにスクラムを大規模に運用する手法であり、ソフトウェアの提供を調整する方法[63] 、特に重複と統合の領域に焦点を当てて、相互依存性の進捗状況について話し合うことができます。スクラムのスクラムのリズム(タイミング)に応じて、各スクラムチームに関連する毎日のスクラムは、他のチームのアンバサダーと一緒にスクラムのスクラムに参加するアンバサダーとして1人のメンバーを指定することで終了します。状況に応じて、アンバサダーは技術的な貢献者または各チームのスクラムマスターになる場合があります。[63]

単に進捗状況を更新するのではなく、スクラムのスクラムは、特定されたリスク、障害、依存関係、および仮定(RIDA)を解決、軽減、または受け入れるためにチームがどのように集合的に取り組んでいるかに焦点を当てる必要があります。スクラムのスクラムは、リスクボード(解決、所有、承認、および軽減されたイニシャルの後にROAMボードと呼ばれることもあります)などの独自のバックログを介してこれらのRIDAを追跡します[64]。チーム間のコラボレーション。[63]

これは毎日のスクラムと同じように実行され、各アンバサダーは次の4つの質問に答えます。[65]

  • 私たちが最後に会って以来、あなたのチームはどのようなリスク、障害、依存関係、または仮定を解決しましたか?
  • 私たちが再び会う前に、あなたのチームはどのようなリスク、障害、依存関係、または仮定を解決しますか?
  • チームの速度を低下させたり、邪魔をしたりする新しいリスク、障害、依存関係、または仮定はありますか?
  • 別のチームの邪魔になる新しいリスク、障害、依存、または仮定を導入しようとしていますか?

ジェフ・サザーランドがコメントしたように、[ 63]

私はもともとスクラムオブスクラムを定義していたので(ケンシュウェイバーはIDXで一緒に働いていました)、スクラムオブスクラムは「メタスクラム」ではないと断言できます。私が使用したスクラムのスクラムは、すべてのチームの作業ソフトウェアをスプリントの最後に完了の定義に配信するか、スプリント中にリリースする責任があります。PatientKeeperは、スプリントごとに4回本番環境に配信されました。Ancestry.comは、2週間のスプリントごとに220回本番環境に配信します。Hubspotは、ライブソフトウェアを1日に100〜300回配信します。スクラムマスターのスクラムは、この作業を行う責任があります。したがって、スクラムオブスクラムは運用可能な配信メカニズムです。

大規模スクラム

大規模スクラム(LeSS)は、スクラムの本来の目的を失うことなく、スケーリングルールとガイドラインを使用してスクラムを拡張する製品開発フレームワークです。

フレームワークには2つのレベルがあります。最初のLeSSレベルは、最大8チーム用に設計されています。「LeSSHuge」として知られる第2レベルでは、最大数百人の開発者による開発のための追加のスケーリング要素が導入されます。「スクラムのスケーリングは、標準の実際の1チームスクラムを理解して採用できるようにすることから始まります。大規模スクラムでは、単一チームスクラム要素の目的を調べ、標準スクラムの制約内にとどまりながら同じ目的を達成する方法を理解する必要があります。ルール。」[66]

BasVoddeとCraigLarman、特に通信業界と金融業界で大規模な製品開発に携わった経験からLeSSフレームワークを進化させました。それは、スクラムを取り、何が機能するかを発見するために多くの異なる実験を試みることによって進化しました。2013年に、実験はLeSSフレームワークルールに固められました。[67] LeSSの目的は、組織の複雑さを「縮小」し、不要な複雑な組織ソリューションを解消し、より簡単な方法でそれらを解決することです。より少ない役割、より少ない管理、より少ない組織構造。[68]

批判

スクラムは、主に概念を十分に適用していないが同じ結果を期待している人、またはスクラムに必要な文化的変化を誤解している人によって何度も攻撃を受けています[要出典]

  • スクラムイベントは生産性を損ない、実際の生産的なタスクにより多く費やすことができる時間を浪費していると報告されており[ 69 ] [ 70]、通常はイベントの目的と目標の誤解によって引き起こされます[71]。簡単な時間枠のある議論ではなく、会議。
  • スクラムの実践は、アジャイルマニフェストの精神に正しく従わない場合、マイクロマネジメントの一形態になり[72]、実践が取り除こうとしたのと同じ機能障害を再導入する傾向があります。
  • スクラムはまた、作業を完了するために必要な労力を正確に見積もることができると想定していますが、これは非常に予測できないことがよくあります。[73]
  • スクラムは、経験的分析と実験の自由を促進するために、規範的な慣行[74]を意図的に省略しています。
  • スクラムは、プロジェクトを管理するための代替アプローチではなく、一種であると認識されています[要出典]
  • スクラムへの最初の進出は、すぐに高品質の結果を生み出すことはありません。焦りはスクラムを埋め込んで成長させるチャンスを奪います[要出典]

スクラムへの一般的な機能不全のアプローチ[75]は、ダークスクラム[76]やスクリーム[77]などのアンチパターンとして認識されています。

も参照してください

参照

  1. ^ Schwaber、ケン; サザーランド、ジェフ(2017年11月)、スクラムガイド:スクラムの決定的なガイド:ゲームのルール、 2020年5月13日取得
  2. ^ 「学んだ教訓:非技術チームでのスクラムの使用」アジャイルアライアンス2019年4月8日取得
  3. ^ a b c d e f g h i j Ken Schwaber ; ジェフサザーランド「スクラムガイド」Scrum.org 2017年10月27日取得
  4. ^ 「アーカイブされたコピー」(PDF)2021年2月9日にオリジナル(PDF)からアーカイブされました2021年4月7日取得 {{cite web}}: CS1 maint: archived copy as title (link)
  5. ^ 竹内弘高と野中郁次郎による「新新製品開発ゲーム」(1986)
  6. ^ 「スクラム、名前には何が含まれていますか?-DZoneアジャイル」dzone.com
  7. ^ 「「SCRUM」はすべて大文字で書くべきですか?」stackoverflow.com 2017年1月10日取得
  8. ^ 「Scrum.orgケンシュウェイバー」2022年2月13日取得
  9. ^ a b c d e f Schwaber、Ken(2004年2月1日)。スクラムによるアジャイルプロジェクト管理MicrosoftPressISBN 978-0-7356-1993-7
  10. ^ Schwaber、Ken(2004)。「スクラム開発プロセス」(PDF)高度な開発方法
  11. ^ ジョンソン、ヒラリールイーズ(2011年1月13日)。「スクラムマスターvsスクラムマスター:どう思いますか?」agilelearninglabs.com 2017年5月10日取得
  12. ^ 「スクラムとは何ですか?」スクラムとは何ですか?複雑なプロジェクトを完了するためのアジャイルフレームワーク-スクラムアライアンススクラムアライアンス2016年2月24日取得
  13. ^ Verheyen、Gunther(2013年3月21日)。「スクラム:方法論ではなくフレームワーク」ガンザー・ヴァーヘイエンガンザー・ヴァーヘイエン2016年2月24日取得
  14. ^ J.ヘンリーとS.ヘンリー。ソフトウェア保守プロセスと要件の変動性の定量的評価。Proc。コンピュータサイエンスに関するACM会議の報告、346〜351ページ、1993年。
  15. ^ a bc竹内 弘高 ; 野中郁次郎(1986年1月1日)。「新製品開発ゲーム」ハーバードビジネスレビュー2010年6月9日取得スクラムダウンフィールドの移動
  16. ^ 知識創造会社オックスフォード大学出版局。1995.p。3.ISBN _ 97801997623302013年3月12日取得
  17. ^ 「スクラム」LexicoUK英語辞書オックスフォード大学出版局nd
  18. ^ a b サザーランド、ジェフ(2004年10月)。「アジャイル開発:最初のスクラムから学んだ教訓」2014年6月30日にオリジナル(PDF)からアーカイブされました2008年9月26日取得
  19. ^ a b サザーランド、ジェフリービクター; ケン・シュウェイバー(1995)。ビジネスオブジェクトの設計と実装:OOPSLA'95ワークショップの議事録ミシガン大学p。118. ISBN 978-3-540-76096-2
  20. ^ 「アジャイルソフトウェア開発のためのマニフェスト」2019年10月17日取得
  21. ^ Schwaber、ケン; ビードル、マイク(2002)。スクラムを使用したアジャイルソフトウェア開発プレンティスホール。ISBN 978-0-13-067634-4
  22. ^ Maximini、Dominik(2015年1月8日)。スクラムカルチャー:組織におけるアジャイル手法の紹介専門家のための管理。チャム:スプリンガー(2015年公開)。p。26. ISBN 97833191182772016年8月25日取得ケンシュウェイバーとジェフサザーランドは、1995年にテキサス州オースティンで開催されたOOPSLAカンファレンスで初めてスクラムを発表しました。[...] 2001年、スクラムに関する最初の本が出版されました。[...] 1年後(2002年)、ケンはスクラムアライアンスを設立し、世界中でスクラムのトレーニングと認定を提供することを目指しました。
  23. ^ 「ホーム」Scrum.org 2020年1月6日取得
  24. ^ Partogi、Joshua(2013年7月7日)。「認定スクラムマスターvsプロフェッショナルスクラムマスター」リーンアジャイルインスティテュート2017年5月10日取得
  25. ^ a b McGreal、Don; ジョチャム、ラルフ(2018年6月4日)。プロのプロダクトオーナー:競争上の優位性としてのスクラムの活用アディソン-ウェスリープロフェッショナル。ISBN 9780134686653
  26. ^ ルービン、ケネス(2013)、エッセンシャルスクラム。最も人気のあるアジャイルプロセスの実用ガイド、Addison-Wesley、p。173、ISBN 978-0-13-704329-3
  27. ^ a b c d Morris、David(2017)。スクラム:アジャイルプロジェクトのための理想的なフレームワーク簡単な手順で。pp。178–179。ISBN 9781840787313OCLC951453155 _
  28. ^ a b c コーン、マイク。アジャイルで成功する:スクラムを使用したソフトウェア開発。ニュージャージー州アッパーサドルリバー:アディソン-ウェスリー、2010年。
  29. ^ 「スクラムガイド」(PDF)
  30. ^ スクラムガイド(PDF)p。6.6。
  31. ^ 「プロダクトオーナーの役割」スクラムアライアンス2018年5月26日取得
  32. ^ Pichler、Roman(2010年3月11日)。スクラムによるアジャイル製品管理:顧客が愛する製品の作成アディソン-ウェスリープロフェッショナル。ISBN 978-0-321-68413-4
  33. ^ アンブラー、スコット。「プロダクトオーナーの役割:アジャイルチームの利害関係者の代理人」agilemodeling.com 2016年7月22日取得[...]実際には、この役割には2つの重要な側面があります。1つは開発チーム内の利害関係者の代理人として、もう1つは利害関係者コミュニティ全体のプロジェクトチーム代表としてです。
  34. ^ 「プロダクトオーナーの役割」スクラムマスターテスト準備2017年2月3日取得
  35. ^ Rad、Nader K .; ターリー、フランク(2018)。アジャイルスクラムファンデーションコースウェア、第2版セルトーヘンボス、オランダ:ヴァンハーレン。p。26. ISBN 9789401802796
  36. ^ キャロル、N、オコナー、M。およびエジソン、H。(2018)。ソフトウェアフローの障害の特定と分類、情報システムに関するアメリカ会議(AMCIS 2018)、8月16〜18日、米国ルイジアナ州ニューオーリンズ。
  37. ^ 「コアスクラム」スクラムアライアンス2015年1月25日取得
  38. ^ a b ドロンゲレン、マイク・ヴァン; デニス、アダム; ガラベディアン、リチャード; ゴンザレス、アルベルト; クリシュナスワミー、アラヴィンド(2017)。リーンモバイルアプリの開発:リーンスタートアップの方法論を適用して、成功するiOSおよびAndroidアプリを開発します英国バーミンガム:Packt PublishingLtd.p。43. ISBN 9781786467041
  39. ^ コブ、チャールズG.(2015)。アジャイルをマスターするためのプロジェクトマネージャーのガイド:適応アプローチの原則と実践ニュージャージー州ホーボーケン:John Wiley&Sons。p。37. ISBN 9781118991046
  40. ^ abc ピート ディー マー; ガブリエルベネフィールド; クレイグラーマン; Bas Vodde(2012年12月17日)。「スクラム入門書:スクラムの理論と実践への軽量ガイド(バージョン2.0)」InfoQ。
  41. ^ 「デイリースクラムとは何ですか?」Scrum.org 2020年1月6日取得
  42. ^ リトル、ジョー(2011年1月17日)。「ImpedimentManagement」アジャイルコンソーシアム。 {{cite journal}}: Cite journal requires |journal= (help)
  43. ^ Flewelling、ポール(2018)。アジャイル開発者ハンドブック:ソフトウェア開発からより多くの価値を得る:アジャイル方法論を最大限に活用します英国バーミンガム:Packt PublishingLtd.p。91. ISBN 9781787280205
  44. ^ マッケナ、デイブ(2016)。スクラムの芸術:スクラムマスターが開発チームをバインドし、敏捷性を解き放つ方法ペンシルベニア州アリクイッパ:CA Press p。126. ISBN 9781484222768
  45. ^ ヒギンズ、トニー(2009年3月31日)。「アジャイル世界でのオーサリング要件」BAタイムズ。
  46. ^ 「製品バックログ:あなたの究極のやることリスト」アトラシアン2016年7月20日取得
  47. ^ ピヒラー、ローマ人。スクラムによるアジャイル製品管理:顧客が愛する製品の作成ニュージャージー州アッパーサドルリバー:アディソン-ウェスリー、2010年。 [確認するには見積もりが必要]
  48. ^ ラス・J・マルティネリ; Dragan Z. Milosevic(2016年1月5日)。プロジェクト管理ツールボックス:プロジェクトマネージャーを実践するためのツールとテクニックワイリー。p。304. ISBN 978-1-118-97320-2
  49. ^ チャールズG.コブ(2015年1月27日)。アジャイルをマスターするためのプロジェクトマネージャーのガイド:適応アプローチの原則と実践ジョン・ワイリー&サンズ。p。378. ISBN 978-1-118-99104-6
  50. ^ Ken Schwaber、スクラムを使用したアジャイルプロジェクト管理、p.55
  51. ^ 「スパイクソリューションの作成」エクストリームプログラミング。
  52. ^ スターリング、クリス(2007年10月22日)。「研究、スパイク、曳光弾、オーマイ!」アジャイルを取得します。2016年10月23日取得
  53. ^ トルコ人、ダン; フランス、ロバート; Rumpe、Bernhard(2014)[2002]。「アジャイルソフトウェアプロセスの制限」。ソフトウェア工学におけるエクストリームプログラミングと柔軟なプロセスに関する第3回国際会議の議事録:43–46。arXiv1409.6600
  54. ^ 「スクラム実装の問題と課題」(PDF)科学技術研究の国際ジャーナル3(8)。2012年8月2015年12月10日取得
  55. ^ ケントベック; ジェームス・グレニング; ロバートC.マーチン; マイクビードル; ジムハイスミス; スティーブメラー; Arie van Bennekum; アンドリューハント; ケンシュウェイバー; アリスターコーバーン; ロン・ジェフリーズ; ジェフサザーランド; ウォードカニンガム; ジョン・カーン; デイブトーマス; マーティンファウラー; ブライアンマリック(2001)。「アジャイルマニフェストの背後にある原則」アジャイルアライアンス2017年8月7日取得
  56. ^ Dubakov、Michael(2008)。「アジャイルツール。良いもの、悪いもの、そして醜いもの」(PDF)2010年8月30日取得
  57. ^ Hron、Michal; Obwegeser、Nikolaus(2022年1月1日)。「スクラムが実際に適応されている理由と方法:系統的レビュー」ジャーナルオブシステムズアンドソフトウェア183111110。doi10.1016/j.jss.2021.111110ISSN0164-1212_ 
  58. ^ Hron、M .; Obwegeser、N.(2018年1月)。「実際のスクラム:スクラム適応の概要」(PDF)2018年1月3〜6日、システムサイエンスに関する2018年第51回ハワイ国際会議(HICSS)の議事録
  59. ^ Bjørnvig、Gertrud; コプリエン、ジム(2008年6月21日)。「組織パターンとしてのスクラム」Gertrude&Cope。
  60. ^ 「スクラムパターンコミュニティ」ScrumPLoP.org 2016年7月22日取得
  61. ^ a b Kniberg、Henrik; Skarin、Mattias(2009年12月21日)。「かんばんとスクラム-両方を最大限に活用する」(PDF)InfoQ 2016年7月22日取得
  62. ^ Ladas、Corey(2007年10月27日)。「スクラムばん」リーンソフトウェアエンジニアリング。2018年8月23日にオリジナルからアーカイブされました2012年9月13日取得
  63. ^ a bcd 「スクラムのスクラムアジャイルアライアンス。2015年12月17日。2014年2月9日のオリジナルからアーカイブ2013年12月17日取得
  64. ^ 「リスク管理–リスクがプロジェクトを台無しにするのを防ぐ方法!」ケリーウォーターズ。
  65. ^ 「スクラムのスクラム」スクラムマスターテスト準備2015年5月29日取得
  66. ^ ラーマン; scrumyear=2013。「アジャイル開発のスケーリング(クロストークジャーナル、2013年11月/ 12月)」(PDF)
  67. ^ 「大規模スクラム(LeSS)」2014年。
  68. ^ Grgic(2015)。「LeSS(ブログ)で組織を説明する」
  69. ^ ジェンソン、ジョン(2019年3月8日)。「会議:開発者にとっての生産性のキラー」TandemSeven-エクスペリエンスイノベーションカンパニー2020年6月5日取得
  70. ^ 「すべての開発者がアジャイルを好むわけではありません。ここに5つの理由があります」ビジネス上の問題2019年12月4日2020年6月5日取得
  71. ^ 「毎日のスクラムの5つの機能不全」Scrum.org 2021年7月3日取得
  72. ^ オン、IsaakTsalicoglou。「アジャイルからマイクロマネジメントに移行する方法|ハッカー正午」hackernoon.com 2020年6月5日取得
  73. ^ ケーグル、カート。「アジャイルの終わり」フォーブス2020年6月5日取得
  74. ^ James(MJ)、Michael(2021年3月29日)。「ケン・シュウェイバーが意図的にスクラムから省略しているもの」シアトルスクラムカンパニー2021年7月3日取得
  75. ^ Derecskey、Dave(2018年7月18日)。「5つの一般的なチームの機能不全(および5つのコアスクラム値がそれらに直接対処する方法)」ミディアム2021年7月3日取得
  76. ^ 「ダークスクラム」ronjeffries.com 2021年7月3日取得
  77. ^ 「悲鳴ガイド」Googleドキュメント2021年7月3日取得

さらに読む

外部リンク