目的

通过这个案例研究，我们希望分享在2020年第一季度的疫情期间，全远程分布式敏捷交付客户项目的一些经验。希望能对大家的远程团队式交付有直接的意义。这些经验可被用来尽量减少疫情对客户造成的影响。如有任何疑问，请与AWS 专业服务团队联系，或邮件沟通，或提供改进建议。

案例梗概

通过实施远程分布式敏捷，或者叫EDF（亚马逊风格的敏捷交付框架 – Engagement Delivery Framework）的一些增强性实践，我们设法将2个月的疫情延迟减少到2个周左右。如果说有哪些你需要注意的，请看以下3方面：（1）远程交付会花费更多精力，需要会前内容准备和人员工具等的设置工作 – 要比往常投入更多才能顺利开展，尤其是在第一次远程迭代期间，（2）不要仅靠操作手册 – 响应客户的挑战，并相应地调整人员工具等的配置工作，并且（3）坚定执行迭代控制会议 – 否则沟通成本只会更高，进而更加阻碍项目进度。

大体情况

项目背景

从2019年8月起，我们开始了某家知名银行的项目，目的是将他们的一个核心系统现代化为基于微服务的系统，并且赋能客户团队。使他们以后能以亚马逊双披萨小组的形式，在微服务架构上，EDF/Agile化地自主工作。这次现代化改造计划为期10个月，有4-5位专业团队的顾问全程投入。顾问的主要工作是实现核心技术穿刺并教授给客户开发人员，同时在整个项目级和迭代级别指导EDF/Agile。

客户团队

客户团队的成员分布在3座国内城市（华东、华南和华西南）和4个办公室，被组建为3个微服务团队。包括客户项目经理/PO/BA、UI、前端、后端、系统测试、用户验收测试、以及行内框架和平台资源支持团队。这些支持团队的工作核心为开发类似spring-boot的框架、PAAS、CI / CD pipeline等，以供上层多系统使用。后端开发和项目级别的PO（产品负责人）引领整个开发过程。

疫情爆发

疫情爆发后的2个月，对项目带来了各种不便（例如，所有成员都被限制在家里、无法访问客户的Dev / IT环境、没有大家合适的远程协作工具、我方的一名顾问被牢牢封锁在武汉等等）， 这些问题我们不得不作出应对。否则，项目会被迫陷入停滞状态。客户还在强调：项目的交付日期不可更改；除非政府出台新规，否则没人可以返回办公室。

行动

我们决定将交付模式从现场变为远程。这改变了我们与客户交流、内部协作的方式以及增强团队，以确保远程工作有效地开展。

交付方法的调整：我们开展了远程分布式敏捷/EDF

在疫情之前，我们已使用EDF / Agile进行交付和赋能，客户团队的迭代速率已经稳定。疫情爆发后，我们完善并改进了现有的会议控制节点，并为远程和分布式团队增加了一些会议。 详见附录1获得快速参考。

[1] 每日早会：

整体项目成员参加，并仅针对关键任务的进度和阻碍进行更新。不包括对后端技术故事的更新 — 从在家工作开始的40分钟，改进到15〜20分钟

[2] 每日新增加1次夕会：

仅针对后端团队，使其能更多专注在后端进展、阻碍和AWS顾问技术支持进展的细节上– 从在家工作开始的30分钟，改进到少于15分钟

[3] 迭代第6天（进行下个迭代需求的梳理会）：

为下个迭代的待办事项表，开始DoR（需求就绪）的会议和梳理的分工，约为60分钟。再于迭代第10天，对需求就绪度，进行快速的检查（15分钟)

[4] 迭代第10天进行评审/回顾会：

约为1.5小时。包括（a）依次评审每个微服务团队的本迭代增量；以及（b）回顾会，其包括后端的每个开发人员，和项目中其他职能角色的一位代表。

[5] 下迭代的第1天的迭代规划会议：

约为1小时。包括:（a）对需求范围的确认（故事的AC和其它相关支持信息）；（b）确保每个故事都有细分的子任务来完成它，包括截止日期计划。尤其是关键交接任务，例如：后端API定义（第2天），完成前端/后端（第5天），完成ST（第10天）和（c）在第1天的晚些时候，对迭代计划结果进行检查，并采取后续行动。

[6] 定期举行AWS 顾问远程内部同步会议:

（a）在每日早会之后举行每日同步会议，少于15分钟；（b）每两周一次的AWS技术任务梳理会，大约30分钟；（c）每两周一次的AWS技术赋能需求计划会，大约1个小时；所有这些都可由微信群，随时沟通补充。

[7] 每周远程赋能客户会议:

每周五1小时会议，一次一个技术主题，专注于最关键和短期的主题。

[8] AWS顾问随时待命客户的临时请求:

其主要用于代码评审和开发相关的咨询；会议结束后，由一名开发人员在Wiki上写下咨询要点。

项目的人员工具设置的调整

[9] 远程访问：

客户提供的VPN工具开通/设置/运行 – 整个过程花费了大约一周的时间。比现场办公的效率略低。

[10] 建立协作：

选择了中国区较有会议质量保证的线上会议工具（如：Zxxm，等）可以正常工作。同时我们使用Wiki/Jira作为敏捷的项目管理工具，并记录关键项目信息。

[11] 客户项目经理副理的轮岗：

通过轮换项目副理，客户项目经理可以更专注于大BA的职责和对外部团队的依赖，而项目副理也不会一直背负太多额外工作量。

[12] 对开发遇到阻碍的快速响应：

任何技术点上的独立研究，不能超过1个小时。当客户开发人员卡在某个开发任务上近1钟头时，需马上与AWS顾问进行快速咨询。客户使用微信提出请求，并通过jira / wiki工具来管理响应。

AWS团队变更

[13] 增加1位顾问：

由于我们不得不在远程沟通/访问上投入更多的精力，而首席技术顾问又被封锁在武汉，所以我们决定增加1位顾问（其80％的时间），用以提升AWS的整体服务客户项目的能力。

[14] 顾问服务更专注：

每个微服务团队都有1位顾问，而整体项目的架构/技术由1位首席技术顾问来总负责。

结果

第一次远程迭代的速率是疫情前速率的一半（即速率变慢），但是在第三次迭代结束时，我们已经完全调整过来，与疫情爆发前的进度安排相比，我们成功地将2个月的预期疫情影响减少到1个迭代时间（2周）。

附录1:与客户远程迭代会议的增强版

新增加的远程会议加了粗体和下划线。

本篇作者