次にリリースプランニング(ミーティング)(全体計画会議)を行って
を実施します。
要求定義はソフトウェア開発の上流工程であり、ユーザーや顧客がソフトウェアに何を求めているのかを打ち合わせ等で明確にしていく作業の事です。
要求定義の手法は色々あって組織やチームが好きに決めても良いのですが、要求仕様書というドキュメントを作成することが多いです。
要求仕様書の書き方にも特に決まり事はないのですが、最低限でも以下の項目は含めた方が良いと思います。
また要求仕様書に図や表なども含めると分かりやすくなるのでより良いと思います。
いずれにしろ、要求定義をきちんとしておかないと何を作ったら良いのか分からなくなるので気をつけましょう。
ユーザーとのコミュニケーションが重要です。
次の全体設計では全体仕様書を作成します。全体仕様書はユーザーの要求定義を元に作成する全体の仕様書です。
全体仕様書の作り方も組織やチームが好きに決めても良いのですが、やはり適当に作ると後で困るので気をつけましょう。
なおウォーターフォール開発の場合は後戻りが出来ないので相当詳細に全体仕様を決める必要がありますが、スクラム開発の場合は後から柔軟に仕様変更することが許されているので、現時点ではそこまで詳細に全体仕様を決める必要は無いです。
次にプロダクトバックログ(Product Backlog)の作成をします。
プロダクトバックログは全体の大まかな作業内容一覧(タスクリスト)のことです。
全体仕様書を元に必要なタスクを大まかにリストアップした後、依存関係や重要度や難易度などから優先順位を決めてプロダクトバックログを作成します。
ここでプロダクトバックログに含まれる各項目(プロダクトバックログアイテム、略してPBIと呼びます)は原則としてユーザー目線で書くことが大事です(※)。
※「ユーザーは○○できる」の様な文言にするとタスクの目的がはっきりします。
なおプロダクトバックログは昔ながらの付箋や、クラウド上のカンバンで管理するチームが多いようです。