アジャイルサムライ
takigucheアジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
takiguche第１章 ざっくりわかるアジャイル開発
1.1 価値ある成果を毎週届ける
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
価値のある成果を毎週必ず届けるために、開発チームは以下の６つを大事にしなければならない。
- 大きな問題は小さくする
- 本当に大事なことに集中して、それ以外のことは忘れる
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- 必要とあらば進路を変える
- 成果責任を果たす
1.2 アジャイルな計画づくりがうまくいく理由
アジャイルのプロジェクト計画はマスターストーリーリストとかユーザーストーリーといったこじゃれた名前で呼ぶ。
- マスターストーリーリスト
- ユーザーストーリー（ex. 1日 ユーザーを追加する）
- ユーザーストーリー（ex. 2日 注文を印刷する）
- ユーザーストーリー（ex. 5日 プロフィールを作成する）
- ユーザーストーリー（ex. 1日 ホテルを更新する）
- ユーザーストーリー（ex. 5日 領収書を印刷する）
マスターストーリーリストは、ユーザーストーリーをまとめたもの。ユーザーストーリーは、開発対象となるソフトウェアで顧客が実現したいと思うフィーチャ（ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手などの総称。）のこと。
これらのユーザーストーリーを１週間か２週間でイテレーションし、テスト済みのちゃんと動くソフトウェアへと変換していく。
開発チームは１回のイテレーションで完了させられるストーリーの量＝ベロシティを実測する。
やるべきことが多すぎるときは、やることを減らすだけ。つまりスコープを柔軟にしておくことがプロジェクトをやり遂げるための秘訣だ。
1.3 「完了」とは完了のことだ
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル開発の「完了の定義」は「フィーチャを届ける」こと。つまりコードをリリース可能にするためのあらゆる作業を終わらせているということ。ひとつのユーザーストーリーには分析、設計、コーディング、テスト、その他もろもろが含まれる。
1.4 ３つの真実
- プロジェクトの開始時点にすべての要求を集めることはできない
- 集めたところで、要求はどれも必ずといっていいほど変わる
- やるべきことはいつだって与えられた時間と資金よりも多い
takiguche第２章 アジャイルチームの紹介
2.1 アジャイルなプロジェクトはどこが違うのか
- アジャイル開発では役割分担がはっきりと分かれていない。肩書きも役割も関係ない。
- 分析、設計、実装、テストといった開発工程が途切れることなく連続的になっている。
- チームが一丸となって成果責任を果たす。
2.2 チームをアジャイルにするためのコツ
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
1. 同じ仕事場で働く
2. 積極的に深く関わる顧客の存在
3. 自己組織化
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
自己組織化とは、自らのエゴを出しすぎないようにしながら、チームで力を合わせるということ。アジャイルチームは、与えられた目標をどうやって達成するかを一歩下がった視点からみんなで客観的に考えることをできるようになる必要がある。
- チームを自己組織化するためのヒント
- 自分たちで計画を立てる。見積もりも自分たちでやる。自分たちのプロジェクトなんだという
当事者意識を持つ。 - 肩書きや役割を気にせずにテスト済みのちゃんと動くソフトウェアを提供し続けることにこそ心を砕く。
- 自分から動ける人を探す。指示待ち人間はアジャイルチームには必要ない。
- 自分たちで計画を立てる。見積もりも自分たちでやる。自分たちのプロジェクトなんだという
4. 成果責任と権限委譲
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
権限があれば開発チームは、自発的に自分たちのやり方で物事を進めていくようになる。
5. 職能横断型チーム
フルスタックエンジニアであれ。要求は変化するため誰かのチーズが消えたとしてもフォローできるようになろうという話。
「チーズはどこへ消えた」
2.3 よくある役割分担
- アジャイルな顧客
- 開発チーム
- アジャイルなアナリスト
- アジャイルなプログラマ
- アジャイルなテスター
- アジャイルなプロジェクトマネージャ
- アジャイルなUXデザイナ
2.4 チームメンバーを探すコツ
いろんな帽子をかぶることに慣れているゼネラリスト。あるときはコーディング。あるときはテスター。
曖昧な状況に抵抗がない人。状況は変わるもの。
我を張らない人。チームがまるで合唱団のように楽しめる人。
takiguche第３章 みんなをバスに乗せる
3.1 プロジェクトがだめになるのはなぜか
関係者の認識が揃っていないから。「顧客が本当に必要だったもの」「7RedLines」
3.3 インセプションデッキのご紹介
インセプションデッキはプロジェクトの核心まで煮詰めて抽出した共通理解を開発チームだけではなく、より広範囲なプロジェクト関係者全員（いわゆるプロジェクトコミュニティ）へ手軽に伝えるためのツールだ。
インセプションデッキの前半では、プロジェクトの背後にある「なぜ」をあきらかにする。
後半では、具体的な解決案とどこからどこまでをプロジェクトの陣地とするかを決める方法を紹介する。
takiguche第４章 全体像を捉える
インセプションデッキの前半では「なぜ」をあきらかにする。
なぜこのプロジェクトをやるのか？
顧客は何を求めているのか？
スコープは何か？
何をやらないのか？諦めるのか？
takiguche第５章 具現化させる
インセプションデッキの後半は具体的な解決案とスコープをあきらかにする。
解決案は顧客の前で話し合って、それを図として示す。目で見て確認したほうが想定しているスコープやプロジェクトの境界、リスクを伝えられる。
アーキテクチャの図は「もし〜だったらどうなる？」というシナリオをいくつか検討しリスクを話し合う。
マイケル・ブルームバーグのリスク管理は、
- 失敗しそうなありとあらゆることを紙に書き出す
- それが起きるのを防ぐにはどうしたらいいかを真剣に考える
- 書き出した紙を破り捨てる
そうだ。
変化に対応するためにプロジェクトの期間は最大でも6ヶ月とするべきだ。これを超えるとプロジェクト失敗のリスクが高まる。
何を諦めるのかをしっかりと見極める。
- 時間
- 予算
- 品質
- スコープ
どんなプロジェクトにも上記は待ち受けており、いつも必ず破壊と混乱を引き起こすのだ。
- スケジュールは圧縮される
- 予算は削減される
- バグのリストは長くなる
- やるべきことは際限なく沸き出てくる
takigucheインセプションデッキのまとめ
- 作ろうとしているものは何なのか、それはなぜ必要なのか。
- このプロジェクトの魅力はどこにあるのか。
- プロジェクトで解決したい課題は何か。
- 「ご近所さん」は誰なのか。
- 解決策はどんな風になりそうか。
- 向きあうことになりそうな課題とリスクは何か。
- プロジェクトの期間はどれぐらいの長さになりそうか。
- 柔軟に対応すべきところはどこか。
- （期間や費用は）ざっくり何がどれだけ必要なのか。
takiguche第６章 ユーザーストーリーを集める
6.1 文書化の難しさ
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
顧客要求の重厚な文書化はうまく機能したことがない。ものすごい時間とエネルギーを費やしても何を成し遂げたいかよりも何を書くべきかになってしまっている。
文書に頼りすぎる弊害は他にもある。
- 変化に対処できない
- → 文書で合意したことを変えることは難しい
- 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる
- → 仕様確定（凍結）したあとの変更は難しい
- 下手な推測や誤った前提を招き寄せる
- → 不確実なことを考えてもしょうがない
- 多くの時間を無駄にする
- → 頑張って文書化をしても読まれない
「文書に頼りすぎてはいけない」というものはアジャイル開発の重要な原則のひとつだ。
「ソフトウェアアーキテクトが知るべき97のこと - 500行の仕様書より1行のコード」
6.2 そこでユーザーストーリーですよ
ユーザーストーリーは顧客がソフトウェアで実現したいと思っているフィーチャのを簡潔に記述したものだ。詳細は顧客と詰めていくとして、ストーリーにはフィーチャの本質を捉えるキーワードを書き留めておき、あとで顧客と何の話をするのか思い出すようにする。なぜキーワードだけなのか、それは思いついたばかりの時点では、それが本当に必要になるのか分からないからだ。
6.2 よく書けているユーザーストーリーとは
顧客にとっての価値が書かれているか。ビジネスの観点で評価できるシンプルな言葉づかいをする。
ユーザーストーリーに備わっている6つの要素（INVEST）
- 独立している（Independent）
- 交渉の余地がある（Negotiable）
- 価値のある（Valuable）
- 見積もれる（Estimatable）
- 小さい（Small）
- テストできる（Testable）
6.4 ストーリー収集ワークショップを開催しよう
顧客、開発者、その他関係者が集まって、フィーチャリストを作成するためにワークショップをする。このときになるべく多くの事柄を俎上にのせて全体像をつかむことが目的だ。（インセプションデッキで作成したやらないことリストはここで役に立つ。）
ブレストをするためにはなるべくたくさんの図を描く。図はアイデアのブレストにはうってつけだ。
（ペルソナ、フローチャート、シナリオ、システム概要図、プロセスフロー、コンセプトデザイン、絵コンテ、ペーパープロトタイプなど）
そしてストーリーは10〜40くらい書き出せれば十分だろう。これで向こう3ヶ月〜6ヶ月くらいはもつ。
ユーザーストーリーマッピングはストーリーを整理するには有効。
takiguche第７章 見積り：当てずっぽうの奥義
不確実性コーン：初期段階の見積りには大きな誤差がある
何も決まっていない状態の見積りなんて当てずっぽうだ。（超概算見積りなんてものは本当にテキトウだし、しかも楽観的すぎる）。不確実性コーンにある通り最大で４倍の誤差があるかもしれないということだ。端的にいえば前もって正確に見積もるなんて無理。
「このプロジェクトをやり遂げられそうなのか！？」（それも与えられた期間とリソースで）
プロジェクト初期段階の概算見積りには大きな誤差があるため、これに答えてくれるだけで良い。
とはいうもののプロジェクトを始めるためには予算が必要だし、プロジェクトにどんな成果が期待できるのか見通しも立てないといけない。そんなときのポイントを紹介する。
- ストーリーそれぞれを互いに相対的なサイズで見積もる
- ポイントをもとにして進捗を追跡する
人間は相対見積りであればうまくこなせる研究調査があるらしい。例えば、目の前に岩が転がっていたとする。片方の岩がもう片方の岩に対してどれぐらい大きいかは非常に正確に見積もれるそうだ。
たしかに絶対サイズは不明でも相対サイズであれば、だいたい２倍のサイズと答えることができる。
なので、アジャイル開発では見積りに日数を使わないで、単なる「ポイント」で見積もることを推奨している。このポイントは営業日の日数とは対応させないようにすることがキモだ。
見積り技法
- Tシャツサイズ
- S（楽勝）
- M（やれないことはない）
- L（ちょっと大変）
- 三角測量
- 基準となるストーリーをもとに残りのストーリーを 1pt、3pt、5pt のように振り分ける
- プラニングポーカー
- メンバー全員の見積り結果が一致するまで話し合う。食い違う場合はとことん会話をする。
takiguche第８章 アジャイルな計画づくり：現実と向きあう
チームの進捗はベロシティを使って計測する。ベロシティはチームの生産性の計測と、プロジェクトの完了日の見通しを立てるのに使われる。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
プロジェクトは始まると何が起きるのか分からない。例えば、突然の退職者、納期の短縮や予算の縮小など。
やれることに限度はあるため、スコープを柔軟にしておくこと。 これこそがアジャイルプロジェクトで計画を誠実なものに保ち続けるための秘訣だ。新しくスコープが追加されたのなら同等のスコープを削ることでプロジェクトで作業できる範囲内に留めておける。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
アジャイルではリリース単位のことを MMF （Minimal Marketable FeatureSet）と呼ぶことがある。
最初のリリースに含めるストーリーを選ぶときには「Minimal、最少であること」と「Marketable、市場価値があること」が２本の大きな柱となる。
初回の計画づくり
- マスターストーリーリストを作る
- プロジェクト規模を見極める
- 優先順位をつける
- チームのベロシティを見積もる
チームのベロシティはイテレーションを3〜4回もこなせばだんだん落ち着いてくるはずだ - 期日を仮決めする
takiguche第９章 イテレーションの運営：実現させる
イテレーションは期間を固定したタイムボックス（1週間か2週間）だ。イテレーションは具体的な成果をあげていくためのエンジンだ。イテレーションのゴールは顧客にとって価値ある成果を届けることだ。
イテレーションの期間内にテスト済みのちゃんと動くソフトウェアを実装しなきゃならない。
ユーザーストーリーは以下の３つのステップをこなしていく
- 分析して設計する（作業の段取りをする）
「必要な分だけを、必要なときに」作る - 開発する（実際に作業する）
ペアプロは有効な手段だ - テストする（作業の結果を確認する）
自動的で継続的なテストを書くことが大事
イテレーション・ゼロ
開発作業の準備を整えるのがイテレーション・ゼロだ。
「プログラマが知るべき97のこと - すばやくデプロイ、こまめにデプロイ」
takiguche第１０章 アジャイルな意思疎通の作戦
- 今回のイテレーションの作業に備える（ストーリー計画ミーティング）
ストーリーのサイズや必要な調査に漏れがないことを確認する - 今回のイテレーションのフィードバックに備える（ショーケース）
動くソフトウェアを顧客にデモする - 次回のイテレーション計画を立てる（イテレーション計画ミーティング）
プロジェクトの健康状態（快晴、曇り、嵐）もこのタイミングで確認する - 次回のイテレーションで改善できる余地を探す（ミニふりかえり）
チームがもっと効率を高めることができるのかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
第１１章 現場の状況を目に見えるようにする
空港のフライト案内板はいろんなことが一目瞭然で分かりやすいので例えられている。今はどうなっているのか。どれがキャンセルされるのか。
不測の事態が起こってもプロジェクトを説明できるようにしておく。
・インセプションデッキ
・リリースボード
・ストーリーボード
・チームのベロシティ、プロジェクトのバーンダウンチャート
・バグの監視
・ユビキタス言語（プロジェクトでの共通用語）
チームの意思を明確にするのも大事
takiguche第１２章 ユニットテスト：動くことがわかる
ユニットテストはメソッドレベルの小さい粒度で書く。
テストコードをたくさん書くメリットはいくつかある。
- 素早いフィードバックを得られる。
- 極めて低コストにリグレッションテストを実行できる。
- デバッグ時間を大幅に削減できる。
- 自信を持ってデプロイできる。
takiguche第１３章 リファクタリング：技術的負債の返済
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
積極果敢にリファクタリングをどんどんする！
- 変数やメソッドの名前変更
- 変数のインライン化
- メソッドの抽出
takiguche第１４章 テスト駆動開発
TDDはこれを見ておくとなんとなく理解できる。
テストコードは動くドキュメントである
「TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング」
takiguche第１５章 継続的インテグレーション：リリースに備える
- ソースコードリポジトリ
- チェックイン手順
- ビルドの自動化
- 作業単位を小さくしようとする姿勢
