みなさんこんにちは！
今日は、長年の共同作業でチームで開発したタスクのいくつかの実践評価についてお話したいと思います。 この記事が、経営の道を歩み始めたばかりの人々、特に「血なまぐさい企業」でウォーターフェルに取り組んでいる人々に役立つことを願っています。
効果的な計画は、さまざまな要因に依存します。評価の質、ソリューションの詳細の精緻化、使用する計画方法論、正しいリスク評価です。
まず、計画の準備段階、つまり開発者によるタスクの評価について説明します。 私たちのチームでは、官僚主義と不可欠な必要性のバランスを取りながら、不必要な遅延や反省なしに評価を作業計画に変えることができる多くのプラクティスを開発することができました。
それでは、評価のルールから始めましょう。
均一なルールに従ってタスクを評価します
評価ルールは、評価の開発者の1人が1人/日の仕事の下で、会議、紅茶/コーヒー、さらには衛生と衛生のニーズを計画するために中断することなく8時間連続して作業することを意味することが判明した後に登場しました。 したがって、私たちはチームとして非常に単純な合意を作成しました。
- 評価は工数で行われます（単に文書に「日」と記載します）。
- 1人分のタスクは1営業日で解決されます。 0.5人日は、朝に始まり、昼食で終わることです。 このマンデイには、同僚、クッキー付きのお茶などを支援する計画会議が含まれます。
- （マネージャー向け）1人日で約6時間の効果的な開発が可能です。
ルールは必ずしも同じである必要はありません。主なことは、同じ座標系で作業することです。
タスクを分解する
多くの場合、開発者にとって「はい、数週間の作業があります」と言う方がはるかに簡単です。 また、マネージャーは計画に80時間のタスクを追加する必要があります。 しかし、計画に対するこのアプローチのために、後の質問が発生します。「残りの作業の割合を教えてください」など、開発者がタスクを完了する上でどのような進捗があるかを理解するためのその他の方法です。
次の制限を設定しました。タスクは、期間が0.5〜3日のサブタスクに分解されます。 各サブタスクは完全な機能です。
繰り返しますが、チームでは、制限が異なる場合があります。 バランスを保つ必要があります。
しかし、私たちの経験では、サブタスクは3日以上です。
0.5日未満には欠点もあります。
- タスクが小さいほど、それらの間の依存関係が多くなります。
- タスクが小さいほど、それらを追跡するためにより多くの時間と注意が必要です。
同時に、すぐに分解ポイント（サブタスク）に番号を付けます-ネットワークダイアグラム（以下でさらに説明します）および計画でそれらを操作する方がはるかに便利です。
統合アプローチ
この状況に直面すると、別のチームの開発の複雑さの評価は、私たちのチームよりも25％少なくなりました。 この状況は経営者にとって非常に興味深いものでした。調査の結果、開発者が開発結果を確認した評価に同僚が含まれていなかったことがわかりました（内部スモークテスト）。
このような状況を回避するために、評価ルールにいくつかのポイントを追加しました。
- 単体テストは開発評価に含まれています。
- 煙検査は個別に評価します。
この段落では、すべてのチームメンバーと利害関係者が同じ座標系で作業する必要があることを再度思い出します。
タスクの依存関係を評価する
依存関係のない計画はルーレットゲームのようなものです。 すべてがうまくいけば、あなたの計画はうまく実行されるでしょう。 しかし、作業のいくつかの要素の厳格な相互依存に出くわした場合、計画は「実行」されます。
したがって、品質計画のためには、分解に加えて、サブタスク同士の関係に関する情報が必要です。 たとえば、最初にバックエンドを開発し、次にフロントエンドを開発します。 または、最初にバックエンド側でスタブを作成してから、バックエンドとフロントエンドを並行して見ました。 そして実際、そして別のケースでは、作品間に依存関係があります。 フロントエンドの作業の開始に影響します。
依存関係を表示する最も簡単で理解しやすい方法は、ネットワーク図です。 たとえば、要素がサブタスクであり、矢印が要素間の依存関係を示しているもの。
制限を考慮します
多くの場合、タスクにはいくつかの他の制限があります。たとえば、すべてのチームメンバーが所有するわけではないテクノロジーを適用する必要があります。 私たちのチームでは、誰もがバックエンドスタックを所有していますが、フロントエンドを開発できるのは少数の開発者だけです。 したがって、分解の各要素で、特定のアイテムがどのテクノロジーに属するかを示します。 作業をフロントエンドとバックエンドに分割することに関するこの情報は、重要なチェーンを構築する際の計画に使用されます。
リスク評価
開発者の評価に経験値を掛けるマネージャーについてのジョークがあります。 マキシム・ドロフェーフは 、なぜそうしないのかを説明します。
推測ゲームをプレイする代わりに、リスクを次のように評価します。各分解ポイントについて、開発者はリスクとは何か、その確率とは何か、そして複雑さにどのような影響があるかを記述します。 これを開発リスクと呼びます。
計画する際に、マネージャーはリスクの処理方法を決定します。 また、開発リスクに加えて、計画段階で管理リスクを評価および追加します。 たとえば、以前のプロジェクトの統計に基づいています。
実際に
実際、私たちのチームでは、評価を実行するときに、開発者は次のような簡単な表に記入します。
| サブタスク番号 | サブタスク | アイテムTK | テクノロジー | 推定日数 | リスク、日 |
|---|---|---|---|---|---|
| 1 | スタブを開発する | バックエンド | 1 | ||
| 2 | 機能を実装する | 1 | バックエンド | 3 | 1（レイアウトの再構成が必要な場合があります） |
| 3 | 実装フォーム | 2 | フロントエンド | 2 |
また、次のようなネットワーク図も作成します。
おわりに
これで、開発者による評価が完了しました。 そして、マネージャーは作業を開始し、そのタスクは、2つの成果物データをタスクの完成した作業計画に変えることです。 この変換の発生方法については、次のパートで説明します。
ご清聴ありがとうございました！