（图片来源：https://unsplash.com/photos/RxOrX1iW15A）

4月18日早上9点30分，团队跟着大屏计时器整齐地喊出倒计时，“五、四、三、二、一”，Tech Lead 强哥和 PO 小楠相对看了一眼，一起按下了earth系统发布的回车键。随着app和web系统用户登录的叮咚声不断响起，earth系统正式上线成功。会议室里也再次响起了团队的掌声和欢呼声。

那曾经是我职业生涯中为数不多的高光时刻，让我至今记忆犹新。

在我们每个人的职业生涯中，也总是希望能加入一个优秀的团队，一起经历这样的高光时光，项目成功自己也有所成长。而当自己成为团队Leader之后，也希望自己能够带领出这样优秀的团队，乘风破浪，创造这样高光时刻。

那么，如何实现呢？作为团队新任Leader，可以从以下5个问题入手，为自己的团队把把脉。

问题1： 团队目标和交付价值是什么，团队成员是否知晓且对此有一致的共识？

“如果没有目标，那么任何风向都是逆风；”——摘自网络

明确的目标会为团队的工作引导方向，就像航行不能少了罗盘，再大的船也需要有明确的航行目标和方向，再强的出海舰队也需要对去往的方向和如何应对险阻有一致的共识。

没有了目标和共识，团队不仅会偏离行驶的目标，也会在一望无边的任务中忙乱、彷徨、失措而最终黯淡离场。

作为团队Leader，首要任务是从繁杂的信息中明确目标，并清晰地传达给团队每一个人。如果说一个Leader只做一件事，我认为是设置清晰明确的目标，并让目标在团队中达成共识。

然而，能做到这一点的团队并不多。

我观察到最常见的问题不在于有没有，而是在于新Leader多无意识地忽略了这一行动举措，仅传递我们要完成的任务。很多团队中开发人员在写代码时并不知道这个迭代的交付优先级和业务价值，已是常态。

敏捷谚语：“所有的Story缺省都是无效需求，除非它有明确的价值”

团队成员作为执行个体不知道目标和价值，就只能尽可能根据自己的理解去优化自己的执行过程和结果。这往往会导致：

• 反复执行方案的浪费
• 追求任务本身优化和细节尽善尽美，导致未预期的开发过程蔓延
• 或出现与目标不匹配的结果偏差
• 乃至导项目的延期交付、成本蔓延、目标偏离等问题

曾经有这样一个心理学家的试验（摘自网络）：

这个心理学家组织了三组人，让他们分别向着10公里以外的三个村子进发。

第一组的人既不知道村庄的名字，也不知道路程有多远，只告诉他们跟着向导走就行了。刚走出两三公里，就开始有人叫苦；走到一半的时候，有人几乎愤怒了，他们抱怨为什么要走这么远，何时才能走到头，有人甚至坐在路边不愿走了；越往后，他们的情绪就越低落。

第二组的人知道村庄的名字和路程有多远，但路边没有里程碑，只能凭经验来估计行程的时间和距离。走到一半的时候，大多数人想知道已经走了多远，比较有经验的人说：“大概走了一半的路程。”于是，大家又簇拥着继续往前走。当走到全程的四分之三的时候，大家情绪开始低落，觉得疲惫不堪，而路程似乎还有很长。当有人说：“快到了！快到了！”大家又振作起来，加快了行进的步伐。

第三组的人不仅知道村子的名字、路程，而且公路旁每一公里都有一块里程碑，人们边走边看里程碑，每缩短一公里大家便有一小阵的快乐。行进中他们用歌声和笑声来消除疲劳，情绪一直很高涨，所以很快就到达了目的地。

在这个心理学试验中显示，当人们的行动有了明确目标的时候，并能把行动与目标不断地加以对照，进而清楚知道自己的行进速度与目标之间的距离，人们行动的动机就会得到维持和加强，就会自觉地克服一切困难，努力到达目标。

以上试验向我们证明了目标对于团队的重要。在一个敏捷团队，产品需求不明确，价值交付是唯一方法时，就更需要有明确的目标和价值主张。这样才能指导团队用“简单足够”的设计去“敏捷地”为客户交付可工作的软件，尽快验证价值获取反馈。

与此同时，当一个明确而又看得见的目标在团队内的时候，还会成为激发团队的动力，甚至会让团队焕然一新，创造奇迹。目标有时候不在于多高大尚，而在于团队是否清晰明确的知晓，它的力量甚至超出你的想象。

那么，一个项目的目标包括什么？

• 项目画布（Project Canvas）包括项目的目标/愿景/MoS/价值主张
• 工作说明书（SOW-Statement of Work）中的交付承诺
• 服务框架协议（MSA-Master Service Aggreement ）中定义的客户信息安全要求及其政策
• 项目的交付周期、关键交付里程碑

又如何让大家看得见且形成共识？

第一，构建信息辐射体（Information Radiator），比如利用物理墙、jigsaw电子墙、团队会议模板等可视化渠道传递项目的关键目标。

第二，使用下面这个问题详单帮你在日常工作中融入目标的维持和加强：

• 是否在Onboarding的时候向新人介绍项目的目标、关键里程碑、MVP。
• 是否在Onboarding的时候向新人介绍交付承诺，实现举措以及优先级。
• 是否有阶段性的组织项目Update，及时传递和更新变更，始终保持团队在目标上的同频。
• 是否在迭代计划会议（IPM-Iteration Planning Meeting）的时候向团队清楚的澄清本迭代的目标和优先级，以及原因，确保团队冲向同一终点。
• 是否在Retro的时候回顾本迭代目标和完成情况。
• 目标和进度是否有足够的可视化，让团队可以看得见找得见。
• 是否每个人都清楚自己的职责和任务，并知道与目标关联关系

孙子曰：上下同欲者胜。

“当一个人知道自己想要什么，整个世界都会为他让路”。团队也是一样。

如果团队成员没有共同认可的目标或对目标缺乏清晰的理解，就会影响到集体决策和协同行动，损及团队以及团队的业务成果。而团队Leader不懂目标的力量，可能累死自己还拖垮了团队。

因此，团队新Leader需要善用目标管理，清楚设置项目目标，并坚信这一目标富有的意义和价值，竭尽全力地始终保持团队在目标的共识，且团队中每个成员都知道自己做什么和怎样做可以共同完成任务。这也决定了在困难来临的时候团队是否有乘风破浪的勇气和动力，也是团队成为王者的前提条件。

在新建一个团队时候，前四个迭代是你做好目标建设的最好时机。

问题2：团队成员是否可以及时获取完成开发任务所需的信息？

（图片来源：https://www.sohu.com/a/203790693_187697）

在《技控革命(从培训管理到绩效改进)》一书中引用了托马斯.吉尔伯特绩效行为工程模型中，它指出环境因素占组织绩效的75%，在环境因素中信息因素占35%，包括：

• 是否被清晰、明确地告知做好工作的标准和期望
• 是否得到做好工作的各种信息，能及时、明确的获得工作的反馈

对于从事敏捷软件开发的知识工作者来说，及时获取完成任务所需的信息输入及实现共识-包括业务价值、技术方案、验收标准以及反馈-显得更为重要。因为这些决定了他/她将以什么样的方法、多少成本去交付什么样价值的可工作软件。

敏捷谚语：“再详尽的文档也无法替代个体和互动”

如果没有及时获取这些信息和共识，就会出现如下问题：

• IPM估算时每个人的理解不同，无法达成一致，最后仓促了事。
• 有时候开发了好长时间的用户故事，突然在沟通中发现根本不是客户想要的，只能重做。
• 用户故事没有DoD（Definition of Done）、技术方案、接口设计，经常做到中间才发现需要推倒重来。
• 代码写到快完成了，发现字段命名不符合规范，联调失败，不得不返工。
• 花费了四天终于把模型和复杂逻辑搞定了，突然发现其它同事已经做过了。
• 同一个bug经常反复出现，改了一个bug又可能引起了新的bug
• 每个人说法都不一样，而且有时候自己都忘了当时的决策是怎么回事。

……

那么，当我们进入迭代开发后，需要哪些信息和共识？以及在什么时候？

迭代过程也是团队对交付工件逐渐达成共识的过程。在迭代的窗口内需要确保需求和计划是明确的，以便团队可以快速的完成和持续验证。

迭代开始，PO与团队TL/PM/BA需要就交付范围的优先级达成一致，而开发团队则需要就本迭代开发的工作内容、DoD(完成标准）的要求、以及如何实现（接口设计、多系统处理的集成设计、组件结构、复杂流程处理和组件、逻辑数据库设计、测试策略、编码规范等）获得相同的理解，以便为本迭代的目标进行全力冲刺。

作为团队的Leader需要确保以上任务信息及时给到团队，以实现团队绩效的最大化。可喜的是，Scrum、XP、精益中的工程实践已经帮助我们定义了清晰的迭代结构和信息流，你需要的是合理的遵循和发挥它们在团队信息和共识的价值。

问题3：团队是否可以有序地开展价值交付活动？

（图片来源：https://unsplash.com/photos/M3cxjDNiLlQ）

疫情时代的到来，我们可以看到不确定性将会是最大的确定。对于交付团队而言，面对的挑战也不仅仅是需求的不确定，还有客户从成本效率向速度及快速适应变化的诉求。对于团队则意味着一切可能都会变，时间紧、压力大会成为常态。

接下来我们来谈谈在这样一个常态下，团队如何从忙乱到有序的这个问题。

1969年塔克曼先生在《小型团队的发展序列》文中指出，团队发展存在五个阶段：组建期（Forming）、激荡期（Storming）、规范期（Norming）、高效期（Performing）和休整期（Adjourning）。这五个阶段在团队的发展过程中都是必须且不可逾越的。

在今天这样的挑战下，留给团队从组建到高效的时间并不多。

一个优秀团队就体现在是否可以快速地从组建的忙乱进入到规范有序。时间越紧压力越大的项目，越需要有经验的Leader站出来，积极主动地通过应用敏捷精益的工程实践构建团队契约、流程机制、可视化价值看板、知识共享等来促成团队在不确定中从无序忙乱到规范有序，而这种适应性的能力和文化也会是未来团队致胜的关键。

1.为什么有序这么重要？

杂乱无序会导致效率低效、士气低下、重复-多头甚至错位管理。无序状态持续越久团队的情况越糟，疲惫不堪，结果也可想而知。而新手Leader容易出现的误区就是缺乏对敏捷精益工程实践的理解、缺乏系统思考、缺乏有效举措，往往导致越管越乱，看不到有效的价值收益。

团队无序的一系列特征可能包含：

• 每个人似乎都有做不完的事
• 任务总在不停的变，团队成员的安排也总在变，随意无逻辑，一切以进度为导向
• 进度迟缓出现救场明星或微管理，结果却越管越乱，系统的负反馈被加强
• 总是被动的响应变化，又马上为了响应被迫做出偏面的决策
• 成员不清楚什么样的事情由谁负责，应invovle谁，好像这算是他负责，也好像是她
• 成员不清楚决策的流程和沟通机制，看到问题也无力解决
• IPM还没有理解清楚业务和方案，也没有清楚的验收标准，赶紧开发吧
• 返工、开发中途的不同反复频繁出现
• 等不了后端了，这几张卡有些复杂我也一起做了
• Bug似乎越来越多
• 人也不少，感觉总是做不完，团队处在紧张加班的焦虑之中
• 反复共识，随随便便就做出决定然后又随随便便推翻，不知道找谁，等待，浪费

2. 如何理解有序？

有序指物质的系统结构或运动是确定的、有规则的。序是事物的结构形式，指事物或系统组成诸要素之间的相互联系。有序是动态的、变化的有序。当事物组成要素具有某种约束性、呈现某种规律时，称该事物或系统是有序的。人们通过认识客观世界，认识各种事物和对象的组成要素、相互联系、结构功能及它们的发展演变规律，即事物的有序性，来促成事物不断从无序向有序方向转化。

有序是动态变化的，随着新事物以及组成要素的变化，有序可能转向无序，也有可能促成有序向更高能力的有序变化。

那么，在敏捷团队价值交付的上下文中，有序意味着什么？

在我看来，在敏捷交付活动的有序代表了以下三个有秩序的活动闭环：

• 价值验证闭环，从想法提出到生产环境客户验收的价值流转是否有序。
• 围绕迭代的团队协作闭环，从迭代计划、迭代启动、Story开卡和关卡、Showcase和Retro这些活动中的任务分工和人员协作是否有序，遇到问题知道找谁，几时站会，几时code review，如何决策，以及代码的规范有序可依。
• 新人融入闭环（能力提升闭环），在新人被卷入快节奏交付前可以有明确步骤的融入和快速胜任上岗。

2.1 价值流闭环指？

我们需要明确，敏捷团队想要交付的是产品价值的最大化，而不是最多的功能点。团队希望可以将客户最初的想法随着需求到上线发布的快速流动转化为可工作的软件产品，从而给客户最初的想法提供反馈和价值验证的闭环——产品价值指所开发的产品或服务对最终用户的价值，它是用户选购或使用该产品的首要因素，也是企业盈利的本质。

团队可以根据所做产品和客户的诉求，组织和设计流程与任务，确定上下游的关系，并按时间顺序排列起来就形成了该产品的价值流图。

价值流图对团队有什么样的启示？

1）聚焦价值成果（Outcome）而非仅仅产出功能点（Output）的流动

构建一个顺畅、一致经各个步骤的价值流，使得我们能够持续地、有节奏地、没有非必要的延迟、并以最优的资源使用方式来交付成果，它的好处还包含：

• 让整个流程可视化，团队可以聚焦在被创造的价值上（outcome），而不是日复一日交付了多少个功能点（output)。
• 有利于从全局视角去分析问题，识别和消除瓶颈，从而避免局部优化的陷阱—指把时间和精力花费在根本没有效果甚至带来负面效果的管理行为上，尤其在忙乱的时候。

同时，基于此也可以促使团队建立如下的迭代交付物理看板墙，可以从全局上从迭代的角度对交付过程进行管理和优化：

• 进行价值优先级的排列Story和开发任务
• 显示化价值流的运转规则
• 管理负荷，控制在制品数量，降低浪费，促成小批量的交付和验证
• 管理拉式的流动，建立反馈和持续的推动价值闭环的改进

2）促使BA将隐性的业务价值知识从无序拆解到有序且足够小的用户故事，提升它被下游消费的效能传递和消费

我们必须要承认业务价值是隐性知识。不管是大到EDGE价值投资管理框架、还是小到用户故事Story的编写实践和可视化工具，它们都可以帮助我们与客户一起协同，从复杂的业务价值识别出最简可行产品（MVP），并将大块的价值需求进行拆分，从EPIC到用户故事地图，再到按迭代优先级排序的用户故事堆。其中，Story在进入迭代前需要足够小以支持团队持续批量的交付，这是实现快速价值流转的基础。

最近在一个项目走查时也发现了业务价值作为隐性知识传递的特点：它的传播成本是距离的衰减函数。

作为BA，在端到端的交付中，除了将业务价值从无序拆解到有序以Story方式输入给交付团队外，还承担了业务知识传递载体的关键职责。因此，需要积极组织有效地社会化学习活动，向交付团队传递隐性的业务知识，且传递的效果要以知识消费者的角度去检验。

这也是因为软件产品开发的好与坏依靠交付团队整体的认知水平。为了交付成功，团队在这方面花再多的时间也不为过。

2.2 围绕迭代的团队协作闭环？

团队最重要的特征在于成员之间存在分工和协作，良性分工和有效地协作创造协同效应，即1+1>2。在Thoughtworks，我们采用的是Scrum与极限编程XP的工程实践组合，一个典型的交付团队内有PM、BA、UX、TL、前后端开发、QA多个角色。

那么他们分别负责什么，在什么时候，什么样的任务如何协作？

以下以Scrum团队的三个角色Scrum Master、Product Owner、Scrum Team描述了团队的相关职责，在不同的项目通常还会根据具体的交付任务和团队情况设置对角色职责进行调整，比如增加面向产品的特性开发团队及Feature Owner、促进每日站会的主持、迭代的交付负责人IM等。

Scrum Master，通常会有PM或IM负责：

• 组织团队按敏捷过程规范高效运作，促进内外沟通协作；
• 管理进度、风险，协调解决敏捷运作过程中各种阻碍，推动持续改进。

Product Owner:

• 负责产品业务设计、需求提出、验收、运营分析和产品改进；
• 建立产品Backlog，排优先级；
• 与BA紧密沟通、澄清业务需求；

Scrum Team：

• 作为PO和开发团队的沟通桥梁，协助PO分析需求和确定优先级
• 编写和拆分用户故事(含验收条件AC)，维护产品Backlog；
• 交互体验设计和高保交互设计图，确保设计与实现一致和优化
• 给开发团队澄清需求，支持迭代开发
• 负责业务建模、技术架构方案设计，测试策略、梳理技术性故事，管理技术债务；
• 推进单元测试、代码评审、持续集成和自动化部署等工程实践能力提升
• 参与迭代计划，演示，回顾等关键活动；
• 应用和选取技术工程实践，负责故事开发、单元测试，自动化测试、代码评审等活动构建可工作的软件；
• 立即修复持续集成发现的问题；
• 参与迭代计划，评审，回顾等关键活动
• 编写用户故事测试案例（以GWT格式: Given、When、Then）；
• 负责迭代开发过程中的各个故事的测试，迭代增量的集成测试和回归测试；
• 自动化测试用例的编写和维护
• 搭建和维护适合团队的CI（Continuous Integration）系统，实现自动部署流水线；

除了敏捷团队角色分工，促进团队协作还需要建立Team Contract。团队规范制度是团队成员聚集在一起，为了达成共同目标追求而产生的，它是用语言、非语言的沟通 规则来影响团队成员行为。通常从团队的工作规范、DoD、团队纪律协作章程（Ground Rule）几个方面建立团队契约。

敏捷谚语：CI 红灯不过夜

协作纪律包括提交纪律、移卡纪律、集成规范、站会纪律、DC（Desk Check）时间、远程协作纪律等。

那么团队协作中会遇到哪些挑战呢？

如果把团队交付比喻为一场4*100的接力赛，那么团队胜出的关键就在于交接棒的技术。这也是我们发现协作有序最大的障碍在于上下游的接力棒交接不畅，出现信息的不对称和信息空隙。而这些是混乱、脱节、甚至造成团队犯错的根源，但常会有相当一部分人意识不到这是一个问题。

《赋能-打造应对不确定性的敏捷团队》作者在第七章中也指出信息空隙是无效组织的根源。要打造应对不确定性的敏捷团队，需要打破信息壁垒，连接上下游信息断点，建立共享意识和文化，获得更大的团队协同效应。

2.3 新人融入闭环（能力提升）

Onboard的流程是以终为始的拉动式学习，旨在帮助团队新人刻意练习来完成快速上岗。通常，TL 或者 Senior Dev 需要为 团队新人的On Boarding 准备材料，其中主要包含业务背景介绍、架构设计、测试策略、用户故事和上岗的胜任要求。准备好相关材料后，安排一位Buddy 对新人进行 On Boarding和有结构的学习，完成第一个用户故事的编写，并通过上岗胜任练习后，即可融入团队开发节奏。

总结

有序的流程和团队协作是团队进入规范期重要标志。规模大、节奏快的交付团队，越要需要可以有序稳定的”部队作战“。小且目标行动一致，并且能够将业务价值、迭代协作、新人Onboard多个价值流闭环从无序到有序快速打通的团队，是在当下时间紧压力下应对不确定性的最好策略。越乱越忙反而越需要这样坚守正确的实践、原则和价值观才能致胜。其它的任何形式都只可能是一地鸡毛。

当下一个迭代开始的时候，你的团队应该已经可以做到规范且行动有序了。那么，恭喜你，开启团队发展的下一个阶段！

---

文 / Thoughtworks 禚娴静
原文链接：如何高效管理一支开发团队（上）