..-- mode: rst --

マップによる新しいユーザーストーリーバックログ

なぜフラットなユーザーストーリーバックログが上手くいかないのだろう？ どうしたら、システムの説明や、優先順位付け、そしてリリース計画がやりやすい、より優れたバックログを実現できるのだろうか？

2008年10月08日

(ここに画像が)

ここに写っているのはGaryだ。

Garyと筆者は、ユーザーストーリーマップを一日かけて一緒に作りあげた。ユーザーストーリマップとは、よりよいプロダクトバックログのことだ。ユーザーストーリマップを作るという作業は、作業者をビックピクチャー、つまりに目先の個々のストーリーの代りにプロダクトの全体に注目させるのに役立つ。

優先順位付けの時に、Garyはシステムの全体を俯瞰しながら優先順位付けをすることができた。Garyのケースでは、もともとMimi(Music Industry Marketing Interface)を構築しようとしていたが、優先順位付けに着手した時に、バンドメンバーのクラブでのギグのプロモーションに目を集中してしまった。そのプロモーションは、１つのストーリーとしても、**エピック** [1] としても大き過ぎたのだ... .. [1] : もとの意味はEpic(叙事詩) だが、ストーリーより粒度の荒い単位と位置付けられている。提唱者はMike Cohn氏

マップを使って、販促メールシステムの設計、視聴者リストの作成やメール送信、聴衆からの反応を分析するについて詳細を考えるために使われた。マッピングエクササイズの最後までに、難題のように見えた、Mimiの他の音楽に関係する事柄すべてを成し遂げることができた。さらには、商用ソフトウェアの一部分の開発、商用ソフトウェアの一部、メール送信作業を簡単に素早く実現する、ことが素晴しいアイディアに見えた。そして実際にそうだった。

MimiはGary、Dave Hoover、そしてObtivaの立派な人たちの多大なる汗と涙を費してリリースした。これを書いている時に、Mimiは現在月に400万メッセージに近いメールを送信している。そのユーザーエクスペリエンスは芸術的な仕事で、セクシーなソフトウェアといってもよいくらいだ。そして、その我われが最初の日に議論のすえ作りあげたユーザーストーリーバックログは、高い水準でその時見たのと同じ - リリース対象外だと除けておいたストーリーは除いて - Mimiのあるべき姿を今でも記述している。

System Message: WARNING/2 (<string>, line 42)

Explicit markup ends without a blank line; unexpected unindent.

フラットなバックログはうまくいかない

平らな地球

私にとって多かったトラブルのひとつは、アジャイル開発の共通プラクティスである 平らなユーザーストーリーバックログ という考え方だ。この考えは筆者にとっては、つまらない考え方に見える。完全に愚かだということではないが、もし自分がインクリメンタルに小さい単位でソフトウェアを作りあげようとした場合、何が最初かを知る必要がある。バックログは、それらの単位を作る順番、つまり最も高い価値から低い価値へ、に並べる。もしあなたがプロジェクトマネージャなら、それは素晴しいことだろうか？ - 私は違う。

私はこの原稿を、クライアントサイトから戻る飛行機の中で書いている。ストーリー書きとリリースプランニグを行った数日間はちょっとした成功体験だった。私は楽しかった - そのグループが巻き込まれていき、自分達がわかってきたことが心地良くなっている様を見るのが楽しかったのだ。私はあるプラクティスを使ってきた。私はそれを(今は) ストーリーマッピング と読んでいる。私は最初はこのアプローチについて How You Slice It. (どのように分けるか) という記事で言及した。その記事は2005年1月に出版された - しかし記事を書き終えるまでに、このプラクティスを2〜3年間使っていた。

数年たった今、私はまだこのアプローチを気に入っている... もっとも私がこのアプローチに 銀の弾丸 を見ているという危険性があるが。私が独善的な愚か者になりつつあるという初期段階の警告ともいえる。しかし、私はますます多くの人々が似たようなアプローチに辿りついたのを見て来ている。少なくとも、私がおかしすぎるわけではないんだ。 .. .. Let me describe what's wrong with story writing, then generally what a story map is - and why it solves problems for me. これから、ストーリーを書く時に何がいけないのか、それからストーリーマップとは何かという一般論と、なぜストーリーマップが私の問題を解決するのか、について述べていくことにする。

System Message: WARNING/2 (<string>, line 65)

Explicit markup ends without a blank line; unexpected unindent.

平坦なバックログはシステムが何を行うのかを説明するには貧弱である

System Message: WARNING/2 (<string>, line 70)

Explicit markup ends without a blank line; unexpected unindent.

ユーザーストーリーを実装していく順番で並び換えることは、私にそのシステムが何を実現するのかを説明するのに役立たない。試しに、ステークホルダーかユーザーから、`あなたが作っているシステムは何をするんだい？` と質問された時に、ユーザーストーリーバックログを見せてみよう。

System Message: WARNING/2 (<string>, line 73)

Explicit markup ends without a blank line; unexpected unindent.

私のお金のために、システムを理解しようとすること - システム全体 - はソフトウェア開発の難しい領域だ。アジャイルチームでよくきく苦情のひとつは、最初の段階では持っていても、ビッグピクチャーを失なってしまうということだ。

System Message: WARNING/2 (<string>, line 76)

Explicit markup ends without a blank line; unexpected unindent.

私はかつて同僚に悪いストーリーバックログについて考えた内容を説明したことがある。そのストーリーは次のような影響をもたらす。

System Message: WARNING/2 (<string>, line 79)

Explicit markup ends without a blank line; unexpected unindent.

木から落ちた、枯葉の山が、ゴミ箱に捨てられる

System Message: WARNING/2 (<string>, line 82)

Explicit markup ends without a blank line; unexpected unindent.

"われわれは、顧客と一緒に多くの時間をかけて作業する。われわれが彼らのゴール、システム利用者、そして構築するシステムの主要部分を理解するのは難しい。主要部分を理解してから、作り手がその詳細、つまり構築できるだけの機能性の粒々にやっととりかかることができるのだ。私の頭の中では、見えている木のどこか主要部分は、システムのゴールか、システムを駆動する望むべき利益によって作りあげられるものだと考えている。大きい部分でいうと利用者であるし、小さな部分は顧客が望む機能や性能である。このような流れの末に、落葉は開発イテレーションに収めるのに十分なくらい小さくなる。"

System Message: WARNING/2 (<string>, line 86)

Explicit markup ends without a blank line; unexpected unindent.

これらの作業は結局のところ、共通理解がすべて確立した後で、すべての葉を木から取り除いて、それらを葉っぱ入れに詰めようという気になる。その後にやっと木を刈るのだ。 これが私にとっての平らなバックログだ。どうとでもとれる覆いのようなバッグだ。

System Message: WARNING/2 (<string>, line 91)

Explicit markup ends without a blank line; unexpected unindent.

私はそのシステムについての真実を物語るための順序立てられたコンテキストを必要としている。新しいシステムにとって、平らなバックログは、それがもしすべてのストーリーを認識し終えたとしても、決定を助けるという目的には憂鬱なんだ。

System Message: WARNING/2 (<string>, line 94)

Explicit markup ends without a blank line; unexpected unindent.

パズルのピース

System Message: WARNING/2 (<string>, line 97)

Explicit markup ends without a blank line; unexpected unindent.

情報カードの束や、またはユーザーストーリーが満載のスプレッドシートを与えられ、それらを凝視するのに数時間、それらについて議論するのに数時間かかってしまう... しかしそれでも、私はいつも、何か欠けているのではないかという不安な気持ちで立ち去るのだ。もちろん、すべてを知ることができないことは知っている。しかし、私が望むのは、いまよりも少しでも満足な気持ちでいれたらなぁというだけなのだ。

System Message: WARNING/2 (<string>, line 100)

Explicit markup ends without a blank line; unexpected unindent.

ソフトウェアの新しい部分のスコープ調整の時に、重要な機能を見落しという不意を突かれることがどれだけ頻繁にありますか？

System Message: WARNING/2 (<string>, line 103)

Explicit markup ends without a blank line; unexpected unindent.

平らなバックログでのリリース計画は難しい

System Message: WARNING/2 (<string>, line 106)

Explicit markup ends without a blank line; unexpected unindent.

私は、バックログの中にあるストーリーの数が最低でも数ダース - しばしば100を越えるプロジェクトに巻き込まれることがよくある。特に着手しはじめた時には、ストーリーを抽象度を高いまま保つのが難しい作業となる。最初のリリースのバックログ中に、120かそこらのストーリー数で終わることはよくある。それらを一歩一歩こなしていき、内外の決定をしていくことは退屈なことだ。そんな中でも今まで一番ひどかったのは、グループでバックログの優先付けミーティングで座り続けていたことだ。これはひどい。

System Message: WARNING/2 (<string>, line 109)

Explicit markup ends without a blank line; unexpected unindent.

ストーリーマップを作る

System Message: WARNING/2 (<string>, line 112)

Explicit markup ends without a blank line; unexpected unindent.

ユーザーストーリーを扱いやすい形に並びかえる - マップは私にはうまくいった

System Message: WARNING/2 (<string>, line 115)

Explicit markup ends without a blank line; unexpected unindent.

とてもシンプルなアイディアだ。小さなストーリーマップはこのようになるかもしれない。

System Message: WARNING/2 (<string>, line 118)

Explicit markup ends without a blank line; unexpected unindent.

ストーリーマップダイアグラム

System Message: WARNING/2 (<string>, line 121)

Explicit markup ends without a blank line; unexpected unindent.

マップの最上部に位置するのは 巨大なストーリー群 だ。 私はそれらをアクティビティと呼んでいる。(この用語はLarry ConstantineやDon NormanらUX [1] コミュニティの人々が使っている用語を借りている)

[1]	: User eXperience(ユーザーエクスペリエンス)の略

System Message: WARNING/2 (<string>, line 126)

Explicit markup ends without a blank line; unexpected unindent.

"アクティビティ" のストーリーは次のように読まれている: コンサルタントとして、私はメール管理をしたい。そうすれば私はクライアント、同僚、そして友人についていくことができる。

System Message: WARNING/2 (<string>, line 129)

Explicit markup ends without a blank line; unexpected unindent.

しかし、このような表現は、ひとつのイテレーションやスプリントに納めるには大きすぎる。

System Message: WARNING/2 (<string>, line 132)

Explicit markup ends without a blank line; unexpected unindent.

こようなストーリーは、 "メッセージを送信する"、"メッセージを読む"、"メッセージを削除する"、"メッセージをスパムとマークする"といったように分割されて小さなストーリーになる。私はこれらのストーリーを、ユーザータスクと呼んでいる。(この単語もUX界隈から借りてきている) 多くのアジャイル界隈の人々にとっては、 タスク という言葉は開発者がユーザーストーリーを完了するためのやることを意味している。ユーザータスクは、ユーザーが彼らの目的に到達するためのやるべきことだ。本来タスクという言葉は、誰かが目的に到達するためにするべき何かのことである。ユーザータスクは、ユーザーが彼らの目的ニ到達するためにすることであり、デベロッパータスクは開発者がストーリーや、Antで何かをうまくやるためのAntタスクを作成することである。