RADICODE BLOG 
◀︎其の1はこちら
◀︎其の2はこちら
◀︎其の3はこちら
◀︎其の4はこちら
◀︎其の5はこちら
◀︎其の6はこちら
◀︎其の7はこちら
◀︎其の8はこちら
◀︎其の9はこちら
◀︎其の10はこちら
◀︎其の11はこちら
◀︎其の12はこちら
こんにちは！
ラジコード編集部です 😊
アジャイルサムライを読む連載記事その8です！😃
前回は第3部 アジャイルな計画づくり の「第7章：見積もり：当てずっぽうの扇」で、見積もりは相対的に判断するために基準を決め、複数人で話し合うことが大事ということが学習できました。
それでは「第8章 アジャイルな計画づくり：現実と向きあう」を読んでいきましょう。
よろしくお願いします！🙋♂️
本シリーズは「アジャイルサムライ − 達人開発者への道」を1〜5部を1~2記事に分け要点を解説していくシリーズです。全13記事を予定しています。
もくじ
第8章：アジャイルな計画づくり：現実と向きあう
プロジェクトが計画通りに進まないというのはよくある事です。
変化と向き合う戦略がないと、プロジェクトに翻弄されるがままになります。
本章は、信頼のおける計画の立て方と、チームがコミットメントしたことをやり遂げるための方法を学びます。
チームメンバーの入れ替わり、期日の前倒し、変わり続ける要求。
こういうことに立ち向かうには次の4つの基準を満たす計画の立て方を身につける必要があります。
- 顧客にとって価値ある成果を届けられる計画
- 分かりやすくありのままを伝える、誠実な計画
- 約束したことを守り続けられる計画
- 必要に応じて変更できる計画
次に変化に向き合うためのアジャイルな計画作りを学びましょう。
アジャイルな計画づくりとは、チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすることです。
- 「マスターストーリーリスト」
プロジェクトでこなすべきToDoをまとめたもの - 「ベロシティ」
チームの生産性の計測とプロジェクト完了日の見通しを立てるのに使う - 「イテレーション」
一連の工程を短期間（1週間〜2週間）で繰り返す開発サイクル
イテレーション数 = 作業量の合計 / チームの予想ベロシティ
プロジェクト完了日の大まかん見通しは上記で立てることができます。
ただ、プロジェクト初期での見通しの実現可能性は未知数です。
進捗が早ければスケジュールを前倒しにする。
逆に進捗が遅れている、やるべきことが多すぎる場合は、やることを減らすべきです。
最初に立てた計画にこだわらず、計画を変えていきましょう。
開発中に新しい機能が必要になった。あれもこれも必要という気になってくる。
そういう時は、新しいストーリーを追加するときは必ずどれかひとつ既存のストーリーを削りましょう。
このルールを実践できると、開発側は顧客に要求変更の機会を提供しつつ、スコープをプロジェクトで作業できる範囲内に留めておけます。
ただ、どんな変更も可能なわけではありません。
追加する分と同等サイズのストーリーを削れないとなると期日を伸ばし、追加費用がかかることも正直に伝える必要があります。
実現可能な状態を保ちつづけるには、自身とお客さんがこの考え方を理解する必要があります。
初回の計画づくり
まずはしっかりしたリストを作ることから始めましょう
- マスターストーリーリストを作る
顧客がソフトウェアで実現したいものを載せ、優先順位をつけて見積もりを行い、計画の土台となります。
先々状況がどうなっているか分からないため、1ヶ月〜6ヶ月程度の期間でこなせる範囲に収めましょう。
そしてリリースを定義します。1つのリリースは本番環境に反映する価値があるように編成しましょう。
- プロジェクトの規模を見極める
前回でストーリーのサイズを見積もる技法を紹介しました。
それを踏まえて、マスターストーリーリストからプロジェクトの規模を把握していきましょう。
- 優先順位をつける
一番重要なストーリーから順番に実装していきましょう。
顧客にビジネスの観点から優先順位づけしてもらえば、最も価値の高い成果を得ることができます。
開発チームはリスクを低減できるストーリーがあれば先に片付けることを提案すべきです。
- チームのベロシティを見積もる
現実的なベロシティの求め方は以下の通りです。
チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーション数
イテレーションを何回かこなせば見当がつくようになりますが、最初は果敢な見積もりにしすぎないのが肝心です。
過度な期待を抱かせず、見積もりは推測でしかないことを意識してもらうようにしましょう。
- 期日を仮決めする
完了期日への期待をマネジメントするには2つ作成があります。
「期日固定」「フィーチャセット固定」です。
期日固定は、「プロダクトはこの日が来たら必ずリリース」するということです。
開発途中に重要なストーリーが見つかったら、同じサイズで優先順位が劣るものをスコープから外して調整を行います。
フィーチャセット固定は、「中核の機能のまとまりをすべて完成させるまで作業を続ける」ことです。
い中核をなすフィーチャセットが明確になります。期日についてのリスクはお客さんやスポンサーに判断してもらいましょう。
途中からアジャイルにする場合、今どんな状況かを把握しよう。
- 今やっている開発がうまくいってない
- とにかく早く、何か成果をあげないといけない
今うまくいかない要因がチームの方向性に関連するものなら、インセプションデッキを作りましょう。
- このプロジェクトにいるのはなぜ？
- 成し遂げようとしていることは何？
- 顧客は誰？
- 解決すべき主な課題は何？
- 最終判断を下すのは誰？
これらの質問にはチームメンバー全員が答えられるようにしよう。
とにかく早く成果をあげる場合は、今のプロジェクト計画を捨てましょう。
マスターストーリーリストを作り、リストの規模を見極め、フィーチャの優先順位をつける。
そして最小限の機能でいいので、お客さんのところへフィーチャを届けましょう。
毎週必ず、価値ある成果をあげることで、成果をあげられる存在だとお客さんに示していくと状況も変わっていくはずです。
以上「第3部アジャイルな計画づくり：第8章 アジャイルな計画作り：現実と向き合う」の解説でした。
マスターストーリーリストを作り、リストの規模を見極め、フィーチャの優先順位決められるようにする事で状況に合わせて計画変更に対応できるということが分かりましたね。
次回は「第4部：アジャイルなプロジェクト運営」を読んでいきましょう😌
- アジャイル宣言の背後にある原則
- アジャイルソフトウェア開発宣言
- アジャイルサムライ − 達人開発者への道
オーム社 (2011/7/16)
著者：Jonathan Rasmusson 著／西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳
月額固定・定額制でアジャイル開発を提供する「サブスクエンジニア」サービスを提供しています。よろしければご覧ください！
