【読書メモ】スクラム現場ガイド - スクラムを始めてみたけどうまくいかない時に読む本-
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
本書は副題の通りスクラムを始めたあと、習得していくうえでの困難に立ち向かっていくためのヒントを得るために読む本だと言える。著者によるとプロジェクトを始めてから6ヶ月〜18ヶ月の企業が対象らしい。スクラムを始めるとよく起こる問題を題材とした架空の物語とその解説を章ごとに扱い、全30章で構成されている。スクラムを経験していれば物語と扱うテーマはだいたい理解できるが、スクラムを始める前に読むには少しハードルが高いかもしれない。第1部は「準備」となっているが、スクラム未経験者の準備という意味ではなくスクラム経験者が新たに取り組むプロジェクトの準備という意味で捉えるのが良さそう。
ある程度スクラム開発を経験していれば章のタイトルを見るだけで扱うテーマが想像できるものばかりなので、実際に始めてみてから疑問や課題を感じた章から読んでみるのが手軽で効果的な活用方法だと思われる。一方で、各章の後半の解説部分は経験豊富な著者の実体験がベースとなっており、現場で活用できるデータや理論が紹介されているため、課題の有る無しに関わらず全章を読んでおいても損はない。
- 1章 スクラム:シンプルだが簡単ではない
- 第1部 準備
- 第2部 現場の基本
- 第3部 救急処置
- 第4部 上級サバイバルテクニック
個人的ピックアップテーマ
以降は個人的に参考になった章を5つピックアップしてまとめておく。
ベロシティの測定
マネージャやビジネスサイドに対してチームがいつまでにどのくらいできそうかを説明するためにどうやってベロシティの予測を立てるか?
大きく3つのやりかたがある。
- 過去のデータを使う
- わからないなりに見積もる
- 様子を見る
過去に一緒に働いたことがあるチームなら過去のデータが使いやすい。過去のデータを使う場合は以下のような変数に注意を払う必要がある。
- チームと構成の新しさの度合い
- 政治的な環境
- プロジェクトの大きさや複雑度
- プロダクトオーナーと顧客
チームが異なればこれらの変数が全く異なるので過去のデータから予測がしにくい。
わからないなりに見積もる場合はPBIを見積もってチームのキャパシティからベロシティを予測する。より現実的な見積りが出せる状態になったらここで出した見積りは捨てる。
様子を見る場合は、数スプリント実施してみて平均を出して予測する。数スプリントも待たずに予測したい場合は『アジャイルな見積りと計画づくり』で紹介されているマイク・コーンの係数表を使う。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本(ソフトカバー)
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
※参考
どのようなやりかたで見積もるにしても、見積りは自信度に応じた幅をもたせ、ステークホルダーには見積りが概算であることと自信の度合いを正直に伝える。実際にスプリントを走らせたらベロシティを測定しデータを集めて見積りなおす。古いデータは捨てて新しいデータで置き換える。
ストーリーやタスクを分割する
適切な大きさのストーリーやタスクを書けるかどうかがスクラムの成否を左右する。
ユーザーストーリーは3つに区分できる。
- エピック:壮大な物語
- テーマ:エピックに含まれる中心的なアイデア
- ストーリー:テーマの中の1つのイベント
- タスク:ストーリーを実現するために必要なアクション
ストーリーをプロダクトバックログに載せる目安は
ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小の機能
ストーリーやタスクの大きさが適切か判断する一番の方法は質問すること。
- ストーリーは明確か?
- 見積りに仮定を置いている場合は注意。質問して分割する。
- ストーリーはどのくらい詳細か?
- テスト可能か?
- 小さいか?
- 自分自身でできるくらいストーリーを理解しているか?
サステインドエンジニアリングとスクラム
サステインドエンジニアリング(保守開発)の2つの手法
- 時間割当モデル
- スプリントに使う時間と保守に使う時間を決める
- 保守の知見をスプリントの開発に活かせる
- 既存システムの変更を開発にも取り込める
- 作業の切り替えコストが高くなる。小さな問題がたくさん発生すると影響が大きい。
- 割当時間で対処できない問題が発生するリスクがある
- 既存システムで問題がたくさん発生するとベロシティが安定せず予測がたてづらい
- 専任チームモデル
- 保守の専任チームをつくる
- 新メンバーが既存システムについて学ぶトレーニングになる
- 新しい問題にすぐに着手できる
- エキスパート化できる
- 保守開発のリリースを頻繁にできる
- 仕事が単調になりがち
- メンバーが保守開発にモチベーションを持てないかもしれない
専任チームの場合、メンバーをローテーションすることがスキルの偏りやメンバーのモチベーションに対処する手段となりうる。時間割当モデルの場合は、TDDなどを新規開発だけでなく既存システムの改善などにも取り入れる。
新しいチームメンバー
新しいメンバー が加入することによってチームは形成期や混乱期に戻るリスクがある。
※参考:タックマンモデル
スキルと価値観に注目して人選し、学びにフォーカスしてチームで以下のような試験問題を準備する。繰り返し試験を行い学習してもらう。
巨大なバックログの見積りと優先順位付け
何から手を付けて良いかわからないほど巨大なバックログを整理するための「巨大な壁」と呼ばれる手法。ストーリーポイントの議論は後回しにしてストーリーの大きさと優先順位を同時に検討する。
- 巨大な壁の左を最小、右を最大としてチームでストーリーを相対的に見積もる
- 見積りサイズの論理的な区切り(例えば3ptか5ptかの区切り)をチームで決めて線を引く
- ステークホルダは下を低、上を高としてストーリーの相対的な優先順位を決める
- 見積りサイズの線を超えない範囲で上下に並べる
- 巨大な壁を4分割してストーリーをプロダクトバックログに並べ替える
事前に目的と全体のルール、タイムスケジュールを説明する。議論が脱線して時間がかかりすぎないように場をコントロールする。議論が白熱して決まらないストーリーはパーキングロットに置いておき、別枠で議論する。巨大な壁はあくまでスタート地点であり、変更を前提にして考えてもらう。