「アジャイルサムライ」を読んでみた

# はじめに
###  読んだ記事やテーマの簡単な紹介
こちらはアジャイル開発を体系的にまとめた書籍です。アジャイルの始め方から運用方法までをざっくばらんに紹介しており、アジャイル開発初心者や未経験者でも分かりやすい内容になっています。
### この記事に興味を持った理由
現在は開発者として参加していますが、将来的にはスクラムマスターになるため、体系的に学びたいと思い、この記事を読みました。
# 記事の概要 ※振り返りながら大事なことをメモする
### 記事の主要なポイントや内容のまとめ
#### アジャイル開発の得意なこと
大きく分けると以下の3つです。
・顧客に対して毎週価値あるものを届けることができる
・仕様の変化に強い
・重要な機能の開発に集中することができる

#### アジャイル開発を始める前に決めること
インセプションデッキの作成が重要です。簡単に言うと、目指している方向性を共有するためのものです。
・我々はなぜここにいるのか
　　・なぜチームを組むのか、顧客は誰か、プロジェクトを始めた理由
  
・エレベーターピッチ
　　・エレベーターで上司に会ったとき、30秒で我々の仕事を伝えるならどんな文言にするか？
  
・パッケージデザイン
　　・我々のプロダクトが広告に載るとしたら、どんなデザインにするか？
  
・やらないことリスト
　・必要かどうかの見極め
 
・「ご近所さん」を探せ
　　・関係者は誰か？
  
・解決案を描く
　　・認識が一致しているかを確認するために、概要レベルのアーキテクチャ設計図を作成する
  
・夜も眠れない問題
　　・最悪の事態を想定し、その対処法を検討する
  
・期間を見極める
　　・デッドラインを把握する
  
・何を諦めるのか
　　・期間、スコープ、予算、品質
  
・何がどれだけ必要か
　　・期間やコストを見積もり、どんなチームならできるかを考える

#### アジャイル計画づくり
##### ユーザーストーリーの作成
・顧客が必要としているものを収集するために、ストーリー収集ワークショップを開催する
　　・大枠を理解するために、ペルソナ、フローチャート、シナリオなどの図をたくさん書く
・リストの作成
　・顧客が見ても分かりやすく作成する
　・独立してテストしやすい形で作成する
　・図だけでは分からないタスクも記載する

##### 概算見積もり
・初期の概算は大まかであるため、信頼しすぎないこと
・振れ幅は大体0.25倍から4倍
・日数の見積もりは信用せず、ポイントで見積もる
・1、3、5ポイントで見積もる

##### 初回の計画づくり
・マスターリストの作成
・タスクの優先順位を決める
・チームのベロシティを見積もる
・完成日の期日を仮決めする

##### イテレーションの運営
###### ユーザーストーリーの進め方
3つのステップをこなす
・分析して設計する
・開発する
・テストする

###### 分析して設計する
・必要な時に必要な分だけを分析する
　・手戻りを減らすことができる
　・最新かつ最も充実した情報で分析できる

###### 開発する
・テスト駆動開発を実施する

###### テストする
・テストはできる限り自動化を行う
・常にテストを実施して開発を行うが、それでもバグが完全になくなることはないため、受け入れテストも実施する

#### カンバン
・時間や資金に制約があるプロジェクトにはイテレーションが向いている
・問題が発生したらすぐに対処しなければならない場合や、決まった長さのイテレーションを確保できない場合には、トヨタ方式のカンバンが適している

#### 意思疎通
変化は常に起こり続けるため、顧客と定期的に顔を合わせる必要がある。その際にフィードバックをもらい、狙いを外さずに進めるために、以下の4つのミーティングを実施することが重要
1. ストーリー計画MTG
2. ショーケース
3. イテレーション計画MTG
4. ミニ振り返り

 ##### ストーリー計画MTG
 ジャストインタイム分析の結果から、見積もりの数値やテスト条件の確認を行う

##### ショーケース
イテレーションが終わったら、顧客にデモを行う場を設ける。ここで顧客からフィードバックをもらう

##### イテレーション計画
開発チームと顧客が一緒に次回のイテレーションを計画する場。ここでプロジェクト全体の進捗確認や課題の共有を行う

##### ミニ振り返り
10-15分くらいで簡単に実施する。心理的安全性を確保することが大事
（振り返りは魔女狩りではない）

質問例：
・うまくやれたことは何か？
・どうすればもっと良くできるか？

他にも、以下のような質問をしてみても面白い（場の雰囲気を変えるために）
・昨日、世界をどう変えたのか
・今日は何をぶちかますつもりか
・不運にも自分の行く手を阻んでしまったばかりに、あえなく吹き飛ばされる定めとなった難問がどんな末路をたどるか

#### 現場の状況を目に見える形で
チームの約束事や大切にすること、プロジェクトで使う言葉を共有することで、チーム内で認識の齟齬が生まれず、意思疎通がしやすくなる

#### テスト駆動開発
機能を開発する前にテストを先に書くことで、凝りすぎた解決策に走ることを避けることができる
（高橋はあまり理解できなかった...）
例：
開発する機能：
・顧客のプロフィールを作成する

テスト条件：
・新規プロフィールを保存する
・重複がないことを確認する
・基本的な入力値検査

フロー：
1. 動くコードが既に記載していると想定して、テスト条件がクリアできるかのコードを記載する
2. 次はこのテストがクリアできるコードを記載する
3. リファクタリングを行う

# 重要な情報や学び
### 読んでみた感想
アジャイル開発では、常に変化に対応するために、メンバーとフランクなコミュニケーションができる関係作りが大事だと分かりました。関係作りは当たり前ですが、対面でのコミュニケーションが重要です。コロナ後、オンラインミーティングが主流になり、この文化が薄れてきていますが、定期的に対面でのミーティングを導入することで、完全ではないにせよ、対策ができるのではないかと思います。また、チームで何を目指しているのか共通認識を持つことの重要性を軽視していたと気づきました。目的がずれると、成果物の品質やモチベーションにも大きな影響があるため、定期的に見直す場を設けたいと思います。

# 今後の応用・活用方法
・インセプションデッキの作成
　・チームが何を目指しているのか共通認識を持つために実施するべきです。それをSlackで定期的に流れるようにし、確認できるようにします。

・初回の概算見積もりを行う際には、振れ幅が大きいことを理解し、顧客にも理解してもらう必要があります
　・予想した期間で開発できないことに不安を感じていましたが、それは当たり前のことだと理解しました。

・分析をしっかり行ってからコードを記載する
　・途中まで分析したらコードを書きたくなってしまう癖があります。これをぐっと抑えて、分析で開発する機能の全体像がクリアになってからコードを記載するようにします。

・開発ではテスト駆動開発を実施する
　・テストを先に記載することはこれまでやったことがありませんが、試しに取り入れてみたいと思います。これで生産性が上がったと感じたら、さらに解像度を高めるために別の書籍でさらに学んでみたいと思います。

・今月からミニ振り返りを行うことになったので、心理的安全性を大事にすることを意識します
（去年まで心理的安全性がない環境だったので痛いほど心にしみます笑）