-Amazon.co.jp： アジャイルサムライ−達人開発者への道−: Jonathan Rasmusson, 西村 直人, 角谷 信太郎, 近藤 修平, 角掛 拓未: 本
--http://www.amazon.co.jp/exec/obidos/ASIN/4274068560/nilabwiki-22/ref=nosim/
--->出版社/著者からの内容紹介
--->マスターセンセイと学ぶアジャイル開発の道
--->動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。
--->
--->内容（「BOOK」データベースより）
--->アジャイルサムライ―それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。本書では、圧倒的なアジャイルプロジェクトの姿を見せる。
--->
--->著者からのコメント
--->日本の読者の皆さんへ
--->君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすごく大事な2つのことが備わってるってことだからだ。
--->1. 君は学ぶことが心から好きだ。
--->2. 君はソフトウェアのことを大切に思っている。
--->このどちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなんて気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになっていただろう。
--->なぜなら世界はソフトウェアを必要としてるわけだから。世界はソフトウェアを作ることを手助けする人を必要としてるんだ。そう、君みたいなね。私たちが、君みたいに才気煥発で、頭が良くて、思慮深い、情熱にあふれた人達をもっと惹きつけられるようになるには、もっと成果をあげるソフトウェアの作り方が必要なんだ。わくわくするような、毎朝目を覚ますたび、今日一日またソフトウェアを作ることが楽しみで仕方がないようなやつがね。
--->そのために私は本書を書いた。もっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していこう（でもあんまり深刻に受け止めすぎないで。楽しみながらやっていこう）。
--->君の探してることが、本書を読んで見つけられることを願っている。もし見つからなかったとしても、探し続けることを止めないでほしい。
--->2011年4月26日
--->ジョナサン・ラスマセン
--->（日本語版序文より）
--->
--->本書の特長
--->タイトルに加えて、ジョナサン独特の筆致と妙な味わいの挿絵に幻惑された読者がいるかもしれませんが、本書は見た目によらず硬派な1冊です。監訳者たちが本書の価値と特長だと捉えている点を、簡単にまとめておきます。1）開発者------もっといえばプログラマ向けに焦点を合わせていること、2）アジャイルな開発の進め方をひと通りすべてカバーしていること、3）よく練られた5部15章の構成になっていること、4）特定の方法論を前提としていないこと、5）ユーモアと楽しむ気持ちを忘れていないこと。これだけの内容を300ページ以内に収めたジョナサンたち原著執筆チームの力量には「お見事！」と喝采を送りたいです。
--->よく誤解されることなのですが、アジャイル開発は腕自慢の「優秀な」プログラマでなければ実践できない、というものではありません。たとえば、監訳者2人はアジャイル開発を実践していますが、プログラマとしてはいたって普通です。ですから、顧客にちゃんと価値を届けるためには、エンジニアリングプラクティスという先人の知恵の集大成を「問答無用」で「規律正しく実践」しなければなりません。それに、普通のプログラマは独りで実現できることもたかが知れています。だからチームを組むのです。
--->本書の冒頭でジョナサンは宣言します。「コードを実行するのはコンピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なんだ」と。私たちプログラマの多くは、普通のプログラマです（たくさんいるから「普通」なのです）。そんな私たちがチームを組んで成果をあげるには、物事をうまく運ぶための仕組みやプラクティスが必要です。だからといって、既存のアジャイル開発手法の提示するやり方を形だけなぞってもなかなかうまくいきません。
--->スケジュールを2週間単位で分割したMicrosoft Execlのシートを作ればイテレーションなのか？毎朝集まればデイリースタンドアップなのか？テストを先に書けばテスト駆動開発なのか？------「そうじゃないんだ」とばかりに、ジョナサンは「12の原則」を、字面だけでなく真に理解して体現した「圧倒的なアジャイルプロジェクトの姿」を私たちに示してくれます。10.6「デイリースタンドアップ」（p. 213）などはその好例です（毎朝、天地神明に誓ってから仕事をしてますか？ただ突っ立ってボソボソしゃべってるような開発者はいねがー？）。
--->私たちのソフトウェア開発の現場をどうにかできるのは私たちだけです。しかも、一つとして同じ現場はありません。だから「どんな書籍も手法も、君が必要とするありとあらゆるものを用意することなんてできない」のです。私たちは「自分の頭で考えるのをやめちゃだめ」なのです。
--->（「監訳者あとがき」より）
--->
--->カバーの折り返し
--->アジャイルサムライ------それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。本書では、圧倒的なアジャイルプロジェクトの姿を見せたい。
--->本書の内容をあまり堅苦しく受け止めないでほしい。楽しんで読んでもらえたほうがうれしい。アジャイルプロジェクトで働くのがどんな感じなのかを親しみやすく伝えたかったんだ。
--->君の探してることが、本書を読んで見つけられることを願ってる。もし見つからなかったとしても、探し続けることを止めないでほしい。
読書メモ
-3つの真実
--プロジェクトの開始時点にすべての要求を集めることはできない
--集めたところで、要求はどれも必ずといっていいほど変わる
--やるべきことはいつだって、与えられた時間と資金よりも多い
-「万人の認める唯一無二なる究極のアイスクリームのフレーバーが存在しないように、万人が従う唯一無二なる究極のアジャイル手法のフレーバーも存在しない」
--「どんな書籍も手法も、君が必要とするあらゆるものを用意することなんてできない。だから、自分の頭で考えるのをやめちゃだめだ。ひとつとして同じプロジェクトはないんだ」
-アジャイルでは細かく定義された役割は用意しない
--人の強みを活かす
--役割に人を合わせるのではなく、人に合わせて役割分担を決める
--職能横断型チーム (Cross-Functional Team)
--幅広い作業をこなすことを厭わないチーム
-ユーザーストーリーのテンプレート
--誰の ためのストーリーで
--何を したいのか
--なぜ そうしたいのか
-アジャイルな計画づくり
--ベロシティ: チームがユーザーストーリーを動くソフトウェアに変換する速度
---チームの生産性の計測と、プロジェクト完了日の見通しを立てるのに使う
-プロジェクトの無駄の元凶
--64%の機能がほとんどあるいは全く使われていない
--重要なこと以外はどけておきたい
-nilog: Choo Choo Train? - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/YUGBbQ2C (2012-08-10)
--http://www.nilab.info/nilog/?type=twitter&id=233856568255455232
--
-nilog: 「開発リーダーが自分だけ宝くじを当てて退職しようとしているッ！」 なんだこのノリｗ - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/pymMZwx5 (2012-08-10)
--http://www.nilab.info/nilog/?type=twitter&id=233857287343730688
--
-nilog: てごわい質問とインセプションデッキ。期待を共有して、認識を合わせる。 - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/02VRYTgm (2012-08-15)
--http://www.nilab.info/nilog/?type=twitter&id=235586589877755907
--
-nilog: トレードオフ・スライダー。何を諦めるのか決める。 - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/j6snxVOe (2012-08-15)
--http://www.nilab.info/nilog/?type=twitter&id=235586874893299713
--
-nilog: ユーザーストーリーの収集。図をたくさん描いて、アイデアのブレスト。要素を分割してストーリーにしていく。 - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/vPghmtm4 (2012-08-15)
--http://www.nilab.info/nilog/?type=twitter&id=235587345183825920
--
-nilog: ペーパープロトタイプでいろんなデザインをどんどん作ろう。チームメンバーが一緒になって紙の上で作業すること1人で考えるより良いアイデアが出てくる。 - アジャイルサムライ−達人開発者への道− / Jonathan Rasmusson http://t.co/6EHeZEBr (2012-08-15)
--http://www.nilab.info/nilog/?type=twitter&id=235587857081839616
--
書籍情報
-アジャイルサムライ――達人開発者への道｜Ohmsha
--http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06856-0
--->主要目次
--->
--->日本の読者の皆さんへ
--->謝辞
--->お目にかかれて光栄です
--->
--->第I部 「アジャイル」入門
--->第1章 ざっくりわかるアジャイル開発
--->第2章 アジャイルチームのご紹介
--->
--->第II部 アジャイルな方向づけ
--->第3章 みんなをバスに乗せる
--->第4章 全体像を捉える
--->第5章 具現化させる
--->
--->第III部 アジャイルな計画づくり
--->第6章 ユーザーストーリーを集める
--->第7章 見積り：当てずっぽうの奥義
--->第8章 アジャイルな計画づくり：現実と向きあう
--->
--->第IV部 アジャイルなプロジェクト運営
--->第9章 イテレーションの運営：実現させる
--->第10章 アジャイルな意思疎通の作戦
--->第11章 現場の状況を目に見えるようにする
--->
--->第V部 アジャイルなプログラミング
--->第12章 ユニットテスト：動くことがわかる
--->第13章 リファクタリング：技術的負債の返済
--->第14章 テスト駆動開発
--->第15章 継続的インテグレーション：リリースに備える
--->
--->第VI部 付録
--->付録A アジャイルソフトウェア開発の原則
--->付録B オンラインリソース
--->付録C 参考資料
--->
--->監訳者あとがき
--->索引
--->著者・監訳者・訳者について
--->
--->詳細目次
--->
--->日本の読者の皆さんへ
--->謝辞
--->お目にかかれて光栄です
--->本書の読み方
--->からかってるわけじゃあないんだよ
--->本書のオンラインリソース
--->
--->第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 参考資料
--->
--->監訳者あとがき
--->索引
--->著者・監訳者・訳者について
-Jonathan Rasmusson さんインタビュー ( 前編 )
--http://www.ogis-ri.co.jp/otc/hiroba/specials/JonathanRasmusson/interview1.html