抜け道を見つける人はほとんどいませんが、見つけても見ない人もいれば、探すことすらしない人も少なくありません。
不思議の国のアリスから
この記事は次の質問を提起します。
- 「スクラム+固定価格」アウトソーシング公式のコンポーネントの不整合について。
- スクラムツールの誤った選択の前に発生する可能性のある1つのエラー（根本原因）。
- スクラムと固定価格を組み合わせる問題が本当にある1つの状況について、それを解決するには綿密な分析とトレードオフが必要です。
この記事は、明確な視点を持たない非常に議論の余地のあるポイントに触れており、無限の議論の主題となっています。したがって、読んでいる間、あなたの意見が提示されたものと一致しない可能性があることを覚えておいてください。
記事「アウトソーシングで疑似スクラムを開始する方法」で述べたように、多数のアウトソーシングプロジェクトでは、それらのチームがスクラムと固定価格を組み合わせた（または希望的思考）場合、プロジェクトのライフサイクル（LC）が正しく識別されません。それら。反復的な増分または柔軟なライフサイクルのどちらかを選択する際に誤りがありました。そしてその結果、誤った管理ツールとしてスクラムフレームワークが選択されました。そして、すでにこの選択の結果、多くの問題が発生し、アジャイル、スクラム、および「拷問」という言葉からの試みに関する誤った結論が出ています。これら2つの相互に排他的な概念を組み合わせるためです。
相互に排他的ですか？
今私は主張します。
読者は、上記の記事の資料に精通していることを前提としています。
Scrum + Fixed Price – , ?
, , .アウトソーシングサービスの提供に関する契約を締結する場合、クライアントはほとんどの場合、固定価格（ターンキー方式）を要求します。彼の望みは、製品の範囲（または作業量）を修正し、予算と期限を確認することです。彼は自分が「購入」しているものを見たいと思っています。 Time＆Materialにお客様が同意することはほとんどありません。
“ ”
したがって、重要なポイント：クライアントの必要性は契約で修正する必要があり、サービスプロバイダーは契約に基づく義務を履行し、開発の開始後、パラメーターが予測可能なエラー（ある程度の不確実性とリスクがあるため）で変化しないままであることを保証することです。不確実性とリスクの度合いを減らすという問題は、製品スコープに関連するディスカバリー（プレセール、診断）フェーズの実現可能性と品質の問題です。
何かを修正した場合（契約に基づいてクライアントに保証します）、義務を確実に果たすように計画および管理する必要があることは明らかです。それら。計画（またはプロジェクトの三角形の固定特性）を管理します。
固定価格は、単にプラン管理を優先するように義務付けています。そうでなければ、なぜそれが変更されることを事前に知っており、実際にそれを管理する予定がないのに、何かを修正する必要があるのでしょうか。契約を結ぶだけですか？確立された販売プロセスにおける重大なエラー：契約に署名するためにのみ変更することを事前に知って修正します！
なぜ変更するのですか？スクラムは常に不確実性とその結果についてのものだからです-変化。これは変更管理の優先順位についてです。また、最初のスプリントの後に表示される可能性もあります。どうして？
変更の考えられる理由についての余談変更の理由は
何でしょうか？たとえば、製品スコープをある程度定義できる状況（例として、記事のケーススタディの段落3を参照）で、不十分に実施されたディスカバリー（プレセール、診断）フェーズにある可能性がありますが、何らかの理由でこれは行われていません。この場合、これはフェーズと内部プロセスの問題であり、固定価格契約のスクラムを選択した理由ではありません。行われたミスを補うために、反復的なライフサイクルではなく柔軟なライフサイクルです。
公平に言えば、アウトソーシング（製品範囲の観点から最も問題の多いフェーズの1つ）の販売（ビジネスアナリストのプレセールス活動）では、特定のプロパティを持つ完成品を購入する場合、店舗ほど単純ではないことに注意してください（機能）。また、ディスカバリーフェーズは、ビジネスアナリストやチームによる販売が難しい活動です。しかし、不確実性をある程度最小限に抑え、リスクを評価することは、しっかりと構築された販売プロセスの主要なタスクの1つです。これらの活動の必要性と重要性についてのクライアントでの理解の形成と同様に（それは非常に難しい場合があります！）しかし、これには十分な数のテクニックとツールがあります。そしてそれは提供されるサービスの質の問題に帰着し、「豚の豚」の販売ではありません。
もう1つの理由は、現時点で製品のスコープとビジョンを決定できないことです（例については、記事のケーススタディの2ページを参照してください）。そしてこれは、深刻な矛盾が生じ、アウトソーシングサービスの提供においてスクラムと固定価格を組み合わせるという疑問が提起される場合、実際には両当事者にとって非常に困難で不利な状況です。慎重な分析、起こり得る困難とリスクについてクライアントを包括的に理解するための追加のアクション（技術的およびイデオロギー的に開発プロセスの現実から遠いことが多い）、および妥協ソリューションの検索が必要です。
では、なぜスクラムが選ばれるのでしょうか？たとえば、誤って実施されたディスカバリーフェーズ（プレセール、診断）の結果として発生した変更、またはこのフェーズで製品のスコープを決定できない場合に発生する変更を管理するには？前者の場合、私の意見では、これは間違っています。 2番目のケースでは、固定価格での実装は困難です。
スクラムをアジャイルツールとして選択するための3番目の選択肢は、製品スコープが検出フェーズ（販売前、診断）で解決および修正され、契約-固定価格である状況で、反復増分ツールではなく柔軟なライフサイクルでも、私の意見では合理的ではありません：なぜ選択するか変更を管理するためのツール（焦点が合っていないことは明らかにより優先度の高い計画です）、その可能性を最小限に抑えるのはいつですか？
記事の主なアイデアに戻ります。
しかし、スクラムが選択されているとしましょう。繰り返しになりますが、スクラムは変更管理ツールであり、不確実性の程度はプロセス内でのみ、適切なアプローチを使用する場合にのみ削減できます。そして、この減少はこのプロセスの結果です。
しかし、固定価格契約は計画の管理を優先します！
したがって、「式」「スクラム+固定価格」は「変更管理+計画管理を同時に」に変換されます。マネージャーのタスクは、さまざまな程度で、計画と変更の両方を管理することですが、優先度は1つだけです。計画または変更のいずれかです。
計画管理または変更管理は、管理とビジネス分析の基礎に組み込まれた一種の公理です。これは、マネージャー（PMBOK）とビジネスアナリスト（BABOK）の基本的な（そしてそれだけではない）マニュアルに反映されています。また、ライフサイクルの分類（および特定のプロジェクトに関連するそれらの識別）はそれに依存しています。計画を管理するように設計されたライフサイクル（たとえば、ウォーターフォール、反復増分（IID））と変更管理のための柔軟なアジャイルがあります。ライフサイクル（およびその後のツール）の選択は、管理で何が優先されるかに基づいています。
フレキシブルライフサイクルは、特定の主要な機能/特性を備えたプロジェクトの一種の反復的なインクリメンタルライフサイクルです（チェックの質問のリストは上記の記事に記載されています））、それを個別のライフサイクルとして識別し、変更管理に「すべての努力を向ける」ことができます。これらの機能が原因である可能性があります：製品の範囲（最も重要な！）のある程度の確実性を達成するための「今ここで」の不可能性、「撃つ」ビジネスソリューションの検索（またはフィードバックを生成するためのビジネスへの迅速な提供）、主要な機能のリストの形成製品（主な機能）、短い反復、可変性、実験、機能の段階的な構築、回顧、製品だけでなく、製品の最適なバージョンを取得するためのプロセスの改善。そのような状況で、予算と条件の適切な見積もりを取得することは可能ですか？
悪魔は1つの詳細にすぎない、または...それはすべて製品範囲に関するものです
すべてに独自の道徳があります。あなたはそれを見つけることができる必要があります！
不思議の国のアリスから
アウトソーシングプロジェクトの開始時の販売段階、ディスカバリーフェーズでの製品のスコープとビジョンに関連する確実性（それを確立する能力）についてどのように言えますか？
製品の一意性の理由により、製品のスコープを定義、評価、修正できない場合、スタートアップのアイデア、行われたビジネス上の決定の有効性に関する不確実性（それらを見つける必要性）、および製品の主要な機能を決定することの難しさ、検証を必要とする仮説の存在など。 ... （ここでもケーススタディのポイント2を参照してください）、もちろん、スクラムフレームワークが最も適切なツールです。
ただし、アウトソーシングの場合、契約を締結する際に固定価格スキームを使用したいというクライアントの要望により、この状況は非常に複雑になり、両当事者にとって好ましくない状況に陥ります。ある程度、いくつかの前提があれば、そのようなプロジェクトの契約と管理において妥協点に達する可能性があります。クライアント（投資家）の正しい理解と正しい期待を形成し、リスクを評価し、可能であれば、他の財務的相互作用のスキームを検討し、プロジェクトの実施の過程で、クライアントの忠誠心と常に連携することが重要です。質問は記事の範囲を超えているため、ここでは詳しく説明しません。
アウトソーシングでは、ほとんどの場合、問題は主に、製品スコープと適切なライフサイクルの選択に関連する発見（プレセール、診断）フェーズの有能な行為にあります。そして、アジャイルとスクラムが製品スコープを修正できる状況で選択されている場合（さらに、将来の開発の期待/想定とともに、何らかの理由で時間どおりに実行されなかった場合はさらにそうです）、同時に契約で-固定価格私の意見では、プロジェクトの前向きな結果に疑問を投げかける間違いがなされています。
ご清聴ありがとうございました！