この記事の概要
「アジャイルサムライ」の第四部を読み、自分なりの解釈をまとめたものです。
アジャイルに詳しい方は、認識の誤りやご意見をいただけたらと嬉しいです。
第四部: アジャイルなプロジェクト運用
アジャイル運用
アジャイルの運用ではイテレーションという決められた期間でアウトプットを出す。
優先順位やプロジェクトの方向性の変更があっても、その期間が終了した時点で、軌道修正していく。
ただし、イテレーションの途中では変更しない。
ステップ１：分析と設計：作業の段取りをする
アジャイルな分析は
- 必要な分だけを
- 必要な時に
行う。
最初はインデックスカードと会話程度の最小な設計から始まり、一枚のドキュメント、複数枚のドキュメントへと分析・設計の具体性を上げていく。
ジャストインタイム分析
実際に取り掛かる直前になってから分析すること
- 最新かつ最も充実した情報で分析できる
- 顧客も学ぶ機会が増やせているので、プロジェクトが進むにつれて分析が上手くなる
- 手戻りが大量に発生することを避けられる
分析や設計はフォローチャートを作ったり、ペルソナを作成することでソフトウェアの役割を簡単に説明できるようにする。
デザインの段階に入れば、ペーパプロトタイプで様々な選択肢を用意する。
受入テストを書いてストーリーの満足条件を定義する。
ステップ２：開発：作業する
- 自動化されたテストを書く
- 設計を継続的に発展させて、改善を続ける
- コードを継続的にインテグレーションする
- 顧客がシステムについて語る言葉に合わせてコードを書く
ステップ３：テスト：作業の結果を確認する
リリース前には正式な受入テストを行う。
イテレーションでやるべきこと
- 作業に備える：ストーリ計画ミーティング
- フィードバックを得る：ショーケース
- 計画を立てる：イテレーション計画ミーティング
- 改善できる余地を探す：振り返り
イテレーションゼロ
- ストーリに取り掛かる前の準備期間。
- ビルドの自動化や環境構築などの開発のための段取りを済ませる時間。
- イテレーションが始まる前に必要。
ストーリ計画ミーティング
- 顧客と一緒に受け入れてテスト条件をレビュー
- 開発チームが見積もりの数値を確認
- 必要な調査に漏れがないかどうかを確認
- 分析を終えていないストーリに着手することを防ぐ
ショーケース
チームが成し遂げた成果をお披露目して、顧客からフィードバックを得る。
イテレーション計画ミーティング
- 開発チームと顧客が一緒になって、イテレーションの作業を計画する
- プロジェクトの健康状態も確認する。
- 何か必要なものがないか
- 厄介な問題がないか
できる限り可視化してステークホルダーに状況を共有する。
振り返り
- 10-15分だけ短く、集中して行う。
- 定期的に集まって、上手く行ったことやうまくやるためにどうすればいいかを話し合う。
- うまくやれたこと
- お互いの行いを褒め合う
- もっとうまくやれること
- なんでも良いので課題を共有しあって、集中力を取りもぢして、頑張って取り組もうという新たな気持ちをえる。
- うまくやれたこと
デイリースタンドアップ
- 昨日やったこと
- 今日やること
- 開発速度を下げてしまう何か
を短い時間で共有しあう
カンバン
カンバンは仕事の流れをスムーズにすることが目的
運用業務などの割り込みが多い場合はカンバンが良い。
- イテレーションのプレッシャーから解放される。
- 成果に対する期待マネジメントの必要がなくなる。
- １回のイテレーションに治らない仕事にも取り組める
- 数週間かかるタスクはそのまま扱い続ければいい
- 期待をマネジメントしやすい
- ストーリポイントはいらない。
- 見積もりの説明もいらない。
- 一度にこなせる時ごとの量が限られているだけ。