この Jira リリースは準備完了？Power Pack で実施するリリース可否レビュー

顧客ポータルのデモは動いています。公開日も間近です。ところが、リリースの準備ができているかと聞くと、チームの回答はそれぞれ別のことを指し始めます。

エンジニアリングはビルドの話をし、プロダクトは顧客の行動を考えています。品質担当はモバイルの確認待ちで、サポートガイドはまだ執筆中です。

有意義なリリースレビューでは、これらの回答を一つの話し合いにまとめます。Jira のリリース課題と Power Pack を併用し、デモの成功から公開までに残っている作業と判断を見つける方法を紹介します。

この例では、説明用のデモ課題 Customer Portal 2.0 を使用します。スクリーンショットは実際の Power Pack 画面にサンプル内容を表示したものです。顧客事例でも、リリース完了の証拠でもありません。

未完了の成果から始める

全員に全体の進捗を尋ねる前に、受け入れ基準ビューを開きます。この例では5項目中、アカウント作成とオンボーディング、チームメンバーの招待、パスワードのリセットの3項目がチェック済みです。

未チェックなのは2項目です。現在のリクエストと提供状況をダッシュボードに表示すること、主要な操作フローがモバイル、タブレット、デスクトップで機能することです。

拡大

未完了の成果ごとに、今の状態が何を意味するのかを尋ねます。まだ誰も確認していないのでしょうか。チェックで問題が見つかったのでしょうか。期待する動作が曖昧なのでしょうか。空のチェックボックスだけでは答えはわかりません。

ダッシュボードは検証できる状態でも、モバイルの操作フローには報告済みの問題が残っているとします。必要な次の手順は異なります。ダッシュボードのレビューを手配し、モバイルについては修正内容と再確認を明確にします。これらの行動は、チームが通常使う Jira の作業として記録します。

機能に付随する作業を確認する

次に完了の定義を開きます。サンプルでは6項目中4項目がチェック済みです。リリースノートとサポートガイド、およびステージング環境でのロールバックのリハーサルが未完了です。

拡大

これで「ほぼ終わっています」を、より役立つ説明に置き換えられます。顧客成果の検証が残り、サポート情報は未完成で、ロールバックのリハーサルも完了扱いになっていません。

各項目の証拠を誰が持ち寄り、いつ再確認するかを決めます。実際の結果へのリンクは課題に残します。Power Pack のチェックマークが記録するのは完了状態であり、チェックそのものを実行するわけではありません。

未完了の作業と判断待ちを分ける

最後に承認状況を確認します。デモのコックピットでは5件がレビュー待ちで、承認はありません。表示されているゲートには、プロダクトのスコープ、デザインとアクセシビリティ、技術アーキテクチャとセキュリティが含まれます。

拡大

レビューを依頼する前に、汎用的なゲートの文言と担当割り当てを、このリリースの実際の範囲とレビュアーに置き換えます。各レビュアーに必要なビルドの参照情報と資料を渡します。

こうすると、2種類の遅れを区別できます。レビューできる状態にない作業と、準備はできていても誰かの判断を待っている作業です。承認を催促しても、未実施のロールバックのリハーサルは完了しません。

行動につながる判断で終える

この架空のレビューでは、未完了のチェックを解消し、必要なレビューを受けるまでリリースを保留するとチームが判断します。これはチームの決定であり、Power Pack がデプロイをブロックしているわけではありません。

Jira の短いレビュー記録に、確認した候補版、残件、担当者、次のリリース可否を話し合う条件を残せます。結果を総合的なパーセンテージだけにしないでください。未解決のリリース条件が一つあることは、複数項目の完了より重要な場合があります。

次のリリースで、顧客成果、完了チェック、レビュアーの判断という順序を試してください。Power Pack for Jira で各ツールの連携を確かめ、成功したデモに加えて残っている作業もリリースの話し合いに持ち込みましょう。