スクラムで開発するときに大変なところをぼやーっと

ぼやーっと書いてみようと思ったら、ほんとにぼやーっとした感じになってしまった。まいっか。

いい感じのスクラム？

バックログアイテムが小さく作られてて内容が明確で
スプリントの途中で差し込みもなくて開発者たちは開発に集中できて
他のチームとの依存はなくてすべての開発がチームの中だけで完結する。

そういう状況だと、まぁ、なんかいい感じに開発できるんだろうなぁと思ったりする。

実際は？

(1) バックログアイテムを準備するのがまず大変。
(2) それから、サービスを運用しているので突然の依頼や問い合わせみたいな差し込みはあるし。
(3) 他のチームとの依存もある。

(1) バックログアイテムの準備が大変

バックログアイテムの準備のときには、プロダクトマネージャーが色んなステークホルダーと調整したり、ビジネスチームやデザインチームと相談したりしつつ、もちろん開発者たちの意見を聞いたりもする。

「開発者たちの意見を聞く」ときには、開発者たちは手を止めることになる。バックログリファインメントという場を設けたり、チケットを作ってスプリントに入れてみたりするのかな。

まだやりたいことがふわっとしてる段階だと、結構あちこちに話が行ったり来たりする。アイテムのサイズを小さくするのが難しいことも多くて、みんなで悩んだりする。

そんなこんなを乗り越えて、だいたい内容が固まってきたら、ストーリーポイントをつけたりする。

そういえば、バックログアイテムには開発者目線のものもあるなぁ。技術的負債の返済とか、フレームワークのバージョンアップとか。そういうのは開発者主導で、プロダクトマネージャーと話をしたい。なので、開発者たちはそっちにも時間をさきたい。

(2) サービス運用

サービスの機能開発だけじゃなくて、サービスの運用も同じチームで見ていると、突発的な対応が結構ある。調査依頼、アラート対応や、まだツール化できてないデータの登録など。

ある程度は「次のスプリントで」って言えたりするけど、やっぱりユーザーやビジネスの人たちが困ってたらできるだけ早く対応したい。

(3) 他のチームとの協業

アプリケーションエンジニアのチームが開発をするんだけど、僕らだけですべてが完結するわけじゃない。サーバーやDBやネットワークやセキュリティなど、色んな専門知識を持ったチームがあって、そういう人たちによって支えられている。

それ以外にも

組織としての活動で、これまた色々やってたりする。組織横断の勉強会とか、研修とか、1on1とか、評価とか。そういうのでもちょこちょこ会議が挟まってたりする。

それから、開発者のスキルにはばらつきがあって、これから育っていくメンバーもいる。あぁ、そうだな、育成もあるな。教えながらコード書いたり。

どれも大切

と、そんな感じなので、最初に書いたような状況では全然ない。でも「この状況をなんとかして、いい感じの開発をしたい！」とは全然思わない。

状況が先。スクラムは後。僕はまず「この状況の中で」いい感じの開発がしたいだけ。

この状況をなんとかして、いい感じの開発をしたい場合

どういう感じなのかな？

プロダクトオーナーが、開発者の手助けは少なくても、バックログアイテムをいい感じに準備したらいい？
サービスの運用は別のチームを作ってそのサービス運用チームに見てもらうことにする？
専門知識をもった部署の人達に開発チームの中に入ってもらう？
組織の活動はできるだけ少なくする？

んー。これをやったら、たしかに開発はやりやすくなるけど、他のところで別の問題がでてきそう。そっちに課題を押しつけてる感じがする。

この状況の中で、いい感じの開発をしたい場合

これが、僕のやってる方なんだけど。

より良いものを作るために、プロダクトマネージャーと開発者が話をした方がいいなら、手を止めるのを気にしない。

ただ、全員が話をすると時間を持っていかれすぎちゃうから、代表で1人が話をするくらいがいいかな。その人が「他のメンバーの意見も聞いたほうがいいな」と思ったら、みんなに聞く。くらい。これは開発者を代表するくらいのスキルが必要なので、テックリードというロールの人がやる。

サービスの運用による突発対応は、あるものとして考える。突発対応が入ったらデイリースクラムでチームとしての動きを話し合う。「今日は突発対応を優先させるから、別のチケットの作業を止める」みたいなの。もし日中に緊急のものが入って次の日のデイリースクラムまで待てないって場合は、テックリードが開発者を集めてチームとしての動きを話し合う。

専門チームは他にも色んなチームとやり取りをしているから、そのようなチームとのやりとりはスプリントをまたいでやることになる。それも全然気にしない。

組織の活動も後輩の育成も楽しい。

大切にしてるのは、そういうのも全部ひっくるめたうえで開発できるものが、自分たちの健全なスピードなんだなって受け止めること。