アジャイルサムライを読んだ。--アジャイルな計画作り--

この記事の概要

「アジャイルサムライ」の第三部を読み、自分なりの解釈をまとめたものです。
アジャイルに詳しい方は、認識の誤りやご意見をいただけたらと嬉しいです。

第三部: アジャイルな計画作り

文章化するのは難しい

文章に頼ると発生しうる問題

• 認識の齟齬
• 考慮漏れがあった場合などで下手な推測や誤った前提で進めてしまう
• 顧客が真に欲しいものではなく、仕様書通りのもの実装

＊ フェイストゥフェイスで話すことこそ効果的な方法

文章に頼らない計画を実現する

ユーザストーリーベースで計画を立てる。

ユーザストーリーとは

• 顧客がソフトウェアで実現したいと思っているフィーチャを簡潔にしたもの。
• フィーチャにはありとあらゆる詳細を書くのではなくて、本質をとらえるキーワードを書き留める。
  • ストーリーの段階では検討する時間とエネルギーは節約する。
  • 本当に必要になると確信を持てる時に詳細に突っ込む。

良いユーザストーリーとは

• 他のユーザストーリとは依存しないこと
  • トレードオフの判断をしやすくする
• 交渉の余地があること
  • スケジュールに対する期待値のコントロールをしやすくする
• ビジネスの観点から評価できるものであること
  • テクニカルなワードでの表現を避ける
• 小さいこと
• 見積もりやすいこと
• テストができること
  • 切り口がエンドツーエンドになっていること
  • 顧客に届けるゴールが明確になる
  • 顧客にとって価値のあるものが届けられる

＊ 上記の要素をINVESTと呼ぶ。(Independent, Negotiable, Valueable, Estimatable, Small, Testable)

感覚的な表現が用いられていても良い（サクサク動く）
求める特徴を捉えていることが大事。
抽象的な場合は制約をつける（２秒以内にページが読み込める）

ユーザストーリーテンプレート

1. 誰のためのストーリーで
2. 何をしたいのか
3. 何故したいのか

ストーリー収集ワークショップを開催しよう

• 顧客と開発チームが一緒になってソフトウェアのユーザストーリをかく。
• 目的は多くの事柄を議論して、全体像を掴むこと。
• その話し合いではやらないことリストを用いるのも良い。

1. 多くて見通しの良い部屋でやる
2. 図をたくさん書く
   • ペルソナ
   • フローチャート
   • シナリオ
   • システム概要図
   • プロセスフロー
   • コンセプトデザイン
   • 絵コンテ
   • ペーパプロトタイプ
   • etc
3. ユーザストーリをたくさん書く
4. ブレインストリーミングする
5. リストを磨き上げる

• どんなふうに動かなければいけないのか、どんなふうになって欲しいのか、イメージしやすくすることを意識して進める。
• 大きすぎるストーリーにはその上位概念であるエピックを使っても良い。
• ストーリに優先順位をつけて、プロジェクトがうあくいくために必要なものの見落としがないかを確認する。
• もれなくダブりがないかグルーピングしたり、本当に価値があるか、シンプルでわかりやすいかを確認する。

見積もりは当てずっぽう

• 見積もりに求められていること
  • 与えられたスケジュールとリソースでやり遂げられるかがわかること
    • 今後の計画がたてられる

なので

• 当てずっぽうだという前提を踏まえた見積もりをすること
• ソフトウェア開発の複雑さを加味すること
• 純粋に大きさを測ること
• 手早く、気軽に、シンプルに見積もること

そのため、タスクを時間で見積もるのではなくて、他のタスクと相対的なサイズで見積もる

見積もり技法

• 三角測量
  • 大中小それぞれのタスクを決めて、他のタスクを相対的に比較してグルーピングする。
  • 論理的なグルーピングを行う
  • エンドツーエンドにするのが良い
• 実際のストーリのサイズと明らかに違うことがわかったら再見積もりする。
• 見積もりの検討がつかない場合は見積もれるまで実験・検証してみる（スパイク）

プランニングポーカー

• タスクを見積もる際に、複数の開発者通しで、どのくらいの重みがあるかポイントの数値で出し合う。
• それぞれの数値の根拠を話し合って、それぞれが想像している実装方法・設計の共通認識を持つ。
• より正しそうな見積もりが出せると同時により効率的な開発方針が見えてくる。

チームのベロシティーを理解する

• チームがユーザストーリを動くソフトウェアに変換する速度をベロシティと呼ぶ。
• ベロシティはチームの生産性の計測と、プロジェクトの完了日の見通しを立てるために使われる。
• チームが１回のイテレーションでこなせるポイントを把握する。

スコープを柔軟にする

• スプリントの後期であっても顧客の要求の変更には柔軟に対応する、
• そのためにスコープの柔軟性とストーリの優先順位づけでトレードオフする。
• アジャイルでは期限を守る。

初回のアジャイル

マスターストーリリストを作る

• １−６ヶ月でこなせる仕事の範囲を治めるリストを作成する。
• 顧客が順位づけして、開発チームが見積もる。そのための土台となる。
• 何がスコープに収まりそうで、何が溢れそうなのか期待値をマネジメントするために使われる。
• ストーリは最小で、市場価値があるものを編成してリリースする。

プロジェクト規模を見極める

• マスターストーリリストの規模を把握する。

優先順位をつける

• ストーリの優先順位をつけるのは顧客だが、開発は効率的に片付けることができるストーリのリリース順番を提案する。

チームのベロシティを見積もる

• アジャイル開発の見積もりがうまくいくのは過去の自分たちの成果を踏まえた計画ができること。
• イテレーションを3−４回行ってチームの開発速度の見当をつける。
• ストーリの完了の定義がコーディングはもちろん、テストや設計であることを踏まえた上でベロシティを計測する。

期日をかり決めする

• 期待値をマネジメントするために期日厳守またはフィーチャ厳守で開発を進める。
• 期日厳守の場合はスコープに柔軟性を持たせる。
• フィーチャ厳守の場合は期日に柔軟性を持たせる。

インセプションデッキの作成に関して

プロジェクトを途中からアジャイルにしていく場合は無理にインセプションデッキを作る必要はない。
しかし以下の質問には全てのメンバーが答えられるようにする

1. このプロジェクトにいるのは何故か
2. 成し遂げようとしていることは何か
3. 顧客はだれか
4. 解決すべき主要な課題は何か
5. 最終判断を下すのは誰か

チームのベロシティを出す

バーンダウンチャート

チームがどのくらいの速度で実装できているのかを一眼でわかるようにするための図
以下が可視化できるようになる。

• どれだけの仕事を完了させたのか
• どれだけの仕事が残っているのか
• チームのベロシティ
• いつ頃全てを完了させられそうなのか

バーンダウンチャートは顧客に定期的に確認してもらって、プロジェクトの期待値のマネジメントを誠実に行うこと。

バーダウンチャートに異変が生じたら

• ステークホルダーに共有
• 彼らの下した決断がプロジェクトにどのような影響を与えたのかをわかりやすく示す