全13960文字
PR

 実践編の第1回では、アジャイル開発プロジェクトを成功に導くために、プロジェクトの「企画」工程で気を付けるべき7つのポイントを解説した。実践編の第2回に当たる今回は、プロジェクトの「初期計画」工程における重要な7つのポイントを解説する。

 アジャイル開発は「プロジェクト途中での変更を受け入れる」ことを前提とするが、プロジェクトのスタート段階ではその時点での「全体を見据えた初期計画」をつくる必要がある。初期計画ではプロジェクト代表者の「プロダクトオーナー(PO)」、または多忙なPOを支援して調整役やリーダー役を担う「代理プロダクトオーナー(PPO)」がリードしながらスコープ、優先順位の付け方、移行やテストといった「通常タスク」の扱い、リリース計画などを決める。

 この「初期計画」は最初から綿密に固める必要はないが、ステークホルダーと事前に合意して進めることが欠かせない。どの程度まで決めておけばよいのか、具体的に解説しよう。

ポイント1:ユーザーストーリーを「ちょうどいい大きさ」に整える

 本特集の「基礎編(第1回~第4回)」では、要件定義においてシステムの全体像や機能の詳細を把握するには、ユーザーの要件を「役割(誰が)」「要望(何をしたい)」「理由(なぜ)」の要素で整理した「ユーザーストーリー」だけでなく、ウオーターフォール型開発でよく作成するドキュメントも積極的に採用すべきだと紹介した。具体的にはデータモデルや状態遷移図、フローチャート、画面イメージなどである。

 今回は、システムの全体感や機能開発の優先順位をステークホルダーと効率的に合意できるよう、プロジェクトの各段階におけるユーザーストーリーの「サイズ」と「粒度」について解説する。

 本題に入る前に、言葉の定義を再確認しておく。プロジェクト全体を通して、それぞれのイテレーションに割り振るタスク(作業)の塊を「プロダクト・バックログ・アイテム(PBI)」と呼び、PBIを一覧で整理したリストを「プロダクトバックログ」と呼ぶ。

 ユーザーストーリーはPBIの1要素であるとともにPBIの多くを占める。ユーザーストーリーを束ねる上位概念として「エピック」という言葉を使う場合もある。開発リーダーがユーザーストーリーをタスクに分解し、「スプリントバックログ」として開発メンバーに提示する。

図 エピックとユーザーストーリー、バックログの関係
図 エピックとユーザーストーリー、バックログの関係
要件を複数階層で表現する(出所:シグマクシス)
[画像のクリックで拡大表示]

 ではユーザーストーリーのサイズと粒度について順を追って説明しよう。

 ユーザーストーリーのサイズは標準的な基準や定義があるわけではない。一般にはチームの人数とイテレーションの期間によって決めていく。まず決めるのはチームのサイズで、次にイテレーションの期間を決める。この決めた1期間で、目安として2~3個を実装できるようにユーザーストーリーのサイズを決める。

 2~3個である理由は、優先順位を付けやすいからだ。数が多過ぎると優先順位を付けにくくなってしまう。

 例えば6カ月のプロジェクトを、よくあるチームサイズである5~7人、イテレーション期間を2週間と仮定してユーザーストーリーの数を算出してみよう。まずはユーザーストーリーがちょうどいい3個の場合、「6カ月×2週間単位のイテレーション×3つのユーザーストーリー」でユーザーストーリーは合計36個となる。36個であれば、全体の把握が比較的簡単で、優先順位付けについてもステークホルダーと合意しやすい。