スクラムにおける「完了」と「出荷」の話 / About Definition of Done

* LeSS の Definition of Done の解説 https://less.works/less/framework/definition-of-done
* 『完成の定義と受け入れ基準の違いは何ですか？』https://www.ryuzee.com/faq/0077/
* スクラムの定義の改訂 - スクラムアップデート2011 https://kawaguti.hateblo.jp/entry/20110807/1312652518

2022/07/05 「考えてみよう」スライドをのぞきました。「まとめ」のスライドを追加しました。

Transcript

1. スクラムにおける 「完了」と「出荷」の話 2022/07/01 Takuya Murakami (むらみん)
2. 何 • スクラムに於いてインクリメントを顧客に届ける活動の解像度を上げる。 ◦ “Definition of Done” や “Undone Work” という言葉を理解しましょう。 • スクラムガイドに書いてあることの概要は「言われればわかる」程度に理解している ことを前提とします。
3. 2つの質問の意味は同じか？ • 例として、個人がブログを開設して記事を公開できるサービスを運営しているとしま しょう • チームはスクラムに則ってプロダクトを開発しています。 • 以下のようなプロダクトバックログアイテム (PBI) があるとします。 ◦ PBI-1: 執筆者が設定するブログ記事のタイトルに絵文字を使えるようにする。 ◦ PBI-2: 読者がブログトップページから RSS フィードの URL を得られるボタンを配置する。 ◦ PBI-3: 記事中に埋め込まれた HEIC画像がブログ上で表示されるようにする。 • 以下の2つの質問への回答は同じですか？違いますか？ ◦ これらの PBI はどうなれば完了となりますか？ ◦ これらの機能は、どうなれば顧客に提供できるようになりますか？
4. Potentially Shippable Increment • 「完成したインクリメント は Potentially Shippable であるべき」と言われる。 • 日本語では「出荷判断可能なインクリメント」という。 ◦ 2011年までのスクラムガイドには記載されていた。 ◦ 今でも LeSS (Large-Scale Scrum) では紹介されている。 • プロダクトオーナーが出荷すると決めれば直ぐに出荷できるもの ◦ プロダクトを実際に出荷するかどうか判断するのはプロダクトオーナー。 ◦ プロダクトオーナーの判断以外のハードルはすべてクリアしている必要がある。 ◦ スクラムチームは出荷判断可能なインクリメントを生み出すことが直接的な仕事。
5. インクリメントが Potentially Shippable であるとは？ • それはスクラムチームが決める。スクラムは教えてくれない。 • 例えば、以下のリストをすべてクリアしていること、としましょう。 ✓ Jenkins によるユニットテストがすべて成功していること ✓ コードレビューが完了していること ✓ すべてのコードの変更が master ブランチにマージされていること ✓ 特定の性能テストをシステム全体がパスしていること ✓ staging 環境にて機能リグレッションテストをパスしていること ✓ 定められたセキュリティスキャンテストが行われていること ✓ 開発責任者によるリリース承認が下りていること ✓ マニュアル・ドキュメントが更新されていること ✓ 本番環境にデプロイされていること • 文脈によって、このリスト自体を指して “Potentially Shippable” と言う。
6. PBI に取り組むたびに、これ全部確認する？ ✓ Jenkins によるユニットテストがすべて成功していること ✓ コードレビューが完了していること ✓ すべてのコードの変更が master ブランチにマージされていること ✓ 特定の性能テストをシステム全体がパスしていること ✓ staging 環境にて機能リグレッションテストをパスしていること ✓ 定められたセキュリティスキャンテストが行われていること ✓ 開発責任者によるリリース承認が下りていること ✓ マニュアル・ドキュメントが更新されていること ✓ 本番環境にデプロイされていること PBI ごとにセキュリ ティベンダー呼んで 脆弱性診断する！？ PBI ごとに深夜に サービス停止してリ リースするの？ リグレッションテストは 1 日がかりだよ？
7. Potentially Shippable の項目を2つに分ける ✓ Jenkins によるユニットテストがすべ て成功していること ✓ コードレビューが完了していること ✓ すべてのコードの変更が master ブ ランチにマージされていること 完了の定義 (Definition of Done = DoD) ✓ staging 環境にて機能リグレッションテ ストをパスしていること ✓ 定められたセキュリティスキャンテストが 行われていること ✓ 開発責任者によるリリース承認が下り ていること ✓ マニュアル・ドキュメントが更新されてい ること ✓ 本番環境にデプロイされていること 未完了作業 (Undone Work) これらを Sprint 内で満たせば PBI は完了とする 後でやろう (別の PBI として管理する)
8. 完了の定義 (Definition of Done) • PBI の記載内容に依らず、すべての PBI を完了とする際に満たすべき品質基準を 定めた記述を完了の定義 (Definition of Done : DoD) という。 ◦ インクリメントの品質の透明化に寄与する。 ◦ 完成の品質の基準を設けてバラツキを抑制することでフロー効率が向上する。 • DoD は開発者を中心にスクラムチームが自ら定める。 • Tips ◦ DoD を満たすことの労力を少なくすることが、エンジニアリングの生産性と持続性を向上させる。 ◦ DoD に沿ってスプリントバックログ (作業計画) を出すと確実性が上がる。 ◦ 応用編: PBI の種類に依って DoD を複数定めて使い分ける。 ▪ やりすぎると成果物のバリエーションが増えてフロー効率が下がるので、 トレードオフには気をつける。
9. Undone Work • Potentially Shippable のうち DoD に含まれないものをUndone Workという。 • 特殊なPBIとして起票してPBL上で管理することで、 Potentially Shippable ではないインクリメントが顧客に届くことを防ぐ。 ◦ Undone WorkをPBIとして管理することで、リリースに向けたバーンダウンチャートが状況を正確に 表すようになる。 ◦ 大抵の場合、複数の PBIのUndone Work部分をまとめて対応する。 ◦ Undone Work解消も PBI の一種なので、プロダクトオーナーに管理する責務がある。
10. Undone Work はなぜ有害か • 価値提供の遅延 ◦ 1つのPBIが完了しても、実際に Undone Work が解消されて出荷されるまでは待ち時間となってし まう。 ◦ フロー効率 = 価値創出に費やした時間 / 価値提供のリードタイム • リスクの不透明化 ◦ リグレッションテスト、セキュリティテスト、性能テスト … などは Undone Work の定番。 ◦ 一度の試験に含まれる PBIが多数に上ると、原因の切り分けが困難になる。 ◦ 不確実性の高い Undone Work がリリース直前に残っていることがリスクである。 A B C U
11. Undone Work を薄く保つ Undone Workの総量 は… 1つのPBIから生じるUndone Work量 ✕ Undone Work を蓄積させる PBI 数 Undone Work を薄く保つには、この2つを小さくし、保つ必要がある。
12. Definition of Done を見直す ✓ Jenkins によるユニットテストがすべ て成功していること ✓ コードレビューが完了していること ✓ すべてのコードの変更が master ブ ランチにマージされていること ✓ 特定の性能テストをシステム全体が パスしていること 完了の定義 (Definition of Done = DoD) ✓ staging 環境にて機能リグレッション テストをパスしていること ✓ 定められたセキュリティスキャンテ ストが行われていること ✓ 開発責任者によるリリース承認が 下りていること ✓ マニュアル・ドキュメントが更新され ていること ✓ 本番環境にデプロイされていること 未完了作業 (Undone Work) 自動化を通じて DoD に含められるよ うにできないか？ 合法的に廃止できないか？ プロセスの見直しや自動化で省力化できないか？
13. 完了の拡張 (Expansion of Done) • Undone Work の源になる事項を DoD に含められるようにすることを 完了の拡張 (Expansion of Done) という。 ◦ 「DoD を強化する」とも言ったりする ◦ Undone を DoD に組み込むだけでなく、「 Potentially Shippable に占める DoD の割合」を高める ことが大事。 • 完了の拡張を考えて実行するのは 開発者 の責務。 ◦ スプリントレトロスペクティブ で議論すべきことのひとつは完了の拡張。 ◦ いわゆる「アジャイルのライト・ウィング」 ◦ 完了の拡張だけ頑張ってインクリメントを生み出さないのは良くないので、バランスが大事
14. 完了の定義 と 受入基準 • プロダクトバックログの完了判定をする材料として、完了の定義の他に 受け入れ基 準 (Acceptance Criteria) がある。 • 受け入れ基準は、プロダクトバックログのビジネス価値を表す。 ◦ 例えば ブログのタイトルに「にゃーん😺」と設定できるとか、 タイトル欄に :ball: と書いたら、記事表示では 🏈 に置換されるとか。 ◦ 必然的にプロダクトバックログアイテムごとに異なる。 ◦ 受け入れ基準はプロダクトバックログアイテムの内容の一部なので、プロダクトオーナーが内容に 責任を持つ。 • 一方で完了の定義は全ての PBI が共通して満たすべき事項を定めている。 ◦ 受け入れ基準はビジネス要件、完了の定義は技術要件を定めていると言える。
15. 完了の定義 と 受入基準の比較 完了の定義 受入基準 何を定めるか？ 技術的品質の水準 ビジネス価値的品質の水準 定める責務は誰にある？ 開発者 プロダクトオーナー PBI毎に定める？ PBI によらず共通 PBI ごとに異なる
16. まとめ • 「PBI が完了した状態」は、チームで合意した完了の定義を満たした状態。 ◦ Undone Work は完了していない状態。 ◦ PBIに書かれていること (受入基準を含む) が完了している状態。 • 「出荷判断可能な状態」は、Undone Work も含めて出荷するために必要な事項が 全て完了している状態 ◦ プロダクトオーナーが適切と判断したタイミングで出荷ができるように保つ。 • 出荷判断可能の要件 = 完了の定義 + Undone Work
17. refs • LeSS の Definition of Done の解説 https://less.works/less/framework/definition-of-done • 『完成の定義と受け入れ基準の違いは何ですか？』 https://www.ryuzee.com/faq/0077/ • スクラムの定義の改訂 - スクラムアップデート2011 https://kawaguti.hateblo.jp/entry/20110807/1312652518 ◦ バーンダウンチャートやリリースプランニングがスクラムガイドから削除されたタイミングで、 Undone Work への言及も無くなったという歴史的経緯がある。