ソフトウェア開発における日常作業の量とその推定への影響

私は、ソフトウェア開発における日常的な作業の量は、無視できないとはいえ、比較的小さく、そしてそうあるべきであり、これがソフトウェア推定の基本的な問題であると確信しています。

この結論に至った経緯を説明し、議論に重大な欠陥があるかどうかを教えてください。

1. 高精度で推定できるのは、以前に行われたことを意味する日常業務です。研究と創造性を含む他のすべての種類の作業は、少なくとも+/- 20％の精度では、実際には推定できません。

2. ソフトウェア開発とは、繰り返し作業を避けることです。その基本原則の1つはDRYです（繰り返さないでください）。プログラマーが繰り返し作業をしていることに気づいたときはいつでも、この繰り返しを回避する抽象化を見つける時が来ました。これらの抽象化は、繰り返しコードを関数に抽出したり、ループに入れたりするような単純なものにすることができます。また、ドメイン固有の言語を作成するなど、より複雑にすることもできます。いずれにせよ、それらの実装には、研究（これを以前に行ったことはありますか）または創造性が伴います。

これらの2つのポイントから、上記の結論を導き出します。

実際、私はこの関係が他のすべての議論、ブログ投稿、またはソフトウェア推定に関する記事で言及されていない理由をかなり長い間疑問に思っていました。理論的すぎますか？私の仮定は間違っていますか？それとも、ささいなことですが、なぜ私が知っているほとんどの開発者は、+ /-20パーセント以上の精度で見積もることができると信じているのですか？

どのプロジェクトでも、これは真実かもしれません。ただし、長年にわたってさまざまな企業で複数の類似したプロジェクトに取り組んでいる場合、基本的に同じ問題をわずかな違いで何度も「解決」することに気付くことがあります。

たとえば、データアクセスレイヤーを何度も書いたので、今月人気のORMを使用するのではなく、「ロングハンド」で行うことを好みます。サードパーティのコンポーネントの新しい癖を見つけて解決するよりも、既知のソリューションで「定期的な問題」に対処する方が迅速かつ簡単です。

明らかに、他の誰かのシステムに未知の癖を追加せずに反復コードを単純化するために独自のORMを書くことができましたが、このコードは当時働いていた会社に属し、他の開発者はそれがその他のサードパーティORM。

同様に、私の経験では、ほとんどのプログラミングはビジネスプロセスの自動化であり、各ビジネスはそれぞれのプロセスが自分に固有のものであると考えるのが好きです。実際にはそうではありません。

推定が簡単だと言うまでもありません！簡単ですが、最近の見積もりの​​問題は、コーディングに費やした時間ではなく、要件が不十分であることが原因であることがわかりました。

要件は、次の3つのカテゴリに分類される傾向があります。

1. あいまい、詳細は開発者に任されています。

「私をウェブサイトにしてください。クールでウィジェットを売らなければなりません」

予想外の難しい問題が発生した場合、要件を機能的に同等なものに変更して問題を回避できるため、これらは最も簡単に推定される傾向があります。

2. 非常に具体的

「ヘッダーの背景色を＃ff1100にする」

非常に迅速に、また簡単に推定できます。だが！要件は変更する必要があります。「うーん、もう考えないで、このもう1つの赤を試してみてください」または「待ってください！私はその1ページでしか意味がありません！」そのため、「ヘッダーの色に満足するまでの時間」のリアルタイムスパンは、コーディングの見積もりとは関係ありません。

3. あいまい、詳細を想定

「ウェブサイトにする（facebookのように）」

ここでは、「もちろん、別のロゴが必要」、「無限のスクロールが必要」、「10億人のユーザーにスケーラブルである必要があります！」という多数の無言の仮定があります。見積もりを効果的に制御します。開発者がすべてを考えて、推定値を「1 meeelion man hours」よりも上に押し上げるか、ベースフィーチャのみが必要であり、推定値が低すぎると考えます。「ああ、一週間か二週間、Facebookをiframeに入れたいだけだと思う​​？」

経験上、コーディングは非常に高速ですが、設計要件は（通常）難しい部分であり、これはますます非コーダーに押し戻されます。アジャイル方法論では、この責任を開発者ではなく「ビジネス」に移すことでコーディング速度を向上させています。

私が知っているほとんどの開発者は、なぜ+/- 20パーセント以上の精度で見積もりができると信じているのですか？

私たちは問題に対する忍耐力を実際の問題よりもはるかに多く見積もっているからです。

バウンドするボールをアニメートする場合、1日、1週間、1か月、または1年を費やして、バウンドするボールのアニメーションのみを作成できます。より多くの時間を費やせば良くなることを願っていますが、ある時点でばかげています。

ボールをバウンスさせるためにどれだけの労力を費やすかは、それに費やすのに妥当な時間の関数です。私のスキルレベルがそれをカットしていない場合、私はちょうどそこに座っているボールになるかもしれません。しかし、締め切りが来たら、締め切りを遅らせるか、少なくとも画面上でボールを取得する必要がありますか？滝はボールの跳ね返りを主張したため、スケジュールはずれました。アジャイルは、ただそこにボールを出すと言います。少なくとも、バウンスを気にする人の数はわかります。そのため、品質が低下しました。

私はボールがバウンドすることを確認しようとしますが、締め切りが近づいたら、何もしないよりも静的なボールを作る方が良いです。したがって、代替案について話す前に問題に費やすのに妥当な時間と思われるものに基づいて、時間を推定します。ボールが跳ね返らない場合があります。時々それは大丈夫です。1か月間消えても大丈夫ではありません。