変化する要件にどのように対処しますか？[閉まっている]

私の現在の仕事では、要件の変更がたくさんあるように感じます。私たちは「アジャイル」ショップですので、私たちは調整することになっていると思いますが、時には変化は大きく、些細なことではありません。

私の質問は、変化のコストをどのように効果的に伝えるかです。アジャイルであるため、変更が十分に大きい場合、現在のスプリントから何かがドロップされますが、通常は次回に追加されます。私たちのモデルはSaaSであるため、最終顧客は事実上ビジネスそのものであり、彼らはn週間後にカット機能を取得することを知っています。

私は本当にそれだけ遅れたとして、通信に使用するものではありません、私は機能の除去である時に取得しようとしていますどのような推測のn週間。変更にかかるコストをビジネスに理解させるには、他にどのような方法が必要ですか？

@Joe「私たちは「アジャイル」ショップなので、私たちは調整する必要があると思いますが、いつかは変化が大きく、些細なことはありません。」

プロセスで要件の変更率を制御できない場合、プロセスはアジャイルではなく、無計画です。アジャイルとは、「自分のやり方で何かをする」という意味ではありません。

要件の変更/クリープを制御するには、プロセスで要件が変更されないという概念（スクラムの中心にあるという概念）を採用できます。要件の変更は、古い要件を新しい要件に置き換えるものとして扱います。要件のバックログが必要であり、ユーザーに実装したい要件を選択させる必要があります。

あなたは2週間でXとYが欲しかったのですが、突然Zが欲しくなったのです。それでは、4週間で3つすべてをお届けできます。または、2週間でペア（XとZ）または（XとY）または（YとZ）を提供し、残りの1つを後で提供できます。選択してください。

これは、顧客と交渉する方法です。これは、要件変更のコストを伝える方法です。あなたのグループがその力を持っていない場合、あなたはアジャイルショップにいません、そしてあなたがそれについてできることは何もありません。それはひどいですが、それは本当です。

交渉できる場合は、要件と要件の変更の実装にかかる時間を（正確に）追跡する必要があります。つまり、過去および現在のプロジェクトからこのデータを収集する必要があります。

リクエスト（またはN個のリクエストの影響を受けるモジュール）ごとに、（開発者数などのリソースに加えて）元の推定時間と実際の完了時間を収集します。さらに良いことに、リクエスト/リクエストの変更のサイズを見積もってください（過去のプロジェクトやリクエストのコード行または機能ポイントの観点から）。

ユーザーと話すことができる指標があるとします。新しいリクエストには、たとえば1K行のコード、または平均5つの入力フィールド（50の関数ポイント）を持つ10のWebページが必要になることがわかっています。

次に、過去のプロジェクトに固有の履歴データ（コードの行ごと、Webページごと、実際の機能ポイントごと）を確認することで、これらのそれぞれのコストを絶対的な完了時間で見積もることができます。十分なデータがある場合は、実際の開発者数を追跡する要件を特定することもできます。

次に、それを使用して、履歴データに基づいて顧客に伝えます。プロジェクトの失敗は指数分布に従う傾向があると主張します。そして、あなたはあなたの顧客のために次の議論で武装しています：

過去および現在のプロジェクトと利用可能なリソースからのデータに基づいて、あなたが求めている要件がかかります

1. X失敗の25％の確率（または成功の75％）で完了する時間

2. 1.5 * X 5％の失敗（または95％の成功）で完了するまでの時間

3. 0.5 * X失敗の95％（または成功の5％）で完了する時間

時間リソースの量の関数としての失敗の確率は、通常95％、25％、5％になります（指数分布に似ています）。 ）。その1.5は、最小限のリスクでほぼ確実に成功する可能性がありますが、それよりもはるかに小さい（元の0.5はほぼ確実に失敗することを保証します）。

あなたは彼らにそれを消化させます。彼らがまだ危険な命題（昨日行われた！）に行くなら、少なくともあなたは彼らにそう言ったことを書面で持っている。あなたのグループがアジャイルであるだけでなく工学的なものであるという希望がある場合、顧客はあなたの番号を真剣に検討し、それに応じてこのリクエストと将来のリクエストをスケジュールするかもしれません。

変更を要求することは無料の食事ではないことを、検証可能な明確な用語でエンジニアに説明するのは、エンジニアとしてのあなたの仕事です。

説明したことから、問題はありません。彼らは変更を求め、あなたがそれができると言うまで待つことをいとわないか、別の機能を延期することをいとわない。時間、リソース、要件のバランスのようです。

新しい追加/変更の最小年齢を設定してみてください（バグ修正には適用されません）。たとえば、3週間経過するまで新しい変更を加えることはできません。

タスクの最低年齢を設定すると、最初はすべてのタスクが非常に重要であるように見えますが、しばらく待つと、重要度が大幅に低下することが多いので便利です。時間間隔に応じて、少なくとも作業中のタスクの安定時間を確保できます。

年齢を追跡するには、タスクを何らかのリストに追加することを許可しますが、その期間が終了するまで、タスクは作業するタスクと見なされません。

これは非常に一般的な問題です。プロジェクトが技術用語でどれほど速く進んでも、クライアントはそれがはるかに遅くなると認識し、開発者がとにかく多くのことをしてはいけないと考えているので、要件を自由に変更できます。

この欠陥のある認識は、時間を消費し、クライアントによって適切に説明されることのない3つの主要な開発タスクから生じます。

1. コードレビュー/クリーンアップ：古いコードは肥大化して混乱し、定期的なレビューとクリーンアップが必要になります。これには多くの時間がかかり、クライアントはそれを決して信じません。
2. セキュリティ監査と修正：特にジュニアチームのメンバーがいる場合、コードに関連するセキュリティの問題が多く発生します。また、作成された新しいコードすべてを定期的に調べ、セキュリティから見栄えの悪いものを書き直したいと思うでしょう。観点から、クライアントはこの時間を知ることも説明することもありません。
3. アーキテクチャ関連の変更：成長するコードベースは、複数のポイントで構造的な再考とリファクタリングを必要とする可能性があります（そしておそらくそうするでしょう）：-パフォーマンス関連の変更/最適化（アルゴリズムの変更、ライブラリの置換、キャッシュエンジンなど）または：B-生産性に関連する変更/最適化（読みやすさ、コードの再利用性、理解の容易さ、新しいコーディング規則、新しいフレームワークなど）。

上記のいずれも、エンドクライアントによって理解され、適切に説明されることはありません。

基本的に、「ビュー」（GUI要素）のないものはすべて実行されていません。

これをprojenixの定理と呼びましょう。