スクラム実践入門
スクラムについてしっかり学んでおきたく、技術評論社から出ている『スクラム実践入門』を読むことにしたのでその記録です。
スクラム導入でよくある問題
- 開発チームの強み、弱みを可視化する
- 強い人と弱い人をペアプロで組ませてスキルの底上げを行う
- スクラムの理解不足
- スクラム勉強会を開催する
- お試し期間を導入してダメだったらもとに戻す
- スクラムを使う理由が不明
- 前に書いた各社の事例では「属人性の排除」を掲げているところが多かった
- あとはコミュニケーションの問題も
- 意欲がわかないメンバーもいるはず、そういう人に気を配る
- 本当に同仕様もなかったら、相談して、スクラムチームから外れることも検討（あくまでも円満に）
- 最適なスプリント期間がわからない
- とりあえず最短の1週間で始める
- インクリメントの量や割り込みタスクの量などをみて調整する
- スクラムイベントの日時
- 月曜は祝日のことが多いので、スプリントレビューなどは月曜日を避ける
- 金曜日だと、スプリントプランニングしてすぐ休みに入ってしまうのでよくない
- 月曜は祝日のことが多いので、スプリントレビューなどは月曜日を避ける
スクラムチームでよくある問題
- プロダクトオーナーの意思決定が覆される
- スクラムチームではプロダクトオーナーが決定権を持つので、外部要因によって左右されすぎるのは良いことではない
- 決定権をプロダクトオーナーに適切に委譲する
- 決定権を持つステークホルダーをスプリントプランニングの必要なタイミング（意思決定が必要なタイミング）に参加させる
- スプリントプランニングの中では意思決定が不要な時間もあるので、そこには呼ばなくてよい
- スクラムチームではプロダクトオーナーが決定権を持つので、外部要因によって左右されすぎるのは良いことではない
- プロダクトオーナーの知識不足などで、必要十分なプロダクトバックログを作れない
- プラクティスを活用する
- プロダクトオーナーを支援する
- 優先順位を適切につけられない
- 優先したいポイントを絞る
- インクリメントを全て受け入れてしまう
- 開発チームに気を使う
- 時間がないので妥協する
- インクリメントの受け入れ条件を作っておく
- チームメンバーが途中で増える
- 強み弱みの可視化など、チームビルディングをやり直す
- ペアで作業する
- チームメンバーが途中で減る
- 引き継ぎ項目を洗い出してプロダクトバックログに追加し、スプリントで引き継ぎを行う
- スクラムを実践することが目的になってしまう
- スクラム導入の目的を明らかにする
- スクラム導入で何を達成したいのか（Goal）
- 現状との差分は（Reality）
- ゴールを達成するためのリソースはどこにあるか（Resources）
- 差分を埋めるためにどのような手段があるか（Options）
- それは今すぐやるべきかどうか（Will）
- スクラム導入の目的を明らかにする
- ロールを兼任してしまう
- スクラムマスターとプロダクトオーナーの兼任はダメ
- スクラムマスターと開発メンバーの兼任はダメ
- 複数チームのスクラムマスターを兼任するのは大丈夫です
日本のスクラムコミュニティやイベント
- すくすくスクラム
- スクラム道
- POStudy（プロダクトオーナーシップ勉強会）
- Scrum Masters Night
- Regional Scrum Gathering Tokyo
スクラムイベントでよくある問題
- タスクの表現の属人化
- フォーマットを決めておく
- 見積もりができない
- 「大雑把な見積もり」と「正確な見積もり」を使い分ける
- 見積もりができるようになるまで見積もらない
- Part8で説明した「スパイク」などを行う
- スプリントでこなせる作業量がわからない
- ベロシティを計測する
- 開発チームの作業時間を見積もる
- デイリースクラムが終わらない
- タイマーを使って無駄なおしゃべりをなくす
- 必要に応じて二次会を開催する
- デイリースクラムに人が集まらない
- 時間・場所を変更する
- 集まらなくても良い仕組みにする
- いつの間にかタスクが増える
- 基本的にスプリントプランニングに無いタスクが増えることはありえない
- メンバーで個別に回答するのは避けてプロダクトオーナーに委ねる
- タスクボードが動かない
- Doingになっていない、Doneになっていないなど
- Doneに動かしていいですか？などと聞いて動かして見せてみる
- みんなが各自でちゃんとタスクを動かすように、「タスク動かすマン」みたいなものは置かない
- Doingになっていない、Doneになっていないなど
- デイリースクラムで困っていることが出てこない
- スクラムマスターが注視して、必要に応じて質問する
- 問題がない場合は問題がないことを明治する
- スプリントレビューがただの進捗共有会になってしまう
- プロダクトオーナーがしっかりレビューの下準備をする
- スプリントレビューまでリリースしてはいけないという誤解がある
- スプリントレビューはレビューするだけであって、リリースする場ではない
- スプリントレビューの目的を再確認する
- 完成しなかったプロダクトバックログのアイテムの扱いがわからない
- 次回のスプリントで扱う、あるいはバックログに新しく載せて終わりにする、など
- スプリントは延長しない
- 完成しなかった原因に焦点を当てたほうが良い
- ベロシティ計測には完了したものだけを使う
- スプリントレトロスペクティブで振り返るだけで実行されない
- 改善をタスクに落として責任者を決める
- 問題が出ない/出過ぎる
- 問題を紙に書いて整理する
- 直ぐに解決したい問題にフォーカスする
- スプリントレトロスペクティブの主導権をプロダクトオーナーが握る
- レトロスペクティブの方はプロダクトオーナーの責任のもと行うものではない
- まずはプロダクトオーナーなしでレトロスペクティブを開催するものあり
- スプリントゴールが達成できなかったことに触れられない
- 終わらなかった原因を明らかにする
スクラムの作成物によくある問題
- プロダクトバックログが大量に作られてメンテナンスされない
- 夢見がちなプロダクトバックログになってしまっている。ビジョンを整理する
- 定期的に整理する
- 隠れたプロダクトバックログ
- プロダクトバックログの追加が面倒だと思わないような仕組みや媒体にする
- 突発的なプロダクトバックログの発生をある程度許容する
- スプリントプランニングの時だけに全てを洗い出すのは不可能なため
- スプリントバックログの管理がうまくいかない
- タスクボードを工夫する
- インクリメントの完成の定義が統一されていない
- 完成の定義を言語化する
- 完成の定義をみなおす
この投稿はシリーズものです
初回はこちら
