アジャイルサムライ

アジャイルサムライ−達人開発者への道−

もうひとつ伝えておきたいことがあるんだった。
アジャイルであるかなんて気にしない
(p.287)

後書きにもあるけれど、「実践的で、一通り全てがカバーされており、読みやすく、押しつけがましくない」という一冊。
上記の引用部は、「なんのためのアジャイルなのか？」を忘れては意味が無いということである。

PMBOKもそうだし、このジャンルの優れた本に共通することだけれど、よほどのことがない限り、いきなり全部適用するなんてことはない。だから、個々人がそれぞれ読んでみて、必要な部分を取り出すことになる。

ということで、自分用メモ。

ソフトウェア開発の3つの真実

１．プロジェクトの開始時点にすべての要求を集めることはできない
２．集めたところで、要求はどれも必ずといっていいよど変わる
３．やるべきことはいつだって、与えられた時間と資金よりも多い
(p.13)

「動くソフトウェアこそが進捗の尺度」(p.12)に加えて、上記の真実を受け入れる。まずはここから。

インセプションデッキ

プロジェクト開始前に聞いておくべき質問集

• 我々はなぜここにいるのか？
• エレベータピッチ
• パッケージデザイン
• やらないことリスト
• 「ご近所さん」を探せ
• 解決案を描く
• 夜も眠れない問題
• 期間を見極める
• 何を諦めるのか
• 何がどれだけ必要か

私は、「ご近所さん」のチェックが甘い。
あと、最後の「何がどれだけ」のところにあった、「アジャイルな顧客」(p.93)という表現は良い。
使おう。

ユーザストーリーに備わっているべき6つの要素

「独立している(Independent)、交渉の余地がある(Negotiable)、価値のある(Valuable)、見積もれる(Estimatable)、小さい(Small)、テストできる(Testable)」の英単語のそれぞれの頭文字とをって、INVESTと呼ぶんだ。(p.111)

ユーザストーリーと書かれているが、私は普段「ユースケース」と呼んでいるかな。

変更は味方

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方に付けることによって、お客様の競争力を引き上げます。(p.153)

スコープを柔軟にすることが大事なので、開発側から顧客へもこういう言い方になる。