はじめに
この記事は Akerunのカレンダー | Advent Calendar 2023 - Qiita 8日目の記事です。
こんにちは、開発部住宅開発チームの ps-yu1129 - Qiita です。普段は Web アプリケーションのバックエンド開発をメインで担当しています。
はじめてスクラムをやることになったら読む本(と書かれていた)、SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 電子書籍｜翔泳社の本 を読んだので、本の内容と私のチームでのスクラム開発事情をご紹介します。
なぜ読もうと思ったか
私のチームでは開発プロセスとしてスクラム開発を採用しています。ですが、私自身、スクラム開発は初めてのため、言われるがまま参加しているような状態です。。
そこで、スクラム開発で行われる各イベントがなぜ行われるかを理解することで、自身の立ち回りの改善を図り、チームがより良いアウトプットを出せるようになるという効果を期待して本を読みました。
本書の概要
本書は基礎編と実践編に分かれています。基礎編では、スクラム開発の基本的な説明がされていて、スクラム開発の全体像を掴むことができます。実践編では、スクラム開発を行うチームの様子がマンガ形式で描かれており、具体的なスクラム開発の進め方を知ることができます。今回は、私のチームでも実践している「スプリントプランニング」、「デイリースクラム」、「スプリントレビュー」についてご紹介します。
スプリントプランニングでのタスクの見積もりについて
スプリントプランニングは、スプリントを開始する前に行うイベントで、次のスプリントの開発内容を決めたり、タスクの見積もりを行ったりします。
タスクの見積もりは、時間やお金による見積もりではなく、どれくらいの作業量があるのかで見積もりを行います。作業量による見積もりを行うことで、着手しようとするタスクにどんな作業が必要なのかがある程度明確になります。その結果、重要な作業の漏れが出にくくなり、見積もりのブレも少なくできます。
私のチームでも作業量による見積もりを行っています。見積もりをスムーズに行うため、次スプリントで行う予定のタスクについて事前にタスクの内容を確認し、スプリントプランニング前に不明点を解消します。私は主に以下のような点を確認しています。
- チケット内容の認識があっているかの確認
- チケットのゴールの確認(漏れがないか、要件を満たすための内容になっているか等)
チケットによっては内容が薄いもの(ミーティング中に急いで作った等の理由)もあるため、事前に確認しておくことでスムーズかつ精度の高い見積もりが行えます。
ベロシティでスプリントプランニングの精度を上げる
スプリントごとにどれくらいのポイント数を消化したかを表したものがベロシティになります。ベロシティを見ることによって、次のスプリントにどれくらいのタスクが消化できそうかが予測できます。
弊社でタスク管理に使用している Jira では、直近5回のベロシティと、次のスプリントでどれくらいのポイントを積むのがおすすめかを提案してくれます(下記画像)。私のチームでは、この値を参考にしつつ、祝日の日数とメンバーの休みの日を考慮し、スプリントプランニングの際にどれくらいのタスクを積むかを検討しています。
デイリースクラムで問題を早期発見する
デイリースクラムは毎日行うもので、スプリントのゴールを達成できるかどうかを検査するためのものです。デイリースクラムの進め方は自由ですが、本書では以下のようなやり方が記載されていました。(ちなみに、私のチームでも同様のやり方です)
メンバーがそれぞれ以下のことを話す ・昨日何をしたか ・今日何をするか ・困っていること、問題点はないか
一番大事なのは、問題となっていることがないかを確認することです。例えば、開発を進めていくうちにタスクが漏れていたことに気付く、簡単だと思っていたタスクがすぐに終わらなかった等が挙げられます。このような問題がある場合は、早めにチームで共有し、解決していきましょう。
私のチームでも、デイリースクラムでタスクでの困りごとや問題を共有し、早期に対策が打てるようにしています。例えば、以下のような取り組みがあります。
- 実装に詰まっている場合には、ペアプロ/モブプロを実施して円滑に実装を進める
- 着手していたタスクで別のタスクが必要なことが判明した場合に、別途チケットを切って見積もりを行い、(必要に応じて)スプリントのチケットを見直す
これらの取り組みによって、開発がスムーズに進められています。
他にも、チーム全体のタスクの消化具合が順調かを確認するために、バーンダウンチャートを活用するのも良いです。バーンダウンチャートは、縦軸にタスクのポイント数、横軸に日数をとったグラフです。Jira では、下図のようなバーンダウンチャートが自動で作成されるため、チームのタスクの進捗具合を確認するのに便利です。
スプリントレビューで行うデモの目的
スプリントレビューは、スプリントの終わりに実施されるイベントで、スプリントの成果物の確認、残作業や進捗の確認、今後の予定の見直しを行います。スプリントの成果物の確認をする際にはデモを行います。デモを行う目的は以下の通りです。
- 実際に動くものを触り、期待通りに動くかを評価する
- もっと良くするためのフィードバックをもらう
私のチームでは、スプリントレビューでの動作確認に加え、チケットを完了にする前にもデモを行っています。具体的なフローは以下の通りです。
- 実装タスクがレビューまで完了し、開発用ブランチに取り込む
- Staging 環境(できなければローカル環境)でデモの準備を行う
- デイリースクラムの後にデモを行う
- 開発メンバーから質問やフィードバックを行う
- 問題なさそうであればチケットを完了にする
このようなフローとなったのは、開発した API の単体の動作確認しかしなかったことで、開発した API の呼び出しに至るまでのフローにおいて期待の動作になっていないことが後から発覚し、無駄な修正工数がかかってしまったことが背景にあります。
チケット完了前にデモを行うようにしたことで、問題の発見やフィードバックによる改善が早くなり、迅速に品質の高い成果物をアウトプットできるようになりました。
感想
割り振られたタスクをただこなすのではなく、スプリントのゴール、その先にあるプロダクトのリリースに向けて、どうやって品質の高いものを開発していけるかという視点で仕事をすることが大事だと思いました。これを意識することで、目標とする期限に間に合わせるために、どうやったら今の不便な開発環境を改善できるか、前スプリントでの課題をどうやったら解消できるか等々の意識が芽生えると思います。
興味を持った方は、ぜひ本を手に取ってみてください。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp
Akerunにご興味のある方はこちらから akerun.com
