デザイン作業の見積りと計画

夕方からプロジェクトの残作業棚卸しをしていて、@shikakunが見積りを計画に悩んでいたので、相対見積りやタイムボックスの考え方について話していました。

最初は私達プログラマがどうやっているかを説明していたのですが、話していくうちに「これ職種関係ないじゃん」ということに気付いて、それなりにいい話になったような気がします。

• 明確なゴールがあるものや完了条件が明確、イメージしやすいものは相対見積りで考える
• スパイクや調査タスクなど、完了条件が曖昧だったり、作業量を見積るの困難なものはタイムボックスで考える
  • タイムボックスの半分くらいで相談するタイミングを入れておく

長期的なプランニングを考えるときは、それらをえいやっと足して計画をたてればいいし、イテレーションプランニングでは相対見積りを時間見積りにざっと変換して、タイムボックスのタスクと合わせて計画していけばよいです。

計画は最初に立てて終わりではなく、現実に合わせて変えていける、計画し続けることが非常に大切です。その為には、がちっと引かれたガントチャートよりは、相対見積りと絶対値の見積りをうまく組合せた「直近の計画は詳細に、長期計画はざっくりと」というアプローチがとれる、いわゆるAEPスタイルがすごくいいなーと思っています。

もちろんプロジェクトの性質や状況はありますが、普通の人が普通にソフトウェア開発をするのであれば、「計画通りに進めること」よりも、プロジェクトを通した学習によって起こる「変化を受け入れること」ができる計画やプロセスを採用したほうが、メンバーのモチベーションの面でもメリットが大きいと主観ですが感じています。

こんな話を10分くらいしていたんですが、そういえばうまく見積りと計画ができたのか聞いていなかった…