“敏捷转型是根据具体问题的演进过程，也是和各干系人真诚合作的结果。敏捷教练需要在战壕里。”
以下是我最近一个项目的敏捷交付模式，它是一个以供应商交付为主、从0到1搭建整套业务系统的过程。
但这个模式并不是一开始预先设计出来的，而是我们和业务、供应商相互配合演进出来的。所以这个模型图是一个事后总结。
在这个过程中，我们并没有像以前那样在一开始尝试通过敏捷培训给业务、供应商“洗脑”，然后根据套路设计全套的模型，要求业务与供应商配合。相反，我们在一开始对“敏捷”只字不提，而是针对一个个当时面临的具体交付问题，看看有没有合适的敏捷、精益的工具和实践，接着和业务、供应商耐心讲解我们想具体怎么做，对大家有什么好处，需要大家怎么配合，然后一起尝试着去做，遇到新问题及时调整。下面我举一些例子：
- 通过JIRA统一管理和跟踪需求问题：为了满足我们的业务特性和IT的全球架构、安全标准，不管是业务还是IT，对供应商产品都有大量的定制化需求，这些需求需要统一登记，需要讨论优先级，从需求、开发、测试到部署的全流程也需要跟踪。
解决方案：我们推荐了JIRA作为管理工具，排序后，从JIRA导出需求给供应商进行开发，在JIRA上建立实时的进度板。
好处：需求统一管理，避免混乱；进度可视化，让所有人都能看到；实现了需求版本化管理。
- 限制在制品问题：项目一开始我们就收集到了60多个需求，然后一次性地推给了供应商，不断给他们施压。但很快我们发现这样不可行，跟踪起来也很费劲。
解决方案：我们思考是否可以用敏捷、精益里的限制在制品的思想，根据供应商在这个项目投入的资源限制每个周期派给他们的需求数量。
好处：供应商可以聚焦在有限的需求，从而提高交付速度，大大减少“跳票”的情况，也使我们的跟踪轻松了很多；把所谓的“高优先级”变成有限资源，迫使我们认真思考哪些需求是当前最迫切的。
- 每周交付计划会议问题：需求分别来自不同部门，优先级需要统一。
解决方案：在限制在制品的原则下，我们每周和业务回顾本周交付的情况和下周的交付计划，然后把这个计划交给供应商。
好处：确保大家保持一致的优先级，实现价值驱动交付。
- 每日例会问题：业务需要透明度。同时，由于没有一个业务代表可以承担PO的角色，代表所有业务人员做决策。而我们有很多事情需要业务一起集体决策。
解决方案：我们建议每周一、三固定时间和业务举行简短的例会。一来，把JIRA看板中的需求进度过一遍，也可以借此催促业务人员尽快完成测试。二来，有什么需要决策的，也通过这个会议快速讨论形成决策。我们也会和供应商每周二、四进行例会，跟踪交付计划中每一个需求的进度和状态。
好处：进度透明化，所有人都有了全局视角，共同加速需求完成；快速集体决策；确保供应商进度。
- 缩短反馈环问题：我们发现有一些需求业务觉得很简单，但供应商做了好几月都没做对。而一个需求，需要经历登记、排序、需求澄清，在供应商那边要需求确认、设计、开发、测试、发包，然后由我们在公司服务器上部署后才能验证是否做对，整个链条非常长，做错的成本非常高。而供应商的交付模式还是比较“传统”，需求、设计、开发、测试、发包都分属于不同的部门，存在大量的交接。
解决方案：通过走访供应商，了解了他们的交付特点，我们提出了在每个环节增加反馈确认（如下图）。
好处：缩短反馈环，确保正确交付。
通过这一个个针对具体问题的具体实践和工具，我们改善了与业务、供应商的协作模式，提升了交付效率。在大家享受到实效的基础上，我才慢慢地把一些敏捷的理念和原则通过闲聊渗透开去。这是一次成功的落地和转型。
在这个过程中，我的体会是敏捷教练需要在战壕里。在这个项目中，我是IT交付负责人，需要对结果负责。但同时，作为一个敏捷专家，我当然不会放过任何一个提高交付效率，改善协作方式的机会。但这是一个根据具体问题的演进过程，也是和各干系人真诚合作的结果。
关于这个项目的更多细节，可以参阅我的另一篇文章《与供应商的敏捷初体验》。
关于作者
- 就职于世界500强银行，负责基金服务业务软件开发与交付
- 敏捷、精益、DevOps专家
- 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈
- 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会等论坛发表主题演讲
- 著有《猎豹行动：硝烟中的敏捷转型之旅》一书
