見積もり

項目内容
優先事項ある程度のバッファを持つが、予定通りに業務遂行できること
 再見積もりが発生するよりは、リリース計画が立てやすいはず
 コーディング工程に限定
 残業時間はゼロを目指す
個人で見積もりしない組織リーダーとユニットリーダーとメンバーの3人で丁度よい
1m( 1人月)の定義~20dとする(週休二日制)
1d( 1人日)の定義4~5hとする(所定労働時間8h)
 会議や雑務や休憩や有休などを考慮して、この程度で丁度よい
 運用なども並行して行う必要がある場合、さらに少な目にする
開発規模の算出最初に直感で想定した見積もりの2倍で丁度よい(最短工数はこの数値)
安全な見積もり最初に直感で想定した見積もりの3倍で丁度よい(実績工数はこの数値)
工数算出の根拠関連書籍数冊を読了した上での経験則(信頼度は割と高い印象)
開発規模と計画の違い経験則として、開発規模が2mの場合、計画工数は3mで丁度よい
開発規模2mを1m見積もり見積もり不足、概算見積もりではこの数値を出しがちだが、非常に危険
 経験の浅いエンジニアは詳細タスクを見通せないため、この数値にしがち
 経験の深いエンジニアは自身の能力を過信してしまい、この数値にしがち
 小規模案件では好調状態が継続できれば達成可能なことがあるので、厄介
開発規模2mを2m見積もり見積もり一致、プロジェクトは円滑に進むことがないので、危険
 ほぼ必ず発生する想定外の事態に対処する工数がないので、遅延する
開発規模2mを3m見積もり見積もり安全、ほとんどのプロジェクトではバッファは残らない
 順調に進まなければ、バッファ期間で遅れを取り戻せる
 順調に進むと、別タスクやフォローを振られるため、バッファは残らない
 順調に進むと、理想的にはバッファを品質向上に使える(3割程度)
  例)Node.js でPromise チェインをGenerator+yield に変更したり
開発規模2mを4m見積もり見積もり超過、期間優先のプロジェクトでは問題となる可能性が高い
 品質を優先する場合、本来これくらいの工数は欲しいがほぼ認められない
 事業の相対的売上の規模を把握していれば、調整できる可能性はあるかも
想定外残業は見積もりミス見積もり精度が高ければ、想定外タスク実施後も残業時間はゼロに近づく
タスク自体の管理GitHubのIssuesやテキストファイルなど、慣れているシステムで管理
忘れがちなタスク以下以外にも色々とありそう(特に不安の大きい箇所は多めに見積もり)
 フォロー新メンバー2人程度をリードする場合、~10dくらい必要(毎月)
 レビュー担当外のコンポーネントまで見る場合、5dくらい必要(毎月)
 タスク管理意外に時間を使うので、2dくらい必要(毎月)
 キャッチアップ要件や外部設計把握に、5dくらい必要
 学習コスト初めて使う技術の場合、5dくらい必要
 共通機能新規開発の場合、~20dくらい必要
 エラー処理新規開発の場合、5dくらい必要(非機能要件の対応も実施)
 リファクタリング新規開発の場合、5dくらい必要
 デプロイ新規開発の場合、5dくらい必要
 単体試験コード実装中規模案件で、5dくらい必要
 結合試験仕様書作成中規模案件で、5dくらい必要
重要事項無言の圧力をかけてくる勢力がいるが、後で苦しむだけなので、屈しない
 週40時間以上の労働はパフォーマンスが下がる
 残業ほぼゼロでもパフォーマンスは発揮できる
 開発を進めることによって不安を解消していく
 必要に応じて再見積もりも推奨(見積もり自体も工数が必要なので注意)