アジャイルサムライを読んでアジャイルな計画作りについて整理する

アジャイルサムライを読んでアジャイルな計画作りについて整理してみました。

アジャイル開発用語

プロジェクトでこなすToDoリストのことです。

チームがユーザーストーリーを動くソフトウェアに変換する速度のことです。

一週間か二週間を全力疾走する短距離走みたいなもので開発期間を指します。

イテレーション数＝作業量の合計 / チームの予想ベロシティ

スコープを柔軟にしておくことがアジャイルプロジェクトで計画を誠実なものに保ち続けるための秘訣です。

新しいストーリーを追加するときは、必ずどれかひとつ既存のストーリーをマスターストーリーリストから削ってもらう必要があります。これにより開発チームは顧客に要求変更の機会を提供しつつ、スコープをプロジェクトで作業できる範囲内に留めておくことができます。

アジャイル開発の原則として、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、顧客の競争力を引き上げます。

この原則により、最初に要求を集めておかなきゃとは思わなくなり、ストーリーの無駄を減らすことができます。

さらに、マスターストーリーの長さを一定に保ち続けていくほうが望ましいとうことを、顧客と開発チームの両者が学んでいきます。

マスターストーリーリストには顧客がソフトウェアで実現したものを載せていきます。

載せた項目は、顧客が優先順位をつけて、開発チームが見積もります。その結果が計画の土台になります。

良いマスターストーリーリストの長さは1ヶ月から6ヶ月程度の期間でこなせる仕事の範囲に収まります。

プロジェクトの規模とこれから始めるプロジェクトの長さを見通します。プロジェクトはどのくらいの期間で終わるかを把握します。

マスターストーリーリストにあるストーリーに優先順位をつけるのは顧客の仕事で、ビジネスの観点から優先順位をつけてもらいます。

そうすることで、投資に対して最も価値の高い成果を手に入れることができます。

しかし、開発チームにも果たすべき義務があります。具体的には、アーキテクチャ上のリスクを低減できるストーリーや顧客にとって価値があり、しかもアーキテクチャを検証できるストーリーなどです。

プロジェクト開始時点でのチーム速度はどれくらいかなのかわからないため、最初はある程度推測する必要があります。

その後、チームベロシティはイテレーションを3、4回こなせばだんだん落ちついていき、チームの開発速度も検討がつくようになります。

チームベロシティは以下のように求めます。

チームベロシティ＝完了させたストーリーポイントの合計 / イテレーション数

プロジェクトの完了期日に対する作戦として、「期日固定」と「フィーチャセット固定」があります。

「期日固定」は、日付を特定して「プロダクトはこの日が来たら何がなんでもリリースします」と宣言する感じです。この作戦の場合、重要なストーリーが新たに見つかった場合、想定的に優先順位が劣るストーリーをスコープから外します。

「フィーチャセット固定」は、中核をなすフィーチャのまとまりに含まれるフィーチャを全て完成させるまでは作業を続け、日程を調整する作戦です。中核をなすフィーチャーセットを確実に揃えるためなら、スコープではなく期日が調整対象になります。

バーンダウンチャートはチームがどれぐらいの速度でストーリーを実装しているかをひと目でわかるようにした図のことです。チームの速度に加えて、この先いつ頃プロジェクトを完了させられそうかの見通しも立てられるようになっています。

バーンダウンチャートの縦軸は残っている作業の総量で、横軸は時間、具体的にはイテレーションを表します。あとはイテレーションごとの残作業量を記録して、図にプロットしていきます。

ここからは本書と関係ないが、自分自身アジャイル計画を始めてみて思ったことは、日々計画とやるべきタスクが明確で常にプロジェクトの進行を見通せることとてもスッキリした気分になります。

今までウォーターフォール開発やアジャイルもどきであったプロジェクトがどう転ぶのかわからないモヤモヤ感が全然ないです。その分、逐一ストーリーの見積もりやメンバー共有、緊急タスクがあった際のストーリーの見直しなど、アジャイル計画を実行するために必要な時間と労力は大きいと感じています。

もちろんその時間と労力をかけるほどの価値を感じており、アジャイル開発を実践できる環境にありがたみを感じています。

アジャイル計画は、ビジネス側と開発チームの両方がプロジェクトを円滑かつ適切に進めていくためにアジャイル開発の中でも特に重要な役割を担っていると思うようになりました。