敏捷项目管理实战第二天量体、裁衣和启动

本文链接：https://blog.csdn.net/fegus/article/details/124836165

03 量体：如何判断是否适合做敏捷转型？

在上一课时，我们学习了敏捷宣言建立了敏捷思维，有了这些理论作基石，接下来便需要学以致用。那到底我们的团队或项目适不适合引入敏捷呢？想要弄清楚这个问题我们就得先弄清楚什么是项目的生命周期。

我们知道 VUCA 时代的特点是不确定性，敏捷是用来应对不确定性的方法，而今天要讲的项目生命周期则是衡量这种不确定性的指标。

项目的生命周期

项目的生命周期是来描述项目从概念到完成的整个过程。整个项目生命周期包括五个过程组。

启动过程组：是一个包含了获得授权，并定义一个新项目或现有项目的一个新阶段，然后正式开始该项目或阶段的过程。比如，我们在开始做斗地主第一个手游版本之前，会先论证市场、竞品和用户商业模式，然后形成结论之后输出项目章程。在这个过程中，我们投入的资源会比较少，只有制作人、产品负责人和项目经理，以及几位研发领导；
规划过程组：是通过明确项目范围和优化目标，为实现目标而制定行动方案的一组过程，使团队工作能够有序发展。比如通常我们的项目会分成四个阶段计划：Demo 阶段、基本功能实现、灰度发布和正式发布，每个阶段都有其范围、资源投入情况等；
执行过程组：是通过完成项目管理计划中确定的工作以实现项目目标的一组过程。在这个过程里，我们主要需要关注的是信息沟通和项目进展；
监控过程组：是指通过跟踪、审查和调整项目进展与绩效，以识别必要的计划变更并启动相应变更的一组过程，使得项目朝目标方向进展。这个过程我们主要控制四个方面：范围变更、质量控制、状态报告及风险应对；
收尾过程组：是指为完结所有过程组的所有活动以正式结束项目或阶段而实施的一组过程。这个过程组的主要价值是可以总结项目过程中得到的教训，并对此持续改进，帮助我们在今后的项目中完成得更好。

到这里我们就清楚了什么是项目生命周期，但是在实际的工作中，我们遇到的项目多样，需求情况是不同的，所以人们根据不同项目的特点对它们进行了归纳，总结出了四种项目生命周期：预测型、迭代型、增量型、敏捷型。我们可以根据自身项目的特点来选择合适的类型，帮助我们更好地推进，也就是说我们可以以此来判断项目是否适合敏捷方法。那么，我们先来看一下这四种项目生命周期的具体内容。

预测型生命周期

首先是预测型生命周期，通常我们所说的项目生命周期其实就是指预测型生命周期。

预测型生命周期是以分析、设计、构建、测试和交付为顺序的方式执行的，这要求我们制定详细的计划，什么时候启动项目，什么时候结束项目。在此过程中，我们尽量限制变更，以至于我们需要成立变更委员会这样复杂的机构来处理每一次变更的审批。因为这样项目尽可能地减少了处理变更带来的成本，有利于最小成本地交付产品。

在项目刚开始制定计划时，团队必须考虑到各种项目制约因素，并将这些制约因素加入风险和成本计划当中。这样当我们在执行计划时，可以严格控制对这些计划的影响，尽量少让项目产生变更。

因为预测型项目强调顺序执行，所以通常不会在项目过程中交付产品或服务，这样会产生一个较大的风险，就是一旦对客户需求理解不够，或对需求产生了分歧，那么前面做的很多工作将付之一炬。

迭代型的生命周期

其次是迭代型的生命周期，早期的互联网项目大多属于迭代型生命周期。它在项目过程当中就会产生交付，我们可以在过程中获得反馈，然后收集这些反馈进行归纳、提炼，随后形成新的需求，再把这些需求放在下一个迭代版本中完成。这样我们就可以通过原型验证或概念验证的方式来帮助我们改进工作成果。这样做的好处是可以减少项目的不确定性。

迭代型的生命周期整个过程包括需求分析、分析设计、构建测试和价值交付，它的特点集中在中间的分析设计和构建测试的过程中，此时我们需要不断快速打磨以完善我们的产品。这样就能通过快速迭代来尽早修复问题，而且修复成本就会变得更小。

如果项目中需求频繁发生变化，或者我们认为客户的需求不是很确定时，就适合采用迭代型生命周期，因为迭代型生命周期更关注构建原型和优化改善，而不是为了提高交付速度。

增量型生命周期

接下来就是增量型生命周期，它可以向客户提供完成的交付成果，让客户能够立即使用。许多企业或客户更愿意团队在项目过程中交付，而不必等到所有需求全部完成。当我们交付一部分解决方案时，客户就已经能够使用了，我们把这种少量交付成果的生命周期称之为增量型生命周期。

项目团队在开始之前就会计划好每一次我们要交付的成果，在开始之后他们会尽快完成第一次交付任务，在实际的工作中，有可能第一次交付时间为一周，第二次交付时间为两周或三周不等。

随着项目的继续，团队可能会发现，最终交付的成果可能与刚开始计划的有较大偏差。但是团队不必在意这个结果，因为我们更重视更快交付价值来收集的用户反馈，相比如期完成计划内的需求，我们更看重客户对于交付成果的看法和交付价值。所以，只要结果是为客户创造了价值，我们就不必太在意最初计划的需求是否被全部完成。

敏捷型生命周期

最后我们来看敏捷型生命周期，它同时有着迭代和增量的属性，但是注入了敏捷的基因，所以是符合敏捷宣⾔的一种生命周期，它能够更好地应对更频繁的变更和交付项⽬价值。具体来说，它在迭代型的基础上增加了增量型对用户价值的分析，也就是说客户满意度将随着有价值产品的早期交付和持续交付不断提升。

所以在这种类型的生命周期中，我们会对产品进行增量交付，有节奏地迭代交付成果，这样客户能够在固定的周期看到我们的交付成果，并进行反馈，这会让我们团队对是否能满足客户所需变得更有信心，项目也能尽快得到回报。

生命周期特性对比

根据项目生命周期的类型，我们就可以来考量是否适合敏捷。我先来帮你区分开它们。在你开始一项项目的时候，我们首先要明确项目的需求、执行方式、交付方式和最终目标这些内容，如果需求非常的明确，也就是说客户的需求在项目之初已经确定，并且不会随着项目的进行而改变，那么此时我们就可以确定，项目采用预测型生命周期来推进。

但是如果我们的项目需求是动态的，而且这个需求比较复杂并且充满了不确定性，需要内部在不断完善中来达成最终的交付，那么此时我们就要选择迭代型生命周期。

如果我们的客户想要根据部分成果来调整最初的需求，也就是说在整个推进过程中要注重客户的反馈，那么此时我们就要选择增量型生命周期。

但在现实生活中，情况往往不是这么简单，我们可能需要在频繁迭代的时候，考虑到客户的反馈，那么此时我们就要选择敏捷型生命周期，这里请你注意，因为敏捷型生命周期注重频繁的交付，所以对团队的要求很高，但是如果遇到大型项目，这样就会很吃力而且不太实际，而增量型生命周期是在固定的周期完成部分交付，就会更加适合。

敏捷方法看重的就是交付成果，所以结合上述分析，我们可以知道，当你的工作场景是预测型和迭代型时，那么你完全没有必要采用敏捷方法；当你的工作场景是增量型和敏捷型时，你就可以部分或全部转型敏捷。这里部分和全部具体指什么呢，在下节课中我将为你讲解。

这里我为你列出了一张表格，从项目需求、执行方式、交付方式和最终目标这四个维度进行对比，而且我列出了应对场景作为参考。要注意的是，每个生命周期所对应的场景都是不同的，不要拿着锤子找钉子，敏捷不是解决一切问题的万金油，所有的情况存在即合理。我们要根据不同的团队、不同的场景，来选择合适的生命周期的方法。

总结

好了，本课时的内容就讲完了，我们学习了项目生命周期，可以从项目需求、执行方式、交付方式和最终目标这几个维度出发确定类型，这样就可以判断是否适合敏捷。那么下一课时，我将为你讲解如何依据我们的实际情况导入敏捷。如果你学习完本节课有什么问题，欢迎你在留言区留言与我一起讨论，我们下一课时见。

04 裁衣：如何使敏捷方法适合公司实情？

在上一课时，我们主要学习了项目生命周期，以及它是如何帮助我们判断当下是否适合敏捷转型。今天，我们将在上一课时的基础上讲解如何做裁剪敏捷方法，使其适应公司的实际情况。

敏捷实践方式：基于迭代和基于流程

首先，我们来了解两种敏捷实践方式：基于流程的敏捷和基于迭代的敏捷。

基于流程的敏捷实践

罗马不是一天建成的，导入敏捷当然也不可能一蹴而就，我们需要一步一个脚印踏踏实实地推进，这个过程中我们逐渐改变自己原有的思维和做事模式，就是从适应到逐渐熟练应用的过程，而基于流程的敏捷就包括这个适应阶段。

具体来说基于流程的敏捷，就是建立在流程基础上的敏捷实践，项目开始时，团队会以客户价值为优先级，从待办事项列表中提取优先级高的若干个功能开始开发。它最大的特点是：每次迭代必须要把所有的功能做完。在这种实践中，团队需要评估本次迭代的总工作量，因为每次选取的功能不尽相同，而总工作量也不同，那么每次的迭代时间也不同。如果这样的项目需要频繁交付的话，我们就只能在每次迭代前，尽可能地选择较少的功能进行开发。不仅如此，如果在迭代过程当中一旦出现变更，变更的工作量也会加到总工作量里，迭代的时间也会相应延长。所以团队要做出适当的进度计划，不能因加入功能过多而拉长了迭代的时间，让项目失去了灵活性。

基于迭代的敏捷实践

我们再来看基于迭代的敏捷实践，在项目开始时，与基于流程的敏捷一样，团队会以客户价值为优先级，从待办事项列表中提取优先级高的若干个功能开始开发。它的最大特点是：每次迭代的结束是严格被时间框死的，也就是说，针对团队的迭代，我们要根据团队的能力，给定一个固定的可用时间。敏捷中把这种严格的时间节点称之为时间盒。我们要在时间周期内交付完整的功能，这就要求我们把需求相对独立地分开，并且严格按照价值排序，因为这样我们便可以灵活应对变更，一旦变更发生并插入当前的排序中，我们就可以把优先级低的需求从迭代中剔除，以保证固定的迭代周期。这样做的好处是，无论何时，团队当前迭代做的一定是最有价值的功能。

总结：两种方式的区别

这两种方式最大的区别在于，基于迭代的敏捷就是我们平时所说的典型的敏捷开发，它规定了明确的交付时间，也就是交付时间是固定不变的。就像坐高铁一样，错过了时间就只能改签到下一列，这个发版日期交付不了就只能等到下一个发版日期。而基于流程的敏捷，它的范围是固定的，也就是说每次必须完成预定的功能才能交付。

比如腾讯的欢乐斗地主项目，前期研发时还没有正式发版面世，这时我们更注重功能的完成度，所以会采用基于流程的敏捷实践方式，当我们完成主要的玩法功能之后才会开始下一轮迭代。这样做的好处是，可以保证在每一次的迭代之后游戏的主要玩法都是比较完整的。当它上线以后我们要开始注重运营，所以此时我们采用了基于迭代的敏捷方法，因为这样可以定期让用户看到游戏的更新，和玩家建立起反馈的节奏，更加有利于我们产品的稳定。

而在实际开发中，并不是每个项目都很标准地适用我们前面讲过的某一类敏捷，这时就会涉及混合型的敏捷开发方式。

裁剪：混合敏捷实践

实际工作场景是非常复杂的，每个项目都有其独特的背景。比如团队成员的专业能力和技术背景、工作环境、团队规模，以及客户规模、客户背景和客户需求等很多因素都不一样，面对如此复杂的情况，我们就不太可能用单一的敏捷方法“一招鲜，吃遍天”，所以我们需要“量体裁衣”。具体来说，我们可以结合之前所说的两种敏捷实践方式，组合出适合团队的方案，这种行为就是“裁剪”，我们也叫这种实践方式为混合敏捷实践。

我们应该如何裁剪呢？对于不同的团队来说，我们需要从问题切入，选中一种方法先解决团队问题。这里我就要提醒你，敏捷是帮助我们解决问题的，所以千万不要为了敏捷而敏捷，只有能够解决团队的问题时，我们才要导入敏捷。

这里我还想再跟你着重说一下裁剪，它不仅仅针对敏捷实践方式，其实对于敏捷方法来说也是一样，我们要针对团队问题灵活运用敏捷方法，也就是具体问题具体分析，对症下药，比如：

Scrum 为 PO（Product Owner）、SM（Scrum Master）以及 Team（跨职能团队）的使⽤提供指导，包括 Sprint 计划、每⽇晨会、Sprint Review 和回顾会议。
看板帮助团队进⼀步提⾼效率，⽅法是将⼯作流可视化，使项目瓶颈更容易被察觉，以及通过调整 WIP（在制品限制）来实现流程管理。
极限编程 XP，运用⼯程实践如使⽤用户故事卡片、持续集成、重构、⾃动化测试和 TDD（测试驱动开发），针对开发过程可以提高开发效率。

总之，与孤⽴地采⽤一种实践相⽐，用不同的实践来解决当前的问题会更有针对性，能取得更好的成果。但是这种方法也要避免“滥用”，我们应该以问题为切入点，有针对性地使用敏捷方法帮团队解决问题，而不是一开始就直接应用所有的敏捷方法，这种很容易让敏捷“形式化”，而且在实际推行中团队会比较反感，这就容易导致失败。

针对适用场景裁剪

了解了这种裁剪方式以后，你可能会问了那具体怎么用呢？我们可以根据适用的场景来进行裁剪，主要就是这两种场景：预测为主敏捷为辅和敏捷为主预测为辅。

首先看预测为主敏捷为辅的。比如京东拼购，和所有电商平台一样，它内部具有首页、分类页、详情页、下单页、支付页和结算页等标准页面，我们在做基础功能的时候就可以先把这些页面做出来，这部分页面已经很成熟了，不需要用户再去验证了，所以京东拼购只需要在它的特色功能“拼购”和“分享”上下功夫，用这些页面去试错就行了。这就是典型的预测为主敏捷为辅。

再来看看敏捷为主预测为辅的案例，这种模型主要用在一些需要集成组件的工作环境中。比如腾讯广告的推荐算法，它是一套成熟的推荐体系，通常会嵌入到各种浏览器、新闻、小视频、游戏等平台中，对算法本身来说，它的功能需求和框架是可预测性的，但是集成之后，需要根据具体业务场景用敏捷的方式不断优化。

马斯克 SpaceX 火箭就是采用敏捷为主预测为辅的场景。研发火箭的组件时主要是预测型，但每次新的组件进行组合时，谁都不能保证新的组件用来这次火箭发射任务一定不会失败，所以这就是一次新的试错过程。

实战案例

清楚了主要的敏捷实践方式，接下来我就结合具体的场景和案例来帮助你理解。

如果你的团队是人数比较多的大型团队，那么我们需要把大团队拆分成小型团队，然后利用敏捷方法进行同步和协调，缩小团队的好处是降低沟通成本。腾讯就是通过组织拆分的方式，实现了大团队向小团队的裂解，这样有利于团队间采取“高内聚，低耦合”的工作方式，具体来说，高内聚就是小团队内部间通过频繁的沟通来达成共识，低耦合是指减少大团队间的沟通，这会降低沟通成本而提高沟通效率，腾讯正是这样来进行大型产品的快速研发。

例如微信团队，根据功能把整个团队分成了各个子模块：微信支付、社交、朋友圈、微信开放平台、微信公众平台和游戏中心等，然后这些团队使用了敏捷迭代来保证团队成员间步调相同，以此避免出现我快你慢、我等你赶的尴尬局面。具体的做法我会在之后的课时里为你详细介绍，这里你只要先记住小型团队更加有优势就好了。

如果你的团队分布在各地，那就可以借助即时通信工具、视频会议和看板来确保通信流畅。面对面交流时更容易建立信任感，提高沟通质量。所以我们应该尽早建立面对面会议让团队彼此熟悉，这样有助于提高后期远程会议的效率。在远程会议当中，因为缺乏面部表情和身体的语言交流，我们可以以点名的方式确定沟通信息是否被对方接收。如果团队有新成员加入，我们需要在会议开始之前，让新成员做自我介绍，增加团队对他的了解。此外，我们可以考虑使用基于迭代的敏捷实践，因为它有固定的迭代周期，所以可以帮助异地团队建立起共同的开发节奏。如果团队成员所在时区差别较大，我们可以取消每天固定时间的晨会，鼓励开展更多更频繁的小型专项会议，最好是时区差别不大的成员参加。

例如腾讯的欢乐升级团队，他们的前端团队在大连，但是后端团队在深圳，在项目成立初期，大连的同事来到深圳办公一周，相互见面熟悉彼此的工作方式，当项目立项和项目计划阶段完成之后，再恢复两地办公，通过视频会议每天进行晨会跟进信息，这样异地团队办公效率也能得到保障。

如果你的团队面对的是经常要应对第三方机构检查的项目，我们仍然可以使用敏捷方法，但需要注意的是，在过程中要花时间准备应对合规性审查、建立文档和准备认证。在这种情况下，文档可能需要和已完成的功能一起交付，只有文档完成后迭代才算完成。此时我们就可以使用混合型敏捷实践，从敏捷所带来的协作和改善沟通中获得益处。

例如，微信支付这种需要国家金融权威机构监管的项目，在内部快速交付价值的同时还需要准备合规性审查文档，并记录项目关键信息以应对合规性审核。

如果你的团队是职能型组织内的职能孤岛项目，也就是说无法与其他部门进行有效沟通，这样就难以形成合力，此时我们应该打破职能孤岛，创建敏捷环境。比如腾讯游戏部门，基本打破了职能组织。游戏工作室制作人为游戏全权负责，组织运营、产品、研发团队共同为项目出力，个人绩效变成了奖金包体现在年终奖当中，而奖金的多少很大程度上取决于业务是否挣钱，这样大家才会形成合力，出色完成项目目标。

敏捷是一套自上而下的方法，落地时必须得到领导的支持，但有的领导可能只是简单地了解了敏捷的好处，没有接受专业的指导就让团队自己摸索并实施，反而会让大家感觉敏捷一些实践环节的增加（如每日晨会），成了团队多出来的负担，这时需要引入专业敏捷教练，帮助大家理解实施敏捷的真正目的。

为了避免团队成员对敏捷转型有所抵制，我们可以先解决团队面临的问题，在总结回顾会议上，告诉团队问题解决完之后产生的效果。当团队认可效果之后，我们再告诉团队是采用了哪些敏捷实践，让大家逐渐接受并认可敏捷方法。

总结

本课时的内容就讲完了，这节课时我们主要学习了要循序渐进地导入敏捷，以及如何根据实际情况对敏捷进行裁剪，让其更适合公司。下一课时我们将要学习怎样拥有敏捷思维。如果你学习完本节课有什么问题，欢迎你在留言区留言与我一起讨论，我们下一课时见。

05 启动：如何拥有敏捷思维？

在上一课时，我们主要学习了需要根据项目的实际情况对敏捷进行一定的裁剪，并分享了一些具体的案例，今天我们开始向团队导入敏捷。

想要向团队导入敏捷，除了掌握敏捷思维外还应该明确其特点。在当下 UVCA 时代，敏捷思维特点可以用三个词来概括：

快速，雷厉风行，只有跑得比别人快才能保持优势；
高效，只有组织高效协同，才能持续交付价值；
试错，通过不断低成本试错，满足客户真正需要，才是必胜之道。

这就是敏捷思维的三个特点。我们在前面也曾讲过，敏捷实践的最终目的是在导入敏捷的过程中，帮助团队建立起敏捷思维。

转型敏捷的起点

改变思维，拥抱敏捷

首先，我们要考虑如何才能让团队敏捷起来？这就需要改变思维，让自己与时俱进，时刻都准备好接受新的事务。无论你是否是团队的领导，只要你想敏捷，那么自己必须先要形成敏捷的思维习惯，用体系化学习掌握理解它，这样才可以更好地引导团队，所以这里我就有以下建议。

保持一颗好奇心，对事物充满好奇。我们可以重新认知这个世界，对 5G、人工智能、大数据等这些新事物充满好奇，同时鼓励自己不断学习前沿技术，从不同的领域汲取知识，在这个过程中，不仅可以开拓视野、提升格局，还可以培养终身学习的习惯，时刻跟上世界的步伐。
体系化地学习敏捷知识。很多人往往通过自媒体了解到敏捷，但往往对敏捷的理解过于片面缺乏系统性，就仿佛管中窥豹，所以我建议你进行系统的学习，构建全面立体的敏捷知识体系。

有了这种改变思维的自觉性，加上理论知识的支撑，你就可以在团队中引导或者说帮助大家敏捷起来。根据我多年的经验，你可以从这三个方面来做：

换位思考，在团队里我们需要多站在他人的角度去思考问题，而不只是着眼于我们自己的想法，站在对方角度思考问题可以使沟通更加高效;
共同经历，指我们需要和团队成员一起经历工作之外的事情。比如在腾讯，一直会定期举行团建活动，比如登山或徒步，让大家在忙碌的工作之余不仅锻炼了身体还增加了彼此的认识，培养了团队默契;
建立共同的目标，我们都希望在工作中团队和自我都能够得到提升，有了这个共同目标后，在日常的工作中协作便能够更加高效，正所谓人心齐泰山移。

掌握了敏捷的体系化知识，团队能够建立共同的奋斗目标，同时每个人又都能够换位思考并对新事物充满好奇，这时你的团队就具备了养成敏捷的培养基。有了理论和认知的共识后，在具体的实践中，怎么做可以帮助我们拥有敏捷思维呢？

用敏捷思维为团队分工

树立敏捷意识，从团队分工开始。践行敏捷，就一定需要按照敏捷思维进行分工，这里我就要向你详细说说敏捷最流行的 SCRUM 方法。

在前面的课时中你已经知道了 SCRUM 是一种敏捷方法，但是我们更需要了解它的三种成员，就是在 SCRUM 中有三种角色。

PO（Product Owner）即产品负责人，一般由产品经理来担任。作为项目的第一负责人，他主要负责指导产品的方向，并对最终交付的产品负责。他需要将待办事项里的需求按客户价值进行排序，还要从客户那里获得产品反馈并告诉团队应该如何改善。产品负责人与团队开展日常合作，参加迭代计划会、每日晨会、评审会与回顾会等，并且为将要开发或交付的下一个版本设定方向。

值得注意的是在敏捷开发中，产品负责人职能最大，他可以决定版本是否达到了发版要求。腾讯的企业文化之一“一切以产品价值为依归”，正印证了这一点。

SM（Scrum Master）即敏捷教练，也被称为 Scrum 主管、团队教练或者团队促进者，一般情况下，由项目经理、研发经理或者质量经理来担任，在所有的敏捷团队中我们都需要有这个角色。敏捷教练应该具备这些能力：

敏捷专家，具备丰富的知识和实践经验，能够带领团队顺利完成敏捷转型。
障碍清除者，在敏捷实践过程中，能够帮助团队清除一些障碍，让项目如期交付。
仆人式领导，能够将领导力从命令式转向服务式，帮助团队快速成长。
变革的引领者，具有感染力，能够身先士卒，带领团队不断拥抱变化。

敏捷教练更像是一只部队的政委，不仅个人经验丰富还能够带领团队披荆斩棘，持续交付价值。

Team 即团队。敏捷中的团队通常指跨职能团队，这是敏捷实践中重要的一环。跨职能团队指打破职能界限，将团队中持续交付产品所需的所有角色，按照项目在空间上聚集在一起，大家共同负责该项目的 KPI，比如设计人员、开发人员、测试人员以及其他所需角色。跨职能团队往往能够在更短的时间，独立地交付高质量的产品，所以我们要注重建立跨职能团队。

如果把敏捷实践比作划龙舟，那么产品负责人相当于舵手，敏捷教练相当于鼓手，而团队相当于划船人。每个角色各司其职，大家认识到自己的职责所在，敏捷才能更加深入人心。

让敏捷思维在实践中成长

敏捷导入的过程中，正是敏捷思维在团队中生根发芽的关键时期，此时我们不仅要帮助大家更好地实践敏捷，而且要在行动中注重培养敏捷的自觉性，让大家既知其然又知其所以然，所以我建议你关注接下来所提到的这几个方面。

建立干净透明的环境

在敏捷实践的过程中，团队需要一个干净透明的环境，是指信息和规则要透明，因为在敏捷实践中，因为复杂的层级会造成执行效率低下，所以敏捷鼓励我们让团队自己做决定，而团队需要清楚目前的信息和规则来做判断。作为领导，就要有意地创建这种环境。

我们可以将团队尽量分成小团队来运作。这是因为小团队沟通更简单，管理成本更低。我建议你根据业务架构将团队拆分成相对独立的 10 人以下的小团队。

我们最好采用集中办公，就是指跨职能团队尽量按照项目进行组合，在物理位置上尽量坐在一起。比如在腾讯，你会看到不少团队霸占一个大的会议室作为“作战室”，他们会为了一款产品，在这个会议室中共同工作两三个月，等发布以后再各自回到自己的工位。

负责人发挥灯塔作用

专注能够提升效率，这是显而易见的，而敏捷最注重的就是效率，所以如果你是敏捷转型的负责人，你就要肩负起灯塔的责任，为大家在黑暗中指明前进的方向。

根据我的经验，我们具体可以这样做。首先进行培训和开展交流活动，一方面敏捷方向的培训可以让团队建立一致的语言，具备体系化的知识，帮助团队了解为什么要敏捷以及如何实施敏捷；另一方面针对团队专业技能，可以帮助成员提升专业知识，让整个团队更加专业。

其次是鼓励团队，庆祝团队的成功。团队在短时间内没有取得成绩的时候，我们要鼓励他们，说明这是转型正常会遇到的阵痛；取得了一些成绩之后，我们则要鼓励团队使其获得信心，让团队成员有信心承担更多的责任，并在组织中做出巨大的贡献。重要的是我们需要充分肯定团队并给予奖励。这样能创造出一种积极的氛围，我们的士气也会高昂，从而使团队效率更高。

最重要的是让团队适当“擦伤”，就是遇到一些小问题我们不要马上就给出解决方案，而让他们自己试着解决，锻炼团队独立解决问题的能力。比如，我们刚转型敏捷时，有一次团队要进行产品验收但是时间很紧，因此大家就有些质疑产品验收的必要性，我就让大家自己做决定，他们商量过后决定不做产品验收。但是后来测试人员测试了十几个开发用例后发现，提交的产品和产品经理当初的需求不一致，于是又叫来产品经理确定，最后发现是开发同学理解的问题。后来在迭代回顾会议时，大家就提出来产品验收很重要，它可以让我们不用等到最终测试就能快速发现问题，节省了大量测试时间。