敏捷研发工作中，如何拆分用户故事，如何让迭代中的用户故事更适合在迭代中开发交付？以及好的用户故事需要有哪些特征？
这些是在敏捷实践中，常遇到的问题。接下来，这篇文章我们就来一起探讨一下敏捷项目中用户故事的作用、编写、拆分以及符合的原则。
Scrum和瀑布式产品开发对待需求的方式不同。
瀑布式产品开发中，需求不可协商，需要在项目开始前细化，并且是相对独立的。而在Scrum中，需求细节是在开发期间持续不断的对话中商讨出来的，并且是在团队开始构建功能的时候，及时地细化这些需求为团队提供支持。
敏捷项目认为，自由掌握需求是达成业务目标的关键，不会在前期就投入大量的实践和成本详细描述需求，与瀑布式开发中事先拟定的需求文档不同，我们为需求创建“占位符”，即“PBI”。
最开始PBI，代表模块化的业务价值，相关细节很少，需要干系人、产品负责人以及不能缺少的开发团队进一步细化，将他们拆分成更小、更详细的PBI，直到一个PBI足够小、足够详细，是可以放入一个迭代中的用户故事。
什么是用户故事？
用户故事是可用于陈述业务价值的一种简便格式，旨在帮助业务人员和技术人员双方都能理解需求。
用户故事的结构很简单，可以编写颗粒度各不相同且，易于逐步细化的用户故事。
用户故事的拆分
以渐进、逐步完善的方式进行用户故事拆分，拆分后更小粒度的需求有利于团队更准确地对工作量进行估算，更早交付出解决方案中最核心最高价值的部分，尽早获得反馈并作出调整；
并且让团队每个迭代都能够完整地交付一批有价值有质量的增量，建立其有固定节奏的迭代交付。
用户故事是一种优秀的工具，可以承载着客户或用户价值的条目贯穿于Scrum的价值创造流程。然而，如果故事的大小都一样，就很难做好概要计划并体会到逐步细化的好处。
幸运的是，可以可编写不同抽象层级的用户故事，用来捕获客户及用户需求。
用户故事的拆分方法
流程步骤：按业务流程、工作流的不同步骤进行拆分
用户角色：按使用同一功能的不同用户角色进行拆分
记录操作：对记录管理类功能，按查询、添加、更新、删除、查看拆分
业务场景：按主场景和分支场景，或多种不同场景分别进行拆分
业务规则：当一个哦那个能支持多种业务规则时，按不同规则进行拆分
界面划分：当复杂界面包括多部分内容时，按界面区域进行划分
延迟性能：将需求中满足性能等非功能性要求的条件拆分为单独故事处理
评估拆分结果
用户故事拆分完毕后，我们怎么知道用户故事写得好不好呢？需要用INVEST原则进行评估故事，是已经可以发挥既定作用还是需要再加工。
好的用户故事要符合INVEST
独立的（Independent） 用户故事应该是独立的，相互间松散耦合的，这样才实用。相互依赖程度高的故事会使估算、优先级排序、规划等复杂化。
独立的目的不是消除所有的依赖，而是尽量避免依赖关系。
可协商（Negotiable）
用户故事是可协商变化的，其细节需要通过开发团队和PO协商来确定。故事是占位符，它是用来提醒开发团队与客户进行交流的。
有价值（Valuable）
对客户或用户来说，故事是有价值的，如没有价值，就不应该放到产品BackIog。
有价值标准的关键在于，列表中所有故事都必须由产品负责人以客户与用户代言人的身份认可它们的价值。不是所有的故事都是独立的，也不是所有的故事都是完全可协商的，但它们必须都是有价值的。
可估算（Estimatable）
故事应该是开发团队可以估算的。PO知道故事大小之后，才能最终确定它在产品Backlog中的优先级。如果故事较大，应细化拆解。
小（Small（大小合适））
即将开发的故事应该是大小合适的。如果4周一个迭代，故事的平均大小（包括开发+故事测试完成）应该在5天左右。
可测试（Testable）
故事的相关测试要么通过、要么失败。“可测试”意味着故事要有明确、无歧义的验收条件，并且测试人员能够有手段对其是否达成验收条件进行验证。
不过，并不是所有的用户故事都必须满足INVEST原则，比如技术性故事，实际都不应该纳入产品列表，相反，这类故事应该属于完成业务价值故事所设计的任务。
阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注掘金账号@鲸舟研发管理
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解
