RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。
概要
-
ryuzeeさん
-
Day2(13:00-13:20)
-
スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します（弊社調べ）。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。
ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません（と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが）。
そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。
気になった内容メモ
- スクラムガイドを踏まえて完成の定義について考えていくセッション
- スクラムガイドのアップデートに伴い、インクリメントに対するコミットメントとして、完成の定義(DOD)が必須になった。
- インクリメントって誤解を招きやすい単語
- 過去に作ったインクリメントと今回のスプリントで作ったインクリメントの集合体
- プロダクトゴールの実現に寄与する
- プロダクトとは、価値を提供する手段であり、価値を運搬or交換するもの
- プロダクトはソフトウェアと言い切るのは無理がある。価値を運搬/提供するものだから、営業とかも入るはず。
- つまり、プロダクトバックログには、インフラ整備や将来に向けた実験も入る可能性がある。要するに、価値があればプロダクトバックログには何でも入る可能性ある。
- 大まかに分けると、顧客向け/内部向け/ソフトウェア以外/将来の価値創出/その他
- スクラムガイド2020によれば、すべてのプロダクトバックログは、完成の定義という検査を経て、インクリメントに変遷する。
- これを踏まえると、完成の定義とはどんなものだと言えるか？
- プロダクトをソフトウェアとして考えるとおかしな完成の定義になる...
- 例) 単体テストが全部パスしてall greenになっていることって、将来の価値創出に繋がってない...
- てことは、顧客向け/内部向け/ソフトウェア以外/将来の価値創出/その他それぞれに完成の定義が必要？？？
- そんなことはない。正式な記述を顧客向け/内部向け/ソフトウェア以外/将来の価値創出/その他それぞれに記述するのはコストもかかるし、本当に正確なものかも分からない。
- 正式な記述よりも共通理解が大切。
- 完成の定義はスプリント1の前に作るべき。でも、継続的手入れは必要(例えば、いつもPBIに記述するような受入基準は完成の定義になる必要がある)
- 正式な記述という考え方がミスリードを生むリスクがあるので注意。
- 組織標準の開発基準はryuzeeさん的には議論の余地が大いにあると思う
- POCなのかどうかとか、どれ位の性能や信頼性が求められるのか...はプロダクトによって違う
- 結局完成の定義は、チームで共通理解することが一番大切
- 全員が完成の定義を理解しなきゃいけない。文書で書いてそれを守ればOKではない。
- チームが意識せずに守れる仕組みにしなきゃだめ(NG : チェックリスト)
- 継続的にメンテナンスしないとダメ
- 文書化は大切だが、チームで共通理解するのはもっと大事
楽しかったこと
- 初めてryuzeeさんの講演を聞いた！めちゃくちゃ聞きやすい。
- 一番大事な話の内容w(プロダクトマネジメントの宣伝でした！)
- 抜群に説明が分かりやすい。
やったこと
- アウトプットを意識しながら話を聞いた
- プロダクトマネジメントを購入した
学び
- DODなど、正解がないようなものは全てチームで共通理解をすることが大切
- チェックリストは自身の現場でたくさん導入しているが、意識づけはできていないしメンテナンスもされていないので、見直ししたい
- DODも文書としてはあるが、チーム全員がどういう解釈をしていて、どれ位重きを置いているかは分からない。一度チームで共通理解をする場を設けないと有効に機能しない。