敏捷開発（スクラムガイド）
2025-02-10 15:35:59 52 0 報告 0
0
ログインして完全な内容を表示
著者の他の作品
概要/内容
スクラムの定義
Scrum は、複雑で適応的な課題を解決するためのフレームワークであり、同時に効率的かつ創造的に最高の価値を提供しうる製品を届けることができます。
特徴
軽量の
理解しやすい
習得が難しい
構成
Scrum フレームワークは Scrum チームと、それに付随する役割、イベント、アーティファクト、およびルールで構成されています。フレームワーク内の各部分にはそれぞれ特定の目的があり、Scrum の成功と使用において非常に重要です。
規則
Scrumのルールは、役割、イベント、アーティファクトを組み合わせて管理し、それらの間の関係と相互作用を整理します。
スクラムアプリケーション
1. 市場、技術、製品能力の研究と識別を実行可能に；
2. 製品を開発し、機能を強化する；
3. 製品と機能強化、一日に何度もリリースされるほど頻度が高い；
4. クラウド（オンライン、安全、オンデマンド）およびその他の実行環境の開発とサポートを提供して製品を使用できるようにする；
5. 製品のサポートとアップデートを提供します。
スクラム理論
経験主義に基づく経験的プロセス制御理論
三大支柱
透明
プロセスの中の重要な段階は、生産に責任を持つ人々にとって明らかでなければなりません。透明性を持つためには、これらの重要な段階に対して統一された基準を設ける必要があります。そうすれば、これらの段階に注意を払うすべての人が観察された事象に対して統一された理解を持つことができます。
検査
Scrumの利用者は、ScrumのアーティファクトとSprint目標の進捗を定期的に点検し、不必要な違いを発見する必要があります。点検が仕事自体を妨げるほど頻繁であってはなりません。熟練した点検者が勤勉に点検を行うとき、その効果は最高です。
適応
検査者がプロセスの一つ以上の側面が許容範囲を超えており、製品が受け入れ不可能になる場合、プロセスまたはプロセス内容を調整する必要があります。調整作業は、さらなる逸脱を最小限に抑えるために、できるだけ早く実行する必要があります。
四つのイベント
スプリント計画会議
毎日のスクラムスタンドアップ
スプリント 評価会議
スプリント レビュー会議
スクラム 価値観
約束
勇気
集中
オープン
尊重
スクラムチーム
PO（プロダクトオーナー）
責任
開発チームが開発した製品の価値を最大化する
製品のタスク管理における唯一の責任者
製品のタスクリスト項目を明確に説明する；
製品のタスクリストアイテムを並べ替えて、目標と使命を最大限に実現できるようにする。
開発チームが実行する仕事の価値を最適化する；
製品のタスク一覧を全ての人に見やすく、透明で明確にすること、同時に Scrum チームが次に行うべき仕事が表示されるようにすること；
開発チームが製品のタスク一覧項目について十分な理解を持っていることを確実にします。
PDT（プロダクト開発チーム）
構成
開発チームにはさまざまな専門家が含まれており、各スプリントの終了時に潜在的にリリース可能であり「完了」している製品の増分を納品することを担当しています。スプリントレビュー会議では、「完了」した増分が必要です。増分を作成できるのは開発チームメンバーだけです。
特徴
自己組織化された
クロスファンクショナルなチーム
開発チームメンバーのいかなる肩書きも認めない
開発チームにおけるいわゆる"子チーム"を認めない
開発チームの各メンバーにはそれぞれ得意分野や専門領域があるかもしれませんが、責任は整個開発チームに属しています。
規模
（3，9]
SM（スクラムマスター）
サーバント・リーダーシップ
スクラムチームが生み出す価値を最大化する
プロダクト責任者へのサービス
スクラムチームのメンバー全員が、目標、範囲、および製品領域をできるだけ理解していることを確実にします。
効果的な製品のタスク管理のコツを見つける
スクラムチームがなぜ明確で簡潔なプロダクトバックログアイテムが必要なのかを理解するのを助ける
経験主義的な環境における製品計画の理解
製品責任者が製品のタスク一覧をどのように整理して最大限の価値を達成するかを理解していることを確実にしなければなりません。
理解し、敏捷性を実践する
リクエストされた時や必要になった時には、スクラムイベントを誘導する。
開発チームへのサービス
開発チームに対して、自組織化とクロスファンクションの面で指導を与えるコーチとして。
開発チームを支援し、高価値の製品を創造する
開発チームの仕事の進捗における障害を取り除く
リクエストされた時または必要に応じて、スクラムイベントを誘導する
スクラムが完全に採用され理解されていない組織環境において、開発チームを指導するコーチとして
組織に奉仕する
リードしてコーチとして組織にScrumを採用する
組織内でスクラムの実施を計画する
従業員と利害関係者に理解し、実施してもらうためのスクラムと経験主導型の製品開発
スクラムチームの生産性を向上させる変化を引き起こす
他のスクラムマスターと一緒に働き、組織におけるスクラムの有効性を高める。
スクラムイベント
効果
一定のイベントを使用して規則性を生み出し、それによってスクラム以外の他の会議の必要性を減らす。
スクラムにおける各イベントは、検査と適応を行うための正式な機会です。
スプリント
SprintはScrumの核心であり、[2週間、4週間]、長さは一定に保たれます。
構成
スプリント計画会議
毎日のスクラムスタンドアップ
開発作業
スプリント 評価会議
スプリント レビュー会議
要求
Sprintの目標に害を及ぼす変更は行うことができません。
質を落とさない目標
情報の掌握が増えるにつれて、プロダクトオーナーと開発チームは、やるべきことの範囲について明確化し、再交渉することができます。
各スプリントはプロジェクトとして見なすことができます。
Sprintの長さは1ヶ月以内に制限されています。
キャンセル スプリント
スプリント時間枠が終了する前に取り消す
製品の責任者だけがSprintをキャンセルする権利を持っています
あるスプリントがその環境にとって価値や意味を失った場合、それは取り消されるべきです。
スプリントの期間が非常に短いため、スプリントをキャンセルすることは通常あまり合理的ではありません。
評価の再検討
重大な打撃を与える
スプリント計画会議
は整個な Scrum チームの共同協力によって完成された
時間枠で制限されています
機能（以下の質問に答えてください）
次のスプリントで納品される増分には何が含まれるべきですか？
プロダクトオーナーがSprintの目標とその目標を達成するために完了する必要があるプロダクトバックログアイテムについて説明します。全体のScrumチームが協力してSprintの仕事を理解するために働きます。
Sprint 会議の入力
製品のタスクリスト
最新の製品増分
開発チームがこの スプリント での能力の予測
開発チームの過去の実績
草拟スプリント目標
どのように増分の納品に必要な作業を完了させるか？
スプリント待機リスト
選択された製品のタスクリスト項目
どのようにそれらを納品する計画ですか
作業量の予測
計画作業
自主的に受け取る
製品責任者は、選択された製品のタスクリスト項目を明確に説明し、バランスを取ることができることが期待されています。
どのように完了するかを説明する
スプリント目標
現在のスプリントで、製品のバックログを実現することにより達成すべき目的
開発チームに指針を提供する
開発チームがSprintで実現した機能に一定の弾力性を残す
選択された製品のタスクリスト項目は、一貫性のある機能を提供します。
もし必要な作業が予想と異なる場合、開発チームはプロダクトオーナーとコミュニケーションを取り、Sprintのタスクリストの範囲について協議する必要があります。
毎日のスクラムスタンドアップ
期間中毎日15分
昨日の成果を検証する
本日の計画を報告する
問題が発生した場合
効果
会議で解決されない
スプリント 評価会議
スプリントの終わりに開催する
機能：納品された製品の増分を検証し、必要に応じて製品のタスクリストを調整する。
デモ増分
時長：≤4時間
含む内容
参加者は Scrum チームと、プロダクトオーナーが招待した主要な利害関係者を含みます
プロダクトオーナーがどのプロダクトのバックログアイテムが「完了」しており、どのアイテムがまだ「未完了」であるかを説明する。
開発チームはSprint期間中にどの作業がうまくいったか、どのような問題に遭遇し、その問題がどのように解決されたかについて議論します。
開発チームは「完了」した作業をデモし、納品したインクリメントに関する質問に答えます。
プロダクトオーナーが現在のプロダクトバックログの状況について議論する
参加者全員が次の一歩の仕事について議論を行いました。
市場の評価や潜在的な製品の使用方法がもたらす、次に最も価値のある変化を行うこと。
次の予定製品機能または製品能力バージョンのリリース審査スケジュール、予算、潜在力、および市場
出力
改訂後の製品のタスクリスト
次のSprintにかなり入る可能性がある製品のバックログアイテムを明確にする
新しい機会を迎えるために全体的な調整を行う
スプリント レビュー会議
スクラムチームが自分自身を検証し、次のスプリントの改善計画を作成する機会です。
スプリント評価会議の終了後に起こり、次のスプリント計画会議の前に。
時長：≤3時間
目的
前のSprintにおける人々、関係、プロセス、およびツールの状況を検証する
良い点と潜在的な改善が必要な主要な方面を見つけ出し、それらを並べ替える。
スクラムチームの働き方を改善するための計画を策定する
スクラム アーティファクト
異なる方法で仕事の内容と価値を表現することで、透明性を提供し、検証と適応の機会を得ることができます。
製品のタスクリスト
製品に含まれる既知の必要事項を網羅した順序付きリストです。
永遠は不完全である
将来リリース予定の製品に対する更新に関するすべての特性、機能、要件、強化、および修正などを列挙する：説明、順序、見積もり、および価値
より大きく、より詳細なリストに成長します
製品のタスクリストアイテムをグループ化できる属性が必要になるかもしれません。
製品のバックログを精緻化するとは、製品のバックログアイテムに詳細、見積もり、並び替えの動作を追加することを指します。
ソート順が高い製品のタスクリスト項目は、一般的にソート順が低いものよりも明確で、より多くの詳細が含まれています。
開発チームが全ての見積もり作業を担当する
機能：目標達成の進捗を監視する
スプリントのタスク一覧
現在のSprintのために選ばれたプロダクトバックログアイテムのセットであり、製品のインクリメントの納品とSprint目標の達成のための計画を含む。
少なくとも前回のレビュー会議で決定された高優先度のプロセス改善を含むものとする
十分に詳細な計画
スプリント期間中は、開発チームのみがスプリントバックログを変更することができます。
機能：スプリント進捗の監視
増分
完成されたすべてのプロダクトバックログアイテムの合計、および以前のすべてのスプリントによって生み出されたインクリメントの価値の総和です。
スプリントの最後には、新しいインクリメントは「完了」している必要があります。これは、それが利用可能であり、スクラムチームの「完了」の定義の基準を達成していることを意味します。
増分はSprintの終わりに経験主義をサポートし、検査可能で、完了した製品の構成要素です。
増分はビジョンや目標への一歩です。製品責任者がそれをリリースするかどうかに関わらず、増分は利用可能でなければなりません。
集める
集める
集める
集める
0 コメント
次のページ
