大雑把ですが、ガントチャートを IDEF0 風に分解すると、こんな図になります。
・インプット方向のタスク（前工程のタスク）がある。
・アウトプット方向のタスク（後工程のタスク）がある。
・タスクは、一定の作業量を持つ。
・タスクは、一定の作業を行うと終了する（開始と終了がある）。
・作業は、配員（人）が行う。
・配員は、一定の作業能力（属人性、能力差）を持つ。
・配員は、リソースとしての制約がある（同時に２つの場所で働けないなど）。
・タスクは、時間制約がある（無限に長い期間でやってはいけない）。
・タスクは、期間制約がある（無限に期限を延ばしてはいけない）。
・１日の時間は、24時間である（週単位の勤務時間は40時間である、など）。
ここで、前者の項目は「前提条件」であり、ある条件をクリアすると「完了」になります。RPG ゲームみたいなものです。
後者の制限は、制約条件で「ルール」になります。ルール違反をすることはできません…というか、ルール自体がないと「ルール違反」って現象がないですよね（と、現象学的な話とか）。
これだけの条件を出しておけば、プログラミング可能/検証可能になります。いわゆる XP で言うところの計画ゲームが可能です。
で、これをベースにして擬似コードを書いてみると。
// 制約条件を設定
Task.制約("40時間勤務");
Task.制約("残業なし");
Task.制約("リリース時期", 2012/01/01 );
// 属人性, 能力差ポイントを設定
Person("masuda").属人性("HP", 100 );
Person("masuda").属人性("MP", 200 ); // 魔法が使えるとか
Person("tomoaki").属人性("HP", 200 ); // 体力が多いとか
Person("tomoaki").属人性("MP", 50 );
// リソース(配員)を設定
Plan.リソース(Person("masuda"), 0.5 );
Plan.リソース(Person("tomoaki"), 1.0 );
// タスクの作業ポイントを設定
Task("本タスク").作業ポイント( 200 );
// 連携を設定
Task("前タスク") -> Task("本タスク");
Task("本タスク") -> Task("後タスク");
こういう風に設定しておいて、
// ガントチャートを作成して Plan.CreateGanttChart();
シミュレートする場合は、こんな風に。
// こんな風にして、100 回ほどシミュレートする Plan.Simulate(100)
現実にプロジェクトの実績を入れる場合は、次のように。
// 実績を設定
Plan.Task("本タスク").実績( 100 );
// タスクが無くなったら、即削除して再計画
Plan.RemoveTask("削除タスク");
Plan.CreateGanttChart();
// タスクが増えたら、即追加して再計画
Plan.AddTask("追加タスク");
Plan.CreateGanttChart();
// タスクが追加されたので、シミュレーションをやり直してみる。
Plan.Simulate(100)
ここで、成功確率なんかが出ると、実に「それらしい」感じになるんでうすがどうでしょう？
アジャイルが一見すると「計画」を捨てているように見えるのは、それぞれのタスク/ストーリーカードの繋がりを「視覚化」しないところにあります。これは、視覚化することによるオーバーヘッドを避ける≒コミュニケーションコストを下げる、ことに一役買っています。
なので、逆に言えば、計画を視覚化することのコストが限りなく低ければ、再計画時の情報となるので、不明確部分が減り、成功確率があがります（と予想されます）。まぁ、計画倒れとか取らぬ狸のなんとやら、というのもありますから「再計画」が絶対という訳ではありませんが、ひとつの選択肢が増えますよね、ってことで。
