アプリをあるプラットフォームから別のプラットフォームに移動するなど、多くの不明な点があるプロジェクトに取り組んでいます。
私の当初の見積もりはかなり外れており、これがいつ終了するかを確実に知る方法はありません.
そのようなプロジェクトを見積もることができないことにどう対処すればよいでしょうか。画面にボタンを追加したり、Web サイトをデザインしたり、アプリを作成したり、バグを修正したりしているわけではありません。これらはバグのあるメソッドではなく、コード全体で行われた仮定であり、もはや正しくなく、段階的に発見され、それぞれが分析され、さらに多くの未知数で軽減されます。
私はたまたまソフトウェア推定に関する修士論文を書いており、学んだ教訓があります。
-1 回目のカウント、2 回目の計算、3 回目のジャッジ - これは、最初に、ファイル、クラス、LOC、UI などのカウント可能な作業項目を特定しようとすることを意味します。次に、このデータを使用して労力 (人/日) を計算します。最後の手段として判断を使用してください。
-あなたの見積もりを文書化してください！数字を表示します。これにより、リスクが最小限に抑えられるため、結果を自分の意見としてではなく、多かれ少なかれ客観的な数値として提示できます。（一般的に、紙の量が多いほど裏面がきれいになります）
・見積もりは約束ではありません。コミットメントは 1 つの数値であり、推定値は常に範囲です。したがって、推定値を範囲として指定してください (範囲を適切に選択するには、円錐形の不確実性を使用してください http://www.construx.com/Page.aspx?hid=1648 ) 。
・分割：WBSを利用し、作品を細かく分割して別々に見積もる。細分性は全体の長さに依存しますが、作業パッケージの魂はせいぜい全体の労力の 10% を超えることはありません。
-最初に工数を見積もり、次にスケジュール、次にコストを見積もります。
- 見積もりを計画のサポートと見なし、各プロジェクト フェーズで再見積もりを行います (s. 不確実性の円錐)。
http://www.stevemcconnell.com/est.htmという本をお勧めします。この本では、これらすべてのポイント、特に、あなたからコミットメントを引き出そうとする上司への対処方法を扱っています。
よろしく、 バレンティン・ハイニッツ
それを知る方法がないので、正確な見積もりを思い付くための本当に正しい答えはありません。
作業自体の見積もりについては、各ステップを個別のサブステップに分割する方法を検討し、チャンクを小さく目立たなくして、できるだけ多くの作業の全体像を把握できるようになるまで、それらをさらに小さく分割します。の健全な見積もりを与えるのに十分です。可能であれば、着陸できる場所の範囲を取得するために、予想時間と最悪の場合の時間の両方を考え出します。
これにアプローチする別の方法は、古いシステムを無視することです。それは頭痛のように聞こえます。古いシステムをスクレイピングして新しいシステムを最初から実装するか、サードパーティを既成のソリューションに統合することを見積もります。このために行われるべきケースがある場合は、少なくとも調査する価値があります。
SOではなくpostsecretの投稿のように聞こえます。:)
私は彼に、それが終わったらやると言います。それで十分でなければ、彼はプログラミングを学び、あなたを助けることができます. それからまた、クビになるかもしれないと思いますが、そのほうがいいかもしれません。
あなたが私たちに言ったことを多かれ少なかれ彼に伝えてください。プロジェクトは不安定すぎて正確な見積もりを出すことができません。あなたができる最善の方法は、特定のタスクの見積もりを出すことです。タスクの数が不明である限り、見積もりになります。彼が給料に見合った価値があるなら、彼はでっちあげの数字よりもむしろこれを聞きたいでしょう。これは、大規模なレガシー コード ベースを扱う場合には珍しくありません。