私はプロジェクトにアジャイルアプローチ（XPとスクラム）を数年間使用しており、素晴らしい結果が得られています。しかし、すべての場合において、開発チームのすべてのメンバーはプロジェクトに100％コミットしました。
今、私はチームが安定していないときにこれを行うことに直面しています。たとえば、1回の反復で4人が作業し、次の反復では2人か3人しか作業しない場合があります。
これにより、通常の速度アプローチを使用して推定することが困難（または不可能）になることを認識しています。これは、変動が大きく、安定しないためです。次のことは、各反復の終わりにリリースできることを実際に期待することはできないということです。
ここでは別のアプローチが必要かもしれません。バックログからコンテンツを取得し、可能な場合はいつでも混乱させてリリースします。私は本当にそれが好きではありません...
何かご意見は？
質問から、プロジェクトに 100% コミットしている開発者 (おそらく 2 人) と、一度にしか参加しない開発者 (別の 2 ～ 3 人) がいると思います。
できることの 1 つは、100% コミットしているコア開発者とそれ以外のすべての開発者に異なるプロセスを設定することです。コア メンバーには通常のアジャイル プロセスを使用し、通常のイテレーション サイクルで作業をリリースします。コアでない人は、ほとんど計画を立てず、彼ら (およびあなた) の見積もりが時々途方もないものになると想定してください。理想的には、それらの変更は分離され、コア メンバーによってコードの安定したブランチにマージされる必要がありますが、すべてのプロジェクトのアーキテクチャとチームの役割がこれを許可するわけではありません。
ポイントは、混乱の原因を分離して隔離し、プロジェクトとチームの中心に影響を与えないようにすることです。
おそらく、アジャイルなアプローチの代わりに、他の反復的で段階的なアプローチで物事を遅くすることができます. チームに人を追加したり削除したりし続ける場合は、反復を数週間単位で測定する代わりに、より長い反復 (おそらく月単位で測定) を行う方がよいでしょう。
これは、一部のアジャイル手法をまだ使用できないという意味ではありません。2 週間ごとにリリースするのではなく、6 週間ごと (約 2 か月) にリリースすることを認識して、バックログとバーン ダウン チャートを維持します。新しい開発者が経験豊富な開発者に加わる場合は、ペア プログラミングを使用するか、新しい開発者をバグ修正に割り当てるか、新しい開発者を単体テストの維持に割り当てて、コード ベースの学習を支援します。
チームの規模が絶えず変化するプロジェクトがあり、上司から所要時間の正確な見積もりを求められていますか? 正確と正確の違いを念頭に置いている限り、これを行うことができます。精度は、アイテムの数と各アイテムの粒度 (分解) に大きく依存します。アイテムが多ければ多いほど、大数の法則が機能し、過大評価と過小評価が平均化されます。
あなたの正確さは自信の関数です。推定値は単一点の値ではなく、信頼度のある数値の範囲であることに注意してください。たとえば、適切な見積もりは「2 週間」ではなく、「2 週間で 50% の信頼度、4 週間で 80% の信頼度」になります。
元の投稿のように恣意的に管理されているプロジェクトの完了までの見積もりを提供するといううらやましい仕事を私が割り当てられた人物である場合、割り当てられた最小人数に基づいて範囲を把握しようとします（たとえば、「 2 人の開発者の場合、48 ～ 66 週間 [50% ～ 80% の確信度]")、および割り当てられた平均人数に関連する範囲 (たとえば、「5 人の開発者で 25 ～ 45 週間 [50% ～ 80% の確信度]」) 、最小数からの高い数値とともに平均数からの低い数値を使用します (たとえば、「2 から 5 人の開発者 [50% から 80% の信頼度] のどこかで与えられた 25 から 66 週間」)。 d 免責事項を記載します (「コンテキストの切り替えによる失われた時間に対してプラス 10%」)。
さらに良いことに、なぜこの取り決めが礼儀正しく、最適ではないのか、そしてマルチタスクが地獄を計画する道の主要な道しるべである理由を正確に説明したいと思います.
他の誰かが示唆したように、ワークフローを反復ベースからフローベース (かんばん) に変更することは、良い戦略かもしれません。かんばんでは、バックログ内のアイテムの優先度を変更することで、プロジェクトの優先度の変更を処理します。アイテムがチームによって取得されると、通常は終了します (ワークフロー全体に流れます。利害関係者は、進行中の作業をいじってチームを混乱させることはできません)。私はカンバンを継続的なエンジニアリング プロジェクトに使用してきましたが、非常にうまく機能しました。見積もりにどのように役立つかというと、継続的なフローの鍵は、各作業項目をほぼ同じサイズにすることです (10x、20x、100x ではなく、1x、2x、3x)。プロセス状態の変化の日付を追跡することにより、ワークフロー内のアイテムの移動を追跡する必要があります。たとえば、キュー 1/15、設計 1/22、開発 1/24、テスト 2/4、統合 2/7 など 次に、累積フロー図を定期的に生成して、時間の経過に伴う状態期間を評価します。各アイテムのサイズとアイテムのワークフロー全体の時間がわかっている場合、プロジェクトにかかる時間を計算することは、読者に任せる簡単な計算作業です。(より興味深い質問は、制約を見つける方法です...そして、それらを削除する方法です。ヒント: 制約の前に作業が積み重なるため、状態の長い時間を探してください。)
速度はあくまでも目安です。
v単純に、 4 人の開発者のチームで特定のベロシティがある場合、イテレーションを次のベロシティでスケジュールします。(v/4)*number_of_developers
あなたが失っているメンバーが平均よりも特に強いか弱い場合は、この値をごまかすことができます.
これは基本的に、PivotalTrackerがチームの強さの指標で行うことです。
平均速度は主に先読みリリース計画に使用されることを忘れないでください。チームは、各反復で引き受けるバックログアイテムの数を選択する責任があります（ただし、過去の速度を知ることでそれらを支援できます）。
チームのサイズ（したがって速度）が反復ごとに変動している場合でも、チームの変動が継続し、したがってチームの長期平均速度が実際に安定。
ストーリーに取り組む個々の開発者に、ストーリーを完成させるために必要な労力を見積もりましょう。その開発者の見積もりでは過去の差異を考慮に入れることができますが、アイデアは、彼らの見積もりを取り、そのスプリントで終了できるストーリーの数を把握できるということです。
ここでの主な問題は、チームがスプリントからスプリントへと変化しているため、チームが予測可能な見積もりと配信を提供するのが難しいことに気付くことです。これはまた、チームのコミットメントと継続的な改善を損なう可能性があります。
このケースは、実際にはカンバン アプローチに適している可能性があります。簡単な概要については、Henrik Kniberg のかんばん入門をご覧ください。
幸運を！