Waka blog.

気になった単語

• スプリントバックログ
  • スプリントゴールを達成するための作業内容
  • 1スプリントで実現するだけのタスクを登録する
  • 開発チーム主体で作成し、進捗を管理する
  • 具体的な作業内容を記載したTODOリスト的なもの
• プロダクトバックログ
  • プロダクト全体のやるべきことのリスト(スプリントというスコープにとらわれない)
  • 新機能、バグ修正、技術的負債の解消、リサーチ等々プロダクトに関連する全作業を記載する
  • タスクの優先順位が決まっている
  • 常に追加、修正される

所管

スクラムはあくまで直近の課題を決定し、それを解決するためのものという感覚。

スプリントゴールの先の、プロダクトのゴールをどのように決めるのか、チームで共有するのかが課題に感じた。

そもそもアジャイル開発自体が、激しい変化に対応するための柔軟な開発手法であるはずなので、プロダクトのゴールが決まっている状態の方が不自然なのかもしれない。

スプリント毎に漸進しながら、自分たちがどこに向かおうとしているのかを話し合うことが重要に感じた。

プロダクトバックログは一朝一夕には作成できないもの。

作業を詳らかにしながら全てに優先順位をつける作業は途方もないし、一度作っても常に見直しを行い変化させ続けるのはとても大変なことに思う。

逆に言えば、完全に作業が明らかになり、優先順位が決定され、変化にも柔軟に対応できる状態になっていればとても心強いツールになる。

今のプロジェクトでは複数サービスを1人のPdMが管理していることもあり、スプリントバックログやスプリントゴールが開発者の裁量に依存しながら進められている。

そのため、差し込みのバグ修正が優先すべきものかどうかは雰囲気で決まっていて、なんとなく作業が遅れがち。

スプリントゴールを明確にすることで、バグの対応可否の判断基準ができる。開発者の心理的安全にも繋がるように思う。

スプリントゴールはチームが前に進むための羅針盤となり、とても心強い存在。

だけど、スプリントゴールはあくまでwhat(何をするか)に着目したもので、why(なぜするのか)までは見ていない。

なので、自分たちが正しい道を進んでいるかを確認する、whyに着目したプランニングの時間も重要になる。