PBI分割のコツ

Transcript

1. PBI分割のコツ
2. アウトライン PBI 分割に必要な基礎知識 - ユーザーストーリー - INVEST 分割の観点 - データ境界に沿って分割する - 操作の境界で分割する - 異常系を分離する - 横断的な関心事を分離する - パフォーマンス制約を分離する アンチパターン - タスクに分割する - 関連する変更への誘惑に負ける - 追加要望を同じPBIに追加する - 分割するタイミングが早すぎる
3. PBI分割に必要な基礎知識
4. PBI 分割に必要な基礎知識 - ユーザーストーリー - INVEST
5. ユーザーストーリー ソフトウェアで実現したい機能（PBI）の記述形式 フォーマット： 「ユーザーのペルソナ」として、私は「ソフトウェアによって可能になる行動」をしたい。 なぜなら「行動ができるようにしたい理由」があるからだ。 例： - 「ユーザーとして、私は商品をカートに追加したい。なぜなら、複数の商品を一度に購入したいからだ。」 - 「銀行の顧客として、私は残高を確認したい。なぜなら、今月の出費を管理したいからだ。」 - 「プロジェクトマネージャーとして、私はタスクの進捗状況を視覚的に確認したい。なぜなら、チーム全体の進行度を把握したいから だ。」
6. なぜユーザーストーリー？ 「How」ではなく「What」をベースに議論・管理できる - ステークホルダーがユーザ価値にフォーカスできる - 簡潔で理解しやすい - コミュニケーションを促進する - 優先度判断が容易になる - 手段は別に議論できるようになる - E2Eであることを強要される - テスト容易性が上がる（直接受け入れテストに投射できる）
7. INVEST よい ユーザーストーリー に必要な要素 1. Independent（独立性） ◦ 他のストーリーに依存せず、単独で計画・実行できる。依存関係があると待機による遅延や優先度入れ替えができない恐れ がある。 2. Negotiable（交渉可能） ◦ チームやステークホルダーと話し合いながら調整や変更が可能であるべき。ストーリーは詳細な仕様書ではない。 3. Valuable（価値がある） ◦ ストーリーはユーザーやビジネスに対して価値があるものでなければならない。単なる技術的なタスクではない。 4. Estimable（見積もり可能） ◦ 時間やリソースの見積もりができる。見積もりができない場合、ストーリーが大きすぎたり、あいまいだったりする可能性があ る。 5. Small（小さい） ◦ 短期間で完了できるサイズである。ストーリーが大きすぎる場合、「エピック（ Epic）」として分割して扱うことが推奨される。 6. Testable（テスト可能） ◦ 完了基準が明確にできてテストできる。明確な基準がないということはスコープが曖昧ということであり、コレジャナイや隠れク ソデカPBIのリスクを内包する。
8. PBI はユーザーストーリーで書くべき？ 正直マストではない - 「How」ではなく「What」をベースに議論・管理する - INVEST を維持する ができればこだわる必要はないが、 ベストプラクティスには従った方が楽だよ ※「なぜなら〜」はあんま書かなくてもいいかも ...？
9. 分割の観点
10. 分割の観点 - データ境界に沿って分割する - 操作の境界で分割する - 異常系を分離する - 横断的な関心事を分離する - パフォーマンス制約を分離する
11. データ境界に沿って分割する データを論理的な集まりで分けて考えて段階化する ユーザーはユーザー情報を入力できる ↓ 1. ユーザーはアカウント名とメールアドレスを入力できる 2. ユーザーは本名と年齢と性別を入力できる 3. ユーザーは住所を入力できる a. ユーザーは郵便番号を元に番地まで自動で入力できる 4. ユーザーは趣味を入力できる etc….
12. ユーザーは検索条件を指定して データを検索できる ↓ 1. ユーザーは検索条件を指定し て該当するデータの件数を確 認できる 2. ユーザーは検索条件に該当す るデータを一覧で確認できる 管理者はユーザーを管理できる ↓ 1. 管理者はユーザーを追加でき る 2. 管理者はユーザーを編集でき る 3. 管理者はユーザーを削除でき る 操作の境界で分割する ユーザーの行う操作を段階的に分離する
13. ユーザーはメールアドレスとパスワードを用いてログインすることができる ↓ 1. ユーザーは正しいメールアドレスとパスワードを用いてログインすることができる 2. ユーザーは間違ったメールアドレスとパスワードを入力するとログイン情報が不適切 であることを知ることができる 3. ユーザーはログインに失敗すると、メール経由でパスワードを更新することができる 異常系を分離する 正常系と異常系で分けて考えて異常系対応をバリエーションとして扱う
14. 管理者はシステム設定を編集することができる ↓ 1. ユーザーはシステム設定を編集することができる 2. 管理者だけがシステム設定を編集することができる 横断的な関心事を分離する セキュリティ・エラーハンドリング・ロギングなどの機能に対して直行する関心事を分離する
15. パフォーマンス制約を分離する 機能要件とそれに付随する非機能要件を段階的に扱う ユーザーは登録済みユーザー一覧を0.5sec以内に取得でき る ↓ 1. ユーザーは登録済みユーザー一覧を取得できる 2. ユーザーは登録済みユーザー一覧を0.5sec以内に取得 できる
16. アンチパターン
17. アンチパターン - タスクに分割する - 関連する変更への誘惑に負ける - 追加要望を同じPBIに追加する - 分割するタイミングが早すぎる
18. タスクに分割する 論外 ここ読め
19. 関連する変更への誘惑に負ける 「これやるならついでにこれもできるじゃん」「まとめてやったほうが効率いいよね」 「このパターンも考慮したほうがいいよね」「こうしたほうがいんせつだよね」etc… で 際限なく PBI は肥大化していく ユーザーが正しいユーザー名とパスワードを入力してログインする ↓ ユーザーがログインページで正しいユーザー名とパスワードを入力し、 SMSコードを受け取り、二段階認証を通 過し、GoogleアカウントやFacebookアカウントでもログインでき、パスワードを忘れた際にはリセットリンクを 受け取り、セッションがタイムアウトした場合は再度ログインし、視覚的に洗練された画面で操作を行う。
20. 追加要望を同じPBIに追加する 「関連する変更への誘惑に負ける」と一緒 追加要件の発信元がどこであれ別の PBI として管理しましょう
21. 分割するタイミングが早すぎる プロダクトバックはナマモノ 絶対やるつもりで作った PBI は10年 経っても着手できないし、完璧に作っ た仕様も半年後には腐って現状に合 わなくなる 着手が先なPBIはエピックとして取っ ておこう 小さくて具体的 大きくて抽象的
22. おさらい 大前提 - ユーザーストーリー - INVEST 分割の観点 - データ境界に沿って分割する - 操作の境界で分割する - 異常系を分離する - 横断的な関心事を分離する - パフォーマンス制約を分離する アンチパターン - タスクに分割する - 関連する変更への誘惑に負ける - 追加要望を同じPBIに追加する - 分割するタイミングが早すぎる
23. おわり
24. おまけ｜実践上のずるい分割観点 - ユーザーを非現実的に限定する - 「CURLを使えるユーザーはデータを確認できる」 → 「ユーザーはデータを確認できる」 というステップ化とか - デザイン品質を分離する - ユースケースに影響しないデザイン調整をまとめ て別PBIにして後ろに回す