なじみのない技術を使用して作業するときに見積もりを提供しますか

最近、私が知らないフレームワーク（および潜在的に別のフレームワークの一部）を使用しなければならないプロジェクトの見積もりを提供するために、新しい問題が提示されました。私が慣れ親しんでいるものを自由に使用できる場合、見積もりを提供することははるかに簡単ですが、慣れていない領域での作業について見積もりが要求されたときに、分析による障害のある麻痺が生じたかのようでした。

振り返ってみると、私の解決策は間違っていました。私はただ働き始めました。

なじみのない言語/技術/フレームワークを使用する必要がある場合、プロジェクトとタスクをより適切に見積もるにはどうすればよいですか？

アジャイル教科書の標準的な答えは、スパイクを実行することです。スパイクは、未知のものを探索するためのタイムボックス化されたタスクです。そのため、最後に、（できれば）有用な推定値を提供するのに十分な情報があるか、そのポイントに到達するのにどれだけ時間が必要かをよりよく理解できます。

スパイクは、1時間から数日、またはさらに長く続くことがあります。タイムボックス化されているため、どちらの当事者にもリスクはなく、支出は厳密に制限されています。

理想的には、スパイク中に、この新しいフレームワークで達成する必要があるいくつかの簡単なことを特定し、それを使用して非常に単純なソリューションを設定します。あなたが進むにつれて、あなたは学びます、そしてそれはスパイクがすべてであるものです。

これを行う古典的な方法は、改良によるものです。最初の計画会議であなたは言います。

「私にはわからない-私たちは基本的にここでソフトウェアの研究を行っている。しかし、私は数ヶ月後に次の会議でより良い推定をするだろう」

その後、あなたは離れて研究を行います。次の会議：

「2〜4四半期かかると思われます。図をさらに改良できるプロトタイプを作成します」。

次の会議：

「プロトタイプは思ったよりも簡単に構築できました。2四半期でプラスマイナス1か月でできるようです。」

等々。各段階で、ビジネスにはプロジェクトを缶詰にするか、継続させるかを選択することができ、完了日をより正確に見積もることができます。

これは、Steve McConnellの素晴らしい著書Rapid Developmentで非常によく説明されています。確かに、私が読んだ「アジャイル」に関する本のどれよりもはるかに優れています。

あなたは研究をすることができ、それでも間違った見積もりを思いつくことができます。JP Lewisによるソフトウェア推定の最大制限、および付属資料「ソフトウェア推定の数学的制限」を参照してください。客観的に正確な見積りができないというだけで、見積もったり調査したりするべきではないと言っているわけではありません。