アジャイル手法におけるユーザーの変更/要件の増加
私の質問は非常に簡単です。チームがソフトウェアプロジェクトにアジャイル手法を適用していて、スケジュールが大きく影響を受けるほど多くの反復と要件の変更がある状況に対処するにはどうすればよいですか？さらに、あなたは常にスケジュール内で物事を成し遂げたいと思っているマネージャーがいて、それはあなたがコントロールできないものですか？
あなたのマネージャーは実際にアジャイルを購入するのではなく、アジャイルペグを「固定日付」型に入れようとするようです。
あなたはcan固定の終了日でアジャイルプロジェクトを実行しますが、すべての関係者は、終了日までに完了した機能を提供するだけであることを理解する必要があります。事前に設定された日付と機能の両方に同意し、最終的な納品に影響を与えることなく顧客が自由に変更できるようにすることはできません。
アジャイル開発チームを固定日プロジェクトと組み合わせる方法の1つは、プロジェクトの範囲を慎重に保護し、実際の顧客との変更要求の交渉を開発チームから遠ざける、強力な社内の製品所有者を持つことです。その場合、製品の所有者は、スコープクリープによる期限の欠落を回避する責任があります。これは、元のスケジュールがそもそも現実的であったと想定しています。
残念ながら、あなたが自分自身を見つける状況はおそらく最も一般的なものの1つです。アジャイルは、理解のためではなく、話題のために多くの市場で採用されています。同じ古い問題が依然として存在します：固定スコープ、固定日付、固定コストの要望。鉄の三角形が修正されている場合、開発プロセスはあなたを救うつもりはありません。
鉄のトライアングルに遭遇したときは、クライアントと妥協する必要があります。あなたの場合、あなたのクライアントはあなたのマネージャーかもしれません。クライアントは、以下から選択する必要があります（またはそれらすべてのバランス）：
- スコープ調整。一部の機能を削除して、変更の余地を残します。すでに提供されている機能へのいくつかの変更は、バックログに残っている可能性のある新しい機能を構築するよりも、実際に行うことがより重要です。プロダクトオーナー（または優先順位の決定を支援している人）は、クライアントと協力してこれを解決できるため、変更を求めたり、実際に必要な機能を失ったりすることはありません。その逆も同様です。
- スケジュールの調整。後の納期を許可するか、複数の納期を許可します。最初の機能セットが時間どおりに納品され、チームは後日、新しいスコープで2番目のリリースを納品します。日付を記入して2週間後に変更しても大丈夫ですか？これは反復的な開発であるため、物事は多くのシナリオで継続的に提供できるはずです。
- 予算調整。ほとんどのクライアントはプロジェクトの予算を固定しているため、これはおそらく最も難しいことです。日付が非常に重要であり（市場投入計画が実施されており、日付を見逃すことはできません）、タイムラインに合わせて範囲を縮小できない場合は、追加予算のリクエストを使用して、のサイズを増やすことができます。チームは、特定の反復内でより多くのことを実行できるようにします。
最も重要な部分は、クライアントが彼らが求めているものの影響を理解する必要があるということです。彼らが変更を要求するとき、彼らは機能を失うか、日付を逃すか、またはプロジェクトのコストを増加させています。クライアントがリクエストの影響を理解していることを確認することが最も重要であり、期待を設定し続けるために、クライアントと一緒にプロダクトオーナーの役割を果たす誰かが本当に必要な理由の1つです。
あなたのケースでは、あなたのチームはあなたのマネージャーと連携するチームリーダーを必要とし、その影響について彼らとこれらの議論をしています。あなたのマネージャーもあなたが失敗することを望んでいませんが、時にはそれはチェーンのどこかで理解が不足しているだけです。マネージャーがスケジュールについて誰かに打ち明けられる可能性があるので、マネージャーに弾薬を渡してチェーンを遡り、より多くの時間、予算、またはスコープ削減のために戦うことは、彼らとあなたを助けるでしょう。
プロジェクトを完了するためのスケジュールが本当に決まっている場合は、アジャイル性の低いプロセスを使用する必要があります。
タイムラインが固定されている場合、要件（機能、ユーザーストーリー）も固定するか、少なくともサイズを固定する必要があります。決まったスケジュールを満たすには、「変化に対応する」よりも「計画に従う」ことに傾倒する必要があります。
変更管理が必要です。誰かがより多くの機能を要求した場合、マネージャーはスケジュールを長くすることなく、要求に対応する方法を決定する必要があります。 ジェイの答え 従来のプロジェクト管理の範囲/スケジュール/予算のトレードオフを示します。
私の経験では、限られた時間枠内でより多くの機能を取得するためにお金を払うための良いオプションがないことがよくあります。その場合、選択肢は
- 新機能を拒否する
- 重要度の低い別の機能をキャンセルして、新しい機能のためのスペースを確保します
- 特定の機能のより安価な実装を受け入れます。 （例：四半期の売上高はテキストとして表示されますが、インタラクティブな3D棒グラフには表示されません）
問題は、ソフトウェア開発が人々によって行われ、管理されていることです。人々（特に管理者）は、クライアントにノーと言いたくないのです。奇妙なことに、クライアントは人々が思っているよりもそれを受け入れる傾向があります。彼らは心の中で、新機能には時間と費用がかかることを知っていますが、後日まで延期されるべきであった要求に対応するために週90時間働く人々によって月を求めることができると考えるように訓練されています。
あなたがアジャイルをしているのか、ウォーターフォールをしているのかは関係ありません。問題は、クライアントと通信している人が彼に真実を伝える勇気を持っていないということです。新機能を要求すると、$ Xのコストがかかり、実行にさらにX時間かかり、期限が変わります。
できる最善のことは、新しいコスト見積もり、作業時間の新しい見積もり、新しい期限、または次の反復に新しい機能を含めることの提案、または何が行われるかの提案があるときにプッシュバックすることです。新機能のためのスペースを作るためにドロップされます。これは書面で行う必要があり、スコープのクリープが発生するたびに発生する必要があります。
開発者として、新しい機能を追加するように求められた場合、このイテレーションでまだ開始されていない、またはほとんど不完全な機能を指摘し（完成した機能、またはほぼ準備ができている機能を削除したくない）、次に、新しい機能に対応するためにどちらを削除するか、または新しい期限を尋ねます。期限の変更またはその他の未完了の作業を将来の反復に移さずに、これ以上の作業を受け入れないでください。ただし、これはeveyoneを搭載している場合にのみ機能します。スコープクリープがあなたの残りを弱体化させるならば、このタイプを受け入れる一人の人。簡単に変更できることを一度受け入れると、複雑な変更をさらに先に進める可能性が損なわれます。あなたとあなたの同僚はこれについて懲戒処分を受ける必要があります。