ジェフの最近の記事は、時間管理のパレートの法則（または80/20ルール）について説明したFirst Fit Decreasingアルゴリズムの時間管理の例にリンクしています。つまり、作業の80％が20％で生成されます。私たちの時間。
今、私たちは皆、プログラマーの引用を聞いています：
コードの最初の90％は、開発時間の最初の90％を占めています。コードの残りの10％は、開発時間の残りの90％を占めています。
しかし、冗談はさておき、コードの20％がやりたいことを実行し、残りの80％が例外を処理するように見えることがよくあります...では、80/20の法則は本当に開発者に適用されますか？
なぜそれが私たちに当てはまる/当てはまらないのかという例はありますか？
ホフスタッターの法則が適用されると思います。
ホフスタッターの法則を考慮に入れても、常に予想よりも時間がかかります。
-ダグラス・ホフスタッター
さらに深刻なことに、クリティカルチェーンプロジェクト管理を見てください。プロジェクトの各ステップに2つの見積もりを与えることをお勧めします。1つは、すべてがうまくいけば会えると約50％確信しているという楽観的な見積もりです。もう1つは、失われた時間と間違いを考慮に入れた、より現実的な見積もりです（言い換えれば、著者を責めないでください）。時間の経過といくつかのプロジェクトでは、どの見積もりがより正確で、どれだけの見積もりであるかを学びます。開発者によって異なるため、追跡する必要があります。
絶対！私の時間の80％はstackoverflow.comに費やされており、20％は実際に働いています。
奇妙なことに、私の生産性はこれまでと同じです...
...これまでと同じです！
;-)
ユニットテストの作成とクライアントへの機能のデモを2時間早く行うことで、デバッグと書き換えにかかる時間を8時間節約できます。
私の意見では、Kozyarchukはそれを正しく理解しています：
問題は、不十分な/不可能な範囲の見積もりであるため、それほど不十分な時間の見積もりではありません。
コードの有効性をテストしながら、できるだけ早く結果または結果のモックアップを顧客/マネージャーに示すことで、目標/要件の理解が深まります。
覚えておいてください:プロジェクトが最初に開始されたときにアナリストが知っている要件を満たした場合ではなく、プロジェクトが完了したときに「顧客を満足させる」場合、プロジェクトは成功です。
当然、これは「動くターゲット」がルールであり、悪いことではなく、恐れる必要がないことを意味します。また、プロジェクト リーダー / アーキテクトとして、スコープの変更にかかる費用が伝達され、カバーされることを確認する必要があることも意味します。
これはどのように行われますか？
これは常に機能しますか？いいえ
なぜ80/20の法則について尋ねるのですか？90/90の法則を正しく引用しました。90/90ルールが開発者に適用されることはすでにご存知でしょう。
（冗談ではなく事実で返答して申し訳ありません。）
私は自分の時間の 20% をやりたいことに費やし、80% をリファクタリングに費やしています。
ですから、最初の 20% で「機能する」と考えれば、そうです。しかし、最後の 80% は、再利用可能であり、維持する価値があり、将来 (負担ではなく) 使用する楽しみがあります。
Pereto の原則は開発者に多く当てはまります。作業の 80% は 20% の開発者によって行われていると言う人もいます。また、バグの 80% は 20% の開発者によって生成されます。さらに、20% のユーザーが 80% の機能を使用しています。これらは私が聞いた例です。
私はトカゲのビルと一緒です。非常に予期しないこと、またはおそらく考慮されていないことが原因で、常に予想よりも時間がかかります。
はい、開発には 80/20 の法則が適用されますが、別の方法で解釈する必要があります。