▌主要内容：
- 瀑布流开发模式弊端
- 敏捷需求管理
- 如何获取需求
- 如何管理需求
- 史诗
- 用户故事
- 如何编写用户故事
- 如何规划需求——故事地图
- 总结
瀑布流开发模式弊端
在介绍敏捷之前先介绍一下瀑布流模式，这是产品开发中非常常见的一种管理模式，它以文档为驱动，在整个开发过程中，开发人员根据需求文档进行开发。所以在项目初期，确定需求和文档至关重要，通常在项目初期整个项目和产品便已经有了较为明确的雏形，项目成员需要严格按照需求文档和项目计划完成各自需要完成的工作。
由于在开发的中后期才会看到软件原型，早期只能通过文档来了解系统的模样，因此在一定的阶段，需求文档看起来会比产品实际的代码要重要。
这样的需求管理方式在传统软件系统管理中的优势在于可以在项目初期确定开发内容，更便于确定产品范围、人天预估、难度确认等，可以大大地减少项目失败的风险，同时项目成员也能通过详尽的文档来确认自己的职责和范围。但是这种管理方式在日新月异的产品开发中显得越来越笨重，在实践的过程中产生了以下难以解决的冲突和问题，比如：
需求变更：需求变更是软件研发中经常遇到的一种情况，而在瀑布流的方式中，软件开发的后一阶段都是在前一阶段交付后才开始实施，流程多、周期长，这样的特点导致瀑布流在应对需求变更时需要付出很大的代价。
质量管理：瀑布模式的测试阶段往往在大块功能开发完成后才会开始，在产品开发的时间线上都会比较晚，若测出来比较大的缺陷，可能导致产品无法准时上线。
成员积极性：由于需求驱动性开发，开发人员容易形成“事不关己”的态度，机械性的等待设计人员或者前阶段的产出与设计，不会站在客户或者实际使用者的角度去进行功能开发，导致开发出的功能常常“很难用”，一旦形成返工修改的恶性循环，甚至导致项目延期，会进一步打击项目成员的积极性。
过度开发：由于需求划定早，但是实际产出较晚，大概率出现实际上线的功能不符合预期或者花了大量时间在使用度并不高的功能上。导致过度开发的时间成本浪费。
适应性：市场需求、客户需求等对于产品的实际预期大概率会产生变化，现在产品需求的灵活度、创新性和变化度变得越来越频繁，瀑布式的开发模式由于开发流程时间长的特点很难适应这种场景下的需求管理。
针对以上传统瀑布流开发模式的弊端，敏捷管理的思维应运而生。在下面的文章中，将会以需求的产生、管理和规划三个部分去详细描述敏捷团队如何来处理软件开发中的需求。
敏捷需求管理
如何获取需求
需求实际上分为业务需求和软件需求，业务需求由不一定熟悉IT的业务人员完成，来源很广，会脱离实际的实现方式，着重于功能的描述。而软件需求由开发人员根据业务需求编写，通过基于技术实现的角度对业务需求进行筛选、梳理、归纳，通过算法、架构、数据库等设计过程完成向软件需求的转化。
在此主要讨论业务需求如何获取，如果一个敏捷团队能够有现场客户，这当然是最理想的情况。但在大多数情况下，我们很难在实际操作中将敏捷团队与客户进行无缝结合，这时候，在敏捷团队中充当客户这个角色的人往往是敏捷团队的PO，PO最重要的职责就是与客户、实际使用者等“终端实际用户”进行交流，能够找到并制定软件系统的功能范围，充分了解和分析需求，找到并确定软件系统真正有用的需求，并将其转化为系统的业务需求，即后续的用户故事。
一个优秀的PO可以做到如下工作内容：
- 在产品积压列表（Backlog）中创建容易理解的、可行的故事。
- 根据优先级调整 Backlog 中故事的完成顺序，以最优的计划实现设定的目标。
- 优化并最大化scrum团队的输出。
- 通过尽可能梳理清楚团队内外所有相关的事项，以避免混乱。
- 帮助团队对后续的迭代进行规划。
- 为产品验收定义标准和关键指标
PO在规划产品需求的过程中，要对产品的商业价值有足够的理解，只有这样，才能把产品分解成小的独立交付价值体，同时也能够对产品待办列表进行优化和价值排序，以便团队能够始终将工作投入在价值最高的产品功能上。
如何管理需求
在敏捷管理中，产品需求同样也是非常重要的环节和组成部分，团队的所有活动都会基于需求展开，由产品负责人维护和排列各自的优先级。在敏捷管理体系中，我们将需求映射为用户故事，同时使用史诗对需求进行更粗粒度的划分和规划。
史诗
在项目开始，我们在定义一个产品的粗略范围的时候如果直接以用户故事作为唯一的细粒度标准进行划分的话，会非常混乱，因为一个系统往往非常复杂，直接对一整个系统进行分析拆分其实是很困难的。所以针对这种情况，猪齿鱼敏捷管理引入了史诗的概念。
史诗是有一个共同目标的大量工作，类似但是区别于系统的“模块”概念，通过定义史诗来划分产品的功能线，再基于史诗来详细讨论相关的用户故事，史诗通常需要多个冲刺才能完成。同时，史诗会随着时间的推移变化，并不是在产品规划的初期就能确定史诗的规模大小，他会通过一系列冲刺对范围进行修改以适应需求的变化，随着团队通过开发和客户反馈，团队成员会不断添加和删除史诗相关的用户故事，以优化团队的发布时间。
用户故事
用户故事（User Story)是指用户通过系统完成的一个有价值的目标，用户故事只是描述系统的外在行为，完全忽略系统的内部动作。好的用户故事应该包括角色、功能和商业价值三个要素。一个完整的用户故事可以涵盖以下问题：
- 实际使用的角色是谁？——期望用户的类型
- 具体要使用的功能是什么？——我希望功能
- 完成这个功能的原因是什么？——产生的价值 和好处
因此，一个用户故事的经典格式为：作为一个角色 , 我想要功能 , 以便于功能价值。
如何编写用户故事
用户故事的定义必须是从真正业务用户的角度，不可以是“技术用户（开发者本身）故事”，在编写用户故事之前，应该清楚地了解创建用户故事的用户是谁，所以，做一个适当的用户调查，区分所有的用户角色并根据用户角色对故事进行区分是非常必要的。通常，客户代表（如产品所有者）负责用户故事。尽管如此，用户故事并不是高层给团队的规范，而是产品所有者和团队之间的协作技术，这就是为什么如果用户故事是合作编写的更好。一个好的方法是成立一个故事编写研讨会，由团队合作编写。
为了构造好的用户故事，我们关注以下两个原则：NVEST 原则和 3C原则
INVEST 原则
Independent 相互独立的：用户故事之间应该是相互独立的，相互关联依赖的故事会导致故事的优先级和计划编排变得很困难，复杂的依赖更会导致故事的难以预估和控制。通常我们会通过组合用户故事、分隔用户故事的手段去减少用户故事之间的依赖性。用户故事的独立性越高，越能根据实际情况去确立故事的优先级以及预估故事完成的可能性。
Negotiable 便于协商的：用户故事包含了一个需求的简短描述，而详情是通过相关人员（客户、需求人员、开发人员等）之间通过讨论阶段来完成，如果用户故事非常详细会导致故事的可讨论、可协商性大大下降，不便于更好地沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。
Valuable 有价值的：用户故事一定是站在客户和使用者的角度去思考和编写的，描述的是产品的一个一个功能，而不是实际实现的任务。
Estimable 能估算的：功能的实现者需要去评估一个用户故事，来确定他的规划。估算一个用户故事需要一定的领域知识，同时太大的故事也会导致估算的不准确。
Small 适量小的：故事在评估时在工作量上要小一些，以不超过一个迭代周期为宜（我们实践中1-3天是一个比较合适的量），短小的用户故事可以减少划分过程中估算的误差，否则很容易在划分范围和估计时出现很多错误。
Testable 可验证的： 这点用于确定用户故事是否完成，如果一个故事无法进行测试，那我们就无法确定这个用户故事是否完成了，在划分故事时，最好确定一个故事的验收标准，这一点很重要。
3C原则
Card 卡片：作为用户故事的书面描述，不会包含详细故事细节，更多的是一个提醒，一个必须跟进后续沟通的承诺。
Conversation 交谈：与产品负责人和客户的交谈中获取故事背后的细节，可以通过一些文档进行补充。
Confirmation 确认：使用验收测试来确认故事是否完成，是否符合工作要求。
在这里需要注意把握需求文档与敏捷故事的平衡点。需求文档属于产品级的文档，不论一个软件系统经过多少次的重构开发，它的核心功能是不会有太大的变化的，这类描述产品的需求文档是项目中不可缺少的一部分。而用户故事则是项目级的功能描述，类似于做完就会扔掉的“抛弃型”需求。很多企业和团队在实践敏捷流程时，对于是否需要编写需求文档经常产生疑问，在实际的操作中，可能部分强调快速交付，或者生命周期很短、业务模式高度可变的互联网、网游等项目，是可以减少甚至放弃需求文档而全部使用故事来管理需求，但是现阶段要求企业的IT项目全面接纳需求完全无文档化其实并不是很现实。
在这里我们认为更合适的方式是找到需求文档与敏捷故事之间的一个平衡点，理性的辨别两者的区别，一份需求用例加上用户故事，然后驱动开发这种方式可能更适合大型企业的敏捷需求实践模式。
如何规划需求——故事地图
在上文，我们已经确定了软件系统的开发范围，找出了需要实现的业务需求，同时根据用户故事的编写原则生成大量对应的用户故事，并且在迭代规划中按照优先级挑选出迭代需要完成的用户故事，将这些故事放入了下图的待办事项（Backlog）中。
但是我们如何对这些需求进行规划管理？如何将待办事项（Backlog）的故事列表在时间轴上进行编排呢？
为了更好地对用户故事进行规划，敏捷中使用 故事地图（User map）作为故事管理方式。故事地图会将产品的backlog从简单的列表模式变为一张二维地图，从而能容易地看到整个产品规划的全貌，不仅能帮助业务人员整理产品需求，协助开发人员更快速便捷地了解客户的需求，同时还能够确定产品模块的实现优先级，实现最大用户价值。
在猪齿鱼敏捷管理系统中，我们将史诗、用户故事、发布版本、冲刺迭代紧密结合，以史诗为主轴，用户故事为核心元素，实现了发布版本和迭代冲刺两个维度的产品需求规划，更加直观、快捷地将用户故事也其他的相关任务进行编排规划。
通过选择故事地图的泳道类型，我们将故事地图区分为冲刺维度和版本维度两种编排方式。
冲刺维度
- 以史诗作为地图的横轴坐标，将地图中的用户故事根据史诗进行分类。
- 冲刺迭代作为地图的纵轴子tab页，可以将地图中的用户故事放入对应的迭代。
- 未规划区的故事是指已经分配了史诗，但是没有编入任意一个冲刺迭代的用户故事。
- 需求池是指未完成的，并且未分配史诗、也未编入任意一个冲刺迭代的用户故事。
版本维度
- 同样也是以史诗作为地图的横轴坐标，将地图中的用户故事根据史诗进行分类。
- 软件的发布版本作为地图的纵轴子tab页，可以将地图中的用户故事放入对应的版本。
- 未规划区的故事是指已经分配了史诗，但是没有编入任意一个发布版本的用户故事。
- 需求池是指未完成的，并且未分配史诗、也未编入任意一个发布版本的用户故事。
通过在故事地图中对用户故事进行操作，可以对用户故事的史诗、迭代、版本进行直观的编排，完成用户故事的规划过程。
总结
在软件系统的开发中，不论是瀑布流模式还是敏捷模式，需求管理都是开发过程中最重要的环节之一，细致深入的项目需求和有效的需求工程管理可以让项目成员所做的工作尽可能地明晰，每一分资源的投入都尽量保证有效地产出。开发者们花费了大量的精力开发的功能由于需求调研的失误发现最后并没有用户去用，或者在大量的开发之后业务人员一句没用便推倒了所有的设计，这些情况是项目管理中是十分常见和极为头疼的情况，不仅打击团队成员的积极性，激化产品和开发的矛盾，还会浪费大量的资源，导致返工频繁、质量低下等结果。
需求管理在敏捷中并不是在项目开始就全部盖棺定论的，在项目期初进行的是大致需求和核心功能的讨论确定，但是后续实现的细节会在每次迭代完成后尽早的反馈给客户，由实际的使用用户来讨论鉴定他们真正的需求，然后根据反馈的情况和效果进行针对性地修改，尽可能做到不合理的需求尽早发现修改，减少返工的成本，同时保证最终项目产出的结果是最为贴合用户需求的产品。
当然这种管理模式也会有一些弊端，比如在实际的项目管控中需要在项目开启时便完成人天的预估，大量的需求变更会导致项目时间的不可控。其实这个问题反过来看，如果真的有如此之多的需求变更，那按照原先确定的需求执着地进行开发可能导致的后果会更加严重。所以在实际项目的中，如何让需求管理也变得敏捷不是单纯地用敏捷理论来生搬硬套，我们要切实的明白敏捷的核心理念，然后贴合实际项目的情况来做出对应的变化。让敏捷管理真的能让我们的项目敏捷起来，让客户、产品、开发者在敏捷中产生享受的快感。
关于猪齿鱼
Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：