工数見積り
前提
参考
いろいろ書いている
見積もりに人一倍時間をかける。リスクを徹底的に抽出する。リスクに合わせたバッファを工数に計上する。
じゃあその目的が達成されるために何の数値があれば十分なのかを考える
タスクの列挙
できるだけ細分化してタスクを列挙したい
機能に対するステップもそうだし、
テストやバグ修正など特定の機能に結合してる物以外も
個々のタスクに対する工数
↑実践する分にはこれで十分な気もするが、実際はこの信憑性の問題がある
だから、実績として
元の工数に対して実際どれぐらいの時間がかかったのかを計測しておく
残された時間
その時間と残りタスクの工数の差分
タスク自体が増減することもある
これを週次ぐらいで更新と整理を繰り返す
タスクの増減の確認
進捗度合いの確認
実績の評価
ってことを考えるとScrapbox上でもどうにかなりそう
Notionなどを導入しなくても、数値の合計計算さえできれば良い
見積を行う際の手順やコツ
工数に幅を持たせる
レビューを行う
その工数を他のチームの人に見てもらう
見積もる前のコミュニケーション
その場で回答しない
見積もった後のコミュニケーション
不確実性への対策
不確実性を減らす
アジャイルに工数見積りを行う
プロジェクトが進むごとに、定期的に更新する
『アジャイルな見積りと計画づくり』.iconって概念は書かれているが、具体的にどうやって作っていくかはあまり書いていない？mrsekut.icon
それともまだmrsekut.iconが呼んでない小児書いている？
タスクの洗い出しの仕方が知りたい
大分類からやっていくとか、
「工数見積りやるぞ！」と思って全体やるのがダルい問題
あるモジュールを触った時に、そこの細かいところが見えるモードになる
そのタイミングでタスクを列挙しておく
ただ、これ途中ではできるけど、初回ではできない方法だな
スケジュールの方に書いてもいいかも？？
リスクを軽減する
既存システムの調査の時間を加味して多めに時間を取っておく
見積もり自体をアジャイルに行う
進めている中で良いアイディアがあればそれも取り込みながら見積もりを更新する
意思決定のためには、見積もりとスケジュールが必要
信頼を確立する
開発者と顧客の間の信頼
開発者目線でも、持続可能なペースで開発でき、コードの品質が上がる
情報を伝達する
↑これ、スケジュール作成の理念、のようなものなのでかなり大事だと思うmrsekut.icon
あらゆるスケジュール作成の施策、工数見積りの施策は、これらのどれかを達成するために考えが得られたものになっている
だから、「この施策は、「不確実性を減らす」のに役立っている」のようにメモを撮れると良い
メモのとり方を工夫したいmrsekut.icon
featureの提供を計画すべき
よくあるのは「作業の完了」を計画しているもの
WBSとかガントチャートとか
そうではなく
計画づくりでは、作業ではなくfeatureを単位にすべき
顧客にとって価値があるのはそっち
作業を単位にすると、本当に重要なfeatureにもかかわらず、それの品質を下げて作業を完結しようとしてしまう
個々の作業が独立していない
ソフトウェアでは構造上そうなっているものが多い
1つの作業が遅れると、他の作業も遅れる
だから、この実装に時間かかっちゃったけど、次の作業は急いで作って、遅れを取り返すよ、はうまくいかないことが多い
そのためにも、何かしら名前がついている見積もり手法で算出するのは説得材料になりやすい
複数人が見積もった時に、それぞれの差異が少ないほうが説得力がある
この一覧を「どう表示するか」もよく考えられるべき対象だと思うmrsekut.icon