与供应商的敏捷初体验

如何在实践传统开发模式的供应商团队实践敏捷

0
2675
一般来说,敏捷转型较容易发生在自主开发领域,如果开发和交付主要由第三方供应商来完成,则没有太多成功先例可参考。笔者最近在做的项目就是以供应商的开发为主。通过与供应商伙伴的交流,也发现敏捷思想在供应商那边并非主流。作为甲方,我们非常希望能提升交付效率,这是对双方都有利的事情。通过几个月的实践,我们摸索出了一套新的交付模式。在此过程中,虽然我们没有跟供应商的伙伴提过‘敏捷’二字,但是我们的交付管理完美地实践了敏捷原则,提升了交付效率。我相信,我们的实践经验对于以供应商交付为主的项目有很好的参考价值。01 限制在制品,聚焦有限需求,提升交付效率
在项目开始阶段,我们把各类需求排山倒海般地抛给了供应商,这些需求包括定制化功能、测试的缺陷和系统上线前必须满足的安全、架构的要求。我们很快发现这个模式不可行。一方面,对于供应商来说,由于需求太多,又不断有新的需求插队,导致交付团队需要不停切换,影响了交付效率,有些需求无法按原定日期交付;另一方面,由于在制品太多,每次双方都要关注冗长的需求清单,费时费力,而且在这种情况下,我们很容易失去焦点,使真正高优先级的需求无法及时交付。我们开始思考是否可以通过敏捷的限制在制品(Limit Work-in-progress原则来优化这个过程。一个需求,只有被交付的那一刻,其价值才会被体现出来过多的在制品其实是没有价值的。因此,我们要落实“暂缓开始、聚焦完成(Stop Starting, Start Finishing”的原则。通过限制在制品,我们可以让供应商的交付团队聚焦在有限的需求上,从而加快交付速度,更快地实现需求价值。限制在制品也使高优先级变成“有限资源”,倒逼作为甲方的我们认真思考到底哪些需求在当前的是最重要的,从而确保我们一直在进行价值最高的交付。通过与供应商协商,我们约定了每个周期聚焦的需求数上限为15个(涉及到5个子系统)。也就是说任何时候,最多只允许15个需求在交付计划中,如果有第16个需求需要加入,则要与已经在交付计划中的其中一个需求进行交换。通过这个实践,一方面,双方都可以聚焦在有限的需求上,沟通与交付的效率都大大提升了;另一方面,作为甲方的我们也能确保进入交付计划的需求都是当前最高优先级的,保证业务价值最大化。

02 每日例会,确保进度

在每周的交付计划确定以后,我们与供应商的项目经理每天都会就交付进度和遇到的问题进行交流,确保进度,也让问题得到及时的反馈与解决。

03 实例化需求,实现交付闭环

说清楚需求,从来不是一件容易的事情。通常情况下,需求描述都是比较抽象的,这就会导致同一句话,不同的人可能有不同的理解,更要命的是,表达的人并不知道接收者的理解是否正确。就像下图,有人说他需要一套渔具,有些听众觉得需求是鱼竿、或者是渔网,甚至是渔夫帽。很多软件问题是由需求这个源头产生的

具体到我们的业务场景,假设需求说的是需要一份报表把某基金管理人下所有投资人的持仓金额进行汇总,如果需求仅仅是这样一句话的话,这“汇总”二字就可以引起很多不同的理解。汇总后具体有哪些信息需要展示在报表中、是否需要做合计、哪些数据需要合计等等,都是需要澄清的。

 

为了确保交付的正确性,一方面,作为甲方,我们需要把需求说清楚。有3个环节确保需求的完整性:业务价值反复确认验收条件。另一方面,供应商需要相应地理解需求的业务价值持续反馈把验收条件放入交付前的测试用例中

业务价值就是为什么要做这个需求,这不光和优先级有关,理解业务价值也有助于所有人对需求细节进行询问和澄清。比如有一个需求是要在原开户信息上增加关联方信息。如果仅看这样的需求,好像只是在开户界面增加字段而已。但当了解到该需求的业务价值是要把原开户信息和所有关联方信息都拿来做黑名单筛查时,就能促进进一步思考:开户信息与关联方信息是一对一还是一对多的关系;当某条关联方信息不能通过黑名单筛查时,如何对关联的所有记录做拒绝申请操作等,从而细化需求。

反复确认就是供应商在接收到需求、完成设计和完成测试后都给甲方需求人员一个反馈与确认,确保需求在交付前已满足期望。

验收条件就是在提出需求的时候,想好如何验收该需求,这样交付团队在交付前也可以根据验收条件进行测试,使整个交付过程变成一个闭环。就像交待任务时,要想确保任务执行的结果满足预期,最好把期望结果在一开始讲清楚,这也是“以终为始”【“以终为始”(Beginwith the end in mind)是史蒂芬·柯维(Stephen R.Covey)的著作《高效人士的七个习惯》(The 7 habits of Highly Effective People)中提到的第二个习惯。】的思路。其实对于一个需求,最后总是要做验收的,而在需求阶段就想好验收条件,就是把关键的测试用例提前想好,避免到后期才发现交付不达预期,造成不必要的返工的情况。这也是测试先行的原则。

由于业务的需要,我们有很多定制化需求。在早期合作过程中,出现过由于需求理解的问题导致返工多次,从而使整个交付周期被拉长的情况,双方都浪费了大量的时间和精力。通过在需求阶段与供应商明确具体的验收条件,供应商在交付前便可验证是否满足验收条件,并提供测试结果,大大减少了需求到了甲方现场部署后才发现做错的情况。

04 真诚交流,持续改善

甲乙方合作,是一个磨合的过程,作为一家全球金融机构,笔者所在的公司在安全、架构、容灾设计都有很高的要求,业务也有很多定制化的需求。而且由于严格的安全管控,供应商实施人员无法直接接触到我们的网络环境和服务器,所有部署和问题排查都需要依赖甲方的IT团队来进行。项目早期出现了很多交付质量的问题。通过收集具体发现的问题,以及在供应商总部现场了解其测试、交付流程,我们制定了具体的整改意见和改善计划。出现问题往往难以避免,也无需回避,唯有持续反馈和持续改善才是王道。通过双方的真诚沟通和定期回顾,磨合越来越顺利。

在以供应商交付为主的项目实施敏捷,一向是业内的难点。但是由于该供应商的高度配合和灵活性,我们在具体实践的推进得到了很大的支持,双方携手实现了交付效率和质量的提高。

关于作者


  • 早期敏捷践行者
  • 起步于极限编程
  • 熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发
  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书