04 | 团队试点（一）：让你的敏捷实践“事半功倍”

Jan 6, 2020

04 | 团队试点（一）：让你的敏捷实践“事半功倍”-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

04 | 团队试点（一）：让你的敏捷实践“事半功倍”

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长20:36大小16.51M



你好，我是宋宁。
上节课我给你讲了怎么做敏捷推进前的评估诊断，也帮你做了短期的推进计划。接下来我要用两节课时间，给你讲讲推进敏捷的第二个步骤：团队敏捷试点。
试点工作的展开可以分为试点前准备和试点推进过程两步。今天我先来讲在做团队敏捷试点前，你需要做哪些准备，试点推进过程我在下一节课会再做详细讲解。
说到这里你可能要问了：直接给公司所有团队都直接导入敏捷不就得了，为什么还要费精力先搞个敏捷试点？
这是因为，敏捷实践毕竟属于一场变革，与其它所有变革一样，都需要先从局部试点试水，只有在试点中积累了切实的经验教训，确定了可行性后，才能去大规模推广。如果不先在试点试水，就贸然在全局上推广，一旦在推进过程中遇到水土不服等问题，不只阶段性的成果会前功尽弃，再想倒回去做新的改变也更不容易，最终整个变革大概率会走向失败。
为什么要做试点前的准备？现在你知道了为什么要做试点，那是不是在毫无准备的情况下，立马就着手做呢？
我先来带你看一家创业公司推进敏捷的故事。因为是创业公司，工作节奏本来就非常快，老板希望他们做敏捷时也能够“短、平、快”：快速行动、快速见成果。于是，相关的负责人只对团队成员进行了两个小时的简单培训，直接就要求所有团队上 Scrum。
但效果极其不好，问题更是显而易见。因为此时，大家连 Scrum Master 是谁都不知道，况且没有任何前期铺垫，直接就要求团队改变熟悉的工作模式，团队成员既不理解为什么要改变，也不知道这种新模式到底该怎么做。大家很快就接受不了这种工作方式，做得一塌糊涂，连个形式上的敏捷都没做到，更别提见收效了。此时，负责人到处救场，劳累不说，团队也不满意，老板更不满意，最后整个敏捷实践就这么灰头土脸地草草收场了。
这家创业公司的敏捷实践为什么会失败？原因就是他们在推进试点前，没有做好试点前的准备工作。俗话说“凡事预则立，不预则废”，敏捷也是如此，只有做好详细、充足的准备，我们才能在推进试点时真正做到有备无患。有人还给敏捷试点前的准备工作起了个名字，叫迭代 0（Iteration 0），这更足以见得这些准备工作的重要性。
如何做好敏捷试点前的准备？现在你知道了为什么要做试点前的准备，那么到底该如何做，才能为你的试点打开一个好局面呢？下面我就结合一个我接触过的实际案例，给你讲讲做好试点前准备工作的基本要点。另外，简单介绍一下这个案例的主角，它是一家拥有一千多名研发人员的银行，我们姑且叫它 B 公司。
1. 选择试点团队首先，你需要挑选试点团队，让他们充当推进敏捷的排头兵，快速打赢变革的第一仗。一般来说，有以下这些特征的团队会成为我们的首选：
采纳敏捷的意愿相对强烈；
业务价值高或采纳敏捷会在短期内给团队带来很大收益。
为什么要选择这样的团队？
这是因为，相对强烈的实践意愿，是团队落地敏捷的优渥土壤。如果团队愿意接纳敏捷，那么在推进过程中，团队成员会很容易发挥他们的主观能动性，成员之间的配合度也会相对较高，更易于产生良好的化学反应，也更有利于克服推进过程中遇到的困难与不适，使敏捷顺利推进并取得成效。
另外如果团队做的产品业务价值高，或者敏捷能在短期内给他们带来很大的益处，那么团队排头兵的示范效应就会比较好。一般而言，这样的项目比较重要，公司也会高度关注，团队做起来也会更认真，也就更重视自己的敏捷实践活动是否能取得成果。而且如果敏捷能在这些团队里率先取得胜利，那么它在公司里的影响力就会更大，也会让其它团队更加信服，为进一步推进它打下良好基础。
此外，我建议你选两个或两个以上团队来进行试点。因为只选一个团队，孤品风险太大，也没有竞争效果；而两个或两个以上团队容易产生竞争性，对比效果明显，大家都会争着把事情做到最好。当然，这也要看敏捷教练的数量，一般来说，一个教练一次只能带 2～3 个团队，否则一个教练的精力是没办法照顾到每个团队的。
比如说 B 公司，他们希望通过导入敏捷提高研发效能。在试点时，我们选择了两个团队：手机银行产品团队和直销银行产品团队。对于 B 公司这样的银行来说，这两个产品都是他们的核心产品，在互联网的冲击下，业务压力很大，所以他们要求研发团队能够快速响应，因此团队有相对强烈的敏捷实践意愿。
2. 前期准备工作细则选好了团队，就要配合团队做一些前期准备工作，你需要从 6 个方面去准备：
组织和人员
管控治理规则
需求范围
架构
方法和工具
办公环境设施
下面我就结合 B 公司这个案例，逐一把这些准备工作详细讲给你。
首先，是组织和人员的准备。说到底敏捷是要靠人来执行和推动的，因此，我认为在所有准备工作中，这一条是最重要，也是最需要你花费心力来做好的，它直接关乎了敏捷试点乃至整个敏捷推进工作能否成功。从组织层面来说，你要查看当前的项目组织结构是否适合做敏捷，如果不适合，就要重新组织。从人员层面来说，你需要对参与试点的人员进行相关培训。
那具有什么特点的组织结构更适合做敏捷呢？简而言之，就是“高内聚，低耦合”。这本来是软件开发中用来衡量软件设计好坏的词，一般而言，模块内部高度聚集和关联，而模块之间关联程度低，这样的软件才是好软件。
引申用在组织结构中，高内聚指的是日常工作中，全功能小团队内部成员之间的沟通合作更紧密；低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织结构才更适合推进敏捷。
那要怎样来划分组织结构呢？其实，业界如今已经有很多这样的组织结构框架，但在这里我想提醒你的是，框架虽然多，但本质都是一样的，都是为了让小团队内的沟通合作频度更多，也更加顺畅，而团队之间的沟通协作尽量少一些。
这里我用 Spotify 框架来说一下，它目前是“高内聚，低耦合”组织结构的一个通用典范。
它分两层，下面一层是 Squad，指的是一个个全功能小团队，每个小团队中都有自己的业务分析师、开发人员、测试人员和迭代经理（Iteration Manager），能端到端负责一个需求或者产品。一般来说，团队中的人数要限制在 5～9 人，当团队人数超过 9 人时，也要分拆成不同的 Squad。而当 Squad 超过 5 个时，就要考虑把它们划分到不同的 Tribe（部落）中去，它是组织结构的第二层。在敏捷中，我们就是按照从 Tribe 到 Squad 这样的线条去管理团队的。
参考这个结构框架，我们将 B 公司的研发团队进行了重新组织。以 B 公司的手机银行项目组为例，这个项目团队有将近 30 人，开发团队和测试团队分属不同的领导，也在不同的办公区办公。
我们把它分成了 4 个小分队，每个小分队都是有开发、测试、业务和迭代经理的、独立的功能团队。在这之外，我们还设立了产品负责人这个角色，用来把握整个产品。为了沟通方便，我们设法将小分队里的人都安排到一起来办公。在重组完成后，我们又定义了各个角色的描述和职责，并进行了宣讲，在团队内达成一致。
在完成团队组织结构的重组后，接下来还需要给团队成员进行培训。在上面 B 公司重组好的团队中，我们是这样做的：
进行“敏捷思想基础”和“敏捷实践基础”两门基础课程培训；
组织拆书会，选择一些敏捷基础的书籍，每个人都来读一节，一起来分享，这样团队成员很快就有了一定的敏捷知识储备。
此外，除了对团队进行培训，我们还对相关项目的干系人也做了一些宣讲，内容是兄弟公司是怎么做敏捷的，取得了什么成效等等。
以上这些都是试点启动前的培训，在试点运行过程中，我们也会根据团队实践情况，针对大家对敏捷认知模糊的部分，随时做出讲解。比如随着团队工作的推进，我们会深入讲需求条目化、怎么做用户故事以及怎么做拆分等等。
其次，是管理治理规则准备。相信你还记得，在前面的课程中我给你讲过，敏捷是有规则的，不是随意的、自由奔放的，不能想怎么做就怎么做。所以，在做好组织结构和人员的准备后，为了大家能更好地协同和配合，省掉管理和交流中不必要的争执，你也要做一些管理治理规则的准备，并在试点之前就跟大家同步明确好，保证整个试点工作有序运行。因此，在 B 公司，我们做了架构和设计的治理规则，质量管理策略规则等等。
再次，是需求范围的前期准备。要想顺利开展后续的迭代，前期需求的准备是必不可少的。但因为在敏捷中，需求是逐渐涌现出来的，所以在后面的每个迭代中，我们都会对下一迭代要做的需求进行新的梳理。
在前期我们做好这些准备就可以：
项目的高阶需求范围、高阶发布计划；
高阶的史诗级故事；
近期 2 个迭代要开发的用户故事。
如何准备好这些用户故事呢？通常我们会开几个工作坊，一起来头脑风暴一下。例如在 B 公司，我们就做了几个工作坊，写好了几十个用户故事，并将其按照优先级排序。这里请你注意，用户故事不仅要准备好相应的故事描述，还要有验收标准。
接着，是架构上的准备。做好需求，就要开始架构。关于敏捷里的架构，之前业界也有很多相关讨论，但总体来说，都是希望抛弃原有的瀑布模式。由于在敏捷中需求是分步提出来的，也是不断演进变化的，因此相应地，要采用演进式架构，而不是做成一锤子买卖。正因为这样，在迭代 0 的时候，你只要基于当时的信息做好架构就好，后面可以随着项目的深入及时调整。
这时候我们做架构的方式，是在完成初始需求分析之后，根据它来做架构建模。在项目早期，进行一些高层次的架构建模，会有助于团队与关键利益相关人商讨系统采取的技术策略，这样做的关键目标是快速识别出架构策略，快速完成架构建模。
在 B 公司，我们通过召开建模的头脑风暴会议，讨论了系统的功能特征，并思考了实现这些特征的高层设计策略，从技术图表、用户交互流程图、领域图和变更流程图四个方面做了建模。
再来看看方法和工具的准备。做完上面的准备后，你还要根据自己在第一步，也就是评估诊断时的访谈结果，根据痛点选择适合自己团队的敏捷方法，当然方法的使用是灵活的，也许一开始你用的方法随着敏捷的推进不再适用，那后面你就要做出相应的调整或改变。
在 B 公司，起初我们在管理实践上选择了 Scrum，在技术实践上则选择了单元测试、自动化回归测试，还有搭建 DevOps 流水线。然而在实际推进试点过程中，我们发现在当时的情况下，由于团队的老旧代码过多，做单元测试的收益不大，所以我们及时调整，优先推进了自动化接口测试、自动化回归测试和 DevOps 流水线，而选择在试点后再尝试做单元测试。
“工欲善其事，必先利其器”，要想把试点工作做好，工具方面也不能马虎。你需要在试点前选择、构建、测试、部署工作过程管理工具，并在测试后安装好；与此同时，你也要选好自动化测试用的工具，如果自动化工具不到位，所有工作都靠手工处理，效率就会过于低下。
工作过程管理工具，主要指研发作业流程管理工具，比如 Jira 和 Trello 等，国内也有人用禅道。你可以根据实际情况，通过这样的原则来选择工具：
如果试点团队已经有自己的工具，那可以先自行试用、评估一下这种工具在敏捷中好不好用，也就是说，看看敏捷的过程在工具中是不是可视化的。比如说有的工具只有需求管理的作用，没法将后面的开发、测试过程囊括在内，这时你就要考虑是要将两种不同功能的工具合起来使用，还是重新选用新的工具；
如果试点团队没有自己的工具，那么无论是工作过程管理工具还是自动化测试等工具，都可以根据预算以及公司要求的安全性级别来引进新的工具。一般来说，这些工具又可分为付费工具和开源工具，像 Jira、Confluence 等 Atlanssian 的付费工具，后续的服务要好一些；而免费的开源工具如 Jenkins，则能节省资金，这还是要结合自身情况去选择。
在 B 公司，由于他们的团队规模较大，考虑到后续可能需要 Atlanssian 的一部分插件来做管理工作，我们选择了 Jira 做工作过程管理工具。另外，考虑到目前 Jenkins 做持续集成的案例比较多，为了日后方便，我们又选择了它来做持续集成，并用 SonaQube 来做代码扫描。
要将敏捷做好，除了上面的“软”件，也离不开硬件的支持，所以办公环境设施的准备也很重要。如果项目中有成员是远程办公的，就需要准备必要的音视频设备，远程会议工具；如果项目都在一个区域，就还要有适用于敏捷开发的办公环境，如物理看板和开放式的工位等等。
在 B 公司，由于他们所有团队的员工都在一个区域办公，我们就在办公区张贴了一些关于敏捷的宣传画报，也安放了物理看板，这可以方便团队学习和交流，提高工作效率。
总结OK，说到这里，我们的试点准备工作就大功告成了，现在我来总结一下，以便于你更好地理解。
所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好试点工作前的充分准备。如何做好准备工作呢？一句话：调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境。你要注意，这些准备工作是相辅相成的，每一步都马虎不得。
俗话说“心急吃不了热豆腐”，在推进敏捷时，不能盲目地求快，不能省略掉该走的步骤。如果不做试点前的准备工作，就直接开展敏捷活动，那么团队成员既没有心理上的准备，也没有知识和技能上的储备，整个试点工作也会如同一团乱麻，达不到预期效果。做好了各项准备，未雨绸缪，才能让我们的试点工作“事半功倍”。
思考题现在，我想请你来思考一下，在团队试点前的准备工作中，关于组织和人员的准备，你会怎么做呢？你有没有更好的方法呢？
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

分享给需要的人，Ta购买本课程，你将得9元

生成海报并分享

赞 14

提建议

03 | 评估诊断：成功迈出敏捷推进的第一步

05 | 团队试点（二）：打造一支无往不胜的敏捷团队

 写留言

精选留言(40)

rocedu
2020-01-08
- [Spotify敏捷模式详解三部曲第一篇：研发团队 ](http://www.scrumcn.com/agile/scrum/21929.html) - [Spotify敏捷模式详解三部曲第二篇：研发过程 ](http://www.scrumcn.com/agile/scrum/21931.html) - [Spotify敏捷模式详解三部曲第三篇：工程文化 ](http://www.scrumcn.com/agile/scrum/21933.html)
展开
共 2 条评论
33
Raymond吕
2020-01-09
看过一个选试点团队的方法，分享下： 1.选择独立的项目，规模在5~9人，尽量避免选择团队之间交叉依赖的项目，避开不必要的复杂性，增加试点成功率；可以选择大项目中的一个小团队做试点 2.团队尽量在一起 3.选择在业务主航道上的项目做试点，不要选择那些最关键的项目，选择主航道上重要程度为中等的项目 4.项目周期不能太短，也不要太长 5.最好选择新产品开发项目，而不是维护类项目 6.选择纯软件项目做试点，试点见效后再考虑硬件项目
展开
共 2 条评论
15
Daniel
2020-01-08
宋老师，能否推荐几本中文的基础敏捷书籍呀
作者回复: 《Scrum敏捷项目管理》、《硝烟中的Scrum与XP》、《敏捷回顾:团队从优秀到卓越之道》、《敏捷教练：如何打造优秀的敏捷团队》
共 2 条评论
9
rocedu
2020-01-09
我说的不是真实案例的展现，而是模拟，脱敏的展示，这个应该没有问题的吧？我是搞不清楚你说的技术图表和领域图是什么，网上找的东西也不确定对不对。技术图表是投资中用的哪些点线图，K线图之类的东西吗？领域图跟软件开发中的领域模型一样吗？
作者回复: 技术图表是UML部署图等，这些图表有助于开发者预测主要的软件和硬件组件，包括你需要访问的旧系统和数据库，系统有可能会与它们进行交互。不是点线图和K图。领域图是领域模型，但是很初始的。后面这些都会随着项目推进进行架构的演进。敏捷中的架构设计与传统架构设计有差别，具体可以了解“演进式架构”，也有相应的图书出版，关于架构建模也可以搜索了解一下“Scott W. Ambler”提出的“架构预测Architectural Envisioning”。不知是否回答清楚了问题。
6
吴言乱语
2020-01-07
1.意愿度高的人员入选。 2.团队结构比例高级、中级、初级成梯队，这样有利于项目风险把控。 3.挑选重要不紧急的项目，有好的容错空间。 4.明确团队人员职责，分工，各项事务的规则。
6
escray
2020-01-15
这一篇关于团队试点前的准备讲的非常详细，如果自己准备推进敏捷，那么基本上可以按图索骥照猫画虎了。以前想的比较简单，以为只需要做好宣讲、配置好工具即可，没有想到有这么多的讲究。团队的选择挺有讲究的，而且是选两个来做比较。如果让我来选，我可能会倾向于有采纳敏捷意愿的，技术实力相对较好，但是不一定是特别核心的团队。主要是感觉，如果直接在核心团队上试点，会有一定的风险，感觉二线团队更为合适。框架的选择也很重要，这个可能得依赖敏捷教练的经验，按照目前团队的状况来选择合适的框架，并进行取舍。演进式架构可能也得在一定程度上依赖敏捷顾问来制定，否则可能会造成后续迭代过程中架构调整的困难。对于敏捷方法和工具，我觉的单元测试可能是最难推动的，因为对开发人员的影响比较大。而接口测试和回归测试相对来说更多的是需要测试人员去做。流程管理工具和持续集成、代码扫描等工具的配置、使用、培训，其实也是需要投入很多的人力。办公环境可能是最容易准备的环节。我自己试着采用敏捷模式开发时，就卡在了单元测试和持续集成环境的搭建上。对于思考题中，组织和人员的准备，主要还是看上层领导和基层开发有没有推进敏捷的意愿，这里当然需要进行宣讲和说服，如果大家都不了解或者不愿意试点敏捷，那么估计就很难进一步推广。另外就是要尽快展示敏捷所带来好处，特别是不能给相关的开发和测试人员增加太多的工作量，如果因为敏捷带来了太重的负担，那么估计是很难被团队成员认可的。
展开
4
rocedu
2020-01-08
架构和设计的治理规则，质量管理策略规则等规则都有什么内容？
作者回复: 主要是为了保证团队能够顺利开展这些工作的一些基本约定，以架构治理规则为例，会约定该产品采用什么样的架构，整个开发过程中架构怎么做，以及是否存在架构评审环节之类的
4
Jagger Chen
2021-04-05
项目的高阶需求范围、高阶发布计划；高阶的史诗级故事；老师您好，能解释下这两个的含义吗？
共 1 条评论
3
smily
2020-01-07
首先，了解业务架构与组织架构是否匹配。其次，了解软件开发生命周期是否健全，是否有输入/输出/评审标准。再次，了解不同角色工具链及工作方式。最后，了解沟通方式/组织方式及方法。从业务，组织，人员，沟通，协作来深度分析，决定敏捷的组队。
3
猿飞日斩
2020-07-10
老师，这种上来就开干的搞法很容易入坑啊，是不是应该先说一下敏捷开发的使用场景（换种问法，什么样的场景根本就不适合敏捷）？解决了什么痛点？是否需要一些基础设施建设作为启动前提（比如，自动化测试，自动化运维）？执行过程中有哪些坑需要我们注意（这关注点）？完事后有哪些屁股需要我们擦？
2
梁中华
2020-03-29
在普通的特性迭代团队里，可能没有人能达到架构师的水平，那怎么保证设计质量，即使前期调个架构师过来指导一番，后期又怎么能保证开发按照架构师点设计来落地呢？
2
而立斋
2020-01-30
老师，这篇文章中所涉及的一些规则，用户故事等，有没有一个完整的模板？这些内容多重要呀。
作者回复: 用户故事可参见《用户故事与敏捷方法》一书了解更多的内容。其他的规则在其他同学的问答中有一些。
2
rocedu
2020-01-08
技术图表、用户交互流程图、领域图和变更流程图四个方面做了建模，这些模型能简单展示一下吗？
作者回复: 抱歉，案例中的具体图形内容涉及客户机密，不方便展示。
共 4 条评论
2
Geek_d1772c
2022-03-01
老师说的这些跟敏捷有什么关系啊？不是敏捷男的就不做就不用了吗？
1
德鹏
2021-09-09
通过竞争来应聘加入敏捷试点，完成后爆发荣誉证书。
1
行骏
2021-08-29
组织要自上而下重视这次试点。
1
刘隐林
2021-05-27
结合我自身的经验,就是感觉在迭代0的过程中没有准备好,大家都摸石头过河,摔得头破血流
1
黄平
2020-10-16
老师，请问“业务分析师”和“产品负责人”的职责是有什么区分和侧重点啊？另外“迭代经理”就是什么职责啊？
共 1 条评论
1
🌾Jeane CHEN �...
2020-08-12
老师，我们正在团队内试点敏捷，目前遇到问题，需求太大，一般都会超过迭代一点点，导致下个迭代无法按照计划进行下个迭代的需求评审和迭代计划会，给团队的感觉是迭代之间界线不明显…目前基本上是每个迭代都会被上个迭代影响。产品经理们（该团队有4个PO）也一直在实践用户故事，但是效果不佳，单独的用户故事大部分是一个模块，无法行程连贯的功能，所以团队还是按照需求的颗粒度来交付，导致了目前的现状，请问有什么好的办法可以解目前的困境吗？
展开
共 1 条评论
1
Don
2020-04-19
在B公司，单元测试都做不到，想问下自动化测试时如何做到的？
1

