私が携わっている基幹システム構築が今年度の初めにリリースされ保守フェーズに入り、多くのバックログが残っている状況で長期に亘る保守フェーズの生産性を維持・向上させながら良いリズムで運営していくためにスクラム開発を導入しました。
弊プロジェクトではRedmineを使用していたこともあり、Redmine上でスクラム開発の運用を開始しました。プラグインなしのピュアRedmineです。
世の中にはスクラムに対応したタスク管理、プロジェクト管理ツールが存在します。Redmineにも専用のプラグインがいくつか存在しますが、そのようなツールを使わずともスクラム開発を運用することができました。
この記事では、弊プロジェクトで開始したRedmineを使用したスクラム開発の運用方法をご紹介します。
弊プロジェクトでやっているスクラムの概要
弊プロジェクトで実施している現在のスクラムフローです。
弊プロジェクトのスクラムフロー
スクラムチームと前提
- スクラムチーム
- プロダクトオーナー(以下、PO)
- POリーダー1名、POメンバー6名というチーム体制にしている
- 理由は基幹システムのドメイン範囲が広いためPO一人ではカバーできないため
- スクラムマスター(以下、SM)
- 1名
- 開発チーム
- 6名
- ※実はSMがわずかながら開発チームのロールを請け負っている
- プロダクトオーナー(以下、PO)
- ストーリーポイント、ベロシティ
- 人日で見積もっている
- (ストーリー規模が全体的に小さく正確に見積もることが可能なため)
- デイリースクラム
- 実施していません
- Slackで常にコミュニケーションを取っています
- SMが開発チームにいるのでチームの問題に対して常々気にかけています
弊プロジェクトのスクラムで使用しているツール
弊プロジェクトでやっているスクラム開発のツールと運用方法
ここから各ツールをどのように使用してスクラム開発を行っているかを紹介していきます。
プロダクトバックログの作成と管理
弊プロジェクトではプロジェクト開始時およびスプリントレビュー、バックログリファインメント、ユーザーからの要望、バグ発覚時にプロダクトバックログを作成します。
スクラムにはバックログの状態としてプロダクトバックログ、スプリントバックログが存在します。これをRedmineのバージョン機能を使用して識別できるようにしています。プロダクトバックログはいつやるかは決まっていないので期日はなし、スプリントバージョンはそれぞれイテレーションごとに決まった期日を設定します。
図:Redmineのバージョン設定
プロダクトバックログを作成する際にチケットのバージョンに「プロダクトバックログ」を設定しておきます。
現在のプロダクトバックログを確認するビューはバージョンを条件としたカスタムクエリを全ユーザー共有で作成しておいて、スクラムチームが同じビューで確認できるようにしています。
図: プロダクトバックログ確認用のカスタムクエリ
スプリントプランニング、スプリントバックログの作成と管理
スプリントプランニングではスクラムチーム全員でプロダクトバックログと優先度を確認しながらチームのベロシティにおさまる範囲のバックログをスプリントバックログとして入れていきます。この時に、バックログ(チケット)のバージョンを「スプリント1」などに変更します。
図: スプリントバックログ確認用のカスタムクエリ
なお、弊プロジェクトではスプリントプランニングの前にPOチームがスプリントにいれたいバックログのバージョンを予めスプリントバージョンに変更します。スプリントプランニングでは対象スプリントを表示するカスタムクエリでスプリントバックログを確認しながら内容に関する確認や質問を行い、工数を見積もりを確定させ、ベロシティにおさまるかどうかを判定する流れになっています。
この運用はバックログ優先度を数字で表しているため、「このスプリントには絶対いれたい」「できればこのスプリントに入れたい」といったPOチームの意図が伝わらないことが原因で追加しました。本来であればバックログ優先度のつけ方を改善することでこのような運用は不要になるかもしれません。
スプリント実施とスプリントレビュー
スプリントが始まると、POチーム、開発チームのそれぞれの担当者が仕様詳細を詰めながらバックログの説明をブラッシュアップしていき開発を進めていきます。
図: スプリントバックログ確認用(開発)のカスタムクエリ
弊プロジェクトでは開発が終わるとステータスをレビューにし、POは随時レビューをしていきます。POからのフィードバックを早めに得ることでスプリント期間内で可能な限りフィードバックの対応もするようにしています。
また、リリースに必要なマスタ更新やパラメータ変更が発生する場合はわかった時点で随時スプリントバックログに追加し、リリース作業時に漏れなく実施できるようにしています。
バーンダウンチャート/バーンアップチャート
バーンダウンチャート/バーンアップチャートはRedmineのプラグインでも用意されていますが、弊プロジェクトでは使用していません。スプリントバックログをcsvで出力し、Excel上で消化工数を算出しグラフを作成しています。
図: バーンダウンチャート
これらのチャートはSlackで随時共有して開発チームで対策を話し合ったり、記録としてはプロジェクトごとに用意しているGrowiのポータルページに掲載しています。
リリース
スプリントが終わるとリリース作業を行います。Growi上にリリース手順書兼報告書を作成します。スプリントバックログにはリリース時に必要なタスク(マスタ更新・パラメータ変更 etc)も含めていますので、それらを抽出して手順書に書き出しています。
リリースが完了したらGrowiのリリース手順書兼報告書を更新し、Slackへの通知 + チャンネル上での完了報告してリリース作業が完了となります。
図: スプリントバックログ確認用(リリース)のカスタムクエリ
スプリントレトロスペクティブ
リリースが終わるとスプリントレトロスペクティブを実施します。弊プロジェクトでは、スプリントプランニングの直前にKPTで行っています。ここで上がったプロセスやルールの修正点はGrowi上にあるスクラムフローやワーキングアグリーメントに反映します。
補足事項
スクラムの基本要素と弊プロジェクトの実現方法を簡単にまとめておきます。
| スクラム | 弊プロジェクトの実現方法 |
|---|---|
| バックログの種類 | Redmineのバージョン機能でプロダクトバックログとスプリントバックログを識別 |
| エピック、ストーリー、機能、タスク | すべてをストーリーと捉え、タスクを細分化する場合は子タスク作成 |
| ストーリーポイント | Redmineのカスタムフィールドに「見積工数(人日)」を追加 |
| 優先度 | Redmineのカスタムフィールドに「バックログ優先度」を追加 |
| かんばん | 対応なし。カスタムクエリを駆使して必要なビューを用意 |
| バーンダウンチャート | Redmineのバックログをcsv出力しExcel上で作成 |
| ユーザーストーリーマッピング | 対応なし。何らかの描画ツールで実現したい |
まとめ
今回は弊プロジェクトで実際に運用しているRedmineを使ったスクラム開発を紹介しました。スクラム開発を導入するうえで「どのツールを使おうか」「今使ってるツールだとできない」「ツールがあればうまくいくのか」など悩む人は多いと思いますが、本記事のような運用を行えば専用ツールがなくてもスクラムを導入することはできますし、基本的な部分を導入することでスクラムの文化を学び実践することがまず大事なことだと感じました。結果として、弊プロジェクトのスクラムチームはスクラムに対して非常に前向きですし、チーム力の向上・改善に向けて自立して動けるようになってきました。（これは純粋にスクラムの効果ですね）
とはいえ、現在の運用方法はまだ発展途上であり、スクラムとして導入できていないこと、ツールで実現できた方が良いこともありますし、私が思うスクラムの効果である「プロダクトの価値の最大化」「強いチームを作る」という点においては後者に比重が置かれていて、前者の「プロダクトの価値の最大化」に対する施策はこれからです。
次回からは本記事と同じような形でAsanaやJira、OpenProjectなどでスクラム運用方法を検証しつつ、現在の課題や今後の取り組みがどのように改善・対応できそうか見ていきたいと思います。