証拠に基づいた計画

翻訳者のメモ： 元の記事は2007年に書かれましたが、私の意見では、今日でも完全に関連しています。

ソフトウェア開発者は、作業計画を作成することを好みません。 通常、彼らはそれを完全に放棄しようとします。 「終わったら終わります！」彼らは、勇敢で陽気な行為がボスによって承認され、計画がうまく忘れられることを期待して言う。



あなたが会う予定のほとんどは、ソウルレスな退会予定です。 完全に忘れられて、それらはある種の共有ディレクトリに保存されます。 数年遅れて製品をリリースした後、オフィスでファイルキャビネットを見たと言う奇妙な男が、失敗の理由を議論するために古いリストを持ち込み、誰もが笑います。 「見てください！ Rubyでシステムをゼロから書き直すために2週間を計画しました！」





ただ叫ぶ！ まだ浮かんでいる場合。



最大の利益をもたらすものに時間を費やしたいと思います。 そして、どのくらいの利益が得られるのかを理解するには、作業にかかる時間を知る必要があります。 アニメーションクリップと金融機能の数の増加のどちらかを選択せざるを得ない場合、各タスクを完了するのにかかる時間を知ることは害になりません。



開発者がアクティビティを正式に計画しないのはなぜですか？ これには2つの理由があります。 まず、それは大きなhemoです。 第二に、計画が現実に対応するとは誰も信じていません。 それでもうまくいかないのに、なぜ時間のスケジューリングを無駄にするのか。



過去1年間、フォグクリークの私たちは、最も肥満のプログラマーでさえ協力することに同意したシステムを開発しました。 そして、私が知る限り、それは非常に正確なスケジュールの作成につながります。 このシステムは、エビデンスに基づいた計画、またはDPと呼ばれます。 このアプローチは、実行された作業の統計の分析に基づいて、 証拠が収集され、将来の計画を立てるために使用されるという事実に要約されます。 その結果、製品のリリース日だけでなく、各時点での作業完了の確率分布の信頼曲線も取得できます。 次のようになります







曲線が急勾配になるほど、特定のプロジェクト完了日がより現実的になります。

方法は次のとおりです。

1.共有...

個々の作品が数日または数週間で測定されるスケジュールを見ると、意味がないことを理解しています。 計画されたアクティビティを、時間単位で測定される非常に小さなタスクに分割する必要があります。 最大16時間。



これは、本当にやりたいことを明確に理解するのに役立ちます。 サブルーチンfooを作成します。 ダイアログボックスを作成します。 Fizzbottファイルを解析します。 その結果、サブルーチンを作成し、ダイアログボックスを作成し、ファイル解析を実行したため、一般的なタスクの時間を簡単に評価できます。



不注意に3週間のタスク（たとえば、「Ajax Photo Editorの実装」）を作成すると、本当に何をしたいのかわかりません。 詳細に。 ステップバイステップ。 そして、行動の正確な計画が考え出されるまで、あなたはそれがどれくらいかかるかさえ知ることができません。



最大タスク期間を16時間に設定することにより、このいまいましい機能を考慮せざるを得なくなります。 しかし、「Ajax Photo Editor」と呼ばれる3週間の仕事を終えると、悪いニュースがあります。この瞬間から、あなたは公式に運命づけられています。 タスクを完了するための具体的な手順を考えることなく、必然的にそれらの多くを忘れます。

2.費やした時間を数える

正確な見積もりを取得することは困難です。 作業中のコンピューターにすべてを再インストールする必要がある場合、仕事、予測できないエラー、会議の計画、年に数回Windowsサービスを提供する日からあなたを引き離すあらゆる種類のケースをどのように考慮することができますか？ さて、どのように、これらすべてを知らなくても、特定のタスクを完了するのにどれくらい時間がかかるかを正確に言うことができますか？



実際、何もありません。



したがって、タイムシートを保持してください。 各タスクの作業時間を追跡します。 したがって、最初の推定値と比較してどのくらい時間がかかったかを振り返って計算できます。 開発者ごとに、次のようなデータを収集する必要があります







グラフ上の各ポイントは、推定リードタイムと実際のリードタイムを備えた1つの完了したタスクです。 見積りを実際のコストで割ると、見積りと比較してタスクがどれだけ早く完了したかがわかります。 時間が経つにつれて、各開発者の速度履歴を蓄積します。

• あなたの想像力にのみ存在する神話上の評価者は、常にリードタイムを正確に予測します。 彼の速度履歴は{1、1、1、...}のようになります
• 典型的な貧弱な評価者は、例えば{0.1、0.5、1.7、0.2、1.2、0.9、13.0}のような非常に幅広い指標を示します。
• もちろん、ほとんどの専門家は間違っていますが、一般的に彼らの評価は良いでしょう。 仕事は常に計画よりも長い時間を必要とします-エラーの修正、会議の計画、コーヒーブレイク、常に気を散らすその狂った人を考慮することは非常に困難です。 この典型的な評価者は、かなり安定した速度の値を示しますが、速度は1よりも小さくなります。 たとえば、{0.6、0.5、0.6、0.6、0.5、0.6、0.7、0.6}

専門家が経験を積むにつれて、評価の質が向上します。 したがって、たとえば6か月よりも古い累積速度統計を完全に削除することをお勧めします。



まだデータを蓄積していない新しい評価者がチームに来た場合、最悪の事態を想定します-彼が半ダースの実際のタスクに対処できるようになるまで、彼に幅広い速度で虚偽の物語を割り当てます。

3.未来をモデル化する

製品の正確なリリース日を計算するために単純にグレードを加算するという最初の誘惑に抵抗してください。 それは正しく聞こえますが、実際には根本的に間違ったアプローチです。 モンテカルロ法を使用して、多くの可能な結果を​​モデル化する必要があります。 モデリングプロセスでは、数百の可能な将来のシナリオを作成できます。 これらの結果はそれぞれ確率の1％に対応します。その結果、将来の各日付でプロジェクトが完了する確率のグラフを作成する機会が得られます。



特定の開発者の予想される結果を計算するには、問題の各評価を、ステップ2で収集したこの開発者の統計からランダムに選択した速度に分割する必要があります。たとえば、







100回繰り返します。各「合計」は確率の1％に対応します。これにより、特定の日付にプロジェクトが完了する確率を計算できます。



何が起こるか見てください

• 神話上の理想的評価者の場合、すべての速度は統一に等しい。 常に単位に等しい速度で除算しても、何も変わりません。 したがって、すべてのモデリングラウンドは同じ完了日を与え、この日付は100％の確率を持ちます。 おとぎ話のように！
• 悪い専門家の評価は非常にバラバラです。 これは、0.1または13.0のいずれかです。 シミュレーションの各段階では、他の段階とはまったく異なる結果が得られます。 確率分布曲線は非常に緩やかで、明日または遠い将来に等しく終わる可能性があります。 ちなみに、これは非常に有用な情報です。製品のリリース予定日がわからないことがわかります。
• 平均的な典型的な評価者は、たとえば{0.6、0.5、0.6、0.6、0.5、0.6、0.7、0.6}のような非常に近い速度のセットを提供します。 これらの速度で割ることにより、タスクに割り当てられる時間を増やします。たとえば、モデリングのある段階で8時間のタスクを13時間のタスクに変え、別の段階では15時間かかることができます。 これは、評価者の根絶不可能な楽観主義を補います。 さらに、 この特定の開発者に固有の楽観主義に基づいて、実証済みで実績のある補償が正確に実行されます。 そして、実際の速度は値がかなり近い（約0.6）ため、モデリングの各ラウンドを開始すると、同様の数値が得られ、その結果、プロジェクトの完了までにかなり狭い範囲の日付が得られます。

もちろん、モンテカルロシミュレーションの各ラウンドでは、時間ごとの情報を暦日に変換する必要があります。 各プログラマーの仕事のスケジュール、休日、週末などを考慮する必要があります。 また、プロジェクトの各反復は、最新の開発者が作業を完了したときにのみ完了するという事実に同意する必要があります-これだけがチーム全体の作業の完了を意味します。 そのような計算は非常に綿密に行う必要がありますが、幸いなことに、綿密な計算はコンピューターが上手くやることです。

強迫性障害は必要ありません

彼の釣り旅行に関する上司の果てしない物語をどうするか？ または、明白な理由もなく出席を余儀なくされる営業会議とは？ コーヒーブレイク？ 初心者が職場を立ち上げるのを手伝うために半日過ごしましたか？



ブレットと私がフォグクリークのためにこの手法を開発したとき、時間の損失につながるものを非常に心配していましたが、同時に事前に予測することはできませんでした。 場合によっては、直接コーディングよりも時間がかかりました。 これを何らかの方法で考慮し、タスクスケジュールに含める必要がありますか？







もちろん、必要に応じてそれを行うことができます。 そして、証拠に基づいた計画は引き続き機能します。



しかし、あなたはする必要はありません 。



現在のタスクの実行時間に失われた時間を単純に追加した場合でも、 DPは正常に機能することがわかります。 どんなに奇妙に聞こえても、この場合にDPを使用すると、さらに良い結果が得られます。



小さな例を考えてみましょう。 できるだけ単純化するために、非常に予測可能なプログラマーJohnを思いつきます。Johnの仕事は、フィールドにアクセスするための1行のメソッドを作成することです。 彼が毎日やるのは

private int width; public int getWidth () { return width; } public void setWidth (int _width} { width = _width; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は知っています-これは信じられないほど愚かな例ですが、確かにあなたは似たようなことに従事しているプログラマーに会ったことがあります。



それにしても、各アクセス方法の実装には2時間かかります。 つまり 彼のタスクの実行時間の見積もりは次のとおりです。



{2、2、2、2、2、2、2、2、2、2、2、2、...}



このかわいそうな人には、カジキを捕まえることについての2時間の会話で絶えず彼を邪魔するボスもいます。 もちろん、ジョンは「カジキについての退屈な会話」というタスクを自分のスケジュールに追加することもできますが、それは政治的に近視眼的なものです。 代わりに、ジョンは単に失われた時間を現在のタスクに帰します。 その結果、コストは次のようになります。



{2、2、2、2、4、2、2、2、2、2、4、2、...}



それに応じて速度



{1、1、1、1、0.5、1、1、1、1、0.5、1、...}



次に、何が起こるか考えてください。 モンテカルロシミュレーションでは、各グレードが0.5で割られる確率は、ジョンの仕事が上司によって中断される可能性に正確に対応します。 したがって、 DPは正しいスケジュールを作成します！



実際、 PDは、最も細心の注意を払う開発者よりもはるかに優れた中断を考慮する可能性があります。 それがとてもうまくいく理由です。 これは私が人々にそれを説明する方法です。 プログラマーが中断されると、彼は選択に直面します

1. 仕事のスケジュールにすべての中断を追加することで大きな騒ぎを起こして、経営者が釣りについて話すのにどれだけの時間を費やすかを見たり、
2. 仕事のスケジュールに追加することを拒否し、その結果として現在のタスクが空中に「ハング」することを拒否し、 完全に正確な推定値を修正するものがないため、釣りについての愚かな会話だけで、 招待することさえしませんでした ...

...とにかく、 DPは 、どのタイプのパッシブアグレッシブな開発者を扱っているかに関係なく、 同様の完全に正確な結果を提供します。

4.プロジェクトを積極的に管理する

すべての設定が完了したら、プロジェクトを積極的に管理して、期限内にプロジェクトを配信します。 たとえば、タスクを優先度に従ってソートすると、将来の作業を計画するのに役立ち、必要に応じて優先度の低い機能を削除できます。







各開発者の完了予定日に関する分布も確認できます。







一部の開発者（この図のMiltonなど）は、期限が非常に不正確であるため、問題の原因になります。タスクのコストをより適切に見積もる方法を学ぶ必要があります。 他の開発者（Janeなど）には正確な完了日がありますが、プロジェクトの完了が遅れます。タスクの一部を他の従業員に移すことを考える必要があります。 一部の開発者（私！大丈夫！）はまったくクリティカルパスではありません-彼らは放っておくことができます。

プロジェクト境界

DPは、すべてを細かく計画している場合に最適です。 ただし、おそらくいくつかの計画外のものを実装する必要があります。 新しいアイデアが登場し、営業マネージャーはそこにないものを約束し、取締役会の1人は、GPSサポートとフィールドを横切って移動するゴルファーの心電図を観察する機能を備えたゴルフモバイルアプリを実装する素晴らしいアイデアを思い付きます。 これはすべて、初期計画の準備中に予測できなかった遅延につながります。



理想的には、これらすべてのために特別なバッファを提供する必要があります。 そして真実は-あなたの計画にバッファを追加する

1. 機能に関する新しいアイデア
2. 競争力のある対応
3. 統合（異なる開発者が作成したコードを1つのシステムに結合）
4. デバッグ時間
5. ユーザビリティテスト（および最終製品でのテスト結果の使用）
6. ベータテスト

したがって、計画外の機能を実装するときが来たら、いつでも適切なバッファーからピースを切り離して、それを使用して作業することができます。



しかし、多くの新しい機能が追加され、すべてのバッファが使用されるとどうなりますか？ さて、この場合、 DPの助けを借りて取得したプロジェクトの納品日は変更されます。 しばらくして変更を追跡できるように、各営業日の終わりに完了日の確率分布のスナップショットを作成する必要があります。







X軸で計算日をマークし、Yはプロジェクトの完了日です。 図には3つの曲線が示されています。上の曲線は95％の確率での結果に対応し、平均曲線は50％に対応し、下の曲線は5％に対応します。 これらの曲線が互いに近いほど、プロジェクトの完了の可能性のある範囲が狭くなります。



完了日が絶えず遅れている場合（曲線が昇順）、問題が発生しています。 すべてが1日1日以上延期される場合、既存の作業を完了するよりも早く新しい作業を追加します。プロジェクトは決して完了しません。 確率分布がより密になる（曲線が収束する）場合、これは実際に特定の日付に向けて出発することを意味します。

ちなみに

プロジェクト計画の長年にわたって私が気づいたいくつかの事柄を以下に示します。



1.作業を実行するプログラマのみが、作業に必要な時間を評価できます。 開発者に任せることなく、管理者がタスクのスケジュールを作成するシステムはすべて、失敗する運命にあります。 特定の機能を実装するプログラマーだけが、目標を達成するために必要なステップを知ることができます。

2.発見されたエラーを修正し、元のタスクに費やした時間を割り当てます 。 発生する問題がわからないため、各エラーを事前に修正することはできません。 新しいコードでエラーが検出された場合、それを修正するのにかかった時間を、正しく実装されていない元のタスクに割り当てます。 これにより、 DPは、 動作するコードだけでなく、 完全にデバッグされるまでの時間を予測するのに役立ちます。



3.開発者に期限を短縮するようプレッシャーをかけさせないでください。 経験不足のプログラムプロジェクトマネージャーは、多くの場合、プログラマーの作業を「やる気」にして、タスクを完了するための優れた「きつい」（信じられないほど短い）計画を立てることができると考えています。 この種の動機は完全に脳みそだと思います。 スケジュールに合わないとき、私は運命づけられ、落ち込んで、動機付けが全くないように感じます。 公式の計画を先に進めるとき、私は熱心で生産的です。 計画は心理ゲームの場所ではありません。



マネージャーがこれを行う理由



プロジェクトの開始時に、技術マネージャーはビジネスマンと会い、タスクのリストを受け取ります。 彼らの意見では、約3か月かかりますが、実際には12です。作成のすべての段階を考えずにプログラムを作成する場合、常にn時間かかりますが、実際には4n以上を費やす必要があります。 実際の作業スケジュールを作成するとき、すべてのタスクをそれに追加し、プロジェクトが当初意図したよりもはるかに多くの時間が必要であることを理解します。 これはビジネスマンを混乱させます。



無能なマネージャーは、問題を解決するために人々をより速く働かせる方法を見つけようとします。 このアプローチには、現実との接点がほとんどありません。 追加のスタッフを雇おうとすることもできますが、スピードを上げるには時間がかかります。その間、彼は50％の効率で作業し、同時にトレーニングを余儀なくされる従業員の生産性を低下させます。



スタッフを完全に燃え尽きさせることなく、 一時的に生のコードを記述する速度を10％向上させることができます。 小さな成果。これは、種苗を食べることを連想させます。 もちろん、人々にリサイクルを強制すると、デバッグ時間が2倍になり、遅れているプロジェクトはさらに遅くなります。 カルマから逃げないでください。



nから4nを取得することも、取得することもできません。成功したと思われる場合は、会社のティッカーを送信してください。削減します。

vmaruninティッカーコメントの解釈

「...ティッカーを送ってショートさせてください」

ショート（ショートポジションを開く）とは、株を借りて売り、価格が下落したら株を買って負債を返済することです。

言い換えれば、Joelは、企業が開発期間を4nからnに短縮できれば、すぐに取引所に転落するという事実に資金を投入する準備ができています。

4.スケジュールは木製のブロックが入った箱です。 箱に入れることができない木製のブロックがいくつかあると仮定すると、2つの選択肢があります。大きな箱を取るか、いくつかのブロックを取り除くかです。 プロジェクトを6か月で提供したい場合、作業計画に従って12になりますが、リリース日を延期するか、一部の機能を放棄するだけです。 木製のブロックを取り除いて減らすことはできません。



特に、現実的なスケジュールの主な利点の1つは、関数を強制的に削除することです。 なぜそれが良いのですか？



2つの機能を思いついたと想像してください。 最初の、非常に便利なものは、製品を本当に美しくすることができます。 もう1つは非常に単純であり、プログラマはエンコードできる瞬間を待つことができません（「見て！<blink>！」）。ただし、実際の利点はありません。



プロジェクト計画を立てない場合、プログラマーはそもそもシンプルで興味深い機能を実装します。 その後、彼らは締め切りを破り、有用で重要な機能を実現するために配達日をシフトする以外に選択肢はありません。



実装の開始前にスケジュールが作成されている場合、いくつかの機能を犠牲にし、簡単で面白いタスクを取り除き、有用で重要なことだけを行うことを決定する必要があることがすぐにわかります。 アプリケーションの一部の機能を事前に破棄することを強制することにより、より売れるより優れた機能のセットを備えたより良い製品を作成するのに役立ちます。



Excel 5で作業していたとき、予定されていた機能のリストは膨大であり、リリーススケジュールからの非常に深刻な遅れを示していました。 「私の神」と私たちは考えました。「これらはすべて非常に重要なものです。 マクロ編集ウィザードなしでどのように生きるのか？”



結局のところ、選択の余地はありませんでした。プロジェクトの実装に絶対に必要なもの以外はすべて切り取りました。 この決定は誰にも適合しませんでした。 どうにか落ち着くために、破棄された関数を完全に放棄せず、それらの実装をExcel 6に転送しただけだと確信しました。



Excel 5が完成に近づいたとき、Eric Michelmanと私はExcel 6仕様の作業を開始し、Excel 5に実装する時間がなかった関数のリストを調べました。 これは、想像できる最も下品な機能リストの1つでした。 それにリストされている関数はどれも実装に値しません 。 スケジュールに合うように機能を切り捨てるプロセスは、彼に提供できるプロジェクトにとって最高のサービスでした。 これが行われていなかった場合、Excel 5の実装には2倍の時間がかかり、半分は不要ながらくたからなり、互換性のために時間の終わりまで維持する必要がありました。

おわりに

証拠に基づいた計画の使用は非常に簡単です。各反復の前に詳細な見積もりを準備するのに1〜2日かかり、特定のタスクで作業を開始したときを記録するために毎日数秒かかります。 メリットは非常に大きく、現実的なプロジェクト計画です。



現実的な作業スケジュールは、優れたソフトウェアを作成するための鍵です。 そもそも最良の機能を実装することを奨励し、最終アセンブリに何を含めるかについて正しい決定を下すのに役立ちます。 これにより、製品が向上し、上司が幸せになり、顧客を喜ばせ、何よりも17:00に正確に家に帰ることができます。

メソッド名の翻訳を手伝ってくれたtruezemezに感謝します。