『アジャイルサムライ』を読んだ

感想

アジャイル開発の具体的な進め方が章立てに沿って書かれた本。4月から本格的なアジャイルで仕事をすることになりそうなので慌てて読んだ。

「アジャイルといえばインセプションデッキ」みたいなイメージがあったけど、別に各プラクティスにこだわらなくてもいいらしい。 いちばん大事なのは顧客に毎週価値あるプロダクトを届けられることで、そのために自分にあった手段を選びましょう、ということが書かれていた。

思い返してみると今まであんまり期間が決まったプロジェクト開発ってやったことないかもしれない。そういう場合には無理にイテレーションでやらずに、カンバンでやるといいと書かれていた。もう少し真面目にTrello使ってみようかな。

ところどころスターウォーズネタ（マスター・センセイ、フォース、遥か彼方の銀河系で…など）が挟まれていて、ニヤリとしながら読み進めることが出来た。というか「Sensei」って海外でも通じるのね…

まとめ

アジャイル入門

価値ある成果を毎週届ける

• 大きな問題は小さく、シンプルにして扱いやすくする
• 本当に大事なことに集中する。
• テスト済みの「動く」ソフトウェアを届ける。
• お客さんからフィードバックをもらう。
• 必要になれば計画を変える。現実を変えない。
• 成果責任を果たす。

アジャイルな計画づくり

• マスターストーリーリスト
  • プロジェクトの TODO リスト。(＝バックログとも呼ばれる)
  • 顧客が実現したいと思うフィーチャ（＝ユーザーストーリー）を載せる。
  • フィーチャに顧客自身が優先順位をつけて、開発チームが見積もることで計画が完成する
• イテレーション
  • 開発期間のこと。
  • 1~2 週間でストーリーを動くソフトウェアに変換していく
• ベロシティ
  • 一回のイテレーションで完了させられるストーリーの量。
  • 実測することで、自分たちのこなせる仕事量が把握できる。

チームをアジャイルにするコツ

• 同じ仕事場で働く
• 顧客に積極的に関わってもらう
  • デモを見て、質問に答え、開発チームにフィードバックをくれる存在
• 人に合わせて役割分担を決める（肩書や役割を気にしない）

アジャイルな顧客とは？

• 何を作るか決める
• 優先順位をつける
• スコープについて決断を下す

アジャイルな方向づけ

インセプションデッキを使って全体像を捉え、具現化させる方法。

• なぜインセプションデッキを作るのか？

  • 自分たちのプロジェクトに対する期待を共有して、認識を合わせる
  • ステークホルダーの判断材料にする

• 我々はなぜここにいるのか？

• エレベーターピッチ
• パッケージデザイン
• やらないことリスト
• 「ご近所さん」を探せ
• 解決案を描く
• 夜も眠れない問題
• 期間を見極める
• 何を諦めるのか
• 何がどれだけ必要か

全体像を捉える

インセプションデッキの前半で、プロジェクトのスコープを明確にする。

• なぜプロジェクトをやるのかを理解している
• よく練られたエレベーターピッチがある
• パッケージデザインがどうなるかを知っている
• スコープの境界が定められている
• 「ご近所さん」と仲良くなろうとしている

我々はなぜここにいるのか？

• お客さんの意図を掴む。
• 必要であれば実際に自分が現場に行ってみる。

エレベーターピッチを作る

• プロダクトを明快にする
• チームの意識を顧客に向かわせる
• 核心を捉える

テンプレート：

- [潜在的なニーズを満たしたり、抱えている課題を解決したり]したい
- [対象顧客]向けの
- [プロダクト名]というプロダクトは、
- [プロダクトのカテゴリ]である。
- これは、[重要な利点、対価に見合う説得力のある理由]ができ、
- [代替手段の最右翼]とは違って
- [差別化の決定的な特徴]が備わっている

パッケージデザインを作る

• 顧客が買う理由を明確にする
• 顧客に訴求する要素を明確にする
• プロダクトの値打ちを明確にする

手順：

1. プロダクトの効能（≠ フィーチャそのもの）をあげる
2. キャッチコピーを決める
3. パッケージをデザインする

やらないことリストを作る

• プロジェクトのスコープを明確にする

やる：
- 検索
- 印刷

やらない：
- オフライン利用

あとで決める：
- 更新

ご近所さんを探す

• プロジェクトに関わりそうな人を明確にする

具現化させる

インセプションデッキの後半で、具体的な解決案とプロジェクトの陣地を決める。

• 技術的な解決案を描く
• リスクを検討する
• プロジェクトの期間を見極める
• 諦めるべきものをはっきりさせる
• プロジェクトに何がどれだけ必要なのかをスポンサーに提示する

解決案を描く

顧客の前で、チーム全員でアーキテクチャ構成図を描く。

• ツール・技術の期待マネジメント
• プロジェクトの境界・スコープを目で確認できる
• リスクを伝えられる

夜も眠れなくなるような問題

プロジェクトのリスクについて腹を割って話し合う。 逆にプロジェクトの成功に何が必要なのかを納得することができる。

例：

- チームが同じ仕事場に居ない
- 顧客を巻き込めない
- 自分の開発環境をコントロールできない

期間を見極める

おおざっぱな予測でもいいから納期を決める。 なるべく短い方が良い。

- 構築　〜3ヶ月
- 受け入れテスト 〜1週間
- トレーニング 〜1週間
- リリース

何を諦めるのかをはっきりさせる（トレードオフスライダー）

プロジェクトに影響を与えるフォースをコントロールする。

• 時間
  • 固定する
• 予算
  • 固定する
• 品質
  • 固定する
• スコープ
  • 動かす！

トレードオフスライダーを使ってフォースの影響を顧客と話し合う。

// どれも最優先はNG.
// 同じメモリが2つ以上あってもNG.

MAX <-|--|--|--|--|-> MIN スコープ
MAX <-|--|--|--|--|-> MIN 予算
MAX <-|--|--|--|--|-> MIN 時間
MAX <-|--|--|--|--|-> MIN 品質
MAX <-|--|--|--|--|-> MIN その他プロジェクトの命運を左右する要素

何がどれだけ必要なのか？

プロジェクトに必要なチーム・期間・費用を説明する。

アジャイルな計画づくり

ユーザーストーリーを集める

• 「文書化」は難しい。小さいインデックスカードに顧客の要望を書くのが丁度いい。
• フィーチャの本質を捉えるキーワードを書き留める程度
• 細かい要求はあとで取り組む直前で分析する
• ユーザーストーリーは E2E になっていると良い
  • UI→ ロジック →DB までが一貫されている

例：

- ユーザーアカウントを作成する
- 新規物件が投稿されたらメーリングリストに通知される
- メーリングリストの購読を停止できる

「よく書けた」ユーザーストーリー

• 他のストーリーに依存しておらず、独立している
• 「松案・竹案・梅案」のように交渉の余地がある
• テストできる

期限切れアカウントでのログイン

- 通常のログインができる
- 期限切れログインはリダイレクトされる
- 適切なエラーメッセージを表示する

• 見積もれる程度の大きさである

ストーリー収集ワークショップ

• 顧客と一緒になって、なるべくたくさんのフィーチャを集める。
• 全てを実装するわけではなく、なるべく多くを議論の机上に乗せるため。

手順：

1. 大きくて見通しの良い部屋を用意する
2. 図をたくさん書く。
   1. ペルソナ
   2. フローチャート
   3. プロトタイプ…などなど
3. 図を辿りなからユーザーストーリーを抽出する
4. 漏れ・ダブリを排除してリストを磨き上げる

見積もる

プロジェクトの概算見積もりは 100%当たらない。 アジャイルでは「何がどれくらいかかったか」を計測して、それをもとに計画を立てる。

• 相対サイズで見積もる

  • ストーリーを互いが互いに対してどれくらいの大きさなのか見積もる。
    • 「おもちゃを作る」は「おもちゃを修理する」の 2 倍くらい
  • 実際にプロジェクトを始めてベロシティを計測する。

• ポイントで見積もる

  • 相対見積もりの単位を扱いやすくする。
    • 1 日、3 日　 → 　 1pt, 3pt

見積もり手法

• 三角測量

  • プロジェクトの代表的なストーリーを大中小それぞれ選出する
  • 残りのストーリーを基準ストーリーとの相対サイズで見積もり、振り分ける

• プランニングポーカー

  • ストーリーそれぞれをメンバー全員で同時に見積もる。
    • 「いっせーの」で 1,3,5 のポイントを同時に出す
  • 議論を重ねて、再度見積もる

現実と向き合う

初回の計画づくり

• ① マスターストーリーリストを作る
  • フィーチャの一覧を載せる
  • 顧客が優先順位をつける
  • 開発チームが見積もる
  • 「リリース」の単位にまとめる
    • ※1〜6 ヶ月でこなせる量に収めておくこと

# マスターストーリーリスト
- 1pt ユーザーを追加する
- 2pt 旅程を印刷する
- 5pt 予定をキャンセルする
…

## リリース1
- ユーザーを追加する
- 旅程を印刷する

## リリース2
- 予定をキャンセルする

• ② プロジェクト規模を見極める
  • 三角測量・プランニングポーカーをもとにプロジェクトがいつ終わるかを見極める
• ③ ベロシティを見積もる
  • 開始時点でのベロシティは推測するしか無い。
  • ベロシティ = 1 イテレーションで完了したストーリー数/イテレーション数
• ④ 期日を仮決めする
  • 期日固定：優先順位の劣るスコープを諦める
  • フィーチャセット固定：期日を諦める

バーンダウンチャート

チームがどれくらいの速度でストーリーを実装しているかがわかる図

アジャイルサムライ P166より

• 縦軸は残っている作業の総量を表す
• 横軸はイテレーション（時間）を表す

アジャイルなプロジェクト運営

イテレーション

1〜2 週間の間に分析・開発・テストを行いストーリーをソフトウェアに変換する。

Step1 分析と設計をする

• 「必要な分を、必要なときに」分析する。
  • 同じ場所で働いているならインデックスカードと会話で事足りることもある。
  • もう少し大きな規模なら、概要をまとめた文章・ストーリーをタスクに分解したリスト・テスト条件の一覧などがあればよい。
  • イテレーション(n)で分析して、イテレーション(n+1)で開発する

アジャイルサムライ P188より

• 複雑なストーリーなら、それ相応に時間にかけるしか無い。
  • フローチャートを書いて、システムの動作・必要な手順を示す
  • ペルソナを作り、どんな人達がどうやって使うかを示す
  • ペーパープロトタイプで色々なデザインを試す
  • 受け入れテストを書く
    • インデックスカードの裏に「このストーリーが完成したことを確認できそうなこと」を3 つ書こう

Step2. 開発する

• 自動テスト・CI/CD・TDD などのプラクティスを徹底する
• イテレーション・ゼロ（はじめのイテレーション）に環境構築をする
  • ソース管理
  • 開発環境・テスト環境
  • ビルド自動化
  • アーキテクチャスパイク
    • ストーリーを 1 つ選んでアーキテクチャの土台にする

Step3. 作業の結果を確認する

• お客さんにデモをしながら、ストーリーの受け入れテスト条件を一つづつチェックする

カンバン

• 運用業務など、プロジェクトの期間が決まっていない場合に使える
  • イテレーションが必要ない。
  • 手が空いたら優先順位の高い作業に着手するだけ
• チームが同時に着手できる作業数（WIP）を定める。
• メリット
  • 差し込みの業務に割り込まれずに済む
  • 1 回のイテレーションに収まらない仕事にそのまま取り組める
  • 期待マネジメントしやすい（一度にやれる仕事は WIP 数まで、と割り切れる）

イテレーションでの意思疎通

イテレーションごとにやるべきミーティング

• 今回のイテレーションの作業に備える（ストーリー計画ミーティング）
• 今回のイテレーションのフィードバックを得る（ショーケース）
• 次回のイテレーションの計画を立てる（イテレーション計画ミーティング）
• 次回のイテレーションで改善できる余地を探す（ミニ振り返り）

ストーリー計画ミーティング

ジャストインタイム分析の結果を確認するミーティング。

• これから取り組むストーリーの準備が整っていることを全員で確かめる
• 顧客と一緒に受け入れテスト条件をレビューする
• 開発チームが見積もりの数値を確認する
• その他必要な調査に漏れがないことを確認する

ショーケース

イテレーション後に顧客に実装したストーリーをデモで見せ、フィードバックを得る。

イテレーション計画ミーティング

次回のイテレーションの作業を計画する。

• チームのベロシティを確認する
• 次に取り掛かるストーリーを整理する
• 次回のイテレーションでチームがコミットメントする作業量を見極める
• バーンダウンチャートでプロジェクトの進捗具合を確認する

ミニ振り返り

10~15 分で「うまくやれたこと」「どうすればもっとうまくやれるか」を話し合う。

デイリースタンドアップ

毎日立って自分のやることをほかのチームメンバーと調整する

• 昨日やったこと
• 今日やること
• チームの開発速度を下げてしまうことがあれば言う

アジャイルなプログラミング

• ユニットテスト
• リファクタリング
  • 技術的負債を貯めない。少しずつ返済していく。
• テスト駆動開発
• 継続的インテグレーション
  • 今すぐリリースできるようにしておく。明日じゃない。