アジャイルな見積もりと計画作りを読んだ
2018年13冊目
スクラムを調べる中で多くの方々に参考にあげていたので読んでみた。
良書すぎて驚いた。
内容としては、いかにタスクベースでなくフィーチャベースで見積もりと現実を継続して進めていくかという話。
ついつい普段からタスクベースの見積もりをしているので目から鱗。
リリースプラン、イテレーションプラン、デイリープランを元にチームのベロシティ(速度)を計測しながらリリース日を決めていく流れはチームに取り入れていきたい。
そもそも見積もりの不確実性をもっと意識しようと思った。理想予想工数とリリース日を一致させるのは不確実性を無視した勘でのリリースにしかすぎず、そりゃ遅れも出るわという印象。
経験と勘と度胸ベースの見積もりをやめ、チームの開発速度を可視化できる術を試していこうと思う。
そのためにはイテレーションベースの開発文化を作っていかないといけない。結局は文化チーム組織作りにつながる。
DevOpsにもつながる部分だ。
以下はきになる点のメモ
毎度出てくる不確実性のコーン
プロジェクト初期では60-160の誤差がある
20週の見積もりは12週から32週のズレがあるという事。モニタリングの重要性。
1章 計画の目的
良い計画とは？
リスクを軽減する
不確実性を減らす
意思決定を支援する
信頼を確立する
情報を伝達する
プロジェクトの成功とは？
予定通りの期間で予定通りの予算で、最初に定義した全てのフィーチャを満たしていること
ほんとに？
最初に定義したフィーチャが、価値に見合わない場合は失敗では？
では失敗とは？
作者は、最初に定義したアイディアより良いアイディアを最後まで誰も思いつかなかったプロジェクト。としている。
ただ最初の定義に入っていないからと却下されるのは、ユーザーにとって満足のいくプロダクトにはならないだろう。
積極的に変更したいと思える状況
これは、学習や過ちに気付いた時にしか起きない気持ち。
プロジェクト初期で全体を予測することを不可能とする立ち位置
その中でアジャイルな計画作りとは？
計画よりも計画作りを重視する
変化を促進する
計画そのものは容易に変更できる
プロジェクト全体に渡って繰り返される
作業の完了ではなく、フィーチャの提供をゴールとする
顧客には作業の完了はどうでも良い。
フィーチャを単位とすべき。
作業ベースだと、作業の抜けがないかを探す。実際は作業の抜けではなく、フィーチャの抜けに気を使わなければいけない。
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。
問題とゴール
見積もりがコミットメントになっている
アジャイルとしての考え方
変化への適応を優先する
ここがウォーターフォールとの大きな違いか。
より身軽に身動きの取れる手法を選択するならば、アジャイル、かっちりと変化が起きにくいとすればウォータフォールとする。
のようなチームの分け方は良いと思う。
ユーザーストーリーは要求を表現する手段。
ユーザー目線で機能の概要となる。
ユーザの種類として、機能や性能が欲しい。それはビジネス価値のためだ。というテンプレート。
例 本の購入者としてISBNで本を検索したい。それは
探している本を素早く探すためだ。
ストーリーカードはスタート地点に過ぎないので、それをベースにオーナーと要求仕様を話したりドキュメントにまとめたりする
10km競争と60分競争
この例えは面白い。60分競争では、ゴールが決まっていない。その期間でどこまで遠くまで走れるかを競う。
ストーリーボードのポイントと、スプリント期間によって、見積もりが出来るというのはとても腑に落ちた。これは皆に共有せねば。
4章
ストーリーポイントと理想日の話
どちらもベロシティで割れば結果が出る
第8章見積もりの技法
プロダクトオーナーはプランニングポーカーに参加する
プランニングポーカーには全エンジニアが参加する フロント、デザイナもそう
見積もりでは絶対的な制度は必要ない
8章
ストーリーポイントは純粋に大きさを表す
理想日ベースよりも見積もりが早い
理想日が違う問題。
誰がやるかわからないから理想日が違うならば技術の標準化、平均化が必要
14章
1ポイントのストーリーでも平均時間が異なる。錯覚しないように。
2ポイントよりも1ポイントのストーリーが大きいことはある。
イテレーション報告書
ペロシデイ平均値
ペロシデイの達成ストーリポイント内訳
次回イテレーションへのアクションプラン
そんなところか。
