estimation - 見積もりプロセスをどのように改善しますか?

Question

特定のタスクにかかる時間を見積もることは、ソフトウェア開発で最も難しい部分の 1 つに思えます。私の現在のショップでは、イテレーションの開始時にタスクを時間単位で見積もりますが、タスクが完了すると、それを将来の見積もりに役立てることはありません。

過去の見積もりから収集した情報をどのように使用して、将来の見積もりを改善しますか?

Answer 1

私がこれまでに見た、現実的なスケジューリングで最も興味深いアプローチの 1 つは、FogCreek FogBugz 6.0 リリースの一部であるEvidence Based Schedulingです。概要といくつかの例については、上記のリンクにある Joel のブログ投稿を参照してください。

Answer 2

見積もりが外れてしまった場合は、それがランダム (環境が壊れた、トリッキーなバグなど) だったのか、それとも特定できなかった何かがあったのかを特定してみてください。

見積もりが大きすぎる場合は、時間がかかると思っていたものを特定し、なぜそうならなかったのかを突き止めます。

それを十分に行うことで、開発者の見積もりに役立つことを願っています。

たとえば、開発者がコントローラーのテストの作成には時間がかかると考えていて、最終的には想像していたよりも時間がかからなかった場合、同様のスコープのコントローラーに対して行う次の見積もりは、それを念頭に置いておくことができます.

Answer 3

見積もりが外れている場合は、ほとんどの場合、明らかな原因があり、教訓が得られます。記憶からの最近のもの：

• ユーザー インターフェイスは、存在しない .NET 機能 (新しい行を挿入し、GridView でインラインで編集する機能) を想定していました。学んだ教訓は、見積もりを行う前に、選択したクラスの機能を検証することです。この間違いで 1 週間かかりました。

• ftp プロセスは、FtpWebRequest が銀行の安全な ftp サーバーと通信できると想定していました。ftp サーバーが現在のディレクトリのバックスラッシュ以外のものを返す場合、このクラスには既知のバグがあることが判明しました。学んだ教訓は、「チュートリアル」と「例」だけでなく、クラス名で「バグ」と「問題」をグーグルで検索して、「落とし穴」が潜んでいないことを確認することです。この間違いで 3 日かかりました。

これらの教訓は、プロジェクトの見積もりと開発の「チェックリスト」ドキュメントに組み込まれるため、次のプロジェクトで忘れられることはありません。

Answer 4

コンセンサスに達するまで、チームメイトと繰り返し見積もりを行います。確かに、私たちは間違いを犯しますが、「速度」係数を明示的に計算するのではなく、新しい見積もりの​​議論で収集した経験を使用します.

Answer 5

時間を見積もることで、ここまで到達できることがわかりました。他のタスクの中断、予期せぬ状況、またはプロジェクトの影響により、必然的に時間枠が変更されます。また、常に再評価を行うと、いつ開発できるかを管理するのに多くの時間を浪費することになります。

したがって、ここでは、経験に基づいてソリューションの初期見積もりを行います (モデルは使用しません。私たちの環境で十分に機能するモデルは見つかりませんでした)。ただし、KPI をそれに対して判断することも、この締め切りに間に合うことをビジネスに保証しますか。ここでの私たちの開発アプローチは大部分が受動的であり、私たちのビジネス要件を非常によく満たしているようです。