リリースから機能を除外するための土壇場の要求がある場合はどうしますか？

社内でも顧客でも既に受け入れテストに合格した機能があります。これは完全に機能する機能です。ただし、現在、この機能を次のリリースから除外するように要求されています。顧客によると、ユーザーはこの機能の使い方についてトレーニングを受けていないため、この機能は削除する必要があります。

この状況に対処するための最善の行動方針は何ですか？構成設定を使用して、機能がギリギリに除外される可能性があることを予測してソフトウェアを設計する必要がありますか？状況によっては他の状況よりも正しいコンテキスト依存のソリューションはありますか？

1. 機能のドキュメントを削除します。
2. 機能のインターフェイスを無効にします（メニュー項目を非表示にするか、コンソールコマンドからオプションを削除します）。

他のすべてはあまりにも危険です。

私の以前の雇用主は、関連する特定のライセンスに基づいてさまざまな機能を可能にするいくつかのソフトウェアを販売しています。そのため、実行時に機能を有効/無効にする機能は、設計された機能でした。一般に、人々はこれを「機能主導型開発」と呼びます（ウィキペディアの記事、テーマに関するまともな本）。機能をオンまたはオフにすることによって引き起こされる可能性のあるバグを見つけるには、多くのテストが必要です。オフィスのほとんどの人がすべての機能のライセンスキーを生成するため、制限された機能の機能は十分に発揮されない傾向があります（お客様がヘルプデスクに電話をかけるまで、まったくテストされないこともあります）。

土壇場の「修正」の場合、最も迅速な解決策は、この機能をオンにするメニュー/ホットキー/ボタンコマンドを非表示にすることです。これにより、他のバグが発生します。顧客とプロジェクトマネージャーの前に立ちます。

私は、機能がオンまたはオフに切り替えられるようなコードを書くことは決してしません-その要件が前もって作られていない限り。

機能の削除または無効化は仕様の変更であり、他の仕様の変更と同様に、実装と検証に時間がかかります。機能が除外される理由を尋ねる必要があります-それでもリリースするにはバグが多すぎますか？クライアントはその機能をまったく望んでいませんか？機能を遅らせるビジネス上の理由はありますか？

特に、機能がリリースされるのに「バグが多すぎる」と思われる場合は、その機能が「バギー」であるのか、それとも実際にはまだリリースの準備が整っていないリリース全体であるのかについて注意する必要があります。その特定の機能は、問題が最も多く現れるものにすぎません。その場合、その機能を無効にしても、あまり役に立ちません...

変更がお客様にとってどれほど重要であるかを話し合うことにより、直前の要求に応えます。ロールアウトの直前に大きな変更を加えると、テストと承認フェーズ全体が無効になるため、変更リクエストを新しいリリースに移動するか、ロールアウト日を移動して、直前の変更を正しくテストできるようにします（お客様多くの場合、ロールアウトの日付を変更することを代替策とすることを知ったとき、変更を次のリリースに移動することを選択しました:-)）

オプション機能は、構成を介してオン/オフに切り替えるのが最適です。あなたが言うように、これは最初から設計する必要があります。

私は過去にこれを行わなければなりませんでした。時々、それを本番環境に入れて、災害であることが判明した機能がありました。私は以下のすべてを行いました。

1）機能を無効にするための構成変更。構成可能な場所で機能します2）機能をトリガーするすべてのUIエンティティを無効化/削除します。3）機能のコードを無効にして、何もしないようにします（ただし、機能しているように見えます）GUIシェルコードにアクセスできなかった場所でこれを行わなければなりませんでした。

機能をオンまたはオフに切り替える機能を設計する必要があるかどうかについては、大きな図を見て、現在機能を追加する方法を見ていきます。最悪の場合動的に発見される機能をモジュールにすることは大きなステップではありません。私はモジュラーが好きなので、この方法をとる傾向があります。

場合によっては、短期的な回避策として機能にアクセスできなくすることができます。アーティファクトが表示されても問題ないかどうかを確認します（表示されているが無効になっているボタンやメニューオプションなど）。

ユーザー/管理者が機能のオン/オフを切り替えることができる必要がある場合にのみ、機能を簡単に切り替えられるようにする必要があります。

予想どおりに実行しても構わないほど簡単な場合は、必要なことがわかっている場合はおそらく同じくらい簡単に実行でき、元に戻すのは少し簡単です。

新しいバグを導入する大きなリスクなしに機能を無効にできない場合は、そのことを人々に伝えてください。それ以外の場合、本当の問題がこのぎりぎりの要件の変更をもたらしたものであっても、避けられない問題が発生した場合、基本的にはスケープゴートになることを志願しています。

あなたの編集に基づいて、これはかなり不可欠な機能だったと思います。削除すると、システムの他の部分に影響を与える可能性があります。実際、お客様はコストをかけずにシステムの根本的な変更を要求できると期待すべきではありません。この場合のコストは、何らかの方法でこれを無効にし（多分コードの膨大な部分をコメント化することにより）、その後、何も壊れていないことを確認するために再テストすることです。

このような機能を「無効にする」最も簡単な方法は、最上位のエントリポイントを削除/コメントアウトすることです。たとえば、機能への唯一のエントリポイントがUIのボタンである場合は、ボタンを作成する行をコメント化します。複数のエントリポイントがある場合は、それを無効にするためにさらに掘り下げる必要がある場合があります。

危険なバグがあるか、壊れているか、不要であるかは、全体に依存します。

安全ではないことができず、使いやすさ、トレーニングドキュメントの不足、または壊れているために除外しているだけの場合は、通常、UIからその機能へのエントリポイントを削除し、その他はすべてそのままにします。

危険なバグがある場合は、それを実行し、コアビジネスロジックに明示的な例外を追加して、実行できないようにします。

最悪の場合、機能は不要であり（規制の変更により、たとえば概念が違法になるため）、機能へのすべての参照を完全に削除する必要があります。

リストを下に移動すると、エラーが発生する可能性が高くなります。状況に応じて、最初のオプション、または最初の2つのオプションはすぐにできるもので、3番目のオプションはほとんどありません。

機能スイッチでの設計に関しては、顧客がそのような遅すぎる選択をしたという履歴を顧客が示すまで、私が通常その方向に行かないことを望まない限り。

私の仮定は、経営陣がこの機能を有料のアドオンとして販売しており、最後に顧客がアドオンの代金を支払いたくないと言っていることです（おそらくお金の価値がないことに気づきました）。

そのため、経営陣は失敗した。

私は、機能へのアクセスがセキュリティ設定によって駆動される多くのシステムを使用してきました。これにより、この種の機能は比較的簡単に無効になります。セキュリティグループの機能を有効にしないでください。すべての機能が有効になっていない限り、機能を無効にしてテストが行​​われます。

簡単に無効にできるその他の機能は、コード値に関連付けられています。これらは一般に、製品、顧客、その他の特定のケースを処理します。これらの機能を無効にするには、関連するコード値を無効にします。

他の人が指摘したように、一部の機能には削除可能な特定のUIエントリポイントがあります。（上記のケースは、これの特殊なケースになる可能性があります。）エントリポイントを削除すると、アクセスを有効にせずに機能を出荷できるようになります。これは通常、このケースを処理するための最もリスクの少ない方法です。

機能が機能ブランチで開発されている場合、機能ブランチをマージ解除して再テストできるはずです。これは、コードを無効にする他の方法よりも簡単なはずです。機能削除パッチを作成すると、後で機能を再度有効にするのが簡単になります。これは、機能ブランチとほぼ同じです。