アジャイル開発、主にスクラムをやっている人にとってタスクの見積りは悩ましいところかと思います。
個人的な備忘録も兼ねてよくあるミスをまとめてみます。
ここでのタスクの見積もりとはスクラムガイドにあるスプリント計画ミーティング第2部のことです。念のため。
①見積りポーカーで時間がかかりすぎる
見積りポーカーを用いて見積りをするのはよい方法なんですが、いかんせん時間がかかりすぎる場合が多いと感じています。
- みんな様子を伺っていてこれといった決め手がないままダラダラと議論してしまう
- 逆に好き勝手に話をしてもよいと思うメンバーがいて、決め手がないまま話が長くなってしまう。
見積りポーカーをやる理由は「タスク量の認識ズレをなくすこと」です。
認識ズレがないようなら見積りポーカーは必要ないはずです。そもそも別の方法でもよいかもしれません。
対策
- 認識ズレがありそうなタスクに対してのみ見積もりポーカーをやる
- そもそも見積りポーカーを用いずにタスク量の意識合わせを行う。
という感じでしょうか。我々のチームでは見積りポーカーにこだわらないようになりました。
とは言え、メンバー間で違和感が残ったまま見積りを終わらせるのだけは避けたいところですので、みんなの意識が合っているかどうかは確認します。
②技術調査や検証のタスクが正確に見積もれない
我々のチームでは「Feasibility Check」と呼んでいる種類のタスクです。
技術的な検証をしないと出来るかどうかわからない、採用してよいか判断できないといったことは開発の途中でもよく遭遇します。
この検証はどの程度で終わるのかなんて誰にもわかりません。さあ見積りとしてはどうすればよいのでしょうか。
対策
このような場合、ある程度時間を区切っての見積もりとします。
我々のチームでは8時間を上限としてタスク化していました。8時間(約一日)やってみてどうだったかをデイリースクラムで共有します。
出来そうなのか無理そうなのかを判断し、必要であれば検証を続けますし、出来そうなら別のタスクとして追加します。
③タスクをやる上での注意点を忘れてしまう
見積り時に、「ここは性能問題を注意する必要があるよね」とか「セキュリティについてxxのことを注意すべき」などの議論になります。
このようによい議論があるのに何もしないのはもったいない。
テストの時や受入時に「あー、見積もりの時に注意しようって言ってたのに~」とならないようにしたいです。
決まったタスクを忘れがち
リリース作業や報告書作成など、スプリント毎に同じような作業を繰り返し行うことがあります。
このようなタスクが見積りから漏れてしまい、結果としてキャパシティオーバーでスプリントのタスクが完了せず、という状況になりました。
対策
このような必要な作業がある場合は、忘れずに作業量を見積もっておきましょう。(当たり前のことです…)
UI変更を伴うタスクは思ったより時間がかかる
WEB系のシステムをやっていると大抵この問題が起こります。
特にチームにUIを得意としている人がいない場合、画面のレイアウトを少し変えるだけでも思ったより時間がかかります。
デザインが苦手なプログラマにとってJavaScriptやCSSなどの修正は手間がかかったり、慎重に作業をしてしまうものなんだと思います。
対策
2割増くらいの感覚で見積りをしましょう。もちろん過去のスプリントを参考にしつつ。
バッファは必要か!?
キャパシティに比べ見積もり時間が100%近くになっていることがあります。
理論上はそうなのかもしれませんが、現実だとこうはいかないことが多かったです。
見積りは実質の作業時間をイメージするのですが、現実は作業を開始する前にアレコレ考えることから始まります。
「影響するのはどのコードだっけ?」「似たようなコードあったっけ?」などなど…。
アレコレ考えることも見積りに含める必要があります。とは言え、どの程度なのかわかりません…?
対策
- バッファとしてしてしまう
アレコレ考えたり、ちょっとした課題で議論したり、と開発中はコーディングや設計書執筆以外のこともやっています。
これをいちいち作業として考え出すと細かくなってしまい大変です。(そもそもこのような作業を正確に見積もるは無理です)
そこで、バッファとしてそのあたりことを行う時間としてしまいます。
目安はキャパシティの20%くらいでしょうか。
まとめ
ダラダラと書いただけなので、まとめも何もないんですが、アジャイル開発時の備忘録でした。
スプリントレビューや振り返りの時も同じような失敗集ができそうです。