BOOK#16｢アジャイルサムライ達人開発者への道｣

●今回読んだ本

｢アジャイルサムライ達人開発者への道」―ジョナサン・ラスマセン著（出版社:オーム社 |2011年07月16日発行）

●内容メモ #ネタバレ

アジャイルがフレームワークであり、心構えであり、ソフトウェアを無駄なく、早く届ける手法だ。チームの持てる力を最大限に引き出すことで、プロジェクトがうまくいく確率を格段に向上させる。価値を生み出すか、生み出さないか。2つに1つだ。

▽この本で学びとるべきこと
・アジャイルプロジェクトの準備とキックオフをうまくやる方法。プロジェクトの意義や目的をはっきりさせる。
・要求を求めて見積もり、計画を立てる方法。わかりやすく、風通し良く、誠実なやり方で。
・ものすごい勢いで成果を上げていくための手法。質の高い、リリース可能な行動を生み出し続けられるようになるには。

▽価値ある成果を毎週必ず届けるために
1.大きな問題を小さくする
2.本当に大事なことに集中して、それ以外の事は忘れる
3.ちゃんと動くソフトウェアを届ける
4.フィードバックを求める
5.必要たらば進路を変える(計画を変えて、現実は変えない）
6.成果責任を果たす

▽マスターストーリーリスト
todoリスト。顧客がプロジェクトの中で実現したいことを記述した一覧表。本書独自の用語。プロダクトバックログ。

▽ユーザーストーリー
タスク。マスターストーリーリストに載せるのは、開発対象となるソフトウェアで顧客が実現したいと思うフィーチャ。記述レベルは、概要がわかれば充分。
リストの項目に顧客が優先順位をつけて、開発チームが見積もったら、プロジェクト計画の土台ができあがる。

▽イテレーション
スプリントのこと。具体的に成果を上げていくためのエンジン。イテレーションの長さは1～2週間にしておく。このイテレーションの期間を使って、開発チームは顧客が最も価値が高いと思うものから順番に、ストーリーをテスト済のちゃんと動くソフトウェアへと変換していく。人はこの期間を通じて、ユーザストーリーを、リリース可能な動くソフトウェアに変換する

▽ベロシティ
1回のイテレーションで完了させられるストーリーの量。チームがユーザストーリーを動くソフトウェアに変換する速度。チームの生産性の計測とプロジェクトの完了日の見通しを立てるのに使われる。実測することで、自分たちのこなせる仕事量を把握できる。

▽トラブル対処法
やるべきことがあまりにも多すぎると言う事態に直面したらどうするか。その時はやれることをやるだけ。つまり、やることを減らす。スコープを柔軟にしておくことが計画のバランスを保ち、やると決めたことをやり遂げていくための秘訣だ。だから、現実が計画にそぐわなくなったら計画を変える。現実に適応する計画作りはアジャイルに価値を届けるための基本だ。

▽ソフトウェア開発の3つの真実
1.プロジェクトの開始時点にすべての要求を集めることができない
2.集めたところで、要求はどれも必ずと言っていいほど変わる
3.やるべき事はいつだって、与えられた時間と資金よりも多い

▽アジャイルチーム
顧客(何を作るかを決める) +開発チーム(どうやって作るかを決める)。
※POINT：アジャイルチームでは、メンバーにどの役割が割り当てられているかを気にしない。気にかけるのは、その役割によって果たされる仕事が、チームの誰かによってちゃんとこなされるようになっているかどうか、それだけだ。

▽アジャイルな顧客
顧客は問題領域の専門家であることが望ましい。業務に深く通じていて、ソフトウェアが何をするのか、どんな見た目になるのか、どんな具合に動くのかを心から気にかける人物。開発チームに確固たる自信を与え、質問に答え、フィードバックしてくれる存在。アジャイルの顧客は要求の優先順位付けも行う。何をいつ作るかを決めるのは顧客だ。とは言え優先順位を顧客の独断で決めるわけじゃない。開発チームとの共同作業だ。

▽開発チーム
（1）アジャイルなアナリスト
（2）アジャイルなプログラマー
（3）アジャイルなテスター
（4）アジャイルなプロジェクトマネージャー
（5）アジャイルなUXデザイナー
（6）その他の役割…データベース管理者、システム管理者、テクニカルライター、トレーナー、業務改善担当、インフラ管理者、ネットワーク管理者…

▽チームメンバーを探すコツ
（1）ゼネラリスト
最初から最後まで自分の力を発揮することが求められる。例えばプログラマなら、フロントエンドからバックエンドまで技術スタックどこでも担当できると言うことだし、アナリストテスターなら分析とテストのどちらも安定してこなせると言うことだ。
（2）曖昧な状況に抵抗がない人
あらかじめ何もかもがしっかりきっちり整っている事は無い。変化球が投げられても慌てない人を探そう。
（3）我を張らないチームプレイヤー
チームがまるで合奏団のように、顔を貼らないことに自覚的なメンバーで構成されている時こそ、アジャイルプロジェクトはうまくいく

▽インセプションデッキ
インセプションデッキは中の手ごわい「質問」と「課題」から構成されている。インセプションデッキはプロジェクトの今後半年間の見通しを立てるのにも向いているが、プロジェクトの状況や方針に大幅な変更があれば、そのタイミングで改訂しなければならない。インセプションデッキは実際に使われる、生きた成果物だ。だから、作りっぱなしで棚にしまっておくようなものじゃない。仕事場の壁に貼り出すのが良いだろう。時々それを眺めて思い出そう。何を作ろうとしているのか。そしてそれはなぜなのか。

▽インセプションデッキの課題一覧
01.我々はなぜここにいるのか?
02.エレベーターピッチ作る
03.パッケージデザインを作る
04.やらないことリストを作る
05.「ご近所さん」を探せ
06.解決案を描く
07.夜も眠れなくなるような問題はなんだろう?
08.期間を見極める
09.何をあきらめるのかをはっきりさせる
10.何がどれだけ必要なのか

▽ユーザーストーリー
ユーザーストーリーは顧客がソフトウェアで実現したいと思っているフィーチャを簡潔に記述したもの。フィーチャの本質を捉えるキーワードを書き留めておくことが大事。ユーザーストーリーはビジネスの観点から評価できなければならない。お客さんが理解できるシンプルな言葉遣いでユーザーストーリーを書くことを心がけるのもそのため。お客さんにはちんぷんかんぷんな技術用語を避けるのも同じ理由。

▽概算見積もりの問題
見積もりをどうしても間違えてしまうことが問題なんじゃない。問題は、見積もりから本来そこにありもしないものを読み取ってしまうこと。つまり、見積もりを未来の性格の予測だと信じ込んでしまうことにある。概算見積もりなんて当てずっぽうだと思っておこう

▽見積もり技法
(1)三角測量
代表的なストーリーをいくつか基準として選出して、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方
(2)プランニングポーカー
開発チームのメンバーは、一つ一つのストーリーをまず自分自身で見積もる。各人が見積もったら、その数値をメンバーとして見せ合って、チームとして統一した見積もりを出す。メンバー全員の見積もり数字が一致すればそれで決まり。見積もり結果に食い違いがあれば、その違いについて話し合ってメンバーそれぞれが再び見積もる。チームで見積もり結果に合意できるまで話し合いと再見積もりを繰り返す。

●その他

▽なぜ読みたいと思ったのか
SUNABACOデザインコース受講中にLeanUXの概念を学び、補足したいと思ったから

▽興味を持ったきっかけ
参考図書としてオススメ本だったので

▽この本を読むことの意義
アジャイルとは何なのかを理論的に理解し、自分の中で整理する

▽どんな本の内容だと思って手に取ったのか
アジャイル開発の考え方、ワークフローが理解できると思って

▽実際読んでみてどんな本だったのか
タイトルからは想像できないくらい、まじめで体系的な本だった。特に、アジャイルなチーム作りの「メンバーにどの役割が割り当てられているかを気にしない。気にかけるのは、その役割によって果たされる仕事が、チームの誰かによってちゃんとこなされるようになっているかどうか、それだけだ。」の部分が刺さる。こういう考えで、仕事に取り組みたい。

▽タイトルをつけ直す（要約）とすると？
アジャイルを生み出すチーム作り

▽知らなかった単語(用語)について
・アジャイル…柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法の総称。Agile（素早い・機敏な・頭の回転が速い）。
・銀の弾丸…「狼男を倒せる武器」から転じて困難な課題を解決する決め手の意味。
・フィーチャ…ソフトウェアの機能、特性や特徴、生の目標、見た目は使い勝手など、いわゆる「売り文句」等を総称することだ。ソフトウェアを使う側の視点から記述している点がポイント。フィーチャはユーザにとっての価値なので、例えば星の木がセキュリティーといったいわゆる非機能要件含まれる
・スプリント…短い距離の疾走。
・スコープ…プロジェクトで行う作業の範囲と、成果物に何を含めるかを定めたもの。

●Amazon

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