バックログマネジメント
アジャイル実装チームにとって最も頻繁に発生する課題の 1 つは、製品バックログとスプリントバックログのプロアクティブな管理です。
チームは良いバックログを作成するプロセス、バックログ内に関連情報を維持するプロセス、それらを定期的にリファインするプロセスに苦労します。
問題は以下のような複数の要因が組み合わさって生じます:
- プログラムマネージャー / プロジェクトマネージャーが圧倒され、または手薄になりすぎている
- 製品ロードマップに変換される明確な ビジョン の欠如
- 明確に表現された リリースゴール に変換される製品 ロードマップ の欠如
- 不十分なツールの専門知識またはアジャイルベストプラクティスに対する理解の欠如
- バックログの時間見積もりに関する問題
以下の図は、これらの事項がいかに強く関連しているかを示しています:
前提条件
製品バックログとスプリントバックログを効果的に管理するために満たさなければならない基本的な前提条件を改めて挙げると、以下のとおりです:
1 と 2 の結果として、効果的なリリース計画が可能になります。
良いユーザーストーリーがなく、良い見積もり手法を適用しないと、製品バックログとスプリントバックログの有用性が低下し、最終的にはアジャイル / スクラムプロセスが予測可能になることを妨げます。
プログラムマネージャー / プロジェクトマネージャーは、プロジェクトの戦略と方向性を提供します。つまり、彼/彼女はビジョン、製品ロードマップ、リリースゴール、スプリントゴールを提供する責任があります。プログラムマネージャー / プロジェクトマネージャーは、製品バックログから項目を挿入、再優先順位付け、リファイン、または削除することが期待されます。これは、スプリントスコープが定義され開発チームによってコミットされるまで、いつでも発生する可能性があります。
製品バックログの サイジングと見積もり は通常、スプリントプランニングミーティングや進行中のスプリント中の定期的な間隔で行われます。プログラムマネージャー / プロジェクトマネージャーがユーザーストーリーを追加する速さによっては、より頻繁な、おそらく毎日の見積もりセッションが必要になる場合もあります。GitLab 実装チーム、顧客開発チーム、プログラムマネージャー / プロジェクトマネージャーは、スプリントプランニングミーティングや進行中の定期セッションのいずれかで、バックログ項目を見積もるために協力する必要があります。
ここで重要なのは、製品バックログ項目は継続的に見積もられる必要があり、取り組みの重要な節目で一度に大規模な見積もり作業を避けることです。見積もり作業の頻度は、エンゲージメントの開発作業によって異なります。これにはチーム全体をプログラムマネージャー / プロジェクトマネージャーの考えにさらすという追加のメリットがあり、全員の同期を保ち、要求された製品機能と機能性に対する理解を向上させます。
スプリントプランニングミーティングまたはより頻繁な見積もりセッションは、確立されたアジャイル見積もりベストプラクティスに従う必要があります。つまり、製品バックログ項目は Estimation Poker または T-Shirt sizing のいずれかを使って見積もられます。
プログラムマネージャー / プロジェクトマネージャーは、要件の開始、ユーザーストーリーの作成、スコープコントロールの行使を担当します。
GitLab 実装チームと顧客開発チームは、プログラムマネージャー / プロジェクトマネージャーと密に連携してバックログを見積もる責任があります。これはチームの努力であり、GitLab と顧客チームメンバーがスコープに同意することが極めて重要です。
プログラムマネージャー / プロジェクトマネージャーはステークホルダーと連絡を取り、優先順位を決定し、バックログを継続的にリファインします。
GitLab には、ユーザーがバックログを追跡するために表示できる動的に生成された Issue リストがあります。ラベルを作成して個別の Issue に割り当てることで、Issue リストを単一のラベルまたは複数のラベルでフィルタリングできるようになります。これにより、より柔軟性が増します。優先度ラベルを使用してこれらのリスト内の Issue を順序付けることもできます。詳細は「エンゲージメントを管理するための CPR の使い方」を参照してください。
製品 - リリース - スプリントバックログ
多くの取り組みでは、3 つのバックログを管理する必要があります:
- 製品バックログ: エンゲージメントのライフタイム中存在する、ユーザーストーリー形式で表現されるエンゲージメントの要件データベース
- リリースバックログ: 製品ロードマップとリリースプランに従って特定のリリース（一連のスプリントで構成）で提供される機能のサブセット - 特定のリリース期間中アクティブ
- スプリントバックログ: 次のスプリントで実行される作業を表す - スプリント期間中アクティブ
ラベルを使用してユーザーストーリー / Issue にタグを付けることができます。
このようなタグ付けにより、特定のユーザーストーリーとそれがどのような状態にあるかについての関連情報を簡単に表示できます。
通常、次に行う予定のスプリントは Estimation Poker を使用して詳細にサイジングおよび見積もられ、その次の 2〜3 のスプリントとそれらの内容は Estimation Poker または T-Shirt Sizing のいずれかを使用してサイジングおよび見積もられます。スプリントがチームによってコミットされたら、「進行中」であるためスコープは変更されないようにすることを覚えておいてください - 「進行中」のストーリーを変更すると、不必要なコンテキストスイッチが発生し、生産性の面でコストがかかります。将来のスプリントは、Product Owner と開発チームが合意するように、引き続き調整やアイテムの並べ替えが可能です。
製品バックログ項目とスプリントバックログ項目には、ユーザーストーリー以外のものも含まれる場合がありますが、特定のバックログに何が含まれているかに関係なく、チームのキャパシティを消費するすべての作業項目を表現することになっています。これには、実装するエンゲージメント機能を記述する実際のユーザーストーリー、欠陥、調査、その他の技術的タスクが含まれます。
スプリントバックログは、動作する製品インクリメントの実際のデリバリーへの即時性のため、最も正確で具体化されたバックログであるべきであることを覚えておいてください:
- スプリントプランニングミーティング中にチームと Product Owner の間で交渉されたコミット済み製品バックログ項目で構成
- スプリント実行中にスコープコミットメントは固定
- 初期タスクはスプリントプランニングミーティング中にチームによって特定
- チームはスプリント実行中に固定されたスコープコミットメントを満たすために必要な追加タスクを発見
- チームに可視
- デイリースクラムミーティング中に参照
- Definition of Done に基づいてプログラムマネージャー / プロジェクトマネージャーがスプリントの受け入れを測定するために使用
バックログはアジャイル / スクラムの支点
「ゴミを入れればゴミが出る」これは、アジャイルバックログの場合に当てはまります。
現在のスプリントのデリバリー成功に影響を与える最も重要なアーティファクトはスプリントバックログです。
エンゲージメント / プロジェクトの成功または失敗に影響を与える最も重要なアーティファクトは製品バックログです。
アジャイルはシンプルなプロセスで、6 つのロール、5 つのイベント、9 つのアーティファクトがあります。
上には 8 つのアーティファクトしか表示されていません - 残された動作するシステムは暗黙的に 9 番目とみなされます。
バックログは実装する必要があるものの本質を保持しており、そのため細心の注意を払って作成、維持、グルーミングする必要があります。
プログラムマネージャー / プロジェクトマネージャー、GitLab 実装チーム、顧客開発チームがバックログを最新の状態に保ち、十分にリファインすることに焦点を当てない限り、アジャイルプロセスは組織にとって最も重要なものを提供できません: それは 予測可能性 です。
一般的な問題と課題
このセクションでは、製品バックログとスプリントバックログの管理を必要以上に困難にしているいくつかの一般的な問題と課題を取り上げます。
適切に書かれていないユーザーストーリー
ユーザーストーリーは INVEST 原則に従うべきです。それらは以下である必要があります:
- Independent（独立した）（可能な限り、ユーザーストーリーは実装される他のユーザーストーリーに依存すべきではありません）
- Negotiable（交渉可能）
- Valuable（価値のある）（つまり、機能に焦点を当て、タスク指向ではなく、可能な限りユーザーの言葉で書かれる; ゲノミクスや医学などのドメイン固有の言語が必要な場合は、主題専門家の参加が必要）
- Estimable（見積もり可能）
- Small（小さい）（1 人の Dev チームメンバーにとってスプリントの半分以下）
- Testable（テスト可能）（受け入れ基準を持ち、主観的でない必要がある）
ユーザーストーリーのテスト可能性は通常、受け入れ基準の形で文書化され、ユーザーストーリーが意図通りに実装されているかどうかを検証するのに役立つ合格/不合格のテスト可能な条件をリストします。
すべてシンプルに聞こえますが、しばしばチームとプログラムマネージャー / プロジェクトマネージャーは良いユーザーストーリーを書くのに本当に苦労し、発生する問題の 90% は ユーザーストーリーが大きすぎることに基づいています。
ユーザーストーリーが大きすぎると、理解、見積もり、実装が難しくなり、まったく異なる意見が出やすくなります。それでは、ユーザーストーリーの良いサイズとは何でしょうか? 基本的なガイダンスは、製品バックログの上位にあるユーザーストーリー（開発者が作業できる十分な特定性を持つべきもの）は、チームメンバーがスプリント中に 2 つのユーザーストーリーを簡単に完了できるようにサイズ調整されるべきだということです。
良いユーザーストーリー は良いバックログの基礎です。
急速な要件の流入
時には、プログラムマネージャー / プロジェクトマネージャーが、開発チームが工数を見積もるよりもはるかに速くバックログにユーザーストーリーを追加し始めることがあります。
または、プログラムマネージャー / プロジェクトマネージャーは、実装チームと開発チームが実装タスクで忙しいため、絶望から、技術チームを巻き込まずに自分自身で工数を見積もり始めます。これは悪いアイデアです!
アジャイルのコア原則の 1 つは「ビジネス担当者と開発者は毎日協力する必要がある」というもので、そのためプログラムマネージャー / プロジェクトマネージャーは、ユーザーストーリーを共同で理解し見積もる目的を損なうため、技術チームに単純にユーザーストーリーを引き渡すことはできません。
要件の流入が、チームが詳細に要件を理解し、それに応じて見積もる能力を上回る場合、最善の対応策は追加のバックログリファインメントセッションを設定して軌道を戻すことです。
ファンタジーウィッシュリスト
バックログには、GitLab、エンゲージメント、リリース、スプリントに関連するユーザーストーリーが含まれている必要があります。エンゲージメント、リリース、スプリントゴールに直接貢献しないファンタジー要件でバックログを乱雑にすることは逆効果です。
このようなウィッシュリスト項目は別に保管し、要件がエンゲージメント、リリース、スプリントレベルで具体的なゴールになるまで、バックログの外で管理する必要があります。「Future」のようなラベルを提供することで、プロジェクト参加者は、実行可能なスプリントスコープから外したまま望ましい Issue をログに記録できます。
バックログ = 要件仕様
特にアジャイルトランスフォーメーション / 採用の取り組み中、チームは以前のソフトウェア開発手法から利用可能な古いアーティファクトの長い裾野に対処することがよくあります。
例えば、顧客には多くの UML 図、機能要件仕様、技術要件仕様などがあるかもしれません。なぜそれらを有効に活用し、ユーザーストーリーの一部にしないのでしょうか?
これを行わない理由は、仕様には議論を停止させる副作用があるためです。「これは私たちが実装する必要がある仕様で、それ以上でも以下でもない」というように、本質的に仕様は新たに出現する要件の発見を妨げます。
ただし、これは、ユーザーストーリーがチームによって十分に理解されたら、実装を文書化するために技術仕様書を絶対に書くことはないという意味ではありません。
不在のプログラムマネージャー / プロジェクトマネージャー
プログラムマネージャー / プロジェクトマネージャーに関する最も一般的な課題の 1 つは、GitLab 実装チームおよび顧客開発チームと協力するための可用性の欠如です。プログラムマネージャー / プロジェクトマネージャーはイネーブラーであり、技術チームの生産性を高めるか、低下させます!
利用可能なプログラムマネージャー / プロジェクトマネージャーがいないと、技術チームは行き詰まります - これは、スプリントゴールが達成されない、品質が低い、ベロシティが低い、ステークホルダー管理が欠如している、ステータスレポートが遅れている、などの形で現れる可能性があります。
バックログリファインメントの欠如
定期的に バックログを見積もる ことをしない理由は本当にありません。前述のように、何らかの理由でバックログがリファインされていない場合、最善の対応策は追加のバックロググルーミングセッションを設定して軌道を戻すことです。
