UATの期間中に、システムに含める必要があるメジャーなことを顧客が認識した場合はどうしますか？
uat中に、ユーザーは、システムに含める必要のある主要な欠落機能に気付きます。これは、アプリケーションの実装とは関係ありませんが、設計と初期の初期要件と関係があります。
現在の状態を製品版にプッシュすると、アプリには主要な機能がないため、使用できないように見えます（お客様が以前に要件に含めていなかったものです）。
開発を続けることもできますが、これによりアプリの達成のタイムラインが延長されます。開発者が予定より遅れているように見えます。
これをどのように進めますか？
まず、これは珍しいことではないと私は言わなければなりません。要件の収集は難しく、顧客はプログラマーが幅広い要件から「ギャップを埋める」ことを期待することがよくあります。
アジャイルの観点からは、まったく問題ありません。バックログにさらに要件を追加し、通常どおり続行します。
ただし、固定価格または期限を顧客と合意した場合は、明らかにビジネスに問題があります。顧客か企業のどちらかが負けてしまいます。
これがアジャイルが発明された理由であり、ソフトウェアプロジェクトの要件が変更されましたA LOT。ビジネスのソリューションは、固定価格から時間とリソースの請求に切り替えることです。または、契約が仕様どおりの作業のためだけのものであることを確認し、悪い仕様について顧客があなたを責めないことを望んでください
それはむしろ、要件が省略されたのは誰の間違いであったかに依存します。
それがあなたの間違いだった場合は、顧客との交渉方法を話さなければなりません。おそらく、ソフトウェアの暫定バージョンを提供し、その後に機能が完全なバージョンを提供します。どういうわけか、あなたはヒットをするつもりです。
それが彼らの過ちだった場合、傭兵のアプローチはこれを機会ではなく問題と見なすことです。お客様が忘れていた機能を追加することを提案します。その追加機能を実装するために必要な作業量と、それに対応するスケジュールの延長に基づいて、その追加機能の適切な価格を計算します。正しく行われると、従業員が顧客資金によるプロジェクトに取り組み続けることができ、そうすることでより多くの利益を上げることができます。そして、製品が遅れて配達されるのは顧客の問題であり、あなたの問題ではありません。
それが起こったとき、あなたはあなたのマネージャーにそれを整理させます。 「ユーザー」が顧客への支払いを意味する場合、関係する企業は、追加の開発の費用を誰が支払うかを彼らの間で把握します。それが内部ユーザーである場合、あなたの管理者はそれをいくつかのレベル上で整理する必要があります。
また、「ユーザー」が派手な新しいソフトウェアを使用したくないだけで、難しいという明らかな可能性もあります。ユーザーが置き換えられたケースがありました（ユーザーAは機能Xなしではソフトウェアを使用できないと判断し、ユーザーBはそれを問題なく使用できるため、ユーザーAは追い出されます）。
だからあなたのマネージャーに決めさせてください。 PS。あなたは約束をせず、誰に対しても過ちを認めません。上司がより多くのお金を交渉したり、ブロックしたり、請求したりするのを難しくするようなことはしないでください。
これまでのところ、プロセスの観点からこれについてコメントしています。アジャイルのようなより反復的な開発プロセスに移行すると、チームでの機能の追加が容易になりますが、UATの驚きによる影響を大幅に減らす、ライフサイクルの計画および開発段階で採用できるアーキテクチャトリックもあります。
これらのタイプの問題が発生した場合、新しい機能が追加されるまでリリースを確実に中止できますが、おそらくそうなると、 長時間実行される機能ブランチ に依存せざるを得なくなり、必然的にマージ地獄に陥ります。
または、既存のSDLCプロセスに次の概念を追加して、これらのタイプのイベントが発生したときにアプリチームの世界の終わりにならないようにしてください。
- 機能フラグ （別名トグル）は、実際に「オンにする」ことなく機能を製品にリリースするための優れた方法です。フラグを立てることは、基本的に、すべての新機能をオン/オフスイッチでラップすることになります。一元化された「配電盤」は、構成ファイル、管理画面、さらにはホストされているWebページなど、さまざまな方法で制御できます。この手法は、運用の準備（ビジネスチームのトレーニングなど）、本番環境を中断せずに多段階のリリースを実装する場合、または（あなたの場合のように）最近発見された問題のためにリリースを遅らせる場合に最適です。
- モジュラー設計 -アーキテクチャの計画に少し時間を費やすと、後でSDLCプロセス中に利益を得ることができます。機能をモジュール化し、アーキテクチャの結合を制限することで、より大きな機能をカプセル化でき（オブジェクト指向クラスと同じように）、個々の機能が姉妹機能に依存することがはるかに少なくなります。 [〜＃〜] soa [〜＃〜] や Microservices のような多くのサービスベースの分野は、これらの概念に大きく依存しています。
- 抽象化による分岐 -場合によっては、深刻な設計上の問題があるレガシーコードや、侵襲的な変更を必要とする高機能システムでさえも作業する必要があります。この記事でMartinFowlerが説明した方法は、かなり基本的な概念ですが、試行錯誤されたものです。別のレイヤーを作成し、アプリケーションの一部をゆっくりと切断して再接続することで、ライブプロジェクトを大幅に損なうことなく、大きな設計変更を実現できます。上記の他の方法と組み合わせて使用すると、これは既存の機能に影響を与える大きな機能の変更を展開するための貴重な方法です。