なぜ、いつFFFを選ぶべきですか？見てみましょう。
1.3つの組み合わせ
プロジェクト管理への各アプローチは、予算、作業範囲、期限、システムの内部品質の値を修正するか、修正しないという点で本質的に異なります。
特定の組み合わせは、特定の作業条件を作成し、長所と短所があります。
- 固定価格
- プロジェクトの三角形の3つのポイントが固定されています。時間、お金、作業量です。
- , , . , 12 IT-.
- . / , .
- . , . , .
- .
- Time and Materials (T&M)
- , - .
- .
- , .
- , . , , .
- .
- ( , Product Owner'), , , , .
- Fix Time and Budget, Flex Scope (FFF)
- : , .
- .
- , , .
- , .
- , , . .
- : , / , .
- , .. . , , , , , , .
– , . , «», , , . . , , SonarQube. Podlodka.
2.
これらの3つの組み合わせが形成されるのはなぜですか？なぜすべてを修正できないのですか？結局のところ、最も簡単なことは、システムの予算、作業範囲、リリース日、および内部品質を修正し、契約に署名し（顧客が内部の場合は、利害関係者との承認手順を実行します）、4つの値すべてで正確にヒットして作業を行うことです。しかし、実践が示すように、歪みなしにこのパスを簡単に通過できないという根本的な問題があります。
予算の計算に問題はありません。リリース日を計算するのは非常に簡単で、IT製品の特定の品質レベルを設定するための多くのメトリックとチェックリストがあります。仕事の範囲を正確に見積もることができれば、それはすべて簡単です。言い換えれば、タスクの詳細なリストとこの作業量の正確な見積もりがあれば、他の3つの量は簡単に計算されます。逆に、正確な見積もりがない場合、残りの値も作業量の見積もりに基づいているため、不正確になります。
許容できる精度で機能する単一の推定方法がないため、作業範囲の推定は常に問題になります。すべての方法は、同様のことを行ったチームの以前の経験に基づいています。これは、人々が不正確であるため、最終的には不正確を意味します。感情的、楽観的、忘却的です。正確な評価方法の欠如は、私たちが仕事量の評価に入るのを妨げる最初の要因です。
この問題について詳しくは、「プログラマーに対する顧客満足度：すべてのプログラマーは楽観主義者である」という記事に書いています。Vadim Makishviliからのレポート36へのリンクがあり、彼は単にスコアに3を掛けることを提案しています。ルートを敷設して歩くという比喩を使用して、ITプロジェクトが計画より2〜3倍長くかかる理由の記事に書かれています。..。
IT製品の作業の過程で、実行する必要のあるタスクのリスト、詳細の深さ、システム設計へのアプローチなどが変化します。これは、外部環境の影響下で発生します。市場の変化、会社の戦略の変更、会社内のポリシーの変更、ユーザーからのフィードバック、分析の段階で沈黙し、後で発言することを決定した人々からの新しい入力などです。外部の影響に影響を与えることができないことは、最初に評価に入るのを妨げる2番目の要因です。
3番目の要因は、作業の範囲を説明するときに完全性の達成を決定するための基準がないことです。 TKの書き込みは終了できず、停止することしかできません。これについては、利用規約の作成をやめる時期についての記事で詳しく説明しました。
かなり複雑な領域で作業する場合は、これがすべて当てはまるということを予約する必要があります。Cynefinフレームワークによると、これらは複雑な領域と複雑な領域です。プロジェクトが明白になり、同時にそれがかなり短い場合は、作業量を非常に正確に見積もることができます。
全体として、問題の根本は、作業範囲の不正確な見積もりと、この見積もりを正確にすることの実際的な不可能性にあると考えられます。したがって、次のようになります。
- 固定価格プロジェクトは、3つの固定ピークで見積もりを行うことはほとんど不可能であるため、システムの内部品質を犠牲にします。または、同じ固定価格プロジェクトで、評価の不正確さをカバーするために非常に多くのリスクを再予算化しますが、これは効果がありません。
- T&M , . Product Owner'.
- FFF , , « » , T&M.
3. ?
作業範囲を十分な精度で見積もることが不可能な場合は、まったくできないのではないでしょうか。そのような動きがあります#NoEstimates。つまり、高い内部品質を維持しながら、アイデア段階から本番環境への展開まで、可能な限り効率的にタスクを実行するように開発プロセスを編成します。彼らは、フロー処理メトリックを追跡し、新しい機能を提供するプロセスを改善することに特別な注意を払って、Kanbanを使用してプロセスを整理することを提案します。時期尚早の評価は有害であると見なされ、バックログの評価と手入れは時間の無駄です。
#NoEstimatesの詳細：
- デビッドアンダーソンは、これについて多くのことを話します。たとえば、彼の講演「エンタープライズアジリティへの代替パス」で。
- Askhat Urazbayevは、AgileDaysで彼のスピーチ#NoEstimates：Non-evaluativedevelopmentで講演しました。
- Ron Jeffriesは、これについて記事「推定に関するいくつかの考え」に書いています。
- Denis Stebunovは、これについてHabréの記事「ソフトウェア開発における用語の見積もりについて」に書いています。
私は両方ともこのアプローチに賛成です。私は彼がエンジニアとして、そしてリーダーとして好きです。しかし、人生は、予算の所有者が少なくとも仕事の最初の段階で、少なくともおおよその見積もりを必要とするように調整されています。でByndyusoft、我々は時々しか顧客とかなり長い付き合いの後、#NoEstimatesに移動し、これは常に発生しません。
4.FFF-柔軟性と予測可能性のバランス
グレードは人生を台無しにし、時間の無駄ですが、グレードなしで始めるのは難しいです。ただし、正確な見積もりがないことは明らかです。最善の選択肢は、締め切りと予算を修正して、ビジネスがそれに耐えられるようにし、作業量を変動させないようにすることです。さらに、顧客と請負業者は、各時点でチームが最も重要で必要なタスクにのみ従事し、顧客は優先順位の選択のダイナミクスを監視するために時間を費やすことに同意する必要があります。
FFFの説明を最初に見たのは、Fix Time andBudgetの章のFlexScopeの37signalsによるRealの取得でした。現時点では、私の会社では、これが最も人気のある仕事のアプローチであり、顧客と私たちは両方ともそれに満足しています。
5.システムの内部品質
上で書いたように、FFFでの作業は、システムの高い内部品質を保証できる有能な開発者がいる場合に可能です。これは通常、すべてと全員を自動化し、ベストプラクティスのチェックリストを作成し、コードとアーキテクチャを絶えず確認し、あらゆる種類のテストを行い、最も重要なこととして、適切な人をチームに採用することで実現されます。
Martin Fowlerのブログ、「高品質のソフトウェアはコストに見合う価値があるのか」と、内部の品質を忘れてはどうでしょうか。 ..。これについては、ITプロジェクトの失敗の判断に関する記事に書いています。..。つまり、FFFでは、製品開発の方向性の変化が想定されており、これはシステムの十分な柔軟性を意味します。システムの品質が低い場合、「ターン」ごとに開発が遅くなり、プロジェクトが完全に停止するまでコストが増加します。
FFFに従って作業する場合は、品質基準を契約に入れて、確実に修正します。
6.顧客と請負業者の動機
FFFの作業は、顧客と請負業者の側に適切な動機を与えます。顧客と請負業者が契約インターフェースを介して通信する固定価格とは異なり、顧客が境界を失い、必要以上に支出する可能性があるT＆Mとは異なります。FFFでは、最も重要なことを行うと同時に契約条件を満足させるために、誰もがコミュニケーションに投資し、プロジェクトに「生きる」必要があります。
7.FFFを選択します
固定価格とT＆Mには、特定の状況での利点があります。
- 入札に参加し、合意された時間とお金の範囲内で特定の作業を完了することを約束している場合、コミュニケーションは主に契約を通じて構築されますが、固定価格がおそらく最良の選択肢です。
- 顧客が必要なものを正確に知っていて、作業プロセスを効果的に構築する方法を知っている場合は、T＆Mリソースを購入し、自分の裁量で処分する必要があります。
ただし、他の条件が同じであれば、FFFを選択しようとします。このアプローチは最もバランスが取れているようです。顧客と請負業者のリスクを軽減し、双方に必要な動機を与え、システムの内部品質を管理します。
リンク：
- Agileで作業するときにどのようにそしてどのような参照条件を書くべきか。
- ArtyomGorbunovの設計局におけるプロジェクト管理の原則。