実際、はい、アジャイルは修正価格で使用できます。 ldmitryは、 「固定コストでのアジャイル-それは本物です」という記事で最近、1つのソリューションを提案しました。
別の、より「古典的な」方法を使用しました。抽象化です。 この場合の顧客は弱いリンクなので、顧客に関連して抽象化を適用します。 これを行うには、プロジェクトに、顧客の要件と技術的な問題の両方を扱う方法を知っている非常にきちんとした有能な専門家を紹介する必要があります。 これを担当するシステムアーキテクトがプロジェクトコンセプトを監督しているため、職業によって、プロジェクトチーム側よりもプロジェクト内の顧客側を頻繁に占有します。 プロジェクトの外部修正価格シェルの一部として顧客と協力し、内部プロセスの製品所有者になるのはこの人です。 顧客は請負業者の内部プロセスから抽象化しますが、プロジェクト結果に対する彼のビジョンは、請負業者のビジョンと常に一致しています。
古典的なケースがあると仮定します：州の顧客のための情報システムの実装のための入札。 本来、これは修正価格です。 エンドユーザーへのアクセスは非常に限られており、予算と期限は固定されています。
顧客との合意により、プロジェクトはいくつかの段階に分けられます。 原則として、最初の段階は技術仕様（要件+技術ソリューション）の開発です。 第2段階は、必要な研究作業に専念できます。 最終リリースまでの、さらに数段階の製品配信。 各ステージは4〜6週間続きます（クラシックスプリント）。 問題は、プロジェクトの最初の段階で主な不確実性を取り除き、最後に顧客の関与をあまり必要としない実装の問題を解決することです。
入札に参加する前に、実現可能性のために将来のプロジェクトの分析を実施することが不可欠です。 また、十分な埋蔵量がない場合は、冒険に参加しないでください。
それで、我々が入札に勝ったとしよう。 顧客は特に私たちに忠実ではありませんが、結果として得たいものを教えてください。 したがって、最初の段階では、主な負担はアナリストと建築家にかかっています。 しかし、ほとんどの場合、プログラマーの仕事は次のとおりです。たとえば、エクスポートまたはインポートされたデータの形式と外部システムとの通信プロトコルが判明するとすぐに、これらのシステムのエミュレーターを作成することは理にかなっています。 UIフォームの基本レイアウトが明確になるとすぐに、サードパーティフレームワークの選択を開始するか、独自のコンポーネントの作成を開始できます。
技術ソリューションの分析と開発に関連するタスクのリストは理解可能であり、原則として顧客にとって興味深いものです。 それは完全に予期しない機会を開く可能性があります。 そして、原則として、チームワークは、将来の製品の統一されたビジョンを迅速に作成し、顧客と請負業者の間の信頼の成長に貢献します。
したがって、作業の最初の段階でアジャイルを使用することに大きな障害はありません。 プロジェクト管理に注意する必要があるのは1つだけです。ステージのタイミングと予算は厳密に制限する必要があり、ステージがこれらの制限を超えた場合に実行する必要がある手順は事前に解決し、制限に違反した場合はすぐに適用する必要があります。 したがって、限られた予算でプロジェクト内にある程度のスペースが作成され、その中に柔軟な方法論を非常に自由に適用できます。 このようなアジャイルの製品所有者は顧客の代表ではなく、プロジェクトマネージャーまたはシステムアーキテクトであり、プロジェクトコンセプト全体の実装を監督します。
最初の段階の結果は、顧客と請負業者の両方が理解できる単一のプロジェクトコンセプトです。 プロジェクトには明確な目標があり、この目標の達成を可能にするトップレベルのタスクを策定しました。 この結果がそうでない場合、作業を続ける価値はほとんどありません。
最初の段階の2番目の結果は、残りの不確実性の90％以上を隠す問題のリストです。 ほとんどの場合、このような問題には技術的な基礎があります。 2分間で、それぞれにダースのパラメーターを持つ200万のエンティティのモデルを再計算することは可能ですか？ 私が試すまで、私は認識しません。 研究をする必要があります。 このような問題を排除することが第2段階の目標です。
第二段階では、顧客も参加に興味を持っています。 しかし、彼は以前のスケジュールに常に関与する余裕はめったにありません。 したがって、私たちは彼にいくつかのプロトタイプの例について、その週の仕事の結果だけを見せます。 2つのプラス点があります。顧客はアルゴリズムが正常に機能していることを確認しますが、同時にプロジェクトが目的の実装をまだ見つけていないことを確認しています。 請負業者に対する顧客の信頼は高まっており、コンセプトの理解は同じままであり、常に洗練されています。 私の経験では、技術的な性質であっても複雑な問題が発生した場合、顧客は解決策を提案できることを示しています。「大きなデータセットをすばやく解析できませんか？ 問題ありません。別のシステムの開発者に、データ形式をわずかに変更するようお願いします！」
アジャイルはうまく機能しますが、顧客自身はそのことを知りません。 ただし、プロジェクト管理は、主要な修正価格プロセスの一部としてアジャイルが存在する「コンテナ」を依然として制御し、プロセスの柔軟性があまりにも多くの予算、時間、リソースを獲得できないようにします。
配送段階は同じように行われます。 顧客には作業の結果が表示されます。 残念ながら、多くの場合、顧客は以前にプロジェクトに注意を向けることができません。 その後、スプリントの最後に4〜6週間に1回だけデモが行われます（顧客にとっては、ステージの結果に応じて最初に合意された配送です）。 それでも、製品の所有者はチームのデモンストレーションを毎週観察し、決定が受け入れられたコンセプトと一致していることを確認します。 不確実性の大部分は初期段階で除去されたため、要件の予期しない重要な変更はほとんど発生しません。 そして、それらが発生した場合でも、顧客に契約の条件を示し、「固定価格！」と言うことができます。契約および合意された技術的解決策にはそのような要件はありません。 そして、いくつかの交渉が始まり、その結果、「何かが追加されたら、何かが削除される」というよく知られた原則が使用されます。 結局のところ、顧客は私たちが柔軟であることを知りません！
プロジェクトが完了すると、誰もが幸せになります。顧客は、プロジェクトの将来の開発のために一部の機能を延期しなければならないという事実に長い間慣れていました（そして、誰がそれらを行うのか推測することさえできます！）
これがアジャイルがフィックス価格の下で生きることができる方法です。
ロシアの統一エネルギーシステムの計画システムを開発する際に、このアプローチを使用しました。 入札の準備として、実現可能性調査を実施し、予備決定を準備しました。 この決定により、入札に勝ちました。 プロジェクトが開始されました。 納品のいくつかの段階でお客様と合意しました。 システムアーキテクトおよびコンセプト作成者として、私は開発者と顧客の間の「レイヤー」の位置を取りました。 私のタスクは、顧客の影響からプロセスを保護することであり、開発者による破壊から共通の合意されたコンセプトです。 内部スクラムでは、プロジェクトオーナーのポジションと、ティムリッド-スクラムマスターのポジションを取りました。 プロジェクトマネージャーと一緒に、各段階に制限を導入し、これらの制限の違反に対応する方法を提供しました。
最初の段階で、「技術的なタスク」、つまり要件の仕様と技術的な解決策の説明を作成しました。 これにより、将来のシステムの共通のビジョンを達成することができ、研究が必要ないくつかの技術的ポイントが示されました。 同時に、開発者はシステムのメインフレームワークを構築し、外部システムとの慣らし運転を開始しました。
第2段階では、すべての研究作業を行いました。 その結果、指定された品質パラメーターを使用してシステムの主要なビジネスプロセスを実行するプロトタイプを示しました。 この段階で、主要な不確実性はすべて取り除かれました。
ステージに割り当てられた時間制限にほぼ違反したのは、第2段階でした。 実行可能コードを動的に生成する作業は困難でした。 ユーザーがデータ修正手順を自分で記述できるようにする必要がありました。これは、オンザフライで当社の決済サーバーが取得するはずです。 サードパーティの決定は、次々に、さまざまな理由で適用できないことが判明しました。 予備テスト後に残った3つのソリューションのうち、完全に満足したものはいませんでした。 この段階に割り当てられた時間と予算が不足していたため、「緊急」の意思決定手順が必要でした。主要な専門家と経営陣が集まり、簡単な議論の後、解決策の1つに指を突っ込みました。 その後、追加のコードを実装して、このソリューションの欠点を補う必要がありました。 しかし、このような問題の解決策は不確実性を取り除き、顧客とのさらなる緊密な作業の必要性から解放し、最も重要なこととして、プロジェクトを許容できるフレームワーク内に維持しました。
次に、さらに2つの中間配信を行いました。 最も困難なのは最終的な配信で、顧客の「戦闘」インフラストラクチャに完全に機能するシステムを実装する必要がありました。 ここでも、顧客の技術専門家がプロジェクトに参加し、私たちと一緒にソリューションを調整し、定量的メトリックの測定結果に基づいて最終的な最適化を実行しました。
したがって、開発プロセスを外部の制約から分離することができました。 現時点では、システムは現在1年間商用運用されています。 そして、私たちは最近、さらなる開発のために入札を獲得しました。
短い要約 ：
- プロジェクトの性質に対応する主要な開発プロセスである古典的な「ウォーターフォール」がありますが、それぞれ4〜6週間の比較的多数の中間段階があります。 ステージごとに、条件、予算、リソースに厳しい制限が設定され、これらの制限に違反した場合のアクションが予測されます。
- メインプロセス内で、アジャイルを使用するネストされたプロセスを作成します。 製品所有者は顧客の代表ではなく、プロジェクトの全体的なコンセプトを管理するアーキテクトです。 スクラムマスターは、全体的な設計コンセプトを監督する建築家である必要はありません。 典型的なスクラムのように、チームワークが実行されます。 同じ製品バックログ、同じスプリントバックログ。 スプリントは配達段階と一致し、4〜6週間です。
- 許容できる修正価格スキームが顧客に対して維持されます。
- パフォーマーにとっては、柔軟な方法論の使用が保証されますが、コンセプトを厳密に制御し、各スプリントごとに事前に考慮された制限があります。