アジャイル開発モデル | １つの価値３つの領域思想と技術

Engineering Department employees, 1962 / Seattle Municipal Archives

アジャイル開発は２つの領域に分けられる。ひとつめは主にプロジェクトの計画・運営に関わるマネジメント領域。ふたつめは設計・開発に関わるエンジニアリング領域である。

構成

概要
マネジメント
エンジニアリング
まとめ
参考リンク
参考文献

概要

マネジメント

マネジメント領域概要

方針

インセプションデッキ

全体像を捉える

我々はなぜここにいるのか？
エレベーターピッチを作る
パッケージデザインを作る
やらないことリストを作る
「ご近所さん」を探せ

具現化させる

解決策を描く
夜も眠れなくなるような問題は何だろう？
期間を見極める
何を諦めるのかはっきりさせる
何がどれだけ必要なのか

何を諦めるのかはっきりさせる

時間
予算
品質
スコープ

何がどれだけ必要なのか

いつ完了するのか？
いくらかかるのか？

計画

アジャイルな計画づくりとは

チームの開発速度を測定して、その速度をもとに、いつ頃すべて完了させられるのかプロジェクトの完了時期を見通せるようにすることでしかない

『アジャイルサムライ』

ユーザーストーリー

顧客にとって何かしらの価値で書かれていること
- 誰のためのストーリーで
- 何をしたいか
- なぜそうしたいのか
```
<ユーザーの種類>として
<達成したいゴール>をしたい
なぜなら<理由>だからだ
```
INVEST
- 独立していること
- 交渉の余地がある
- テストができる
- 小さい、見積もれる

ストーリー収集ワークショップ

大きくて見通しのよい部屋を用意する
図をたくさん書く
ユーザーストーリーをたくさん書く
その他もろもろをプレインストーミング
リストを磨きあげる

見積もり

相対図を見積もる
ポイントで見積もる
見積もり技法
- 三角測量
- プランニングポーカー

計画の立て方

顧客にとって価値ある成果を届けられる計画
わかりやすくありのままを伝える誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画

初回の計画づくり

リリースを定義する
プロジェクト規模を見極める
優先順位をつける
チームのベロシティを見積もる
期日を仮決めする

運営

価値ある成果を毎週届ける

分析と設計：作業の段取りをする
- 「必要な分だけを、必要なときに」分析する
- それからペルソナを作ろう
- ペーパープロトタイプでいろんなデザインをどんどん作ろう
- 受け入れテストを書いて、ストーリーの満足条件を定義しよう
開発：作業する
- 自動化されたテストを書く
- 設計を継続的に発見させていき、改善し続ける
- ちゃんと動くソフトウエアであり続けるために、コードを継続的にインテグレーションする
- 顧客がシステムについて語る言葉に合わせてコードを書く
テスト：作業の結果を確認する
- カンバン・・・仕掛り(WIP:Work In Progress)にできる作業の上限を設けていること
- イテレーションのプレッシャーから開放される
- １回のイテレーションに収まらない仕事にも取り組める
- 期待をマネジメントしやすい

アジャイルな意思疎通の作戦

今回のイテレーションの作業に備える(ストーリー計画ミーティング)
今回のイテレーションのフィードバックを得る(ショーケース)
次回のイテレーション計画を立てる(イテレーション計画ミーティング)
次回のイテレーションで改善できる余地を探す(ミニふりかえり)

現場の状況を目に見えるようにする

ストーリーボード
リリースボード
ベロシティとバーンダウンチャート
インセプションデッキ(壁のスペースに余裕があれば)
チームの約束(Working Agreements)
チームが大事にすること(Shared Values)

組織

アジャイルチーム

きっちり区別しない役割分担。継続的な開発工程。チームで成果責任を果たそうする態度
チームをアジャイルにするためのコツ
- 同じ仕事場で働く
- 積極的に深く関わる顧客の存在
- 自己組織化
- 成果責任と権限移譲
- 職能横断型チーム
顧客
- 何を作るか決める
- 優先順位をつける
- スコープについて厳しい決断を下す
開発チーム
- アナリスト
- プログラム
- テスター
- UXデザイナ
- プロジェクトマネージャー

エンジニアリング

エンジニアリング領域概要

ユニットテスト

メソッドレベルの粒度で書く
目的は変更の結果が期待通りになっていることをあきらかにすること
テスコードはプロダクトコードには含めない
メリット
- 素早いフィードバックが得られる
- 極めて低コストにリグレッションテストを実行できる
- デバック時間を大幅に削減できる
- 自身を持ってデプロイできる

リファクタリング

ソフトウエアの整合性を保ちながら、設計を少しずつ改善していける方法

変数の名前変更
メソッドの名前変更
コードをシンプルに
メソッドの抽出
変数のインライン化

テスト駆動開発

以下のサイクルを回しながら、開発をすすめていく方法

レッド
グリーン
リファクタリング

ルールその１:失敗するテストをひとつ書くまでは、新しいコードを一切書かない

ルールその２:「危なっかしい所」をすべてテストする

プログラマはまず、あたかもテスト対象のプロダクトコードが既に存在しているかのように考える。そして、それを呼び出して使うのに必要な、最低限のコードをテストコードとして表現する。