testing - 直前のスコープ変更? もちろん？

Question

ソフトウェア リリースに土壇場で要件や範囲を導入することの危険性について、送信できる記事を持っている人はいますか? 常識でしょ？しかし、常識を無視するのは人間の本性です。

私には、前世でこの「IT/ソフトウェア エンジニアリング」の経験がすべてあると主張しているビジネス関係者がたくさんいますが、UAT 中または場合によっては UAT 後でもスコープを追加できない理由を繰り返し尋ねています。

Answer 1

珍しい問題ではありません。はい、発生します。:)

私は、COST が固定されていることを理解しています。顧客は、要求された追加のスコープに対して追加料金を支払うつもりはありません。あれは正しいですか？

その場合、プロジェクト文書の「承認基準」が明らかになる場所です。UAT はサインオフされていますか? もしそうなら、追加の範囲を追加のプロジェクトとして追加の時間と費用で引き受けるより良いケースがあります。明確に定義された「承認基準」がない場合は、なぜこれが余分な労力になるのかを納得させる必要があります。

上記は純粋にビジネスとコストの観点からのものです。エンジニアリングの観点からは、追加の計画、テスト、「回帰テスト」、文書化、および配信サイクルが含まれるため、追加のオーバーヘッドがかかることは間違いありません。追加するスコープに応じて、コードのリファクタリングも行われる可能性があります。「あなたの主張を支持すると、ソフトウェア プロジェクトの追加の範囲は、複数階建ての建物にもう 1 フロアを追加するだけではなく、追加される新しいフロアに集中できます。」おそらく、上級管理職またはビジネス ユーザー (必要な人は誰でも) にこれを説明して、この種のスコープの変更が少なくとも次回から最小限に抑えられるようにします。(現実世界でのみ最小化でき、理想世界のように無効にすることはできないことに注意してください)

あなたの質問から少し外れますが、一日の終わりに - プロジェクトは、品質、時間、コストなど、さまざまな視点から見なければならず、それらすべてを一緒に満足させることはできません。したがって、あなたがプロジェクト マネージャーである場合は、意見を述べる必要があります。場合によっては、追加の時間または追加のリソースを要求する可能性があります。プロジェクトの最後に打撃を受けるよりも、範囲と時間をより明確にするために、責任を取り、今立ち上がる方がよいでしょう。

次回からより適切に処理する必要がある場合は、これらの契約モデルのいずれかが役立つかどうかを確認してください - http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects。

とはいえ、プロジェクトマネージャーとして、「顧客満足と顧客維持」を何よりも優先し、限られた範囲の追加（追加費用なし）を受け入れなければならなかったケースもいくつかあったことは認めます。顧客が私たちと長期的な関係を築くと、スコーピングの問題や、追加の労力がどのようにかかるかなどについて、顧客を説得するのがより簡単になりました。私たちが解決しているのはエンジニアリングの問題だけではありません。