はじめに
弊社では、開発手法としてスクラムを導入しています。
私たち新卒エンジニア4名はスクラム開発の経験がこれまでなかったため、まずは基本の型を知ろうということになり、SCRUM BOOT CAMP THE BOOK を課題図書にしました。そして今回、読後の疑問点を解消し、より理解度を深めるために、共有の場を設けました。
本の紹介
“はじめて「スクラム」をやることになったら読む本"が7年ぶりに増補改訂! 近年、より複雑化しているプロダクト開発をチームでうまく進めていく手法として、 世界中で注目されている「スクラム」。実際の開発現場にどう適用すればよいのかを、 とにかくわかりやすく解説しています。 ・理論だけで終わらない“実践"の手引き ・架空の開発現場を題材に、実際のプラクティスを詳しく解説!
話したこと
- 弊社では開発チームの数が大きくないため、厳密なスクラムマスターをやっている人はいない。
- 通常知識が属人化してしまうことは起こりがちなので、ドキュメントを作ることを促したり、ペアプロなど一緒に作業する時間を意識的に設けるようにしていくことが大事
- 弊社ではNotionに情報を蓄積していくようにしています
- タスクの完了条件をより明確にしても良いのではという意見
- デイリースクラムが15分よりも長くなってしまうことがある
- 書籍には、人数に関係なくデイリースクラムを15分間で行い延長しないと書かれているが、延長してしまうこともしばしば
- 話すべきことは全員に共有したいことだけで、個別に話しても済むことは後で話す時間を設けるように意識していきたい
良かったこと
- 全員が同じ開発チームのメンバーでなく、同じスクラムといえどもチームごとに少しやり方が違うため、チームごとにうまく行っている部分や改善したい部分を共有できた
- 新卒ではあるが4月から徐々にタスクをこなし始めていたので、数スプリント経験した上での振り返りにもなった。また、課題点に対して次のアクションを議論することができた
- 他の人の挙げた論点を再び本を見返し議論することで、一人で読むだけで終わるよりもスクラムに対する理解度を高めることができた。
- 開発チームでは、実装した特定の人にしかコードの内容を説明できない、といった属人化は避けるのは難しい。しかし、スウォーミング（ペアプロ）によって、複数人のメンバーで同じタスクに取り組むことによって知識の移転を図ることができ、属人化をある程度避けることができると分かった。
- 書籍には誰でもバックログに書き込めるようにするべきと書いてあり、開発チーム以外のメンバーがバックログに書き込めるようにすべきかどうかという議論ができた。
まとめ
今回は、スクラムガイド2017年版に対応し増補改訂された、SCRUM BOOT CAMP THE BOOK を新卒エンジニア4名で読み、そこから得た知見を共有しました。 今後は書籍で紹介されていたようなスクラムの利点を活かした開発を進めていきます。 次回は『SQLアンチパターン』を課題図書とし、開発チームに依存しない、DB設計やSQL記述の際のアンチパターンについて学ぼうと思います。
