# ユーザーストーリーの分割 ## 定義 ユーザーストーリーの分割とは、大きなユーザーストーリー(エピック)を、1イテレーションに収まる複数の小さなストーリーへ分けることである。分割すべきタイミングは3通りある。(1) ストーリーが大きすぎて1回のイテレーションに収まらない場合、(2) ストーリー自体は1イテレーションに収まるが、計画中のイテレーションには他のストーリーが入っていて余地がない場合、(3) より正確な見積りが必要な場合。分割の切り口として、データ境界に沿った分割、操作の境界(CRUDを含む)に沿った分割、横断的な関心事(セキュリティ・ロギング・エラーハンドリングなど)の分離、機能要求と非機能要求の分離、サブストーリーの優先度に沿った分割、の5系統が示される。ストーリーをタスク(ユーザーインターフェイス/中間層のような実装レイヤー)へ分解することは禁じられ、分割しづらい場合は各論理層を部分的に貫通する「曳光弾」の作戦を用いる。適切な大きさに分割したストーリーには、優先度の異なる「ついでの変更」を上乗せしてはならない。逆に、個別には小さすぎる複数のストーリーは1つにまとめてよい。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 12 ユーザーストーリーの分割]] §1-9) ## 横断的知見 - 12章はデータ境界に沿った分割の例として、バランスシートの入力項目や電話番号の国内/国際といった、同種のデータの粒度・種別による分割しか挙げていない。23章のケーススタディでは、20ポイントの「弱いエンジンと対戦できる」というストーリーを、認識できる勝ち手の形(リング用・ブリッジ用・フォーク用)ごとに3つのストーリーへ分割している。これは入力データそのものではなく「対応するゲームルールのバリアント」による分割だが、複数存在する種類・カテゴリのそれぞれを個別ストーリーにするという12章のデータ境界分割と同じ構造を持つ。12章の例だけでは対象が入力データに限られるように読めるが、23章の実例は、扱うルール・条件のバリアントにも同じ考え方が適用できることを示している。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 12 ユーザーストーリーの分割]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §2) - 12章は分割すべき3つのタイミングを示すが、「見積もった時点で規模が大きいからすぐ分割する」とは述べていない。23章のケーススタディでは、20ポイントのストーリー(「ゲームの見た目を美しくする」)について、カルロスが「あとで少なくとも2つに分ける方法を見つける必要がある」と認めつつ、「このストーリーを実際に開発するときになってから分割すればいい。いまの時点で分割してもなんのメリットもない」と判断し、その場では分割しなかった。実装に近づくほど情報が増えて分割の精度が上がるため、必要になるまで分割を遅らせるという運用は、12章が挙げる3つの分割タイミングの範囲内の解釈として読める。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 12 ユーザーストーリーの分割]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §2) - 12章は分割の切り口(データ境界・操作境界・横断的関心事・非機能要求・優先度)を列挙するが、分割にともなう見積り上の副作用には触れていない。23章のケーススタディはこの副作用を2つの実例で示す。1つは、20ポイントのストーリーを3つに分割した合計が21ポイントになっても元の見積りに合わせて調整する必要はないという判断(「見積りはあくまで見積りにすぎない」)。もう1つは、依存関係のために先に着手できない部分を切り出す際、切り出した分だけ元のストーリーの見積りを機械的に減らす(8→7ポイント)ことを避け、見積りの精度を実際以上に高く見せないようにした判断である。分割は作業への理解を深める手段であって、算術的な整合性を保つ手段ではないという運用規範は、23章の実例からのみ読み取れる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §2) ## 未解決の問い - 「データ境界」と「操作の境界」のどちらの切り口を先に試すべきかの優先順位は、12章では示されていない。23章の実例では発言者が偶然思いついた切り口が採用されており、複数の切り口を試す際の探索順序は原本に明示されていない。 - 分割を「実装に近づくまで遅らせてよい」という23章の運用と、12章が示す「より正確な見積りが必要な場合には分割する」という基準は、どちらを優先すべきかの境界(いつまで遅らせてよいか)が明確でない。 - ストーリーをタスクに分解してはならないという12章の禁則(§7)と、23章でイテレーション計画時にストーリーをタスクへ分解する場面(表23.7など)がどう両立するかは、14章「イテレーション計画づくり」の取り込みで明らかになる可能性がある。 - 分割の切り口を5系統(データ境界・操作境界・横断的関心事・非機能要求・優先度)以外にも見出せるかは、他の章・他のソースの取り込みを待って検証する必要がある。 ## 関連 - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 12 ユーザーストーリーの分割]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] - concept: [[フィーチャの優先順位づけ]](分割してはじめて優先順位づけが可能になる関係) / [[ストーリーポイント]](分割前後の見積りの扱い) - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 12章, 23章.