スクラム ブートキャンプにいってきた その３

スクラム　ブートキャンプ　for NII
講師　高江洲　睦氏(twitter,facebook: @takaesu0)
のお話の続き

Ｓｃｒｕｍって何？

のメモメモ

---

導入
・フレーワーク
　　３つのロール
　　４つのイベント
　　３つの成果物
　それらの関係性や相互作用を統括するルール

→技術的なプラクティスはない
　→ＸＰとの併用になる

特徴
・軽量
・理解は容易
・習得は非常に困難

　　Ｓｃｒｕｍアライアンス
　　　　理解の低いところ：ワースト３－日本

大事なこと
・経験的（エンピリカル）にプロセスを制御する
・反復的、漸進的に進めていく
・３本柱を大切に

３本柱
・透明性：関係者全員が共通理解をもつ
・検査：障害検知、ゴールに向かっている？
・適応：プロセスを調節

ロール（ヒト）
・プロダクトオーナー
・開発チーム
・スクラムマスター

プロダクトオーナー
・Ｗｈａｔを探求するヒト
・プロダクトバックログ（ＰＢＩ）の管理責任者
　　項目を明確に
　　優先順位付け（優先度（高がいっぱい）と優先順位（一列に）は違う）
　　価値を保証
　　プロダクトバックログの見える化
　　開発チームが理解できるように

開発チーム
・Ｈｏｗを探求する
・インクリメントを作成する
　　３～９人
　　自己組織化
　　職能横断的
　　専門家がいてもチーム全体の責任

スクラムマスター
・Ｓｃｒｕｍの番犬
・スクラムの理論、プラクティス、ルールを内外に守らせる
　　外部からのチームの盾となる
　　サーバントリーダー
　　ほかのロールを支援
　　スクラムイベントをファシリテート
　　ほかのロールの潤滑油

サーバントリーダーシップ
・傾聴
・共感
・いやし
・気づき
・納得（説得でなく）
・概念化
・先見力
・世話役
・人々の成長にかかわる
・コミュニティづくり


ＷｈａｔとＨｏｗ
Ｗｈａｔのじく：プロダクトオーナー
ＨＯＷのじく：開発チームが責任
理想はどちらも正

成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント

プロダクトバックログ
・ただひとつのプロダクトに対するバックログ
　　プロダクトに必要なものが順序付けされた一覧
　　　　優先順位の高いものは同じ大きさ
　　プロダクトオーナーにより管理される
　　　　バグ、技術的課題を含む
　　各項目は、ユーザーストーリーの書式を使用することが多い
　　　　大きさは１日から数日
　　スプリント内で手入れ（グルーミング）される
　　直近の数スプリント分は詳細に
　　　　受け入れ条件を明確化
　　　　　　デモ手順

バックロググルーミング
・スプリント内で行うバックログの手入れ
　　　スクラムチーム全員が参加
　　　頻度やどう手入れを行うかはスクラムチームで決める
　　　必要があれば見積もり

ユーザーストーリー
　　・＜役割＞として
　　・＜機能や性能＞がほしい
　　・それは、＜ビジネス価値＞のためだ

よいストーリー：ＩＮＶＥＳＴ
　　Ｉ独立してる
　　Ｎ交渉できる
　　Ｖ価値がある
　　Ｅ見積もれる
　　Ｓ適切な大きさ
　　Ｔ評価できる

スプリントバックログ
・ＷｈａｔとＨＯＷを結びつけるもの
　　プロダクトバックログ項目をインクリメントにする契約をまとめたもの
　　　　開発チームによって管理される
　　　　必要なタスクをすべて見える化
　　　　　　タスクボード
　　　　　　バーンダウンチャート
　　　　残作業の見積もりを日々更新
　　　　タスクは誰が担当してもいい
　　　　　　むしろ、固定化は悪

タスクボード
・Ｓｔｏｒｙ
・ToDo
・Doing
・Done
　タスク管理でよく使われる
　　　模造紙やホワイトボードを使用
　　　　　付箋がよく使われる
　　　　　強粘着タイプ必須
　　　地理的に分散した環境は、デジタルツールで

ふせんのはがしかた
　　Ｘ下からめくる→粘着面がそり、はがれやすくなる
　　○横にはがす
　　○上から下に引く

バーンダウンチャート
　　残作業管理の定番
　　　　スプリント内のタスクの合計残時間を記録
　　　　基準線と見比べて状況を把握
　　　　　　状況によってプロダクトオーナーと相談して調整
　　　　模造紙やホワイトボードを使用
　　　地理的に分散した環境は、デジタルツールで


インクリメント
・スプリント終了時の増分
　　スプリントで完了したプロダクトバックログ項目の成果物
　　　　スプリントの終わりには完了しているべき
　　　　プロダクトオーナーにより受け入れられるか否かにかかわらず
　　　　常に動く状態

完了の定義
・作業の完了についての合意を見える化
　　→チェックリスト
　　Ａさんの完了とＢさんの完了が違っていたら？
　　成熟度によって、厳しさも異なる
　　更新されることもある

完了の定義例
　テストコードがすべてパスしていること
　コードレビューが済んでいる
　　　　：
　　　　：

妨害リスト→スクラムマスターが管理
・非公式だがよく知られたもの
・デイリースクラムなどであがった妨害のリスト
・スクラムマスターが管理、優先度の高い障害から取り除く

イベント
・スプリント計画ミーティング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ

イベントの特徴
・定義かされていないミーティングの必要性を最小化
・スプリントそのものを含め、すべてタイムボックス化

スプリント
・１週間から１ヶ月のタイムボックス
　　　決めたら最後まで期間を変えないこと
・この間の変更受け入れは原則なし
　　　スプリントの長さを決めるのに影響
　　　なくはない（２週間でたまに？）
・途中で中止の可能性もある
　　　ＰＯが権限をもつ

２Ｗスプリントの例
・スプリント計画ミーティング
　　月曜はじめ１部、２部

・デイリースクラム
　　毎日朝（ないし昼）

・スプリントレビュー
　　金曜終わり１つ前
・スプリントレトロスペクティブ
　　金曜終わり一番最後


スプリント計画ミーティング第一部
　スクラムマスター（外）
　プロダクトオーナー
　開発チーム

　プロダクトバックログ
　プランニングポーカー

開発チームがスプリントで開発する機能を計画
　　スプリントの２．５％のタイムボックス
　　優先順位の高いバックログ項目を理解し
　　その大きさを見積もる
　　実績に基づいた収まる分量
　　　ベロシティ

見積もり
　　基準を決めよう
　　整数で考える
　　まよったら大きいほう

見積もりの流れ
・１、２、３、５、８、１３
準備
・優先順位の高いものから見て、簡単そうなものを２とする
・優先順位の高いものから見て、その倍ちかいものを５

流れ
１、優先順位の高いものから、
　　２と５と比べて決めていく
２、全員が同じ数字
３、全員がとなりあう数字になったら、大きいほうをポイントとして１へ
　　　１回目でそろったら、念のため根拠をいう
４、一番大きな数字と小さな数字を出したヒトが根拠を
５、２に戻る

ベロシティ
・開発チームの生産量
　　各スプリントリームの生産量
・固定するパラメータに応じて可変するパラメータを予測できる

スプリント計画ミーティング第二部
・Ｗｈａｔの実現をＨｏｗに落とし込む
・プロダクトバックログ項目を完了にする方法を決定
　　→スプリントの２．５％のタイムボックス
　スプリントバックログを作成
　　各タスクは１日以下の単位に分解
　　理想時間で見積もる
　　時間はチームのだいたいの平均
プロダクトオーナーの参加は任意
　　何かあったら聞けるところに

デイリースクラム
・タスクログ
・バーンダウンチャート
・日々の検査と適応の場
・毎日の情報共有
　　毎日定時１５分以内
　　開発チームとスクラムマスター
　　話すこと３つ
　　　前回のデイリースクラムからやったこと
　　　次回のデイリースクラムまでにやること
　　　困っていること
　　→進捗報告会ではない。今の状態をわかってもらう場
　　　スクラムマスターはファシリテートするだけ

スプリントレビュー
・スプリントの検査と適応
　　インクリメントの検査を行う
　　スプリントの２．５％のタイムボックス
　　スクラムチーム全員参加
　　ＰＯやステークホルダーへのデモ
　　ＰＯが受け入れをきめる

スプリントレトロスペクティブ
　次スプリントのカイゼン計画
　　　スプリントの２．５％
　　　スクラムチーム全員が参加
　　　　　ＰＯは任意、いいづらければはずれる
　　　うまくいった項目、改善点、改善案
　　　ＫＰＴ（けぷと）

ＫＰＴ
・振り返りの定番
　話し合うのは、次の３つ（付箋とか使う）
　　Ｋｅｅｐ
　　　よかったこと、続けたいこと
　　Ｐｒｏｂｌｅｍ
　　　よくなかったこと、カイゼンしたいこと
　　　→Ｔｒｙにあげていくように
　　Ｔｒｙ
　　　やってみたいこと、改善案
　　　→あがりすぎたら、できることに絞る