InfoQ ホームページ User Stories に関するすべてのコンテンツ
-
-
誰がこのユーザストーリーを欲しているのか？
誰の利益になるのか簡単には言えないユーザストーリーがある。誰がこのユーザストーリーを欲しているのか表現できないとき、標準的な「... として、.... が欲しい。それは ... のためだ」というユーザストーリーのテンプレートをどうやって埋めればよいのか？
-
ユーザストーリー完了後の再見積は精度向上に有効か？
Scrum Development メールリストの最近のスレッドで，Paul Battison 氏がひとつの質問を投げかけている。スプリントの終了後に完了したストーリーの再見積を行って，チームの速度 (Velocity) 評価に実際の成果を反映させることは適当だろうか，と問うものだ。
-
-
繰り返しタスクはアジャイルの臭い？
ストーリーを水平方向のタスクに分割することは「アジャイルの臭い」か？これはスクラム/アジャイル計画会議によく見られ、チームの顧客価値へのフォーカスを損なう悪習なのか？代わりに提案されているのはどんなことなのか？
-
Scrum Gathering: コミュニティの実践
アジャイルコミュニティは次の3つの重要な実践について共通理解を作り出そうとしている。その3つとは、要求の収集、アジャイルコーチング、そして集団学習のためのオープンスペースの形式だ。最近開催されたScrum Gatheringでは、これらのトピックが初日、二日目、三日目の議論の的になった。InfoQはこれらのトピックについてより深く理解するため詳細を取材した。
-
ストーリー・マッピングによるユーザ・ストーリーへのコンテキスト付与
「バックログ」というスクラムの要素は、チームが実装するユーザ・ストーリーに優先順位が付けられた1つのリストである。これは、チームが直近に取り組むべきこと（たとえば、スプリントの計画など）を整理するのに効果的だ。Orlando Scrum Gatheringにおいて、Jeff Patton氏は、ストーリー・マッピングについて述べたが、これは、よりリッチなコンテキストを提供しリリース計画に役立つストーリーを構成するため���手段である。
-
優秀なProduct Ownerであること
効率的に実行されたアジャイルプロジェクトに関わったことがある人は誰でも、Product Owner(またはXPでは「Customer」)の開発チームとの協調は、チームの成功において、重要な役割を果たすという事実を証言することができる。Peter Stevens氏は、こうした役割を担った人びとが、うまく協働できるようにアドバイスをしている。
-
リーン/アジャイルな要求獲得のためにユースケースは価値がある（オプションだけど）
『Scaling Software Agility』の著者であり、RallyでChief Product MethodologistをつとめるDean Leffingwell氏は、ユースケースが大規模のリーン/アジャイルなプロジェクトにおける要求をモデル化する価値のあるツールになりえると結論を下した。
-
タスク単位ではなくストーリー単位で作業を行う
実装作業をチーム内で分散して行うために、また、適度な粒度での進捗のトラッキングを行うために開発者はユーザーストーリーをタスクへと分割する。不幸なことに、ストーリーをタスクへと分割してみると重大なタスクばかりになってしまいイテレーション内にそのストーリーを終えることができない、といったことが起こりうる。
-
-
-
新たなユーザストーリーフォーマットがビジネス価値を強調
アジャイル要求を捉える共通のフォーマットであるユーザストーリーは、ビジネス価値にもっとフォーカスしてもよいのではないか。ユーザストーリーを記述する従来のフォーマットは、「As a <type of user> I want <some functionality> so that <some benefit>」である。価値を中心とすると、「In order to <achieve some value>, as a <type of user>, I want <some functionality>」このようになるだろう。
-
ユーザストーリーの適正サイズ
経験豊富なアジャイル開発実践者なら誰もが知っていることだが、適正なストーリーを引き出してまとめるのは、もっとも難しい作業のひとつだ。Pat Kua氏は最近自分の記事で、次の重要な問いかけをした。ストーリーはどれくらい詳細にすべきだろうか？