2014/09/17開催回のコメントページ
「アジャイルサムライ」を読んだ感想コメント・疑問を、以下に記入ください。読書会では、ここに書かれたコメント・疑問を中心にディスカッションを行います。
P.1 第I部 「アジャイル」入門
P.3 第1章 ざっくりわかるアジャイル開発
P.3 1.1 価値ある成果を毎週届ける
- 大きな問題は小さくする
- 本当に大事なことに集中して、それ以外のことは忘れる
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- 必要とあらば進路を変える
− 成果責任を果たす
P.8 1.2 アジャイルな計画づくりがうまくいく理由
- マスターストーリーリストでユーザストーリーを優先順位をつけて管理する
- イテレーション（タイムボックス）で開発を進める
- ベロシティ（一回のイテレーションで完了させられるストーリーの量）を把握し、それを元に予測する
P.11 1.3 「完了」とは完了のことだ
コードをリリース可能にするためのあらゆる作業を終わらせていること。80%完了している、というような中途半端な状態はアジャイルにはない。
P.12 1.4 3つの真実
- プロジェクトの完了時点ですべての要求を集めることはできない
- 集めたところで、要求はどれも必ずといっていいほど変わる
- やるべきことはいつだって、与えられた時間と資金よりも多い
- やりかたがたったひとつなんてことはないんだ！
P.17 第2章 アジャイルチームのご紹介
P.17 2.1 アジャイルなプロジェクトはどこが違うのか
- アジャイルなプロジェクトでは役割分担ははっきりとは分かれていない(「多能工」)
- 開発工程は途切れることなく連続的(開発工程のそれぞれを密接に連携させながら作業を進める)
- チームが一丸となって成果責任を果たす(態度)
P.20 2.2 チームをアジャイルにするためのコツ
- 同じ仕事場で働く
- 積極的に深く関わる顧客の存在
- 自己組織化
- 成果責任と権限移譲
- 職能横断型チーム
P.27 2.3 よくある役割分担
P.38 2.4 チームメンバーを探すコツ
- ゼネラリスト
- 曖昧な状況に抵抗がない人
- 我を張らないチームプレイヤー
P.41 第II部 アジャイルな方向づけ
P.43 第3章 みんなをバスに乗せる
P.44 3.1 プロジェクトがだめになるのはなぜか
チームメンバーが誰もいないところで合意したことを前提にしているから。
P.45 3.2 手ごわい質問をする
P.46 3.3 インセプションデッキのご紹介
P.47 3.4 インセプションデッキの仕組み
P.48 3.5 インセプションデッキの課題一覧
P.51 第4章 全体像を捉える
P.52 4.1 我われはなぜここにいるのか？
P.56 4.2 エレベーターピッチを作る
P.59 4.3 パッケージデザインを作る
P.63 4.4 やらないことリストを作る
P.66 4.5 「ご近所さん」を探せ
P.73 第5章 具現化させる
P.74 5.1 解決案を描く
P.76 5.2 夜も眠れなくなるような問題は何だろう？
P.80 5.3 期間を見極める
P.84 5.4 何を諦めるのかをはっきりさせる
P.92 5.5 何がどれだけ必要なのか
P.99 第III部 アジャイルな計画づくり
P.101 第6章 ユーザーストーリーを集める
P.10 6.1 文書化の難しさ
P.105 6.2 そこでユーザーストーリーですよ
P.107 6.3 よく書けているユーザーストーリーとは
- お客さんにわかってもらえる言葉づかいで表現すること
- お客さんがわくわくするようなストーリー
- 独立している(Indipendent)
- 交渉の余地がある(Negotiable)
- 価値のある(Valuable)
- 見積もりできる(Estimatable)
- 小さい(Small)
- テストできる(Testable)
テンプレート：<ユーザの種類>として<達成したいゴール>をしたい。なぜなら<理由>だからだ
P.117 6.4 ストーリー収集ワークショップを開催しよう
P.125 第7章 見積り：当てずっぽうの奥義
P.125 7.1 概算見積りの問題
- 不確実性コーン：初期段階の見積りには大きな誤差がある
P.128 7.2 ピンチをチャンスに
- ストーリーを相対的なサイズで見積る
- ポイントをもとにして進捗を追跡する
P.136 7.3 見積り技法
- 三角測量
- プランニングポーカー
P.145 第8章 アジャイルな計画づくり：現実と向きあう
P.145 8.1 固定された計画の問題
P.150 8.2 アジャイルな計画づくり
チームの開発速度を計測して、その速度を元にプロジェクトの完了時期を見通せるようにすること（に尽きる）
P.152 8.3 スコープを柔軟に
P.154 8.4 初回の計画づくり
- マスターストーリーリストを作る
- プロジェクト規模を見極める
- 優先順位をつける
- チームのベロシティを見積もる
- 期日を仮決めする
P.165 8.5 バーンダウンチャート
P.169 8.6 プロジェクトを途中からアジャイルにしていく
- チームの方向性に問題があるならインセプションデッキを作ってみよう
- とにかく早く成果を上げたいなら計画を立て直そう
- 進捗を示さなければならないならフィーチャーを選んで完了させよう
P.171 8.7 現場で実践する
P.181 第IV部 アジャイルなプロジェクト運営
P.183 第9章 イテレーションの運営：実現させる
P.183 9.1 価値ある成果を毎週届ける
- 必要な分だけを、必要なときに分析する
- 品質を作りこむ(バグを作りこまない)
- テストは早めに、こまめに行う
P.184 9.2 アジャイルなイテレーション
P.186 9.3 【急募】アジャイルチーム【切実】
P.187 9.4 ステップ1：分析と設計：作業の段取りをする
P.193 9.5 ステップ2：開発：作業する
P.197 9.6 ステップ3：テスト：作業の結果を確認する
P.198 9.7 カンバン
P.205 第10章 アジャイルな意思疎通の作戦
P.205 10.1 イテレーションでやるべき4つのこと
- やりかたはひとつじゃない
P.206 10.2 ストーリー計画ミーティング
- 今回のイテレーションの作業に備える
- 顧客と一緒に受入テスト条件をレビューしたり
- 開発チームが見積りの数値を確認したり
- ストーリーの実装を始めるにあたって、必要な調査に漏れがないことを確認する
P.208 10.3 ショーケース
- 今回のイテレーションのフィードバックを得る
- 顧客に対するデモ、感想のヒアリング
P.209 10.4 イテレーション計画ミーティング
- 次回のイテレーションの計画を立てる
- ベロシティを確認し、次に取りかかるストーリーを整理する、コミットメントする作業量を見極める
- チームの健康状態を確認する
P.211 10.5 ミニふりかえり
- 次回のイテレーションで改善できる余地を探す
- １０〜１５分で、うまくいったことや、もっとうまくやるためにどうすればいいかを話し合う
P.213 10.6 デイリースタンドアップ
- 重要な情報を、毎日、すばやく共有する
P.214 10.7 自分たちに合った手段を選ぼう
P.219 第11章 現場の状況を目に見えるようにする
P.220 11.1 これは……荒れる！
P.224 11.2 貼りものの作り方
- ミニマムセット：ストーリーボード、リリースボード、ベロシティとバーンダウンチャート
P.226 11.3 チームの意思を明確にする
P.228 11.4 プロジェクトで使う言葉を共有する
P.229 11.5 バグを監視する
P.233 第V部 アジャイルなプログラミング
P.235 第12章 ユニットテスト：動くことがわかる
P.236 12.1 ラスベガスへようこそ！
P.238 12.2 はじめてのユニットテスト
- ユニットテストのメリット：
-- 素早いフィードバック
-- 低コストのリグレッションテスト
-- デバッグ時間の削減
-- 自信を持ってデプロイできる
P.247 第13章 リファクタリング：技術的負債の返済
P.247 13.1 どうしてこうなった
P.249 13.2 技術的負債
- スパゲティコード、度を越した複雑さ、重複、ありがちな手抜き
P.251 13.3 リファクタリングで技術的負債を返済する
- できるかぎり頻繁に行う
- 一度に行う変更は小さく
P.261 第14章 テスト駆動開発
P.261 14.1 テストを先に書く
- 失敗するテストをひとつ書くまでは、新しいコードを一切書かない
- 「危なっかしい所」をすべてテストする
P.266 14.2 テストを使って複雑さに立ち向かう
- 少しずつ、確実に歩を進める
P.273 第15章 継続的インテグレーション：リリースに備える
P.273 15.1 ショータイム
P.276 15.2 リリースに備える文化
P.277 15.3 継続的インテグレーションとは
- 統合作業を途切れることなく続けていく
P.279 15.4 どうすればうまくいくのか？
- ソースコードリポジトリを用いる
- チェックイン手順を習慣づける
- ビルドを自動化する
- 作業単位を小さくしようとする
P.279 15.5 チェックイン手順を習慣づける
P.281 15.6 ビルドを自動化する
P.283 15.7 作業単位を小さくする
- できるかぎり頻繁に行う
- 一度に行う変更は小さく
P.285 15.8 この先どこへ向かえばいいのか？
P.289 第VI部 付録
P.291 付録A アジャイルソフトウェア開発の原則
P.291 A.1 アジャイルソフトウェア開発宣言
P.292 A.2 アジャイルソフトウェア開発の12の原則
P.293 付録B オンラインリソース
P.295 付録C 参考資料