はじめに
どうも、ヒロキングです。
新しいチームと、兼業のチームとの活動がスタートしました。
時間のやりくりに苦闘しながら始まりましたが、色々と調整しながら進んでいくしかありませんね。
今回のお話は、80%チームの中でどうやって日々過ごしているのか、スクラムマスターとしてこのチームをどうやって支援していこうと悩んでいたことについてお話していこうと思います。
午前中の過ごし方（80%チーム）
9:00
前回もお話しした通り、80%のチームは、兼業メンバーが在籍しているため、兼業メンバーはその日の午後からの進捗が分かりません。このチームでは、朝9時ごろミーティングルームに集まったらまず最初に、昨日の午後に行った作業の共有からスタートします。
10:00
10時からは、DSをやることになっています。
1月から改めてのスタートなので、最初はDSというよりも、情報共有の続きをしてしまっていることが多かったです。
あらかた共有が終わったら、今日は何をするか。
始まったばかりだったのでインセプションデッキの「我なぜ」「エレベーターピッチ」などの設定に着手しました。まだチームのやり方がよく分かっていなかったこともあり、こんな進め方でいいのかしら？？しばらくそんな感じでその日暮らしのような形になってしまったのは、スクラムマスターとしてもう少し工夫が必要だったなぁと反省しています。
既存のメンバーが多いので最初はこれまでのやり方を踏襲していこうと思っていました。勝手にしゃしゃり出たほうがいいのかお任せしたほうがいいのか・・今思うと後手後手になることが多かったので、もう少しコミュニケーションを取りながらやっていけばよかった😅
午後
午後は、残されたメンバーのみで作業することになります。
最初だったこともあって決めごとが多いので、午後の過ごし方は難しかったなぁと感じました。
ただ、他のメンバーは慣れているからなのか、そこまで難しさを感じていなかったのかも。
全体で決めなければならない課題は残しつつ、残りのメンバーでできること・進められることを話し合って、午後の過ごし方を決めながら作業します。
このリズムがまだまだ私が慣れていなくて、先回りして進められそうな準備が間に合わないことが多々ありました。私も兼業なので、20%のチームにも時間を割かれてしまうのも悩みのタネでした。
20%のチームのことも考えなければなりませんね。とはいえ、現状は予定していただいた時間帯に集合して、確保した時間内以外の作業ができません。20%チームでもスクラムマスターなのですが、これまたどう動いたらいいのか・・・新米にはまだハードルが高いぞ💦
完成の定義を作った話
チームで完成の定義を作ったのですが、スクラムマスターとして、チームに良いアドバイスをすることができませんでした。コーチが見かねてサポートしてくれてことなきを得ました。
完成の定義について、何かをアドバイスするほどの自信がなかった・・・
まだまだ勉強が足りていませんで。。というわけで、改めてスクラムガイドを読んでみました。
「完成の定義」というワードを中心に一通り見てみます。
開発者
「開発者は常に次の結果に責任を持つ」という文脈でも出てきますね。
「完成の定義を忠実に守ることにより品質を作り込む。」
どのPBIについても共通の定義となるので、これをしっかり守ることで品質が保たれるということか。
スクラムマスター
スクラムマスターのところにも出てきていますね。
「スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。」
スクラムマスターはどんな支援ができるんだろう。
スプリントプランニング
スプリントプランニングにも記載されていました。
「開発者が過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に⾃信が持てるようになる。」
ストーリーポイント見積もりやタスク分解のときに、何をすれば完成の定義を満たせるのかを考えることになるので、そういう意識を持って取り組んでいけば、スプリントが進むごとに予測が立てやすくなるという理解をしました。なるほど。
スプリントプランニングの項にはもう1箇所ありました。
「開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。」
完成の定義を満たすために、どんなタスクが必要なのかを考えていけばやるべきことが見えてきますね。
スプリントレトロスペクティブ
「スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。」
完成の定義についても、レトロスペクティブで検査するんですね。これは意識できていなかったかも。「個人、相互作用、プロセス、ツール、完成の定義」という部分については、チーム全体で意識してもらうように働きかけなきゃいけないですね。
スクラムの作成物
「各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。」
とあります。
プロダクトゴールを達成できるプロダクトバックログなのか、スプリントゴールを達成できるスプリントバックログなのか、完成の定義を満たせるインクリメントなのかを検査する。それにより進捗を測定できるんだと理解しました。
- プロダクトバックログのためのプロダクトゴール
- スプリントバックログのためのスプリントゴール
- インクリメントのための完成の定義
インクリメント
インクリメントと完成の定義は因果関係が強いので、かなりここに完成の定義についての説明がなされています。
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 完成の定義により、作業が完了してインクリメントの⼀部となったことが全員の共通認識となり、透明性が⽣み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提⽰することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
インクリメントの完成の定義が組織の標準の⼀部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。
スクラムガイド2020より
「完成の定義を満たしていないと、リリースすることもできず、ましてやスプリントレビューで提示することもできない」これって本当は結構シビアですよね。例えば、完成の定義に「テストのカバレッジが80%以上であること」という定義を設定していたとしたら、プロダクトとして動くものができていたとしても、テストのカバレッジが80%以上ないとPBIが完了したとみなされないということですよね。
「テストの実装が間に合わなかったけど、モノはできているから見逃してよ〜」は通用しないということですよね。
スプリントゴール、完成の定義、プロダクトゴールの居場所
こちらにも記載がありました。
スプリントゴール、完成の定義、プロダクトゴールの居場所
以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。2020年版では「プロダクトゴール」を導⼊し、これらの位置づけを明確にした。3つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。
スクラムガイド2020
ちょっと脱線してしまうのですが、スプリントバックログを決める前に、スプリントゴールを決めるべきなんでしょうか？スプリントゴールが決まらないと選択すべきスプリントバックログは決められませんよね。
正直どっちでもいいのかと思っていましたが、セオリーとしてはスプリントゴールが先な気がしてきました。
参考資料：
ドキュメント類は完成の定義に含めないの？
チームで完成の定義を決めているときに、ドキュメント類は完成の定義に含めるのか否かでとても迷いました。含めてもいいような気もするし、含めなくてもいいような気もするし。。
下記のリンクがとても参考になりました。
内部リリースや製品リリースの前にまとめて行う作業（PBIもしくはスプリントの完成の定義に含まれない作業）をUndoneの作業と言う。下図のように完成の定義を拡張してUndoneの作業を減らしていくことが望ましい。多くのUndoneの作業が残っているとタイムリーなリリースを阻害するためである。完成の定義の拡張のためには、テストの自動化や承認プロセスの見直しが必要になる。
https://www.agile-studio.jp/post/apm-definition-of-done
参考リンクでは、ドキュメントの類についてはUndoneの作業としていて、内部リリースや製品リリース前にまとめて行う作業としているようです。
ただし、徐々にUndoneを減らしていくのが望ましいとのことでした。
なるほど、ということは「ドキュメント類はプロダクトバックログの完成の定義には含めなくて良い」でいいのかな。結果的にはよかったのかな^ ^
みんなで作った完成の定義
さて、これらを踏まえてチームで作った完成の定義を見てみましょう。
これから新しいプロダクトを作っていくので、最初の段階としてはよかったのではないかと思っています。
いずれにせよ、今後レトロスペクティブで検査して見直していけばいいですね！
箇条書きにまとめてみました。
- 受け入れ条件を満たすことを担保するテストケースが準備されていること
- 作成したコードについてリファクタを実施し、完了していること
- 結合テストが全てGreenになっていること
- E2Eテストを実施し合格していること→STG環境で問題なく触れること
さいごに
いかがだったでしょうか。
完成の定義について、思うように支援できなかったで終わらないよう、次こそはうまく支援できるといいなと改めて思いました。
改めてスクラムガイドや、その他参考リンクを読んでみるなどして完成の定義を改めて考える良い機会になりました。
今日学んだことはチームにも共有して、また少しずつ見直していけたらと思います。
最後まで読んでいただき、ありがとうございました！
