radioc@?

レディオキャットハテナ

【読書メモ】スクラム現場ガイド - スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

本書は副題の通りスクラムを始めたあと、習得していくうえでの困難に立ち向かっていくためのヒントを得るために読む本だと言える。著者によるとプロジェクトを始めてから6ヶ月〜18ヶ月の企業が対象らしい。スクラムを始めるとよく起こる問題を題材とした架空の物語とその解説を章ごとに扱い、全30章で構成されている。スクラムを経験していれば物語と扱うテーマはだいたい理解できるが、スクラムを始める前に読むには少しハードルが高いかもしれない。第1部は「準備」となっているが、スクラム未経験者の準備という意味ではなくスクラム経験者が新たに取り組むプロジェクトの準備という意味で捉えるのが良さそう。

ある程度スクラム開発を経験していれば章のタイトルを見るだけで扱うテーマが想像できるものばかりなので、実際に始めてみてから疑問や課題を感じた章から読んでみるのが手軽で効果的な活用方法だと思われる。一方で、各章の後半の解説部分は経験豊富な著者の実体験がベースとなっており、現場で活用できるデータや理論が紹介されているため、課題の有る無しに関わらず全章を読んでおいても損はない。

  • 1章 スクラム:シンプルだが簡単ではない
  • 第1部 準備
    • 2章 仲間と共に旅立つには
    • 3章 チームコンサルタントでチームの生産性を最適化する
    • 4章 ベロシティの測定
    • 5章 スクラムの役割
    • 6章 スプリントの長さを決める
    • 7章 完成を知る
    • 8章 専任スクラムマスターの利点
  • 第2部 現場の基本
    • 9章 エンジニアリングプラクティスのスクラムにおける重要性
    • 10章 チームのコアタイム
    • 11章 リリースプランニング
    • 12章 ストーリーやタスクを分割する
    • 13章 欠陥を抑制する
    • 14章 サステインドエンジニアリングとスクラム
    • 15章 スプリントレビュー
    • 16章 ふりかえり
  • 第3部 救急処置
  • 第4部 上級サバイバルテクニック
    • 23章 持続可能なペース
    • 24章 動作するソフトウェアを届ける
    • 25章 価値の測定と最適化
    • 26章 プロジェクトのコストを事前に考える
    • 27章 スクラムにおけるドキュメント
    • 28章 アウトソースとオフショア
    • 29章 巨大なバックログの見積もりと優先順位付け
    • 30章 契約の記述

個人的ピックアップテーマ

以降は個人的に参考になった章を5つピックアップしてまとめておく。

ベロシティの測定

マネージャやビジネスサイドに対してチームがいつまでにどのくらいできそうかを説明するためにどうやってベロシティの予測を立てるか?

大きく3つのやりかたがある。

  • 過去のデータを使う
  • わからないなりに見積もる
  • 様子を見る

過去に一緒に働いたことがあるチームなら過去のデータが使いやすい。過去のデータを使う場合は以下のような変数に注意を払う必要がある。

  • チームと構成の新しさの度合い
  • 政治的な環境
  • プロジェクトの大きさや複雑度
  • プロダクトオーナーと顧客

チームが異なればこれらの変数が全く異なるので過去のデータから予測がしにくい。

わからないなりに見積もる場合はPBIを見積もってチームのキャパシティからベロシティを予測する。より現実的な見積りが出せる状態になったらここで出した見積りは捨てる。

様子を見る場合は、数スプリント実施してみて平均を出して予測する。数スプリントも待たずに予測したい場合は『アジャイルな見積りと計画づくり』で紹介されているマイク・コーンの係数表を使う。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

※参考

takaaki-kasai.blogspot.com

どのようなやりかたで見積もるにしても、見積りは自信度に応じた幅をもたせ、ステークホルダーには見積りが概算であることと自信の度合いを正直に伝える。実際にスプリントを走らせたらベロシティを測定しデータを集めて見積りなおす。古いデータは捨てて新しいデータで置き換える。

ストーリーやタスクを分割する

適切な大きさのストーリーやタスクを書けるかどうかがスクラムの成否を左右する。

ユーザーストーリーは3つに区分できる。

  • エピック:壮大な物語
  • テーマ:エピックに含まれる中心的なアイデア
  • ストーリー:テーマの中の1つのイベント
  • タスク:ストーリーを実現するために必要なアクション

ストーリーをプロダクトバックログに載せる目安は

ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小の機能

ストーリーやタスクの大きさが適切か判断する一番の方法は質問すること。

  • ストーリーは明確か?
    • 見積りに仮定を置いている場合は注意。質問して分割する。
  • ストーリーはどのくらい詳細か?
    • テスト可能か?
    • 小さいか?
  • 自分自身でできるくらいストーリーを理解しているか?

サステインドエンジニアリングとスクラム

サステインドエンジニアリング(保守開発)の2つの手法

  • 時間割当モデル
    • スプリントに使う時間と保守に使う時間を決める
    • 保守の知見をスプリントの開発に活かせる
    • 既存システムの変更を開発にも取り込める
    • 作業の切り替えコストが高くなる。小さな問題がたくさん発生すると影響が大きい。
    • 割当時間で対処できない問題が発生するリスクがある
    • 既存システムで問題がたくさん発生するとベロシティが安定せず予測がたてづらい
  • 専任チームモデル
    • 保守の専任チームをつくる
    • 新メンバーが既存システムについて学ぶトレーニングになる
    • 新しい問題にすぐに着手できる
    • エキスパート化できる
    • 保守開発のリリースを頻繁にできる
    • 仕事が単調になりがち
    • メンバーが保守開発にモチベーションを持てないかもしれない

専任チームの場合、メンバーをローテーションすることがスキルの偏りやメンバーのモチベーションに対処する手段となりうる。時間割当モデルの場合は、TDDなどを新規開発だけでなく既存システムの改善などにも取り入れる。

新しいチームメンバー

新しいメンバー が加入することによってチームは形成期や混乱期に戻るリスクがある。

※参考:タックマンモデル

www.educate.co.jp

スキルと価値観に注目して人選し、学びにフォーカスしてチームで以下のような試験問題を準備する。繰り返し試験を行い学習してもらう。

巨大なバックログの見積りと優先順位付け

何から手を付けて良いかわからないほど巨大なバックログを整理するための「巨大な壁」と呼ばれる手法。ストーリーポイントの議論は後回しにしてストーリーの大きさと優先順位を同時に検討する。

  • 巨大な壁の左を最小、右を最大としてチームでストーリーを相対的に見積もる
    • 見積りサイズの論理的な区切り(例えば3ptか5ptかの区切り)をチームで決めて線を引く
  • ステークホルダは下を低、上を高としてストーリーの相対的な優先順位を決める
    • 見積りサイズの線を超えない範囲で上下に並べる
  • 巨大な壁を4分割してストーリーをプロダクトバックログに並べ替える
    • 優先順位が高くサイズが小さい左上のストーリーはバックログの先頭
    • 優先順位が高くサイズが大きい右上のストーリーは上記の次のバックログ
    • 優先順位が低くサイズが大きい右下のストーリーはバックログの最後
    • 優先樹にが低くサイズが小さい左下のストーリーは不要になるかもしれないので別にしておく

事前に目的と全体のルール、タイムスケジュールを説明する。議論が脱線して時間がかかりすぎないように場をコントロールする。議論が白熱して決まらないストーリーはパーキングロットに置いておき、別枠で議論する。巨大な壁はあくまでスタート地点であり、変更を前提にして考えてもらう。