スクラム開発は、スクラムガイドに書いてあることに従いながら開発を進めれば良いのですが、実践するには難しいことが沢山あります。スクラム開発で陥りやすい罠やアンチパターンについての記事が多いことがそれを物語っていますが、スクラムガイドに書いてある理論に沿ってスクラムを実践するのは容易いことではありません。私も何度もスクラム開発を経験し、実践するのことの難しさを日々感じています。
今回はそんなスクラム開発において、あまり取り上げられる機会が少ない Doneの定義について記事を書きました。
Doneの定義とは
まず、Doneの定義とはどのようなものなのか、スクラムガイドでは次のように書かれています。
～ 確約（コミットメント）：完成の定義 ～
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。
具体的にDoneの定義は、プロダクトをリリースするまでに必要な「やるべきこと」のリストです。
仕様書作成、コードをgitなどのコード管理システムにプッシュすること、テスト、マニュアル作成はもちろん、ユーザへの告知やセミナーの準備などのリリースに関連する部署への連携作業なども、「やるべきこと」として洗い出します。
「やるべきこと」が洗い出せたら、次にそれらがスプリントに含めることができるならば「Done」、含めることができなければ「Undone」に分けます。
Done の例
- 仕様書・設計書
- コーディング
- 単体テスト
- 結合テスト
Undone の例
- マニュアル作成
- システムテスト
- 脆弱性診断
- オープンソースソフトウェアのライセンスチェック
- テスト版準備
- 使用許諾・サービス規約の作成・更新
- 知財登録(ロゴ、商標、特許)確認
- 製品カタログ作成、Web掲載、製品紹介セミナー・Webinar
- 価格表・セールスガイド
- リリース承認
- 告知メール準備・送信
私が受けたスクラム研修では、毎スプリントいつもできるものがDoneに入り、1スプリントでもできなければ、即Undone行きとなると聞きました。UndoneのものがDoneに行く場合は5スプリント程度できていれば、検討してもよいとのことでした。厳しい...
Doneの定義の重要性
Doneの定義を行うことの一番重要な点は、Undoneが見えてくることだと思います。
Undoneは、スプリントが完了してからユーザにプロダクトを届けるまでに発生するリスク要因といえるものを多く含んでいます。たとえば、Undoneに脆弱性診断がリストされており、リリース前に脆弱性診断を行ったらプロダクトに深刻な脆弱性が見つかったとします。すると脆弱性の原因となったソースが作り込まれたスプリント以降の成果物は修正の可能性があり、修正が必要ということはテストなども再考することになります。リリース承認やユーザ告知など、チーム外で行うタスクなどは、Undoneにあってもプロダクトへの直接リスクは少ないといえます。しかし、開発者が対処すべき非機能系などの作り手として保証しなければならない品質は、Undoneからできるだけ排除すべきです。そうしなければ、スクラム開発が目標とする、スプリント毎にリリース可能なプロダクトを作る、という考えに沿うことができません。開発者が対処すべきUndoneは、いわばスプリント内で完了することができない、いわば「負債」といえます。
リリースのリスク要因となる負債（Undone）をあぶり出すのが、Doneの定義の重要な点だと私は考えています。
バーンスプリント（炎上スプリント）をできるだけ避け、こまめな回収を
負債であるUndoneはこまめに回収する必要があります。
なぜなら、リリース前の最後にUndoneを回収するスプリントを行うと、それはいわゆるバーンスプリント（炎上スプリント）となるからです。バーンスプリントで問題が発見されると、そのスプリント以前のスプリントは問題のリスクを潜在的に持っていることになります。
先ほどの脆弱性の問題を例に挙げれば、脆弱性が無いと信用できる状態は、前回脆弱性診断を行ったUndone回収スプリントとなります。その間のスプリントは、脆弱性につながるコードを作り込んだ可能性のあるスプリントとなります。そうならないよう、プロダクトへの直接リスクとなるようなUndoneは細かく回収すべきだと言えます。
その考えからいくと、マニュアル作成などのドキュメンテーションもDoneに含めたいところです。マニュアルで案内するには情報が多すぎたり複雑すぎるなどの、製品仕様を見直す問題が発生するリスクもゼロではないからです。
出荷可能なポテンシャルを持ったインクリメントを作る
スクラムではスプリントの成果物（プロダクト）をインクリメントと呼びます。
インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。
インクリメントは、スプリント毎にリリース可能なインクリメントでなければなりません。”リリース可能な”は、正確に言うと「出荷可能なポテンシャルを持ったインクリメント」（Potentially Shippable Product Increment）です。つまり、スプリントが完了した時のインクリメントとリリースに必要なすべてのUndoneを行うスプリントを行えば、リリースできるということです。その状態を毎スプリント保つことが、出荷可能なポテンシャルを持ったインクリメントを作るといえます。この時、リリースに必要なすべてのUndoneの数が多いほど、実際のリリースまでのリスクや期間が多く必要となります。
ユーザに価値を素早く届けるならば、やはり、Undoneの項目をできるだけ減らす必要があります。
まとめ
- Doneの定義はプロダクトをリリースするまでに必要な「やるべきこと」のリスト
- Doneの定義を行うと負債であるUndoneが見えてくる
- バーンスプリント（炎上スプリント）になるのでUndoneは細かく回収すべき
- ユーザに価値を素早く届けるならUndoneの項目をできるだけ減らす
Doneの定義を行って、Undoneをあぶり出し、Undoneはできるだけ減らす。
これに尽きます。
とはいえ、かく言う私が参加するプロジェクトもDoneの定義を最初に行ったきり放置となってる有様です...
目を背けずに改めてDoneの定義をしっかり考え直したいと思います。