敏捷开发最佳实践：需求管理实践案例之需求层次与流动

最新推荐文章于 2024-07-25 16:44:27 发布

我的C币

最新推荐文章于 2024-07-25 16:44:27 发布

阅读量787

点赞数 5

文章标签：敏捷流程

本文链接：https://blog.csdn.net/XPF156915/article/details/139240729

版权

在上一期的最佳实践中，我们分享了需求管理实践——业务驱动开发，为“如何从被动接收大量无效需求，到主动获取需求并最终实现整体获益？”这一问题提供了解决思路。本期实践我们继续分享需求管理领域的最佳实践——“需求层次与流动”的具体做法，值得大型团队借鉴。

本实践节选自《2021中国企业敏捷实践白皮书》（点击可下载），分享者为GalanXu，是来腾讯工程效能平台部的高级项目经理。

问题：

需求拆分不合理，交付时间不可控；规划目标的落地进展不理想，管理层很难获取有效的反馈。

问题成因：

需求分层管理意识不够，没有对需求进行很好的评估及拆分；各个团队定义的工作流千差万别，没有统一的需求管理规范，造成推进困难。

敏捷实践：

1.需求按照来源与颗粒度进行分层;

2.需求来源划分为产品与运营需求、技术优化需求、运营配置变更需求，团队会聚焦于产品与运营需求，并进行详细度量;

3.需求颗粒度划分为Epic、Feature、Mini-Feature和 User Story。而 Task 不作为一种颗粒度的分层，也不会进度量，更多是作为个别工程师的工作安排单位；

4.基于颗粒度的需求分层让需求最终会呈现出一种金字塔型的结构，每一层需求都有各自的工作流和工作状态，通过工作流的状态联动，便可以从最底层的 Task 透视到最顶层 Epic ，进而把控实际整体进展情况;

5.不同颗粒度的需求对应到不同类型的需求负责人，比如 Epic 会对应高阶管理者，Feature与Mini-Feature对应到产品人员，而User Story则对应到技术人员。

实践结果：

通过限制并落实需求拆解层级让目标达成情况越来越可控；管理者能更快了解到需求交付的进展；业务侧对产研团队的交付需求满意度显著提升。

总结：

需求分层与流动的敏捷实践非常适合诠释敏捷原则第一条：“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”

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

卢建成

靖本行策首席顾问

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

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

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

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

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