聊聊远程项目交付的敏捷管理

这是鼎叔的第四十三篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

对于日益重要的国际化市场，越来越多的离岸项目（内包或外包）在进行中，即需求方/客户在A地，开发团队在B地甚至海外。这种情形下，常见的敏捷实践活动也都是适用的。敏捷和精益关注的是价值观和原则。价值观也是文化的一部分，因此需要和离岸团队交谈并学习如何共同工作才能建立。本文内容也适用于任何远程项目的敏捷管理。

参考文章聊聊多地点团队的敏捷研发，《在离岸开发中使用敏捷软件过程》（martinfowler.com) 。

对于远程项目，关键的不足在于缺少致力于理解和应用敏捷价值观的利益相关方（即客户和管理层），因此，我们要教导真正客户和真正开发者之间通过反馈循环进行紧密而持续的协作。所有利益相关方的思维模式和行为要为了敏捷而改变。

客户的期望

销售人员可能会给新客户不切实际的许诺，但却不关心采用Scrum所需的行为改变。建议和远程团队一起，准备一个清晰简单的指南，请销售人员和潜在用户阅读。

传统理念的客户不太习惯与实际开发人员对话，而宁可和一个中间人（项目经理）对话，客户认为只要移交了规格说明，那么在项目结束时就能得到一个好系统。

因此，当我们和新客户开始新项目时，尝试进行一天的“远程敏捷”研讨会吧。在这个会议上，像客户分享敏捷开发的基本理念，探讨如何降低各种生产中的浪费，演示一个Scrum发布周期的过程。

邀请客户去远程团队所在地GoSee（实地查看），让他和开发及测试工程师建立直接联系，并明晰产品负责人的角色职责。

开发团队与客户的互动

远程团队和真正客户之间如果有中间代表，那他应该是牵线搭桥的角色，鼓励双方直接会面，互相拜访或者视频通话。邀请客户参加迭代计划会议，迭代评审和回顾会议，或远程需求研讨会。对于跨国项目，公司甚至可以雇佣翻译，克服双方沟通上的困难。

远程外包一个普遍的毛病是客户看不到真正的问题，所以通过邀请客户参加一次迭代回顾会议对增加信心会有帮助。我们也鼓励让远程团队部分成员出差到客户所在地，完成一个到几个迭代。

如果可能的话，说服客户找到更好的产品负责人，他应该更接近用户，但并非客户IT部门内的人员，积极接受Scrum培训。

远程敏捷开发需要各方之间大量持续沟通，因此要特别确认对方的回答，不同国家的回答可能含义不同。建议提出开放式问题，或者让对方反向提问。

将需求外包给远程团队

远程外包团队可以突然被要求开发自己不熟悉的系统，就会面临“知识转移”问题，尤其面临文化、时区和语言的不同，这个问题挑战更严峻。

通常的传统做法是派人去客户那里出差，写需求，成为业务主题专家（SME）。事后发现这些SME可能成为了研发瓶颈。每个迭代的详细需求从客户发到远程团队，都依赖SME的仔细阅读。

因此，我们建议每次迭代都召开一次远程需求研讨会。整个团队一起消化需求材料，同时用白板进行问题说明和大量交谈，将争议点记录到共享WIKI上供客户侧阅读，然后两边团队举行视频会议审查争论点并把结论在线更新。这个需求研讨会也是产品代办事项清单提炼的一部分，以此方式把交接浪费降低。

远程团队还可以为新接触的大型系统，在首次迭代前组织一场“产品愿景研讨会”，先创建业务领域视图，建立共同的概念和词汇，然后认知产品未来的愿景宏图和主要特性。

发给远程团队的需求文档也不是越详细越好，而是在迭代回顾会议上确认用户故事的细节程度是否满足要求，灵活适应。详细文档并不能替代面对面交流。

还有一个技巧是，请客户方的UI设计师尽早地（最好每次迭代）制作UI原型图，或者通过视频通话共同创造UI，以尽量扩充交流的可能。

从一开始就安排验收测试用例来表达需求，对于远程短期外包项目有特殊的好处。明确客户的验收测试用例UAT，如果每个用户故事完成后，客户都能进行手工UAT，可以进一步成批地降低工作量。

稳定的远程Scrum团队

管理层需要意识到尽量把团队保留在一起的价值，不管是长项目还是短项目，理想情况下长期稳定的团队有利于保障交付和学习。但在特殊情况下可以组建新团队，比如领域专家分散在公司不同部门，或稳定团队的提升趋势缓慢。

鼓励远程团队说“不”，这是自组织团队的自我赋权，改变过度承诺，获得个人安全感。Scrum的原则之一是工作不能强加给团队。

建立长期的敏捷指导中心团队，为远程团队引入外部可以充当感染源的敏捷指导专家，给新人分配经验丰富的伙伴。

健康的合作关系

避免“本地管理，离岸开发”的模式，这是差劲的泰勒主义形式，和精益敏捷开发实践违背。不要把单职能或组件外包出去，而是可以外包一整套以客户为中心的完整特性。绝大多数工作都由外包方承担，除了接近真正客户的本地团队帮助进行详细的需求分析。

把远程外包团队当内部伙伴来对待，出现问题时拜访合作伙伴并寻找根本原因，要实地查看，而不是盲目遵循所谓的“质量准则”来兴师问罪。

在远程团队和本地团队中不偏爱一方。比如多地点会议时不要总安排远程（离岸）团队不方便的时候，不要忽视离岸团队的假日。

远程外包团队可能是经验不丰富的年轻人，如果我们采取本地经验丰富的专家来做设计，指挥远程团队将其编码实现，那么就会带来大量的交接和转移浪费，更多的规范，以及更糟糕的代码。因此，我们要反过来，尝试让本地丰富经验的“设计师”充当指导和审阅者角色，让远程团队采取小幅度的创造性编码和设计。本地老手带异地新手，充分利用共享桌面的结对编程，短周期代码评审。

基于敏捷来甄选外包公司

外包公司有可能号称自己支持各种敏捷研发模式，实际上将其变异成自己能够重新定义，控制的东西，兜售逐利的商业工具，但是有些敏捷原则可能在该外包公司根本无法支持。

在头重脚轻的外包公司中，资深的人做为管理者积极强化传统管理，“控制”经验少的年轻群体，形成“假冒敏捷”的组织。因此，要亲身Go See外包公司的程序员，看他们的才能是否匹配一个自组织团队的高要求。警惕外包公司仅仅以“擅长编程”来招聘员工，而是观察员工的编程质量，以及结对工作时的表现。

而这些外包公司的环境布置可能也和敏捷倡导的背道而驰，需要进行互动可视化和创造力的改造。

把编码和测试工作比喻成“工厂”的外包公司，没有理解反馈循环的意义，“工厂”强化了长队列上的大批量工作，把“半成品”交付给其他团队。