01 限制在制品，聚焦有限需求，提升交付效率
02 每日例会，确保进度
在每周的交付计划确定以后，我们与供应商的项目经理每天都会就交付进度和遇到的问题进行交流，确保进度，也让问题得到及时的反馈与解决。
03 实例化需求，实现交付闭环
说清楚需求，从来不是一件容易的事情。通常情况下，需求描述都是比较抽象的，这就会导致同一句话，不同的人可能有不同的理解，更要命的是，表达的人并不知道接收者的理解是否正确。就像下图，有人说他需要一套渔具，有些听众觉得需求是鱼竿、或者是渔网，甚至是渔夫帽。很多软件问题是由需求这个源头产生的。
具体到我们的业务场景，假设需求说的是需要一份报表把某基金管理人下所有投资人的持仓金额进行汇总，如果需求仅仅是这样一句话的话，这“汇总”二字就可以引起很多不同的理解。汇总后具体有哪些信息需要展示在报表中、是否需要做合计、哪些数据需要合计等等，都是需要澄清的。
为了确保交付的正确性，一方面，作为甲方，我们需要把需求说清楚。有3个环节确保需求的完整性：业务价值、反复确认与验收条件。另一方面，供应商需要相应地理解需求的业务价值、持续反馈和把验收条件放入交付前的测试用例中。
业务价值就是为什么要做这个需求，这不光和优先级有关，理解业务价值也有助于所有人对需求细节进行询问和澄清。比如有一个需求是要在原开户信息上增加关联方信息。如果仅看这样的需求，好像只是在开户界面增加字段而已。但当了解到该需求的业务价值是要把原开户信息和所有关联方信息都拿来做黑名单筛查时，就能促进进一步思考：开户信息与关联方信息是一对一还是一对多的关系；当某条关联方信息不能通过黑名单筛查时，如何对关联的所有记录做拒绝申请操作等，从而细化需求。
反复确认就是供应商在接收到需求、完成设计和完成测试后都给甲方需求人员一个反馈与确认，确保需求在交付前已满足期望。
验收条件就是在提出需求的时候，想好如何验收该需求，这样交付团队在交付前也可以根据验收条件进行测试，使整个交付过程变成一个闭环。就像交待任务时，要想确保任务执行的结果满足预期，最好把期望结果在一开始讲清楚，这也是“以终为始”【“以终为始”（Beginwith the end in mind）是史蒂芬·柯维（Stephen R.Covey）的著作《高效人士的七个习惯》（The 7 habits of Highly Effective People）中提到的第二个习惯。】的思路。其实对于一个需求，最后总是要做验收的，而在需求阶段就想好验收条件，就是把关键的测试用例提前想好，避免到后期才发现交付不达预期，造成不必要的返工的情况。这也是测试先行的原则。
由于业务的需要，我们有很多定制化需求。在早期合作过程中，出现过由于需求理解的问题导致返工多次，从而使整个交付周期被拉长的情况，双方都浪费了大量的时间和精力。通过在需求阶段与供应商明确具体的验收条件，供应商在交付前便可验证是否满足验收条件，并提供测试结果，大大减少了需求到了甲方现场部署后才发现做错的情况。
04 真诚交流，持续改善
甲乙方合作，是一个磨合的过程，作为一家全球金融机构，笔者所在的公司在安全、架构、容灾设计都有很高的要求，业务也有很多定制化的需求。而且由于严格的安全管控，供应商实施人员无法直接接触到我们的网络环境和服务器，所有部署和问题排查都需要依赖甲方的IT团队来进行。项目早期出现了很多交付质量的问题。通过收集具体发现的问题，以及在供应商总部现场了解其测试、交付流程，我们制定了具体的整改意见和改善计划。出现问题往往难以避免，也无需回避，唯有持续反馈和持续改善才是王道。通过双方的真诚沟通和定期回顾，磨合越来越顺利。
在以供应商交付为主的项目实施敏捷，一向是业内的难点。但是由于该供应商的高度配合和灵活性，我们在具体实践的推进得到了很大的支持，双方携手实现了交付效率和质量的提高。
关于作者
- 早期敏捷践行者
- 起步于极限编程
- 熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发
- 著有《猎豹行动：硝烟中的敏捷转型之旅》一书
