アジャイルサムライ書評

アジャイルサムライの書評です。
アジャイル関連で個別に記述した記事と重複する箇所もあるかと思います。

■各章の概要

アジャイル入門
- ざっくり分かるアジャイル開発

　　アジャイルな開発は短期間でのイテレーションを軸に、
　　継続して動作する成果物を提供する。
　　それを実現するためには、アジャイルな計画を行う。
　　システムで実現する機能をユーザーストーリーとしてまとめ、
　　そのユーザーストーリーを列挙してマスターストーリーを作成。
　　各ユーザーストーリーに難度と優先度を設定することで
　　各イテレーションで行うべき作業の選定や、
　　1イテレーションでどの程度の課題をこなすことが出来るか
　　（ベロシティ）を見積もることが出来る。
　　
　　補足として、アジャイルな開発が必要となるのには主に以下の3つの理由がある。
　　開発開始時には必要な仕様は出揃わない。
　　要求は常に変化する。
　　やるべきことは時間・予算の制約よりも大きい。
　　どれもある程度の開発経験のある技術者ならうなずける内容です。

- アジャイルチームのご紹介

　　アジャイルなチームは従来の役職や自分の担当箇所に固執するような体制とことなり、
　　明確な役割を持たずどんな仕事もメンバー全員でこなしていく姿勢が重要となる。
　　
　　また、顧客もチームメンバーとみなし可能な限り近い距離で連携することで
　　仕様の齟齬を減らしプロジェクトの真実を常に知ってもらうことが出来るために
　　リスクが隠蔽されるような状況を回避出来る。

アジャイルな方向づけ

- みんなをバスに乗せる

　　プロジェクトの目的を共有したり、問題を洗い出すために
　　開始時にはインセプションデッキを利用する。
　　インセプションデッキの詳細に関しては以下に続く。

- インセプションデッキの各項目について

　　『我々はなぜここにいるのか』
　　対象システムの利用者がどのようにシステムを利用するのか
　　可能なら直接現場を見て理解すること。
　　
　　『エレベーターピッチを作る』
　　エレベーターピッチのテンプレートなどを利用してシンプルで分かりやすく対象システムを説明出来るようにする。
　　[課題を解決]したい
　　[対象]向けの
　　[プロダクト名]というプロジェクトは
　　[カテゴリー]です
　　これは[利点]でき
　　[代替]と違って
　　[特長]が備わっている
　　
　　『パッケージデザインを作る』
　　ビジョンを共有したり、外へのアピールに使えたりする。
　　パッケージデザインはプロダクト名、イメージ画像、キャッチコピー、特長3つなどを
　　1ページ程度にまとめるのがよい
　　ー
　　『やらないことリストを作る』
　　やることとやらないことと後でやることをいつでも分かるように管理する。
　　
　　『「ご近所さん」を探せ』
　　プロジェクトに関わる関係者を早めに想定し、コミュニケーションをとっておく。
　　
　　『解決案を描く』
　　アーキテクチャーの検討を行い、開発に必要となるメンバーや
　　コスト（ソフトやサーバー等）を見積もる。
　　
　　『夜も眠れなくなる問題は何だろう？』
　　対応を必要とするリストを重視し、対応しようがないリスクは除外する。
　　
　　『何を諦めるかはっきりさせる』
　　トレードオフスライダーを用いて、各要素の優先度決めを行う。
　　主要素はスコープ、予算、時間、品質であり、基本はスコープを減らすことで
　　全体の工数を調整する。
　　当書籍いわくスコープ、予算、時間、品質は荒ぶる四天王だそうだｗ
　　
　　予算「スコープがやられたようだな…」
　　時間「ククク…奴は我ら荒ぶる四天王の中でも最弱…」
　　品質「アジャイルごときに負けるとは荒ぶる四天王の面汚しよ…」

　　『何がどれだけ必要なのか』
　　人員やソフト、ハード等の必要なコストを洗い出す。

アジャイルな計画づくり
- ユーザーストーリーを集める

　　ユーザーストーリーはINVESTを意識して作成すること。

独立している（Independent）
交渉の余地がある（Negotiable）
価値のある（Valuable）
見積もれる（Estimable）
小さい（Small）
テスト出来る（Testable）

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

　　複雑なストーリの作成が必要になった場合には以下のような手法を利用する。

ペルソナ
フローチャート
シナリオ
システム概要
プロセスフロー
コンセプトデザイン
絵コンテ
ペーパープロトタイプ
独自手法

- 見積　当てずっぽうの扇

　　初期から厳密な見積もりをすることは不可能。
　　数イテーレーションを経て、過去の作業から
　　チームのベロシティを割り出し、それを元に相対的に見積もりを行う。
　　ベロシティは難易度に応じたポイントで計算。

- アジャイルな計画　現実と向き合う

　　イテレーション、ベロシティを用いた見積を行い
　　全体の工程をバーンダウンチャートで管理する。
　　バーンダウンチャートは残課題のポイント総計を時系列にグラフ化する表。
　　この表で、残作業の量や各イテレーションでのベロシティが分かりやすく管理出来る。

アジャイルなプロジェクト運営
- イテレーションの運営

　　ドキュメントは必要最低限。
　　1イテレーションは1-2週間。
　　分析-実装-テストを繰り返す。
　　
　　分析時はユーザーストーリーに概要、画面、テスト条件などを追加する。
　　また、ユーザーストーリーを実際の作業単位ごとのタスクに分割する。
　　
　　実装時は自動テストを導入し、いつでもリファクタリングや
　　改修＋退行テストが容易に行えるようにする。
　　結合環境は継続ビルドを行うことでシステムを常に健全な状態に保つ。
　　

- アジャイルな意思疎通の作戦

　　様々な手法があるが、メンバーにあった方法で。
　　毎日スタンドアップミーティングで意思共有。
　　イテレーションごとに振り返りを行い、次イテレーションに活かす。
　　

- 現場の状況の可視化

　　使用する業務用後の統一。同じ言葉で話せるようにする。
　　変数などの統一にも貢献。
　　貼り物を増やして、重要な情報をいつでも共有できるようにする。
　　→対面で開発できない場合は似たような機能をもつソフトの導入を検討

アジャイルなプログラミング
- ユニットテスト

　　ユニットテストの自動化で退行テストの工数を減らす。
　　そのことでリファクタリングのリスクを減らし、コードを高品質に保つ。
　　テスト駆動開発でシンプルな設計、要件漏れを防ぐ。

- 継続的インテグレーション

　　バージョン管理システムとビルド自動化とビルドエージェントの導入により
　　継続的に結合環境を提供。
　　結合以降の問題を早期に発見してリスクを軽減。
　　また、いつでもリリース可能な状態にできる。
　　
■感想
書評通り非常に読みやすく、表現や図表での説明などとっつきやすく
退屈させない作りなのでワクワクしながら最後まで読むことが出来ました。
注意点としては既にアジャイル開発、XP、スクラムについて熟知している方
にはあまり参考にならないと思います。
逆にアジャイルって何？とか、これからアジャイルを導入したい、という人には
最高な書籍です。