あなたは本物のアジャイルをしているだろうか。
アジャイルチックなウォーターフォールになっていないだろうか。
もし、あなたがユーザーストーリーを使って要求を表現し、要求一覧をプロダクトバックログにまとめたとしても、それだけでアジャイルとは言えない。
テスト駆動開発やテスト自動化をしていなければ、開発部分から従来通りの流れになっているのではないだろうか。フェーズをスプリントと呼んでみても、開発以降が開発スプリント、テストスプリント、リリーススプリントの順に進んでいるなら、それはスクラミー・フォールである。
本当のアジャイルは小粒であってもスプリント毎に動くモノをデリバリーしていく。
動くプロダクトで進捗を表現していくのがアジャイルだ。
では、なぜ後半で失速してしまうのか。
 |
|
新品価格 |
もちろん、テストファーストのエンジニアリング・プラクティスだとか、継続的なリファクタリング、ペア・プログラミング、常時結合のメカニズム、テスト自動化等々、理由はいろいろあるだろう。
今、上流をアジャイル方式で進めているなら、顧客の受入基準を意識して欲しい。
顧客の受入基準とは、お客様が完成品として受け入れてくれる基準である。そして、完了基準とは開発チームが目指すスプリント毎の完了条件である。
理想はキレイなシンクロである。同期をとれれば、スプリント完了時点で即納品できるから、お客様に喜んでもらえる。
例えば、顧客にラップトップPCを納めるとしよう。
彼らの受入基準は、以下のものだ。
- A4サイズのラップトップ
- 厚さ12ミリ以内
- 重量800グラム以内
- バッテリー持続10時間
まずは、これらの受入基準を顧客との会話から引き出す。
媒体はユーザーストーリー・カードでも付箋でもなんでもいい。プロダクトオーナーや顧客との対話から、具体的な受入基準（数値データ）を特定する。そしてストーリー・カードの裏側にチェックリストをつくるのだ。
- A4サイズ
- 厚さ12ミリ以内
- 重さ800グラム以内
- バッテリー連続使用10時間以上
次に、開発チームのスキルと経験を踏まえて完了基準（完了の定義）を決める。
戦力十分で1回のスプリントで実装できるなら、あっぱれ。
一度のスプリントで受入基準をすべて満たすのが困難であれば、スプリント毎にマイルストーンを設けて、段階的に完成品に近づけていく。各スプリントのマイルストーンはスプリントゴールになる。
例えば、
スプリント1： A4サイズで厚さ12ミリのラップトップPCをつくる。
スプリント2： 重さ800グラムに軽量化する。
スプリント3： バッテリー連続使用7時間を達成。
スプリント4： バッテリー連続使用10時間を達成。
このケースでは、受入基準を満たす完成品をつくるのに4スプリントを要することを意味している。
チーム全員で開発するので、個々のメンバのパーツを頻繁にコードベースに統合していく。
もし、スプリント4でやむなくバッテリーを大型化する場合、重さや厚みの基準を超えないようリグレッションテストをしなくてはならない。今回の変更が今までの作り込みを台無しにしないようチェックするのだ。
固定チームであればナレッジがどんどん蓄積されていく。
ペア作業を通して、チーム全員で学びあうことで、機能横断型チームに進化する。
そうすれば、作業のボトルネックも最小化できるし、担当者レベルのムラ・ムリ・ムダをなくすことができる。
開発チームが主体的に自分達の作業を計画し、実行し、ふりかえり、継続的に改善していけば、自ずとチームの総合力は上がっていく。
チームのパフォーマンスが上がれば、一つのスプリントで実装できる事が増える。結果、ますます高速で受入基準を満たせるようになる。
組織のアジャイル化の過程では、大抵ウォーター・スクラム・フォールになっているものだ。
既に上流工程でアジャイル手法を取り入れているなら、プロダクトオーナーとの対話から受入基準を明確化しよう。数値化できるものは数字で捉える。そしてチェックリストをつくりPOに確認してもらう。チェックリストはそのまま簡単なテストケースになる。
受入基準が明確になれば、あとは求められるレベルを目指して作るだけだ。開発手法を洗練したり、常時結合の仕組みを構築し、冗長なテストを自動化することで実装部分にもトラクションをかけていこう。
2つの基準のギャップを埋めよう。
ストーリーも小粒にサイジングしていくことで、毎回、お客様の受入基準を満たすプロダクト・インクリメントを届けられるようになる。
完了基準はチームの成長とともに拡張していく。
プロダクトマネジメントの要諦 The Rules of the Game of Product Management 