Jeff Patton がよく紹介する絵に、モナリザを使ったインクリメンタルとイテレーティブの説明があります。
インクリメンタル = フィーチャごとに作っていく
スクラムでは、ユーザーストーリーの独立性を高め、一つ一つのストーリーの独立性を高める事で、スプリント毎に徐々(インクリメンタル)に「出荷可能な増分(Potentially Shippable Increments)」を作っていく、という原則があります。独立性が高ければ、順番を入れ替える事も容易になり、製品開発の方向性を決めるプロダクトオーナーにとっては、現在の状況を見極めてベストな判断を下せる選択肢が増える訳です。
各ストーリーを独立してテストできることで、全体が組み上がった後に膨大なテストをこなすのではなく、各部品(フィーチャー)単位での健全性を確保して、さらに全体を結合したときのテストをしよう、という流れになり、欠陥の発見を早める作用も期待できます。
図1: フィーチャ毎に完成させるインクリメンタル
[注] 品質の高い製品をスプリント期間内(2週間)で一気に作れるほど我々の開発速度は早くないので....という前提になっています。
イテレーティブ = 全体のユーザーエクスペリエンスを考える
一方で、部品毎に設計して作っていく場合、組み上がったときの全体のユーザーエクスペリエンスがちぐはぐになってしまう危険性があります。
初期の設計時点では問題なかったはずのものが、インクリメンタルに作りながら、順番を入れ替えたりするうちに、おかしな組み合わせの製品になってしまう、というケースに注意が必要です。ユーザーは常に製品全体を自分のワークフローに従って利用するわけですから、機能毎の品質だけでなく、つながりを体験することになります。
そこで、設計やリリース順序の変更を行う場合は、製品全体の設計図を参照しながら決定を行おう、というのがユーザーエクスペリエンス側の主張になります。
図2: 全体のエクスペリエンスを考えるイテレーティブ
ユーザーストーリーマッピング
Jeff Patton のユーザーストーリーマッピング技法は、ユーザーのワークフロー(横方向) と インクリメンタルなリリース(縦方向) を可視化するやり方です。
- 一つ一つのスプリントの中で、製品全体の設計を見失わない
- 設計を柔軟に変更可能(ポストイットですから)、具体的に議論できる(ポストイットですから)
- 一つの図で製品全体を表し、非技術者でも議論に参加可能 (マーケティング、営業、経営者も)
図3: ユーザーストーリーマッピングは、利用者ワークフローと製品リリースの関係を視覚化
チームの作業計画にはタスクボード(スプリントバックログ)
チームの作業計画にはスプリントバックログを表すタスクボードを併用します。ユーザーストーリーマッピングは、リリースまでしか表しませんので、スプリント毎の着手順序は表示しません。チーム毎のスプリント計画にはちょっと図の粒度が大きすぎる、というケースが多いと考えられます。
図4: スプリントとリリース
元の資料はこちらにあります
- Jeff Patton: Successful Incremental Releases
- Yasunobu Kawaguchi: 10分でスクラム
