この記事は自分の気持ちを記録しただけのものです。
参考程度に読んでいただけたら幸いです。
スクラムとは
アジャイル開発の代表的なフレームワークで、10人以下の小規模なチームが「スプリント」と呼ばれる1~4週間の短期間で計画、設計、開発、テスト、リリースを繰り返し、動くプロダクトを迅速に届ける手法のこと。
体制と進め方
チームメンバー：10人前後
スプリント期間：2週間
タスク管理ツール：Jira
※以下、タスクとバックログを混同して使用していますが、概ね同じ意味合いで書いております。
開発メンバーがそれぞれファシリテーターになり、スクラムイベントを仕切る。
- プランニング
- スプリント初日に実施する
- ボードにあるバックログに対してポイント付けをし、スプリント内のタスクとして入れる
- バックログは優先順位が高い順にスクラムマスターより作成されている
- タスクのイメージを詳細に書き、チーム全体で認識合わせをする
- わからないことは透かさず質問をする
- 不明点をできるだけなくす
- ポイントの合計が規定に達したら完了、スプリントゴールを決めて開始する
- 各バックログのサブタスクを作成するために、ランダムに担当がそれぞれ割り振られ、サブタスクを作成する
- 翌日、それぞれを発表し、問題なければ各々が適当にタスクを取って作業を進める
- デイリースクラム
- 日々の進捗を口頭で簡潔に報告する
- 困っていることや課題があれば共有し、長くなる場合は別途個別相談する
- リファインメント
- スプリントの真ん中に実施する
- 進行中のバックログについての状況を確認する
- 全体の完了を目指し、スケジュール表（リカバリー表）を作成する
- いつまでに完了（PRレビュー含む）できるか、日単位で計画する
- このスケジュール表をデイリーで使用していく
- 手空きの人が出そうならバックログを追加（おかわり）する
- レトロスペクティブ
- スプリント終了後に実施する
- 全体的にどうだったかを振り返る
- 振り返りのフレームワークはKPTが多かったが、その時のファシリテーターが気分で別の方法を試すのもあり
- 次のスプリント以降の目標を決め、心掛ける
良かったこと
- やるべきタスクが明確に一覧化されていることで、自分の位置を見失わない
- バックログの進め方は個人に委ねられるため、自己管理能力が上がる
- リファインメントにて、遅れていた場合は日単位で管理されてしまうが…
- 着実にプロジェクトを進められているという実感が持てる
- 短期間で成果を出すため、「俺何してるんだろう？」という気持ちにならない
- 周期的にやりがいを感じられる
- 会議の時間を最低限にし、その分を作業に充てられた
良くなかったこと
- 全体の進捗や状態を把握することが困難
- PRレビューを誰に出してよいかも不透明になる
- タスク同士の依存関係があると、詰まることが多い
- その人がタスクを終えるまで待ちになる、など
- タスク取りが難しい
- 適任とかないから、自分が取っていいのか不安になる
- → プランニングでタスクの確認をしているから、チームの誰もがどのタスクをも実施できるという前提がある
- 進捗報告が口頭で人によって粒度が異なり、リファインメントまでは信じるしかない
- 報告する内容を統一させたほうが良かったかも（例：進捗率(これも属人的だが…)、課題の有無、完了見込み日、など）
- 提案や悩み事に対して回答する人が、暗黙的にスクラムマスターに集中していた
- 全体的に意見を言う人に自身がなく、スクラムマスターに決定権があった（自分の反省でもある）
最後に
事前に「スクラムガイド」を一読し、初めてのアジャイル開発に挑みました。
今まではウォーターフォール形式のみ経験があったため、スピード感がすごいなと感じました。
その一方、もっとこうした方が良かったのでは？といったことも度々ありました。
今回はあまり意見できなかったため、次回のスクラム開発ではここで書き記したことを生かそうと思います。
（個人的な反省：意見を言えなかったこと）
もちろん、自分のチームの文化もあるため、別の現場でのスクラム開発ではまた違った感触を得られるはずです。
何が正解かではなく、そのチームにとって最も生産性が高くなるやり方こそ正解だと思います。
スクラムイベントそれぞれに対してもコメントはありますが、今回はスクラム開発の進め方で感じたことのみをまとめる形で記事にさせていただきました。