ソフトウェアのスケジュールを定義するのが難しいのはなぜですか？

私の経験では、エンジニアに完了させるタスクを正確に見積もり決定させることは、歯を抜くようなものです。2〜3週間または3〜6か月の盗品の見積もりを与えるだけでなく、ソフトウェアスケジュールを定義する最も簡単な方法は何ですか？たとえば、顧客Aは2011年2月1日までに機能を希望しています。他のバグ修正が途中で必要になる可能性があることを知って、この機能を実装する時間をどのようにスケジュールし、追加のエンジニアリング時間を費やしますか？

使い慣れたツールと使い慣れたチームを使用して、他のプロジェクトとほぼ同じプロジェクトを開始し、しっかりした書面の要件が与えられている場合、適切な見積もりを行うことができるはずです。

これらは、画家、カーペット設置者、造園家などが定期的に経験する条件です。しかし、多くの（またはほとんどの）ソフトウェアプロジェクトには適していません。

新しいツール、テクノロジー、要件が変化する場所などを使用するプロジェクトを見積もることがよく求められます。これは、過去の経験に対する補間よりも、未知へのより多くの外挿です。したがって、推定がより困難になることは当然です。

私の個人的な経験によると、それはペムダスが言ったことの正反対です。実際、タスクに必要な時間を見積もることはまったく不可能だと理解しました。ソフトウェア開発でのキャリアの初めに、「45日間」、「5週間」などの見積もりを出すことがよくありました。数年後、「約1か月」、「5〜7週間」など、あまり正確ではない見積もりを出し始めました。実際、見積もりを出さないか、お客様に見積もりをお願いしています。または締め切りまたは私はできるだけ大まかな見積もりを与えます。

見積もりが難しいのはなぜですか？ソースコード全体が実際に書かれる前にどのように書かれているかを知ることはほとんど不可能であり、あなたの仕事は他の人々の仕事やあなたの動機などのランダムなものに依存しているためです。

1. 製品を実行するために必要なもの、特にその実行方法を正確に知ることは容易ではありません。非常に頻繁にアプリケーションの一部を開始しましたが、何日もの仕事の後、私の最初のアプローチが間違っていること、そして物事を行うためのより良いスマートな方法があることを理解しました。

2. いくつかの問題が発生する可能性があります。たとえば、作業を開始するために、マシンに派手なSQLサーバーをインストールする必要があり、インストールが失敗し、サポートが存在しない場合、この問題の解決に数週間かかる場合があります。

3. 多くの場合、要件は十分に明確ではありませんが、最初に要件を読んだ後は、要件が満たされていると思います。時々、あなたは平均「A」を理解でき、それらを実装し始めた後、「B」を意味するかもしれないことに気付くでしょう。

4. あなただけの関係部分を終えた正確に変化するようなお客様の要件、そしてあなたがする2週間以上と$ 2000要求している理由は、彼らが本当に理解していない小さな彼らはこのことを見ていないので、変更を小さな変更をする必要があり他のものを変更する必要がある他のものを変更するなど。

5. あなたの動機を推定できません。何時間も働き、うまくいく日があります。10行のコードを書いた後、プログラマーStackExchangeに切り替え、質問に答える時間を費やして数週間を費やします。

6. あなたの見積もりが他の人に依存しているとき、物事は本当に悪くなります。たとえば、ある2か月のプロジェクトでは、デザイナーが自分の仕事を終えるのをデザイナーが待つのを待たなければなりませんでした。このデザイナーは、使用できないがらくたを届けるまでに3か月かかりました。もちろん、プロジェクトは遅れました。

7. お客様の見積もりもお客様に依存します。メールに返信する前に数週間を費やす顧客がいました。回答を待つ必要がある場合（たとえば、要件を正確に尋ねる場合）、スケジュールに大きな影響を与える可能性があります。

何ができる？

1. より大きなスケジュールを与える。あなたが2週間で仕事をすることができると思うならば、あなたは1ヵ月でそれを届けると言います。

2. 明確にしてください。デザイナーや他の開発者などに頼っているなら、それを言ってください。「製品を3か月以内に納品する」と言う代わりに、「デザイナーがPSDファイルを提供してから2か月後に納品する」と言います。

3. 要件が毎日変更された場合、プロジェクトが間に合わないことを説明します。

4. スケジュールをスライスします。大規模プロジェクトの一部を予定どおりに配信するのが簡単です。

5. よく知らない製品を使用するとき、または特に他の人のソースコードで作業するときは、推定値を与えないでください。それを理解し、The Daily WTFにコピーアンドペーストします。

よく似た質問は、「このクロスワードパズルを解くのにどれくらい時間がかかりますか？」です。

次のような多くのことを見るためにそれを見るまで、あなたはそれに答えることができません：

• 使い慣れた言語ですか？（スペイン語対英語対中国語）
• 以前に解決したタイプの1つですか？（たとえば、雑誌で実行されているシリーズの1つ）
• リードを理解する前に、追加の知識が必要ですか？
• パズルのどこかに、あなたの知る限り、追加の作業が必要になるものはありますか？

通常、プロジェクトにはいくつかの新しいものがあるので（そうでない場合はプロジェクトではありません）、それらを非常に注意深く見るまで、解決にどれくらいの時間がかかるかわかりません。たぶん多かれ少なかれそれらを解決したとしても、あなたはそれらを思いもしなかった驚きや二つがないことをまだ確信していません。

また、できる限り安く​​、それゆえにできるだけ早くそれを行うように強い圧力があり、低すぎる見積りに対する責任はプロジェクトマネージャーに圧力をかけるのではなく、開発者が見積りを与えることになります。開発者がこれをキャッチするのに多くの反復を必要とせず、絶対数を与えることに非常に疲れることを学習します。

エンジニアが正確な見積もりを提供できない最も明白な理由は、それが不可能だからです。

もちろん、自宅から職場までにかかる時間+ -2分を見積もることができます。車の運転方法、交通量、その他の外部要因を評価できます。

ロンドンからバルセロナまで運転するのにどれくらい時間がかかるか教えてください。もちろん、高度なGPS計画ツールはありません。まだソフトウェア推定で行っているような古き良き方法を使用します。経験的推定および予測。

ソフトウェアでは、さらに悪いことです。

1. 見積もりはしばしばコミットメントになるため、判断が変更されます。
2. 同じタスクに対するボブとカールの見積もりには大きな違いがあります。
3. 不確実性は非常に一般的であり、私たちのどれだけが愚かなバグやハードドライブのクラッシュに巻き込まれ、明らかな良い推定値を破壊します。
4. 通常、会議、電話、同僚の支援など、プログラミング以外のすべてのタスクを忘れます。
5. 人間の脳は限られています。長時間実行されるタスクを推定するようには設計されていません。

そのため、2011年2月1日に出荷できることを正確に顧客に伝え、2011年3月1日を忘れることはできません。

すべてのこれらの問題に対処するために、私はあなたのような高度な推定技術をお勧めプランニングポーカー：（免責事項これは私のウェブサイトの一つである）および反復的な開発と速度の計算。

• 最初の2つの問題は、Planning Pokerを使用して対処します。推定は集合的であり、チームは個人ではなくそれらを所有します。
• 最後の3番目の問題は、Velocity and Iterative Developmentを使用して対処されます。速度（履歴に基づいた推定に適用する要因）を知ることにより、より自信を持ってリリースを計画できます。反復的な開発は、うまくいけば、最も重要な機能を最上部にもたらし、ユーザーに価値を早期に提供するのに役立ちます。

ソフトウェア開発は、定義上、発見と発明の行為です。それは常に未知のものを含まなければなりません。

ソフトウェア開発に関連するすべてが知られているのは、ソフトウェアが完成したときだけです。

未知のテクノロジーやビジネス機能が存在しないのは、完全なパッケージ化されたソリューションがダウンロード可能な状態になっているときだけです。

新しいソフトウェアを作成する理由は、新しい機能または新しいテクノロジー、あるいはその両方を備えているためです。新しいとは、新しい-未知-予測不可能を意味します。

ソフトウェア開発には新規性が必要であるため、開発努力を予測することはできません。

正直なところ、練習が必要だと思います。最終的に十分なコードを記述する場合、「かなり」正確である必要があります。私の最初のボスは、このスキルは十分に重要であると信じていたので、実装したすべての機能/プロジェクトで非公式にこれを練習するよう要求しました。各プロジェクトの後、見積もりを確認し、どこが間違っているのかを突き止めようとしました。最終的に、あなたはそれのこつを得ます。

決して簡単ではありません。あなたはそれで良くしようとします。

成果物のコードを小さな断片に分割することの利点の1つは、クライアントが何を期待し、いつそれを期待するかを理解できることです。これで、参照として使用するための何らかのベースラインができました。

定義された時間に必要な機能の厳密な定義がある場合、追加のリソースをこの要求に割り当てる必要があることを知る必要があります。彼らは、発生するバグの重大度と、バグを修正せずに継続できる期間にリスクを冒しています。何か大きな問題が発生したら、クライアントに戻って決定を強制します。バグを修正するか、新しい機能の期限を設定しますか？十分な情報を与えて、十分な情報に基づいた決定を下してください。

うまくいけば、一緒に仕事をした十分な歴史があり、信頼できるほど十分に自分自身を確立したことを願っています。開発プロセスを完全に理解することを期待することはできませんが、正直な努力をしており、知識の不足を利用していないと感じさせることができます。

スケジュールが早すぎるからです。予備の大まかなものを実行することに関するConstruxの記事を参照してください。また、以前の見積もりでどのように行ったかを追跡しない場合、改善するのは困難です。FogBugzはそれを行います[無料の顧客、他の利益相反はありません]。

この本から多くのことを学びました。

ソフトウェアの推定：ブラックアートの謎を解く

要するに、より良い推定結果を得るためにこれを行います：

1. 些細なタスクを除くすべてが1人以上（この場合は2人）によって推定されます
2. タスクを小さなタスクに分割します。あなたが持っているタスクが多ければ多いほど、あなたの推定値は良くなるでしょう-私がブーイングから正しく覚えていれば、大きな数の法則
3. 最悪、最良、および最も可能性の高いシナリオを推定します。時には、私たち一人一人がこれらのツリーシナリオをまったく異なる方法で推定します。それは私たちが話さなければならないことを意味し、通常私たちのうちの1人がタスクを理解しなかったことが判明します。一人がタスクを単独で推定した場合、それは間違って推定されます。
4. 上記のポイントから3つの数値を方程式に入れて、推定値（excell）kを受け取ります

作業タスクが完了し、見積もりが間違っていた後、理由を見つけようとします。そして、この知識を次の推定プロセスに組み込みます。これまでのところ、これは、より大きなタスクの推定に使用した最高のプロセスです。タスクとは、約50〜500時間かかるジョブのことです。

注：これは実際には、固定/フラットレートではなく時間単位で請求するプロジェクトにのみ適用されます。

私は通常、スケジュールを計画して、SCRUMスプリントの集まりで構成されるようにします（SCRUMを使用するかどうかに関係なく）。スケジュールを立てる際に、各スプリントの長さとプロジェクトの機能を決定します。通常、最初に実行する必要がある機能がいくつかあるため、それらについて最良の推定値（楽観的と混同しないように）を提供しようとします。機能をスプリントにマッピングした後、プロジェクトの末尾に1〜2個のスプリントを追加して、右にスライドする機能と、元の要件収集で見落とされた機能を考慮します。

これの鍵は、クライアントに対してこのすべてを透過的にすることで、最後の2つのスプリントが空であるか、まばらに配置されている理由を理解することです。少なくとも私が一緒に仕事をしたクライアントは、SWの見積もりが具体的ではない傾向があることを知っているため、スケジュール/財務にある程度のクッションがあることを知っているため、これが気に入っています。彼らはまた、最後のスプリントなどが必要ない場合は、請求しない時間であることを認識しています。スケジュールの作成方法の透明性と、プロジェクトの実行中の進捗状況に関する定期的なフィードバックにより、私がこれを行ったすべてのクライアントは非常に満足しています。

名前が付けられたすべてのことに加えて、私はこれら2つのことを最大の問題の一部と考えています。最初に、週5日、1日8時間利用できるすべての開発者に基づいて最終日を見積もります。これは誤りであり、些細ではないプロジェクトの終了日が事実上100％保証されます。休暇を取る、会社（または非プロジェクトベース）の会議に出席する、健康保険請求をめぐってHRと戦う、休憩を取るなど、開発者1人あたり1日あたり6時間を超える空き時間を想定しないでください。

次の開発者は、プロジェクト、展開、QAサポート、UATサポート、ユニットテスト、調査、ドキュメントなどに関する会議やメールなど、開発以外のすべてのタスクの見積もりを忘れることで有名です。これらのタイプのタスクを見積もりスプレッドシートに追加したら、推定値が改善されました。

数時間以上かかるタスクの時間の見積もりに関しては、次のルールを使用するように最善を尽くします。

1. あなたがそれに依存するようになった場合、他の人がいつ仕事を終えるかを予測しようとしないでください。自分のためだけに話してください。
2. 最初にタスクを分析し、次に推定します。分析するということは、サブタスクのリストとそれらのそれぞれの推定値を少なくとも書き留めることを意味します（そして、すべてを頭の中に入れようとはしません！）。
3. タスクが十分に複雑な場合は、そのような分析自体の時間を見積もります。推定を別のプロセスとします。また、上司がそれについて知っていることを確認することもできます。
4. プレッシャーの下で推定しないでください。妥当な見積もりをするのに時間がかかることを明確にし、「明日、11：00までにタスクの分析を終了する日付を指定する」などのように伝えます。一部の顧客/管理者が一生懸命押すことができることは知っていますが、彼らは合格しません。忙しい顔をして時間を稼ごう！
5. 推定にコーヒーブレイク時間（およびその他の分散）を追加するのを忘れた可能性があるため、必要だと思うよりも少し長い時間を求めてください。
6. 大きなタスクの場合は、さらに多くの質問があります。おそらく、複数のコーヒーブレークがあります。
7. 本当に推定できない場合（タスクが難しすぎる/なじみがない場合）、または本当に不確かな場合は、分析の支援ができる人に依頼してください。

おそらくそれよりも多くのルールがありますが、実際には、このルールを壁に貼ったポスターはありません。私は今それらを定式化したが、それらは私の経験から来ている（だからあなたには役に立たないかもしれない）。

私が考えることができるソフトウェア開発をスケジュールする唯一の信頼できる方法は（しかし、実際には試していません）、エビデンスベースのスケジューリングです。これは基本的に、あなたがしたタスクに関する履歴前に達成しました。推定時間と実際の時間以外のメトリックを使用しようとしないため、良い感じです。ただし、大きなタスクを事前に小さなタスクに分割するには多くの経験が必要であり、十分に正確に機能させるためには大きな履歴データのセットが必要です。

「既知の未知数」と「未知の未知数」があります。:-)

1. 見積もりはしばしば締め切りになります。

   • 締め切りを逃して見出しになりたい人はいません！

2. 要件は（しばしば合理的に）変更され、プログラマーはそれを拒否することはできません。

3. プログラマーは、次のような要因を制御できる場合とできない場合があります。

   • 彼女が依存しているコードの可用性
   • 彼女が依存しているコードの品質
   • システムの全体的なアーキテクチャと設計
   • システムの他の部分にアクセスするためのAPI