PR

プロダクトオーナーから開発チーム全員に説明する

 続いて、イテレーション計画を説明する。アジャイル開発手法のスクラムでは、イテレーション(スプリント)ごとにイテレーションの初めに当該イテレーションで開発する内容などを打ち合わせる。これが、イテレーション計画だ。

 イテレーション計画では、プロダクトオーナーとチームリーダー(スクラムマスター)を含む開発チームのメンバー全員が集まって、イテレーションでリリースするものと進め方を決定する。イテレーション計画の時間の目安は、2週間のイテレーションで4時間程度を推奨している。

 イテレーション計画は、前半と後半に分けて行うことが多い。前半では、図4の左ようにプロダクトオーナーが要件定義のユーザーストーリーをベースに進める。それぞれに優先度とストーリーポイントを付けて、一覧にしたプロダクトバックログリストから開発チーム全員に何を開発するかを説明し、最終的に開発チームと合意する。

図4●プロダクトバックログとイテレーションバックログ
図4●プロダクトバックログとイテレーションバックログ
[画像のクリックで拡大表示]

 後半では、プロダクトオーナーは退席する。残った開発チームのメンバーが話し合って、イテレーション内で開発するユーザーストーリーを決め、ユーザーストーリーを実現するための具体的な作業であるタスクに分割する。そして、当該のイテレーションで開発するユーザーストーリーとタスクをイテレーションバックログ(スプリントバックログ)として整理する。

 イテレーション計画は、前半と後半に分けずに通して行う場合もある。プロダクトオーナーが後半にも参加するかどうかでプロジェクトで決めればよい。前半と後半の参加メンバーに変わりがなければ、あえて分けずに行う場合もある。

 ただし、基本設計までを終えてから反復開発するハイブリッドアジャイルでは、イテレーション計画の前半にプロダクトオーナーから説明することで、開発チームからの質問を受けるだけではなく、仕様に関する確認ができる。イテレーション計画では、ドキュメントだけではなく、コミュニケーションを重視したい。それにより、仕様の食い違いの防止にもなり、手戻りリスクを低減できるからだ。

イテレーションレビューで確認する

 各イテレーションの最後には、イテレーションレビュー(スプリントレビュー)を実施する。イテレーションレビューは、開発した成果物をレビューする場である。チームリーダー(スクラムマスター)を含む開発チームとプロダクトオーナーやユーザーの代表者なども参加して実施する。

図5●イテレーションレビューの実施
図5●イテレーションレビューの実施
[画像のクリックで拡大表示]

 図5は、イテレーションレビューの実施例である。開発側が開発した成果物の内容を説明した後に、ドキュメントベースの確認だけではなく、ユーザーに実際に動作するソフトウエアを使ってもらい、成果物が確実に作られているかなどを確認する。変更の要望があれば、プロダクトオーナーと開発側で対応方法を合意し、対応する変更要望は次のイテレーション以降に取り込む。

 ハイブリッドアジャイルでは、実際に動作するソフトウエアで確認することで、仕様の食い違いを防止するだけではなく、仕様の問題を早期に発見できる。そのため、以降のイテレーションで同様の問題が発生させないような予防にもつながり、手戻りリスクを低くできる。

 イテレーションレビューでは、できるだけシステムを利用するユーザー自身に操作してもらうのがよい。仕様の間違いだけでなく、操作性や分かりやすさなども確認できるからだ。こうすることで、開発しながらユーザーの満足度の高いシステムを開発していくことができる。さらに、ユーザーからのフィードバックを得ることによって、ユーザーの満足度を意識した開発を心掛けるようになり、開発チームメンバーのモチベーション向上につながることも期待できる。

 イテレーションレビューでは、(1)目的に合わせて適切なレビュアーを設定する、(2)レビュアーの人数を限定する、(3)決まった時間に行う、(4)あらかじめ確認内容を決めておく、という4点を考慮して実施するとよいだろう。

 (1)は、レビューの目的を明確にして、目的に応じて適切な利用者像を設定し、合致するユーザーにレビューに参加してもらうことだ。調整できない場合は、ユーザー企業のIT部門の人などが利用者の人物になりきってレビューする。

 (2)は、限られた時間の中でレビューを行うのに有効な施策だ。レビュアーの人数が多過ぎると、意見調整に時間がかかる。そこで、効率良くレビューするために、人数を絞ったり、調整のための期間を長めに確保したりするとよい。

 (3)は、レビュー時間の確保に有効だ。「毎週金曜日」や「毎月の最終日」などのように、定期的な時間を指定したほうがスケジュールは調整しやすい。「レビューの対象物ができたときに実施する」や「10日ごとに実施」といった計画にしてしまうと、日程調整が難しくなる場合がある。

 (4)は、レビューに余計な時間をかけないための施策である。実際に動作するソフトウエアを見ると、画面デザインや文言などのユーザーインタフェースばかりに目を取られがちになる。これでは、肝心な機能や非機能の仕様確認がおろそかになってしまう。そこで、事前にレビューで確認する内容を明確にしておけば、作業が横道にそれることを防げるわけだ。