用户故事如何表达需求

首先什么是敏捷
美国敏捷联盟提出四大宣言和12条准则。
敏捷宣言：个体和互动优于流程和工具工作的软件，优于详尽的文档客户合作优于合作谈判。响应变化，优于遵循计划。敏捷是一个相对的词汇。
十二准则。1.我们的最高目标是通过尽早和持续的交付有价值的软件来满足客户。
2.欢迎对需求提出变更，即使是在项目开发后期要善于利用需求变更，帮助客户获得竞争优势。
3.要不断交付可用的软件周期从几周到几个月不等，且越短越好。
4.项目过程中，业务人员与开发人员必须在一起工作。
5.要善于激励项目人员给她们所需要的环境和支持，并相信他们能够完成任务。
6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标。
8.敏捷过程提倡可持续的开发项目方开发人员和用户应该能够保持恒久稳定的进展速度。
9.对技术的精益求精以及对设计的不断完善将提升敏捷性。
10.要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术。
11.最佳的架构需求和设计出自于自组织的团队。
12.团队要定期反省，如何能够做到更有效并相应地调整团队的行为。
SCRUM是今年最火的敏捷方法论。中文翻译是橄榄球。
它适用于大中小项目。核心内容：团队架构和软件研发框架。
SCRUM的团队角色:产品负责人，SCRUM Master，“自组织”的开发团队。
产品负责人的主要职责是提供愿景，提供边界提供用户故事的优先级。
要特别注意:    需要和开发团队沟通需求，需要考虑开发团队的研发能力。
SCRUM Master :   没有行政权训练团队用正确的方法做事遵循SCRUM的流程和做事原则。不代替团队做决定。
要特别注意：要忍住帮团队做决定的冲动产品负责人和SCRUM Master不建议是同一个人。
“自组织”的开发团队由业务分析师，程序员，测试人员，软件架构师，数据库设计师 用户体验设计师等等组成。能够主动与产品负责人 ，SCRUM Master，个人能自我管理和主动协调工作，能从项目大局出发，自觉完成工作。
SCRUM在需求方面的核心理念：1.不要试图初期就明细化全部需求。2.通过“用户故事”来组织及细化需求。
将“写需求”转变为“讨论需求”。
1.使用“用户故事”来讨论需求。2.所有人都参与需求讨论，持续明确需求细节。
用户故事。
标准格式：作为……角色。希望系统可以……（目标）。以便……（原因）
这个标准格式的用处：
作为……角色。
从用户的角度来思考问题。
希望系统可以……（目标）。
思考系统要实现什么功能，达到什么效果等
以便……（原因）。
思考这个功能对于该用户有什么实质价值。
用户事故的难点：
1.需求由一系列大小不一的用户故事组成。
2.最开始的用户故事往往是“大故事”，需要拆分为“中故事”，“小故事”。
难点：
1.发现和提炼用户故事。
2.由粗到细的拆分用户故事。
3.安排用户故事优先级分派到不同的Sprint中去实现。

用户故事的组成

1.用户角色（User Role）：定义了这个用户故事的受益者是谁。它帮助团队理解故事是为谁编写的，以及他们的需求和期望是什么。

2.完成某个动作（Action）：描述了用户想要执行的具体操作或任务。这是用户故事的核心部分，它指明了用户想要系统如何响应他们的需求。

3.达到某个目的（Benefit）：解释了为什么用户想要执行这个操作，即他们期望从该操作中获得什么好处或结果。这有助于团队理解故事的真正价值所在。

用户故事的优势：

1. 以用户为中心：强调从用户的角度出发，确保产品功能满足用户的真实需求。2.促进沟通：简短的描述使得跨职能团队（如产品、开发、测试等）之间的沟通更加容易和高效。
2. 灵活性和敏捷性：用户故事可以根据实际情况进行调整和优先级排序，适应快速变化的需求。
3. 促进迭代开发：将大型项目分解为一系列小的、可管理的用户故事，有助于实现快速迭代和持续交付。

编写用户故事的技巧：

1. 保持简洁：尽量用简短的语言描述用户故事，避免冗长和复杂的描述。
2. 具体明确：确保用户故事中的用户角色、动作和目的都是具体且明确的。
3. 可测试性：编写时考虑如何测试这个用户故事，以确保其满足用户需求。
4. 独立性：尽量让每个用户故事都是独立的，以减少它们之间的依赖关系。
5. 优先级排序：根据业务需求、用户价值等因素对用户故事进行优先级排序，以确保先完成最重要的功能。

用户故事如何表达需求的一些关键点：

1.明确用户角色
首先用户故事需要明确指出哪个用户角色，或用户类型是故事的受益者，这有助于团队将注意力集中在特定的用户群体上并理解他们的需求和期望

2.简短描述用户需求

用户故事的主体部分应简短地描述用户需求。这通常包括用户想要执行的动作或完成的任务，以及他们期望从该动作中获得的结果或好处。这部分内容应该足够具体，以便开发团队能够理解并实现它，但又不会过于详细，以至于限制了解决方案的灵活性。

3.强调价值

用户故事应该强调这个功能或特性对用户来说的价值。这有助于团队在资源有限的情况下优先处理最重要的需求。价值可以通过描述用户如何通过使用新功能来改进其工作流程、提高效率或获得更好的体验来体现。

4.使用INVEST原则

INVEST原则是一种指导用户故事编写的有用框架，它代表独立性（Independent）、可协商性（Negotiable）、有价值（Valuable）、可估计（Estimable）、小（Small）和可测试（Testable）。通过遵循这些原则，可以编写出更清晰、更易于管理的用户故事。

5.鼓励讨论和细化

用户故事通常是一个起点，而不是最终的需求规格说明书。它们鼓励团队成员之间的讨论和细化，以确保每个人都对需求有共同的理解。在讨论过程中，可能会发现需要进一步澄清或调整用户故事的必要性。

6.使用验收标准来补充

为了更具体地定义用户故事的完成标准，可以添加一组验收标准。这些标准描述了如何验证用户故事是否满足用户需求，并作为测试和开发工作的参考点。