スクラム ブートキャンプ for NII
講師 高江洲 睦氏(twitter,facebook: @takaesu0)
のお話の続き
Scrumって何?
のメモメモ
導入
・フレーワーク
3つのロール
4つのイベント
3つの成果物
それらの関係性や相互作用を統括するルール
→技術的なプラクティスはない
→XPとの併用になる
特徴
・軽量
・理解は容易
・習得は非常に困難
Scrumアライアンス
理解の低いところ:ワースト3-日本
大事なこと
・経験的(エンピリカル)にプロセスを制御する
・反復的、漸進的に進めていく
・3本柱を大切に
3本柱
・透明性:関係者全員が共通理解をもつ
・検査:障害検知、ゴールに向かっている?
・適応:プロセスを調節
ロール(ヒト)
・プロダクトオーナー
・開発チーム
・スクラムマスター
プロダクトオーナー
・Whatを探求するヒト
・プロダクトバックログ(PBI)の管理責任者
項目を明確に
優先順位付け(優先度(高がいっぱい)と優先順位(一列に)は違う)
価値を保証
プロダクトバックログの見える化
開発チームが理解できるように
開発チーム
・Howを探求する
・インクリメントを作成する
3~9人
自己組織化
職能横断的
専門家がいてもチーム全体の責任
スクラムマスター
・Scrumの番犬
・スクラムの理論、プラクティス、ルールを内外に守らせる
外部からのチームの盾となる
サーバントリーダー
ほかのロールを支援
スクラムイベントをファシリテート
ほかのロールの潤滑油
サーバントリーダーシップ
・傾聴
・共感
・いやし
・気づき
・納得(説得でなく)
・概念化
・先見力
・世話役
・人々の成長にかかわる
・コミュニティづくり
WhatとHow
Whatのじく:プロダクトオーナー
HOWのじく:開発チームが責任
理想はどちらも正
成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント
プロダクトバックログ
・ただひとつのプロダクトに対するバックログ
プロダクトに必要なものが順序付けされた一覧
優先順位の高いものは同じ大きさ
プロダクトオーナーにより管理される
バグ、技術的課題を含む
各項目は、ユーザーストーリーの書式を使用することが多い
大きさは1日から数日
スプリント内で手入れ(グルーミング)される
直近の数スプリント分は詳細に
受け入れ条件を明確化
デモ手順
バックロググルーミング
・スプリント内で行うバックログの手入れ
スクラムチーム全員が参加
頻度やどう手入れを行うかはスクラムチームで決める
必要があれば見積もり
ユーザーストーリー
・<役割>として
・<機能や性能>がほしい
・それは、<ビジネス価値>のためだ
よいストーリー:INVEST
I独立してる
N交渉できる
V価値がある
E見積もれる
S適切な大きさ
T評価できる
スプリントバックログ
・WhatとHOWを結びつけるもの
プロダクトバックログ項目をインクリメントにする契約をまとめたもの
開発チームによって管理される
必要なタスクをすべて見える化
タスクボード
バーンダウンチャート
残作業の見積もりを日々更新
タスクは誰が担当してもいい
むしろ、固定化は悪
タスクボード
・Story
・ToDo
・Doing
・Done
タスク管理でよく使われる
模造紙やホワイトボードを使用
付箋がよく使われる
強粘着タイプ必須
地理的に分散した環境は、デジタルツールで
ふせんのはがしかた
X下からめくる→粘着面がそり、はがれやすくなる
○横にはがす
○上から下に引く
バーンダウンチャート
残作業管理の定番
スプリント内のタスクの合計残時間を記録
基準線と見比べて状況を把握
状況によってプロダクトオーナーと相談して調整
模造紙やホワイトボードを使用
地理的に分散した環境は、デジタルツールで
インクリメント
・スプリント終了時の増分
スプリントで完了したプロダクトバックログ項目の成果物
スプリントの終わりには完了しているべき
プロダクトオーナーにより受け入れられるか否かにかかわらず
常に動く状態
完了の定義
・作業の完了についての合意を見える化
→チェックリスト
Aさんの完了とBさんの完了が違っていたら?
成熟度によって、厳しさも異なる
更新されることもある
完了の定義例
テストコードがすべてパスしていること
コードレビューが済んでいる
:
:
妨害リスト→スクラムマスターが管理
・非公式だがよく知られたもの
・デイリースクラムなどであがった妨害のリスト
・スクラムマスターが管理、優先度の高い障害から取り除く
イベント
・スプリント計画ミーティング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ
イベントの特徴
・定義かされていないミーティングの必要性を最小化
・スプリントそのものを含め、すべてタイムボックス化
スプリント
・1週間から1ヶ月のタイムボックス
決めたら最後まで期間を変えないこと
・この間の変更受け入れは原則なし
スプリントの長さを決めるのに影響
なくはない(2週間でたまに?)
・途中で中止の可能性もある
POが権限をもつ
2Wスプリントの例
・スプリント計画ミーティング
月曜はじめ1部、2部
・デイリースクラム
毎日朝(ないし昼)
・スプリントレビュー
金曜終わり1つ前
・スプリントレトロスペクティブ
金曜終わり一番最後
スプリント計画ミーティング第一部
スクラムマスター(外)
プロダクトオーナー
開発チーム
プロダクトバックログ
プランニングポーカー
開発チームがスプリントで開発する機能を計画
スプリントの2.5%のタイムボックス
優先順位の高いバックログ項目を理解し
その大きさを見積もる
実績に基づいた収まる分量
ベロシティ
見積もり
基準を決めよう
整数で考える
まよったら大きいほう
見積もりの流れ
・1、2、3、5、8、13
準備
・優先順位の高いものから見て、簡単そうなものを2とする
・優先順位の高いものから見て、その倍ちかいものを5
流れ
1、優先順位の高いものから、
2と5と比べて決めていく
2、全員が同じ数字
3、全員がとなりあう数字になったら、大きいほうをポイントとして1へ
1回目でそろったら、念のため根拠をいう
4、一番大きな数字と小さな数字を出したヒトが根拠を
5、2に戻る
ベロシティ
・開発チームの生産量
各スプリントリームの生産量
・固定するパラメータに応じて可変するパラメータを予測できる
スプリント計画ミーティング第二部
・Whatの実現をHowに落とし込む
・プロダクトバックログ項目を完了にする方法を決定
→スプリントの2.5%のタイムボックス
スプリントバックログを作成
各タスクは1日以下の単位に分解
理想時間で見積もる
時間はチームのだいたいの平均
プロダクトオーナーの参加は任意
何かあったら聞けるところに
デイリースクラム
・タスクログ
・バーンダウンチャート
・日々の検査と適応の場
・毎日の情報共有
毎日定時15分以内
開発チームとスクラムマスター
話すこと3つ
前回のデイリースクラムからやったこと
次回のデイリースクラムまでにやること
困っていること
→進捗報告会ではない。今の状態をわかってもらう場
スクラムマスターはファシリテートするだけ
スプリントレビュー
・スプリントの検査と適応
インクリメントの検査を行う
スプリントの2.5%のタイムボックス
スクラムチーム全員参加
POやステークホルダーへのデモ
POが受け入れをきめる
スプリントレトロスペクティブ
次スプリントのカイゼン計画
スプリントの2.5%
スクラムチーム全員が参加
POは任意、いいづらければはずれる
うまくいった項目、改善点、改善案
KPT(けぷと)
KPT
・振り返りの定番
話し合うのは、次の3つ(付箋とか使う)
Keep
よかったこと、続けたいこと
Problem
よくなかったこと、カイゼンしたいこと
→Tryにあげていくように
Try
やってみたいこと、改善案
→あがりすぎたら、できることに絞る
講師 高江洲 睦氏(twitter,facebook: @takaesu0)
のお話の続き
Scrumって何?
のメモメモ
導入
・フレーワーク
3つのロール
4つのイベント
3つの成果物
それらの関係性や相互作用を統括するルール
→技術的なプラクティスはない
→XPとの併用になる
特徴
・軽量
・理解は容易
・習得は非常に困難
Scrumアライアンス
理解の低いところ:ワースト3-日本
大事なこと
・経験的(エンピリカル)にプロセスを制御する
・反復的、漸進的に進めていく
・3本柱を大切に
3本柱
・透明性:関係者全員が共通理解をもつ
・検査:障害検知、ゴールに向かっている?
・適応:プロセスを調節
ロール(ヒト)
・プロダクトオーナー
・開発チーム
・スクラムマスター
プロダクトオーナー
・Whatを探求するヒト
・プロダクトバックログ(PBI)の管理責任者
項目を明確に
優先順位付け(優先度(高がいっぱい)と優先順位(一列に)は違う)
価値を保証
プロダクトバックログの見える化
開発チームが理解できるように
開発チーム
・Howを探求する
・インクリメントを作成する
3~9人
自己組織化
職能横断的
専門家がいてもチーム全体の責任
スクラムマスター
・Scrumの番犬
・スクラムの理論、プラクティス、ルールを内外に守らせる
外部からのチームの盾となる
サーバントリーダー
ほかのロールを支援
スクラムイベントをファシリテート
ほかのロールの潤滑油
サーバントリーダーシップ
・傾聴
・共感
・いやし
・気づき
・納得(説得でなく)
・概念化
・先見力
・世話役
・人々の成長にかかわる
・コミュニティづくり
WhatとHow
Whatのじく:プロダクトオーナー
HOWのじく:開発チームが責任
理想はどちらも正
成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント
プロダクトバックログ
・ただひとつのプロダクトに対するバックログ
プロダクトに必要なものが順序付けされた一覧
優先順位の高いものは同じ大きさ
プロダクトオーナーにより管理される
バグ、技術的課題を含む
各項目は、ユーザーストーリーの書式を使用することが多い
大きさは1日から数日
スプリント内で手入れ(グルーミング)される
直近の数スプリント分は詳細に
受け入れ条件を明確化
デモ手順
バックロググルーミング
・スプリント内で行うバックログの手入れ
スクラムチーム全員が参加
頻度やどう手入れを行うかはスクラムチームで決める
必要があれば見積もり
ユーザーストーリー
・<役割>として
・<機能や性能>がほしい
・それは、<ビジネス価値>のためだ
よいストーリー:INVEST
I独立してる
N交渉できる
V価値がある
E見積もれる
S適切な大きさ
T評価できる
スプリントバックログ
・WhatとHOWを結びつけるもの
プロダクトバックログ項目をインクリメントにする契約をまとめたもの
開発チームによって管理される
必要なタスクをすべて見える化
タスクボード
バーンダウンチャート
残作業の見積もりを日々更新
タスクは誰が担当してもいい
むしろ、固定化は悪
タスクボード
・Story
・ToDo
・Doing
・Done
タスク管理でよく使われる
模造紙やホワイトボードを使用
付箋がよく使われる
強粘着タイプ必須
地理的に分散した環境は、デジタルツールで
ふせんのはがしかた
X下からめくる→粘着面がそり、はがれやすくなる
○横にはがす
○上から下に引く
バーンダウンチャート
残作業管理の定番
スプリント内のタスクの合計残時間を記録
基準線と見比べて状況を把握
状況によってプロダクトオーナーと相談して調整
模造紙やホワイトボードを使用
地理的に分散した環境は、デジタルツールで
インクリメント
・スプリント終了時の増分
スプリントで完了したプロダクトバックログ項目の成果物
スプリントの終わりには完了しているべき
プロダクトオーナーにより受け入れられるか否かにかかわらず
常に動く状態
完了の定義
・作業の完了についての合意を見える化
→チェックリスト
Aさんの完了とBさんの完了が違っていたら?
成熟度によって、厳しさも異なる
更新されることもある
完了の定義例
テストコードがすべてパスしていること
コードレビューが済んでいる
:
:
妨害リスト→スクラムマスターが管理
・非公式だがよく知られたもの
・デイリースクラムなどであがった妨害のリスト
・スクラムマスターが管理、優先度の高い障害から取り除く
イベント
・スプリント計画ミーティング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ
イベントの特徴
・定義かされていないミーティングの必要性を最小化
・スプリントそのものを含め、すべてタイムボックス化
スプリント
・1週間から1ヶ月のタイムボックス
決めたら最後まで期間を変えないこと
・この間の変更受け入れは原則なし
スプリントの長さを決めるのに影響
なくはない(2週間でたまに?)
・途中で中止の可能性もある
POが権限をもつ
2Wスプリントの例
・スプリント計画ミーティング
月曜はじめ1部、2部
・デイリースクラム
毎日朝(ないし昼)
・スプリントレビュー
金曜終わり1つ前
・スプリントレトロスペクティブ
金曜終わり一番最後
スプリント計画ミーティング第一部
スクラムマスター(外)
プロダクトオーナー
開発チーム
プロダクトバックログ
プランニングポーカー
開発チームがスプリントで開発する機能を計画
スプリントの2.5%のタイムボックス
優先順位の高いバックログ項目を理解し
その大きさを見積もる
実績に基づいた収まる分量
ベロシティ
見積もり
基準を決めよう
整数で考える
まよったら大きいほう
見積もりの流れ
・1、2、3、5、8、13
準備
・優先順位の高いものから見て、簡単そうなものを2とする
・優先順位の高いものから見て、その倍ちかいものを5
流れ
1、優先順位の高いものから、
2と5と比べて決めていく
2、全員が同じ数字
3、全員がとなりあう数字になったら、大きいほうをポイントとして1へ
1回目でそろったら、念のため根拠をいう
4、一番大きな数字と小さな数字を出したヒトが根拠を
5、2に戻る
ベロシティ
・開発チームの生産量
各スプリントリームの生産量
・固定するパラメータに応じて可変するパラメータを予測できる
スプリント計画ミーティング第二部
・Whatの実現をHowに落とし込む
・プロダクトバックログ項目を完了にする方法を決定
→スプリントの2.5%のタイムボックス
スプリントバックログを作成
各タスクは1日以下の単位に分解
理想時間で見積もる
時間はチームのだいたいの平均
プロダクトオーナーの参加は任意
何かあったら聞けるところに
デイリースクラム
・タスクログ
・バーンダウンチャート
・日々の検査と適応の場
・毎日の情報共有
毎日定時15分以内
開発チームとスクラムマスター
話すこと3つ
前回のデイリースクラムからやったこと
次回のデイリースクラムまでにやること
困っていること
→進捗報告会ではない。今の状態をわかってもらう場
スクラムマスターはファシリテートするだけ
スプリントレビュー
・スプリントの検査と適応
インクリメントの検査を行う
スプリントの2.5%のタイムボックス
スクラムチーム全員参加
POやステークホルダーへのデモ
POが受け入れをきめる
スプリントレトロスペクティブ
次スプリントのカイゼン計画
スプリントの2.5%
スクラムチーム全員が参加
POは任意、いいづらければはずれる
うまくいった項目、改善点、改善案
KPT(けぷと)
KPT
・振り返りの定番
話し合うのは、次の3つ(付箋とか使う)
Keep
よかったこと、続けたいこと
Problem
よくなかったこと、カイゼンしたいこと
→Tryにあげていくように
Try
やってみたいこと、改善案
→あがりすぎたら、できることに絞る