アジャイル、ウォーターフォール、要件の変更

要件の変更によって「アジャイル」と定義されたプロジェクトのこの問題が発生したことはありますか？私は4週間のSprintで実行される開発プロジェクトに取り組んでいますが、これらのSprintの間には常に変更があります。それでもアジャイルとして定義されていますか？私はそれがサブアジャイルプロセスのようなものだと感じています-アジャイルプロセスの要件は、スプリントの始めに定義され、その終わりに向かってレビューされるべきです。私はこれで正しいですか？この経験を教えてください。

アジャイルプロセスの要件は、スプリントの開始時に定義し、そのスプリントに向けて検討する必要があります。私はこれで正しいですか？

いいえ、これはプロジェクトの性質（およびプロセス）によって異なります。

一部のアジャイル開発モデルでは、スプリント中に要件を修正する必要があり、次のスプリントに対してのみ変更する必要があります（顕著な例はスクラムです）。

ただし、ほとんどの場合、変更が発生する可能性のあるプロセスもあります（変更が原因で生じる遅延と追加の作業を顧客が受け入れる限り）。これらのワークフローの管理にはかんばんがよく使用されます（かんばんはスクラムと組み合わせることもできます）。

どのモデルに従うかは、各プロジェクトの詳細によって異なります。

そのため、はい、お客様が要件を常に変更する可能性が必要だと感じた場合、アジャイルプロセスでこれに対応できます。ただし、お客様は、絶え間ない変更の結果を認識し、プロジェクトの速度が低下することを理解する必要があります。

これは、アジャイルマニフェストの原則、つまり「プロセスとツールに対する個人と相互作用」、および「計画に従うことによる変更への対応」に要約されます。

私はあなたが尋ねる必要がある質問は次のとおりだと思います：なぜあなたは要件の変更によってオーバーランするのですか？一般的な原因は次のとおりです。

• 開発者はエンドユーザーと（十分）接触していないため、ユーザーのニーズを理解できません。代わりに、要件を抽象的なルービックキューブのように扱います-彼らは自分の精神を理解しようとさえせずに要件の文字に従います
• 誰か（たとえば、マーケティングの担当者）が、エンドユーザーには意味をなさない要件を追加しています（たとえば、パンフレットではいい音がします）。したがって、「実際の」要件と「他の」要件との間には、開発者の背中をめぐって戦う戦いがあります。
• プロジェクトの範囲は定義されていません（とにかく、ワードプロセッサを実装している場合は、給与計算を行う小さなモジュールを追加するだけではどうでしょうか。ワードプロセッサでC ++コードもコンパイルできるようにしますか？」）

根本的な問題が何であれ、それを修正する必要があります。「アジャイル」（またはその他の方法論）の層の下で溺死させることはできません。

少なくともスクラムでは、最近の管理タイプで最も人気のあるアジャイルプロセスのようですが、スプリントの範囲は固定されています。スプリント中にスプリントバックログが変化している場合、それはスクラムではなく、混乱です。スプリントバックログは、スプリントの開始時に作成し、スプリントの終了時まで固定したままにする必要があります（その時点で、次のスプリント用に新しいスプリントバックログを作成します）。

スプリント中にプロダクトバックログが変化しても、大したことではありません。変更は、次のスプリントに対する他の要件と同様に、優先順位が付けられ、推定され、選択された新しい作業になります。要件が大きく変化し、プロダクトオーナーが定期的にスプリントをキャンセルする必要がある場合は、大文字の「T」のトラブルが発生します。

多分あなたはより短いスプリントが必要ですか？

プログラマーの健全性のためには、リビジョン/スプリント中に要件が変更されないことが最善です。

あなたの状況では、2つの明白なオプションがあります：

1. より短いスプリント
2. リビジョン/スプリント全体がキャンセルされて再計画されない限り、リビジョン/スプリント中に要件を変更しないことにお客様に同意してもらいます。

私は両方を強くお勧めします。

主な問題は、あなたがスクラムを使用していると信じているが、使っていないということです。特にあなたの製品の所有者はそれに従っていません。スクラムではスプリントは安全なゾーンであり、現在のスプリントがキャンセルされない限り、コミットされたユーザーストーリーに変更を加えることはできません。これを実施するのはスクラムマスターの責任です。これが環境で機能しない場合は、プロセスの問題です。つまり、スクラムを使用していません。

（スクラムをフォローしたい場合）実行できる最も簡単な変更は、スプリントを短くすることです（たとえば、1週間）。スクラムの初期には4週間のスプリントがオプションと見なされていましたが、今日の一般的なものは1〜2週間で、3週間が上限と見なされています。4週間は環境の変化に非常に長い時間です。