您的团队是王者还是青铜者？，TechLead强哥和PO小楠对视一眼，一起按下了地球系统释放的回车键。随着APP和Web系统用户登录的叮咚声，地球系统正式上线成功。会议室里再次响起团队的掌声和欢呼声。那是我职业生涯中为数不多的辉煌时刻之一，我至今仍记忆犹新。在我们的每一个职业生涯中，我们总是希望能够加入一个优秀的团队，共同经历这样一段美好的时光，项目的成功也会随之成长。而当我成为领队后，我也希望自己能够带领这样一支优秀的队伍，乘风破浪，创造这样的高光时刻。那么，如何实现呢？作为团队的新领导者，您可以从以下五个问题入手，为您的团队把脉。问题1：团队目标和可交付成果是什么，团队成员是否了解这些目标并达成一致？如果没有目标，那么任何风向都是逆风；——摘自网络明确的目标会指引团队工作的方向，就像没有指南针的航海一样，再大的船也需要有明确的航行目标和方向，再强大的船队也要前行出海也需要在前进的方向和如何应对障碍上有一致的共识。没有目标和共识，团队不仅会偏离开车的目标，还会在没完没了的任务中手忙脚乱、犹豫不决、不知所措，最后灰溜溜地离开赛场。作为团队领导者，首要任务就是从纷繁复杂的信息中理清目标，清晰地传达给团队中的每一个人。如果一个Leader只做一件事，我觉得就是设定清晰明确的目标，让目标在团队中达成共识。然而，能做到这一点的球队并不多。我观察到的最常见的问题不是有没有，而是新的Leader如何不自觉地忽略了这个动作，只把我们要完成的任务交给了。很多团队的开发人员在写代码的时候并不知道本次迭代的交付优先级和业务价值是常态。敏捷谚语：“默认情况下，所有故事都是无效需求，除非它有明确的价值。”团队成员作为执行个体，并不知道目标和价值观，只能根据自己的理解，尽可能优化执行过程和结果。这往往会导致：重复执行计划的浪费，追求任务本身的优化和细节的完美，导致意想不到的开发过程蔓延或结果与目标不符的偏差，甚至导致到项目延迟交付、成本摊薄、目标偏差等问题。这样一个心理学家的实验（摘自网络）：心理学家组织了三组人，让他们分别前往10公里外的三个村庄。第一组的人既不知道村名，也不知道距离多远，只被告知要跟着向导走。刚走两三公里，就有人抱怨；说到一半，有些人都快怒了。他们抱怨为什么要走这么远，什么时候才能到达终点。有些人甚至坐在路边不肯走；，他们越沮丧。第二组的人知道村名和距离，但路边没有路标，只能凭经验估算行程时间和距离。走到一半的时候，大多数人都想知道自己走了多远，更有经验的人说，“大概走了一半吧。”于是，众人挤在一起，继续往前走。当我们走到四分之三的时候，大家都开始感到压抑和疲惫，路途似乎很漫长。当有人说：“快了！快了！”大家精神一振，加快了前进的步伐。第三组的人不仅知道村名和距离，而且在路边每公里都有一个里程碑。人们边走边看里程碑，每缩短一公里，每个人都会有一阵小小的幸福。行军中，他们用歌声和笑声消除疲劳，情绪总是高涨，很快就到达了目的地。这个心理学实验表明，当人的行动有了明确的目标，并能不断地把自己的行动与目标进行比较，进而清楚地知道自己的速度与目标之间的距离时，人行动的动机就会提高。如果保持和加强，就会自觉地克服一切困难，努力达到目标。以上实验向我们证明了进球对于球队的重要性。在敏捷团队中，当产品需求不明确，价值交付是唯一途径时，更需要有清晰的目标和价值主张。只有这样，才能引导团队用“足够简单”的设计，“敏捷地”向客户交付可工作的软件，并尽快验证价值，获得反馈。同时，当一个清晰可见的目标在团队中时，它也会成为激励团队的原动力，甚至让团队焕然一新，创造奇迹。有时候目标不在于它有多么高尚，而在于团队是否清楚它，它的威力甚至超乎你的想象。那么，项目的目标是什么？项目画布（ProjectCanvas）包括项目目标/愿景/MoS/价值主张工作说明书（SOW-StatementofWork）中的交付承诺服务框架协议（MSA-MasterServiceAgreement）中定义的客户信息安全要求和策略)项目交付周期和关键交付里程碑如何让大家看到和共享？首先，搭建一个信息辐射器，比如利用物理墙、拼图电子墙、团队会议模板等视觉渠道来传达项目的关键目标。其次，使用下面的问题列表来帮助你将目标维护和强化融入到你的日常工作中：是否在Onboarding时向新人介绍项目目标、关键里程碑和MVP。是否在入职期间向新人介绍交付承诺、实施计划和优先事项。是否有阶段性的组织项目更新，及时交付和更新变更，始终保持团队在目标上的同一频率。是否在迭代计划会议（IPM-IterationPlanningMeeting）中向团队明确说明本次迭代的目标和优先级，以及原因，确保团队同归于尽。Retro时是否回顾本次迭代的目标和完成情况。目标和进度是否足够可视化，以便团队可以看到并找到它们。每个人是否清楚自己的职责和任务，是否清楚与目标的关系。孙子说：志同道合者胜。“当一个人知道自己想要什么的时候，全世界都会为他让路。”团队也是如此。如果团队成员没有共同商定的目标或对目标缺乏清晰的认识，就会影响集体决策和协调行动，损害团队和团队的经营成果。然而，团队领导者不了解目标的力量，可能会耗尽自己并拖累团队。因此，团队的新领导者需要善用目标管理，明确项目目标，坚信这个目标的意义和价值，竭尽全力始终保持团队对目标的共识，让每一位成员团队的成员知道他们在做什么以及他们在做什么。如何一起完成任务。这也决定了球队在困难来临时是否有乘风破浪的勇气和动力，也是球队成为王者的前提。当开始一个新团队时，前四次迭代是你做好目标构建的最佳时机。问题二：团队成员能否及时获得完成开发任务所需的信息？（来源：https://www.sohu.com/a/203790693_187697）《技控革命(从培训管理到绩效改进)》一书中引用了ThomasGilbert的绩效行为工程模型，指出环境因素占组织绩效的75%。信息因素占环境因素的35%，包括：是否清晰明确地告知做好工作的标准和期望，是否能够获得做好工作的各种信息，并能及时、清晰地获得对他们工作的反馈。对于从事敏捷软件开发的知识工作者来说，更重要的是获得及时的信息输入并达成共识——包括业务价值、技术方案、验收标准和反馈——以完成任务。因为这些决定了他/她将使用什么方法和多少来交付什么价值的工作软件。敏捷谚语：“再多的详细文档也无法替代个体和交互。”如果不能及时获得这些信息和共识，就会出现以下问题：大家在估算IPM时，理解不一，无法达成共识，最后仓促行事。有时候一个开发了很久的用户故事，在沟通中突然发现根本不是客户想要的，只能重做。用户故事中没有DoD（DefinitionofDone），没有技术方案，没有界面设计，经常中途发现需要推倒重来。代码写的差不多了，发现字段命名不符合规范，联调失败，只好返工。花了四天时间终于把模型和复杂的逻辑搞定了，突然发现其他同事已经搞定了。同一个bug经常会重现，修改一个bug可能会引起新的bug。每个人都有不同的看法，有时我会忘记当时的决定是什么。......那么，当我们进入迭代开发时，需要哪些信息和共识？什么时候？迭代过程也是团队对交付工件逐渐达成共识的过程。需要保证迭代窗口内需求和计划清晰，团队才能快速完成并持续验证。在迭代开始时，PO和团队TL/PM/BA需要就交付范围的优先级达成一致，而开发团队需要就本次迭代开发的工作内容达成一致，DoD的要求（完成标准），以及如何实现（接口设计、系统处理的多集成设计、组件结构、复杂流程处理和组件、逻辑数据库设计、测试策略、编码规范等）获得一致的理解，从而为本次迭代的目标冲刺。作为团队的领导者，他需要确保及时将上述任务信息提供给团队，以最大化团队绩效。好消息是Scrum、XP和精益工程实践帮助我们定义了清晰的迭代结构和信息流。你需要的是合理地跟随他们，发挥他们在团队信息和共识中的价值。问题三：团队能否有序开展价值交付活动？（来源：https://unsplash.com/photos/M3cxjDNiLlQ）随着疫情时代的到来，我们看到不确定性将是最大的确定性。对于交付团队来说，挑战不仅是需求的不确定性，还有客户从成本效率到速度和快速适应变化的需求。对于团队来说，意味着一切都可能发生变化，时间紧迫和压力将成为常态。接下来我们就来说说在这样的常态下，团队是如何从忙碌走向有序的。1969年，塔克曼先生在他的文章《小型团队的发展序列》中指出，团队发展有五个阶段：形成、风暴、规范、执行和休会。这五个阶段在团队的发展过程中是必须的，也是不可逾越的。在如今的挑战下，留给球队从组建到高效的时间已经不多了。一个优秀的团队，体现在能否从忙碌的编队迅速进入到规范有序的状态。项目时间越紧，压力越大，越需要有经验的Leader站出来，积极构建团队契约、流程机制、视觉价值板、知识共享等，从混乱到有序，这种适应性和文化会也是未来团队成功的关键。1.为什么顺序如此重要？组织混乱会导致效率低下、士气低落、重复管理甚至错位管理。混乱持续的时间越长，团队就会变得越糟、精疲力竭和可预测。新手领导容易出现的误区是对敏捷和精益工程实践缺乏了解，缺乏系统思维，缺乏有效措施，往往导致管理越做越乱，看不到有效的价值效益。团队紊乱的一系列特征可能包括：每个人似乎都有无穷无尽的事情要做任务总是在变化，团队成员的安排总是在变化，随意且不合逻辑，一切以进度为导向，进度缓慢，出现救援结果是管理变得越来越混乱。系统的负面反馈总是被动地应对变化，并立即被迫做出有偏见的决策作为回应。成员不知道谁负责什么。invovle，好像他有责任，又好像她的成员不清楚决策过程和沟通机制，看到问题也无力解决。IPM目前还没有了解业务和计划，也没有明确的验收标准。赶快返工吧。开发中途差异频繁重现，等不及后端。这些卡片有点复杂。我也一起做bug。似乎人越来越多，人山人海。我觉得我无法完成它。中间反复共识，随便做个决定再随便推翻，不知道找谁，等等，浪费2.顺序怎么理解？秩序是指系统结构或物质运动是确定的、有规律的。秩序是事物的结构形式，是指事物或系统的要素之间的相互关系。秩序是动态的、不断变化的秩序。当一个事物的组成要素受到一定的约束并呈现出一定的规律时，就称这个事物或系统是有序的。人们通过认识客观世界，认识各种事物、对象的构成要素、相互关系、结构功能及其发展演变规律，即事物的秩序，从而促进事物由无序向有序的不断转变。“秩序是一种动态的变化，随着新事物和构成要素的变化，秩序可能会向无序转变，也可能导致从秩序向更高能力的有序转变。那么，在敏捷团队价值交付的背景下，订单意味着什么？在我看来，敏捷交付活动的顺序代表了以下三个有序的活动闭环：价值验证的闭环，生产环境中从idea提出到客户接受的价值流是否有序。围绕迭代的闭环团队协作，迭代规划、迭代启动、Story开平、Showcase、Retro等活动中的任务分工和人员协作是否井然有序，知道遇到问题联系谁，什么时候站出来，以及何时代码审查，如何决策，代码规范有序可靠。新人融入闭环（能力提升闭环），新人在参与快节奏交付之前，可以有清晰的整合步骤，快速成为胜任者。2.1什么是闭环价值流？我们需要明确一点，敏捷团队要交付的是产品的最大价值，而不是功能最多的点。团队希望通过需求的快速流向线上发布，将客户最初的想法转化为可工作的软件产品，从而为客户的最初想法提供反馈和价值验证的闭环——产品价值是指开发出来的产品或服务终端用户的价值是用户购买或使用产品的首要因素，也是企业盈利的本质。团队可以根据产品和客户需求组织设计流程和任务，确定上下游关系，并按时间顺序排列，形成产品的价值流图。价值流图对团队有什么样的启发？(1)关注价值成果（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团队的ScrumMaster、ProductOwner、ScrumTeam这三个角色来描述团队的相关职责。在不同的项目中，角色职责通常会根据具体的交付任务和团队情况进行调整，例如增加面向产品的Feature开发团队和FeatureOwner，推动每日站会的主持人，以及负责人迭代交付IM等ScrumMaster，通常为PM或IM，负责：组织团队按照敏捷流程规范高效运作，促进内外部沟通与协作；管理进度和风险，协调解决敏捷运营过程中的各种障碍，推动持续改进。ProductOwner：负责产品业务设计、需求提出、验收、运营分析和产品改进；建立产品Backlog，确定优先级；与BA密切沟通，明确业务需求；ScrumTeam：作为PO与开发团队之间的沟通桥梁，协助PO分析需求并确定优先级编写和拆分用户故事（包括验收条件AC），维护产品Backlog；交互体验设计和高质量的交互设计图，保证设计和实现的一致性和优化向开发团队明确需求，支持迭代开发负责业务建模，技术架构方案设计，测试策略，梳理技术故事，管理技术债务;提升单元测试、代码评审、持续集成、自动化部署等工程实践能力，参与迭代规划、论证、评审等关键活动；应用和选择技术工程实践，负责故事开发、单元测试、自动化测试、代码审查和其他活动以构建可工作的软件；立即修复持续集成发现的问题；参与迭代计划、评审、评审等关键活动，编写用户故事测试用例（GWT格式：Given,When,Then）；负责测试迭代开发过程中的各个故事，迭代增量集成测试和回归测试；编写和维护自动化测试用例，构建和维护适合团队的CI（持续集成）系统，实现自动化部署流水线；除了敏捷团队的角色分工，促进团队协作还需要建立TeamContract。当团队成员聚集在一起以实现共同目标时，就会创建团队规范系统。它使用语言和非语言的交流规则来影响团队成员的行为。团队契约通常从团队的工作规范、DoD、团队纪律合作章程（GroundRule）等几个方面来确立。敏捷谚语：CI红灯不留夜协作纪律包括提交纪律、换卡纪律、集成规范、站立会议纪律、DC（DeskCheck）时间、远程协作纪律等。那么团队合作中有哪些挑战呢？如果把团队接力比作4*100的接力赛，那么团队成功与否的关键就在于接力棒的技巧。这也是我们发现，有序协作的最大障碍在于上下游接力棒交接不畅，造成信息不对称和信息鸿沟。虽然这些都是混乱、脱节甚至团队错误的根源，但通常有很大一部分人没有意识到这是一个问题。《赋能-打造应对不确定性的敏捷团队》作者在第七章也指出信息鸿沟是无效组织的根源。打造应对不确定性的敏捷团队，需要打破信息壁垒，打通上下游信息断点，建立共享意识和文化，获得更大的团队协同效应。2.3新人融入Onboard的闭环（能力提升）过程是端到端的拉动式学习，旨在帮助新人刻意练习，完成快速入职。通常，TL或SeniorDev需要为团队新人OnBoarding准备材料，主要包括业务背景介绍、架构设计、测试策略、用户故事和入职能力要求等。准备好相关材料后，安排Buddy对新人进行OnBoarding和结构化学习，完成第一个用户故事的编写，通过入职能力练习，然后融入团队发展的节奏。总结有序的流程和团队合作是团队进入规范期的重要标志。一个规模大、节奏快的交付团队，需要更加有序、稳定的“部队作战”。一个目标和行动一致的小团队，能够快速连接业务价值、迭代协作、新人Onboard的多个价值流从无序到有序，是当前时间压力下应对不确定性的最佳策略。越乱越忙，越需要坚持正确的做法、原则和价值观，才能取胜。任何其他形式都只能是地面上的羽毛。到下一次迭代开始时，您的团队应该已经受到纪律和组织。那么，恭喜，进入团队发展的下一阶段！原文链接：你的队伍是王还是铜（上）（qq.com）
