ガチガチにスケジューリングされた開発フローに疲れ、その反省から組織にアジャイルを導入したとき、
「アジャイルは締切にコミットはしない。だからチームは安定して健康的に働けるのだ」
というような理解・説明がされることがあると思います。
このメッセージは誤りではありませんが、誤読される可能性も高そうです。
この記事では「コミット」をテーマに、アジャイルな計画を学んでみます。
非アジャイルは「コミット」をする
アジャイルでない開発で計画するとき、スケジューリングとは「いつまでにできるか」を考えることが大半です。
スケジュールにおける「コミット」とは、「特定の日付までに、成果物が完成／作業が完了する約束」を指します。
約束するのだから、適当に日付を決めることはできません。プロダクト開発／プロジェクトのなかで発生するタスクの工数を丁寧に見積もり、合理的な締切1を設定します。
合理的な締切であるからこそ、これに間に合わないことは一種の失敗とみなされることも多いでしょう。
アジャイルは「見積り」をする
一方でアジャイルにおけるスケジューリングは、基本的に「いつごろにできそうか」を見積もるものです。
一見、コミットメントの「いつまでにできるか」とほぼ同じ表現に見えますが、明確な違いがあります。それは、アジャイルな見積りはコミットすることを拒否します。
そのため、たとえば以下のようなフレーズが計画中に出てくるでしょう。
- 7,8割の確立で予定通り終わりそう
- とりあえず設定したみたけれど、来月また見積りなおしたほうがよい
- この機能はリリースに間に合わないかもしれない
私なりに言い換えるなら、日付とスコープと品質のすべてが固定されたコミットをしないこと、と表現したくなります。
アジャイルは「見積り」をつねに更新する
「いつまでにできるか」をコミットしないので、アジャイルな計画は楽そうに見えます。しかし一方で大変なこともある、というのが本記事の主張です。
その大変な理由は、アジャイルが「いつまでにできそうか」をつねに更新するからです。
開発者・チームは、その日、その週、その月の変化をもとに「いつまでにできそうか」という情報の変化を、ステークホルダーにすぐ伝える義務があります。
この更新によって、下記に引用する各特徴を満たす計画が出来上がっていきます。
よい計画づくりとは、以下のような特徴を持ったプロセスのことだ。いずれも「ソフトウェア開発の問い」に対する答えを見つける手助けとなる。
・リスクを軽減する
・不確実性を減らす
・意思決定を支援する
・信頼を確立する
・情報を伝達する2
ちなみに上記の引用で、計画ではなく計画づくりと表現されているのがポイントです。よろしければアジャイル開発は計画しない？も参照ください。
まとめ
アジャイルは頻繁に計画をする手法です。完璧な計画をつくってコミットすることを拒否する代わりに、完璧な計画がつくれないからこそ計画づくりをやり続けます。
アジャイルは計画と共に存在する、というのが自身の理解です。
参照
- Mile Cohn『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』
- アジャイル開発は計画しない？