アジャイルサムライ読んだ
目的
プロジェクトがアジャイル開発になり、アジャイル開発やスクラム体制について理解を深めるために「SCRUM BOOT CAMP」を読んだ。
現状自分にとってスクラム体制でのチーム開発が非常に楽しく感じていて、さらに理解を深めていきたいと思ったので、アジャイルサムライを読むことにした。
1日1章ずつ読みながら、自分なりに要点をまとめ感想を書きたい。
要点整理・感想
1部 アジャイル入門
1. ざっくりわかるアジャイル開発
- アジャイルな計画の立て方
大きな問題は小さくし、本当に大事な課題に集中する。質はしっかり担保し、フィードバックをちゃんと求める。大事な事が変わってしまうこともある為、変化に柔軟になる。成果に責任を持つ。
- プロジェクトが上手く行っている度合いの測定
ベロシティを元に完了の期限を推測できる。完了にはすべての作業（分析・テスト・設計・コーディング...etc）が含まれている。ただオプションを全て実装するわけではない。
- 3つの真実と、それを受け入れる効能
1. プロジェクト開始時点にすべての要望を集めることはできない。
2. 集めたところで、要望はどれも必ずと言っていいほど変化する。
3. やるべきことは、与えられた時間や資金よりも多い。
これを受け入れることができれば、霧が晴れたような視界を得られる...
- 感想
あらためて、アジャイル開発は好きだなと感じた。結局お客さんに良いものが届くし、縦割り組織ではないのでチームメンバー各々が責任を持つ一方で現実的で健康な開発体制を組めると思う。また、期待をマネジメントする、というTipsは面白かった。透明性を保ちながら同時にそこも意識して仕事をしていこうと思う。
2. アジャイルチームのご紹介
- 典型的なアジャイルチームはどんな姿をしているのか
アジャイル開発では役割がはっきりと分かれていなく、プロジェクト成功の為ならなんでもする。さらに、開発工程（分析・設計・実装・テスト）が途切れることなく連続的な取り組みになる。また、アジャイルプロジェクトではチーム一丸となって成果責任を果たす。
- 自分のチームをどう編成すれば良いのか
アジャイル開発の原則は自己組織化。そのために成果責任と権限委譲が必要になってくる。実際に実装したものをお客さんにデモをすれば、成果責任に対して自覚的になれる。またクロスファンクショナルな組織であれば、スピード感のある開発ができるようになる。ゼネラリストの方が向いている。
- どんな心構えでチームに参加すれはよいのか
アジャイル開発に曖昧な状況はつきもの。要求がかわることにも柔軟に対応する必要があるし、なんなら受け身ではなく自ら問題を探す姿勢も〇。また、チームで成果を出していく為、協調性も非常に大事。
- 感想
成果責任にはハッとさせられるところがあった。仕様がまだ決まってないから進められない...UIデザインが複雑すぎて作れない...なんて状況はいくらでもあるが、勝手に自分のポジションを限定して嘆くのはおかしいよな～と気づいた。何かあった時に自分から発信できれば、より価値があるものを作れるようになるなと感じた。
2部 アジャイルな方向付け
3. みんなをバスに乗せる
- インセプションデッキと10の課題
インセプションデッキを共有することで、プロジェクトで期待されていることをプロジェクトメンバーで共有することができる。ただし、これは単なるとっかかりでしかない為、プロジェクトの状況や方針の変更があれば、インセプションデッキも改訂しなければならない。
1. 我々はなぜここにいるのか
2. エレベーターピッチを作る
3. パッケージデザインを作る
4. やらないことリストを作る
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れなくなる問題は何だろう？
8. 期間を見極める
9. 何を諦めるかはっきりさせる
10.何がどれだけ必要なのか
- 感想
今回のプロジェクトはPOやステークホルダーや一部の開発メンバーでやってしまったので、参加はできなかった。ただ、以前は眺めるだけだったインセプションデッキをより具体的にイメージできるようになりたいので、しっかり腑に落としたい。
4. 全体像を捉える
- インセプションデッキの前半でプロジェクトの目標を理解する
1. 我々はなぜここにいるのか
自分自身が現場に言ったり、顧客になってみたりすることで、顧客の考えや本当に必要としていることを知ることができる。
2. エレベーターピッチを作る
練られたエレベーターピッチは重要で、次の利点が得られる。
・明快になる。プロダクトが具体的に何で、誰のためのものなのか。
・チームの意識を顧客に向けさせる。プロダクトは何を提供し、なぜそれが必要なのか。プロダクトの強みと顧客にとっての価値が分かる。
・核心を捉える。本当に重要なのは何なのか。
3. パッケージを作る
パッケージを通してどんな訴求ができるのか。また客観的に見て、自分がそれを欲しいと思えるのか。
4. やらないことリストを作る
スコープを視覚的に理解することは非常に重要。
5. 「ご近所さん」を探せ
プロジェクトコミュニティは考えているより常に大きい。信頼関係を築いておく。
- 感想
「ご近所さん」を探せ、にはハッとさせられた。エンジニアにもコミュニケーション能力は必要だし、このような視点を普段から持てるだけで、ちょっとした懇親会などの意味付けも変わってくるので知れてよかった。
5. 具現化させる
- インセプションデッキの公判では「どうやって」の理解を進める。具体的な解決案と、プロジェクトのスコープを決める。
解決できる課題は以下。
6. 解決案を描く
図にするメリットはたくさんある。ツールや技術に対する期待のマネジメントや、プロジェクトの境界やスコープの可視化、リスクを伝えられることなど。イベントストーミングがこれにあたるかな？？
7. 夜も眠れなくなる問題は何だろう？
リスクを表題化し議論することは意味がある。取り組む値打ちのあるリスクをしっかり見極める。
8. 期間を見極める
原則として、プロジェクトの期間に比例して、失敗のリスクは増大する。ステークホルダーへの提案は2つの選択肢がある。期日を決めてスコープを調整するか、ある程度コアな機能は実装するつもりで期日に幅を持たせるか。大事な事として、提案がコミットメントととらえられてはいけない。実際の期日は作業を進めてみて、そのフィードバックを元にしないと正確性は担保できない。
9. 何を諦めるかはっきりさせる
品質は常に優先事項であり、期日と予算・スコープはトレードオフの関係にある。問題は何を諦めるか決めること。奥義トレードオフスライダーを使う。
10.何がどれだけ必要なのか
まずはPOの決定が非常に重要。コストの計算は簡単で、工数と人日を掛ければよい。
- 感想
プロジェクトがまず半年に最初のMVPのリリースになった時は驚いたが、この章を読むとそこが腑に落ちたので良かった。プロジェクトの期間に比例して失敗のリスクは増大するし、ウォルマートの在庫システムを作成したランディ・セットによると、長くてもファーストリリースの期間は6ヶ月以内にした方がよいらしい。期日を固定化し無限に増えるスコープを調整しようとするのは正しいと思った。
3部 アジャイルな計画づくり
6. ユーザーストーリーを集める
ユーザーストーリーとは、仕様を詳細に書き留めるものではなく、「会話の約束」という位置付けくらいの、簡単なものにする。機能を思いついた時点では、それがまだ必須のものか分からない。
また、ユーザーが理解できる言葉遣いで、ユーザーにとって価値のあるものを作る。様々な図を使うのも良い。
7. 見積もり：当てずっぽうの奥義
見積もりの目的は、結果を予言することではなく、達成可能な程度に現実的か確認するため。そのための見積もり手法として下記の3つが大切になる。
・今後の計画を立てられる
・見積もりは当てずっぽうだという前提を踏まえている。
・ソフトウェア開発の複雑さを理解している。
また、具体的な見積もり（継続的な）は下記の2つ。
・それぞれのストーリーを相対的に見積もる。
・ポイントを元にして予測を立てる。
- 感想
見積もりに関しても、やはり原則が大事だと感じた。予めこれらを知っているかいないかで、取り返しのつかない事態に陥るかどうか決まる。
8. アジャイルな計画づくり：現実と向き合う
プロジェクトに困難はつきもの。次の基準を満たすような計画をたてなければならない。
- 顧客にとって価値ある成果を届けられる計画・・・リリースの単位をMMFという。世の製品の64％は使われないほとんど機能。顧客にとって重要なものから作成する。
- 分かりやすくありのまま伝える誠実な計画・・・奇跡のマネジメントを信じない。表面を取り繕った誤魔化しに加担しない。
- 約束したことを守り続けられる計画・・・ベロシティを安定化させ、それを基に計画を立てる。
- 必要に応じて変更できる計画・・・スコープを柔軟にする。
- 感想
この計画で進めていくには、POやステークホルダーのアジャイル開発に対する理解が必要不可欠だと思った。そこが無い時に誠実に対応できる人間力も身に着けていければ良いと思う。
4部 アジャイルなプロジェクト運営
9. イテレーションの運営：実現させる
- 一言で表されるSBIをちゃんと動くソフトウェアに変換する方法
1. 分析。何もかもドキュメントにしない。必要な時に必要な分だけアウトプットする。
2. 開発。設計をしっかり行い、動く状態にしながら進んでいくのが理想。
3. テスト。適切に動作する確認をしながら進む。後に積み残しをしない。
- 感想
必要な時に必要な分だけ、というのはアジャイル開発では非常に重要な視点だと思った。ついつい、その場で詳しく全てを理解しようとしてしまうが、結局無駄に終わることがこれまでも多々あった気がする。
5部 アジャイルなプログラミング
12. ユニットテスト：動くことがわかる
アジャイルな開発プロセスのベースとなるのは確固たるプラクティスの実践。
バグを見つけた時の対処としては、必ず失敗するテストを書いて修正する。これはバグの本質を理解することになるし、自信をもってバグを修正したと言える。また、同じバグが二度と出ないことを保証する。
- 感想
テストについてまだ未熟すぎる。しっかりキャッチアップしながら沢山テストを書いていきたい。またカバレッジ（網羅性）だけを大事にするよりも、コードに自信を持てるような本質的なテストを書くことを意識する。
13. リファクタリング：技術的負債の返済
時間とともに技術的負債は必ず積み重なっていく。
積み重なってから大掛かりにリファクタリングのタスクとして切り出すのではなく（クライアントにも納得してもらいにくい）、コツコツと少しずつやっていく。
- 感想
良いコードが書きたい気持ちは強い方だと思う。だがまだまだ経験も知識も足りないと思っているので、別途リーダブルコードはまず読みたい。
14. テスト駆動開発
- 必要なテストだけ書く
- システムが既に実装されていると考えて先にテストを書く
- 感想
すぐにTDDを実践するのはプロジェクトの環境もあり難しいかもしれない。まずはテストの基礎をしっかり理解した後に挑戦していきたい。
15. 継続的インテグレーション：リリースに備える
- リファクタリングやTDDと同じく、インテグレーションもコツコツやる。
