软件产品的开发过程，是将现实世界的商业目标和解决方案，通过一系列系统化的方法拆分为需求描述，进而用代码实现的过程。为了更好、更低成本、更有效率地达成商业目标，逐步探索并实现更优的解决方案，我们不仅需要明确做什么，还需要一步一个脚印完成需求的拆解、实现、验收与优化改进。
++01++
++需求拆分与验收测试实践综述++
如《DevOps需求篇：业务探索的4种实践方法》一文中介绍，商业画布、设计思维有助于帮助企业确定业务目标。从业务目标到产品方案，则可以使用量化式影响地图等实践，使用卡诺模型来帮助确定需求的优先级。从产品方案到用户故事，需要确定MVP，需要采用“用户故事地图”的实践。最后一步则是用户故事到代码实现任务的拆解，直接影响需求完成度、开发交付效率和产品质量，我们推荐使用验收测试相关实践。如下图所示：
在《DevOps需求篇：业务探索的4种实践方法》一文中，我们已经介绍过商业画布、设计思维、量化式影响地图相关方法，卡诺模型可以帮助我们确定目标需求的优先级。在《DevOps需求篇：精益思想引领下的业务敏捷（下篇）——精益创业与精益数据分析》系列文章中，我们相信介绍了MVP（最小可行产品）如何开展。本次我们重点介绍下用户故事的相关内容。
++02++
++用户故事地图++
用户故事地图的概念来自Jeff Patton的著作《用户故事地图》^[1]^。用户故事地图是产品设计可视化的最佳方法，不仅是一种团队沟通工具，也是一种需求分析管理工具。
用户故事地图的横轴代表了用户与产品交互的活动主路径，从左至右展示用户旅程的不同步骤。在这个维度上，我们可以按照用户从初次接触产品到完成主要操作的全过程，依次排列各个用户故事，形成一种叙事性的流程。比如，对于一个电商应用而言，横轴可能包括“注册登录”、“浏览商品”、“搜索筛选”、“购物车添加”、“结算支付”及“售后服务”等一系列关键场景。
纵轴则代表了抽象层次或者需求粒度，自上而下通常由宏观到微观逐层细化。顶层是用户的主要目标或 Epic（史诗故事），它们可以被拆分成多个更具体的用户故事，这些故事再进一步分解为任务级别的细节。这种结构使得团队能够全面把握产品的整体架构和功能模块，并有效地进行优先级排序和迭代规划。
通过用户故事地图，团队成员可以从全局视角理解产品价值流，明确各阶段的核心需求，并基于此制定出切实可行的开发计划和验收标准。同时，它也促进了跨职能团队间的协作沟通，确保所有参与者对产品愿景和用户需求有共同的理解和共识，从而更加高效地实现业务目标并提升用户体验。
一个在线购书网站的示例^[2]^如下：
++03++
++用户故事的八大特性++
用户故事是软件功能的简单描述，可使用以下形式描述一个用户故事：
作为 …一个xxx用户…
为了完成 …xxx业务…
我希望能够 …使用xxx功能…
INVEST是用户故事拆分是否得当的原则。
I：独立（Independent）。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
N：可协商（Negotiable）。用户故事应该是可协商的，这意味着它们不应该是具体的解决方案描述，而应是需求或期望的概述。开发团队与利益相关者之间应当就用户故事的具体实现细节进行开放、持续的沟通和讨论，确保最终实现的产品功能能够满足用户的实际需求。
V：有价值（Valuable）。用户故事必须对终端用户或者业务具有明确的价值，即每一个故事都应该有助于解决用户问题或提升用户体验，直接或间接地推动商业目标的达成。
E：可估算（Estimable）。为了有效地规划和管理项目进度，每个用户故事都应当足够具体，具备可估算性。团队成员需要能基于当前的信息和技术能力，合理预估出实现该用户故事所需的工作量和时间成本。
S：小（Small）。理想的用户故事应当足够小，以便在一个迭代或冲刺中完成。较小的故事更便于管理和测试，并且可以更快地获取反馈，从而降低风险并提高开发效率。
T：可测试（Testable）。一个合格的用户故事应包含清晰、可度量的验收标准，使得开发完成后可以通过具体的测试用例来验证其是否已正确实现。
如何进行故事估算？需要对每个故事进行工作量估计，比如3个故事点，或者5个故事点等。团队可以通过计划扑克（Planning Poker）这样的敏捷估算技术来实现对用户故事的工作量评估。在计划扑克中，每个团队成员会根据自己对用户故事的理解和实现难度，选择一张代表相应工作量的数字卡片，这些数字通常采用斐波那契数列或其他预定义的点数系统。通过讨论并达成共识，团队最终确定每个用户故事的估算值，从而为迭代规划和优先级排序提供依据。
故事点不需要精准，但是要相对准，比如登录比退出复杂，那登录的故事点如果是3，那退出的至少不能大于3吧。也可以团队约定一个故事点代表半天的工作量。基于此，就可以评估速率了。
还有一点需要指出，经理和主管或许倾向于将故事分配给程序员。应该避免这种情况，而让程序员们自己协商，这样做的效果要好很多。这有助于核心程序员选择自己更感兴趣的工作，指导有抱负的新员工，避免新员工承担超过他能力的工作，也有助于团队合作。
++04++
++验收测试如何做++
用户故事需要明确的验收标准，例子必须精确到位，不能模棱两可，要精确可测。可以遵循Given-When-Then的范式来描述例子，比如，当用户进入网站时，应展示登录页，登录成功后，应展示欢迎登录。
有两个重要的问题需要探讨：谁来编写验收测试？谁来运行验收测试。
业务人员或产品同学代表的是业务方，应该负责说明需求的规格。因此，一般场景的验收测试应该业务方确认。谁来编写验收测试？QA人员。QA应负责非功能的用例。
谁来运行验收测试？程序员。理想的情况是，QA编写用例，程序员来运行这些用例，这对提升效率、减少沟通产生的浪费很有必要。测试左移也在支持这一观点。
++结语++
为什么要进行需求拆分？为了快速验证业务假设，为了快速上线占据市场先机，为了小步快跑，为了业务敏捷。
需求拆分有助于小批量交付，加速价值流动，低成本拥抱变化，通过可视化的方法有助于团队的不同角色建立共识，协调工作。用户故事的频繁交付，也有助于帮助团队建立信心，提升士气。
需求拆分当然也是有成本的，包括需求拆分产生的沟通成本，前期的讨论需要更多人参与也必然导致更高的成本。分批开发、测试和部署的迭代成本也是不容忽视了，这就需求我们建设简单、易用的持续集成/持续交付（CI/CD）基础设施了，幸运的是，相应的工程手段也已经相对成熟了。
参考：
[1] https://book.douban.com/subject/26760348/
[2] https://www.woshipm.com/zhichang/3227451.html