もう10日くらい前だが、弊チームの振り返りを行った。 メンバーは私含めて3人で、1時間でKPTと開発チームのルールの見直しをした。
定例会で「ふりかえり」をしているのだが、開発としてのふりかえりではなく、製品に関わっている人のふりかえりなので、開発っぽいふりかえりをしたかった。因みに、そのふりかえりも、あまりビシッとした感じのネタは出てこない。時々出てくるけど。まぁそんなもんだろうか。
Keep
Keepは、
- レビュー日を分ける
- 読書会
- モブレビュー
で、これらはこのブログでも書いていたことだが、ちゃんとKeepしたい理由をフィードバックしてもらえたのでよかった。やってよかったー！って思える。作業日とレビュー日を分けたことで、レビューで辛くならないことだけではなく、「明日がレビュー日なので、それまでには仕上げたい！」というモチベーションに繋がったとのことだった。リズムも生まれたようで、これは副次的によかった面だった。
読書会は、もちろん勉強にもなるのだが、皆で同じ本を読んでいるので、共通言語ができるのが効いてくる。これはモブレビューのほうで詳しく説明する。あとは、プリンシプル オブ プログラミングを読んだことで、どういうことに気をつければいいかが何となくわかるようになってきたので、コードの質がよくなったと思う。
モブレビューは、書いた人にPRのコードの説明をしてもらうので、意図がわかりやすいし、それならこうしたほうがいいよって言いやすい。ここで読書会の効果が効いてきて、Effective Rubyで書かれてたアレを適用したほうがいいとか、言いやすい。言う方も言いやすいけれど、言われたほうも「あー、確かにそうですね」と受け止めやすい。 レビュー→修正→レビュー→修正→レビュー→修正…の地獄が起きにくい構造になるし、コミュニケーションコストが文字だけより断然早い（口頭で伝えた後に、コメントは残しています）。
Problem
問題は、あんまりそんな大きなものはなかったけれど、ちゃんと出してくれたのでよかった。心理的安全性が育っているかなと思える。
- 私が休みのときにスプリントプランニングしていいかわからない
- 夕会の時間が決まっていない
スプリントプランニングの件は、チケットはあって、優先度は決まっているのだが、なんらかの理由があって着手できないものがあるのだが、その判断が私になっているからだということだった。これを書いていて今、思い出した…😅。なぜ着手できないかを書いておくタスクを積んでおこう。 とはいえ、取りかかれそうなやつからやってもらっていいですよって話はしておいた。
夕会は私のタイミングで適当にやっていたので、申し訳なかったなと思い、Teamsの会議で16:30に行うように設定しておいた。
Try
Tryはなんだったかな…。あまり思い出せない。ほとんどなかったような…。
- 定例会のふりかえりの項目をKPTをやめて意見の出やすいものにする
というのを、自分が上げたのは覚えている。以下のを参考に、定例会の議事録のフォーマットを変えてみた。
一応、一回終わったのだが、まだあんまり慣れていないせいか、続けたいことやお礼したいことは出なかったけれど、聞いてほしいことに連絡事項がバババッと出ていて、それはよかったかなと思う。
開発チームのルールの見直し
書いてあることは至極真っ当なことなので、既存のものは変更なしでOKで、追加することにした。
- 他の人のために、Yard、JSDocを書きましょう
- 契約プログラミングを意識しましょう
- コードのフォーマットはフォーマットルールに任せよう
YardやJSDocは、書いておいたほうが後で見返すときに助かるし、呼び出すときに引数の型がわかるので便利。やはり途中からプロジェクトに参加する人の理解の手助けになるので、やっていこうということにした。
契約プログラミングは、プリンシプル オブ プログラミングに載っていたんだけれど、責任をメソッドの呼び出し側に持たせることができるので対応範囲が明確になるし、メソッド側で型のチェックを行わなくてもよくなるので、やっていこうということにした。
コードのフォーマットは、RubyはRubocopに任せているんだけれど、JavaScriptとCSSはまだ特にないので、ちゃんとPrettier等を導入していこうということにしたところ（まだやってない。チケットは登録した！）。
とまぁ、こんな感じで開発チームのルールをアップデートできたのは、モブレビューと読書会があってこそだなと思う💪。最近「みんなでアジャイル」を読んで、開発以外にもアジャイルを適用できるようにしていきたいと意識が高まっているので、頑張っていきたい。
