ボトムアップの計画とトップダウンの計画
伝統的なワークブレイクダウンストラクチャー（WBS）によるタスクの分割と、ガントチャートによるスケジューリングと依存性の把握、これらのウォーターフォール開発の計画はトップダウンです。一方、プロダクトバックログを中心としてマイルストーンやスプリントの最初に必要な分だけ計画を詳細化し、その詳細計画やスプリントの実施結果をプロダクトバックログにフィードバックさせていくやり方はボトムアップです。
また、ウォーターフォール開発において管理者によるスケジューリングで開発者を管理していくのはトップダウン。それに対して、アジャイル開発において開発者（現場）主導でバックログを作成し、現場からフィードバックを返すのはボトムアップです。
アジャイル開発ではプロダクトバックログは実装すべき機能を中心に記述しますが、これに非機能的タスクを織りまぜると、さらに複雑になります。そのため、スプリント内の開発はスムーズに流れますが、全体を掴むことは困難です。
そのほか、大規模な開発を行なう場合、開発チーム外とのやり取りが多い場合には、アジャイル開発のボトムアップ的な計画だけでは不十分です。表2にトップダウン計画とボトムアップ計画の違いを示します。これを参考に両手法をうまく取り入れていくのが良いでしょう。
| トップダウン計画 | ボトムアップ計画 | |
| ツール | ワークブレイクダウンストラクチャー（WBS）、ガントチャートなど | （ストーリー、タスクなどの）バックログ |
| 構造 | 概要－詳細の階層関係、およびタスク間の依存関係を持つ | 単純なリストで表現する。工数／期限／重要性などの属性を適宜付与する |
| メリット |
|
構造が単純でメンテナンスしやすい |
| デメリット |
|
全体をつかみにくい |
| 求めるべき役割 | 概要計画を立てる際（特に開発チーム外との調整が必要な場合）に利用する | 開発における日々の計画や進捗把握のために用いる |
Steve McConnellの『ソフトウェアの見積り』（日経BPソフトプレス刊）にもあるように、計画手法を併用することは決して悪いことではありません。しかし、異なる計画手法の間で整合性を取ろうとすると、途端に厄介なものとなります。
それぞれの計画手法の良いところを積極的に取り入れて明確な計画を立てることに終始し、無理に整合性を取らないようにしましょう。とは言うものの、ディーバではこれについては未だに試行錯誤が続いており、計画における最も難しい作業であると認識しています。
幾何学の用語で「図形の部分と全体が自己相似になっているもの」であり、自然界でも雪の結晶や樹木の枝分かれの様などの例が挙げられます。
アジャイル開発では計画からリリースまでを短いサイクルで回しますが、そのサイクルがデイリースクラム単位、スプリント単位、マイルストーン単位、リリース単位と粒度が異なっても相似的に見えることから、フラクタルに例えられることがあります。
アジャイル開発の計画にも「銀の弾」はない
ここまでひとくくりに計画と呼んできましたが、計画と見積もりは本来別のものです。見積もりは客観的であるべきものであり、正確な見通しを示すべきものです。一方、計画とは意志の入り込む領域です。こうしたい／こうあるべきというシステムの姿がベースとなって計画が作成されます。
アジャイル開発においては、機能に優先順位を付けてリスト化しますが、最終的にどこまで組み込めるかは事前に「精密」には分からないということを正確に把握します。すべてが見えないときに一般的に人は“楽観的”に見積もってしまう傾向があるようです。
アジャイル開発も「銀の弾」（※注3）ではありません。ソフトウェア開発本来の不明瞭さを認識し、スコープは可能な限り柔軟に保ち、プロジェクトの早い段階では安請け合いをして優先順位の低い機能までコミットしてしまうことを避け、慎重にコミットしていきましょう。
イテラティブに開発し定期的に振り返りを行なっていくこと、これは絶え間ない開発プロセスの改善であると言えます。特に技術的な領域から離れるほど各社各様、各人各様になり、決まりきったプラクティスがなかなか通用しないのかもしれません。
短絡的な解を求めすぎず、振り返りとそれによる気づきの中で少しずつ自分たちにしっくりくる方法を身につけていければ良いでしょう。
狼男や悪魔を撃退できる弾丸。転じて物事に対する決め手や特効薬のこと。ソフトウェア開発ではFrederick Brooksが書いた書籍『人月の神話』（ピアソンエデュケーション刊）で“銀の弾などない”と述べられ、その後よく使われるようになった言葉。
