特定のソリューションとツールの説明に移る前に、新しい要件に関するポリシーについて少し説明します。 おそらく私たちが理解した最も重要なことは、要件が常に変化することであり、「要素と戦う」代わりに、変化する要件を管理する方法を学ぶ必要があるということです。 もちろん、TKと予算がありますが、多くの場合、新しい要件を含めるための交渉は、変更自体よりも費用がかかります。 一方、顧客が望むことは何もできません。プロジェクトはまったく開始されません。 したがって、要件を管理する必要があります。
当社はマネージャーとプログラマーで構成されているため、私たちのお気に入りの娯楽は、開発プロセスを整理し、この開発のための自動化ツールを開発することです。
しかし、ここ数年、時間とお金はありますが、これをほとんど行っていません。 それは簡単です-長い検索の後、私たちにとって安定して動作するソリューションを見つけました。 この投稿の一部として、私はすべてについて話すことはしません-それはあまりにも判明しますが、私たちの仕事の主なテクニックの1つについて話します。 これを「基本チケット」と呼びます。
どの自動化ツールが使用されているかは関係ありません：トラッカー、エクセル、ステッカー。 組織の主要な原則とプロセス。 そのため、このアプローチの本質は非常に単純です。開発を開始する前に、プロジェクトタスクの完全なリスト、プロジェクトの一種のTo Doリスト（科学的にはWBSと呼ばれる）がコンパイルされます。 Excelで行うのが最も便利です。 オートフィルターと階層があります。 WBSには、プロジェクトを完了するために実行する必要があるすべてのタスクが含まれていることが重要です（以前に未処理のタスクが表示される場合は、ジョブのリストに追加する必要があります。「新しい」フラグを使用できます）。 4〜16時間の開発からタスクスケールを選択します。 数百のタスクがあれば大丈夫です-それらはサブプロジェクトと反復に結合できます。
そして今、主要なトリック-WBSからの各タスクに対して、このタスクの完全なステートメント（または1タスク= 1テープの原理で議論できるシステム）で、トラッカーにチケットが作成されます。 これはケースベースのアプローチ（ユースケース、ユーザーストーリー）であると言えます。 チケットにはインジケータがあります-タスクが現在どちら側にあるか（これもExcelでマークできます）。 タスクの開発（チケット）は顧客に引き渡されるため、開発の最初の段階で顧客からフィードバックを受け取ります。
リーダーにとって、このアプローチにより、開発のペースと品質を最初から評価できます（たとえば、悪い結果が顧客に送信された場合、彼はすぐにそれを表明し、状況を修正して新しい応答を得る機会があります）。
しかし、「基本チケット」の主なことは、もちろん、変化する要件を追跡することです。 一般に、要件の変更はITプロジェクトの最も深刻な問題の1つであり、そのため、たとえば建設のように、「ウォーターフォール」の原則が機能しません（TKを書きました）。 要件は変わらないと言う人は、おそらく実際のプロジェクトを実施しなかっただけでしょう。 ITプロジェクトを管理することは、要件を管理することを意味すると言うことさえできます。 さらに、大企業の従業員、社内顧客、さらには小規模オフィスなど、すべてが要件を変更します。 基本的なチケットを持っていると、初期設定が簡単にわかります。
したがって、個別のドキュメント管理や現在の要件のあるウィキなしで、プロジェクトの状態とその要件に関する関連知識を得ることができます。 通常、要件変更の別の履歴は関係がないか、それを維持するために不適切な管理作業が必要です。 プロジェクトの状態も完全に現実的です。これは、タスクが顧客に受け入れられるためです（つまり、「ほとんどすべての準備が整っています」という抽象ではなく、顧客に受け入れられるタスクの数、修正のために送信されるタスク、まだ転送されていないタスクなど）
私たちはプロセスを整理し、独自の何かを追加して、さまざまな手法（RUPからXPまで）を基礎として取り入れました。 当然、私たちのアプローチは絶対的な真実（目新しさまたは独創性）であると主張していませんが、私たちのために働くので、他の誰かにとっても有用です。 何かが理解できないままであるか、カウンターオファーがある場合、私は議論することを嬉しく思います。
UPD：
公正な発言で補完する。
この投稿では、技術的なアプローチについて詳しく説明しましたが、要件が変更されたときにどうするかという質問には答えませんでした。
1）最初に、要件を変更するための小さなマージン（予算内で）を設定する必要があります。 エンドツーエンドの作業で採用されたプロジェクトは、マイナスになる可能性があります。
2）変更を行う前に、この変更が本当に必要であり、プロジェクトを改善することを確認する必要があります（これはお客様と話し合うことができ、また話し合う必要があります）
3）TKに応じて、デバッグと機能的承認の配信後にのみ変更を行う必要があります。
4）当然、プロセスは反復的である必要があります。反復が完了するまで、変更を加えることはできません。 変更パッケージは別の反復で発行されます
5）プロセスが制御され、顧客が本当に重要な変更のみを行うように、顧客が費やすことのできる時間のプール（100など）を無料で提供します。 当然のことながら、特定の変更の導入について顧客と話し合って、彼はそれがどれくらい時間がかかるか、そして何時間残したかを説明する必要があります。
複雑なプロジェクトでは、最初に安定したバージョンを取得してから、変更を加えることが非常に重要です。
戦略について話す場合、要件を開く前は1つであり、実際の作業の1か月後は完全に異なるため、できるだけ早くバージョンをリリースするよう努力する必要があります（サイトを開いて作業する）。