固定長/固定価格プロジェクトでスクラムを使用していますか？ [閉まっている]

Question

私はスクラム初心者で、会社にスクラムを実装したいと考えています。バイインを取得することは問題ではありません。それは私の会社であり、開発者はこのように仕事をすることを喜んでいます。

問題は、収益の75％が固定長/固定価格プロジェクトから得られていることです。

Ken Schwaberの著書「Scrumによるアジャイルプロジェクト管理」では、巻末の付録で固定長/固定価格プロジェクトの入札に関するトピックを取り上げています。

多くの魂を検索した後、ケンは、潜在的なクライアントに違った考え方をさせることができる場合、スクラムはこの状況でのみ有用であると導きました。クライアントは、使用できる可能性のあるものをもっと早く入手し、すべての機能を実装する必要がない可能性があるため、お金を節約できます。 / p>

これが固定長/固定価格プロジェクトでスクラムを実装する唯一の方法であるとは確信していません。

固定長/固定価格プロジェクトで他の人がどのように成功して入札し利益を得たかを知りたい。

Answer 1

はい。できると思う。 ウォーターフォールが機能しないを参照してください。

「固定価格ボックスの外に出る」会話はそれほど難しくありません。顧客はまた失敗を見ました。彼らは、要件文書を取得するまでに長い遅れが見られました。彼らは無限の変更命令を見てきました。彼らもそれを好まない。

しかし、顧客が別の方法で管理したくないと確信している場合は、ハイブリッドなアプローチを採用する必要があります。

価格を設定することはアジャイルではありません-それはできません。非妥協的な顧客を満足させるために、価格を補う必要があります。明らかに、価格を正当化するための何らかの種類のマスタープランがあります。ほとんどの場合、このマスタープランに必要なのはバックログだけです。その他の詳細は、仮想的な計画の前提にすぎません。 [彼らは常に計画の前提ですが、一部のPMは、最初の計画は従わなければならない神聖な神託だと考えています。そうではありません。]

次に、小さなアジャイルな増分ステップで実行します。ユーザーを早期かつ頻繁に関与させる必要があり、会話を行わなければなりません。しかし！バックログの各変更は、範囲、コスト、またはスケジュールの潜在的な変更として調査する必要があります。

すべてのスプリントの終わりに、バックログの変更は、プロジェクトの範囲と契約の変更になる可能性があります。

アジャイルを使用すると、スコープの変更をより早く、より生産的に顧客と積極的に連携させるため、リスクが軽減されます。スコープを定義（およびフリーズ）しようとするのは付加価値の高いアクティビティではないため、やめるだけです。スコープを推測どおりに扱い、各スプリントでスコープの変更を処理します。

Answer 2

入札と利益についてはわかりませんが、スクラム方法論は確かに固定長/価格プロジェクトに適用できます。要件が既知でしっかりしている場合は、それらを製品バックログに入れることができ、要件と時間制限に従ってスプリントを計画できます。毎日のスクラム会議、バーンダウンチャートなどの利点を活用して、プロジェクトが順調に進むようにすることができます。