曳光弾で考えるユーザーストーリーの分割
ストーリーを分割する
大きすぎるストーリーを分割したい時
以下の観点で分割をするとよいよと
アジャイル見積もりでは記載されています。
- データ境界に沿って分割する
- 操作の境界で分割する
- 横断的な関心毎を分離する
- パフォーマンス制約をストーリーにする
- 優先度に沿ってストーリーに分割する
そして大きいストーリーを分割する上で
どうしてもうまくユーザーストーリーに分割できず
タスクに分割してしまった経験を持つ人も多いのではないかと思います。
そこでストーリーを「曳光弾」にするための作戦を考えることで
うまくストーリーを分割する術がないか考えていこうと思います。
大きいストーリー
どのようにチームで見積もりの基準を設けているかによって
若干差異はあるかもしれないですが、
基本的にストーリーの見積もりは、規模感で考えていくと思います。
昨今マイクロサービスなども増えてきたことで
一つの機能に関連するAPIが増え
結果規模感が大きくなることも多いと思います。
我々のチームはイテレーションを1週間に設定していたため
リリースまでには大きすぎるストーリーがしばしばあり
チームとしても課題感を持っていました。
曳光弾とは
そもそも「曳光弾」とは何か？
元は達人プログラマー 職人から名匠への道で紹介されている言葉で
特定の論理層だけ完成させず、それぞれ部分的であったとしても
全ての論理層を跨いだ実装を心がけることを指しています。
More Effective Agile “ソフトウェアリーダー”になるための28の道標では
バーティカルスライスと表現されています。
曳光弾で考えるストーリー分割
ここでは、マイクロサービスを採用しているプロダクトで
ダッシュボード画面に新しい表示項目を増やしたいようなケースで考えてみます。
ストーリーとしては「ユーザーはダッシュボード画面で、顧客のアカウント名を見ることができる」としておきます。
ざっくりな全体像
今回は、マイクロサービスなどを前提にしているため、APIが複数あり
横断したデータ取得を行う想定なので
API毎に役割が変わってきます。
- hoge API はBFFのような立ち位置
- fuga API は共通APIのような立ち位置
そのため、APIを全量完成させててからリリースまで持っていこうとすると
規模感も大きくなり、リリース手順も複雑になっていきます。
そこで曳光弾を意識することで、以下のような考え方でストーリーを分割することができます。
- データは１件ではだめか？
この観点をもつだけで、一気に分割がしやすくなり
もともと一つだったストーリーが以下のように分割することも可能になります。
- 特定のユーザーは、ダッシュボード画面で顧客のアカウント名"hoge"を見ることができる
- 特定のユーザーは、ダッシュボード画面で全ての顧客のアカウント名を見ることができる
- 全てのユーザーは、ダッシュボード画面で全ての顧客のアカウント名を見ることができる
ここではデータを一件だけ固定値で返す所から始めることで
全ての論理層をほぼまたぐような形でストーリーを分割できます。
※DBから固定値を返すか、fuga APIから固定値を返すかは検討の余地があります。
「特定のユーザーは、ダッシュボード画面で顧客のアカウント名"hoge"を見ることができる」を想定したケース
バーティカルスライスすることで、ストーリーとしては価値は届けつつ
実装する重みを分けながら進めることができます。
fuga API から特定のデータだけ固定で返すことで
フロントとBFFに集中して開発を行い、
次のストーリーで、fuga API の開発を進めるようなイメージです。
初めから全てのデータに対応しようとすると
規模感も大きくなり、想定していないケースに出くわす頻度も増え
結果イテレーション内でリリースできない可能性も高くなります。
論理層を全てまたぐ意識
論理層を全てまたぐことはとても有効だと感じました。
大きなストーリーをただ分割せず、一つの機能として分割できているため
ユーザーへの価値を見失わず進むことができます。
また、APIもストーリーの内容に合わせて実装する箇所も分割できるため
結果リリースサイクルが早くなります。
バーティカルにスライスすることでリリース単位を小さくでき
何か問題が起きたときも原因のきりわけもしやすく
すばやいFBを得ることにつながり重要なスキルだと感じました。
特にマイクロサービスを採用しているプロダクト開発においては
とても大きな効果を発揮するため
イテレーションに見合った分割ができていないと感じた時は
分割できないか検討するよう心がけていきたい。
Discussion