リリーススプリントとはなにか

みなさんこんにちは。@ryuzeeです。

実際のプロジェクトやプロダクトでスクラムを利用している場合、リリースの前に「リリーススプリント」と呼ばれる期間を設けて、残作業を行うことがあります。これが何なのかについて見ていきたいと思います。

なお、リリーススプリントは、スクラムガイドなどで定められているスクラムの要素ではありません。あくまで、現実世界でリリースをしようとした場合に行うことがある、というくらいに理解してください（ベストプラクティスではありません）。

基本的な考え方

まずは基本的な考え方を整理しておきましょう。

スクラムでは毎スプリントごとに「リリース判断可能」な成果物を作ります
リリース判断可能とは、必ずしもリリース可能であるとは限りません
ただしリリース可能になっていれば、ビジネスの要請に応じていつでも状況に対応できるようになります
つまり**「リリース判断可能」な基準と「リリース可能」な基準の差分はなるべく少ない方が好ましい**と言えます
差分が大きく後回しにすればするほど、実際のリリースをしようとした場合に「大きな問題」が起こって速やかにはリリースできない可能性が高くなります

なお、「リリース可能」の定義はプロダクトのジャンル、特性、顧客数、法律などの影響を受けます。医療用ソフトウェアとキャンペーンのウェブサイトでは「リリース可能」の基準は大きく異なります。そして、リリース可能の基準は「開発手法」には左右されません。したがって、リリーススプリントをするかどうかに関係なく、最初のスプリントを開始するまでに非機能要件の洗い出しや完成の定義の設定などが必要になります。

現実

とはいえ実際のところ、必ずしも全てのスプリントで「リリース可能」にできるとは限りません。技術的には可能でもコスト面や開発チームの能力面からすべてを行うことが現実的でないこともあります。

例えば以下のようなタスクは全てをスプリントで実施するのは難しいこともあります。このようなタスクはリリーススプリントと呼ばれる「リリース判断可能」と「リリース可能」の差分を埋めるスプリントでまとめて対応せざるを得ません。

法務、特許、規制対応
システム単体での追加の試験や回帰テスト
パフォーマンステスト、負荷テスト（ただしその時点で問題があることがわかると手のうちようがないので、早期から継続的な実施が必要）
他システムとの結合試験や総合試験
セキュリティアセスメント
本番環境へのデプロイ
運用手順書、仕様書、マニュアルなどのドキュメント作成
社内承認プロセス
ユーザーのトレーニング

なお、リリーススプリントは「差分を埋める」ためのものであって、新規の機能追加や先送りしたバグの一括修正を行うものではありません。

繰り返しにはなりますが、なんでもかんでもリリーススプリントに先送りすると、そこで大きな問題が見つかってリリースできない可能性が高まります。プロダクトやプロジェクトごとにリリースの頻度や初回リリースまでの時間も違います。こういった要素を考慮に入れた上で、進め方を考える必要があるということになります。

リリース時対応とする項目の扱い方

実際にどのようにリリーススプリントに向けて準備するかを以下で説明します。

依存関係の影響を受けて日程が固定になるプロダクトバックログアイテムの並び順を後ろにおいておく
スプリント単位では実施できないが「実際にリリース」するのに必要な作業をプロダクトバックログに入れておく
事前に定常的にプロダクトバックログの見積りをしておき、見積りの精度が向上するようにしておく
リリース前に必要なプロダクトバックログアイテムの総量と、開発チームの速度によって必要な期間が決まる
もしくはリリーススプリントの長さを固定した場合、リリース作業関連のプロダクトバックログアイテムは上位から準備実施し、キャパシティに入らないものは実施されなくなる
したがって、リリース前に実施することを検討しているプロダクトバックログアイテムが必須なのか、やっておいた方がよいというレベルなのかの切り分けが必要
必須の項目が多い場合は、ベロシティと照らし合わせて早めにリリーススプリントに移行する
つまり、リリーススプリントに入ってから、プロダクトバックログアイテムを洗い出しているようでは遅い（入らないリスクがある）

それでは。