開発計画の線表の引き方
個人的な引き方です。
前提
時間境界型のプロジェクトを想定
各開発項目は平均ケース、最悪ケースの二点でポイント見積もりがされている
線表とは
開発項目と担当者が示されている
いわゆるガントチャート
線表の目的
計画と現実のギャップに気づき、修正機会を得る
計画のもっともらしさを可視化する
計画と実行のズレを検知する。ズレの影響を可視化する
レビュー観点
上にある項目ほど優先
開発効率は不確実性と比較して重視しない
開発効率が一見良くなるが不確実性が高まるような計画は基本的に採用しない
欲しいのはもっともらしい計画
例えばビッグバンマージ
開発効率がよくなるかも知れないが、博打のような新技術導入もしない
やるなら事前に失敗しても巻き返せる規模の小さい機能開発でやる
そもそも全部の開発項目が含まれているか
そもそも全部の開発項目が見積もられているか
開発項目の依存関係からクリティカルパスが想定されているか
https://ja.wikipedia.org/wiki/クリティカルチェーン・プロジェクトマネジメント
合流バッファなども考慮できているか
妥当な期間を設定できているか
https://qiita.com/Hiraku/items/c29ca383fbef8eb38fd2
線表上の線の長さは平均ケースで引く
長さはポイントを期待するベロシティで割り算して出す。期待するベロシティは目立つところにメモしておく
実測ベロシティがどうやら期待ほどでなかったときにギャップに気づくのに役立つ
プロジェクトバッファは機能開発ごとに取らず、プロジェクト全体で設定する
着手順が不安量が大きい順になっているか
https://zenn.dev/hirokidaichi/articles/af0a92b9ce666968f97b#不安の定量化
長期休暇や評価期間など、業務に影響のあるイベントを考慮できているか
担当者のスキルや習熟度を考慮できているか
上記の条件を満たした上で複数の選択肢があるなら、開発効率が良くなる選択をする