estimation - ソフトウェア開発で 80/20 ルールを回避する方法

Question

私のプロジェクトが何であれ、私は仕事の 80% をかなり早く終わらせているようです。ユーザーと管理者は、物事が予定よりかなり進んでいると考えて興奮していますが、残りの厄介な 20% の作業は、前の 80% の 4 倍の時間がかかるようです。プロジェクトの定期的なチェックインやスタンドアップを行うと、「はい、これまでのところ順調に進んでいますが、まだやらなければならないことがかなり残っています...」と言って、記録が破られたように感じます。

ほとんどの場合、私の見積もりはかなり正確ですが、私は人間です。最後の 20% の作業に実際に 80% の時間がかかっていることをユーザーに納得させるための最善のアプローチは何ですか? IT は簡単で、指を鳴らすだけで魔法が起こると信じているユーザーや管理者が増えているようです...

一般に、私たちはかなり低いレベルであると私が信じているタスクを追跡します。必ずしもラベルやテキストボックスを作成する必要はありませんが、かなり詳細です...また、すべてのタスクの完了までの見積もりを追跡します。これは、プロジェクトの途中にある場合、元の見積もりよりも重要な数値だと思います.

それはユーザーと管理者の認識に帰着すると思います。彼らは見積もりを完全に知っているかもしれませんが、見ているものに対する感情や認識にとらわれ、見積もりの数字は後回しになります。これが、期待を抑えたり管理したりする方法を見つけようとしているものです。

EDIT
これはかなり主観的であるため、コミュニティwikiに変わります。最初からそうすべきだった。

score 18 · Accepted Answer

18

完成したらすぐに最初の 80% を見せないでください。ドリップフィード。

于 2009-03-04T00:04:45.407 に答える

score 8 · Accepted Answer

ホフスタッターの法則を考慮しても、常に予想よりも時間がかかります

しかし、私は脱線します。

ベストプラクティスは悲しいことに経験です。SCRUM メソッドは、リリース日をより正確な日付に常に更新するため、一部の種類のソフトウェア開発に非常に役立ちます。(スクラムについての簡単なビデオ)

score 8 · Accepted Answer

おそらく、作業のスケジューリングとチェックイン/レポートの両方のために、作業中のタスク/機能を小さな単位に分割する必要があります。たとえば、私のスケジュールには、2 日以上続く個々の項目はほとんどありません。

その後、スクラムで 2 週間毎日「新しいマペットメーカーに取り組んでいます」と言う代わりに、「現在、マペットメーカーのアイセレクターに取り組んでいます」と言うことができます。

スケジュールに従って作業していて、スケジュールが正確である場合 (つまり、スケジュールが 80% と 20% の両方を占めている場合)、管理に問題はありません。あなたが「ほぼ完成」しているために割り当てられた時間を短縮できるとほのめかしている場合は、実装されていない仕様の部分を彼らに示してください。

何かが何をすべきか、どのように振る舞うべきか、そして対処しなければならないエッジケースを詳述する何らかの形式の機能仕様に基づいて作業していると思います。この場合、経営陣の感情や認識を心配することは私には非常に奇妙に思えます。彼らはスペックをあなたの仕事と比較するか、あなたのスケジュールを読んで何が残っているかを見ることができるはずです.

score 5 · Accepted Answer

時間の見積もりに関しては、これが私の経験です。

タスクにかかる時間が 4 時間未満であると断言できない場合、それを正確に見積もることはできません。それをより小さな断片に分割し、再帰的に繰り返します。
そのような時間の見積もりを作成することはピクニックではありません。時間がかかります。基本的に、プロジェクト全体を管理可能なチャンクで解決する必要があります。つまり、要件を変更すると、タイムプランが変更されます (驚くべきことですよね? )
最大の問題は、すべての詳細を予測できないことです (おそらく、おそらく 20% としましょう? 残りの 80% は推定されていません...) - 他の人がすでに指摘しているように、SCRUM を参照してください。
実行に「時間がかかりすぎる」ため、経営陣はそのような詳細な時間の見積もりを「受け入れる」ことはめったにありません。

しかし、経営者は利益を上げることに関心があるため、手を抜くことにも関心があります。そのため、関連する実際のシナリオに基づいて、カットして高度な妥協を行うことができるコーナーを特定する必要があります。経営陣の支援があれば、最後の 20% の多くは何もせずに達成できます (ある意味悲しいことですが、それでも真実です)。

最終製品の最後の 20% に相当する作業の最後の 80% は、実際にはバグの修正と修正、および変更された要件への適応などであるためです。限定的な最初のバージョンなどを作成することは可能かもしれません。 .

score 5 · Accepted Answer

仕事量はどうやって見積もるの？「厄介な残りの 20% の作業は、前の 80% の 4 倍の時間がかかるように見える」と言うが、どのようにして「20%」の作業が残っていて、「80%」が終わり？明らかに、見積もりは間違っています。実際には、作業の 20% しか完了しておらず、80% が残っています。

ソフトウェア開発では、かなり前から正確な見積もりを出すことは非常に困難です。唯一の方法は、作業を扱いやすい小さな部分 (それぞれ 10 時間未満) に分割することです。すぐ次のステップのみを正確に見積もることができます。

スクラムには、進捗状況の見積もりに役立ついくつかのプラクティスがあります。次のスプリント (1 か月以内) で実行される作業の範囲は、スプリントの開始時に決定され、各作業に大まかな見積もりが与えられます。次に、スプリントの後、チームはどれだけの進捗があったか、まだどれだけ不足しているか、見積もりがどれほど正確であったか、何がチームを遅らせているかを振り返ることができます。スクラムやその他のアジャイル手法では、何が完了したか、プロジェクトのどこまで進んでいるかについてのフィードバックを迅速に得ることが重要なポイントです。それらについてもっと読むことをお勧めします。Ólafur Waage が彼のメッセージでリンクしたスクラムに関するビデオは、適切かつ迅速な紹介を提供します。

score 4 · Accepted Answer

Steve McConnell の優れた本Rapid Developmentを読んでください。この本には、80/20 の問題やその他のソフトウェア予測の気まぐれについて多くのことが書かれています。

score 3 · Accepted Answer

私は、 JoelがPainless Software Schedulesで述べた以上にうまく言えるとは思いません。

マネージャーが見積もりを下げるように要求した場合は、次のことを行ってください。スケジュールに Rick's Estimate という名前の新しい列を作成します (もちろん、あなたの名前が Rick であると仮定します)。そこに見積もりを入力します。Curr Est 列を使用して、マネージャーがやりたいことを何でもできるようにします。上司の見積もりは無視してください。プロジェクトが完了したら、どちらがより現実に近いかを確認します。これを行うと脅すだけでも効果があることがわかりました。特に、あなたのマネージャーが、あなたがどれだけゆっくり仕事をすることができるかを競うコンテストに参加したばかりだと気付いた場合はなおさらです。

score 2 · Accepted Answer

プロジェクト時間の最初の 90% は 90% の作業に使用され、プロジェクト時間の残りの 90% は残りの 10% または作業に使用されると言われています。;)

最初に最も簡単な部分を実行するだけなので、プロジェクトの開始時に大きな進歩を遂げるのは自然なことです。また、コードの最初の 80% に問題がある場合、すべてがまとまり、すべてのコードを実際にテストできるようになるまで、問題が明らかにならないことがよくあります。

おそらく、経験者として、90% 完了したアプリケーションを人々に試してもらい、最後の 10% がどのような違いをもたらすかを確認する必要があります...

score 2 · Accepted Answer

時間の見積もりに非常に役立ついくつかのことを発見しました

コードベースに精通していること。仕様を聞いて、「クラス A、B、および C に触れる必要があります。それ以上でもそれ以下でもない」と考えることができれば、かなり正確になります。これは、どの特定の関数を記述する必要があるかを知るよりもうまく機能すると思います。なぜなら、何を記述する必要がないかがわかるためです。
テスト、バグ修正、展開、直前のリクエストを含めることを忘れないでください。大量のレコードを移行する必要があることを忘れがちです。
ある程度、言語に精通していること。どのライブラリが必要になるかがわかれば、何をする必要がないかを簡単に知ることができます。

私はこれを同僚の速度の概算にもかなりうまく使用しました.実際にテストする前に、機能を開発する速度と機能の良さについて経験的な観察が必要です.

score 0 · Accepted Answer

時間範囲を短くしてください。今後数か月よりも、今後数週間で何をするかを予測する方が簡単です。プロジェクトを短いマイルストーンに分割することを検討してください。1 か月またはおそらく数か月は、何をしようとしているのかによって異なります。これは基本的にスクラムが行うことです。次に、現在のマイルストーンで行う予定の作業のみを最も正確に見積もります。次のマイルストーンに到達したら、見積もりを再見積もりし、見積もりの基礎となるデータがさらに多くなるようにします。最後の 20% に非常に時間がかかる理由の 1 つは、十分な知識がないときに事前に見積もりを作成している可能性が高いことです。

また、Wideband Delphi推定手法を試してください。これにより、おそらく考慮していない隠れたコストがさらに明らかになります。

score 0 · Accepted Answer

「はい、これまでのところ問題はありませんが、まだやらなければならないことがかなり残っています...」と言うのは、あなたの主張を伝える最良の方法ではないかもしれません. マネージャーやクライアントが「はい、やるべきことはかなり残っていますが、彼はこの部分を非常に速くやったので、残りは最小限です」と考えるかもしれないと聞いた後.

代わりに、残りの作業を特定してスケジュールを設定してください。このようにして、プロジェクトの残りの 20% でどこにいるべきかを示すことができます。時間がかかりすぎると、プロジェクトが予定より遅れていることがスケジュールに表示され、切迫感が高まるはずです。

タスクを毎週更新します (または定期的にステータスレポートを作成します)。特に他の領域がそれらに依存している場合、遅れる危険がある領域を特定します。

score 0 · Accepted Answer

約束を過小評価し、過剰に提供することができるのであれば、それが最善だと思います。

あなたの見積もりが正しければ、あなたは厄介な 20% を占めることになります。あなたは明らかにそうではありませんでした。それが問題である理由です。

たぶん、あなたは彼らが望むものすべてを彼らに与えようとしていますが、それは非現実的です. マーフィーの法則を十分に説明していなかったり、テスト、バグの発見、再テストなどに十分な時間を与えていなかった可能性があります。

もう少しリスク管理をした方が良さそうですね…

score 0 · Accepted Answer

最良の方法は、スケジュールを最新の状態に保ち、各タスクの完了率を維持することです。このように、進捗状況は非常に明確です。そのことを経営陣に伝えてください。そうすれば、彼らは常にあなたがどこにいるかを理解する必要があります。

score 0 · Accepted Answer

80% と 20% をまとめてタスクの見積もりを作成している場合、スタートは弱いと思います。見積もりを分割します。80% と 20% の 2 つの明示的なタスクを作成します。必要に応じて、簡単なビットと難しいビット。

その後、作業全体のより現実的な時間の見積もりを前もって提供し、プロダクションが詳細を追跡しやすくすることができます。

score 0 · Accepted Answer

計画するときは、それを考慮してください。サブタスクを実行するのにかかる時間を見積もるときは、「基本的に完了」ではなく「完了」の見積もりを出します (「完了」にかかる時間を経験から見積もります。統合、文書化、片付けを却下する誘惑に抵抗してください。、テスト、テスト後のバグ修正、展開などの小さなタスクとして、他のタスクに吸収されます。

あなたは恐ろしい大規模な見積もりで終わるでしょう。ただし、以前のプロジェクトに費やした実際の時間と一致していないかどうかを自問してください。

score 0 · Accepted Answer

可能な限り正確な見積もりを提示し、プロジェクトに可能な限りの透明性を提供してください。見積もりに一貫して近い場合は、マネージャーを満足させるのに十分なはずです. 生産性を測定するのは非常に難しいことを覚えておいてください。

score 0 · Accepted Answer

それはユーザーと管理者の認識に帰着すると思います。彼らは見積もりを完了するまで知っているかもしれませんが、見ているものに対する感情や認識にとらわれ、見積もりの数字は後回しになります。これが、期待を抑えたり管理したりする方法を見つけようとしているものです。

最初にアルゴリズムを書き、次に UI を書きます。

score 0 · Accepted Answer

最後の 20% の作業に最初の 80% の 4 倍の時間がかかっていることが一貫してわかっている場合は、技術的負債を積み上げていないかどうかについて、自分自身 (または信頼できる仲間) と率直に話し合う必要があるかもしれません。最初の 80% の間は上昇し、最後には苦しめられます。

これは、変更を検討できる作業慣行を示している可能性があります。

技術的負債を抑えるために私が知っている 2 つのベストプラクティスは、適切なテストを作成すること (できればコードを作成する前ですが、コードを作成した直後でも機能します) と、すべてのタスクの後にリファクタリングすることです。リファクタリングは、月末ではなく、毎食後のキッチンの掃除と考えてください。

estimation - ソフトウェア開発で 80/20 ルールを回避する方法

19 に答える 19

Related

Reference