需求管理是敏捷实践价值输出的源头，需求是所有研发工作的起点，如果需求质量不高，后续环节的质量无从谈起。如何从被动接收大量无效需求，到主动获取需求并最终实现整体获益？本节案例中给出了有效实践思路。

本实践节选自《2021中国企业敏捷实践白皮书》（点击可下载），分享者为周光彬，是来自某一线消费家电品牌的敏捷教练。

问题

IT 部门所接收到的大多数并非原始需求，而是由其他部门转交而来，原始需求价值缺失。由于被动接收大量无效需求，即使 IT 部门已经进入迭代阶段，业务部门仍频繁变更需求。

问题成因

1.已有的需求传递结构为“业务部门-产品经理-研发团队”，以至于传递到 IT 部门的需求是经过二次理解的，跟原始的客户需求存在偏差:

2.业务部门需求频繁变更，导致研发团队工作难度增加，项目交付周期延长。

敏捷实践

1. 规范业务侧需求提出方式，保障需求池内容简洁性，必要时 IT 部门会到现场获取需求全貌;

2. 迭代计划会启动前三天，以需求池为出发点，根据需求内容召集相关人员，含业务、产品、开发、设计、测试等强调实际用户的参与。通过 BDD (行为驱动开发)的方式加强沟通与共创，明确需求边界，解决需求传递中出现的低效以及偏差问题；

3. 需求敲定的同时也会评估用户故事的大小，将大于 3 天的用户故事进行拆分，以便能够在即将到来的送代中按时完成。在后续的迭代会议中，由于需求已经被充分讨论并达成各方共识，有效避免了迭代中需求的变化；

4. 聚焦近两周的重要需求，使需求能够专注于解决痛点，提升需求的价值。

实践结果

1.采用上述实践后，在两周迭代中解决了用户的主要痛点，并为研发团队保留充足的时间进行优化，保证了需求的价值和有效性;

2.BDD 会议沟通起到了至关重要的作用，不仅能确保需求的顺利提出，也让各角色成员基于内容详情和工作安排达成共识，保障需求的稳定性。

总结：

业务驱动开发的敏捷实践非常适合诠释敏捷原则第一条和第四条：“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”、“业务人员和开发人员必须相互合作，项目中的每一天都不例外。”

功能性和非功能性需求管理同等重要

卢建成

靖本行策 首席顾问

需求有效性对于产品的成功与否有着相当大的助益，而有效性可以从效度和效率两方面来思考。需求的效度有赖于是否和利害关系者充分地沟通并且透过详实且易理解的方式描述需求，“业务驱动开发”这一实践便是透过围绕着 BDD 的实践来确保需求的效度。需求实现的效率则有赖于资源聚焦与流动管理才能够达成，“需求层次与流动”（下一期实践案例）这一实践便是基于需求来源和颗粒度进行明确的分层来帮助团队聚焦有立即价值的需求，并且有效推动需求实现的进展。

通常企业都是以生产为导向，因此聚焦于功能性的需求往往是高阶管理者、产品人员与技术人员的首选，然而过分地专注功能性需求，却容易导致技术债务与团队成长力道不足。

因此在每次迭代的时间安排上，提供一定比例的闲置时间，并且关注与提高非功能性需求的重要性是相当关键的一步。这样的安排不仅能够促使团队产生自发性行动，也能为产品的持续运营提供稳定性。

按过往经验，迭代过程的会议安排、人员职能养异、工时评估的不确定性，意外事件等都会让每次迭代产生或多或少的零碎闲置时间，而这样的闲置时间可以占整体送代时间 10% ~ 20%。此时可以透过分析团队的工作流、每项工作的完成时长、每次迭代的实际工作量等，来找出工作量的浮动区间，或者重新调整会议和工作的安排方式，来找出这些闲置时间，然后将这些浮动的时间还给团队，协助他们善用这些时间去改进工作流程、去除技术债务、增加技术交流等。

对于团队成长、留才、和产品与服务的质量都会有所帮助。去除浪费不是为了加载更多的工作，而是为了松绑被浪费逼得喘不过气来的工作负载，试着去找找团队的 Slack，让团队可以从紧绷中释放，体验一下“松弛”。