これはすべての初心者の質問の初心者になるでしょうが、スコープクリープとは正確には何ですか、それは何を伴いますか?
13 に答える
スコープクリープは、「プロジェクトのスコープの制御されていない変更を指します。この現象は、プロジェクトのスコープが適切に定義、文書化、または制御されていない場合に発生する可能性があります。一般に、回避すべきネガティブな発生と見なされます。」
ソース。
あなたはマウスから始めて、象で終わります。
言い換えれば、要件は毎日変化し、提供することになっているものは、プロジェクトの開始時に提供されることになっているものとはまったく異なります。
ウィキペディアは、私ができるよりも完全にそれを表現しています。
プロジェクト管理におけるスコープ クリープ (要件クリープ、またはキッチン シンク シンドロームとも呼ばれます) は、プロジェクト開始後の任意の時点での、プロジェクトのスコープの変更、継続的または制御不能な成長を指します。これは、プロジェクトの範囲が適切に定義、文書化、または管理されていない場合に発生する可能性があります。それは一般的に有害であると考えられています。これは、機能のクリープに関連していますが、これとは異なります。
スコープ クリープは、次の結果として発生する可能性があります。
- 変更管理が不十分
- プロジェクトの目的を達成するために必要なものを最初に適切に特定することの欠如
- 弱いプロジェクトマネージャーまたはエグゼクティブスポンサー
- 当事者間のコミュニケーションが悪い
- 初期の製品の多様性の欠如
スコープ クリープには 2 つの定義があります。
ネガティブ。範囲が制御されない方法で変更され、コストとリスクが追加されました。
ポジティブ。私たちの幻想的なプロジェクト計画が間違っていたため、範囲が制御不能な方法で変更され、学習するとは予想していなかったものを学習し始めました。
ほとんどの人は最初のものが好きなようです。
ただし、2 番目の方がより正確です。スコープクリープ -== 学習を認識している少数のマネージャーは、それを賢く管理し、物事を成し遂げることができます。
残りのマネージャーは、制御されていない学習を脅威と見なしています。このプロジェクトは、空想のスケジュールや予算では、期待される成果物を作成しません。これは、範囲を縮小するか、予算を拡大する必要があることを意味します。
ほとんどのアジャイル メソッドは、スコープまたはスコープ クリープをあまり気にしないように見えることに注意してください。次のリリースに焦点を絞り込むことで、全体像の脅威や恐怖が軽減されます。
アジャイルのコンテキストでは、学習もスコープ クリープにつながりますが、これは良いことです。役に立たないものは延期されます。私たちが始めたときは重要ではなかったことが加速されます。
それは、プロジェクトが当初の計画よりも絶えず大きく複雑になり、そのため、スケジュールよりも常に遅れ、予算を超過している場合です。
プロジェクトを開始するときに、特定のパラメーターを設定します。これらのパラメーターはスコープです。あなたのプロジェクトが何をすることになっているのか、どれくらいの費用がかかるのか、完了するまでにどれくらいの時間がかかるのかを考える必要があります. より多くの機能、時間、お金....がプロジェクトに忍び寄ると、これは「スコープクリープ」と呼ばれます。
スコープ クリープとは、当初合意された仕様/プロジェクト スコープ/定義に対する変更です。この変更は、以前の未知の発見、内部/外部市場の変化、技術の変化、または計画のスポンサーが何かを望んでいることが原因である可能性があります. 変更をレビューして承認または拒否するための変更管理プロセスが整っていない場合、プロジェクトに悪影響を及ぼします。
スコープ クリープとは、要件が変更され続けたり、現在の製品リリースに追加されたりすることです。たとえば、顧客/ユーザーにデモを見せて、新しいレポート/ボタン/フィールドを要求したとします。また、開発者が新しい「クールな」機能などを必要とせずに追加したい場合にも発生する可能性があります。プロジェクトのリリース サイクルを管理することで、これを防止するのが最善です。人々が機能を提案するのは良いことですが、関係者全員がプロジェクトと予算への影響を理解する必要があります。新機能のリクエストをリストに追加し、定期的に会議を行って、「次のリリース」に追加する新機能を決定することを検討してください。
私の見解では、機能クリープの場合、製品の没落に寄与する要素が必要です。たとえば、都市の成長は良いことですが、都市の無秩序な広がりは悪いことです。
または、UI デザインの場合は、関連するすべての機能が 1 つのコントロール画面で動かなくなってしまいます。新しい機能が継続的に追加され、機能が有用であると感じる以上に多くの人が混乱してしまいます。
機能クリープと見なされるには、システムのライフサイクルにおいて不必要な複雑さに貢献したり、不必要なレンチを投げたりするテストに合格する必要があります。この基準を満たさない、当初は計画されていなかった機能は、機能クリープと見なされるべきではありません。
スコープクリープは、製品スコープのレベルでのみ機能クリープと同じ観点から考慮されます...例:
あなたのチームは、ある場所から空気を吸い込み、2 ブロック離れた工場に運ぶ「エアサッカー」(tm) を構築しています。エアサッカーのスコープは、空気を動かすことです。
その後、管理者は、吸引装置も水と砂を吸引して輸送する必要があることに気付きます。エア サッカーは、液体または粒状の材料を輸送するようには設計されていないため、エア サッカーの範囲が拡大し、新しい輸送要件を満たすために大幅に再設計する必要があります。
また、スコープ クリープは製品スケジュールにどのように影響しますか? 開発プロセスからスコープ クリープを防ぐ方法はありますか? PM はスコープ クリープをどのように処理しますか? スコープクリープから生まれた最高の機能は何ですか? などなど
スコープ クリープはポルノグラフィーのようなものです。
機能、予算、スケジュール: 3 つすべてではなく、任意の 2 つを選択してください
適切な変更管理がある場合は、おそらく現金牛です。
小さなランナバウトがけん引している大きな動力船の有名な写真があります。ランナバウトは「元の契約」と呼ばれ、動力船は「変更要求」と呼ばれます。