要件のステータスとリクエストの変更

各リリースのベースラインを設定した後、開発プロセス中に行われた変更を必ず追跡してください。 XNUMX つの変更要求が、さまざまな種類 (ユーザー指向、機能的、非機能的) の多数の要件に影響を与える可能性があることを忘れないでください。 特定の期間に行われた変更の数を評価するには、変更の数をこの期間より前の要件の合計数で割ります (ベースラインを定義するときなど)。

要件の変動性を完全に取り除きたいわけではありません。 結局、多くの場合、それらを変更する正当な理由があります。 しかし同時に、プロジェクトが変更を処理し、その義務を果たすことができることを確認する必要があります。 変更が頻繁に行われると、完成に近づくと追加のコストが発生します。 これにより、製品をいつ世界にリリースするかを決定するのが難しくなります。 開発が進むにつれて、ほとんどのプロジェクトは変更に対する回復力が向上するはずです。 言い換えれば、リリースが終了したときにゼロになるまで、変化の受け入れ率が徐々に減少する必要があります。 反復的なアプローチにより、チームは各サイクルのタイムラインを追跡しながら、後の反復で改善を組み込む複数の機会を得ることができます。

チームに変更要求が殺到している場合、抽出プロセスが包括的ではなかったか、プロジェクトが進行するにつれてアイデアが生まれ続けている可能性があります。 そのため、これらの変更がマーケティング、ユーザー、営業担当者、管理チームなどのどこから来たのかを追跡することが不可欠です。この情報を把握しておくと、見落とされた要件を最小限に抑え、将来の誤解を防ぐために、誰が、何を注意する必要があるかを判断するのに役立ちます。

変更要求が長期間にわたって未解決のままである場合は、変更管理プロセスに注意が必要であることを明確に示しています。 私は個人的に、数年前から保留中の拡張要求を持っている XNUMX つの組織を目撃しました。 プロジェクト マネージャーがバックログの最も重要な項目にエネルギーを優先するようにするには、このチームは、特定のオープン リクエストを計画されたメンテナンス リリースに割り当て、その他の長期延期された変更を拒否されたものとして変換する必要があります。 このようにして、緊急性の低い問題に取り組む前に、最初に不可欠で緊急のものに簡単に取り組むことができます。