基本スケジュール式を信頼できますか？
私はスティーブマコネルの ソフトウェア見積もり：ブラックアートの謎を解く 本を読んでいます、そして彼は人月の努力に基づいて名目上のスケジュールを見積もるための方程式を与えます：
ScheduleInMonths = 3.0 x EffortInMonths1/3
この本によると、これは非常に正確です（25％以内）が、上記の3.0係数は組織によって異なります（通常は2から4の間）。組織内の過去のプロジェクトを使用して、使用に適した要素を導き出すのはおそらく簡単です。
私は、アジャイル手法に対して方程式を調整しようとしています。2〜6週間のサイクルを使用します。これは、多くの場合、最後に成果物が機能するミニプロジェクトです。 4週間（1か月）にわたって5人の開発者のチームがある場合、EffortInMonths = 5人月。次に、アルゴリズムは3.0 x5のスケジュールを出力します。1/3 = 5か月。
5か月は、1か月と25％以上異なります。 3.0係数を0.6に下げると、アルゴリズムが機能します（約1か月のスケジュールが出力されます）。本で言及されている可能な最低の要因は2.0です。
何が起きてる？ 「従来の」非アジャイルプロジェクトを見積もるためにこの方程式を信頼したいのですが、それが私の（アジャイル）経験と調和しない場合は信頼できません。誰かが私を理解するのを手伝ってもらえますか？
他の誰かからこれに対する答えがあるとは思わないので、私はここに私自身の答えを置くつもりです：
@Ryanthalは正しいと思います---アジャイル反復はウォーターフォールプロジェクトと同じスケジュール推定式に従わないだけです。質問したとき、理由を説明する必要があるのではないかと思いました。
方程式は基本的に、同時に同じことを行うことができる人の数には厳しい制限があり、作業が少ないほど、チーム全体で作業を拡大することが難しくなることを示しています。私たちは皆、小さなプロジェクトでこれを経験しました-2人の間で作業を分割することは挑戦であり、ある程度の非効率性があります。より多くの作業を3人に分割することは、もう少し管理しやすくなりますが、それでも困難です。
これはアジャイルプロジェクトにも当てはまると思いますが、アジャイルプロジェクトは、反復のために作業を分割する方法を計画することによって、この課題に対処するために2〜4週間ごとに協調して努力します動作するソフトウェアを提供するという制約があります、そしてコラボレーション環境での作業。そうすることで、アジャイルはチームをより自由に拡張できます（少なくとも3〜10人の開発者のアジャイルスイートスポット内で）。
従来のウォーターフォールプロジェクトのように、スケールアップのみが可能なモノリシックサーバーアプリケーションです。メモリを追加することはできますが、CPUの制約にぶつかります。 CPUを改善すると、メモリまたはディスクが新しい制約になります。スケーリングが難しいだけで、いくつかの厳しい制限に直面する可能性があります。従来のプロジェクトは、作業が1つのモノリシックチャンクとして扱われるため、利用可能な開発者リソースをどれだけ効果的に使用できるかという制約があります。
（リソースとスケジュールの点で）アジャイルは、サーバーコンポーネントアーキテクチャに似ており、各部分を複数のサーバーにまたがって個別にスケーリングできます。承認コンポーネントがボトルネックの場合は、別のインスタンスを起動します。それでも厳しい制限に直面する可能性がありますが、インフラストラクチャの機能の範囲内で多くの柔軟性があります。
あなたはそれが決して意図されていなかった何かのために方程式を使用しています。スティーブの本で説明されている基本スケジュール式の制限のいくつかを次に示します。
スケジュール式は、式によって示されるサイズに合わせてチームサイズを調整できることを暗黙的に想定しています。
チームのサイズが固定されている場合、スケジュールはスコープの立方根に比例して変化しません。チームサイズの制約に基づいて、より大きく変化します。セクション20.7「スケジュールの見積もりと人員配置の制約」では、この問題について詳しく説明します。
基本スケジュール式は、小規模プロジェクトや大規模プロジェクトの後期の見積もりも対象としていません。
プロジェクトに取り組んでいる特定の人の名前がわかっている場合は、他の手法に切り替える必要があります。