「スクラム現場ガイド」
スクラム現場ガイド
最初にまとめ
スクラムを導入したときに、まさに現場でぶち当たる問題とその対処方法が紹介されている。そういう意味では中級者〜上級者向けの本だと思う。
いくつかの本でスクラム開発は「守破離」が肝だと解説されているが、その「破」や「離」にあたるさまざまな応用的なテクニックが紹介されていて、ぜひとも取り入れたいと思った。
Part1 準備
第３章
コアチームメンバーとチームコンサルタント
コアチームメンバー：１つのプロジェクトに、フルタイムでコミットするメンバーで、機能横断的な役割を担う
チームコンサルタント: 複数のプロジェクトにまたがって専門的な領域を担当する。
コアチームメンバーというのはなかなかおもしろいというか、現実にもこういった、あの人のあのスキルがほしいな、という時はある。なんとなく理想論のように聞こえるけど、多分そうではない。ただ実際に導入する場合にはいくつか制限の中で運用することになる。 複数プロジェクトに関与するということは、
- ある特定の問題を解決する
- あるスプリントだけ、時間を決めて参加する
というような働き方になるので、あまり時間が求められるようなシーンでは難しくなりそう。
- 比較的やることがはっきりしていて、いつまでにコレをお願い、と言えるようなタスクに向いているかも
- 時間や内容次第では、コアチームメンバーとペアワークするだけでも良さそう
スクラムイベントには基本的に参加してもらうので、そういう点でのオーバーヘッドは出てきそう。あと、チームコンサルタントが毎回使う時間が違うので、チームとしてのベロシティの実績値にも影響がでるかもな。
第４章 ベロシティの計測
基準ストーリーから近似値を得る
基準とするタスクを分解し、それぞれ作業時間を予測して、合計時間をポイントにする。３つくらいのストーリーで行えばもう少し正確になりそう。
チームの稼働時間
一週間あたりに使える時間をどれだけとするか、チームの稼働時間をメンバーごとに最大時間、最低時間を決める。 しかし、これだと人のスキルとか習熟度によって結構違うんだよなと。
このあたり、初回のベロシティを”わからないなりに見積もる方法”についてこうやって書いた本は、これまで読んだものの中にはなかったが、やってみる価値はありそうだなと思った。
第５章 スクラムの役割
プロダクトオーナー・スクラムマスター・チームメンバーを兼任してはいけない。 当然だけど。当然だけどね。。
第８章 専任スクラムマスターの利点
- 障害を取り除く、問題を解消する
- 争いや言い合いを収める
- チームの心のケア
- パフォーマンスの報告
- 各イベントにおけるファシリテーター
- 必要なら手伝う（それ専任じゃないじゃん）
これまでどの本をみても「障害を取り除く」について抽象的な書き方しかされてなかったけど、それはなぜなら、とにかくチームのアウトプットを低下させる「すべて」が対象であるからなんですね。本書には少し例が書かれていました。ミーティングに遅刻する人の対応、他チームとの折衝、メンバーの病気による離脱、マネジメントとうまくやる、などなど。
第２部 現場の基本
第９章 エンジニアリングプラクティスにおける重要性
前述の話と合わせると、スクラムマスターとかチームコンサルタントのメンバーがペアプログラミングに参加するのは良いかもしれない。 スクラムマスターはリーダー的な立場の人になることが多いし、チームコンサルタントはその分野の熟練者を育てるという目的を達成できる。
第１１章 リリースプランニング
- 完全な機能の一覧と完成日を両方決めてしまうのは無責任である
プロダクトオーナーは、どちらか一方を固定し、状況に合わせて調整するべきだと。両方を固定してしまうと、多分開発チームは保守的な見積もりをすることになり、みんなが損をする。
良いスクラムチームは、完成日に、最小の予想と最大の予想の間のどこかに落ちるようにリリースすることになる。
第１６章 ふりかえり
- プロダクトオーナーは参加しないほうが良い
- ふりかえりの内容は参加者以外見えない形に保存しておくのがよい
なるほど、可能な限り正直なコメントを言える場にすることを重視するということですね。スクラム開発の効率を上げるのが目的なので、変な気遣いをスべきでないと。だとすると、場合によってはメンバーを絞るセッションもあったほうが良いかもしれない。例えば協力会社のメンバーを入れる場合と入れない場合とか。
ふりかえりは基本的にすべての人が参加すべき、というのが原則だと思うので、これは応用編あるいはオプション的なアイデアのように思う。守破離でいう「離」になるのかも。
- クロージングでスプリントに点数をつけてもらう
不満があるがふりかえりの場でそれを言えなかった人をあぶり出し、なにか問題がないか、ミーティングのあと個人的に質問する。特に日本の文化にこれは合いそうだと思った。
- ふりかえりはスプリントに限らない
大きいリリースがあったあとや、顧客など複数のチームを巻き込んでおこなうなども有用。
第３部 救急処置
第１８章 第４の質問
- 「今回のスプリントゴールをチームで達成できる自信はどのくらいありますか？１〜１０で答えてください」
一部のメンバーだけが気になっている細かい事象が後で発覚しないように、なるべく早く拾うための施策。あとは、自分の経験からだと、自分には危機感が結構ある一方で、他のメンバーがあまり危機感を感じてないみたいなことがあり、そういった状況を共有するのにも良いかもと思った。
第４部 上級サバイバルテクニック
第２３章 維持可能なペース
- イテレーションを短くし、バーンダウンチャートを監視し、だいたい85%くらいの力で働くようにコミットする
100%以上頑張っちゃいそうな日本人です。
２９章 巨大なバックログの見積もりと優先順位付け
- すべてのユーザーストーリーを壁に小さい順に並べて、ストーリーポイントが1,2,3,5,8... になる場所に線を引く。優先順位が大きいものは上に、小さいものは下に。
面白い。賢い。 出てきた数字を過信しないという前提でしっかり扱えば十分使えそうなテクニック。
あと、POがpriority付するときに理由を明確にしてもらうというのも重要。
