# アジャイルサムライ　第Ⅳ部　アジャイルなプロジェクト運営
## 第9章　イテレーションの運営：実現させる
### 9.1 価値ある成果を毎週届ける　
#### 毎週実践すべきこと
* 【分析】は**必要な時に必要なだけ！**　全部やってる暇はない。
* 【開発】は**しっかりと！**　手戻りしている暇はない。
* 【テスト】は**早めに！こまめに！**　イテレーションの終わりには動くように。
### 9.2 アジャイルなイテレーション
* イテレーション（スクラムでいうスプリント）は1～2週間。
* 軌道修正はイテレーションの終了時に行う。
### 9.3~9.6 アジャイルな開発の進め方
#### ステップ1　【分析】
**必要なだけ書く！必要な時に分析する！**
1. まずは**必要な分だけを文書にまとめる。** →インデックスカードと対話
* ストーリーの概要、必要なタスク、テストすべき項目程度が挙げられれば良い。
2. **必要な時に分析する。**
* 具体的には、実装イテレーションが近づいたら、**1つ前のイテレーション**で分析を行っておく。→**ジャストインタイム分析**
* ジャストインタイム分析には以下のような効果がある。
* **最新かつ最も充実した情報に基づいた分析**が可能である。
* 顧客もチームも学ぶ機会を増やせる。
* 分析は、すればするほどうまくなっていく。
* 手戻りの大発生を予防する。
3. 分析に必要なツール達
* **フローチャート**：処理の流れを追うために必要不可欠である。
* **ペルソナ**：システムに関わる**各ユーザーの役割や特徴、典型的な姿**等を記したものである。
* **ペーパープロトタイプ**：紙面でUIデザインを考えたもの。手軽にたくさん作れるのが特徴である。
* 大切なのは、ツールをどう使うかではなく、**創意工夫を凝らす**ことである。
#### ステップ2　【開発】
ジャストインタイム分析したストーリーを「**金塊**」に変えていく。
＝**リリース可能な動くソフトウェア（MVP）として実装する。**
##### 規律に基づいた開発
* 自動化されたテストを書く。
* 設計を継続的に発展させ、カイゼンし続ける。
* 動くソフトウェアであるよう、定期的にインテグレーションする。
* 顧客がシステムについて語る言葉に合わせてコードを書く。

##### イテレーション・ゼロ
**イテレーション・ゼロ**とは、イテレーション開始前の準備期間のことである。
イテレーション開始前に、必要な準備は整えておく必要がある。
具体的には、開発環境や言語環境、gitなどのコードの管理、ビルドの自動化など。
#### ステップ3【テスト】
ステップ1で策定したテスト条件に沿って、動作の可否を確認する。
顧客にデモンストレーションしてもらい、正しく動くかどうかをチェックする。また顧客の挙動も同時に検証すると良い。
なお、リリース直前には「**受け入れテスト**」が必要である。これは、アジャイル開発者の目標として、**いつでも受け入れテストができるようにする**ことが挙げられるため。
### 9.7 カンバン
カンバンはストーリーボードと似ているが、いくつか決定的な違いがある。
* **仕掛かり(WIP:Work in Progress)に制限を設けている。** チームが作業できる最大値を予め決めておく。
* カンバンは、**イテレーションにとらわれない。**
* 優先順位が高い順に取り組めばよいため、イテレーションのプレッシャーから解放される。
* 1回のイテレーションで収まらない仕事にも取り組める。
* 期待をマネジメントしやすい。

## 第10章　アジャイルな意思疎通の作戦
### 10.1 イテレーションでやるべき4つのこと
* **期待をマネジメントする**
* **フィードバックを得る**
この2点を意識したうえで、イテレーションごとに取り組むべきことが4つある。
### 10.2 ストーリー計画ミーティング
ストーリーが始まる前に、各種準備が整っていることを全員で確かめる。必要な調査に漏れがないかも確認する。
なお、**これはどのアジャイル手法の解説にも載っていない。やり方は一つじゃないアジャイルの美しさである。**
挑戦して失敗しても良い。主導権を手放さないようにさえすればよい。
### 10.3 ショーケース（スクラムのスプリントレビュー）
イテレーションの成果を披露して、顧客から本物のフィードバックを得るための時間である。
**動くようにチームが奮闘し、「完了」させた成果**であり、本番環境にリリースしても良いコードである。
### 10.4 イテレーション計画ミーティング（スクラムのスプリントプランニング）
開発チームと顧客が一緒になって、次回のイテレーションの作業を計画する。
チームのベロシティを確認し、次に取り掛かるストーリーを整理する。
そして、次回のイテレーションでチーム全体としてコミットメントする作業量を見極める。
顧客との話し合いやオススメの作戦がある場合、その旨もここで伝える。

バーンダウンチャートは、**ありのままのプロジェクトの現状**を伝えてくれる。
良い情報も悪い情報も早めに届けることがアジャイルの流儀である。
### 10.5 ミニ振り返り（スクラムのスプリントレトロスペクティブ）
10~15分程度で開催する、短期間ミーティングである。
チーム全員が定期的に話し合い、うまくいったことや課題のカイゼン策等を話し合う。
ここで大切なのは、チームに**心理的安全性が働いているか**どうかである。
振り返りの最優先事項は、魔女狩りのような失敗の追及ではなく、
**自分のできる全力を尽くした中で、上手くいったことは続け、カイゼン点を見直そうという趣旨である。**
お互いに敬意を持った振る舞いが大切である。

### 10.6 デイリースタンドアップ（スクラムのデイリースクラム）
毎日素早くチーム内の情報を同期できるように行うミーティングである。
デイリーは会議体としては開催せず、メンバーが毎日自主的に集まることで行う。

### 10.7 自分たちに合った手段を選ぶ
**行う手段は人それぞれであり、チームによって異なる**。
どんなやり方が役に立つのかを見極めて実践していけばよい。

### ケーススタディ
* ストーリーは、進捗によらず完了or未完了の二択！未完了のストーリーは次のイテレーションに持ち越す。
* チームで価値のないミーティングだという認識が共有できているならば、止めても良い。
* 何も価値が生み出せなくても、顧客にきちんと報告。その状況が素晴らしい教師となることがある。

## 第11章　現場の状況を目に見えるようにする
### 11.1, 11.2　経営陣からの理不尽な要求→貼りもの
経営陣から理不尽な要求が突き付けられた場合、一度現場を見てもらうと良い。
以下のものを見せて説明して回る。
* インセプションデッキ
* リリースボード：イテレーションごとに完了したストーリーと、残っているストーリー(スクラムのプロダクトバックログ)を見える化したもの。
* ストーリーボード：現イテレーションのユーザーストーリーの状況。未着手（スクラムのスプリントバックログ）、仕掛かり（実行中）、テスト待ち、完了の4つ。
* ベロシティとバーンダウンチャート
こうした「貼りもの」は、ステークホルダーの期待マネジメントや、プロジェクトの現状を明らかにする効果がある。
もちろん、これらの真価は取り組む物事をはっきりさせ、仕事を支援することにある。
### 11.3　11.4　チーム内の合意事項をまとめて共有する
* ワーキングアグリーメント：チームとしての目標やミーティングの開催時間などを共有する。
* Shared Values（チームが大事にすること）：チームとしての意識や教訓等を共有する。
* プロジェクト用語の共有：キーワードの定義を共有して、全ての成果物に正しく反映できるようにする。
### 11.5　バグを監視する
バグを増やさないためには、日ごろから監視を怠らないこと。
イテレーションの10％程度をバグ取りに費やすという対策もある。

###### tags: `読書`