スクラムを始めてみての感想
転職して1ヶ月半ぐらい経ちました。 技術的にもチーム運営的にも新しいチャレンジをさせてもらっているので、頑張って結果を出して行きたいと思います。
さて、この1ヶ月半人生初のスクラムマスターをやっています。もともと「2週間のタイムボックスで開発をやってる」ぐらいの状況だったので、メンバーが増えてきたこのタイミングで少しスクラムっぽくやろうということになったので。比較的きちんとしたスクラムは自分も初めてやるので、やってみての感想や気づきをメモしておきます。
スクラムを始める前にやったこと
業務委託でサポートしてくれている方でスクラムの経験がある方にいろいろアドバイス頂き、以下のことをやりました。
スクラムでやることや簡単なルールを決める
- バックログは今も使用しているZenHubを継続して使う
- スプリントの期間
- タイムボックは今まで通り2週間
- 最初の月曜にプランニング、最後の金曜日にレトロスペクティブを行うということにした
- レトロスペクティブからプランニングまでに時間があるが、その期間は次のスプリントに含めることに(レトロスペクティブとプランニングを同じ日にやるのはきついかなと...)
- どのスクラムイベントをいつやるか
- スクラムイベントではどんなことをやるか(後述)
- 1ポイントの基準
- 今まで消化したタスクの中で、数行程度の修正だったものを"1"ということにして、チーム全体のコンセンサスを取った
そもそものスクラム開発の説明
- 自分のスクラムに対する認識を整理するためにも簡単なドキュメントを作って、メンバーに共有しました github.com
所感
- レトロスペクティブから次のプランニングまでの間は半日〜1日分ぐらいの稼働時間がある。アサインされているタスクが終わった人は、この期間のやることが無くなってしまう。まあ勉強とかすればいいのだが、この辺りは今後変えていくことになるかも。
- レビューはそれぞれのissueのリリース前確認時にやってるから一旦なしになったが、UI/UX等の改善を考えると、全員でシステムを確認するレビューの時間をとってもよいかもしれない
- ZenHubめっちゃ便利
- スクラムの説明資料にアジャイルソフトウェア開発宣言のことも書いたけど、意外と知らない人が多く、説明してよかったと思った
スクラムを始めてみて
スプリントの途中から始めたので、デイリーの改善からやりました。
デイリーでやっていること
- バックログの更新共有
- Issueのパイプライン(New, ToDo, InProgress, Test, Review, Done, Closeを用意している)更新は個人で行うようにしているので、それの共有。昨日やったこと、今日やることの代わり。
- 新規Issueの確認
- 新しいIssueが登録されていれば全員でその内容を確認し、見積もりを行う
- 優先度の高い場合もあるので、必要であればスプリント計画の見直しを行う
- その他共有、相談等
所感
- 開発チーム以外も含めてデイリーをやっていたけど、開発チームだけの時間を設けることでコミュニケーションは増えた。スコープを小さくすることは大事。
- みんなバックログの更新をやってくれて嬉しかった。前職は全部一人でやってたし。
- 見積もりはまだまだ課題がある。最終的なポイントの決定ロジックは明確なルールがなく、自分のさじ加減(平均を採用したり、上を採用したり、などなど)
- その他共有はまだ業務連絡みたいなものが多いけど、技術的なトピックスとかをみんなが話すような雰囲気になっていけばいいなと思う
プランニングでやっていること
途中だったスプリントが終わって(レトロスペクティブも次のスプリントからということにしていた)、初めてのプランニングになりました。 ざっくり以下のアジェンダで進めることにしています。
0. 前回のスプリントで消化しなかったIssueを今回のスプリント(マイルストーン)に移しておく 1. プロダクト状況共有 2. new issueの見積もり 3. 今回のスプリントでやるIssueを決めて、マイルストーンを設定していく 4. マイルストーンに登録された未アサインタスクに関してアサインを決める 5. 微調整(多い少ない等、自己申告してもらう)
0. 前回のスプリントで消化しなかったIssueを今回のスプリント(マイルストーン)に移しておく
これは事前準備として、プランニングの前にやっていること。ZenHub上の作業です。 結構消化できてないIssueが残ってたりするんですよね。
1. プロダクト状況の共有
プロダクトオーナー的な立場の人も参加してくれているので、ビジネスの話は必ず共有してもらいたい。のでこの時間を取ってます。 ビジネス側でウォッチしているKPIや、検討中のビジネス展開などを共有してくれるので、非常に有意義だと思ってます。 たった2週間でも、結構状況は変わるんですね。
2. new issueの見積もり
デイリーでNewIssueはチェックしてるとはいえ、プランニングの前に新しいものが出てくるもの。なのでそれのポイントを出します。 初回はIssueの整理をしておらず、見積もりがされていない昔から残っていたIssueが大量にあったので、それの見積もりだけでプランニングの時間が終わってしまった。 2回目移行はプロダクトオーナーがIssueの整理をやってくれて、デイリーでのNewIssueチェックもワークしてきたのでこの問題な無くなったけど、大変だった。。
3. 今回のスプリントでやるIssueを決めて、マイルストーンを設定していく
大体80〜90ポイントぐらいを基準にしてますが、現状もっと増えてしまっている。 すぐにリリースできないようなタスクが多くて、Reviewなり、リリース待ちの状態で残っててそれがそのまま持ち越されてしまう、ってところが原因なのかなと。。 改善の余地あり。
4. マイルストーンに登録された未アサインタスクに関してアサインを決める
仕掛り中のもの以外は基本的にはアサインがないため、アサインしていく
5. 微調整(多い少ない等、自己申告してもらう)
アサインした結果、偏りがある場合微調整を行う。 個人が何ポイント持っているか、までは個人攻撃になる恐れがあるので、極力自己申告してもらうようにする。(個人単位では見ないほうがよいとアドバイス頂きました。確かに。)
所感
- ものすごく課題に感じているのが、事前準備で消化しなかったIssueをそのまま次に移していること。Issueの設定がわかったのかもしれないけど、依存関係とかがすごく多くてまとめでじゃないとリリースできないものが結構おおい。全部着手しているので、それをまとめてマイルストーンを変更すると、すごいポイントがすでにやることとして加算されてしまう(実際は8割ぐらい完成していたりするのに)。何とかしたいけど、どうするのが正解なのだろうか。こういった状況にならないように適切なIssueに分割なりするのがプランニングなんだろうけど...
- タスクアサイン時のルールと言うか意識というか、現状は個人の成長を意識したアサインにはなっていない。できそうな人をアサインしている状況なので、当然アサインされるタスクの量に偏りが出るだろうし、モチベーションにも影響するかもしれない(いつも簡単なタスクばかり回される...みたいな意見がでそう)。ここも改善ポイントだなと。
レトロスペクティブでやっていること
振り返りのやり方はいろいろあるけど、日本でよく使われているKPTをベースとすることに。 ざっくり以下のアジェンダで進めることにしています。
1. 今回のレトロスペクティブの目標共有
2. 振り返るためのデータを集め
- Keep出し
- ZenHub上のデータ共有
- Problem出し
3. 改善のためのアイディア出し
- ZenHubのデータも参考にし、Keep/ProblemからTryを出す
4. 出たアイディアから何をやるか決める
5. レトロスペクティブの振り返り
進めることにしているといっても、まだ1回しかやってませんが...。 コロナの影響で在宅勤務になったため、今はペンディングしている状況。ただ、流石に振り返りがないのは良くないとチーム内からも意見がでてきたので(いや、嬉しい限りです)、今のスプリントではやります。
1. 今回のレトロスペクティブの目標共有
振り返る上で何も思いつかない人もいるので、今回のスプリント内でのトピックスについての振り返りを考えてみませんか?というアナウンスをする。 もちろんトピックス以外でも全然OK。初回のときは以下のような例を上げた。
- 1スプリントで消化できるポイントの目安 - ポイント消化を向上させることができるような取り組み - ZenHubの運用方法
2. 振り返るためのデータを集める
ポジティブなことを最初に行ってもらうために、Keepから考えてもらうようにしている。 そしてZenHub上での計測値と合わせて、Problemを出す。
3. 改善のためのアイディア出し
Keep/Problemに対するTry出し。ZenHubのデータを踏まえてTryを出せるようになればいいのだが、まだ難しそう。
4. 出たアイディアから何をやるか決める
改善策として上がったTryのうち、何をやるかきめる。 Issueとして取り組まなければならなそうなものは、1〜2個ぐらいに絞って次回のスプリントで出来るようプロダクトオーナーと交渉する。 それ以外のものはチームのルール的なものに入れる(増えすぎるとよくないけど...)。
5. レトロスペクティブの振り返り
今回のレトロスペクティブの総評と、フィードバックをもらうようにしてます。
所感
- アジェンダには書いてないけど、なぜ振り返りをやるのかの共有は最初にやったほうがよい。腑に落ちない人もいるかもしれないし。
- 1人1人に発言してもらうので、時間がすぐにオーバーする。なのでタイムキープが凄く大切。
- 改善案はいいことしかないから、その中からどれを選ぶかきちんと決めること
- 次からリモートになるから、うまくやれるかな。
全体を通しての感想
- 全てにおいて、事前準備は大切です。アジェンダは事前に作って印刷し、それを見ながらファシリテートしてました。これがなかったら辛かった。
- 目下の課題はプランニングの改善
- 80〜90ポイントぐらいのタスク量でスプリント開始したい。
- 個人の成長も考えた上でのアサインもやっていきたい。そのためにはメンバーそれぞれが何をやりたいのかを把握しないといけないけど。
- スクラムとかファシリテートとかの本は流し読みしかしてないので、自分自身ももっとうまく回せるように努力しなければ
といった感じです。これからも頑張っていきます。
