工数見積もり

kii的な見積もり

0.kiiは15分単位で作業を見積もる

1.実装内容に対する純粋な見積もりを、既存の経験から見積もる

自分が実装したことのない機能は、安直に自分の勘に頼るのでなく、一度軽く、実装方法を調べて実装難易度を把握する

全体の中で、どのタスクで共通componentを作成するか決める。分割しても良い。

2.見積もった数字を1.5倍し、それを実装見積もりとする

大体、自分が直感で見積もった1.5倍くらいかかるため

3.実装見積もりから

実装内容 2.75Point + 2(小数点切り上げ)

実装見積もり 1Point

見た目や動きを似せることがメイン

見直し修正 0.5Point

code整理やformat、より良い書き方の模索

プルリクの作成 30分

よくわからない所、イマイチな所質問する

プルリク修正&会話 1.25Point

時間が経つと、自身で気付けることが増えるため、ここの枠が減り、実装見積もりや見直し修正の枠が増えると予想

まず、この考え方を使いながら、自分用にアレンジしていく

以下頂いたもの引用して整理したもの

工数見積もりは主に3観点

1.タスクの細分化

2.細分化タスクの規模感設定（積算すると全体工数）

3.バッファの設定

見積もりに使う工数比率は 1 が 70% / 2 が 25% / 3 が 5% くらいをざっくりイメージ

タスクの分解がキモ

見積もりを外した場合には、次のように振り返り

1.タスクの細分化が足りなかった？なぜ？

a.既存システム調査で見落とした仕様があった？

b.共通化の設計に使う時間配分を考慮してなかった？

c.テスト関連で見劣しがあった？

d.新規に作る範囲の要件確認や調査が不足していた？

2.規模感の設定が大きくずれた？なぜ？

a.自分の集中する時間や作業時間がうまく確保できなかった？

b.依存するシステムへの改修工数の読みが甘かった？

c.今後の事を考えてリファクタリングを一緒に行なった？

d.追加要件確認が思ったより工数を取られた？

3.バッファがたりなかった？積みすぎた？なぜ？

a.レビューがすんなり通った？

b.会議や差し込みが結構多い期間だった？

c.自分にとって新規トライアルな技術が多かった？

3観点での GAP を産んだ要因を自分なりに整理して、次の工数見積もり時はこれ変えて見よう

というところをアクションとして設定しなおして次のプロジェクトに進む

このような事を繰り返しながら、工数見積もりというものをスキルにする

全体的に経験則により補完が効いてくる部分が多いため、徐々にこのような精緻な振り返りはしなくなる

自分の中の工数見積もりに対するロジック作りと、振り返りの道筋というものを 自分らしく作る

とにかく、課題分解が大事。共通の一定粒度に小さくして初めて、計算出来る。

考える要素追加

既存システムによる実装の縛り、調査による時間消費

既存システムのその部分、触ったことある？

マルチプラットフォーム対応

各デバイスやブラウザ独自の対応修正の時間を考慮しているか？

そのAPI利用経験ある？ブラウザ独自のバグ無かったけ?

レビューの観点

デザインレビュー

Interactiveな部分、動的な部分は特に新規で発生しがち

実装レビュー

実装前に設計相談出来ることは無いか？

別で設計と確認の時間を設けないのか？

参考

マイルストーン、注目、エネルギーの観点