ソロ開発者のためのキャパシティプランニング-アクティビティ？
キャパシティプランニングで使用するタスクの[アクティビティ]フィールドを設定する利点がわかりません（スクラムテンプレートを使用しています）。実際、そうすることは物事をより面倒にするようです。
要件、設計、開発などの間で時間のバランスを取りたいのはなぜですか？実行する実際のタスクは、それがどのような種類の作業であるかではなく、物事を推進する必要があると思います。私がやろうとしているのは、スプリントの計画中に1日あたりの容量を調整して、赤字にならないようにすることだけです。少なくとも私の場合は、それだけで機能が無効になります。
これまで見てきたすべてのキャパシティプランニングの例では、各チームメンバーに1つのアクティビティが割り当てられています。ここで、アクティビティが役立つ場所を確認できます。これは、チームメンバーが予定より少し進んでいる可能性のある誰かからの支援を必要とする場合を知る手段です。
チームにとっては、確かに。しかし、一人の開発者にとって、私はそれを見ることができません。
誰かが私がこれで間違っているかもしれないところを私に示すことができますか？アクティビティトラッキングを使用すると、私の生活をより困難にするだけでなく、何ができますか？
編集：
明確にするために、私はキャパシティプランニング（CP）のコンテキストでのみ[アクティビティ]フィールドの使用について話しています。後のレポートで使用するためにタスクの[アクティビティ]フィールドを設定しても問題ありません。実際、そうしたいと思います。しかし、CPの場合は別の話です。
たとえば、次の計画を検討してください。
これらのCPDフィールドには、不要と思われる詳細がたくさんあります。優先順位と労力に基づいてスプリントのタスクを選択した後、右側のグラフ（上の図の下に表示）が赤く表示されなくなるまで、数字をいじくりまわすだけです。
それは無駄な運動のようです。私の主張は、実行される作業は、作業のタイプではなく、タスク選択を駆動する必要があるということです。特に、この部分に到達するまでに、とにかくタスクをすでに選択しているので。
はい、それは本当です... TFSの最近の採用の背後にある動機の大部分は、ひどく過小評価している私自身の傾向に巻き込まれています。実際、私の顧客の1人が「ジェフ、誰もあなたを過小評価することはできない」と言っています。
しかし、振り返ってみると、私の過小評価はタスクベースであり、タイプの作業ベースではありませんでした。
何が欠けていますか？[CP]タブの[アクティビティ]フィールドを空のままにして、個々のキャパシティを毎日の作業時間数に設定する必要がありますか？
私たちにとって、これはレポートのドリルダウンカテゴリにすぎません。彼らはそれがどんな種類の活動であるかを知るためにタスクの説明を通り抜ける必要を省きます。
誰もあなたのスプリントに目を向けておらず、レポートなどを作成していない場合、これを無視したくなるかもしれませんが、実際にはそれほど余分な作業ではありません。
マクロレベルでは、プロジェクトの牽引力を判断するための酸テストとして使用できます。最初のいくつかのスプリントとその後の開発に関する分析と要件があるものもあれば、各スプリントにすべてのビットがあるものもあります。それは本当にプロジェクトに依存します。
仲間の孤独な開発者として、特にコミュニケーションと時間の文書化の分野で、チームにとってより有益な多くのものの必要性を理解することは困難です。
見積もりスキルをどの程度微調整しますか？考慮していない領域（展開など）があるか、または一部の領域を過小評価または過大評価している可能性があります。私の経験では、チームは設計に非生産的な時間を費やし過ぎていることに夢中になっているように見えるので、時計を見て、トピックに留まるようにすることが重要です。孤独な開発者は、設計に十分な時間を設定できないリスクを冒します。
チームを成長させる。理想的にはスクラムでは、あなたと同じようにすべてを行う別のチームメンバーを追加しますが、パートタイムのヘルプまたはコンサルタントだけがあなたが行くことになる状況を見つけるかもしれません取得する。