私が初心者プログラマーだったとき、そして実際に私が初心者のリード開発者だったとき、私はあなたが何かをする時間枠を予測することは絶対に不可能だと思いました。 または、適切な予測には、タスク自体とほぼ同じ期間の非常に詳細な設計と準備が必要です。

後で、もちろん、私はいくつかのスマートブックが予測のトピックについて書かれていることを発見しました。 もちろん、最も便利な方法は、類推によって評価することです。すでに似たようなことをすでに行っている場合、このタスクに必要な作業を非常に正確に知っています。 しかし、経験が比較的少ない、または類推する場所がないが、それでも評価したい状況はどうでしょうか？

私が働いていたチームの1つで、タスクの予備評価のための独自の方法を思いつきました。 この方法は、文献から知られているいくつかの技術を合成しますが、与えられた形式では、おそらく誰も説明していません。 概念は次のとおりでした。客観性（測定可能な指標との関係）。 アジャイルとの統合性; 再現性 評価速度（タスク量の0.5％未満）; 初心者開発者向けのアクセシビリティ。 私たちのアイデアを喜んで議論し、Habraauditoriumの誰かがそれを好きになる可能性を排除しません。

4つの難易度：タスク分析

だから、私たちは仕事をします（正式に記述されていない、悪いポーズです-すべてが人生のようです）。 エクスプレス分析を実行します。つまり、どの機能を実装する必要があるのか​​、このタスクをどのように技術的に実行できるのかという直感的なアイデアを頭（またはボード上）で収集します。

最初の目標は、次の4つのスケールを使用して数値的に評価できるように、生まれたアイデアを具体化することです。

複雑さの要因 、それらは予測であり、条件付きでそう呼ばれます：

• 「表面」
• 「テスト」
• 「要件」
• 「技術的リスク」

メソッドのこれらの用語は、元々非常に理解されています（たとえば、「表面」は一般に非標準の概念です）が、客観的現実と関連するように定式化されています。 測定可能な値：

一般的な場合の表面は、私たちの洗練と外の世界との接触領域です。 たとえば、GUIコンポーネントの場合、インターフェース要素の将来の数を定量的に把握する必要があります。 ライブラリの場合、パブリックAPIのメソッドの数。 バグ修正-影響を受けるコードの量について。 ステートマシンの場合-着信イベントのクラスについて。 タスクに「一方と他方の両方」がある場合、何が外部で何が実際にはプライベートであるかを考える必要があり、評価されるのはパブリックな部分です。

テストとは、TDDスタイルで実行するために記述する必要のある基本的な自動テストの数に関するアイデアです。 これは必ずしもテストを通じて開発することを意味するわけではありません（実際のカウボーイはテストをまったく書かないと言います）が、タスクの複雑さを評価するには、テストボリュームがどれだけ対応するかを考える必要があります。

要件 -これは、古典的なアプローチで要件と呼ばれるものの量の私たちのアイデアです。 この要因は、正式に問題を提起する場合に記述する必要がある仕様のサイズとして理解できます。 当然のことながら、このような仕様のコンパイルに時間を費やすことはほとんどありませんでした（要件のコンパイルはプロセスの一部ではありませんでした）が、そのようなドキュメントが大量に得られることはわかっていました。 「正式にこれを説明するには、15ページかかる」という形式で評価を行い、次に進みます。

技術的リスク -この要因は、何かが一緒に成長していないという事実のために、いくつかの研究を行うか、いくつかのアプローチを試すか、作業の一部を捨てなければならないという期待を反映しています。 理論的には、この値は0％から100％の数値として表現できますが、実際には4つの値の中で最も主観的です。 このように行動できます。リスクを評価するために、このタスクを完了する方法をすべて考え出します。 その結果、落ち込んでいると感じ、合理的な期間内に最終的に回復するという重大な疑念がある場合は、格付けを最大値に近づけます。

結果の4つの「投影」 は、タスクの一種のプロファイルを形成します -その主な複雑さを構成するものが明らかになります。 同時に、タスクを分析するとき、そのステートメントは検証（チェック）されます。たとえば、洗練をテストする方法がわからないことがわかった場合、ほとんどの場合、コードの記述を開始できません。 予測の比率もある程度重要です-いくつかの要因の大きな指標は、タスクに「隠されたボリューム」（何度も期待を超える恐れがある）があることを示唆しますが、「フラット」タスク（1つの支配的な「投影」を持つタスク）通常、見やすく、期待どおりに表示されます。 同じケースで、タスクが最初は小さく見え、実際にすべての見積もりで小さいことが判明したとき、思考時間はまだ無駄になりました：少なくとも、何を実現する必要があるかについて十分な理解があることを確認しました。

このような高速分析は迅速に実行され、タスクの複雑さと複雑さのかなり明確なアイデアを提供します。 これを終了し、質的アプローチに限定することも可能です。 ただし、実際にはさらに進んで、この概念から実験的なメトリックを合成しました。

以下では、4つの定性的推定値から定量的な値を取得する方法を説明します。これは、最終的に、反復バックログのコンパイルや時間予測の表示に役立ちます。 その背後には深刻な科学的研究はありませんが、私たちの実践では、最小限の労力でかなり良い精度を提供しました。

実験指標

すでに理解したように、最初の段階では、4つの予測は次のように表されます。 20ページの説明が必要になりますが、これは決してありません。すべてをやり直す可能性は約10％です。 すべてを見積もったので、これらの数量を集計する必要があります。 もちろん、テストとチャンスを単純に合計することは不可能であるため、推定値を任意の複雑さの単位に変換する必要があります。

一般に、 複雑さは 、費やされた時間から、明らかな定型文やその他すべての日常的な予測可能な操作の記述を差し引いたものとして理解されます。 初期変換では、次の非線形スケールが使用されます。

• 0- 「すべてが単純」を意味します（実行する必要があること、および実際に短時間で実行されることを詳細にすぐに想像できます）。
• 1-これは、わずかな時間（たとえば、4時間または8時間）で克服できる複雑さです。
• 3-ユニットよりも3〜5回、これはすでにかなり高いと考えられており、やや問題のある値
• 5-最大スコア、「叙事詩」を意味します（非常に難しいため、破壊、トリミング、または放棄する価値があることは間違いありません）

フォーミュラ

最終的なメトリックを取得するために、4つのスケールで複雑さの単位ですべての推定値を要約します。

ただし、2つ以上のスケールで≥2が得られた場合、2つの最大数を加算せずに乗算します。

イラスト：

 問題1. 1 0 0 0-> 1-> 1
問題2. 1 0 2 0-> 1 + 2-> 3 
問題3. 1 1 2 0-> 1 + 1 + 2-> 4
問題4. 3 3 1 2-> 3 * 3 + 1 + 2-> 12 
問題5. 1 4 1 5-> 4 * 5 + 1 + 1-> 22 

使用する

複雑さのメトリックは、知的作業の量、明示的および隠された量のアイデアを提供し、ほとんど機械的に時間の悲観的な評価に変換することさえできます。 これを行う方法については、以下を参照してください。しかし、最初にいくつかのより軽いユースケースを見ていきます。 以下で説明する方法の一部は、メトリックの取得方法にまったく関係していません-それらは、同様の数値から何らかの利点を得る方法を示しています。

技術的ソリューションの選択

大規模で複雑なプロジェクトを作成する場合、いくつかの機能を追加するための受け入れ可能な2つまたは3つの方法があり、どちらの方が簡単かを事前に予測する必要があります。 決定を下すには、4つの要因で各オプションを評価し、値を比較できます（ただし、 技術的な負債を追加する場合は、より簡単な方法を選択することを検討する価値があります）。

タスク検証

このメソッドには、算術とスケールが配置されているために、タスクの隠れた複雑さを明らかにする興味深い機能があります（同じ隠れたボリューム 。「使用経験」セクションも参照）。 定性分析に限定されず、メトリックを計算する場合、問題のステートメントを改善できます。 このために、2つの基準が導入されています。

• 複雑さのメトリックは、特定の制限を超えてはなりません。 ボリュームタスクは比較的均質です（小さすぎず、大きすぎません）。
• 「3次元」および「4次元」の問題はありません。 タスクは最大2つのプロジェクションで高い評価を得ます。

これらの基準では、目的のパーティションサイズを特徴付けるいくつかの定数が導入されています。 それらはカスタマイズできます。 「メトリックで10以下、2つのマイナープロジェクションで1以下」オプションを選択しますが、かなり大きいことがわかります。

バックログのコンパイル

ソフトウェア開発には非常に多くの方法論がありますが、それらの重要な部分は特定の反復を伴います。これは、チームが一定の期間目標を設定し、この目標を達成するために実行する必要があるタスクのセットを決定するという事実にあります。 反復の最後に、製品バージョンを提供する準備ができているはずです。

反復の開始時に、この期間中に一般的に実行できることについて評価が行われ、タスクが洗練され、ユーザーストーリーのバックログやタスク記述の他の形式に類似したリストが作成されます。

「期間の作業計画」に対するUser Story形式の標準バックログのよく知られている利点は、スクラムの独特の「魔法」のために、正確に評価する必要がないことです。 しかし、重要な注意事項があります。 多くのチームで発生するタスクが標準的なユーザーストーリー形式ではなく、より大きく、またはより「アーキテクチャ」に分類される場合、前述の「魔法」は簡単に分類されます。反復の開始時にタスクのサイズを推定する品質が重要な役割を果たし始めます。 これは非常に一般的な状況であり、過去のタスクに関する一連の履歴データと、疑わしいタスクのサイズの推定として反復の開始時に使用する計算可能なメトリックの両方が必要になる場合があります。 反復の誤った構成は、製品と開発者の動機の両方を損なうため、タスクを適切に評価する努力をすることは正当化される以上です。 これを行うことをお勧めします。

スクラムを強化する

スクラムチームは通常、タスクを任意の単位（ストーリーポイント）で評価します。 これは必ずしも簡単ではありません。 プランニングポーカーなどの比較的複雑な手順が実践されています。

アジャイルスタイルのメソッドの適用は、タスクのサイズまたはその実装の可能性について疑問がある場合に、提案されたメトリックを考慮することです。 特定のタスクでは、この方法によるすべての計算と推定を頭の中で行うことができるため、これは非常に痛みがなく、大きな方法論的な論争がありません。 また、このメソッドの「パルチザン」アプリケーションの可能性もあります。開発者としてタスクのみを評価し、4ファクターメソッドが機能する場合、このメカニズムをすべてスタンドアローンで伝える必要はありません。

計画が必要ですか？

「計画」が虐待的な言葉である読者に事前に謝罪します。 他の読者は、慎重に行動すれば、メトリクスから即時の時間的推定も導き出されることを喜ばしく思っています。 この方法で戦略的に計画することはおそらく機能しません。 ただし、 この方法の利点の1つは、かなり大きなタスクブロックを事前に評価できることです。

メトリックを使用した計画は、将来の実際のボリューム内のタスクがボリュームメトリックとして相関するという前提に基づいています。 もちろん、複雑さと量は同等の概念ではありません。開発者の努力の一部が問題自体の解決を目的としている場合があるためです。 プログラミングに加えて、大量のXMLの記述、手作業による非効率的なテスト、時間のかかる展開手順など、何らかの知的でない活動に従事する必要がある場合。 さらに、顧客と交渉し、ドキュメントの原稿を書いており、そのようなクラスがすべてタスク間で不均等に分散している場合は、同情するしかありません。 非プログラム的で知性の低い活動を評価する方法を理解する必要があります。 ただし、そのような作業があまりない場合（良いプロジェクトではあまりない場合）、計画の目的でボリューム==複雑さを考慮し、追加の修正を行わないことを十分に考慮することができます。

中期計画を立てなければならなかったとき、私は次のことをしました。

1. タスクのリストが強調表示され、各アイテムのメトリックが計算されます。
2. 評価が変更または内訳の必要性を通知するタスクは分類されます（基準-「タスクの検証」を参照）
3. さらに、直感的な感覚に焦点を当てて、このグラフを時間で圧縮または拡大し、ボリュームの計算された割合を多かれ少なかれ観察し、非現実的な外観のアイテムの出現を防ぎます。

もちろん、これはかなり単純なアプローチです-タスクの評価なしで計画を立てることができます-しかし、結果は悪化します。 メトリックは、計画時に数値の推定値（タスク間の相関）を確認するのに役立ちます。これにより、歪みがなくなり、時間を合理的な制限以下に減らすことができなくなります。 最終的に、用語はまだ機械的に選択されず、部分的に直感的に選択されますが、メトリックからの深刻なサポートがあります。

あるいは、自分で計画している場合は、より簡単に行うことができます。「速度」の特定の係数を歴史的に計算し、次のタスクのメトリックを係数で除算して時間の予測を機械的に計算します。 しかし、この方法を計画することは、全体像を見るときよりも悪いです。 さらに、そのような係数の較正は快適な仕事ではありません。 「速度」を使用した同様のアプローチは、バーンダウンダイアグラムを使用したスクラムでも非常にうまく機能しますが、より効率的で自然に見えます。 スクラム速度の概念は、単にボリュームと時間の比率よりも細かく配置されたメカニズムであると言えます。

使用経験

小さなタスクの場合、実践が示すように、推定と計算は心の中で1分以内に実行されます。 コンポーネントが大きくなると少し時間がかかりますが、この方法は、口頭での迅速な計算のように見え、許容できる精度の結果が得られます。通常は、N日間の直観的な予測よりも正確です。 他のチームの同僚が本物の仕事をしているときに、これらの数を数え、集会で心に留めることがありました-Buzzword Bingoのセルをひそかに塗りつぶしました。

この方法は非常に単純とは言えませんが、 暗黙の複雑さを明らかにする有用な機能があります -貧弱なライブラリとツール、貧弱なアーキテクチャ、労働の非線形性、技術的負債に隠されているものであってもです。 部分的には、非線形算術がこれに寄与しますが、全体的には、グレーディングスケールが完全に直交していないため、隠れた複雑さが明らかになります。実際の問題のいくつかのバリエーションを検討すると、主に1つのスケールで増加する変更でも部分的にはまだ気づくでしょう残りに表示されます。 さらに、場合によっては、そのような転送が強く現れることもあれば、弱く現れることもあります。 また、転送の発音が少ないほど、対応するタスクの完了がより直感的に簡単に見えますよね。 実際、この式は、さまざまな「落とし穴」が主に別々のスケールで現れることはありませんが、それらの存在によって2つまたは3つの投影が同時に大きくなるという観察を使用しています。 数式の非線形性がこの効果を「キャッチ」し、計算値が大幅に増加します。

これらの解剖学的詳細のため、4因子評価は、より時間がかかりますが、ほとんどの場合、単純な「類推による」推定または単一因子に基づく推定よりも優れています。

私自身も数年前からこの方法を時折練習しています。 彼への愛着はいくつかの理由によるものです。 まず、慎重に適用すると、他の基本的な方法よりもはるかに正確な予測が可能になります。 第二に、1つまたは別の開発方法論に適応するのに非常に柔軟性があります：ある程度のストレッチで、「クリーンな」アジャイル環境、ハイブリッドプロジェクト、およびプログラマーのチームの最上位にあるMicrosoft Projectによる条件付きの「クラシック」プロジェクト管理で使用できます。 また、ある程度の快適な拡張性にも気付きました-小規模（バグ、ストーリーなど）だけでなく、より大きな時間スケール（機能ブロック、コンポーネント）でも同様の評価を適用できる場合があります。 最後に、この方法は、評価者が学習するのに役立ちます。実際の指標（コードサイズ、テストの複雑さなど）を初期評価と比較し、実質的な結論を引き出す機会が常にあります。

∗ ∗ ∗

私の記事では、基本的にプロジェクトのタスクを評価するかどうか、ソフトウェア開発で何らかのメトリックスを使用するかどうかについて議論するつもりはありませんでしたが、そのようなニーズがある人に役立つツールを提供したかっただけです。 私の賄briは、かなり良い指標では、この方法はほとんど知られていないということです。 そして、私は彼の概念のいくつかの最初のソースを見つけることは私にとって非常に興味深いだろうと認めます。

方法がわからない場合にタスクを評価する方法を学ぶには？ この質問に答えて、私は自分の好きな方法について話しました。それは、比較的初心者が使用するのに十分なメカニズムです。 一般的に、評価方法は多数あります。このトピックをより深く研究したい場合は、よく知られている本のいずれかを読むことをお勧めします。

• スティーブマッコネル ソフトウェアプロジェクトはいくらですか
• マイク・コーン。 アジャイルの見積もりと計画

私はあなたの批判とコメントに喜んでいるでしょう。