はじめに
弊社では少し前から、スクラム開発の導入を進めています。
わたしも新米エンジニアとして2021年6月にスクラムチームに入り、１年と少しが経ちました。
今回、新米からの目線で、チーム内でやってよかったことやよくなかったこと、これから改善していけそうなことを、スクラム手法には限定せずまとめてみました。
前提
立ち上げ時のメンバー
- 開発のベテラン・スクラム経験者（半年弱）が２人
- 開発初心者・スクラム未経験が３人 ←私はこっち
途中メンバーの増減はありましたが、だいたいこんなメンバーで日々回しています。
やってよかったこと
スクラムガイドの読み合わせをしてみる
2022年5月ごろから、月に1〜2回のペースでガイドの読み合わせ会をしています。
やり方は簡単で
- どのセクションを読むか決めて、５分くらい黙読
- 気づき、あいまいなことを各自付箋に書く
- 付箋の内容をみんなで確認して、認識を合わせていく
をひたすらくるくる回していきます。
もともとは、スクラムにもう少し詳しくなりたいよね、とはじまった取り組み。
ガイドがあまりにも抽象的すぎて、途中から「国語の勉強をしているのかな？」と錯覚することもあります。
でも一方で、自分たちが普段している活動や、スクラムがどういうことを目指しているのか、基本的な考えへの理解が深まりました。
聞けば、2020年の改訂で、以前よりもガイドの内容が抽象的になったとのこと。
昔のガイドも読み合わせしてみると、また別の発見があるかもしれません。
ペアプログラミング・モブプログラミング
チーム内で好き嫌いが分かれる取り組みです。
ちなみに個人的には苦手寄りだったりします。
メリット
- コードとそれに関する知識を共有できる
- ベテランの人の考えかたを知れる
- 複数人で見るのでコードレビューの手間が減る
デメリット
- 自分のペースでの作業ができない
- 人によっては話すことが億劫だったり苦手だったり話に混ざれなかったり
などなど。
今のところチームでは、新しいプロダクトを作るときや新しい技術を使う時の土台設計を作るときにモブを選ぶことが多いです。
その他は基本的にソロでプログラムを書いていますが、うまくいけばメリットが大きい手法なので、もう少し別の運用もできたらいいなと思っています。
コードレビュー
今は、プルリクエストを送った段階で、自分以外のチームメンバー全員がそれぞれでコードレビューをするという方法をとっています。
全員でレビューをすると、誰かがボトルネックになったり、自分のタスクを消化できなかったりする障害にもつながります。
一方で、全員でレビューすることで、
- コードの規約がなんとなく合ってくる
- 別の人のコードの書き方が勉強・発見につながる
などのメリットは大きいため、方法は変えつつ続けていきたいですね。
よくなかったこと
チーム立ち上げ時に、開発もスクラムも未経験のメンバーがたくさんがいる
個人的に、この状況は避けられるなら積極的に避けた方がいいことの上位に入ってます。
ただでさえチーム立ち上げ時というのは
- チーム共通の経験、価値観がない
- むしろそれを作っていこうという段階
です。
ここに開発未経験&スクラム未経験のメンバーが入ると。。。？
ベテランさん 「○○があって、xxxが必要で、（省略）こうなるよね。じゃあ見積もりしようか」
新人さん「（丁寧に説明してもらったけど頭に入ってこない。。。これで見積もりだと。。。？）」
ベテランさん 「毎週火曜日にレビューとレトロスペクティブ、プランニングするよ」
新人さん 「れびゅー？れとろなんちゃら？てなんだっけ？本読んだけど覚えてないや」
ベテランさん 「（）」
新人さん 「ここのこれがよくわからなくて。。。」
ベテランさん 「いいよ、ちょっと説明しようか。（今日全然開発進まないなあ。。。）」
みたいになりかねません。
未経験メンバーは覚えることが純粋に増えるから大変だし、ベテランメンバーは教えることが増えます。
ある程度開発やスクラムに慣れたチームに新人が１人2人ならそれでも進んでいけます。
ですが、人数が過半数を超える場合は、1,2ヶ月チームで業務に入った後に、スクラムを改めて始めるとスムーズにいきそうです。
SPを開発にかかりそうな時間で見積もる
これは、チームで実践してみてあまりうまくいかなかった方法です。
チーム立ち上げ時からだいたい9ヶ月くらい、時間を見積もりに使っていました（半日かかりそうなら0.5、みたいな感じです）。
ですが、結局チームのベロシティが安定することはありませんでした。
うまくいかなかった原因として、時間だけを尺度にすると
- 誰がそのPBIを取るかで、かかる時間は大きく変わる
- SPは基本的に相対的な数字なので、絶対的な時間は扱いにくい
- PBIの扱いやすさが表しにくい
あたりがあるのではないかなーと思っています。
ただ、時間はわかりやすい尺度ではあるので、初心者が多かった当時にそれをとったのは、１つの挑戦としてよかったのかなとも思っています。
ちなみに今
よくあちこちでお薦めされる、あるPBIを3とおいて、他のPBIを相対的に見積もっていくというやり方に変えています。
このやり方も最初は苦労しますが、見積もりに差が出た時の話し合いや、予想より重かった・軽かったPBIについてその認識を合わせていくことで、徐々にチームのベロシティが安定するようになってきました。
今後がんばると良さそうなこと
リファインメントを細かく細かく
このチームが苦手なことリスト
- 目の前にエディタがない状態での設計とミーティングです
- ついでに、開発に関する想像をすること
結果、リファインメントはどんぶり勘定のような精度で終わることが多いです。
それはそれで楽しいのですが、見積りだったりベロシティを測ったり共通認識を取ったりする上では、やはり不安が残りますし、属人的な部分も増えます。
精度が高いリファインメントをできるように練習していけるといいなーと思う今日この頃です。
デイリーをもっと使えるようになる
デイリーが必要か必要でないかは、いろんな記事を見かける気がします。
チームでは、デイリーは進捗確認だったり問題を抱えてそうな人を見つけるために重要、という認識はあります。
ただ、特に鬼のように忙しいとき、デイリーはこなすものになりがちです。
重要だという認識をもっと合わせるか、その認識を具体的な方法に落とし込むために模索するか、問題を抱えていそうな人を発見するのに焦点を当てて考えるか。
もっと使えそうとは思っているものの、なかなかその方法がわからないという一面もあります。
デイリーに関する悩みは、どこでも尽きないものなのかもしれません。
POをもっと巻き込む、もしくは巻き込める人を探す？
チーム内でも度々出る議論です。
わりと最近（2022年6月ごろ）から、スクラムイベントのレビュー会にPOにも参加してもらうようになりました。
ただ、スクラムの観点から言えば、これは当たり前にできるようになれるのがベストです。
その上で、より良い製品を作ろうと考えると、第三者（できればユーザーの目）は欠かせません。
他者を巻き込むことに積極的になりたいです。
おわりに
チームで進めるって、なかなかに大変です。
そして、スクラムはなかなかに奥が深いです。
やってるうちに、何がスクラムで何がどうなのかわからなくなる時もありますが、試行錯誤を少しずつ進めていきたいです。