はじめにのはじめに
自分がいつ死んでもいいようにチームメンバー向けにノウハウを色々書いていたのですが、 見直すとほとんどryuzeeさんのブログで書かれていたことの焼き直しになってしまった、、
ただ、そこそこ具体的なところまで書いているので参考になったって人がいたら嬉しいです。 （スプリントゼロ以降は欲しい人いたら公開しようかな）
以下より本題になりますが、何かここ違うんじゃないかって人いたらコメントください！
はじめに
スクラムチームを組成し、いざ始めるとなったとき、スクラムガイドにはいわゆるスプリントゼロについて詳細に書かれているわけではなく、困ることが多い。
本記事では、具体的にどう進めると良いのかプラクティスレベルで記載するものである。なお、これは筆者の経験に基づいたものであり、カーゴ・カルト（積荷崇拝）にならないで欲しい。
その時々の現場や状況に合わせて、取捨選択してください。
参考記事：ryuzee.com:スプリント1を始める前にどんな準備をするか)
スプリントゼロでやるべきこと
プロダクト・プロジェクトレベル
プロダクト・プロジェクトレベルでやるべきことは以下の通り。
- インセプションデッキの作成
- クネビンフレームワークによるプロダクトやプロジェクトの置かれている状況の理解
- 全員のスクラムに対する理解度を統一する（勉強会・研修など）
- チームビルディングのイベント開催
- DoDの作成
インセプションデッキの作成
まず初めに、インセプションデッキの作成を行う。やり方的には、プロダクトオーナーが雛形を作成しスクラムチームで認識を合わせる方法や、ある程度全員の認識が揃っている状態であれば、各個人で作成しすり合わせしながら1つのものへ収斂させていく方法などが考えられるだろう。
インセプションデッキは抽象的な表現が多いのでさらっと作成完了となってしまうこともあるが、1つ1つのテーマにきちんと取り組んで考えていくことを推奨したい。また、各ページでディスカッションすべきことについて補足する。
- 我われはなぜここにいるのか：プロダクトビジョン、プロダクトゴールの明確化
- パッケージデザイン：明確にデザインが決まっているものであれば良いが、そうでない場合、カンプまではいかないがある程度固まったもの、サイトマップ等があると望ましい
- やらないことリスト：作成するドキュメント、しないドキュメント
- 夜も眠れなくなる問題：ネイティブアプリ審査のリジェクトなど、ここで出されたものはリスクバッファとしてプロダクトバックログにあげるのが望ましい
パッケージデザインに関しては、全体像が不明瞭なままだと開発者としても不安なため、できる範囲で可視化することが肝要だと考えている。
クネビンフレームワークによるプロダクトやプロジェクトの置かれている状況の理解
ここは参考サイトに記載の通りであるが、この段階であればスクラム以外の手法で開発することも考えられる。そのため、今一度プロダクトやプロジェクトの不確実性について議論し、開発手法を再検討することも重要だと考えられる。
全員のスクラムに対する理解度を統一する（勉強会・研修など）
スクラムマスター主導のもと、基本的な用語、各セレモニーの進め方、ロールの役割の共通理解ができている状態にしておく。一朝一夕でスクラムの本質的な価値や原則について理解することは難しいかと思うが、特にプロダクトオーナーはプロダクトの成否を決める重要な役割なので、理解度が低いようであれば、反復・継続して教育し続けることが望ましい。
チームビルディングのイベント開催
星取表とドラッガー風エクササイズなどのプラクティスが利用されることが多いように思う。
働き方や各個人の強みが明確化されていない場合は実施すること。
閑話：AgileTechExpoでの永和システム平鍋氏の講演で印象に残っているチームビルディングの話がある。オンサイトでは最初にチームビルディングイベントを行って一気にレベル底上げを図っていたが、リモートになって中々対面でのイベント開催が難しくなる昨今では、継続的なチームビルディング活動が重要になってくると。例えば、打ち合わせやスクラムセレモニーの5分前には集合するようにして、雑談する時間を増やすなど、直接顔を合わせられない分、違ったアプローチでのチーム成熟度を高める必要があるとのこと。スクラムマスターはこのあたりも目を配るようにしたい。
DoDの作成
ここは色々なサイトを参考にチームで考えたものを導入すればいいと思うが、テストについて補足しておきたい。自動テストをどのレイヤーまで進めるのか、いわゆる連結テストレベルのテストはどの段階で担保していくのか。テストを先送りにすればするほどUndoneは増えていく。リリース直前になってバグが頻発してリリースの見通しが立て辛くなる。スクラムではスプリントが終わった段階で「リリース判断可能な品質であること」という前提を忘れず、こういったリスクについては、きちんとチーム内で検討したうえで、DoDを作成して欲しい。
プロダクトオーナーレベル
プロダクトオーナーレベルでやるべきことは以下の通り。
- プロダクトビジョン・プロダクトゴールの作成
- プロダクト全体像がわかる資料の作成
- ユーザストーリーマッピングのイベント開催（PBIの作成）
- スケジュールの作成
- プロダクトオーナーというロールへの理解
プロダクトビジョン・プロダクトゴールの作成、プロダクト全体像がわかる資料の作成
こちらは先ほど記載したので割愛。
ユーザストーリーマッピングのイベント開催（PBIの作成）
横軸に時系列を取り、利用者毎にアクティビティとタスクに分割、どういった開発が必要なのかを整理するもの。その後、縦軸をスプリント1〜3等、スプリント毎のブロックに分け、いつどのような開発を行うのか議論する。ここは会話量が多く忘れることもあるため、議事録か音声録音しておくことを推奨。電子的にバックログを管理することが多いため、その後チケット管理ツールに転記することとなる。
また、インセプションデッキの夜も眠れなくなる問題で記載したリスクバックログはバッファとして積んでおくことで不確実な問題にも対応できる。
補足：PBIの書き方について
ユーザーストーリー形式で記載することが多いと思うが、その場合、「〇〇（誰）として〇〇（アクション）したい、それは〇〇（理由）だからだ」というもの。
あくまでも会話のインプットとなるものレベルではあるものの、プラスアルファで「理由」部分の一言で網羅できないストーリーの背景などを記載するのが良いと考えている。
AcceptanceCriteria（受け入れ条件）に関しては、デモが行える粒度で書くこと。経験上、ストーリーのACは5〜10程度はあると手戻りなく、開発側との会話が活発になって良い。
ツールにもよるが、エピック等の運用ルールについては予め決めておいた方が良い。（後々の管理のし易さ）
スケジュールの作成
現段階のスケジュールをきちんと立てる。
スクラム（アジャイル）は行き当たりばったりではない。（変化への適応はするが）
プロダクトオーナーというロールへの理解
例えば以下を問うと良いかもしれない。（この段階では回答が難しいものがある可能性あり）
- PBIはReadyReadyになっているか
- PBIは優先順位通りになっているか
- 次スプリントのゴールは明確になっているか
- ベロシティを参考に先々のスケジュールを立てられているか
- バックログに記載されている項目のWhyを1秒以内に答えられるか
- スクラムセレモニーに時間が割けているか
- バックログのHowにまで口出ししていないか
- POとしての決定権を持っているか、ステークホルダーのただの中継役になってないか
これらに迷うようなことがあれば、ロールやバックログの理解が足りていない。
スクラムマスターを中心に理解を深める手伝いをすべきである。
開発者レベル
開発者レベルでやるべきことは以下の通り。
- 開発者目線でのプロダクトバックログの作成
- PBIの見積もり
開発者目線でのプロダクトバックログの作成
やらなければならない、なおかつタスクとして大きいものが抜けていることは後々のリスクや見通しが悪くなることに繋がる。以下のようなバックログが抜けていないのか確認すること。
※バックログをDoneとするためには、ACとDoDの両方をクリアする必要があるため、Undoneとして残しているものがバックログ化されていないのは矛盾していると考えている
- 開発環境の構築（ローカル端末へのツールインストール、Dockerファイルの作成、チケット管理ツールのプロジェクト作成、リポジトリの作成・設定（コミュニケーションツールへの通知設定、プルリクの承認下限数）、ユーザの作成・追加、インフラの構築（Development、Staging）、CI/CDの構築）
- 移行計画・テスト・リハーサル
- テスト計画・実施（デグレ確認（内部連結テストレベル、外部連結テストレベル）、総合テスト、非機能テストなど）
- 非機能要求グレード等を参考にした非機能関連のタスク
- 社内標準やガイドラインの対応（ガイドラインチェックリスト、PCIDSS、CIS Controls等の対応）
- 脆弱性診断の実施、指摘対応
- 社内説明・承認用のドキュメント作成
PBIの見積もり
プロダクトオーナーが作成したPBIと開発者が作成したPBIの優先順位を並び替え、相対見積もりでストーリーポイントを付けていく。3〜6ヶ月程度先であれば全てのバックログにポイント付けた方が後々の見通しが立てやすくなる。また、優先順位が低いものに関してはざっくりポイントで問題はない。