プログラマの思索

認定スクラムマスタ研修を受けた時に、感銘を受けた考え方の一つに、「Doneの範囲はチームの能力に比例する」という内容がある。
ラフなメモ書き。

【元ネタ】
Doneの定義を共有する「Doneの定義シート」 BIGLOBEエンジニアブログ

メモ帳: スクラム道バーストに参加した感想＆doneの定義の話

【1】チームがタスクやプロダクトのDoneの条件を決めるスプリント計画ミーティングがある。
その時、納品可能(shippable)なモジュールというDoneの条件はどのような内容になるか？
実際にラフにブレーンストーミングしながら書き上げてみたら、以下のようにたくさん出てきた。

プログラムの単体テストが終わった。
システムテスト、受け入れテストが終わった。
バグが無くなった。
負荷テストをやって、性能やスケーラビリティに問題がない。
レビューが終わった。
リリースノートを書く。
モジュールのパッケージングが終わった。
リリース計画や障害復旧の計画を作った。
デプロイ用スクリプトを作った。
ソフトウェア製品の値段を決めた。
ユーザマニュアルを作った。
契約が締結された。

つまり、システムが納品可能とチームが決定するには、たくさんのDoneの条件をクリアする必要がある。
普通のチームならば、最後のDoneの条件まで辿り着かないかもしれない。
全てのDoneの条件を満たさずにリリースしていたならば、リスバーガーの例え話のように、品質不良の商品を顧客へそのまま押し付けていたことになる。

チームが達成可能なDoneの範囲は、チームの開発能力、生産性に比例しているのだ。
例えば、せいぜい受入テストまでがそのチームのDoneの定義になっているならば、それ以外のDoneの条件を満たすだけの能力を持っていないことを意味する。
実際、負荷テストの方法を知らなければ、性能改善やスケーラビリティ向上の計画や作業を見積もることもできないだろう。
そして、製品の値段の付け方やソフトウェアの契約方法を知らなければ、どれだけの作業が必要なのか、も想像することができないだろう。

【2】AgileTourOsaka2012で、藤原さんは、チームのふりかえりでたびたび、Doneの条件に関する議論が出てきたと言っていた。

AgileTourOsaka2012の感想　#agileto2012: プログラマの思索

その発言の文脈では、チームやメンバーの能力が低いために、当初はDoneの条件の範囲がとても小さかったけれども、スプリントを経るごとにメンバーが経験を積んでチームで作業できる範囲が広がったために、Doneの条件の範囲が広がり、Doneの条件を再定義しなくてはならなかったことを意味しているのだろうと思う。

その話から類推すると、ふりかえりでDoneの条件を再定義する議論が生まれたならば、チームが経験を積んでDoneの条件の範囲を広げようとするタイミングであると推測することもできる。
Doneの条件の範囲を広げることで、作業できる範囲を広げるだけでなく、システムの品質をどんどん上げることができるし、プロセスを拡張して生産性が上がってきていることを意味している。

経験的には、最初のスプリントではDoneの範囲は狭いのが普通。
初めてのチーム、初めての技術でプロジェクト運営しているならば、尚更だ。
いわゆる「Doneの拡張」は、スプリント後にチームが経験値を増やすことで、可能になってくるわけだ。

全てのDoneが達成可能になるという意味は「組織（会社）の柔軟性が増している」と同義。
つまり、顧客の変化、市場の変化に対し、組織がDoneの条件の範囲をコントロールすることで状況に対処できることを示している。

【3】逆にDoneの定義をスプリント途中で減らしてもいいのか？
それは駄目だ。
Doneの範囲を減らせば、チームが作業の手抜きをしてもいいと学習してしまう。

未完了の作業、つまりUndone作業が増えると、スケジュールが遅延したり、想定しないリスクが増える。
スケジュールの遅延は、組織の柔軟性を妨害する。
リスクの増加は、作業結果やチーム間のコミュニケーションの透明化（オープン、Transparency）を少なくする。

Undone作業が増えてスプリント内で完了できる見込みがなくなると、次のスプリントへ延期することになる。
すると、定期的に、Undone作業のみを実施するためだけの「Releaseスプリント」という特殊なスプリントを実施せざるを得なくなる。
例えば、最後の結合テストのバグが未解決のまま残ったり、致命的な性能劣化の症状が残ったままになった場合など。

「Releaseスプリント」は、プロダクトオーナーから見れば、何の価値も産まない。
本来ならば、Releaseスプリントの前に完了させておくべき作業がUndone作業として残っているからだ。

だから、Googleの80％ルールのように、チームの作業負荷は故意に80％にしておき、20％の余裕時間で、リファクタリングや更なるテスト追加、性能テストなどを実施して品質向上に努めておく戦略が勧められるのだろう。

【4】チケット駆動開発でよく聞かれる質問として、「チケットの粒度」だけでなく「チケットの完了条件」もよく出てくる。
その理由の一つは、Doneの条件の範囲がチームの経験値やチームの能力の向上によって、変わってくることもあげられるだろう。

Scrumに関しては今後も色々考えてみる。