『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』読書メモその２

前回の続きです。

イテレーション

スクラム開発ではイテレーションを区切って開発をしていくことになります。
イテレーションで達成するものに向かって全力で取り組むことは大事ですが、ただこなすだけではなくリリースという大きい目標に向かってやっていることを常に意識しておかなくてはいけません。
リリースのためには何が求められているのか、いつまでにどんな機能が必要なのか、そこに向けてイテレーションでは何をしていくのがよいか、優先順位は今のままでよいのか、といったことを定期的に見直し、イテレーションをこなしていくことが重要です。
すべての詳細を決めなくてはいけないというわけではなく、リリースまでにどんな道のりでいくのか、ということをイメージしておくことです。
そのためにはリリースまでに必要なストーリーの一覧が用意されていることなどが必要になってきそうです。

プランニング

プランニングではどのストーリーに当たっていくかということを決めていきます。
その際、担当者を決めず、チームで当たるという形にします。おそらく個人にしてしまうとチームで取り組む姿勢が生まれなくなるからですね。
取り組む段階になるとタスクはポイントではなく時間単位で見積もってもよいそうです。すでに全員が内容を理解した上で議論をするので見積もりの時間に信頼性があるからです。
MTGなどもチームとして時間を使うタスクの１つとなります。
次のイテレーションなどの見積り精度を上げるため、タスクの実行のための事前調査タスク（スパイク）もタスクとして数えます。
タスクの単位はできれば1営業日以内まで区切れていると進捗が見えやすいのでよいです。
1日の作業時間は多くても6時間として見積もっていきます。

ベロシティ

ベロシティはチームがイテレーションで消化できるストーリーポイントです。リリースまでの見積もりをするために役立ちます。
ベロシティ自体を見積もる場合、過去の実績などから推測します。
チームの状態が同じである場合は信頼性のあるベロシティを測ることができそうです。
逆にチーム構成が変わってしまっている場合、参考程度にしかならなそうです。
初期の段階での見積もりは不確実性のコーンというものがあり作業が進むにつれて不確実性は減っていく図となっています。
初期の段階であればブレが大きく15という見積もりをしている場合、9〜24ぐらいまでぶれることがあるそうです。

ベロシティの計測は実際にイテレーションを実行して数回こなした平均値などで出すのが確実です。その値からリリース日を予測することができます。
逆に実行する前に何もないところからベロシティを計測するのは困難だと思っていて、ストーリーが全ていきなり揃っていてそのポイントが見積もることができて、チームの消化量も何かしらで予測しないといけません。
さすがに難易度が高すぎそうです。

不確実性のバッファ

見積もりをする上でバッファというのも欠かせません。
作業に対して見積もりをしたものは順調に消化していけばそのままいけるものですがたいていそうはいきません。
そこで何か不測の事態が起きた時のためにスケジュールとしてのバッファをとっておくと間違いないです。
バッファを乗せる場合、個別のタスクそれぞれに乗せてしまうと膨大になるので全体の見積りに対して乗せるとちょうどよいと思います。
ここでは二乗和平方根法などの計算式が出ていましたが、単純に1.5倍としてしまう方法もあるとありました。
バッファとは工数の水増しではなくプロジェクトを安全に保つための余裕です。
ですので作業としての工数とバッファは別物として提示することで水増しではないと表現することができるはずです。

振り返り

イテレーションを終わった時に振り返りで起きた問題を認識してできれば対策していきたいですね。
未完成のストーリーがある場合、ストーリーを外すか分割するのかの判断をすること、またフィードバックまで辿り着けないことへの損失のリカバリなどがあります。
そしてなぜ終わらなかったのかについてもチームで振り返っておきたいですね。見積もりが甘かったのか、そもそもやろうとしたことが多すぎたのか。
予定通り消化していけばリリースバーンダウンチャートなどの運用もでき、よりリリースまでの道のりが見えてきます。

共有

上司やチームと仕事をするにあたってお互いの信頼関係なしに正直なコミュニケーションは望めません。
信頼を失わないためには問題が起きたら共有をきちんとしていくこと、わかっている範囲でも正直に全てを伝えるです。
計画の共有などは正確な見積もりでないならわかっている範囲の前提条件などを提示して予測できる範囲で伝えるようにします。
正確にはわかりませんがあと3〜4ヶ月かかりそうです、などです。
進捗の共有はベロシティをベースとして過去のベロシティから、直近、平均、ワーストなものを見て最低限でもここまでにはいけそうという範囲を見積もり伝えていくなどです。

完璧な計画を立てるのは不可能

ここまで読んできて見積もりの段階で完璧な計画を立てるのは不可能だという記載が現実味を帯びました。
かといって計画通りに進めていくことができないというわけではなく、現段階での見積もりを定期的に見直していくことで徐々に精度が高まっていくものなのだと感じました。