アジャイルサムライ
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (257件) を見る
詳細目次 日本の読者の皆さんへ 謝辞 お目にかかれて光栄です 本書の読み方 からかってるわけじゃあないんだよ 本書のオンラインリソース 第I部 「アジャイル」入門 第1章 ざっくりわかるアジャイル開発 1.1 価値ある成果を毎週届ける 1.2 アジャイルな計画づくりがうまくいく理由 1.3 「完了」とは完了のことだ 1.4 3つの真実 やり方がたった1つなんてことはないんだ！ 用語と言葉づかいについて少し 次章予告 第2章 アジャイルチームのご紹介 2.1 アジャイルなプロジェクトはどこが違うのか 2.2 チームをアジャイルにするためのコツ 同じ仕事場で働く 積極的に深くかかわる顧客の存在 自己組織化 成果責任と権限委譲 職能横断型チーム 2.3 よくある役割分担 アジャイルな顧客 開発チーム 2.4 チームメンバーを探すコツ ゼネラリスト 曖昧な状況に抵抗がない人 我を張らないチームプレイヤー 次章予告 第II部 アジャイルな方向づけ 第3章 みんなをバスに乗せる 3.1 プロジェクトがだめになるのはなぜか 3.2 手ごわい質問をする 3.3 インセプションデッキのご紹介 3.4 インセプションデッキの仕組み 3.5 インセプションデッキの課題一覧 第4章 全体像を捉える 4.1 我われはなぜここにいるのか？ 自分自身が現場で確かめる 「司令官の意図」をつかむ 4.2 エレベーターピッチを作る エレベーターピッチのテンプレート 4.3 パッケージデザインを作る 進め方 4.4 やらないことリストを作る うまくやるには 4.5 「ご近所さん」を探せ 大規模プロジェクトでやらかした大失敗 進め方 次章予告 第5章 具現化させる 5.1 解決案を描く 進め方 5.2 夜も眠れなくなるような問題は何だろう？ リスクを話し合うのは良いことだ チームにとって取り組む値打ちのあるリスクを見極める 5.3 期間を見極める 小さく考える プロジェクトの長さへの期待をマネジメントする 5.4 何を諦めるのかをはっきりさせる 試験 荒ぶる四天王 トレードオフ・スライダー 期日と予算を守るだけでは十分ではないのだ 5.5 何がどれだけ必要なのか 君の「Aチーム」を編成する 最終判断を下すのは誰か？ コストがどれぐらいかを見積もる 最後のスライドを仕上げる インセプションデッキのまとめ 次章予告 第III部 アジャイルな計画づくり 第6章 ユーザーストーリーを集める 6.1 文書化の難しさ もっと文書を増やしたらいいんじゃない？ 6.2 そこでユーザーストーリーですよ 6.3 よく書けているユーザーストーリーとは ビッグウェイブ・デイブのサーフィンショップへようこそ 6.4 ストーリー収集ワークショップを開催しよう ステップ1：大きくて見通しのよい部屋を用意する ステップ2：図をたくさん描く ステップ3：ユーザーストーリーをたくさん書く ステップ4：その他もろもろをブレインストーミング ステップ5：リストを磨きあげる 次章予告 第7章 見積り：当てずっぽうの奥義 7.1 概算見積りの問題 7.2 ピンチをチャンスに 相対サイズで見積もる ポイントで見積もる 7.3 見積り技法 三角測量 プランニングポーカー 次章予告 第8章 アジャイルな計画づくり：現実と向きあう 8.1 固定された計画の問題 8.2 アジャイルな計画づくり 8.3 スコープを柔軟に 8.4 初回の計画づくり ステップ1：マスターストーリーリストを作る ステップ2：プロジェクト規模を見極める ステップ3：優先順位をつける ステップ4：チームのベロシティを見積もる ステップ5：期日を仮決めする 8.5 バーンダウンチャート バーンアップチャート 8.6 プロジェクトを途中からアジャイルにしていく 8.7 現場で実践する シナリオその1：お客さんが新しい要求を発見したら シナリオその2：思っていたほどは速く進んでないとき シナリオその3：大切なチームメンバーがいなくなったら シナリオその4：時間が足りなくなったら 次章予告 第IV部 アジャイルなプロジェクト運営 第9章 イテレーションの運営：実現させる 9.1 価値ある成果を毎週届ける 9.2 アジャイルなイテレーション 9.3 【急募】アジャイルチーム【切実】 9.4 ステップ1：分析と設計：作業の段取りをする 9.5 ステップ2：開発：作業する イテレーション・ゼロ 9.6 ステップ3：テスト：作業の結果を確認する 9.7 カンバン 次章予告 第10章 アジャイルな意思疎通の作戦 10.1 イテレーションでやるべき4つのこと 10.2 ストーリー計画ミーティング 10.3 ショーケース 10.4 イテレーション計画ミーティング 10.5 ミニふりかえり 10.6 デイリースタンドアップ 10.7 自分たちに合った手段を選ぼう シナリオ 1：完成してないストーリー シナリオ 2：デイリースタンドアップの価値 シナリオ3：何も価値を生み出せなかったイテレーション 次章予告 第11章 現場の状況を目に見えるようにする 11.1 これは……荒れる！ 経営陣にちゃんと状況を説明する 11.2 貼りものの作り方 11.3 チームの意思を明確にする 11.4 プロジェクトで使う言葉を共有する 11.5 バグを監視する 次章予告 第V部 アジャイルなプログラミング 第12章 ユニットテスト：動くことがわかる 12.1 ラスベガスへようこそ！ 12.2 はじめてのユニットテスト もっと学ぶには 次章予告 第13章 リファクタリング：技術的負債の返済 13.1 どうしてこうなった 13.2 技術的負債 13.3 リファクタリングで技術的負債を返済する どんどんリファクタリングする――そしてそれを続ける もっと学ぶには 次章予告 第14章 テスト駆動開発 14.1 テストを先に書く 一体なにが起きたのか？ 14.2 テストを使って複雑さに立ち向かう もっと学ぶには 次章予告 第15章 継続的インテグレーション：リリースに備える 15.1 ショータイム シナリオ1：一大事 シナリオ2：日常茶飯事 15.2 リリースに備える文化 15.3 継続的インテグレーションとは 15.4 どうすればうまくいくのか？ 15.5 チェックイン手順を習慣づける 15.6 ビルドを自動化する 15.7 作業単位を小さくする もっと学ぶには？ 以上だ、諸君！ 15.8 この先どこへ向かえばいいのか？ 最後に アジャイルであるかなんて気にしない 第VI部 付録 付録A アジャイルソフトウェア開発の原則 A.1 アジャイルソフトウェア開発宣言 A.2 アジャイルソフトウェア開発の12の原則 付録B オンラインリソース 付録C 参考資料 監訳者あとがき 索引 著者・監訳者・訳者について
つまり、あれだ、アジャイルというのは「とにかく実践的に、短い期間で、お客様の目に見える形で成果をあげる開発手法」
ってことでおｋでしょうか？
まぁ、なんだ。
色々と技法はあるよ。継続的インテグレーションだとか、テスト駆動開発とかさ。
でも、それは「なるたけ早く！ 目に見える形で！ お客様に！ 動く製品を！」ってことだよね。それを達成するためなら方法なんて、まぁ、好きにすればいいじゃない？
いくつかのガイドラインみたいなものはあるけど、現場ありきで自由に変えてよ。ってことですね。多分。
あと、個人的には「無理な計画は無理です！」って言うためにも、一週間を目安に成果を届けることは重要なんだなってことが面白かった。
「今まで一週間、この人員でこれだけの成果があがってます。で、新しい機能を追加しろと、あんたは言うけど。どう考えても無理だよね？」
って言葉に説得力をもたせるためには一週間は確かにいい。数ヶ月とかだと「気合でなんとかなるだろ？ はい、デスマーチ」って感じになるもんなぁ。
「ほうれんそう」はマメにってことだなぁ。
なんか良さげに思えるアジャイルだけれども、チームの目標を固めるとか、すばやく計画変更可能とか、それは裏を返すと「衆愚的意思決定という不安要素」とか「計画変更しまくって、なんかどっか行っちゃう」とかありそう。
基本は「早めにコケて、早めに直す」ってことなのかな。これはアジャイルに限らないけれども。
