LeSS・PBI・Scrum
これはMackerel Advent Calendar 2022の8日目の記事です
こんにちは、株式会社はてな Mackerel開発チームでディレクターをしています。
今回は今のチーム状況と気になっていることをつらつらと書こうと思います。
LeSS
前回の投稿から1年たちました。ずっとLeSSを回しています。 時間がかかるのは覚悟の上で、いろいろやってきたおかげで、まあまあ回るようにはなってきたと思います。
ベロシティの予測がほぼ正確に出来るようになってきました。 逆にPOの負担がさらに増えてきている状況です。さすがにタスクレベルの管理はやらないようにしていますが、限界に近そうです。 目下、可能な限り優先順を直列に並べて、並列度を下げるように工夫しています。 とはいえ、やらないといけないことも多くやりくりに苦労しているところです。
やり方に忠実に従うと、分割したチームごとにSMを置かないといけないのですが、現状2チームなので、チーム代表のみ置くようにしています。
PBI
PBIの書き方を変えたりしています。 特に完了の定義は「どういう状態になればこのPBIは終わるのか」を考えるようにしています。 本番リリース出来る状態にするのが大前提ですが、やらなくていいことも考えておかないと永遠に終わらないなんてことになってしまします。 また、可能な限り具体的に書くようにしています。 完了の定義に暗黙知が含まれているときも多いので本来であれば別に列挙しておいた方がいいのかもしれないです。
PBIについてもう一つ。 基本的には価値提供の単位となっているはずなのですが、実現したいことに対しての説明中、どうも上手くいかないことがあります。 どうやら、PBIの内容は決定事項であり、それをその通りに実現すればよいという空気が漂っているようです。
本来PBIに書かれている内容は - どのような価値を誰になぜ提供したいのか？ - その価値を提供するためには何を満たせばいいのか？ といったことであり、仕様書やタスクリストの類いではないと考えています（どのように扱うかはチームごとに決めればいいとは思います）。
PBIの内容はPOと開発チーム間で合意を取る必要があるのですが、開発チームは「その価値を提供するためには何をどうすればいいのか？」を全力で考える必要があるはずです。 したがって、設計から実装、結果の計測方法など、価値提供に必要なものを洗い出し、実際に実行し、できあがったものが完了の定義を満たすかをPOに確認を取り、プロダクトとしてリリースして初めてPBIがクローズできるようになります。
それでも、何か違うとなれば、完了の定義を進行中に変えることをPOと相談することも出来ます。 それは、Agileの原理原則から見ても許容されているものです。
したがって、仕様書（PRDやDD）は別で用意するようにしています。 Agileであろうと無かろうと、ドキュメントがなければメンテナンスをするにも大変ですし、どうしてこのような作りになっているのか、なぜそれをやったのか、なにをやろうとしたのかわからなくなってしまいます。 今やっていることに対して振り向く対象としてドキュメントを残すのであり、それを見直し向き直りをしていくことを許容するのがAgileであると思います。 たくさん書く必要はないのですが、必要最低限のものは残していく必要はあるでしょう。
Scrum
最近Scrumの意義、イベントの意味などに対して無意識になっているような気がしています。 一度有意識下にもっていき、下意識（体が覚える）にしていきたいところです。 そのためにも、メンバー全員に対する啓蒙活動を続けていかないといけませんね。
