エビデンスベースのスケジューリングを使用した計画および技術設計の時間の見積もり
私は大規模な組織で開発プロジェクトを始めています。
機能要件は現在、エンタープライズ設計部門によってビジネスの利害関係者と一緒に作成および文書化されています。
テクニカルデザインドキュメントを作成し、チームを管理して実際にソリューションを構築する必要があります。
試してみたい エビデンスベースのスケジューリング しかし、私が理解しているように、その一部は、ジョブを14時間未満の小さなタスクに分割することです。これには、すでに実行している必要があります。テクニカルデザイン。
したがって、エビデンスベースのスケジューリングは、技術設計が完了した後にのみ使用できますか？
次に、テクニカルデザインを考案するのにかかる時間をどのように計画および見積もりますか？
したがって、エビデンスベースのスケジューリングは、技術設計が完了した後にのみ使用できますか？
何を構築するのかわからない場合、どのくらいの時間がかかるのかをどうやって知ることができますか？
そうです、あなたは間違いなく少なくともドラフトのデザインを持っている必要があります、そしてあなたはあなたのチームのプログラマーに任せる必要がありますそれらの部分を推定するために（ 記事 あなたがリンクしたように）。また、同等のプロジェクトの経験が必要です。そうでなければ、チームの見積もりと現実の関係がわかりません。以前の経験がない場合は、計算の基礎となる証拠が得られるまで待つ必要があります。
次に、作業を進めながら設計を改良すると、見積もりが改善されます。いつでも、あなたのスケジュールは可能な限り良くなります。それは推測や希望ではなく、証拠に基づいています。
エビデンスベースのスケジューリング、またはストーリーポイントと速度などは、単純な線形推定量の単なる空想の言葉です。X％の量のジョブを実行するのにT時間がかかった場合、（1-X）* T/Xの可能性があります。残り時間-作業の合計量が一定である場合。この種の推定量は、次の理由で人気があります。
- とても簡単です。
- 実際にはかなりうまく機能することがわかっています。
- 過去の技術設計の労力を対応するエンタープライズ設計のサイズと相関させると、証拠ベースのスケジューリングを使用して、技術設計自体にかかる時間を見積もることができます。それは、異なる種類の仕事に適用されるのと同じ原則です。
- 仕事をどれだけうまく分解しなければならないかという特定の制限は実際にはありません。分解が少なければ少ないほど、見積もりの精度は低くなります。エンタープライズ設計を使用すると、簡単に数回離れることができます。しかし、ビジネスマンは、交渉を継続し、設計の労力を危険にさらす価値があるかどうかを知るために少なくとも何かを必要とすることがよくあり（プロジェクトが高すぎることが判明した場合）、過去のプロジェクトのサイズを企業の設計のサイズと相関させることが最善の方法ですその場合はそれら。