1

2014年5月21日

ＧＭＯインターネット株式会社

次世代システム研究室

藤村 新

AEP読書会

第十二章

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

どんなに優先順位が高かろうと、ユーザーストーリーの大きさが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

おわり