Scrum開発のお困りごと解決Tips集

こんにちは、AITPの菊池です。
今回はTips集ということで、A-TeamがScrum開発の序盤に解消した数多くの問題点のうち、他の開発チームでも起こりそうな事例と、実際の解決事例を紹介していきます。

調査タスクなど、完了条件がはっきりしないタスクの扱い

私たちが担当していたシステムは、既に稼働中のもので他所から譲り受けたばかりという経緯があったため、その気になればシステムの調査はいくらでもできました。言い訳ができる環境ではありましたが、いつまでもベロシティが伸びないことは容易に想像がつきました。とりあえず型にはめてみてうまくいかなかったら修正しようと思い「必ず出荷可能なインクリメントを用意すること」をスプリントバックログの完了条件にしました。そしてスクラムマスターとして、完了に辿り着くための支援を全力で行いました。

詳細は別記事にしますが、モブプロがチームの進捗に非常に役立ち、仕様がわからず調査から始めたタスクでも、意外と本番投入まで持っていくことはそこまで難しくなかったです。

時間が中途半端に余り、次スプリントに向けた先行着手がしたい

例えば2週間のスプリントのうち、最初の1週間で全てのタスクが終わってしまった開発者には、追加でタスクを依頼することは今でも時々あります。一方で、ラスト2日で手が空いた人は、新規のタスクを依頼しても完了に至らないケースが多いため、追加の業務依頼はしないと決めました。まずは他の開発者のサポートに入ってもらうことを検討しますが、特にサポートも必要ない場合は、頑張って早く終わらせた開発者に不利にならないよう、下記のルールを定めました。

• 自己学習の時間にあててよい
• 他のメンバーの作業と競合しない場所であれば、リファクタしてPull Requestを出しても構わない
• 次スプリントで担当したいタスクを見定めている場合は、こっそり実装を進めておいて構わない。チームはこれから実装を始める前提で、リファインメントにてストーリーポイントを出すものとする。

スクラムマスターとして気にしたのは、チームがスプリントの区切れを意識しない仕事をするのは避けたいということでした。それ以外は何をしても問題ないと明示することで、業務以外のインプットを通じてシナジーを起こし、チームをより強くしたいという思いもありました。

POが多忙で、各所の調整やチケット用意ができない

マネージャークラスをPOに置くと、各所との調整やMTGに追われてスクラムにリソースを割けないのは、割とあるあるなのではないかと思います。POが丸腰でスクラムイベントに来るのは仕方ない部分もあるので、特別好ましい形ではないですが

• みんなでヒアリングして、バックログ起こしをする
• 要望がよりざっくり曖昧になったプロダクトバックログを許容する。必要に応じてスプリントの期間を延ばし、開発者のカバー領域を広げる

といった応急処置を行いました。
POが徐々に業務調整できる場合は、少しずつあるべき姿に戻していけますが、そういった見通しが立たない場合はスクラムマスターや開発者の誰かがPO業務を巻き取り、兼任することも検討すべきです。

弊社では権限委譲に伴い、大野→現Senior ManagerのIMI→菊池と一時期PO業務の棚卸しが頻繁に行われていました。ポジションが合わない人にPOをお願いするとチームの動きが悪くなってしまったので、菊池がスクラムマスターと兼任する形を取っていました。

一定の適性が見込まれ、PO業務に割けるリソースがある人材をアサインすることで、仮に兼任であってもチームは円滑にドライブすると思われます。

既存の開発手順は、スプリントレビュー実施前に本番リリース済みである

Scrum開発開始前のA-Teamのブランチ運用は、mainとfeatureのみの運用モデル、通称GitHub Flowでした。またmainブランチに取り込んだらすぐ本番リリースしていたため、スプリントレビューをするころには既に本番稼働しているという運用面での不具合が起きました。（あるあるではないかもしれません、、、）

本件は、開発環境と本番環境の間にReview環境というものを用意し、スプリント中に作ったインクリメントの一時貯蔵場所を設けたことで、スプリントレビュー後にインクリメントを本番リリースできるという当たり前のことができるようになりました。

最後に

開発チームの数だけ、チームが抱える課題や解決策があると思います。
みなさんの経験をコメントでいただけると嬉しいです。

せっかくモブプロの話をしたので、次回はA-Team流にカスタマイズしたモブプロの話をしたいと思います。
最後までお読みいただき、ありがとうございます。