最近、新しい問題が発生しました。私が慣れていないフレームワーク(および場合によっては別のフレームワークの一部)を使用する必要があるプロジェクトの見積もりを提供するためです。私が慣れているものを自由に使用するときは、見積もりを提供する方がはるかに簡単ですが、見知らぬ領域での作業の見積もりが要求されたとき、分析による障害のある麻痺が発生したかのようでした。
振り返ってみると、私の解決策は間違っていました。私は働き始めただけです。
使い慣れていない言語/テクノロジー/フレームワークで作業する必要がある場合、プロジェクトとタスクをどのように見積もればよいでしょうか?
アジャイル教科書からの標準的な答えは、スパイクを実行することです。スパイクとは、未知のものを探索するためのタイムボックス型のタスクであり、最終的には、(うまくいけば)有用な推定値を提供するのに十分な情報が得られるか、そのポイントに到達するのに必要な時間をよりよく理解できるようになります。
スパイクは、1時間から数日、またはそれ以上にも及ぶ可能性があります。彼らはタイムボックス化されているので、どちらの当事者も関与するリスクはなく、支出は厳しく制限されています。
理想的には、急上昇中に、この新しいフレームワークで達成する必要があるいくつかの簡単なことを特定し、それを使用して非常に単純なソリューションを設定することになります。あなたが進むにつれて、あなたは学びます、そしてそれはスパイクがすべてについて何であるかです。
これを行う古典的な方法は、改良によるものです。最初の計画会議であなたは言う。
「私にはわかりません。ここでは基本的にソフトウェアの調査を行っています。ただし、次の会議までに1か月以内に、より適切な見積もりを出すことができます。」
その後、あなたは立ち去って調査を行います。次の会議:
「2四半期から4四半期まで何でもかかるようです。数値をさらに洗練させるプロトタイプを作成します。」.
次の会議:
「プロトタイプは私たちが思ったよりも簡単に構築できました。2四半期、1か月または1か月で実行できるようです。」
等々。各段階で、ビジネスはプロジェクトを缶詰にするか、継続させるかを選択できます。これにより、完了日をより正確に見積もることができます。
これは、Steve McConnellのすばらしい本 Rapid Development で非常によく説明されています。確かに、私が読んだ「アジャイル」に関する本のどれよりもはるかに優れています。
あなたは研究を行うことができ、それでも間違った見積もりを思い付くことができます。 J. P.ルイスによるL ソフトウェア推定の大きな制限 、および付随する資料 ソフトウェア推定の数学的な制限 を参照してください。見積もりや調査に煩わされるべきではなく、客観的に正確な見積もりを行うことができないと言っているのではなく、到達した見積もりと一緒にこれを言う必要があります。