Scrumにおける完成とは何か #RSGT2021

2021/1/7にRegional Scrum Gathering Tokyoで発表したときの資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. スクラムにおける「完成」とはなにか？ 2021/1/7 Regional Scrum Gathering Tokyo 2021 株式会社アトラクタ取締役CTO/アジャイルコーチ 吉羽龍太郎
2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自動化、、組 織改革を中心にオンサイトでのコンサルティングとトレーニングを提供。Scrum Alliance認定チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定 スクラムデベロッパー(CSD) / 認定スクラムマスター(CSM) / 認定スクラムプロ ダクトオーナー(CSPO)。青山学院大学非常勤講師 2
3. 新刊のご紹介 ✤ 『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』 ✤ メリッサ・ペリ著、拙訳 ✤ オライリー・ジャパン ✤ 2020/10/26 発売 ✤ 税込み2640円 ✤ 224ページ 春頃に 新しい本が出る（はず） 3
4. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 4
5. 登壇 各種イベントでの登壇 オンサイト トレーニング コーチング アジャイル開発やDevOps に関するオンサイトコーチン グ アジャイル開発や組織づくり に関するオンサイト トレーニング 認定研修 認定スクラムマスター研修 Suitable for all等の主催 categories business and personal presentation 執筆・翻訳 技術書やドキュメントの 執筆や翻訳 などなど
6. スクラムガイド2020出ましたね 安定の角さん翻訳 6
7. スクラムガイド2020の変更点 ✤ 指示的な部分を削減 ✤ ひとつのチームがひとつのプロダクトに集中する ✤ プロダクトゴールの導入 ✤ スプリントゴール、完成の定義、プロダクトゴールの居場所 ✤ 自己組織化よりも自己管理 ✤ スプリントプランニングの3つのトピック ✤ 幅広い読者のために全体的に文章を簡略化 7
8. 3つの作成物に対するコミットメント “ 以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴー ル」と「完成の定義」について説明していた。 3つの作成物には、それぞれの「確約(コミットメント)」が含まれる。つまり、プロダクトバックログ にはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定 義(カッコをなくした)が含まれる。 これらの存在により透明性がもたらされ、 作成物の進捗に集中できるようになる。 スクラムガイド 2020 (p.16) 8
9. ✤ インクリメントと完成の定義の紐付けが明確になった ✤ では、インクリメントとは何だろうか？ 9
10. インクリメントの定義（スクラムガイド2020） “ インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれ までのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能するこ とを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメン トを利用 可能にしなければならない スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリン トレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にイ ンクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値 をリリースするための関門と見なすべきではない 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない スクラムガイド 2020 (p.13) 10
11. ほかにインクリメントが登場する箇所(一部抜粋) ✤ 「スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える」（p.4） ✤ 「スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持 つ」（p.6） ✤ 「プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない」 （p.10） 11
12. つまりインクリメントとは？？ ✤ 過去に作ったインクリメントと今回のスプリントで作ったインクリメントの集合体 ✤ その集合体が全体として機能しなければいけない ✤ その集合体が全体として利用可能でなければいけない ✤ 価値がなければいけない ✤ 完成の定義を満たさなければいけない ✤ プロダクトゴールの実現に寄与する 12
13. そもそもプロダクトとは?? ✤ スクラムガイド p.12 「プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、 既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サー ビスや物理的な製品である場合もあれば、より抽象的なものの場合もある」 ✤ プロダクト＝価値を運搬（交換）するもの（『プロダクトマネジメント』での定義） ✤ 我々の文脈だとソフトウェアが中心 ✤ とはいえ、プロダクト＝ソフトウェアではない ✤ ✤ ましてや、プロダクト＝顧客やユーザー向けに提供している部分だけでもない プロダクトを構成する主要要素としてソフトウェアが存在する 13
14. とするとプロダクトバックログには何が含まれるのか？ ✤ プロダクト＝価値を運搬（交換）するものと考えたときに…… ✤ プロダクトバックログには、以下のものが含まれる可能性がある ✤ ✤ ソフトウェアの顧客向けの部分 ✤ ソフトウェアの内部向けの部分 ✤ プロダクトに関係するソフトウェア以外のもの ✤ プロダクトの将来の価値を生み出すもの（検証や実験、学習など） ✤ その他 スクラムガイド「プロダクトバックログは、創発的かつ順番に並べられた、 プロダクトの改善に必要なものの一覧である」 14
15. とするとプロダクトバックログには何が含まれるのか？ ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） その他 15
16. ✤ これを踏まえて完成の定義を考えてみましょう 16
17. 完成の定義（スクラムガイド2020） “ 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述 である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。 完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、 透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リ リースすることはできない。ましてやスプリントレビューで提示することもできない。 そうした場 合、あとで検討できるようにプロダクトバックログに戻しておく。 スクラムガイド 2020 (p.13) 17
18. むむ？ ✤ 「プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生 する」 ✤ 「プロダクトバックログアイテムが完成の定義を満たしていない場合（中略）あとで検 討できるようにプロダクトバックログに戻しておく」 ✤ つまり、「すべての」プロダクトバックログアイテムは完成の定義を満たさなければい けないということになる 18
19. PBI、完成の定義、インクリメントの関係 ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） その他 P B I 完成の定義という共通理解による「検査」 イ ン ク リ メ ン ト 19
20. ✤ これを踏まえると完成の定義はどういう形になるのだろうか？ 20
21. 思考の叩き台としての完成の定義（Webアプリの例） ✤ コードやアセットがバージョン管理システムに登録されている ✤ コードは他の開発者によってレビューされている ✤ ユニットテストをすべてパスしており、カバレッジが90%以上である ✤ インテグレーションテストをすべてパスしており、主要ケースをカバーしている ✤ IE、Edge、Chrome、Safari、Firefoxで動作することが確認できている ✤ 静的解析により、重大度AおよびBの問題がない ✤ 必要なドキュメントの作成または更新が行われている ✤ OWASP ZAPでセキュリティの検証が行われていて問題がない ✤ テスト環境にデプロイ済である ※筆者が例として作ったものなので、網羅性や正確性はありません。そのまま使わないこと 21
22. ✤ よくある例だけど、これってどうなのだろうか？ 22
23. PBI、完成の定義、インクリメントの関係 ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） その他 P B I 完成の定義という共通理解による「検査」 イ ン ク リ メ ン ト 23
24. 画一的な基準の適用はうまく行かない気がする…… ソフトウェア(顧客 ソフトウェア(内 ソフトウェア以外 将来の価値創出 向け) 部向け) のもの 完成の定義 その他 バージョン管理システムへ登録済 ○ ○ ○ △ ？ 他の開発者のレビュー済 ○ ○ ○ △ ？ ユニットテスト全パス＋カバレッジ90% ○ ○ △ ✗ ？ インテグレーションテスト全パス＋主要ケース網羅 ○ ○ △ ✗ ？ クロスブラウザ確認済 ○ ○ ✗ ✗ ？ 静的解析で重大問題なし ○ ○ △ ✗ ？ ドキュメント作成・更新済 ○ ○ ○ ○ △ セキュリティの検証済 ○ ○ △ △ ？ テスト環境にデプロイ済 ○ ○ △ ✗ ？ ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 24
25. 画一的な基準の適用はうまく行かない気がする…… ソフトウェア(顧客 ソフトウェア(内 ソフトウェア以外 将来の価値創出 向け) 部向け) のもの 完成の定義 その他 バージョン管理システムへ登録済 ○ ○ ○ △ ？ 他の開発者のレビュー済 ○ ○ ○ △ ？ 【こんな疑問】 ユニットテスト全パス＋カバレッジ90% ○ ○ △ ✗ インフラ構築ってどうなれば完成か？ インテグレーションテスト全パス＋主要ケース網羅 ○ ○ △ ✗ スパイクはどうなれば完成か？ クロスブラウザ確認済 ○ ○ ✗ ✗ プロトタイプとかユーザーインタビューはどうなれば完成か？ ？ ？ ？ 静的解析で重大問題なし ○ ○ △ ✗ ？ ドキュメント作成・更新済 ○ ○ ○ ○ △ セキュリティの検証済 ○ ○ △ △ ？ テスト環境にデプロイ済 ○ ○ △ ✗ ？ ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 25
26. 各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 その他 バージョン管理システムへ登録済 他の開発者のレビュー済 ユニットテスト全パス＋カバレッジ 90% インテグレーションテスト全パス＋ 主要ケース網羅 クロスブラウザ確認済 ここを埋める (たぶん一気には埋まらない) 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済 ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 26
27. 各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 その他 バージョン管理システムへ登録済 他の開発者のレビュー済 ユニットテスト全パス＋カバレッジ 90% でも定義を埋めること以上に、共通理解こそが透明性を生む インテグレーションテスト全パス＋ ここを埋める 主要ケース網羅 (スクラムガイドでは「正式な記述」と言ってるが誤解を生みそう) クロスブラウザ確認済 (たぶん一気には埋まらない) 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済 ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 27
28. 各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 その他 バージョン管理システムへ登録済 他の開発者のレビュー済 ユニットテスト全パス＋カバレッジ 90% インテグレーションテスト全パス＋ 主要ケース網羅 クロスブラウザ確認済 共通理解がすべて ここを埋める (たぶん一気には埋まらない) 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済 ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 28
29. ✤ 完成の定義を「いつ」、「どうやって」決めるか？ 29
30. 完成の定義（スクラムガイド2020） “ インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチー ムは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロ ダクトに適した完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場 合、共通の完成の定義を作成して、それに準拠する必要がある。 スクラムガイド 2020 (p.13) 30
31. 完成の定義をいつ作るか？ ✤ ✤ 完成の定義は最初のスプリント1の開始前までに作るのが望ましい ✤ スクラムガイドには明確にそうは書いていない ✤ ただし完成の定義を満たさないと、PBIはインクリメントにならない、と明示されている ✤ つまりプロダクトバックログアイテムに着手する前に必要になる ✤ それはスプリント1の開始前になる ただ、継続的な手入れは必要（「正式な記述」という言葉は誤解を招きそう） ✤ 新たな種類の仕事が登場する場合には、随時更新していく ✤ これはリファインメントの作業から派生する可能性がある ✤ 今まで受け入れ基準と呼んでいたもののうち共通するものは完成の定義になるかも 31
32. 完成の定義をどう作るか ✤ 「完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それ に従う必要がある」 ✤ 会社として従うべき基準が決まっているなら、それをもとにする ✤ ✤ ✤ これは議論の余地が多そう。プロダクトの種類に依存 不足部分はスクラムチームで足せば良い 「組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作 成する必要がある」 ✤ 組織の標準がなければ、スクラムチームで作る 32
33. ソフトウェアやインフラでどの程度を目指すのか？ 33
34. 完成の定義をどう守るのか？ ✤ 全員が完成の定義の内容を理解していなければいけない ✤ 誰でも見える形で文書化する（スクラムガイド2020で「正式な記述」とされた） ✤ 一方で、全てを詳細に記述することは不可能であり、それを維持することはできない ✤ 人間の力の活用は必要（チームメンバーによるレビューなど） ✤ 自動化できるものは自動化する ✤ 意識しなくても守れる仕組みを作る ✤ スプリントレトロスペクティブなどをきっかけにして改善していく 34
35. 完成の定義をどう守るのか？ ✤ 全員が完成の定義の内容を理解していなければいけない ✤ 誰でも見える形で文書化する（スクラムガイド2020で「正式な記述」とされた） ✤ 一方で、全てを詳細に記述することは不可能であり、それを維持することはできない ✤ 共通理解がすべて 人間の力の活用は必要（チームメンバーによるレビューなど） ✤ 自動化できるものは自動化する ✤ 意識しなくても守れる仕組みを作る ✤ スプリントレトロスペクティブなどをきっかけにして改善していく 35
36. まとめ ✤ 完成の定義はインクリメントに対するコミットメントになった ✤ インクリメントは、過去と今回のインクリメントの集合体で、価値があり、プロダクトゴールに寄与 ✤ プロダクトとは価値を運ぶもので、ソフトウェアが中心だがそれだけに限らない ✤ 必然的に、プロダクトバックログにはソフトウェア以外のものも含まれる ✤ 完成の定義を満たさないとプロダクトバックログアイテムは完成しない ✤ つまり、さまざまなプロダクトバックログアイテムにあわせた完成の定義が必要 ✤ 完成の定義はスプリント1の前に用意する。会社の標準があればそれを踏まえ、なければスクラム チームで検討する ✤ 文書化によって見える化し、自動化や仕掛け化によって意識しなくても守れるようにする。またレ ビューを活用する。レトロスペクティブなどでスクラムチームとしての守り方を改善していく 36
37. まとめ ✤ 完成の定義はインクリメントに対するコミットメントになった ✤ インクリメントは、過去と今回のインクリメントの集合体で、価値があり、プロダクトゴールに寄与 ✤ プロダクトとは価値を運ぶもので、ソフトウェアが中心だがそれだけに限らない ✤ 必然的に、プロダクトバックログにはソフトウェア以外のものも含まれる ✤ 完成の定義を満たさないとプロダクトバックログアイテムは完成しない ✤ つまり、さまざまなプロダクトバックログアイテムにあわせた完成の定義が必要 ✤ 完成の定義はスプリント1の前に用意する。会社の標準があればそれを踏まえ、なければスクラム チームで検討する ✤ 文書化によって見える化し、自動化や仕掛け化によって意識しなくても守れるようにする。またレ ビューを活用する。レトロスペクティブなどでスクラムチームとしての守り方を改善していく 共通理解がすべて 37
38. 38
39. でもね ✤ プロダクトは完成しない ✤ 機能として完成しても、それが役に立たないかもしれない ✤ ずっとフィードバックサイクルを回さないといけない ✤ スクラムの完成は、スクラムでの完成でしかない 39

Comment

No comments...