タスクの所要時間を見積もるために使用する適切な時間の分解能は何ですか?
0.5、1、2、5 日のようなものですか、それとも 0.5、1、2、4 時間のように数時間に減らしてから数日まで続ける必要がありますか?
ラベル テキストの変更はタスクである必要がありますか? ( ETA < 1 分 )
提案?
タスクの所要時間を見積もるために使用する適切な時間の分解能は何ですか?
0.5、1、2、5 日のようなものですか、それとも 0.5、1、2、4 時間のように数時間に減らしてから数日まで続ける必要がありますか?
ラベル テキストの変更はタスクである必要がありますか? ( ETA < 1 分 )
提案?
スクラムは、0、0.5、1、2、3、5、8、13、20、40、および 100 の値を使用します。値の時間は、より詳細に計画する場合 (機能要求を技術的なチケットに分割する場合)、時間単位です。そして、より大きな絵 (全体像の特徴) を計画する日。
一般に、20 時間 (または 20 日) を超えるチケットを見積もる場合は、タスクをより小さな部分に分割する必要があります。
まあ、それは本当に依存します。個人的には、タスクを小さくするのが好きです (通常、フィボナッチ数列に近いものを使用して、時間単位で見積もる必要があります: 0.5、1、2、3、5、8、...)。
小さなタスクについては、通常、それらも見積もる必要があります。マイナーな変更でさえ、テストの作成、他のどれも壊れていないかどうかの確認、サーバーへの送信などの作業が必要です。これらのようなもののためにシリーズで 15 分間を作成できます :)
未来を予測するのは本当に難しい。
単位 (分、時間、日、週、2 週間) は関係ありません。
あなたのマネージャーを幸せにするユニットを選んでください。
30 分、0.5 時間、または 0.0625 日という見積もりは単なる推測であり、事実ではないことを明確にしておいてください。
0.0625 日または 30 分という推定値は、小数点以下の桁数が多いため、非常に正確に見えます。ただし、要件、アーキテクチャ、言語、ライブラリ、単体テストなどに関するあいまいさがあると、この数値は不正確になります。
あなたが望むことができる最善のことは、すべての見積もりの平均が実際の事実にかなり近いことです. これは、見積もりの半分が低すぎ、半分が高すぎることを意味します。それはまた、あなたの見積もりの一部が、あなたのマネージャーが期待する正確さとはかけ離れていることを意味します.
必要な時間を計画して見積もることはプロジェクトの目標ではないため、これらのユニットは何らかの目的を果たさなければなりません。
使用する良いルールは次のとおりです。次に何をすべきかが正確にわかるまで、タスクを小さなチャンクに分割します(そして、それは計画的ではありません)。この「何をすべきかを正確に知る」ことは少し主観的ですが、2 日を超えるタスクがこのカテゴリーに当てはまることはめったにありません。
どれだけ正確になりたいかによると思います。
私は個人的に分を使用します。「日」または「月」は誤解を招く期間になる可能性があるためです。たとえば、何かに1日かかると言った場合、それは24時間の堅実な作業を意味しますか?または8時間?または、1営業日で平均3〜4時間の生産性がありますか?
すべてのタスクをリストする必要がありますが、タスクが小さい場合は、多くの場合、それらをグループ化できます。ただし、ラベルテキストを変更するだけなので、ラベルを変更するだけで時間がかかることを覚えておいてください。ラベルを見つけ、ファイルを開き、変更を加え、変更をコミットし、ドキュメントを更新し、テストする必要があります。ごくまれに1分未満しかかかりません。
また、タスク時間に上限を設けるようにしてください。3〜4時間以上かかるタスクを追加する場合は、それらをより小さなサブタスクに分割し、それらをリストします。これにより、はるかに正確な見積もりが得られます。
適切な場合は時間の単位を使用する傾向があります(1時間、4.5時間、6時間など)。日が方程式に忍び寄ると、私は時間を使用せず、使用される唯一の単位として日を維持する傾向があります(3d、7d、10d)。わずかに過大評価すると、途中で発生する望ましくないが予想される合併症に対応する余地があります。
タスクを次のカテゴリに分類していることに気づきました。
多くの第 2 レベルのサポートを行っている私の職場環境では、より詳細なシステムを使用しても意味がありません。また、作業環境を少し改善するために 1 時間かかるように、計画に余裕を持たせることもお勧めします。
推定作業量 (何かが完了するまでにかかる時間) と推定時間 (別名、期間) には違いがあります。
未来を予測することは決してできず、推定はあくまでも推定であり、最初の 6 つのタスクに 5 分かかるとしたら、1/2 時間単位で 1 週間を予測できる可能性はそれほど高くありません。完了まであと 1/2 です (3 時間の作業後)。
ワーク ブレークダウン ストラクチャー (WBS) を作成して工数を決定し、タスクを 1 日以上、1 週間以下のグループにグループ化することをお勧めします (プロジェクトの全体的な期間によって異なります。次に、全体の作業工数の 2 ~ 3%)。これにより、プログラムは、特定の 1/2 時間の配達を満たさなければならないというプレッシャーなしに、タスク (通常の作業条件) を切り替えることができます。