チームが安定していないときにアジャイル開発を管理する方法は？ [閉まっている]

Question

私は、プロジェクトでアジャイルアプローチ（XPおよびスクラム）を数年間使用してきましたが、素晴らしい結果が得られました。しかし、すべての場合において、開発チームのすべてのメンバーはプロジェクトに100％コミットしました。

今、チームが安定していないときにこれを行うことに直面しています。たとえば、1回のイテレーションには4人の作業員がいて、次の作業員は2人か3人だけかもしれません。

これにより、通常の速度アプローチを使用して推定するのが難しくなる（または不可能になる）ことがわかります。次のことは、各反復の最後にリリースできることを期待できないことです。

ここで別のアプローチが必要かもしれません。バックログからアイテムを取得し、可能な限り混乱させてリリースするだけです。私は本当に 気に入らないのですが...

何か考えはありますか

Answer 1

質問から、一部の開発者（おそらく2）がプロジェクトに100％コミットしており、一部（他の2-3）は一度にしか参加していないと思います。

できることの1つは、100％コミットされているコア開発者と他のすべてのユーザーに異なるプロセスを設定することです。コアな人には通常のアジャイルプロセスを使用し、通常の反復サイクルで作業をリリースします。中核でない人々については、ほとんど計画を立てずに、彼らの（そしてあなたの）見積もりが一度に道になると仮定します。理想的には、それらの変更は隔離され、コアメンバーによってコードの安定したブランチにマージされるべきですが、すべてのプロジェクトのアーキテクチャとチームの役割がこれを許可しているわけではありません。

ポイントは、カオスの原因を分離して隔離し、プロジェクトとチームの中心を影響を受けないままにすることです。

Answer 2

アジャイルアプローチの代わりに、他の反復アプローチと増分アプローチを使用すると、速度を落とすことができます。繰り返しを数週間で測定するのではなく、チームに人を追加したり削除したりする場合は、繰り返しを長くする（おそらく数ヶ月で測定する）方が良いでしょう。

これは、まだいくつかのアジャイル技術を使用できないという意味ではありません。 2週間ごとにリリースする代わりに、6週間（〜2か月）ごとにリリースすることに気付いて、バックログを維持し、チャートを焼き付けます。新しい開発者が経験豊富な開発者に加わる場合は、ペアプログラミングを使用するか、新しい開発者をバグ修正に割り当てるか、新しい開発者をユニットテストのメンテナンスに割り当てて、コードベースの学習を支援します。

Answer 3

速度は単なる推定値です。

単純に、4人の開発者のチームで特定のベロシティ v を持っている場合、（v / 4）* number_of_developers

負けているメンバーが平均よりも特に強いまたは弱い場合、この値を変更できます。

これは、基本的に PivotalTracker がチームの強さの指標で行うことです。

Answer 4

では、チームの規模が絶えず変化するプロジェクトがあり、上司は、どのくらいの時間がかかるかを正確に見積もることを望んでいますか？これは、正確と正確の違いを念頭に置いて行うことができます。精度は、アイテムの数と各アイテムの粒度（分解）に大きく依存します。アイテムが多いほど、大きな数の法則が機能し、過大評価と過小評価が平均化されます。

あなたの正確さは自信の関数です。推定値は単一ポイントの値ではなく、信頼度のパーセンテージを持つ数値の範囲であることに注意してください。たとえば、適切な見積もりは「2週間」ではありません。 「2週間の信頼度50％、4週間の信頼度80％」となります。

私が元の投稿のように任意に管理されているプロジェクトの完了まで見積もりを提供するといううらやましいタスクを割り当てられた人であれば、割り当てられた最小人数に基づいて範囲を見つけようとします（例えば、「2人の開発者に与えられた48から66週間[50％から80％自信]」）、および割り当てられた平均人数に関連する範囲（例えば、5人の開発者に25から45週間[50％から50 80％自信がある]＆quot;）、平均値の低い数字と最小数字の高い数字を使用します（例：「2〜5人の開発者に与えられた25〜66週間[50％〜80％自信がある] ＆quot;）、それでも免責事項を付けます（「コンテキスト切り替えによる損失時間の10％プラス」）。

さらにいいのは、この配置が丁寧で次善である理由と、マルチタスクが地獄を投影する主要な道標である理由を正確に説明することです。

他の誰かが示唆したように、ワークフローを反復ベースからフローベース（かんばん）に変更することは、良い戦略かもしれません。カンバンを使用すると、バックログ内のアイテムの優先度を変更することにより、プロジェクトの優先度の変更を処理できます。アイテムがチームによって取得されると、通常は終了します（ワークフロー全体に渡って流れ、利害関係者は進行中の作業に手を加えてチームを混乱させることはできません）。持続的なエンジニアリングプロジェクトにかんばんを使用しましたが、非常にうまく機能しました。見積もりにどのように役立つかについて、連続フローの鍵は、各作業項目をほぼ同じサイズ（10x、20x、100xではなく1x、2x、3x）にすることです。プロセス状態の変更の日付（キュー1/15、デザイン1/22、開発1/24、テスト2/4、統合2/7など）を追跡し、生成することにより、ワークフロー内のアイテムの移動を追跡する必要があります。累積フロー図を定期的に使用して、一定期間の状態継続時間を評価します。各アイテムのサイズとアイテムのワークフローの時間を知っている場合、プロジェクトにかかる時間を計算することは、読者に残された簡単な計算課題です。 （より興味深い質問は、制約を見つける方法です...そして、それをどのように削除するかです。ヒント：制約の前に作業が積み重なるため、状態を長時間探します。）

Answer 5

ストーリーを作成する個々の開発者に、ストーリーを完了するために必要な労力を見積もらせます。その開発者の推定値の過去の変動を考慮することができますが、アイデアは、その推定値を取得し、そのスプリントでいくつのストーリーを完了できるかを把握することです。

Answer 6

先読みリリースの計画には、平均速度が主に使用されることを忘れないでください。 チームは、各イテレーションでバックログアイテムの数を選択する責任があります（過去の速度を知ることでそれらを支援できますが）。

チームのサイズ（したがって速度）が反復ごとに変動している場合でも、チームの変動が継続するため、チームの長期的な平均速度を前提として、過去N回のスプリントの平均速度を使用して、有用なリリース計画を実行できます実際に安定します。

Answer 7

ここでの主な問題は、チームがスプリントからスプリントに変更しているため、チームが予測可能な見積もりと納品を提供することが難しいことです。また、これはチームのコミットメントと継続的な改善を損なう可能性があります。

このケースは、実際にはかんばん方式に適している可能性があります。簡単な概要については、KenbanのHenrik Knibergsの紹介を参照してください。

がんばって！