この質問は here/programmers で何度か尋ねられていることを知っています。これは非常に一般的で古典的な質問です。
タスクにかかる時間を正確に見積もるにはどうすればよいでしょうか?
私が抱えている問題は、Windows でのポイント アンド クリック タスクに関するもので、正確な見積もりを出すことができます。何か新しいものをコーディングする場合 (よく知らない API を使用する場合など)、命を救う正確な時間を見積もることはできません。頭に浮かぶ最初の数 (日/週など) を考えて言う場合です。使い慣れた API を使用するコードや、すぐに開発できると言えるアプリ (メモ帳タイプのアプリなど) については、正確な見積もりを出すことができます。
どんな助けでも感謝します。
ありがとう
部分に焦点を当てます。高いレベルでタスクを見積もろうとすると、気が遠くなるだけでなく、合計時間を構成するすべてのものを正確に因数分解できなくなります。
代わりに、合計を推測しようとさえせず (役に立たないだけでなく、実際に個々のタスクの見積もりにバイアスがかかる可能性があります)、座って、タスクを構成するすべてのサブタスクについて考えてみてください。それらが大きすぎると感じたら、さらに小さなサブタスクに分割します。
これが完了したら、各サブタスクに見積もりを出します。それらのいずれかが約 4 時間を超える場合、サブタスクはおそらく十分に分割されていません。これらのサブ見積もりをすべて追加します。これはあなたの見積もりです。
このアプローチを使用すると、タスクを完了するために実際に何が必要かを推論する必要があり、より適切な見積もりを作成できます。
タスクを完了するために必要な明確でない手順についても考えてください。コードを書いている場合、関連する単体テストを書くための時間の見積もりを含めましたか? コードをテストするには？それを文書化するためですか？
時間を数日に換算するときは、実際に頭を下げて仕事に費やす時間について、現実的な予測を使用してください。一般的なコンセンサスは、開発者は 1 日 8 時間の作業で 4 ～ 6 時間の作業を完了することができるということです。これは私の個人的な経験とほぼ一致します。
他のチーム メンバーがいる場合は、Planning Pokerと呼ばれる手法を試すことができます。最も単純なアイデアは、チームの各メンバーに仕事を任せて、それぞれのタスクを個別に見積もることです。それが完了すると、チームは集まり、見積もりを比較して大きな偏差を探します。これは、タスクが十分に明確でない場合、他のメンバーが持っていない関連情報をチームのメンバーが持っている場合、または別のチーム メンバーによって異なる仮定が行われている場合に明らかになる傾向があります。
見積もりを行うときは、仮定に注意し、見積もりの一部としてそれらを文書化してください。x、y、& x とすると、タスク q には n 時間かかるはずです。たとえば、機能をテストするための QA エンジニアが利用できると仮定する、テストのために機能を展開する開発環境が利用できると仮定する、まだ一緒にテストされていない 2 つのサードパーティ フレームワークの互換性を想定する、タスクが依存している機能 z は、特定の日付までに準備ができている...などです。私たちは、無意識のうちに常にこれらの仮定を大量に行っています。それらを文書化することで、それらを認識する必要があり、他の関係者があなたの仮定が正しいことを検証できるようになります。また、見積もりが間違っていることが判明した場合は、その理由を分析するための情報がさらに多くなります。
このすべてのアドバイスに従ったとしても、不正確な見積もりを頻繁に行うことになりますが、私たちの脳は抽象的なタスクに対してひどい見積もりを出すように組み込まれているため、それほど気にする必要はありません。私たちは、タスクのサイズと労力を測定する能力に影響を与える多くの認知バイアスを持っています.
さらに詳しい情報とアドバイスについては、この記事を読むことをお勧めします。
http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/
私が通常行うことは、タスクを小さなタスクに分解することです。最大のタスクは 2 日を超えてはなりません。小さなタスクを見積もることはそれほど難しくありません。小さなタスクごとにテスト時間が見積もりに含まれているため、プロジェクトの最後に大量のテストされていないコードが残ることはありません。
高レベルの設計が整っている場合にのみ、タスクを細かく分割することが可能です。それ以外の場合、見積もりは大まかな推測であり、通常は 2 週間です。これは、ほとんどの開発者が使用する有名な 2 週間です;)
プロジェクトの最後に、integrate-stabilize-bug fix に時間を追加すると、妥当な見積もりになります。
私は主に「より短い」期間のプロジェクトに取り組んできましたが、私にとってうまくいったことは、タスクを十分に小さなサブタスクに分割して、それぞれを約1日で実装できると思うことです。いくつかのアイテムでは、これは 2 つまたは 3 つのサブタスクを意味するだけであり、他のアイテムでは、これは数十または数百を意味する場合があります。非生産的な活動に浪費されるオーバーヘッドのパーセンテージと、間違った方向性を調査するためのオーバーヘッドを追加すると、最終結果の妥当な範囲内の数値が得られることを願っています.
サーノルドが言及しているのと同様に、タスクを分解することが重要です...しかし、関連するドメイン/テクノロジーを理解していない場合、1日単位で細かく分割するのは難しいかもしれません。あなたの場合、私は次のことを提案します（特に、これが完了するのに数日もかからないタスクであると明らかに思われない場合）：
1）まず、チームや同僚に光を当てることができるかどうか（および/または使用しているのと同じAPI /テクノロジーを使用しているかどうか）を尋ねる必要があります。誰も何も知らない場合は、合理的な推測を危険にさらすのに十分なデータがないという事実を理解する必要があり、調査にX日を費やす必要があります（調査にかかる時間は使用しているAPI/ドメインの複雑さに合わせて）
2）新しいテクノロジーを調査するために割り当てた時間の終わりに、APIを使用する（コンパイル、リンク、および正常に実行される）非常に基本的なhello、world-ishタイプのアプリケーションを実行できるはずです。この時点で、タスクに数日、数週間、または数か月かかるかどうかを判断するのに適した位置にいるはずです。
3）次に行うべき重要なことは、できるだけ早く、予測を吹き飛ばそうとしている主要な障害/一時的な中断を特定することです...これが重要です。あなたができる絶対的な最悪のことは、期日に継続的にあなたのマネージャー/顧客に行き、あなたが配達するのにかなりの追加の時間が必要であると言うことです。状況を改善したり、プランBを考え出したりするために、できるだけ早く頭を上げる必要があります。
そしてそれはほとんどそれです...それはロケット科学ではありませんが、あなたがそれを与える立場になったら基本的にあなたは見積もりを提供し、そしてあなたに重大な影響を与える新しい予期しない出来事に基づいてその見積もりを更新することを確認してください予想される日付を作成する機能。