イベントレポート | カイゼン・ジャーニー著者による本読みの会第10話「完成の基準をチームであわせる」再放送 #kaizenJ

はじめに

いつも心は虹色に！ nikkieです。
昨夜放送されたカイゼン・ジャーニー本読みの会10話の聴講メモです。

勉強会の概要

カイゼン・ジャーニー著者による本読みの会第10話「完成の基準をチームであわせる」再放送 - DevLOVE | Doorkeeper

「著者による本読みの会」では、著者2人がカイゼン・ジャーニーを1話ずつとりあげて、内容を解説したり、深掘りしたり、脱線したりします。

予定している内容
・第10話「完成の基準をチームであわせる」
下記の公開収録イベントの再放送になります
07-12（木）再始動・公開収録イベント：カイゼン・ジャーニー著者による本読みの会第2部第09話「一人からチームへ」と第10話「完成の基準をチームであわせる」

感想

この章は完成の定義と受け入れ条件の違いの理解になかなか苦労した章です。

改めて読むと、スプリントプランニングを経て、プロダクトバックログからスプリントバックログが作られるというわかりやすい図がありました。

「お客にとって」無駄なものを作らないんですね。
自分たちが作りたくないからドキュメントを作らないんじゃなくて、お客様が必要としていないから作らないという論理なんですね。

インクリメントを届けること(利用者のゴール)から逆算するという考え方、直近の業務に取り入れたらよさそうです。

音読のSiriさん、ナナサトじゃなくて七里(シチリ)さんでしたよ。

一人で読むだけじゃ気づいていなかったことに気づかされました。今回もありがとうございました。

本読みの会メモ

元の9話を2つに分けて9話と10話
- 9話後編は「バックログと格闘する」->10話「完成の基準をチームであわせる」
「事前調査」スプリント0¹　どんなリスクがあるかわからないので、スプリントを開始する前にチームでやる
- スプリント0はチームビルディングの目的も持つ
- このあとのインセプションデッキなどもスプリント0でやる
何を作ってもらうかは執筆中悩んだ
- プロダクトについてはあまり説明したくない(本題と外れる)
- 「品質管理ツール、地味やなー笑」
- このプロダクトにどんな機能があるかは著者も答えられない笑
失敗経験、リスクの経験から品質管理ツールの必要性がわかる²
完成アイテムのイメージがついているとコンバートするだけなので簡単
- イメージをつけるまでは霧の中。開発者とお客の間で洗練させる
- 「お客にとって無駄なものを作りたくない」のがスクラム
完成のイメージがついていないで思い出そうとしたのは、第1部の神戸橋さんのところ(<-おそらく4話。仕様を詰めきれていない問題)
イメージをつける=直近のプロダクトバックログは詳細化。数スプリント先は粗い
プランニング=スプリント計画会議でプロダクトバックログを作る

第1フェーズ=Whatのフェーズ

プロダクトバックログを濃く、優先順位を決める、Readyにする(=開発者が全力疾走できる)
数スプリント先のプロダクトバックログをReadyにするために「リファインメント」
- イベントではなくて「アクティビティ」なので、やらなくてもいい
- バックロググルーミングとも呼ばれる(グルーミング=毛繕い)
誰でも見える=透明性確保するためにはアナログツールがおすすめ
- 新井さん「付箋紙を使いましょう」
スプリントゴールを決める <- スクラムの練度が上がらないとできない
- チームのゴールを簡潔に明確化
- スプリント間でメリハリをつけたくなる
- 新井さん「インクリメントを届けることが重要で、そこから逆算していく」

第2フェーズ=Howのフェーズ

【気づき】Howのフェーズを経て最終的にスプリントバックログができる！
どんな作業が発生するか、開発チームがタスクを洗い出していく
タスクを時間見積もり³
市谷さん: 最大見積もりは6時間にしていた(8時間中使えるのが6時間)
- 社内イベントでスクラムから離れることも加味する
- 見積もりの最大の時間単位は人によっては4時間
スプリントボードはカイゼン・ジャーニーオリジナル。管理の仕方の例
- リーンのカンバンとは違うということを伝えたかった

完成の定義と受け入れ条件

混同しやすい概念
完成の定義
- スクラムガイドに結構書かれている
- チェックリスト
  - チェックリストを満たすことを確認することで、手戻りを減らしたい
- 全体的なこと「ユニットテストをパス、ステージング環境でエラーなく動く」
受け入れ条件
- スクラムガイドにはあまり書いていない
- 要件を満たしているか確認する
- 項目ごとに定義される
- 実際のところ定義しているか？
  - 新井さん「バックログに対する完成の定義に受け入れ条件も含めている」
- プロダクトの領域によって、受け入れ条件がかっちり決められるか変わる
江島：タスクを消化しているだけのチームという気づきシステムの全体像が腹落ちしない
「試行錯誤をしなくなると消化試合のように感じる」

メモは以上です。注釈は感想です。

こんな手法があるのかと驚きました！たしかによさそうですし、今回の本読みの回の収穫です。↩
経験を重ねると品質管理ツールの必要性がわかるようになるという話、実体験から同意です。↩
認定スクラムマスター講習で案内されたポイント見積もりでないんですねー。私はポイント見積もり派です(バーンダウンチャート併用) 関連：フィボナッチ数でポイント見積もり https://scrum.esm.co.jp/blog/123/↩