研究所は、アルゴリズム、データ構造、OOPを教えています。 良いケースでは、彼らはデザインパターンやマルチスレッドプログラミングについて話すことができます。 しかし、人件費を正しく評価する方法については聞きませんでした。

一方、すべてのプログラマーは毎日このスキルを必要としています。 常に実行可能な作業よりも多くの作業があります。 評価は、正しく優先順位を付け、いくつかのタスクを完全に放棄するのに役立ちます。 予算や計画などの家庭の問題は言うまでもありません。 それどころか、誤った見積もりは多くの問題を生み出します：過小評価-競合状況、処理と予算の穴、過大評価-プロジェクトのキャンセルまたは他の実行者の検索。

公平に言うと、開発では過小評価がはるかに一般的であることに注意する必要があります。 なんで？ プログラマーは本質的に楽観的すぎると誰かが考えています。 これにもう1つの理由を付け加えます。優れたプログラマーであることと優れた評価者であることは同じことではありません。 優れたプログラマーになるには、1つの欲求だけでは十分ではありません。 知識と実践が必要です。 評価が異なるのはなぜですか？

記事では、タスクの評価に対する私の態度がどのように変化したか、そして当社のプロジェクトがどのように評価されているかについて話します。 そして、評価する必要がない方法から始めます。 「してはいけない」方法について既に知っている場合は、記事の第2部に直接進んでください 。

アンチ評価パターン

プロジェクトのほとんどの評価は、ライフサイクルの開始時に行われます。 そして、これは、要件が定義される前に推定値が取得され、それに応じてタスク自体が研究される前に推定値が取得されることを理解するまで気になりません。 したがって、通常、評価は間違った時間に行われます。 要件内のすべてのスポットは推測ゲームであるため、このプロセスは正しく評価ではなく推測または予測と呼ばれます。 この不確実性は、評価の最終結果とその品質にどの程度影響しますか？

些細だが不快

注文入力システムを開発しているが、電話番号を入力するための要件をまだ開発していないとします。 プログラムの評価に影響を与える可能性のある不確実性の中で、すぐに以下を強調できます。

1. クライアントは、入力された電話番号の有効性を確認する必要がありますか？
2. 顧客が電話番号検証システムを必要とする場合、どのバージョンを好みますか-安いですか、それとも高価ですか？
3. 電話番号を確認する安価なバージョンを実装する場合、クライアントは後で高価な番号に切り替えることを望みますか？
4. 電話番号を確認するために既製のシステムを使用することは可能ですか、またはいくつかの設計上の制限により、独自のシステムを開発する必要がありますか？
5. 検証システムはどのように設計されますか？
6. 電話番号検証システムをプログラムするのにどれくらい時間がかかりますか？

そして、これらは、経験豊富なプロジェクトマネージャーの頭に浮かぶ質問のほんの一部です... そして、それらを大規模プロジェクトの数百および数千の機能に結合すると、プロジェクト自体の評価に非常に大きな不確実性が生じます。

「むくみ」のもう1つの優れた例は、基本的な要件のようです。記事「 2週間はどうですか？ 」

不確実性のコーン

ソフトウェア開発-および他の多くのプロジェクト-は、数千のソリューションで構成されています。 研究者は、プロジェクトの予測は、予測される不確実性のレベルに固有のさまざまな段階で推定されることを発見しました。 不確実性の円錐は、プロジェクトが進むにつれて見積もりがより正確になることを示しています。 最初の概念の段階（見積もりが頻繁に行われ、義務が行われる）では、エラーが400％（400％、カール！）になる可能性があることに注意してください。 詳細設計の完了後にコミットメントを行うことが最適です。

神話上のマン月

機能が厳密に固定されている場合、より短時間でより多くの作業を行うスタッフを追加することにより、いつでも時間の短縮を達成できると考えている幹部もいます。 このような推論の誤りは、評価と計画で使用される測定単位、つまりマンマンにあります。 コストは、実際に従業員数と費やした月数の積として測定されます。 しかし、結果は達成されていません。 したがって、作業量の測定単位として人月を使用することは、危険な誤解です。 すべての研究者は、名目上の期間を短くすると総作業量が増えることに同意しました。 7人のグループの名目期間が12か月の場合、単純にスタッフを12人に増やしても期間は7か月に短縮されません。

大規模なグループでは、調整と管理のコストが増加し、通信パスの数が増加します。 タスクのすべての部分を個別に調整する必要がある場合、コミュニケーションのコストは二次的に増加し、チームの「力」は直線的に増加します。 3人の作業者は、2人の3倍のペアワイズ通信を必要とし、6人​​は4人です。


プロジェクトチームは、rump部に対処しようとしています// Ivan Aivazovsky、1850

8人が10か月でプログラムを作成できる場合、80人が1か月で同じプログラムを作成できますか？ 極端に厳しい締め切りの非効率性は、1日でプログラムを作成する必要がある1,600人のような極端な場合に特に顕著になります。 これについては、フレデリックブルックスの同名の本で詳しく読んでください。

評価パターン

そのため、問題があることはすべて明らかです。 何ができますか？

分解

大きなタスクを評価する代わりに、それを多くの小さなタスクに分割し、それらを評価し、最終評点を初期評点の合計として取得することをお勧めします。 したがって、私たちはすぐに1石で最大4羽の鳥を殺します。

1. 作業範囲をよりよく理解します。 タスクを分解するには、要件を読む必要があります。 不可解な場所はすぐに現れます。 要件を誤って解釈するリスクが軽減されます。
2. 要件のより詳細な分析の分析中に、知識を体系化する思考プロセスが自動的に開始されます。 これにより、リファクタリング、テストの自動化、またはレイアウトと展開の余分な作業など、作業の一部を忘れるリスクが軽減されます。
3. 両方のツールが同じツールを使用していれば、分解結果をプロジェクト管理に使用できます（この問題については、後ほど詳しく説明します）。
4. 分解中に得られた各問題の推定の平均誤差を測定し、この誤差を合計推定の誤差と比較すると、合計誤差は平均より小さいことがわかります。 つまり、このような評価はより正確です（実際の人件費に近い）。 一見、このステートメントは直感に反します。 分解された各問題の評価を間違えた場合、どのように最終評価をより正確にすることができますか？ 例を考えてみましょう。 新しいフォームを作成するには、a）バックエンドでコードを作成し、b）フロントエンドでレイアウトを作成してコードを作成し、c）テストしてレイアウトする必要があります。 タスクAは5時間で、タスクBとCはそれぞれ3時間で評価されました。 合計スコアは11時間でした。 実際には、バックエンドは2時間で完了し、フォームには4時間、バグのテストと修正にはさらに5時間かかりました。合計ワークロードは11時間でした。 評価するのが理想的です。 さらに、タスクAの評価のエラーは3時間、タスクBは1時間、Cは2時間です。 平均エラーは3時間です。 事実は、推定値の過小評価と過大評価のエラーが互いに打ち消し合うことです。 バックエンドで節約された3時間は、フロントエンドおよびテスト段階での1時間と2時間の遅れを補償しました。 実際の労働は、多くの要因に依存するランダム変数です。 病気になった場合、集中することが難しくなり、3時間ではなく6時間かかることがあります。 または、1日中検索して修正する必要のある予期しないバグが発生します。 または、逆に、独自のコンポーネントを作成する代わりに、既存のコンポーネントなどを使用できることが判明する場合があります。 正と負の偏差は互いに相殺します。 したがって、総誤差は減少します。

機能とタスク

分解の中心にあるのはFeatureです。 機能とは、他の機能とは独立して実稼働に使用できる機能の配信単位です。 このレベルはユーザーストーリーと呼ばれることもありますが、ユーザーストーリーはタスクの設定に必ずしも適しているとは限らないという結論に達しました。そこで、より一般的な定式化を使用することにしました。

1人のメンバーが1つの機能を担当します。 誰かが実装を手伝うことはできますが、1人がテストに合格します。 タスクは、改訂のために彼に戻されています。 チームの組織に応じて、これはチームリーダーまたは直接開発者になる場合があります。

残念ながら、時には大きな機能があります。 そのようなボリュームで単独で作業するには非常に長い時間がかかります。 そして、長い間、受け入れプロセスをテストして実装する必要があります。 次に、タスクのタイプをEpicに変更します。 Epicは非常に厚い機能です。 私たちは壮大なもの以外何も始めません。 つまり エピックは、大きくても、巨大でも、巨大でもかまいません。 いずれにせよ、叙事詩は一部（機能）で受け入れに送られます。

より正確に評価するために、機能は個別のサブタスク（タスク）に分解されます。 たとえば、新しいCRUDインターフェイスの開発などの機能があります。 タスクの構造は次のようになります。「データを含むテーブルを表示する」、「フィルタリングと検索を高速化する」、「新しいコンポーネントを開発する」、「データベースに新しいテーブルを追加する」。 通常、タスクの構造はビジネスにとってまったく興味深いものではありませんが、開発者にとって非常に重要です。

グループでの評価、ポーカープランニング

プログラマは作業量について楽観的すぎます。 さまざまな情報源によると、過小評価はほとんどの場合20〜30％の範囲で変動します。 ただし、グループでは、エラーは減少します。 これは、異なる視点と気質の評価によるより良い分析によるものです。
アジャイルの人気が高まりつつある最も一般的なプラクティスは「 ポーカープランニング 」のプラクティスでしたが、グループ評価には2つの問題が関連付けられています。

1. 社会的圧力
2. 時間費用

社会的圧力

ほとんどすべてのグループで、参加者の経験と個人的な効果は異なります。 チームに強力なチーム/技術-リード/リードプログラマーがいる場合、他のメンバーは不快感を覚え、自分の成績を意図的に過小評価している可能性があります。 私もできる！」 理由は異なる可能性があります。実際よりも良く見えるようにしたいという欲求、競争または単なるコンフォーマリズム。 結果は1つです。グループ評価はすべての利点を失い、個別になります。 ティムリッドはマークを与え、残りは彼に同意しただけです。

長い間、私はチームにプレッシャーをかけて、私の期待とより一貫した評価を得ました。 これは常に品質の低下と用語の内訳につながりました。 その結果、私は態度を変え、今では私の評価が最大になることがよくあります。 議論の中で、私は思い浮かぶ潜在的な問題を指摘します：「ここではリファクタリングは害にならず、ここではデータベース構造が変化しているので、回帰テストを行う必要があります。」

主な推奨事項がいくつかあります。

1. ほとんどの評価は過小評価されています。 2つの評価から選択することはできませんか？ 大きいものを取ります。
2. 評価がわからない-カード「？」を捨てる または素晴らしい評価。 おそらくほとんど持ち運びません。
3. 計画と事実を常に比較してください。 2回は収まらないことがわかっている場合は、予想より2倍高い見積もりを行います。 誇張し始めましたか？ あなたの心に1.5を掛けます。 数回の反復の後、成績の品質が大幅に向上するはずです。

時間費用

「仕事をしたいですか」というフレーズを知っていますか 会議を開催してください！」 1人のプログラマーがコードを書く代わりに未来を予測しようとするだけではありません。 今、グループ全体がそれを行います。 さらに、グループで決定を下すことは、個々の決定を行うよりもはるかに長いプロセスです。 したがって、グループ評価は非常にコストのかかるプロセスです。 これらのコストを反対側から検討する価値があります。 最初に、評価プロセスで、グループは要件を議論することを余儀なくされます。 つまり、それらを読む必要があります。 すでに悪くない。 次に、これらのコストを、プロジェクトの過小評価のために会社が負担するコストと比較しましょう。

何年も前の11月1日、私は仕事を大企業に変えました。 仕事が本格的だったことはすぐに明らかになりました。 同社の半数は、年末までに製品のリリースに取り組みました。 しかし、約一週間後、年末までに彼らは時間がないと私には思えました。 次の日ごとに、この企業の成功の可能性はますます幻想的になりました...このプロジェクトは、翌年でありながら、12月に実際に引き継がれました。 夏に問題が従業員への賃金の支払いから始まり、私は州の約半分と一緒に辞めたので、私はずっと後でこのことを学びました。 「もちろん、マネージャーは愚か者です。安全にプレイしなければなりませんでした。」 彼らは自分で保険をかけました。 6か月間、賃金の支払いに問題はありませんでした。 運転資金を半年間資金調達するのは簡単なことではありません。 アセスメントがより正確であれば、トップマネジメントレベルで他のマネジメント決定が行われると思います。

アセスメントへの投資を健全な経営判断の採用への投資と見なすと、それらは非常にコストがかかるように見えなくなります。 グループのサイズは別の問題です。 もちろん、チーム全体に作業量全体の評価を強制する必要はありません。 タスクをモジュール 、アエム、マイクロサービスに分割し、チームに自律性を提供する方がはるかに合理的です。 より高いレベルでは、各チームが取得した見積もりを使用してプロジェクト計画を作成します。 次の段落のトピックにスムーズに移動できます。

依存関係レイアウト、ガントチャート

プログラマーが通常評価を行う場合、プロジェクト計画を作成することは多くの中間管理職です。 分解とプロジェクト管理に1つのツールを使用すれば、これらの人たちが助けられることを覚えています。 評価とカレンダーの日付は同じものではありません。 たとえば、単純なデータテーブルを表示するには、次のものが必要です。

1. DBテーブル
2. バックエンドコード
3. フロントエンドコード

この順序でタスクを実行することは、技術的な観点から最も簡単です。 ただし、実際にはさまざまな専門分野があります。 フロントエンドのスペシャリストは、より早く解放される予定です。 アイドル状態ではなく、サーバーリクエストをモックデータまたはハードコードされたデータに置き換えてUIの開発を開始する方が論理的です。 その後、APIの準備が整うまでに、残っているのはコードを実際のメソッドの呼び出しに置き換えることだけです...理論的には。 実際には、次のように最大レベルの並列処理を実現できます。

1. まず、API仕様に一貫性を持たせるためにすばやく振り替えます
2. 次に、手元に応じて、データを背面または前面にハードコーディングします。
3. 同時に、データベース、バックエンド、フロントエンドを実行します。 データベースとバックエンドは互いに部分的にブロックしますが、ほとんどの場合、これらの能力は1人で組み合わされ、作業は実際に順番に進みます。最初にデータベース、次にバックエンド
4. すべてを収集してテストします
5. バグを修正し、再度テストします

ロックの数を減らすには、ステップ1、4、および5をできるだけ早く実行することが重要です。 必要な能力の専門家の可用性に関する技術的な制限と制限に加えて、ビジネス上の優先事項がまだあります！ そしてこれは、3週間後に重要なクライアントのためにデモンストレーションがすでにスケジュールされており、彼があなたのプロジェクト計画の前半で吐き出したかったことを意味します。 彼は最終結果を見たいと思っており、それは2か月後には利用可能になります。 それでは、このデモ用に別の計画を準備する必要があります。 プランに追加して、必要なデータベースデータを追加したり、UIへの移行用の新しいリンクを挿入したりします。 また、最終的にはコードの20％を捨てる必要があり、このすべてのデモンストレーションが必要というわけではありません。

このような計画の芸術的なカットは簡単な作業ではありません。 依存関係を構築すると、プロセスが大幅に簡素化されます。 レポートモジュールに進む前に、データ入力モジュールを作成する必要があります。 論理的ですか？ 依存関係を追加します。 関連するすべてのタスクについて繰り返します。 私を信じて、依存関係の多くはあなたに驚きとして来るでしょう。

ビジネスプロセスを自動化するタスクでは、通常、いくつかの大きなロックノードを持つ関連タスクのいくつかの長い「蛇」を取得します。 ほとんどの場合、初期計画はリソース使用率の面で効果的ではない、および/またはカレンダーの面では長すぎます。 人件費の査定の修正はより速く起こります-オプションではありません。 したがって、評価は最も楽観的です。 分解に戻り、長すぎるチェーンを探し、並列性を高めるために「フォーク」を追加する必要があります。 したがって、総人件費が増加するため（1つのプロジェクトで同時に作業する人が増えます）、プロジェクトのカレンダー期間が短縮されます。 「神話上の人月」を覚えていますか？ 計画が30％以上縮小することはまずありません。 予算と期限が一致するように、計画を数回レビューできます。 プロセスをより速く簡単にするためのトリックがいくつかあります。

タスクロック

ブロックの最初の理由-依存関係-すでに検討しました。 さらに、単に理解できない/不正確な要件がある場合があります。 タスクをブロックして質問するためのツールが必要です。 要件を指定することで、タスクのロックを解除し、グレードを調整できます。 ちなみに、このプロセスは、プロジェクトの前ではなく、プロジェクト中にほとんど常に行われます。

クリティカルパス、先のリスク

クリティカルパス方式は 、プロジェクトの開始から完了までのタスクの最も長いシーケンスを、それらの関係を考慮して決定することに基づいています。 クリティカルパス上にあるタスク（クリティカルタスク）のリードタイムはゼロであり、期間が変わるとプロジェクト全体の条件が変わります。 この点で、プロジェクトの実施中、重要なタスクは、より慎重に監視する必要があります。特に、実施のタイミング、ひいてはプロジェクト全体のタイミングに影響を与える問題とリスクのタイムリーな特定が必要です。 プロジェクトの実装プロセスでは、プロジェクトのクリティカルパスが変更される場合があります。タスクの期間を変更すると、それらの一部がクリティカルパス上にある可能性があるためです。

要するに、データベースの構造を台無しにした場合、バックを書き直さなければならず、負荷を計算せず、テクノロジー全体を変更する必要があるかもしれません。 設計作業のリスクについては、記事「 費用対効果の高いコード 」で詳しく説明しました。 クリティカルパスのリスクが実現するのは早ければ早いほどよい。 結局のところ、まだ時間があり、何かをすることができます。 それらがまったく実現しない場合はさらに良いが、現実的になりましょう。

したがって、最も泥だらけで複雑で不快なタスクから開始し、それらを「ブロック」状態にして、可能な限り依存関係を明確にし、過大評価して削除する必要があります。

合格基準、テストケース

自然言語：ロシア語、英語、中国語-関係ありません-冗長で不正確な場合があります。 テストケースはこれらの制限を克服します。 また、開発者、ビジネスユーザー、品質部門の間の優れたコミュニケーションツールです。

プロジェクト管理

あなたは神を笑わせたいですか？ あなたの計画について彼に話してください。 奇跡が起こり、仕事を始める前にすべての要件を収集して明確にした場合でも、十分な能力のある人がいて、計画ではほとんどの仕事を並行して行うことができますが、従業員の病気、他のリスクの評価や具体化の誤りから免れることはできません。 したがって、計画を定期的に更新し、それを事実と比較する必要があります。 そして、このために、労働時間の会計が重要です。

時間追跡別名時間追跡

業界では、時間と出席が事実上の標準となっています。 評価と同じ機器で作成することが非常に望ましい。 これにより、推定時間から実際に費やされた時間の偏差を追跡できます。 このツールがプロジェクトマネージャーでも使用されていると便利です。 その後、クリティカルパスのすべての遅延がすぐに認識されます。 さまざまなツールを備えたバリアントも可能ですが、プロセスを保守するために大幅に高い人件費が必要になります。つまり、だまされたくなります。 これがどのように終わるかはすでにわかっています。 YouTrackを使用します 。 記事で私が書いたものはすべて、すぐに使用できますが、少しカスタマイズする必要があります。

おわりに

1. 評価が難しい
2. 分解により、要件のギャップを見つけ、評価の質を向上させることができます
3. グループのスコアは個々のスコアよりも正確です。ポーカーを使用してください
4. ブロッカー、テストケース、正式な受け入れ基準によりコミュニケーションが改善され、プロジェクトの成功の可能性が高まります。
5. プロジェクトのクリティカルパスで最もリスクの高いタスクから始める必要があります
6. 評価は一度限りのアクションではなく、プロジェクト管理と切り離せないプロセスです
7. 作業時間を考慮しないと、プロジェクトのステータスを最新に保ち、見積もりを調整することは不可能です

プロジェクト評価についてもっと知りたいですか？

Steve McConnellの本「 ソフトウェアプロジェクトにかかる費用 」およびHabréに関するこのテーマに関する他の記事を読んでください。

1. habr.com/en/company/infopulse/blog/170777
2. habr.com/en/post/308494
3. habr.com/en/company/ruswizards/blog/151029
4. habr.com/en/company/mindbox/blog/321270
5. habr.com/en/post/307820