需要計画の第2ステップのユーザーストーリーマップ
ユーザーストーリーマップと言えば、ユーザーストーリーマップの基本的な構成は、名前からユーザーストーリーでなければならないことがわかります。ユーザーストーリーとは何ですか？
ユーザーストーリーは、ユーザー、システム、またはソフトウェアの購入者にとって価値のある機能について説明しています。ユーザーストーリーの表現を標準化し、コミュニケーションを促進するために、ユーザーストーリーの通常の表現形式は次のとおりです。<ユーザーロール>として、<価値を実現>するために<アクティビティを完了>したい。
したがって、ユーザーストーリーは、ニーズを機敏に説明する方法です。従来の要件ドキュメントとは異なり、ユーザーストーリーはより簡潔で、大きなテキストの説明を必要としません。ユーザーの役割、機能、価値の実現の3つの側面に焦点を当てるだけで済みます。しかし、これらの3つの側面は不可欠であり、機能は特定の役割が問題を解決するのを支援することであるため、どのような価値を達成できるかが非常に重要です。つまり、前述の価値主導型の配信であり、ユーザーストーリーには有名な3Cの原則であるカードがあります。会話、確認;
- カードの ユーザーストーリーは、一般的にカードに書かれていますが、その理由は、視覚的な管理のためにかんばんと組み合わせることができます。一方、カードのサイズは小さく、書くことができる内容は限られており、多くの詳細を説明することはできません。これは、2番目の主要な会話につながります。
- 会話は 詳細に説明されていないため、チーム内のすべての利害関係者は緊密なコミュニケーションを維持する必要があります。ユーザーストーリーは、伝えられるため、ストーリーと呼ばれます。多くの詳細は継続的なコミュニケーションを通じて得られます。コミュニケーションは詳細を明確にするだけでなく、より深く、より多くの潜在的なニーズを引き出す機会をより深く理解することができます。
- confirmation 用户故事是需要被确认和验证的，一般在使用卡片写用户故事的时候，我们会在正面以as...I want...So that的格式书写用户故事，而背面会以given...when...then的形式写验收条件；
除了遵循3C原则，一个好的用户故事还应该符合INVEST原则，这个原则的具体内容就不在这里赘述了，我们还是把焦点回到用户故事地图上来。下方就是一个用户故事地图的例子：从图中能够发现，这是一个邮件管理的产品，最上方（棕色卡片）是对非常重要的四大功能（organize Email、Manage Email、Manage calendar、manage contacts）的描述，我们也可以把他们理解为史诗故事、下方（蓝色卡片）就是对史诗故事的进一步拆分，可以认为是一些核心的特性，而下面更多的内容（黄色卡片）就是用户故事，所以我们理解了用户故事地图从纵向来看是一步步的拆分和细化，但是在用户故事的部分，我们还发现黄色卡片被分成了三个部分，也就是图中的release1、release2、release3，这里就涉及到一个非常核心的概念MVP,也就是release1对应的内容我们管它叫做最小可行成品MVP。
最小化可行产品（MVP）， 由埃里克.莱斯( Eric Ries )在《精益创业：新创企业的成长思维》一书中提出，也是现在硅谷产品开发最推崇的理念。
关于MVP首先要澄清一个误解，MVP是要快速交付的，是要足够简洁的，但是绝对不是粗糙的、低质量的，反而是能够利用最少的功能验证市场需要，并帮助客户解决问题的高质量版本。
所以回过头来看用户故事地图也足够灵活、足够全面、足够简单，最重要的是足够有效！
第三步 需求优先级排序
ユーザーストーリーマップで分割されたさまざまなバージョンも優先されますが、メジャーバージョンの分割に加えて、ユーザーストーリーマップにあるか製品のやることリストにあるかにかかわらず、各ユーザーストーリーに優先順位を付ける必要があります。優先順位の決定は、単に頭を撫でることによって決定されるのではなく、価値、コスト、市場ウィンドウ、リスク、機会、いわゆる遅延コストなど、考慮すべき多くの要因もあります。これが優先順位付けのツールです。 ：M o S C o Wルールでは、単語の黄色い文字は4つの内容を表すことができます。
- Must have は、所有する必要のある機能を指します。これらの機能がないと、製品を製品と呼ぶことはできません。この部分は、先ほど説明したMVPにマップすることもできます。
- あるべきと は、製品が持つべき機能を指しますが、何らかの理由で機能が実現できない場合は、他の方法で交換・補償することができます。お客様はこれらの機能を気にかけますが、他の点でご満足いただければ問題ありません。 ；
- 持つことができる機能を参照している可能性がありますが、そうでない場合、影響は小さくなります。最適化された要件や機能しない要件など、後続のバージョンをネゴシエートして実装するか、一時的に提供しないことができます。
- 持っていませんが 必要とされていない機能を指し、このような機能は、価値をもたらすか、コストパフォーマンスが非常に低い、あるいは逆の需要である（このような機能を提供するが、顧客が不満されます）はありません。。で
、のいずれかを与えてみましょうすべての人の理解を容易にするためたとえば、私たち一人一人が製品である場合、どの器官が必要で、どれが不要ですか？MoSCoW原理分析の使用：
- 脳と心臓が必要であり、不可欠である必要があります。不足している場合、この製品は完全ではありません。
- 手、足、足が必要ですが、本当になくなったらどうしますか？人々はまだ生きることができ、この製品は十分に強力ではないようですが、それでも価値を生み出すことができます。
- 髪と付録が可能である可能性があり、ヘアカットは見苦しいかもしれませんが、それはコア機能に影響を与えません、そして付録は少なくともそれがどのような効果を発揮できるかを見ていません。
- 持っていない不要であるべきではないものについては、私が考えることができるのは、価値がないだけでなく健康にも影響を与える腫瘍だけです。
上記の例は完全には適切ではないかもしれませんが、MoSCoW原則の最も基本的な概念を理解するだけで十分であり、俊敏性要件の優先順位付けに役立つツールと方法が多数あります。今後の記事で詳しく説明します。 。
最後の2つの記事では、主にアジャイルデマンド管理の3つのテーマであるデマンドマイニング、デマンドプランニング、デマンドシーケンスについて説明しました。デマンド見積もり、デマンド分割など、デマンド管理に関するコンテンツは他にもたくさんあります。引き続き注目してください。
