今回は、「アジャイルサムライ達人開発者への道」を読みました。
対象読者
- どんな人でも
- エンジニア初級者にとっては、プロジェクトを進めるにあたって持っておきたい心構えを非常に多く学ぶことができると思います。
- エンジニア中級者・上級者にとっては、初心に返るのにとてもいいと思います。
この本で学べること
- アジャイルプロジェクトの準備とキックオフをうまくやる方法。プロジェクトの意義や目的をはっきりさせ、誰のために何をするのか明確にする。
- 要求を集めて、見積もり、計画を立てる方法。それもわかりやすく、風通しよく、誠実なやり方で。
- ものすごい勢いで成果を上げていくための手法。プロジェクトを手入れの行き届いた機械のようにして、質の高いリリース可能なコードを生み出し続けられるようになるためにはどうすればいいか。
第１部 「アジャイル」入門
第１部では、アジャイルなソフトウェア開発の全体像と、アジャイルチームがどう機能するかを説明します。
第１章 ざっくりわかるアジャイル開発
- お客さんにとって「価値ある成果」とは何か
それは「毎週動くソフトウェアを届ける」こと
- 毎週価値ある成果を届けるために大切なこと
①大きな問題は小さくする
毎週成果を届けられるように。
②本当に大事なことに集中して、それ以外のことは忘れる。
ドキュメントや実施計画書はあくまでも動くソフトウェアを補完するものでしかない。
③ちゃんと動くソフトウェアを届ける
そのために、こまめにテストする
④定期的にお客さんからフィードバックを求める。
間違っていたら軌道修正するために。
⑤必要とあらば進路を変える。
プロジェクトではいろんなことが起こるので、計画を柔軟に変更する。
⑥成果責任を果たす
彼らの資金の使い道を示すことができたら、成果責任を果たしたことになる。
- プロジェクトの3つの真実
1. プロジェクト開始時点に全ての要求を集めることはできない
2. 集めたところで、要求は必ずと言っていいほど変わる
3. やるべきことはいつだって与えられた時間と資金よりも多い
第２部
第２部は、便利なツールやフレームワークの紹介です。
第３章 みんなをバスに乗せる
プロジェクトが失敗する理由は、主にみんなのゴールやビジョンがあってないから。
それを合わせるために、インセプションデッキというものを使用する。
第４章 全体像を捉える
さらにビジョンを明確にしていくために、エレベータピッチやパッケージデザイン、やらないことリストなどを作っていきます。コラムにあった、「エンジニアが実際の現場に行ってその地域にあった車を作った」といういい話も印象的でした。
第５章 具現化させる
3章と4章で「なぜここにいるのか」ビジョンのすり合わせができたので、5章では「どうやって実現させるか」をみていきます。
- リスクと向き合う
実現させるにあたって、まずはじめにやることは、「リスクとの向き合い方」です。
チーム内でリスクについて認識合わせを行い、予め手を打っておくことです。
- 荒ぶる四天王（時間、予算、品質、スコープ）との向き合い方
どれも最優先にはできないので、スコープを諦めてもらう場合があること、優先順位が同じになるものを作らないこと。
スコープ設定や計画に何ヶ月も時間をかける必要はないことなどが書かれていました。
第３部
アジャイルな計画づくりの基礎を扱います。ユーザーストーリー、見積もり、それから現実に合わせて変えられる計画の立て方を解説します。
第６章 ユーザーストーリーを集める
６章は、ユーザーストーリーについてでした。
- 文章よりface-to-face
- ユーザーストーリーはお客さんにわかりやすいように
データベースにコネクションプールを導入する→現状の10秒かかるページの読み込み速度を2秒まで縮める
- 制約をつける
ウェブサイトはサクサク表示する→サイトのページはどれも2秒以内に読み込めること
第７章 見積もり：あてずっぽうの奥義
７章は見積もりについてでした。
- 見積もりで欲しい答えは一つ
このプロジェクトをやり遂げられるのか？
- 仕事のサイズがどれくらいの大きさなのか
基準より大きいか小さいか「相対サイズで見積もる」のがアジャイル見積もりと計画作りの真髄。
- プランニングポーカー
> 1人の専門家より、複数の素人の平均の方が正しい（！）という研究結果もある。
やり方：
1 顧客がストーリーを読み上げる
2 開発チームが見積もる
3 開発チームで議論を重ねる
4 再び開発チームが見積もる
第４部
プロジェクト運営。立てた計画を、お客様が実際に使えるソフトウェアとして具現化するための作戦を学ぶ。
第９章 イテレーションの運営：実現させる
- テストは開発と一緒
プロジェクトの最後にならないと全体として動作するかわからない状況に甘んじない
- ユーザーストーリーの詳細は、必要な分だけを、必要なときに分析する
- カンバン
プロジェクトの進行状態を"誰でも"把握できるツール。
- ”価値のあるプロジェクト”
分析、開発、テストといった作業を一つにまとめあげてこそ。
第５部 アジャイルなプログラミング
第１２章 ユニットテスト：動くことがわかる
- ユニットテストがあれば、プロダクトに変更を加えても期待どおりであることを確認することができる。
- 変更を加えるたびに手動でシステム全体のリグレッションテストを実行する手間が省ける。
第１４章 テスト駆動開発
- テスト駆動開発をする。
ルール１：失敗するテストを一つ書くまでは新しいコードを一切書かない。
ルール２：「危なっかしいところ」を全てテストする
- 既に実装されたコードがあると考えながら、先にテストを書くと良い。
第１５章 継続的インテグレーション：リリースに備える
- ビルド時間は10分以内に留めるのが望ましい。
- ビルドを大切にすること。ソフトウェアはいつも動くようにしておこう。
- リリースに備えるとは、心構えのこと。今日書いたコードは今日テストしてリポジトリに統合する。バグがあれば即座に直す。「あとで直す」と先送りにしてはダメ。
感想
ずっと読んでみたかった名著、アジャイル・サムライ読み終わりました！
プロダクト開発の本質を突きながら、所々ユーモアがあって楽しく読み終わることができました。いやー... 2年前に読みたかったです。
先日「アジャイルな見積もりと計画づくり」という本を読んだのですが、それよりももっと"概念"というか、抽象的なアジャイルのお話でした。
エンジニアになったばかりの人は必ず読んでおいた方がいい本だと思います。
「もっと細かいことわからないと見積もりできないよ！」
「時間がないからリファクタリングは後にしよう」
「テストも後にしよう...」
「CIってなに？よくわからないけど、動いてるからヨシ」
「え！？そんな機能あるなら早くいってよ！」
「このコード、どっから変更したらいいんだ...」
全部私が今までの開発で通ってきた失敗でした... orz
もし、私が2年前にこの本を読んで多少なりともアジャイルの考え方を理解していたなら、もう少し良いアプローチ方法や問題への対処法を考えらえたはずです。
それにしても、アジャイルな考え方って素敵ですよね。この世の仕事って、なかなかアジャイルな考え方で進められる内容の仕事って少ないと思います。
これからどんな新しい機能ができて、どんなコードにしておけばいいかなんて誰にもわからない。
そんなこれから起こる未来にできるだけ対処していくための先人たちの知恵って、めちゃくちゃかっこいいですね。
色々書いてありましたが、一番大切なことは「顧客にとって本当に価値のあるプロダクトを安定して届ける」ということですね。
いろんな事情があると、だんだんと忘れがちになってきますが、このマインド（User Firstな気持ち）を忘れずにこれからも開発に取り組んでいきたいと思います。
