【読書】アジャイルサムライ 達人開発者への道 / Jonathan Rasmusson
入門
「価値ある成果を毎週届ける」
大きな問題は小さく
本当に大事なことに集中して、それ以外のことは忘れる
ちゃんと動くソフトウェアを届ける
フィードバックを求める
必要とあらば進路を変える
成果責任を果たす（＋期待をマネジメントする）
「マスターストーリーリスト(TODOリスト)」
概要、優先順位、見積 → 土台
ベロシティ（１回のイテレーションでの量）を実測
スコープを柔軟にしておく（開発者は顧客にありのままを伝える）
「完了」の定義
リリースに関するあらゆる作業を完了させる
「３つ」の真実
プロジェクトの開始時に全ての要求を集めることはできない
集めたところで、要求はどれも必ずといっていいほど変わる
やるべきことはいつだって、与えられた時間と資金よりも多い
「やり方はたった１つではない」
原理原則、プラクティス＋自分の頭で考えること
「アジャイルなチーム」
役割分担はない（全員が何でもやる）
開発工程が連続的
同じロケーション
顧客に積極的に参加してもらう（アジャイルな顧客）
自己組織化（当事者意識、肩書きや役割を気にしない、自分から動く）
チームメンバー（ゼネラリスト、曖昧な状況に抵抗がない、我を張らない）
方向付け
「プロジェクトがダメにならないために」
ゴールやビジョン、プロジェクトの状況や背景など話し合っておく
ステークホルダーにプロジェクトを続けるかどうか判断するための情報を提供する
「インセプションデッキ」
我々はなぜここにいるのか？（顧客は？プロジェクトが始まった理由は？）
エレベーターピッチを考える（３０秒以内、２センテンスでプロジェクトを）
パッケージデザインを作る
やらないリストを作る
ご近所さんを探す
解決案を描く（概要レベルのアーキテクチャ設計図）
夜も眠れなくなるような問題は？（どう最悪の事態を避けるか、被害を抑えるか）
期間を見極める
何を諦めるのかはっきりさせる（期間、スコープ、予算、品質）
何がどれだけ必要か？
計画
「文書化」の難しさ
変化に対処できない
顧客の欲しいものではなく、仕様に合わせて作ることになる
下手な推測や誤った前提を招き寄せる
多くの時間を無駄にする
「ユーザーストーリー」
あらゆる詳細を聞き出すこと＜本質を捉えること
顧客にとって何かしらの価値が書かれていること
「よくできているユーザーストーリー」とは？
お客さんがワクワクするようなストーリー
独立している
交渉の余地
テストできる
小さい（見積れる）
誰のため 何をしたいのか？ なぜしたいのか？
「ストーリー収集ワークショップ」
大きくて見通しの良い部屋
図をたくさん描く
ユーザーストーリーをたくさん書く
その他もろもろをブレインストーミング
リストを磨き上げる
「アジャイルな計画」
顧客にとって価値ある成果を届けられる計画
分かりやすくありのままを伝える、誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画
開発速度を計測し、完了時期を見通せる
「計画づくり」
マスターストーリーリストを作る
プロジェクト規模を見極める
優先順位
チームのベロシティを見積もる
期日を仮決め
運営
「イテレーション」の進め方
必要な分を必要なときに分析する
必要な分だけ、必要なときに掘り下げて分析する（フローチャート、ペルソナ、ペーパープロト）
開発（ソースコード管理、ビルド自動化、開発環境テスト環境）
テスト（だいたい動いていることを確認、できる限り自動化）
「イテレーション」でやるべきこと
今回のストーリー計画ミーティング
ショーケース（→フェードバック）
次回のイテレーション計画ミーティング
ミニ振り返り
デイリースタンドアップ
プログラミング
アジャイルソフトウェア開発の１２の原則
１ 顧客満足最優先、価値のあるものを早く継続的に提供
２ 要求の変化は歓迎、変化を味方につけてお客さんの競争力を引き上げる
３ 動くソフトウェアを２−３週間の短い時間間隔で
４ ビジネス側の人と開発者は日々一緒に
５ 意欲に満ちた人を集め、環境と支援を与え、無地終わるまで信頼
６ フェイストウフェイス
７ 動くソフトウェアこそが進捗の最も重要な尺度
８ 持続可能、一定のペースで継続的に
９ 技術的卓越性と優れた設計に対する不断の注意で機敏さを高める
１０ シンプルさ（無駄なく作れる量を最大限にすること）
１１ 最良のアーキテクチャ、要求、設計は自己組織的なチームから
１２ 定期的に振り返り、自分たちのやり方を最適に調整
