要件の変化にどのように対処しますか？
私の現在の仕事では、要件の変更が多いように感じます。私たちは「アジャイル」ショップなので、調整する必要があることとそうでないことを理解していますが、変更が大きく、些細なことではない場合があります。
私の質問は、変更のコストをどのように効果的に伝えるかです。アジャイルであるため、変更が十分に大きい場合、現在のスプリントから何かが削除されますが、通常は次に追加されるだけです。私たちのモデルはSaaSなので、エンドカスタマーは事実上ビジネスそのものであり、カット機能n週間後に提供されることを知っています。
n週間だけ遅れていたため、機能の削除はコミュニケーションに使用するものではありません。ビジネスに変更のコストを理解させるには、他にどのような方法がありますか？
@ジョー「私たちは「アジャイル」ショップなので、調整することになっているはずですが、そうでない場合もありますが、変更が大きくて些細なことはありません。」
プロセスで要件の変化率を制御できない場合、プロセスは俊敏ではなく、無計画です。アジャイルは、「私の道に来るものを何でも取る」という意味ではありません。
要件の変更/クリープを制御するには、プロセスで、要件が変更されないという概念（それがスクラムの中心にあるという概念）を採用できます。要件の変更は、古い要件を新しい要件に置き換えるものとして扱います。要件のバックログが必要であり、実装するものをユーザーに選択させる必要があります。
2週間でXとYが必要でしたが、突然Zが必要になりました。それでは、3つすべてを4週間でお届けできます。または、2週間で（XとZ）または（XとY）または（YとZ）のペアを提供し、残りのペアを後で配送することもできます。選択してください。
これは、お客様と交渉する方法です。これは、要件変更のコストを伝える方法です。あなたのグループがその力を持っていない場合、あなたはアジャイルショップにいないので、それについてあなたができることは何もありません。それは悪いですが、それは本当です。
交渉できる場合は、要件と要件変更の実装にかかる時間を（正確に）追跡する必要があります。つまり、過去と現在のプロジェクトからこのデータを収集する必要があります。
リクエスト（またはNリクエストの影響を受けるモジュール）ごとに、（開発者数などのリソースに加えて）元の推定時間と実際の完了時間を収集します。さらに良いのは、リクエスト/リクエストの変更のサイズを推定することです（過去のプロジェクトとリクエストのコード行または関数ポイントに関して）。
ユーザーと会話できる指標があるとします。たとえば、新しいリクエストには、1K行のコード、または平均5つの入力フィールド（50関数ポイント）を持つ10のWebページが必要です。
次に、過去のプロジェクトの履歴データ固有（コード行、Webページ、実際の関数ポイントなど）を確認します。絶対完了時間の観点からこれらの各コストを見積もることができます。十分なデータがある場合は、実際の開発者数を追跡する要件を特定することもできます。
次に、それを使用し、顧客に履歴データに基づいてそれを伝えます。プロジェクトの失敗は指数分布に従う傾向があると主張します。そして、あなたはあなたの顧客のために次の議論で武装しています：
過去と現在のプロジェクトのデータと利用可能なリソースに基づいて、あなたが求めている要件は
失敗の確率が25％（または成功の75％）で完了するまでのX時間
1.5 *失敗の5％（または成功の95％）で完了するまでのX時間
0.5 *失敗するまでの時間の95％（または成功の5％）
時間量の関数としての失敗の確率は、通常、95％、25％、および5％になります（指数分布に似ています）。特定のベースライン量がある程度まともな成功のチャンスを与えるというメッセージを伝えます（ただし、実際のリスクがあります） ）。その1.5は、最小限のリスクでほぼ確実に成功する可能性がありますが、それよりはるかに低いです（元の0.5はほぼ確実に失敗することを保証します）。
あなたは彼らにそれを消化させます。彼らが危険な命題にまだ行くなら（昨日やった！）少なくともあなたはあなたが彼らにそう言ったことを書面で持っています。アジャイルであるだけでなくエンジニアリングのようなグループに希望がある場合、顧客はあなたの数を真剣に検討し、これと今後のリクエストをそれに応じてスケジュールするかもしれません。
技術者としてのあなたの仕事は、変更を要求することは無料の食事ではないことを、技術者が確認できる明確な言葉で説明することです。
あなたが述べたことから、あなたには問題はありません。彼らは変更を求め、あなたがそれが可能であると言うまで待つか、別の機能を延期する用意があります。時間、リソース、要件のバランスのようです。
新しい追加/変更の最小経過時間を設定してみてください（バグ修正には適用されません）。たとえば、3週間経過するまで、新しい変更を行うことはできません。
タスクの最小経過時間は、最初はすべてのタスクが非常に重要であるように見えるのでいいですが、しばらく待つと、重要性が大幅に低下することがよくあります。あなたの時間間隔に応じて、それはあなたが取り組んでいるタスクの少なくともその時間の安定を与えます。
経過時間を追跡するには、タスクをいくつかのリストに追加することを許可しますが、その期間が経過するまで、それらは作業対象のタスクとは見なされません。
これは非常に一般的な問題です。プロジェクトが技術用語でどれだけ速く進んでいても、クライアントはそれがはるかに遅くなっていると認識し、開発者はとにかく何もしてはいけないと考えているので、自由に要件を変更できます。
この欠陥のある認識は、時間を消費し、クライアントによって適切に説明されない3つの主要な開発タスクから生じます。
- コードレビュー/クリーンアップ：古いコードは肥大化し、めちゃくちゃになり、定期的なレビューとクリーンアップが必要です。これには多くの時間がかかり、クライアントはそれを信じません。
- セキュリティ監査と修正：特にジュニアチームメンバーがいる場合は、コードに関連するセキュリティの問題が数多く発生し、作成されたすべての新しいコードを定期的に確認し、セキュリティ上問題があると思われるものを書き直す必要があります。視点では、クライアントはこの時間を知ることも、説明することもありません。
- アーキテクチャ関連の変更：成長するコードベースでは、複数のポイントで構造的な再考とリファクタリングが必要になる可能性があります（ほとんどの場合そうなります）。A-パフォーマンス関連の変更/最適化（アルゴリズムの変更、ライブラリの置き換え、キャッシュエンジンなど）または：B-生産性関連の変更/最適化（可読性、コードの再利用性、理解の容易さ、新しいコーディング規約、新しいフレームワークなど）。
上記のいずれも、エンドクライアントによって理解され、適切に説明されることはありません。
基本的に、「ビュー」（GUI要素）がないものは何も行われていません。
これをプロジェニックスの定理と呼びましょう。笑ってはいけません：D