敏捷转型是根据具体问题的演进过程

最新推荐文章于 2025-10-13 14:49:42 发布

原创最新推荐文章于 2025-10-13 14:49:42 发布 · 260 阅读

0 ·

CC 4.0 BY-SA版权

本文分享了一个以供应商交付为主的项目中，如何通过逐步引入敏捷方法论，如JIRA需求管理、限制在制品、每周交付计划会议等，有效提升跨团队协作与交付效率的实际案例。

“敏捷转型是根据具体问题的演进过程，也是和各干系人真诚合作的结果。敏捷教练需要在战壕里。”

以下是我最近一个项目的敏捷交付模式，它是一个以供应商交付为主、从0到1搭建整套业务系统的过程。

640?wx_fmt=png

但这个模式并不是一开始预先设计出来的，而是我们和业务、供应商相互配合演进出来的。所以这个模型图是一个事后总结。

在这个过程中，我们并没有像以前那样在一开始尝试通过敏捷培训给业务、供应商“洗脑”，然后根据套路设计全套的模型，要求业务与供应商配合。相反，我们在一开始对“敏捷”只字不提，而是针对一个个当时面临的具体交付问题，看看有没有合适的敏捷、精益的工具和实践，接着和业务、供应商耐心讲解我们想具体怎么做，对大家有什么好处，需要大家怎么配合，然后一起尝试着去做，遇到新问题及时调整。下面我举一些例子：

通过JIRA统一管理和跟踪需求

问题：为了满足我们的业务特性和IT的全球架构、安全标准，不管是业务还是IT，对供应商产品都有大量的定制化需求，这些需求需要统一登记，需要讨论优先级，从需求、开发、测试到部署的全流程也需要跟踪。

解决方案：我们推荐了JIRA作为管理工具，排序后，从JIRA导出需求给供应商进行开发，在JIRA上建立实时的进度板。

好处：需求统一管理，避免混乱；进度可视化，让所有人都能看到；实现了需求版本化管理。
限制在制品

问题：项目一开始我们就收集到了60多个需求，然后一次性地推给了供应商，不断给他们施压。但很快我们发现这样不可行，跟踪起来也很费劲。

解决方案：我们思考是否可以用敏捷、精益里的限制在制品的思想，根据供应商在这个项目投入的资源限制每个周期派给他们的需求数量。

好处：供应商可以聚焦在有限的需求，从而提高交付速度，大大减少“跳票”的情况，也使我们的跟踪轻松了很多；把所谓的“高优先级”变成有限资源，迫使我们认真思考哪些需求是当前最迫切的。
每周交付计划会议

问题：需求分别来自不同部门，优先级需要统一。

解决方案：在限制在制品的原则下，我们每周和业务回顾本周交付的情况和下周的交付计划，然后把这个计划交给供应商。

好处：确保大家保持一致的优先级，实现价值驱动交付。
每日例会

问题：业务需要透明度。同时，由于没有一个业务代表可以承担PO的角色，代表所有业务人员做决策。而我们有很多事情需要业务一起集体决策。

解决方案：我们建议每周一、三固定时间和业务举行简短的例会。一来，把JIRA看板中的需求进度过一遍，也可以借此催促业务人员尽快完成测试。二来，有什么需要决策的，也通过这个会议快速讨论形成决策。我们也会和供应商每周二、四进行例会，跟踪交付计划中每一个需求的进度和状态。

好处：进度透明化，所有人都有了全局视角，共同加速需求完成；快速集体决策；确保供应商进度。
缩短反馈环

问题：我们发现有一些需求业务觉得很简单，但供应商做了好几月都没做对。而一个需求，需要经历登记、排序、需求澄清，在供应商那边要需求确认、设计、开发、测试、发包，然后由我们在公司服务器上部署后才能验证是否做对，整个链条非常长，做错的成本非常高。而供应商的交付模式还是比较“传统”，需求、设计、开发、测试、发包都分属于不同的部门，存在大量的交接。

解决方案：通过走访供应商，了解了他们的交付特点，我们提出了在每个环节增加反馈确认（如下图）。

好处：缩短反馈环，确保正确交付。