作者：程力 | 编辑：余涛

文章简介：分布式敏捷组织与传统敏捷组织的管理方式在核心上其实并无本质区别，但在“分布式”这一严苛条件的前提下，在日常敏捷实践中的那些只重“形”不重“神”的环节所引发的问题则会暴露无遗，严重时甚至会阻碍团队的正常运转，这是对团队是否真正掌握了“思想敏捷”的一次深度考验。

庚子年初，荆楚大疫，众惶恐，皆闭户，举国防之。位于疫情风暴中心的我们在第一时间成立了专班小组奋斗在“科技战疫”的一线，与湖北省防疫指挥部开展密切协作，全力保障医疗物资在生产计划、分配、储运、签收到货等各个环节的准确与效率，为政府防疫工作的顺利开展提供了有力的支撑。

每一个光明前途背后，都有一条曲折的道路，2020年1月23日武汉封城，随后疫情一天天加剧，政府也相继出台了愈来愈严格的防控隔离措施，身在抗疫一线的我们，如何即确保质量与效率又能保障日常工作协作与落实的顺利开展，“分布式敏捷组织”成为了我们的必由之路。

我平常开玩笑说IT研发更像是“一场大型线下社交活动”，团队协作中的沟通无处不在，但因为人的多样性和语言表达的丰富性，团队中“与人沟通”的难度常常远超过“与代码沟通”。而分布式之后，团队协作则变成了“一场大型线上社交活动”，这对团队的沟通和管理都无疑是更艰难的挑战：

沟通介质从“空气”变成了协同工具、终端设备、网络等多个节点串联起来的通道，而任意一个节点出现故障都会导致沟通不畅甚至中断；效率下降也意味着成本上升，大半夜开会成了家常便饭，远程办公成了一直办公。

由于成员不能处于同一空间，缺少了相互督促的同侪工作环境氛围，由于一些或主观或客观的干扰因素，工作效率不如现场办公；受限于沟通条件，主动询问进度经常会演变成“干预性打扰”，容易引发信任危机。

研发流水线本身在敏捷团队中就尤为重要，其稳定性和扩展性直接决定了团队的整体研发效能；如果平常没有花足够的成本去持续改进和积累，在面临突发的远程协同工作时势必会严重影响团队效率。

在这次的省医疗物资保障管理系统项目中，由于项目的特殊性和紧迫性，我们不得不采用大规模的分布式敏捷组织架构，同时一些既有的基础设施也无法完全利用，但结合团队在敏捷实践中的深厚积累，以及在项目中高强度的磨合和迭代改进，我们的团队基本克服了上述困难，得到以下几点实践经验。

看板应该是一个组织进行敏捷实践最先使用到的工具，但同时也极有可能是第一个流于形式的工具，移动卡片的新鲜感通常在“蜜月期”过后即消散于无形，沦为了敏捷教练一个人的小把戏。现场办公的团队之所以可以不使用看板继续工作的本质原因是因为沟通成本低，随便喊一嗓子就能得到回应，如果喊一遍解决不了那就再喊一遍。但高昂的沟通成本是分布式团队不能承受之重，所以此时将看板作为项目信息及状态同步的工具，极大地确保了团队中的每一位成员，在任何时刻都能从看板上获取目前团队的最新进展，同时将自己的状态在看板上予以更新，看板信息的呈现与反馈全员协同并行，才能节约大量的沟通成本，将看板打造成全团队的“唯一信息辐射源”是一个分布式团队能成功运转的关键所在。

图1：因地制宜的改良看板以适配分布式协作

同时，利用电子看板的优势，因地制宜的进行改良以适配分布式协作。要实现看板“唯一信息辐射源”功能，需要尽可能多的将重要信息发布在看板上，对齐团队的“沟通语言”。例如上图，我们在看板中添加了“分支名称”和“依赖”两列，这是因为我们在团队运转过程中发现，对于研发人员而言，常常是知道了自己要做什么，但是不知道应该在哪里做即不知道其任务所处分支及分支状态，在聊天记录中搜索“分支”关键字可以发现相当一部分比例都是在询问分支在哪里或者分支状态；而“依赖”则是在版本发布时，根据每个任务的“优先级”和“阶段”即可准确迅速地决定发版策略，从而极大节省信息同步的时间及决策时间。

团队在刚开始实行分布式办公的一段时间里，每天依然坚持传统集中站会制度，但运转一段时间之后，我们发现每天大集中式的站会变得不太可行且必要性不强，现阶段不是特别适配团队。一是确实有各种客观原因导致个别成员无法按时参加；二是在分布式下日常的沟通变得相对正式且重要。

图2：每一次会议都是一次“站会”

现场办公中，团队成员之间会靠“混沌的、自发的、随机的面对面交流来凑合解决问题”（程序员练功房,熊节）。而分布式组织里，通过视频会议工具发起的每一次会议和讨论，因为会强制中断会议参与人的工作而变得相对正式；同时由于较高的沟通成本，讨论主题必须清晰，讨论过程必须聚焦。因此，我们将站会的核心要素：”控制时间“、”聚焦问题“、”明确下一步“等带入每一次会议，而且每一次会议中都会自发诞生一个临时的Scrum Master来提醒大家。这样每一次会议都能高效起来，聚沙成塔，团队整体效率才能得以显著提升。

backlog梳理本是需求管理的重要的环节之一，但为了匹配项目进度，我们将“backlog梳理”与“点数估算”的工作合成为了确定“优先级”，同时“backlog梳理”中的内核“梳理客户价值”，与“点数估算”的内核“计算研发成本”，依然保留了下来。

我们将优先级分为了“极高”、“高”、“中”、“低”四个级别，这四个级别是对应了“时间管理四象限”：“极高”对应重要且紧急，“高”对应不重要但紧急，“中”对应重要但不紧急，“低”不重要且不紧急。其中需要重点讨论的是 “高” 和 “中”。在 “高” 和 “中” 里，可以把“重要”与否看成研发成本高低，“紧急”与否看成客户急迫程度高低。

• 标记为“不重要”即“研发成本较低”，而“紧急”即客户很急迫的任务，是研发组给产品组的底气，从而让产品组与客户协商时保有充分的余地；

• 标记为 “重要”即“研发成本较高”，而“不紧急”即客户不急迫的任务，是产品组对客户不做出时间上的明确承诺，从而让研发组能有更多时间把重要的事情做好。

这样直观且清晰的划分，能充分发挥团队成员的主观能动性：

• 怎么样把“研发成本高”的事情变成“研发成本低”，这是研发组自己的课题；

• 怎么样把“客户急迫高”的事情转成“客户急迫低”，这是客服组自己的课题。

基于此，团队成员之间各自努力把自己的课题做好，形成了相互信任，公开透明的协作文化。

我们项目组起初需要在48小时内为客户交付一个满足基本需求的版本，这是一个典型任务型阶段，那么主干开发主干发布即可满足有求。在满足客户的初步需求之后，产品组开始主动思考如何更好的协助客户时，项目由任务型阶段转变成了功能型阶段，即会根据客户使用情况，按天释放功能。此时我们的代码管理策略随即转换为了下图所示的分支开发主干发布的方式。

图3：适配项目阶段的代码管理策略

在渡过了需求井喷阶段之后，产品组开始构思更加长远的需求、研发组开始进行部分功能的重构时，我们的代码管理策略则转变为标准的gitflow策略(A successful Git branching model, Vincent Driessen)，以适配不同特性功能的差异化释放策略。

我们并没有在一开始使用“最好”的代码管理方式，是因为越精细复杂的分支策略，也会带来管理成本上升，根据项目的进展阶段，选择合适的代码管理方式才是最好。同时，在代码管理方式变得精细化之后，code view的重要性和必要性也日渐突出。流于形式的code view导致我们经历了几次大型的代码冲突，最终我们将合并权限收口到几位经验丰富的研发组长之后，问题才得以解决。慢即是快，code view看似是成本，实际上是提升研发能力和交付质量的一剂良药。

搭建研发流水线，将研发中流程化的工作沉淀为自动化任务，是一个敏捷组织的基本必备能力。而在分布式敏捷组织里，这种能力已然成为团队的效率基石，每天上百次的持续集成和2到3次的产品发布，全都依赖着一条稳定且扩展性良好的流水线。

图4：利用协同工具机器人推送持续集成信息

同时，我们不仅仅只局限在代码集成自动化上。分布式协作中高昂的沟通成本，不断的推动着我们去梳理工作流程并实现更多的自动化场景从而辅助团队提升效率。例如根据不同条件触发应用版本和数据版本的备份或回滚，自定义数据清洗及同步，基于协同工具机器人实现流水线各阶段进展通知，人员工时统计，报表自动化生成等等诸如此类的小自动化设计在工作场景中比比皆是，这些改进都可以极大地减少不必要沟通，同时最大化工作信息的透明度。

传统组织的项目管理的核心工作内容为：需求管理，目标管理，配置管理。敏捷组织则是在围绕“交付质量”为核心的前提下，将传统的项目管理工作映射成敏捷管理实践的三部分：产品实践、管理实践、工程实践。而分布式敏捷组织与传统敏捷组织的管理方式在核心上其实并无本质区别，但在“分布式”这一严苛条件的前提下，在日常敏捷实践中的那些只重“形”不重“神”的环节所引发的问题则会暴露无遗，严重时甚至会阻碍团队的正常运转，这是对团队是否真正掌握了“思想敏捷”的一次深度考验。

在VUCA时代我们总会遇到一些小概率的黑天鹅事件，而我们的敏捷组织在遇到这样的风浪和危机时，如何依然能够比较顺利地前进，是非常值得探究的事情。此次突发的疫情就是一只不折不扣的“黑天鹅” ，成为了检验我们敏捷转型成果的“试金石”，我们相信在经受住此次极限压力测试的考验之后，我们的敏捷组织能力必将再上一个台阶。