スクラム開発の備忘録
コンテンツ
はじめに
今回は備忘録。最後に感想。
2022年5月14日 スクラムを経験して
スクラム開発に初めて参加したので、具体的な進め方や感想を書き残しておく。スクラム開発とは、アジャイル開発のひとつで、スプリントと言われる短い期間で小規模な機能を設計・開発・テストしていく手法です。他のアジャイル開発の違いとしてよく上げられるコミュニケーションを重要視している点だそうです。スクラム開発には公式の スクラムガイド なるものがあるので、詳しく知りたい場合は要確認。
体制
数十人規模のプロジェクトだったので、各プロダクト毎にプロダクトオーナーと開発者からなる少人数のチームに分かれ、それらをまとめるプロダクトオーナーとスクラムマスターという体制でした。スクラムマスターは、少人数チームに一人ではなく全体で一人で、スクラムに関してのアドバイスや困りごとのアドバイスなどはチームを横断して行っていました。このプロジェクトでは、基礎開発チームが開発したものを、発展開発・運用チームに
納品する形となっていました。自分は基礎開発チームにいたのですが、発展開発・運用チームの体制はよくわかりませんでした(POは、いました)。また、全体のプロダクトオーナーは5，6スプリントの交代制でした。
スプリントの進み方
スクラムでは、設計・開発・テストからなるスプリントという短い期間(1週間程度)を繰り返すことでプロダクトを作り上げていきます。参加したプロジェクトでは、毎スプリント納品していました。各スプリントの各期間では、図のようなイベントを行っていました。いくつかは、スクラムで行うように決まっているスクラムイベントです(下の説明には「スクラムイベント」と記載)。また、毎日行うミーティングや定例のミーティングもありました。
設計期間
スクラムには、プロダクトバックログというものが定義されています。プロダクトバックログは機能や改善すべきことと優先順位を記述したものです。参加したプロジェクトでは、プロダクトバックログの記述にユーザストーリー形式が用いられていて「誰が・何を・どうして(課題があるから、効率かできてうれしい等)」を明確にしていました。そこから毎スプリント、スプリント内で完遂可能なスプリントバックログ(そのスプリント期間でのタスクリストのようなもの)を作製していました。
設計期間は主に先述したバックログに関する作業をしました。具体的には今スプリント進めるプロダクトバックログを選定・作製して、プロダクトバックログから必要なタスクをチームメンバ全員で考え、割り振られたタスクに対しては必要なら仕様の検討・設計をしました。イベントもバックログに関するものしかありません。
チーム内スプリントプランニング
全チームでのスプリントプランニングを行う前に、チーム内で今スプリントに進めるプロダクトバックログを選定または新たにないか確認していました。チームのプロダクトオーナーがプロダクトバックログを確認し、開発メンバに説明・確認していました。
スプリントプランニング(スクラムイベント)
全チームで各チームの今スプリントに進めるプロダクトバックログを説明・確認しあっていました。
チーム内タスク割り振り
チーム内で今スプリント進めるプロダクトバックログのタスク洗い出しと、割り振りをメンバ全員で行っていました。
プランニングミーティング
プロダクトを納品する先の運用チーム(体制図の下のチーム)と相談が必要なプロダクトバックログについて相談していました。また、プロダクトバックログの優先順位の確認や運用チームからの機能の追加・改善の要望も聞いていました。ここで、緊急の機能追加・機能改善のプロダクトバックログを作製し、今スプリントで進めることも多々ありました。
バックログ共有ミーティング
設計期間の終わりの方に全チームで、各チームの今スプリント進めるプロダクトバックログについて、設計期間で検討した内容(進め方やどのように実現するか)を含めて説明・確認しあっていました。
開発期間
その名の通り、設計期間で検討した内容に沿って開発を進める期間です。機能の追加・改善をした場合、新たにテストをしなければならないのでテストの計画や作製もこの期間でしていました。また、それに伴いテスト関連のイベントを行っていました。
テストプランニング
全チーム(主に開発者)で、プロダクトバックログでテストが必要な項目を確認して作製が必要なら担当決めなどを行っていました。他には、今スプリントで実施するテストの項目などの確認(手作業が必要で昼間実施・完全に自動化できているので夜間に実施・関連する部分に変更がないので必要なし等)を行っていました。テスト環境の構築も開発期間に行っていたのでそのスケージュールの共有もありました。
テストシナリオレビュー会
全チーム(主に開発者)で、作製したテストのレビューを行っていました。他チームのプロダクトを横断してテストを作製するので、自分のプロダクト以外の部分が問題ないかのチェックなどが多かった印象です。
テストタスク割り振り
テスト期間が決まっているのに、テストが肥大化していくので基本的には全自動を目標にテストを作製するのですが、どうしても手での作業が残ってしまう場合があります。そういった項目の担当決めをチーム内で行っていました。
テスト期間
その名の通り、ひたすらテスト進める期間です。テスト環境の構築の準備は開発期間まででほとんど終わっているので、初日にプロダクトをデプロイしてひたすらテスト項目を消化し行きました。プロジェクトに参加した時点で、テストの項目が多くすでにかつかつ状況で、既存のテストの自動化も積極的に行っていました(開発期間)。自動で可能なテストは夜間に実施していました。
この期間はテストを消化するのに必死なので、その他の定例ミーティング以外にはイベントはありませんでした。
振り返り
毎スプリント、1日だけ振り返りの日を設けてそのスプリントの振り返りを行っていました。振り返りは、KPT(Keep, Problem, Try)フレームワークを用いていました。
チーム内振り返り
チーム内でKPTフレームワークに則って、振り返りを行っていました。
スプリントレビュー(スクラムイベント)
全チームで今スプリントに進めたプラダクトバックログの状況(問題なく完遂できた・次スプリント以降も継続・問題点等)を共有していました。
スプリント振り返り(スクラムイベント)
全チームで、プロダクトバックログとは関係なくスプリントの進め方をKPTフレームワークで振り返っていました。チーム内振り返りもここで共有していました。
毎日のスケジュールは以下のようでした
一日のスケジュール
スクラムイベントのデイリースクラムから始まり、あとはその期間の作業をしていました。
デイリースクラム(スクラムイベント)
全チームでの情報共有をしていました。ほとんどが連絡事項やスケジュールの確認でした。プロダクトバックログに課題があるときやスケジュール的に厳しくなったら進捗の共有もしていました。
デイリースクラム(テスト)
テスト環境の準備は開発期間から行っており、そのスケジュールやイベントのスケジュールの共有・調整を行っていました。
デイリースクラム(チーム)
チーム内でのデイリースクラムです。これがスクラムで定義されている「デイリースクラム」だと思いました。スケジュールの確認や進捗が悪かったり、課題が生じた場合に相談したりしていました。
その他
スプリントを円滑に進めるために運用チーム(体制図の下のチーム)と定例ミーティングを開催していました。
定例ミーティング
週2回、運用チーム(体制図の下のチーム)と次以降のスプリントに向けて機能の追加・改善の要望を聞いたり、提案したり、今スプリントの課題の相談などを行っていました。
感想等
開発ツールは、GitLabやMattermostを使っていました。MattermostはSlackライクなコミュニケーションツールで使いやすかったです。GitLabの方は、バージョン管理的な機能の部分は問題ななかったのですが、CI/CDのPipelineの機能の部分は初めてだったので難しく感じました。ただ、Pipelineは扱えればとても便利でした。スクラムのバックログは、GitLabのissueで管理していました。
本題のスクラムの感想ですが、正直なところスキルに差があると厳しいなと思いました。参加したプロジェクトに関連する基本的な知識をほとんど持ち合わせておらず、プロダクトバックログからタスク割り出しのミーティング(チーム内タスク割り振り)のときも聞いていてほとんど分からず、後で調べることがほとんどでした(こんなタスクが必要と分かっておらず話し合いに参加できていなかった)。タスクをどれくらいで終わらせるかの見積もりも、稀に自分には厳しいなと思うものもありました。能力があるひとが集まってやるなら問題ないと思いましたが、スキル的に差がある人が集まる場合はつらく思う人もいるのではないかと思いました。