こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
天野さん家永さん木下さんのアジャイルコーチお三方が、視聴者からの悩みに回答していくイベントです。
今回のテーマは、「完成の定義に何を記録するのか？」でした。
会の様子
完成の定義に関して解説
こちらの記事をもとに、完成の定義に関して簡単な解説がありました。
ごちゃごちゃにされがちな受け入れ条件との違いであったり、なんで完成の定義が必要なのか？どういう部分がポイントか？*1
普段アジャイルコーチの方が完成の定義に書くことをおすすめすること
チームの成熟度や状況に応じて変わってくるものの、以下の条件をおすすめすることが多いということでした。
- Unit testが全てPassしていること(カバレッジに関してはメンテナンスコストが高くなりがちなフォースが働くため、チームの成熟度がよほど高くない限りは完成の定義に含めない)
- VSMを書いてもらった上で、スプリント内で「ここまでは最低限やりましょう」というのを完成の定義に記載することが多い
- 文章の羅列と言うよりは表とかで整理しながら書くことが多い
- 情報過多になりすぎないように注意する
また、完成の定義をレトロスペクティブに持っていった上で見直すことで、定期的にメンテナンスをしていくことも重要だということです。
完成の定義に書かないほうがいいこと
一方で、以下の点は完成の定義に書かないように注意するということでした。
- 完成の定義を細かく記載しすぎないようにする
- 経過で見ていくような部分はなるべく書かないようにする(例えばまずはE2Eを全件Passさせた上で、次にE2Eにかかる時間をXX時間とする必要があるなら、E2EがXX時間以内にPassするという最終結果を記載し、段階は記載しないようにする)
定性的な完成の定義はありか？(例えば内容がドキュメントにわかりやすく整理するなど)
定性的な完成の定義もありではないか？という話が出ていました。
完成の定義が出ているかの共有の方法は、オノマトペ方式*2だったりペアワークなどでの共有が一つの方法としてあるということです。
また、同じものを話し合うレビューは定性的な完成の定義を作る活動の基本になるというお話も出ていました。
完成の定義を追加した場合はこれまでに「完成した」としていたのも見直すべきか？
参加者からの質問で、「完成の定義が拡張された場合はこれまでの完成の定義を見直すべきか？」という話がありました。
これは、基本的に過去の分も遡って対応する必要があるということですが、当然過去の分に対応するための工数を積むことが必須な点には注意したいということです。
会全体を通した感想
テスト関連の話が多く、ドキュメント系やLinterの話、ドメイン固有の話はそこまで出ていなかったのは意外でしたが、お三方がテスト関連の項目を特に重視しているのがわかったのは非常に興味深かったです。
