4月のことを、この前書いた。 patorash.hatenablog.com
もう3週間くらい経ってしまった。なかなかブログを書く時間も取れないほど、日々は慌ただしい。主に、家庭面で。まぁ岡山県も新型コロナの影響で緊急事態宣言が出てしまい、それもあって幼稚園が登校自粛になったりなど、色々あった。
まぁそれは置いといて。
5月になって取り組んでいること
前回の反省点を踏まえて、5月に取り組んでいることを並べる。
一つずつ紹介する。
週単位でのスプリントプランニング
まず、前回の反省で、細かなPRが沢山きてコードレビューだけで1日が終わってしまうという課題があった。 そこで、流量を決めるために、月曜日にスプリントプランニングを行うようにした。先のような課題はあるものの、簡単なプロダクトバックログであっても「急ぎではないが重要なこと」であったりするので、無闇に進める速度をゼロに落としたくはない。
ルールとしては、
- 月曜日にスプリントプランニングする
- 決められたプロダクトバックログを全てこなしたら、その週の仕事は終了とする
- 残り時間は自己研鑽・技術調査・急ぎではないが重要なこと等に取り組んでもよい
- あまりにチケット数を減らしすぎるのもよくないので、適度にアサインしてほしい
- しかし、技術調査のために敢えて担当チケット数を少なくすることがあってもよい。それはスプリントプランニング時に要相談
とした。
アジャイルボード作り
弊社ではRedMineを使っているのだけれど、アジャイルプラグイン(?)が入っている。スプリントの設定を今までやっていなかったので、それを設定して週単位で見やすい形にした。
Rubyに関する読書会を開いた
コーディング力と、コードレビュー力を上げるために、Rubyに関する読書会を業務時間内にやりたいと考えていたので、それをメンバーに説明して、やることにした。お題の本は、Effecive Rubyにした。
- 作者:Peter J.Jones
- 発売日: 2015/01/19
- メディア: Kindle版
これを選んだ理由は、私が読んだことがなかったことと、みんな初級の本はこなしているので、よりよい書き方にフォーカスしたかったからだ。メタプログラミングRubyだと妙なテクニックに走りかねないかも…という懸念もある(第二版はまだ読んでないが)。
とりあえず今月は今のところ2回やっている。週に1回のペースでやっていく。
レビューする曜日を決めた
PRの量を調整したところで、毎日のようにレビューがあるとスイッチングコストが大きくなってしまう。それは他のメンバーもそうだと思うので、レビューする日としない日を決めた。
曜日 | やること |
---|---|
月曜 | 打ち合わせ、読書会、残りはタスクに取り組む |
火曜 | タスクに取り組む(相談はOK) |
水曜 | モブレビュー、残りはタスクに取り組む |
木曜 | タスクに取り組む(相談はOK) |
金曜 | モブレビュー、残りはタスクに取り組む |
水曜と金曜をモブレビューの日にして、火曜・木曜を動けるようにしたので、とりあえず集中して作業できる日が確保できたので、ある程度進捗を出せるようにもなった気がする。とはいえ、これはあくまでも開発チームとしての決まりごとなので、他のチームからの問い合わせには柔軟に対応している(データ出してー、とか)
モブレビューした
モブレビューは、モブプログラミングみたいに、ワイワイとチームでレビューする会である。オンライン会議で画面共有しながらレビューをするので、どういう意図でこう実装したのか聞いたり、より良いコードはこう、とか、歴史的経緯でこう実装されているという話をメンバー全員に共有できるので、話が早い(まぁ私含めて3名だけど)。PR作成者に実際の動作を画面共有しながら見せてもらうこともできるので、こちらで下準備する手間とかもない。
また、指摘のほうが間違っている場合にも、即座に反論というか意見交換できるのでレビュワーが勘違いしてた場合も助かる(主に勘違いするのは私)。
本来の目的は、ベテランの視点でのレビューで指摘されるところをメンバーに共有して、若手のレビュー力を向上することにあるのだが、週報のときに感想を聞いてみたら、「文字だけで指摘されるよりも腑に落ちやすい」ということだった。
まとめ
これらの取り組みによって、
- チームのRuby力の向上
- チームのレビュー力の向上
- 割込を少なくして開発効率を上げる
- 自己研鑽・技術調査をタスクに入れてもいいと認識してもらう
というところを狙っている。
個人の力量が上がらないことには、チームの力量も上がらないので、私としては、まずはチームとしての力を底上げしつつ、各々が自分の好きな技術分野で得意を増やしていってもらえたらなあ、と考えている。