アジャイルサムライを読んだ

入社前に読んどけって言われたので。

筆者が日本人じゃないと知ってからニンジャスレイヤー臭が高まった。

動くソフトウェアこそが尺度
大きなタスクは分解しろ
最初の見積もりは信じるな
チームの力を無駄なく最大限にするのが目的
顧客の要求を叶えるために、顧客には積極的にプロジェクトに関わってもらおう
プロジェクトの成功に奇跡が必要なら、それは絶対に良いプロジェクトではない

個々人の役割は横断している。
ただし、自分と近い人(お隣さん)を常に知っておくとチームはよく動ける。
あいまいな状況を許容しよう
自分の縄張りを主張しすぎてはならない

プロジェクトに対するクリティカルな質問集
プロジェクトに関わるメンバーがその質問に対して同じように答えられる = 意思共有ができているということ
詳細は略

〜したい
〜向けの
〜というプロダクトは
〜である
これは〜することができ
〜とは違って
〜が備わっている

プロジェクトを簡約したもの。これに答えられるようしておくこと。

リスクを洗い出す
チームにとって取り組む価値があるリスクと、そうではないリスクを分類する。
プロジェクト期間に応じて、リスクは増大する。(目安としては6ヶ月という例が紹介されている)
アジャイル開発においては、顧客のプロジェクトの期間に対する期待をマネジメントしろ

プロジェクトの要素として、品質時間スコープ(範囲) 予算
アジャイルにおいては、品質、時間、予算は固定されたものとして考える。
それぞれにスライダーを用意して、優先順位を決定する。
うやむやにしないために、同じメモリの項目が2つあってはならない。

開発中にいじれるのはスコープだけということになる。
なぜならばほとんどの機能は使われることはないから。優先的なものから実装する。

顧客が実現したいと思っているフューチャーを小さな紙に書きだす。(インデックスカード)
文書化は難しい。可能ならば顧客とのFace to Faceで定義する。
(ユーザーストーリーは必ず顧客が書け、という派閥も存在する)

インデックスカードに細かく要求をかきまくってはいけない。それは顧客と話さないといけないものだから。 => 話しに行けってことだ
顧客にとって価値があることを書きだす。 C++で実装するかRubyで実装するかはどうでもいい。大事なのは「ユーザーアカウントを作成できること」

「誰のための」「何をしたい」「なぜ」

前提として… 概算見積もりなんてあてずっぽうだ
とくにプロジェクトが初期段階であるほどそうだ。(概算で最大四倍の誤差がある、らしい)

すべてのストーリーは相対的に見積る。
見積もりの最小ストーリー群を1として、それを基準に大きなタスクにポイントを付ける。(3, 5...細かく分けすぎてもいけない)
期間にこなせたタスクの総合ポイントで、チームのベロシティ(開発速度)を割り出す

比較するために、ユーザーストーリーは似たようなグループで分類する
プランニングポーカーを行う。

根拠：人間は絶対値より相対的に見積るのが得意

1イテレーションは 1週間から2週間
価値ある成果を毎週届ける(毎週とはとにかく定期的にみてもらうということ)

イテレーション数 = 作業量の合計/チームの予想ベロシティ
スコープにするマスターストーリー(全体目標)は柔軟に入れ替えられるようにする(優先順位は入れ替わる)

インデックスカードから1つの文書に

フローチャート(シナリオ)を作成

イテレーション・ゼロ
プロジェクトの最初のイテレーションではとにかく開発の準備を整える。
テスト環境の構築だとか、CIだとか。

10章はちゃんと読んでない。
11章以降はCIとユニットテストやリファクタリングについての話だったので割愛。