アジャイルサムライ−達人開発者への道−は、アジャイル開発に関する書籍の中で、いろいろな面で群を抜く書籍である。
そんなアジャイルサムライを一気に要約してみたので共有したい。
価値ある成果を毎週届けるために
１大きな問題は小さくする ２本当に大事なことに集中して、それ以外のことは忘れる ３ちゃんと動くソフトウェアを届ける ４フィードバックを求める ５必要とあらば進路を変える ６成果責任を果たす
アジャイル開発の原則
・顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する ・動くソフトウェアこそが進捗の最も重要な尺度 ・顧客と日々一緒に働く ・最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出される ・意欲に満ちた人々を集めて構成。環境と支援を与え、仕事が完了するまで彼らを信頼する。 ・情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること。 ・要求の変更はたとえ開発の後期であっても歓迎する。変化を味方につけることによって、お客様の競争力を引き上げます。 ・シンプルさが本質です。（機能の２０％が８０％の価値を生み出す） ・チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する ・技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます
アジャイルな計画づくりが上手く良く理由
・マスターストーリーリスト（プロジェクトのToDoリスト。顧客が実現したい機能（ユーザーストーリー）のリスト） ・ベロシティ（１回のイテレーションで完了させられるストーリーの量）を測る ・スコープを柔軟にしておく
ソフトウェア開発の３つの真実
・プロジェクトの開始時点に、すべての要求を集めることはできない ・集めたところで、要求はどれも必ずといっていいほど変わる ・やるべきことはいつだって、与えられた時間と資金よりも多い
チームをアジャイルにするためのコツ
・同じ仕事場で働く ・積極的に深くかかわる顧客の存在 ・自己組織化 ・成果責任と権限移譲 ・職能横断型チーム
ドラッカー風エクササイズ（プロジェクト開始時点で行う）
・自分は何が得意なのか？ ・自分はどうやって貢献するつもりか？ ・自分が大切に思う価値観は何か？ ・チームメンバーは自分にどんな成果を期待してると思うか？
チームメンバーを探すコツ
・ゼネラリスト ・曖昧な状況に抵抗がない人 ・我をはらないチームプレイヤー
プロジェクト開始の注意点
・手強い質問をする インセプションデッキ １我々はなぜここにいるのか？ ２３０秒以内にプロジェクトのアピールができるか？(エレベーターピッチ) ３パッケージデザインを作る ４やらないことリストを作る（やる、やらない、あとでやる） ５プロジェクトの関係者を探す ６解決案を描く（概要レベルのアーキテクチャ設計図） ７夜も眠れなくなるような問題は何か？ ８期間を見極める ９何を諦めるのかをはっきりさせる １０何がどれだけ必要なのか（期間と費用）
・エレベーターピッチのテンプレート ・[潜在的なニーズを満たしたり]したい ・[対象顧客]向けの ・[プロダクト名]というプロダクトは ・[プロダクトの具体]ある。 ・これは[重要な利点、対価に見合う説得力のある理由]ができ、 ・[代替手段の最右翼]とは違って、 ・[差別化の決定的な特徴]が備わっている。 例 建設現場の作業を把握したい 現場責任者向けの CSWPというプロダクトは 危険作業許可証発行システムである これは作業許可証を申請・追跡・監査することができ 現行の紙ベースのシステムとは違って、 ウェブ経由で、いつでもどこからでも利用できる機能が備わっている
・トレードオフスライダー 時間、予算、品質、スコープ 変えるべきはスコープ
よく書けているユーザーストーリー INVEST
Independent 独立している Negotiable 交渉の余地がある Valuable 価値のある（技術よりではなくメリットを明確に） Estimatable 見積もれる（短い期間なら精度が上がる） Small 小さい Testable テストできる
ユーザーストーリーのテンプレート
＜ユーザーの種類＞として ＜達成したいゴール＞をしたい なぜなら＜理由＞だからだ （誰のためのストーリーで、何をしたいのか、なぜそうしたいのか）
見積り
・条件 今後の予定を立てられる 見積りは当てずっぽうだという前提を踏まえている ソフトウェア開発の複雑さを認めている ・ストーリーそれぞれを互いに相対的なサイズで見積もる ・数値の単位をポイントにし、それをもとにして進捗を追跡する
アジャイルな計画づくり
・アジャイルな計画づくりとは、チームの開発速度を計測して、その速度をもとに完了時期を見通せるようにする ・４つの基準 １顧客にとって価値ある成果を届けられる計画 ２わかりやすくありのままを伝える、誠実な計画 ３約束したことを守り続けられる計画 ４必要に応じて変更できる計画 ・イテレーション数＝作業量の合計／チームの予想ベロシティ ・ステップ １マスターストーリーリストを作る ２プロジェクト規模を見極める ３優先順位をつける ４チームのベロシティを見積もる ５期日を仮決めする ・バーンダウンチャート 縦軸：残っている作業量 横軸：イテレーション 次の４つが明確になる ・どれだけ仕事を完了させたのか ・どれだけ仕事が残っているのか ・チームのベロシティ ・いつ頃すべてを完了させられそうか
アジャイルなプロジェクト運営
３のステップ １分析して設計する（作業の段取りをする） ・ジャストインタイムの分析「必要な分だけを、必要なときに」 ・まずはフローチャートを作る ・ペルソナをつくる（ユーザーがどんな人で、どんなことをしようとするのか） ・ペーパープロトタイプをどんどん作る ・受入れテストを書いて、ストーリーの満足条件を定義 ２開発する（実際に作業する） ・自動化されたテストを書く。 ・設計を継続的に発展させていき、改善し続ける。 ・ちゃんと動くソフトウェアであり続けるために、コードを継続的にインテグレーションする ・顧客がシステムについて語る言葉にあわせてコードを書く。 イテレーション・ゼロ（ソースコード管理、ビルドの自動化、開発環境やテスト環境、おまけ） ３テストする（作業の結果を確認する）
イテレーションで行うこと
１今回のイテレーションの作業に備える ２今回のイテレーションのフィードバックを得る ３次回のイテレーション計画をたてる ４次回のイテレーションで改善できる余地を探す
デイリースタンドアップ
・昨日、世界をどう変えたか ・今日、世界をどう変えるか ・どんな難問が行く手を阻んでいるか
アジャイルなプログラミング
問答無用で実施すべきプラクティス ・ユニットテスト ・リファクタリング ・テスト駆動開発（TDD） ・継続的インテグレーション
テストコードを書く利点
・素早いフィードバックが得られる ・極めて低コストにリグレッションテストを実行できる ・デバック時間を大幅に削減できる ・自身をもってデプロイできる
バグを修正する前に、失敗するテストを書く
・バグの本質を理解したことを示せる ・自信をもってバグを修正したといえる ・君のプログラムに同じバグが二度と現れないことを保証できる
テスト駆動開発
１レッド：失敗するユニットテストを書く ２グリーン：テストに成功するコードを書く ３リファクタリング：実装を見直し、明瞭でわかりやすいコードにする
要約というより、要点の箇条書き？
面白く、一気に読めちゃってイメージに残る良書なので、気になる方はポチることをおすすめします。
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (257件) を見る
ほらあなより愛をこめて たぬきち
