アジャイルな見積りと計画づくり

7部構成となっています。

1部、2部、3部が、4部を理解するための準備です。これが150ページ弱もあるので、面白くないとして読むのを止めてしまうかもしれません。
1部と2部は、ストーリーポイントやベロシティやプランニングポーカーといったアジャイルに関心のある人は、聞いたことのある話しです。
3部は、お金と顧客満足度のことなども絡めた話しです。実際に仕事しながら読み返すことで身に付きそうです。

4部と5部はとても面白いです。実際にどうするか、です。
4部は、”スケジュールを立てる”という題で、ベロシティの見積り、不確実性に備えるバッファの計画、など新規項目の説明もあります。
5部は、”トラッキングと情報共有”という題で、バーンダウンチャート、タスクボード(カンバン)、の説明があります。

6部がまとめです。
7部は小説仕立ての読み物とのことで、おまけの感じです。


4部と5部から、いくつか抜粋します。

第4部 スケジュールを立てる

13章-16章 : 計画づくり

13章 リリース計画づくりの基本

良いプロダクトオーナーとは、優先順位づけの最終責任を引き受けると同時に、開発チームからの助言にも耳を傾けるものだ。特に、開発する順序についての助言を聞き入れられるかどうかが大事だ。

14章 イテレーション計画づくり

イテレーションプランニングでタスクに担当者を割り当てても得るものは何もないのに、大事なものが失われる。プロジェクトが最もうまくいくのは、チームに「全員が一丸となって取り組む」という態度が備わっているときだ。自分の空いた時間はチームのために使うし、他のメンバーもきっとそうしてくれると思える状態である。

タスクのサイズは、開発者が平均して1営業日に1つ完了できるぐらいの大きさが適切だ。

これよりサイズが大きくなると、1人か2人の開発者に負荷が集中してしまって、残りのメンバーは、多忙な開発者の作業が終わるのを待つことになりがちである。

現実には、多くのチームで一番うまくいくのは、計画した作業(タスクカードの合計)が1日あたり4~6時間になっているときだ。

ここで鍵となるのは、チームメンバーひとりひとりが、自分の得意分野以外でもやれることを探してチームに貢献することである。

15章 イテレーションの長さを決める

私が理想的だと考えるイテレーションの長さは2週間だ。

16章 ベロシティの見積り

したがって、私が単一の値で表現されているベロシティの平均を幅を持った見積りへと変換する場合には、60%と160%を掛けて最小と最大の値を計算することにしている。つまり、過去のベロシティの平均が15ポイントなら、幅を持った見積りとしては、9ポイントから24ポイントになるということだ。

60%から160%という幅を大きすぎると感じるかもしれないが、現時点での不確実性を考慮すればこれぐらいが適切だ。

ベロシティの見積りを出す前にイテレーションを1回でも実施できるなら、迷わずそうすること。実績値にまさる見積りはない。実際にチームのベロシティを測定するのが一番だ。

どのやり方で見積もったにせよ、ベロシティの実績値を使えるようになったら、すぐそちらに切り替えること。

いずれの方法を採用するにせよ、ベロシティの見積りには幅を持たせる。

17章 : スケジュールに組み込むバッファ

17章 不確実性に備えるバッファの計画

アジャイルな計画づくりについて私がよく耳にするのは、「場合によってはうまくいかないのではないか」というものだ。よく引き合いに出されるのは、以下のような状況である。

・ずっと将来のプロジェクトを計画する
・プロジェクトには定められた締め切りがあり、かつスコープも厳密に決まっている
・プロジェクトが契約で縛られている
・要求がごく表面的にしか把握できていない
・柔軟なスケジュールでプロジェクトを進めることを、組織が好まない(厳密な納期や成果を定める必要がなくても、厳格なスケジュールが求められる))

このような状況では、信頼のおける計画を立てられる能力がとりわけ重要になる。その場合、16章で説明したやり方だけでは足りないことも多い。

たとえば私はかつてフォーチュン40企業でソフトウェア開発担当副社長を務めたことがある。そこでは翌年度の予算策定の都合上、プロジェクトは開始される12ヶ月から18ヶ月前にスケジュールを立てていた。もちろんこの時点ではまだ要求への理解も曖昧だが、それでも最初のコミットメントをしなければ、適切な要員をアサインするために動くことができない。しかもこれはさらに不確実性を増すことになる。というのも、実際にプロジェクトが開始される時点では、具体的に誰がチームに参加するかはわからないのだ。そして、その「適切な誰か」はまだ雇ってすらいないことも珍しくない。

たとえば、あなたがプロジェクトの納期と中心となるフィーチャにコミットメントを求められているとする。納期を守れなかったり機能が不足したら会社の評判に大打撃を与える。社内でのあなたの評価も大きく下がることになるだろう。

こうしたリスクへの備えとしては、スケジュールにバッファを組み込むのが有効である。バッファとは、見積り誤差を吸収するための余裕である。不確実性が高かったり、誤りの代償が高くつく場合、バッファを組み込むのは賢い選択だ。

顧客に「こちらにあるフィーチャはすべて実装します。うまくいけば、こちらのフィーチャも実装できるかもしれません」と言うのだ。

ソフトウェアプロジェクトにスケジュールバッファを持たせるには、まず私たちの見積りプロセスを見直して、ユーザーストーリーやフィーチャの見積りの値を2つにしなければならない。

必要なのは50%見積りと90%見積りである。

5. 使用上の注意 p.213

・一般にプロジェクトでは、納期と提供すべきフィーチャ一式のどちらも、実は交渉可能であることが多い。大抵の場合チームに求められるのは、高品質なソフトウェアを持続可能なペースで提供し続けられることだ。納期やフィーチャを交渉できるなら、交渉すべきだ。このような状況でプロジェクトにバッファを追加するのは、手間を増やすだけでしかない。
・バッファのことを話題にするときには注意が必要だ。バッファの存在を隠したり、バッファの使い方を秘密にすべきではない。というのも、バッファは水増しのように見えてしまうからだ。とりわけスケジュールバッファは誤解されやすい。こうした誤解を避けるには、見積りとバッファをどうやって導き出したのかを伝えること。そして、バッファは全員がスケジュールに自信を持てるようにするためのものだと説明するのだ。

プロジェクトというものは非常にたくさんの不確実性を抱えている。しかし、この不確実性をきちんと反映したスケジュールが作成されることは稀である。不確実性が大きすぎる場合や、問題が起きた場合の影響が深刻な場合には、プロジェクト期間を見積るのに工夫が必要になる。

18章 : 複数チーム編成プロジェクトの計画づくり

18章 複数チーム編成プロジェクトの計画づくり

「アジャイルチームの開発者は7名から10名である」とよく言われる。これぐらいのチーム規模だとかなりの仕事ができる。

第5部 トラッキングと情報共有

第4部では、プロジェクトの適切なスケジュールを決める方法を扱った。しかし、計画とスケジュールを立てただけでは、計画づくりは終わらない。計画づくりでは、計画に対する進捗を把握すること、情報を共有すること、そしてそこから得られた知識にもとづいて計画を見直すことが重要なのだ。

19章 : バーンダウンチャートとベロシティ

19章のバーンダウンチャートは、リリース計画に対する全体のバーンダウンチャートです。

19章 リリース計画のモニタリング

ストーリーを予定されていたイテレーションで完了できなくなりそうなことが発覚したらすぐに、開発者と顧客は一緒に問題を解決すること。よくある解決策は、ストーリーをイテレーションから外すか、ストーリーを分割して、その一部を先送りにするというものだ。プロダクトオーナーや顧客であれば、イテレーション中であっても即時にそうした判断を下せるし、ストーリーのコストについて得られた新たな知識をもとに、残っているストーリーの優先順位づけも見直すことができる。

グラフの縦軸は、プロジェクトの残ストーリーポイント数(または、残ストーリーの理想日数)である。横軸はイテレーション数だ。リリースバーンダウンチャートは、イテレーション開始時点での残作業量を示すグラフである。このグラフは、チームがゴールに向かってどれぐらい進んでいるかを視覚的に訴える、強力なツールである。

20章 : タスクボード(カンバン)とバーンダウンチャート

20章のバーンダウンチャートは、それぞれのイテレーションに対するバーンダウンチャートです。

20章 イテレーション計画のモニタリング p.238

「リリース」という大まかなゴールに対する進捗をトラッキングすることに加えて、個々のイテレーションの作業を完了するという、身近なゴールに対する進捗もトラッキングする価値がある。この20章では個々のイテレーションのトラッキングに使う2つのツールを紹介する。タスクボードとイテレーションバーンダウンチャートだ。

一番左の列にはストーリーカードを貼る。ストーリーカードには見積りポイントがかいてあるので、タスクボードを見るだけでイテレーションで取り組んでいるストーリーそれぞれのポイントがわかるようになっている。

左から2番目の列はこのイテレーションで「やること(To Do)」を一覧するための列だ。ここにストーリーを実装するために洗い出したタスクカードをすべて貼り出す。タスクカードに書き入れる見積りは、作業完了までの所要時間だ。

「作業中」の列は、開発者がサインアップしたカードを貼る場所だ。使い方はこうだ。開発者は作業を着手するときに「やること」からカードを取る。取ったカードに自分のイニシャルを書き入れ(サインアップ)して、「作業中」の列に貼る。

「確認待ち」の列はなくても構わないが、私はあったほうが有用だと考えている。特に、チームがアジャイルな開発チームになろうとしている間は用意しておいたほうがよい。

経験から言うと、開発者がタスクを完了したと思ったときに、他の誰かと一緒に作業の内容をざっと確認するだけでうまくいくことも多い。

タスクボードに貼り出したタスクカードの見積りが変わったと思ったら、いつでも再見積りしてよい。むしろ、見積りは積極的に見直すべきだ。

私は毎朝、各行の残り見積り時間を集計している。集計結果をもとにイテレーションバーンダウンチャートを更新するためだ。イテレーションバーンダウンチャートは、タスクボードと並ぶ、イテレーションの進捗をトラッキングするためのツールだ。

私の経験では、イテレーションの長さが2週間より長い場合、イテレーションバーンダウンチャートがあると非常に便利である。イテレーションバーンダウンチャートは、作業の残り時間を1日ごとに集計したグラフである。

グラフは毎日更新する。

しかも、見積りは変わりやすいものだということを忘れてはならない。どんなに努力したところで、完璧に見積もることはできないのだ。

警告する。個人のベロシティをトラッキングしてはならない。個人のベロシティをトラッキングするのは、プロジェクト全体の成功を妨げることになる。

チームメンバーに仕事への動機づけを与えるなら、それはメンバー個人個人ではなく、チーム全体に貢献することを促すようなものでなければならない。他のメンバーを手助けすることでチーム全体のスループットが向上するなら、チームメンバー全員がお互いに助けあうべきだ。

タスクの所要時間の見積りと実績の比較はしないほうがよい。大抵の場合、予実を追跡することによるリスクと手間が利点を上回ってしまうからだ。

21章 : 計画と進捗とイテレーション終了の情報の共有

21章 計画とコミュニケーション

プロジェクト初日に立てた計画を3ヶ月、あるいは6ヶ月も放置しておくことはできない(そんなことはしたくない)。計画はプロジェクトの期間を通じて変更されるものであり、変更された結果は伝えねばならない。計画の変更内容を伝えるのに失敗と、フィードバックループを活用できない。

最後に、あなたが伝えようとする相手全員に、伝えたい内容を正しく理解してもらうのは、あなたの仕事だ。単に聞いてもらうだけではなく、理解させるのだ。あなたがプロジェクトマネージャで、プロジェクトが遅れていることを伝えねばならないなら、誰にも誤解の余地がないように伝えなくてはならない。アジャイルなチームが大きな目立つグラフ(big visible chart)を好んで使う背景にはこうした理由もある。プロジェクトの作業スペースに貼り出されているのが数枚の大きな目立つグラフだけだとしたら、どのグラフも重要だと誰の目にも明らかになる。

改めて書くまでもないが、リリースバーンダウンチャートが進捗を伝える最も重要なツールである。リリースバーンダウンチャート上の進捗は、残作業とチームのベロシティの関数である。リリースまでに必要なイテレーション数の単純な計算法は、開発が必要な残ポイント合計をチームのベロシティで割り、端数を切り上げた整数を求めればよい。たとえば、残ストーリーポイントが100ポイントでチームのベロシティが10なら、完了まであと10イテレーションかかるということだ。

しかし実際には、計測した過去のベロシティも緻密なものではないし、未来のベロシティは変動する。

過去の履歴からベロシティの傾向というものがつかめるとよいのだが、ほとんどのプロジェクトでは、はっきりとした傾向を捉えられるほどイテレーションの絶対数をこなしていない。それに、もし私が自分のチームのベロシティが増加していく傾向を見つけたとしても、気持ちの上で喜ぶだけで、具体的に何か行動を起こすことはない。図21.2にベロシティの傾向線を記入したり、「この調子なら次のイテレーションではベロシティは20ポイントは出せるんじゃないか」と発言したりするようなことは、私は絶対にしない。同様に、ベロシティが下がっていく傾向を見せたとしても、この先もベロシティは低下し続けるとは考えない。ベロシティを低下させている原因を探し出して、それを取り除くのだ。

表21.1に示した3つの値を使って今後のベロシティを予測すると、プロダクトオーナーとチームが、予定したリリース日までに完了できる仕事量を予測できるようになる。表21.1の例でいえば、プロダクトオーナーは次のように判断できる。残り5イテレーションで、少なくとも70ポイント分のストーリーの完成はまず期待していいだろう。しかし、85ポイントを越えた領域にあるフィーチャについては、広告飛行船向けのプロダクト広告にその機能のことを掲載するスペースを用意しても、きっと無駄になるだろう。

まとめ

4部と5部から最重要と思うところを外して抜き出しました。

仲の良いチームが大きな成果をあげる、全員が一丸となる、中間生成物ばかりが肥大して顧客が満足しないものを作ってしまうの避けて顧客の満足を最大まで引き上げる、といったアジャイル手法について理論と実際について精緻に整理された素晴らしい本です。
準備が長い(150ページ弱)ですが、それを乗り越えるとボーナスステージが100ページ強ほど続きます。

1部から3部の中にも、

第1部 2章 なぜ計画づくりに失敗するのか
5. 見積りがコミットメントになっている

いかなる見積もりも暗黙のコミットメントになってはならない。

など、誰もが経験したことがありそうな問題や、

第1部 6章 見積りの技法
5. プランニングポーカーがうまくいく理由

そして、プランニングポーカーがうまくいく最後の理由は、それが楽しいからだ。

など、作業自体を楽しくしてチームとしてプロジェクトを成功させるための具体的な方法が書かれています。


コメントを残すために、Twitter OAuthを必要としています。ご了承ねがいます。
コメントは、Twitterに影響しません。

Twitter OAuth