先日、会社で初めてスクラムを導入してみた。
以前から開発プロセスをもっと改善できないかなーと思っていて、前々から気になっていたスクラムを取り入れたいと思って提案したら、なんかめちゃでかいプロジェクトのスクラムマスターになってしまった…😇
なんとか無事にスタートを切れたので今後の改善のために現時点での状況や気持ちを書いておこうと思う。
前提条件
スクラムチームの規模
開発チームが9名。スクラムではギリギリな大所帯。かつ、1名リモートワークがいる。
プロダクトオーナーは元々プロダクトを管理していた方にやってもらった。決定権限も持つような形にできたので良かった。
スクラムマスターの俺は対象プロジェクトの開発はやっていなかったので逆に第3者的な目線で入れてやりやすかったかもしれない。
対象プロジェクトの状況
機能開発をガツガツやっていくようなフェーズで、関係者やユーザさんから改善要望がひたすら上がってくるような感じ。差し込みタスクが頻繁に入ったり、依頼フローもばらばらの印象。
プロダクトメンバー全員がすごい頑張ってプロジェクトを進めているような状況（これを読んでる関係者、そこは違うよ！😎と思われたら、すいません）。
スクラム導入に向けてやったこと
スクラムを調べれば調べるほど失敗事例やなんちゃってスクラムというものが大量にあることがわかった。これは、学び実践し改善する心構えが必要だと感じた。
インプット
まず、@ryuzeeさんのブログやスライドを読んだ。
あと本を3冊ほど読んだ。
身近にスクラムを実践している人が居なかったので、こういう形でインプットしていった。理解はしやすかったと思う。
本当は認定スクラムマスター研修なども受けたかったが時間がなかったので今回は見送った。今後、検討したい。あと@ryuzeeさんのセミナーとかも良さそう。
アウトプット
チームにスクラムの理解を促進するために導入スライドをつくって共有した。これで正解というものではないと思っていて、スクラムをやっていく中でわかったことがあれば改善していきたい。
スクラムを導入してみて
スプリント計画会議
今回のスプリントは2週間にしたので、初日4時間とって、第一部と第二部に分けて開催した。開催する前は、膨大なプロダクトバックログ・複雑な要件に対して時間内に見積もりができるのかと不安だったが、やってみたら意外とできた。
プロダクトオーナーが事前にバックログを整理してくれていたのと、開発メンバーが自分が知っている情報をちゃんと共有してくれて、無駄な議論の時間を消耗せずにいけたのが良かったのかもしれない。
スクラムマスターとしては場が膠着しないように時間を意識しながら声をかけて進行していった。
プランニングポーカー
プロダクトバックログの相対見積もりには定番のプランニングポーカーを使った。購入が間に合わなかったのでトランプと紙に書いて行った。
9人もいるので相当ばらばらになるんじゃないかと予想したけど、予想通りバラバラ…2を出す人もいればBigを出す人もいて、収束するのかこれ？と正直思った😂
でも、大きいカードを出した人に「なぜこのカードにしたのか？」と意見を聞くと、他のメンバーが「あー、それも考慮しなきゃなのか」と納得したり、小さいカードを出した人の場合は「以前に作ったことがあるので、それがほぼ使えます」という情報を知ったりすることができた。
これによって多少のばらつきはあるものの、ほぼほぼ一致した。プランニングポーカーは、開発メンバー同士での意見交換が短時間で行えるので良い取り組みだと感じた。
ただ、集中するからかめっちゃ疲れる！
プロダクトとスプリントの見積もりが乖離する？
ちょっと分からないのが、第一部でプロダクトバックログをプランニングポーカーでポイント見積もりしたものと、第二部でタスクに細分化し時間で見積もりしたものが乖離しているタスクがあった。
例えば、ポイント13で5時間のタスクもあれば、ポイント8で8時間のタスクもあるといった感じ。
ポイント見積もりは詳細に見積もらないので、実際にタスクに落とし込んでいったら意外と簡単だった…というのはよくある事なので、そういうものかと思うが、ベロシティとしてポイントを使っていく際に、乖離が大きいと予測の精度が上がりにくい気がした。
ここらへんはどうしたらいいんだろう？
デイリースクラム
カンバン
ポストイットで紙でペタペタやっていくカンバンでタスク管理することにした。ポストイットにはGitHubに登録されているプロダクトバックログIDと見積もりした時間工数と内容が書かれている。上から順に優先度が高い。
開発メンバーはタスクを対応する時は、自分の名前が書いてDoingにうつす。終わったらDoneへ。
やり始めたばかりなので、これでうまくいくのかどうかは分からないが、やるべきことがハッキリするので良さそうな気がしている。
リモートワークメンバー
リアルなカンバンの場合、リモートワークのメンバーが物理的にさわれないので、今は実験として毎日カンバンの写真を取ってSlackに流している。フルコミットではないので、これくらいの雑さでも行けそうな気がするが、実際にどうなのかはもう少し様子を見たい。
スクラムを導入した今の気持ち
優先度を明確にし、一番上から各個撃破して早めのフィードバックを得る。スクラムを導入する中で得た考え方は非常に面白く、納得感の高い考え方だと思った。
これからスプリントを回して成果物が上がっていく過程の中で、いくつも課題が出てくるとは思うが、それらをチームで解決して乗り越えていければ、より楽しい開発が待っている気がする。
この記事の続きが書けるように、がんばるぞい😀
