ユーザーストーリーの分割

AEP読書会 第十二章 ユーザーストーリーの分割 2014年5月21日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新 1

どんなに優先順位が高か ろうと、ユーザーストーリー の大きさが1回のイテレー ションでは完了できないの であれば、2つ以上に分 割せざるを得ない。

1.ユーザーストーリーをいつ分割するのか ストーリーが大きすぎて1回のイテレーションに は収まらないような場合 いま計画を立てている次のイテレーションには もう他のストーリーが入っていて、そのストーリー を入れる余地がない 一部なら実装できるが、すべては無理 大きなストーリー(エピック)を分割するのは、よ り正確な見積りが必要な場合に有用

2.データ境界に沿って分割する 例1)ユーザーとして、バランスシートの情報を入力できる ユーザーとして、バランスシートのデータをサマリで入力できる 入力項目は、資産、負債の2つ ユーザーとして、バランスシートのカテゴリごとの入力ができる 現金預金、投資有価証券、不動産、短期貸付金など ユーザーとして、入力を間違えないような入力値のバリデーションが欲 しい 負の値も入力できる、入力値の端数は自動的に四捨五入して丸 める ユーザーとして、貸付金の詳細を入力できる このストーリーで扱う詳細情報が貸付金に限定されているため小 さくなった 他のストーリーの雛形として使うことができた

2.データ境界に沿って分割する 例2)自動FAXシステム システムの設定を変更可能にする 米国内の電話番号と国際電話番号とにストーリーを分割 例3)ローンの返済を処理するシステム 借主として、ローンを返済したい 借主が誤って返済額以上の小切手を送ってしまったらどうするの か？ 払い戻し小切手を借主に郵送しなければならない この対応は返金額が¤2以上の場合に限られる 借主として、ローンを返済したい。このとき、払い過ぎてもかまわな い。 借主として、もし返済し過ぎてしまったら、 ¤2以上の場合に限り、 払い戻しできる。

3.操作の境界で分割する 例1)きわめて複雑な検索画面 画面の上半分には数十個の入力項目 中央には入力内容を元にデータベースへのクエリを構築できるク エリビルダ その下には複雑なデータ表示用グリッド 3つに分割 1. 基本的なユーザーインターフェイス  検索条件の半分を扱う  クエリビルダ  検索結果数だけを表示 2. データ表示用のグリッド  開発にかかる時間が読めなかったため2番目にした 3. 残りの検索条件を入力する項目

3.操作の境界で分割する 例1)コーチとして、チームの選手を管理できる(SwimStats) CRUD(Create, Read, Update, Delete)操作を境界として分割  コーチとして、新しい選手をチームに追加できる  コーチとして、チームの選手の情報を編集できる  コーチとして、チームから抜けた選手を削除できる

4.横断的な関心事を分離する 例1)データを検索して、その結果を表示する 表示する結果はそのユーザーに閲覧が許可されているデータに限定し なければならない 表示する検索結果の制約を無視する 最初のイテレーションでは、ユーザーはすべての検索結果を見 ることができる 例2)ユーザーとして、システムを利用したければユーザー名と パスワードを入力してログインしなければならない セキュアでないログインとセキュアなログインの2つのストーリーに分離 横断的な機能の別のストーリーへの分離を検討すること。 その場合、横断的な機能を含まないストーリーと、含むストー リーの2つに分けること。

5.パフォーマンス制約をストーリーにする 「動くようになってから、速く動かすことを考えろ」(カーニハン ＆プローガー) 例)株価をグラフ表示させる 満足条件 的確な折れ線グラフ表示 データが存在しない場合の対応 パフォーマンス パフォーマンスのためのキャッシュ機能は欠かせない要素 別の新規ユーザーストーリーにして、次のイテレーションで開発する 大きなストーリーの機能要求と非機能要求とをそれぞれ個別 のストーリーに分割することを検討せよ。

6.優先度に沿ってストーリーを分割する 例)ユーザーとして、システムにログインしなければならない 満足条件 ユーザーが正しいユーザー名とパスワードを入力した場合に限り、 アクセスを許可する ユーザーが間違ったパスワードを3回連続して入力するとログインで きなくなる。ログイン制限を解除するにはカスタマサービスに連絡しな ければならない ユーザーがログイン制限されたら、そのユーザーに対して、そのアカ ウントを使ってログインしようとした形跡があったことを知らせるメー ルが送信される 大きなストーリーを分割する場合には、サブストーリーの優先 度に沿って分割すること。

7.ストーリーをタスクに分解してはならない 悪い例) ユーザーインターフェイスを実装する 中間層を実装する システムを「曳光弾」で照らす。(ハント＆トーマス) 「曳光弾」とは、あるフィーチャに必要なシステムの論理層すべ てをまたいで実装することを指す。 大きなストーリーをタスクに分解するのではなく、ストーリーを曳 光弾にするための作戦を考えること。

8.関連する変更への誘惑を断つ ストーリーを適切な大きさへと首尾よく分割できたとしても、そ こに作業を追加してしまえば、分割した意味がなくなる 「ついでにこの変更もやれるじゃないか」 他のフィーチャと同様に優先順位を付けなければならない 適切なサイズに分割したストーリーに、関連する変更を上乗せし てはならない。 ただし、関連する変更の優先度が同じ場合はこの限りではない。

9.ストーリーをまとめる あらゆるストーリーを最初からなるべく小さくしておきたくな るかもしれないが、ガイドラインの狙いはそうではない。 イテレーション期間：2週間 2日から5日で完了できる大きさにストーリーを分割する のが適切 イテレーション期間：1週間 ストーリーはもう少し小さく分割した方が良い イテレーション期間：2週間以上 イテレーション期間2週間同様、2日から5日が適切 1つにまとめたストーリーは、個別の小さな見積りを足し合わせる のではなく、全体を1つの数値で見積もる。(バグレポートなど)

話し合ってみよう 1. 現在の、または最近のプロ ジェクトで、分割するのが 難しかったストーリーは?こ の章を読んだ後なら、どう やって分割するだろうか？

個人的回答 パスドラクローンのパズル部分 のストーリー。 「3.操作の境界で分割する」を 参考に、ページ上部のエフェクト 部分、ページ下部のパズル部分 等に分割した。

話し合ってみよう 2. ストーリーをタスクに分 解して、そのタスクを ユーザーストーリーのよう に扱うと、どのような問 題が起きそうだろうか?

個人的回答 計画の基準がフィーチャではなく タスクになってしまい、プロダクトを 正しい視点で捉えられなくなる。 その結果、ユーザーに直接価値を 提供することができなくなる。

おわり 19