mod

极客时间专栏/说透敏捷/实战篇/03 | 评估诊断：成功迈出敏捷推进的第一步.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="03 | 评估诊断：成功迈出敏捷推进的第一步" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9c/e4/9cf2d9897b2597b9ba1cf3cc31f449e4.mp3"></audio>
+
+你好，我是宋宁。
+
+从今天这一节课开始，我要给你讲讲具体怎么来推进敏捷。我会结合案例，用四节课的时间介绍推进敏捷的三大步骤：评估诊断、团队敏捷试点、大规模推广。今天，我们先来学习第一步：评估诊断。
+
+在我做咨询的过程中，一开始经常会碰到下面这些问题：
+
+- 有很多人一头雾水，跑过来问我：“老师，我们现在准备开始做敏捷实践了，可是从哪里做起呢？敏捷那么多方法，我要先用哪个呢？”
+- 还有的人说：“敏捷很好，因此我要以它为标准，所有项目都要遵循这个标准。”
+- 而有的人在敏捷面前踌躇不前：“敏捷对人的要求很高，我们现在还不具备做敏捷的条件，等条件成熟了再说吧。”
+
+其实，无论是想做敏捷但不知道怎么去选择方法，还是不管三七二十一直接套用成熟的实践经验，抑或以自己不具备条件为借口犹犹豫豫不敢去做，这些问题反映的都是大家没有做前期的评估诊断，因此不了解自己的现状，不清楚自己的痛点，不知道从哪里下手去推进敏捷。
+
+就像医生在看病之前需要患者先做各种相关检查，有了检查结果，医生才好对症下药，敏捷实践亦是如此。在我们决定推进敏捷前，第一步就要评估企业目前的整体情况是什么样的，它在文化、实践、工具等维度上，已经达到了什么程度？它有什么痛点亟待解决？
+
+**只有把这个第一步做好，对自身的情况有个清晰的认识，我们才能针对自身的问题找到适合自己的敏捷方法。**
+
+那么，如何做敏捷推进前的评估诊断呢？我想分为两部分来谈，首先从理论上说说做评估诊断的方法步骤，然后以一个案例具体说明在实践中到底应该怎么做。
+
+## 评估诊断的方法步骤
+
+从理论上来说，我们通常采用“四步法”来做评估诊断。
+
+**第一步：挑选代表性项目。**这一步类似抽样调查中的抽样，在做评估前你需要在企业里选一些具有代表性的项目，可以是业务上有代表性，也可以是研发模式上有代表性。如果企业的项目囊括了大、中、小型项目，那么我建议你从这三类项目中各选一个来进行评估，这样你在深入评估项目时，得到的结果才能更真实地反映企业现状。
+
+**第二步：访谈评估。**在划定了需要评估的项目范围后，你需要对这些项目中的团队成员进行访谈，从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估。这一步的目的是通过访谈有意识地探查项目的痛点。
+
+**第三步：制定转型计划。**你需要根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。痛点不同，计划也不同，一定要有针对性地做计划方案。比如说团队的主要问题是跨部门、跨团队沟通协作不畅，那在计划中就要优先考虑团队组织的问题，必要时再做组织变革；如果团队的问题集中在从开发完成到上线前这一阶段，那么在计划中就要优先考虑建设DevOps流水线。
+
+**第四步：沟通。**在访谈评估和制定计划后，在正式进行敏捷实践前，你需要与相关人员，比如说团队成员、团队主管，以及推进敏捷的内部负责人等，沟通评估结果和相应计划，以便整个团队达成一致意见。如果不沟通，大家对目前的现状理解不一致，那在互相配合上就会有偏差；更严重的是，如果沟通得不好，大家说不定还会互相拆台，这样再好的计划也是没法真正落地的。
+
+此外，关于由谁来做评估诊断，你也要注意一下。以上四个步骤，如果你请了有经验的咨询师来做，那只需要配合他们选好项目，并安排相关成员参加访谈即可。如果你没有请咨询师，也可以请公司里与研发团队平行的部门如PMO（项目管理中心）等部门，或内部的敏捷教练来负责推进，但这些人员一定要了解敏捷，了解业界的敏捷实践情况，参加过相关培训。否则的话，不仅不能很好地发现问题和痛点，还可能使评估结果不够专业，难以服众。
+
+上面这四点，就是评估诊断在理论上行得通的“四步法”，接下来我就以一个我之前做过的案例，来具体说明下如何做好评估诊断。
+
+## 评估诊断案例分析
+
+先说一下这个案例的背景：这是一家国有银行，在找我去帮忙评估之前已经做了一些敏捷方面的尝试，而且，内部做尝试的那几个团队自以为做得还不错。现在他们计划向更多团队推广敏捷，在此之前想让我去检查一下他们目前的敏捷成熟度，并让我帮忙做后续的推广计划。
+
+接到这个任务以后，我跟负责接洽的部门简单沟通了下，然后选择了他们敏捷推进情况不一样的两种项目：一种是几个已经做了敏捷尝试的项目，另一种是几个没有做过任何敏捷活动的项目。之所以这样选择，是因为只有把这两种不同的项目都覆盖到，才能更好地看清这个公司的研发现状。
+
+在选定好代表项目后，我便开始访谈评估。我把这些项目中的团队成员分成不同角色，例如开发、测试、运维、需求、项目管理人员等等，依次去和他们访谈，这主要是为了全面了解项目的研发流程，了解每个角色在研发活动中的工作情况，也了解各个角色之间的协作情况。
+
+另外我还去他们做敏捷尝试的团队里做了实地观察，观察他们的站立会议，了解他们的需求管理、开发测试过程、上线过程。最后我有了以下这3个发现。
+
+**首先，虽然这些团队进行了敏捷尝试，但成熟度并不高，如果用5分制（1为最低，5为最高）给他们打分，这些团队的实践水平也就是在1和2之间。**而且他们的管理实践推进不力，技术实践压根也没有推进。
+
+比如，他们有一个研发团队是由5个不到9人的小Scrum团队组成的，每个Scrum团队理应各自开站立会议，这样每个团队都有一个自己的看板，这样会很方便。但他们却把5个小团队的看板放到了一块板子上，这就使同一块看板上每个团队的区域都很局促，所有的卡片都叠在了一起；这也导致每次开站立会议时，大家不只要排队，每个人还得在一堆卡片里找自己负责的卡片，既浪费时间又不够方便。另外，由于看板上所有的卡片都叠在一起，也不利于大家及时发现问题。
+
+所以，这一系列安排都使他们的站立会议和看板没有起到提高透明度、提高协作水平的作用，这样的会议只是一个形式上的会议。
+
+**其次，该企业未推进敏捷的团队现在采用的是瀑布模式，对敏捷了解甚少**。这是因为这个企业当初号召大家做敏捷时，遵循的是自愿原则，并未统一做敏捷宣讲和进一步培训，想尝试的团队就自己去学习，没有尝试的团队也就从没有主动去了解敏捷的益处，这样即便团队有了痛点，也意识不到可以用敏捷方法去解决。
+
+所以我在访谈过程中，发现有很多人只是听过“敏捷”这个词，至于它的含义、研发管理用了它后会有什么新变化，以及到底应该怎么去做它，他们是完全没有概念的。
+
+**最后，这些团队在跨团队交流方面有很大的障碍，这表现在业务人员与开发测试团队隔离，目标不统一，参与敏捷的投入度明显不够。**他们只是在开发测试团队里做了一些敏捷实践，而并没有把业务人员拉进来；团队也没有相应的制度，所以业务人员在这场敏捷活动中是想来就来、想走就走，毫无纪律性可言。另外，业务人员还是像过去一样，认为提完需求，自己的工作就结束了，至于做不做得出来，是开发测试团队的事情。
+
+根据上面的评估结果，我在分析问题后，尝试寻找解决方案。
+
+第一个问题的表象是大家的敏捷推进做得不够好，还有些野路子的样子，但根本原因其实是缺乏专业的指导，并不了解敏捷实践背后的意义。
+
+针对这个问题我给出的方案是：对已经推进敏捷的团队，重新检视他们的实践情况，固化已经做得很好的地方。
+
+第二个问题实质就是未推进敏捷的团队对敏捷没有概念，也不知道怎么去做。
+
+针对这个问题，我给出了两步走的方案。第一步，先解决认知问题，对未推进敏捷的团队进行专业的基础知识培训；第二步，选择试点团队示范怎么做。可以将团队拆分成10人以内的全功能小团队，根据项目的痛点做相应试点计划，推进后定期做总结回顾，并邀请试点团队分享经验。
+
+最后一个问题，其实也可以拆分成两个子问题。一个子问题是团队在跨团队交流方面有很大的障碍，这本质上是个系统性的问题，所以需要建立相应的机制。另一个子问题是团队虽然已经导入了敏捷，但并没有将业务人员纳入到其中，业务人员的工作习惯和工作模式并没有发生很大的改变。针对这个问题，我给出的方案是提出业务与研发团队的组织变革，建立产品负责人制度。
+
+现在，我们把上面每个解决方案加上具体实施时间，就形成了半年的短期计划：
+
+- 1月～4月：选择试点团队示范敏捷实践；
+- 5月：推动跨团队交流，建立相应的机制；
+- 5～6月：建立产品负责人制度。
+
+看到这里，你也许会问，为什么是短期计划而不是长期计划呢？
+
+这是因为在敏捷中，计划的制定是渐进明细的，这也就是说，近期的计划可以具体到可实施的细节，而远期的计划则是粗略的，所以更长远的计划我们并未在评估和诊断结束之后马上就开始做。此外，因为不清楚敏捷在这个公司里的试验效果如何，所以我们还是要先做个短期试验，由试点团队试点之后，根据实施的情况做回顾和总结，再推导出进一步的长期计划。
+
+前期访谈结束和短期计划制定完成后，我便开始和这些团队沟通。那么问题来了，这个企业的评估结果不是很乐观，我该怎么和团队沟通，才能让他们既理解自己的现状，又不失去信心呢？
+
+经过思考，我决定不拿“满分是5分，而你们只能得1.5分”这样的量化数字给他们看，这样对他们的冲击太大。我在发现（finding）描述里，先列出了一系列的正向发现（positive findings），紧接着在旁边又列了一些负向发现（negative findings），并且告诉他们对于每一则条目来说，好的标准是什么，这样他们就会自己感觉到自己的不足和差距。然后我再讲怎样做才能弥补这些不足，并给出我推荐的时间表，让大家看看是否合理。这样循序渐进，后面我在和团队沟通具体计划时，就顺畅了很多。
+
+另外，前面我们讲的是一个公司做敏捷转型的案例，那如果是一个项目组自己想尝试敏捷，是否需要做前期的评估呢？我是建议谁也做一下，因为项目组的现状和痛点也是需要在评估诊断中来分析的。只不过因为只有一个项目，不存在代表性项目的问题，所以四步法里的第一步是可以省略的，只做其它三步就可以了。
+
+## 总结
+
+现在我来总结一下今天的课程内容，希望能对你有所帮助。
+
+推进敏捷的第一步是评估诊断，其目的是在转型之前，让企业或者团队了解自己的现状、存在的问题和痛点。采用的方法是四步法：选定代表性项目、访谈评估、制定转型计划和沟通。
+
+你要注意的是，评估诊断的目的是为了解自己的现状是什么，了解自己的痛点在哪里，并针对这些问题和痛点，结合短期要达成的目标，找到解决方案，制定合理的计划。也可以说，我们引进敏捷就是为了解决痛点。
+
+目前有很多公司，他们之所以没有把敏捷做好，很大一部分原因就是他们在推进敏捷前，不对自身情况加以评估，直接套用成熟的实践方法，却不管这些方法适不适合自己，结果就像医生看病不问病因就直接开方抓药一样，药不对症，花了很大力气治病却没有收到好的效果，得不偿失。所以我建议你在决定做敏捷实践之前，一定不要怕麻烦，要先对自己的现状做细致的评估和诊断，之后再针对具体问题使用适合自己的敏捷实践方法，这样你的敏捷推进就迈出了成功的第一步。
+
+## 思考题
+
+看了今天的文章，你是不是已经跃跃欲试了呢？课程最后，我想请你结合今天的内容和自己的实际情况思考一下，如果让你来牵头推进敏捷，你会怎样迈出第一步呢？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/04 | 团队试点（一）：让你的敏捷实践“事半功倍”.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="04 | 团队试点（一）：让你的敏捷实践“事半功倍”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/f4/4dfb3cc5e4593a6cef3248beb87d8af4.mp3"></audio>
+
+你好，我是宋宁。
+
+上节课我给你讲了怎么做敏捷推进前的评估诊断，也帮你做了短期的推进计划。接下来我要用两节课时间，给你讲讲推进敏捷的第二个步骤：团队敏捷试点。
+
+试点工作的展开可以分为**试点前准备**和**试点推进过程**两步。今天我先来讲在做团队敏捷试点前，你需要做哪些准备，试点推进过程我在下一节课会再做详细讲解。
+
+说到这里你可能要问了：直接给公司所有团队都直接导入敏捷不就得了，为什么还要费精力先搞个敏捷试点？
+
+这是因为，敏捷实践毕竟属于一场变革，与其它所有变革一样，都需要先从局部试点试水，只有在试点中积累了切实的经验教训，确定了可行性后，才能去大规模推广。如果不先在试点试水，就贸然在全局上推广，一旦在推进过程中遇到水土不服等问题，不只阶段性的成果会前功尽弃，再想倒回去做新的改变也更不容易，最终整个变革大概率会走向失败。
+
+## 为什么要做试点前的准备？
+
+现在你知道了为什么要做试点，那是不是在毫无准备的情况下，立马就着手做呢？
+
+我先来带你看一家创业公司推进敏捷的故事。因为是创业公司，工作节奏本来就非常快，老板希望他们做敏捷时也能够“短、平、快”：快速行动、快速见成果。于是，相关的负责人只对团队成员进行了两个小时的简单培训，直接就要求所有团队上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，说到这里，我们的试点准备工作就大功告成了，现在我来总结一下，以便于你更好地理解。
+
+所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好试点工作前的充分准备。如何做好准备工作呢？一句话：**调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境。**你要注意，这些准备工作是相辅相成的，每一步都马虎不得。
+
+俗话说“心急吃不了热豆腐”，在推进敏捷时，不能盲目地求快，不能省略掉该走的步骤。如果不做试点前的准备工作，就直接开展敏捷活动，那么团队成员既没有心理上的准备，也没有知识和技能上的储备，整个试点工作也会如同一团乱麻，达不到预期效果。做好了各项准备，未雨绸缪，才能让我们的试点工作“事半功倍”。
+
+## 思考题
+
+现在，我想请你来思考一下，在团队试点前的准备工作中，关于组织和人员的准备，你会怎么做呢？你有没有更好的方法呢？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/05 | 团队试点（二）：打造一支无往不胜的敏捷团队.md

@@ -0,0 +1,100 @@
+<audio id="audio" title="05 | 团队试点（二）：打造一支无往不胜的敏捷团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d9/4c/d9eab7cc79da8bdfdc73a4c646b75a4c.mp3"></audio>
+
+你好，我是宋宁。
+
+上节课我讲了怎么做团队试点前的准备工作，这节课我们一起来看看具体怎么推进敏捷试点。
+
+你可能要问了，既然准备工作已经做好，万事俱备，还等什么，直接推进试点不就可以了吗？其实没那么简单，因为一切准备工作还得靠团队来执行和交付。如果说试点准备工作中最重要的是组织和人员的准备，那么在推进试点过程中，最重要的也可以说是核心的关键点，**就是打造一支活力与战斗力并存的敏捷团队。**
+
+团队是整个敏捷实践活动的根基，只有团队能有条不紊又高效率地执行实践中的每一项工作，敏捷才能发挥出它最大的效用。如果团队氛围不好、执行力不高，那即便导入了敏捷，团队也很有可能做不好。
+
+在做试点准备工作时，我们已根据最适合团队交流协作的方式，对它的组织结构进行了重组，那么重组后的团队就可以成为一支无往不胜的团队了吗？当然不是，你还需要想办法来唤醒、激发团队，让它更有活力和战斗力。
+
+因此在今天的课程里，我想教给你的是如何完成敏捷试点中最重要的一步：打造一支活力与战斗力并存、无往不胜的团队。学好了这关键一步，不管你和你的团队采取的是哪种敏捷方法，你都能在推进时得心应手、运筹帷幄，你的团队管理能力也会因此更上一层楼。
+
+## 一起制订社会契约
+
+我先来讲一个做法，叫做“社会契约”（Social Contract）。
+
+什么是社会契约？它本指一个社会里的全体成员，为了更好地生活，制定了一些基本准则，大家一起来遵守。用在团队中，指的就是团队里的行为公约，也就是为了让团队中每个成员都能加强协作、发挥价值，一起来约定的一些基本准则。在工作中，如果有任何成员的行为影响了团队协作，其他成员都可以拿这个契约来约束他，这样就可以“对事儿不对人”，在处理不良行为的时候更有说服力。
+
+落地社会契约的过程，其实就是团队内部相互认可、磨合和协作的过程。那具体怎么来做呢？我认为可以将团队所有成员都聚到一起，大家一起来制定，只有这样，才能充分征求每一个人的意见，让大家一致认可，这样就有充分理由让大家一起来执行了。
+
+首先，给大家分发一些贴纸，并给所有人5分钟的静默时间，让每个人都思考一个问题：你认为加强协作、达成团队目标，需要哪些行为准则？每个人都要把自己认为重要的准则写在贴纸上，且一张贴纸只写一条准则。
+
+写完之后，每个人把自己手中写好准则的贴纸贴到白板上，然后把白板划分为不同区域，把内容相似的贴纸归在同一个区域里。
+
+接着，会议的组织者要给大家宣读每一条准则，并询问大家是否同意，如果有人不同意，就停下来就此讨论一番，如果讨论的结果还是有人不同意，就放弃它；如果大家都同意，就将该准则保留下来。
+
+这样进行一遍，把大家都同意的行为准则留下来，就形成了团队的“社会契约”。
+
+你要注意的是，“社会契约”做完以后要张贴到所有团队成员都可以看到的地方，以便整个团队时时可以看到它，感受它带来的激励和约束。如果把它束之高阁，那就失去了它应有的效用，团队的协作也可能因此出现问题，进而导致敏捷推进的失败。
+
+## 回顾会议，引导团队的自主性
+
+在试点推进前制定“社会契约”，可以让你的团队形成一个约束和激励机制；那么在试点推进过程中，通过开展回顾会议，你的团队会形成一个引导机制，它能引导团队的自主性。
+
+在评估诊断阶段的调研访谈中，你已大体了解到团队的痛点，也根据痛点选择了相应的敏捷方法。那问题来了，这些方法里既有管理实践又有技术实践，它们的推进顺序是怎样的呢？
+
+一般而言，作为敏捷教练，我们自己会有一个自认为“正确”的推进顺序。但是实践方法是团队来用的，行为和习惯的转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易获得团队的认可和接受。所以重要的不是“你想”，而是“团队想”，回顾会议正好可以完美地做到这一点。
+
+怎么开展回顾会议呢？其实也很简单。
+
+首先，要选一个大家都方便的时间，把会议时间固定下来。前几次的会议可以由敏捷教练来引导，等大家对会议流程都熟悉了，就可以由团队的组长来组织了。
+
+会议开始后，要先说明会议目的，接着让大家讨论三个条目：
+
+- 团队工作中做得好的地方是什么？
+- 做得不好的地方又是什么？
+- 除此之外，有没有什么其它疑问？
+
+和制定契约的会议一样，先用五分钟时间让大家自己思考，然后把每一个点子都只写在一张贴纸上。将白板划分成不同的区域，把相似内容的贴纸分区域贴到白板上。
+
+接着和大家一一讨论这些问题。做得好的地方在接下来的迭代中可以保持下去，做得不好的地方大家可以一起头脑风暴看看到底怎么去改善，并做一些行动计划。对于有疑问的地方大家也可以互相提问，有些是敏捷教练需要阐释的，有些则是团队成员需要解释的。
+
+这里你要注意，回顾会议是有时间盒的，一般不会超过1个半小时。在前几次会议中，团队成员会提很多问题，但我们的时间有限，所以如果问题几句话就能解释明白，通常我会当场解释清楚，否则我会安排专门的时间答疑解惑，而不会把会议拖得太长，占用过多时间。
+
+你可以看到，这个会议其实也有查漏补缺的功能，可以让你发现团队成员在哪些方面有困惑，或者哪些敏捷知识储备不足，后面你可以安排其它时间来帮助他们专门补齐。
+
+以我带过的一个手机银行团队为例。在第一次回顾会议时，团队提出了一个问题：“项目透明度差，大家只了解自己的工作而不了解其他人的工作”。就这个问题，我引导团队成员思考它背后的原因，之后大家一致认为主要原因是“没有地方和机会了解别人的工作”。
+
+我就势说：“大家觉得可以做些什么事情来改善呢？”最后大家讨论认为，不如约一个时间，每天定时定点地开个短会来共享一下彼此的工作内容和状态，这不就是“站立会议”吗？我们又一起给它定了一个时间段：下个迭代。我领取了这个改进任务，在下一个迭代中为团队导入“站立会议”。
+
+说到这你发现没有，通过回顾会议来引导团队思考，所有的改进就不是我作为“敏捷教练”安排给团队来改进的，而是团队自己思考出来的行动。身为敏捷教练，我只需要将专业的知识和做法示范给团队即可，团队会更愿意践行自己主动思考出来的行动，这样，整个团队的行为和习惯就会转变得非常顺畅。
+
+所以说，只要掌握了正确的方法，敏捷的推进并没有想象中的那么难。每个团队其实都有向好转变的原动力，我们只需要将它激发出来，并且告诉他们正确的行为规范，加以引导就好了。
+
+## 成绩墙与错题集，记录团队敏捷的成长
+
+有了契约的约束和回顾会议的引导，是不是就意味着在试点过程中，会始终一帆风顺呢？不会，你一定还会遇到些小波澜。因为团队也不会一直都正确地思考，也有犯错的时候，比如：
+
+- 团队为了赶进度，省略了部分测试，匆忙上线；
+- 迭代中间，有业务人员向某个团队成员提出了新的需求，要求把它加到迭代中，团队成员不顾自己的研发产能，擅自将该需求加到了迭代中，最后却搞不定。
+
+遇到类似这些情况，该怎么办呢？这里我不想教你具体的解决方案，而是想教你引导团队解决问题的思维。
+
+如果这个所谓的错误并不会带来毁灭性的灾难，比如导致用户大规模投诉，或给公司带来巨大的经济损失，那么我会选择放手让他们按自己的想法先做一做，即使碰个壁也未尝不可。事后我们再坐下来认真分析到底怎么做才是对的，引导大家想出新的解决方案。有了这样一个试错的过程，大家通常会把经验教训记得很清楚。
+
+另外，配合着试点，我会让团队通过“成绩墙”和“错题集”在推进敏捷的过程中记录自己的心情曲线，以及取得的成绩和犯下的错误，所以这其实也记录着团队的成长。
+
+团队有任何大大小小的进步和成绩，我都会让他们顺手记录下来，贴在一面小小的“成绩墙”上。同样，我们也将自己遇到的问题和坎坷，以及解决方案也顺手记录下来，贴在另一面小小的墙上，构成一个“错题集”。这样大家经过它时，都会很容易想起在我们敏捷实践的过程中都发生过什么。在试点结束的时候，我们也会把总结中关于成功的经验和失败的教训写到这里。
+
+这样做有很多好处，首先团队会一直感觉到敏捷氛围的存在，有精气神儿；其次，以后有团队请我们去做宣讲时，我们很快就能找到素材，也能绘声绘色地讲给大家；还有，团队记录的心情曲线、“成绩墙”和“错题集”，这些都是试点结束后在做总结时，记录团队敏捷历程的鲜活素材，是团队敏捷实践的轨迹记录。
+
+## 总结
+
+现在，我来总结一下今天的内容，以利于你更好地理解。
+
+在做团队敏捷试点时，团队的执行力、战斗力是关键，你可以通过三个方法唤醒团队的活力：
+
+1. 推进试点前，制定“社会契约”，保证团队工作的有序和高效；
+1. 推进试点过程中，开展定期的“回顾会议”，引导团队成员自发思考，激发大家的自主性，使工作变得更顺畅；
+1. 在试点过程中和结束后，通过“成绩墙”和“错题集”记录团队的成长，总结敏捷实践中的经验。
+
+我想让你知道，其实打造一支无往不胜的团队并不难，只要你善于利用我给出的这三种方法，善于用同理心理解团队，那么你离敏捷实践的成功就不远了。但你也要注意的是，做试点不是目的，我们的真正目的是通过试点总结经验和教训，以便我们在给其它团队导入敏捷时能有所参考。
+
+## 思考题
+
+现在，我想请你结合今天的内容来思考一下，如果由你来负责推进团队敏捷试点，你会怎么做呢？如果你是试点但团队成员之一，正在做敏捷改进，你喜欢用什么样的方式来做呢？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/06 | 规模化推广：复制粘贴试点的经验就够了吗？.md

@@ -0,0 +1,109 @@
+<audio id="audio" title="06 | 规模化推广：复制粘贴试点的经验就够了吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bb/fb/bb3a145dfb5dd69099e8e44a573125fb.mp3"></audio>
+
+你好，我是宋宁。
+
+在前两节课中，我讲了如何做团队敏捷试点，这节课我就给你说说怎么把试点成功的经验做规模化推广。
+
+试点不是目的，做试点是为了在我们的环境中探索敏捷实践的可行性，积累经验，若是确认敏捷在我们的环境中是好用的，我们就要根据试点结果，把这个过程中积累的成功方法推广到更多团队中。
+
+## 规模化推广≠直接复制试点经验
+
+那么其他的团队该怎么使用试点团队的成功经验呢？是不是把它们直接复制过来就大功告成了呢？
+
+在我做咨询的经历中，我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”，但其实这个说法只对了一半。
+
+**没错，我们是做了试点，试点中的经验教训也是可以拿来给后面的推广做参考，但如果直接复制未免有点简单粗暴。**
+
+举个例子。某个试点团队成功使用了Scrum，于是领导一拍脑袋，也不管其他团队能不能吃得消，直接让所有团队一股脑儿在一个月内全部上马Scrum。结果，有的团队导入Scrum比较顺利，而有的团队却遇到了很多困难。
+
+其中，一个团队做的是运维类的项目，由于运维类项目开发的内容通常来自客户的建议或生产上的Bug，比较零散，没有一定的规划性，所以对于他们来说使用Scrum并不合适，他们其实更适合使用看板；还有一个近百人的团队，产品本身比较大，团队拆分后有十几个小团队，只使用Scrum却没有解决好团队间的协同问题，效果同样不佳。
+
+从这个例子你可以看出，上面这位领导除了拍脑袋和一刀切做决策，在推广敏捷时也只是机械地简单复制试点的成功经验，这非但没有给其他团队带来好处，对于他们来说反而成了一种桎梏。
+
+**此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。**
+
+在做试点时，我们更多解决的是小团队内部的敏捷怎么用，所以对于单一小团队来说，借鉴试点中的经验更为便利有效。
+
+而当你想规模化推广敏捷时，一旦小团队的数量多于两个，就会牵涉到团队与团队之间的协同问题。当然，在多个团队一起开发同一个产品的情况下，试点可能就是在多个团队中同时进行的，那么团队间的管理你也多少会涉及到。
+
+当小团队数量多于5个时，如果你用的是Spotify这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用管理小团队的方法就不够用了。
+
+所以，从试点到规模化推广，是要从团队内敏捷扩充到团队间敏捷的过程。由于牵涉到团队间的协同管理，团队间的敏捷较之团队内的敏捷更为复杂，因为你要开始考虑让各个团队方向一致而不是互相羁绊，还要考虑跨多个迭代、多个团队、多个产品的情况下推进计划和安排优先级，更要考虑团队间的依赖、更大规模地沟通协调、多团队版本控制等一系列的问题，所以要想做好规模化推广，直接复制团队内敏捷的成功经验远远不够。
+
+## 规模化推广的正确方法
+
+关于怎么做敏捷的规模化推广，当前有两个主流的框架，[SaFe](https://www.scaledagileframework.com)（Scaled Agile Framework）和[LeSS](https://less.works/zh-CN)（Large Scale Scrum），这里我不想用大量的笔墨给你介绍它们，如果你对它们的具体内容感兴趣，可以去它们各自的官网了解一下。
+
+而之所以提到这两个框架，是因为它们是如今做规模化推广比较成熟的范式，它们的方法可以为我们提供参考，有很多团队甚至直接套用这两个框架，但我并不建议你这么做，因为它们都有各自的长处和短板，如果你使用不当，反而会陷入敏捷实践的歧途。
+
+其实不只这两个框架，每个框架都有各自的优劣之处，**所以我想和你强调的是，要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，你就可以有选择地拿来使用。就像我在一开始讲敏捷的价值时提到的，是不是冠以敏捷的名称不重要，只要它能帮助我们解决问题就好。**
+
+那规模化推广到底该怎么做呢？我认为，在做之前，还是要从企业或团队的痛点切入，看他们究竟需要解决什么问题。分析具体问题后，你可以从下面这些方面考虑怎么去推广，并形成自己的方案：
+
+- **选择合适的规模化推广策略。**推广时该选择激进式变革还是渐进式改革？其实这两种策略没有优劣之分，你需要结合企业变革的急迫程度、领导支持敏捷推广的力度以及团队能接受的方式来进行选择。
+- **做好敏捷文化铺垫，培养好敏捷的中坚力量。**文化和人员始终都是整个敏捷推进过程的坚实基础，在规模化推广过程中也是如此，所以你也要做好必要的全员敏捷基础培训和核心敏捷人员的能力培养，以便支持更多团队开展敏捷。
+- **搭建适合敏捷的工作环境，做好必要的工具和自动化准备。**适合敏捷的工位布置，必要的物理白板和各种协同管理工具等，这些无论在试点还是规模化推广中都是必要的硬件设施，配合着规模化推广也要有相应的硬件准备。
+- **组织级别的敏捷度量以及持续改进。**你要做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。
+- **重视大型团队的敏捷导入与推广。**这一点是规模化敏捷的核心，因为有的产品需要多个团队共同交付，这就涉及到复杂的团队间的敏捷，因此很多企业在做规模化推广时都会遇到这个问题，这也是我想重点给你讲的部分。
+
+接下来我会结合一个案例，来给你讲具体怎么做大型团队的敏捷导入与推广，做好了这点，我相信你的规模化敏捷之路会更加平稳顺畅。
+
+## 规模化推广实例分析
+
+这个案例来自一家银行，我们姑且叫它D公司，他们的研发团队有接近2000人，在比较顺利地做了试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。
+
+我先分析了他们的痛点，总地来说就是研发效率比较低，无法满足业务发展的要求。他们的问题也很突出，主要有3点：
+
+1. 研发中各个环节的效率有待提升，各个角色的等待时间过长；
+1. 敏捷走到业务那里就卡壳，业务人员参与度低；
+1. 跨团队沟通不畅，协作效率低。
+
+针对问题1，我们在规模化前的试点中，改变了研发模式，让小团队使用了Scrum，很有效地解决了这个问题。
+
+而问题2和问题3涉及的就是大型团队导入与推广敏捷最需要解决的两个问题。要想做好规模化敏捷，主要就是要突破这两个问题。
+
+那么该如何解决这两个问题呢？
+
+针对问题2业务人员参与度低这个问题，其实就是D公司在推广时忽视了业务这一环。
+
+你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一个小胜利，最重要的是要走向业务敏捷。只有业务敏捷了，我们才能和IT团队一起真正打通研发整个过程的敏捷，才能在短时间内快速交付业务价值。
+
+**因此，大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。**
+
+所以针对问题2，我们主要通过两个方法来解决。
+
+第一是**定制度。**确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中心的管理。只有这样，才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往一处使”，从而方便团队做好研发全链条的敏捷。
+
+第二是**定反馈机制。**在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样做的好处是为端到端的研发过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。
+
+针对问题3跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。
+
+我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？
+
+**因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。**这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟通和无谓的等待。
+
+由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探索团队间的敏捷，带你做好这关键的第一步。
+
+所以针对问题3，我们主要是**建立沟通机制，对齐团队目标**，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和高效了。
+
+具体的措施是定义了一系列关于产品团队内以及与Scrum团队间的沟通策略和沟通机制，定期的产品集体计划会议，并将团队间的依赖放到看板上，通过Scrum of Scrum来定期沟通进展。其它还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等等。
+
+把这两个问题解决好以后，D公司根据自己的情况优先选择了做管理实践的规模推广，又在工具和自动化方面做了更多工作。考虑到要做敏捷的长期实践规划，我们又通过培养核心人员，也即内部敏捷教练来延续企业的敏捷文化，具体的举措，你可以参考后续[09](https://time.geekbang.org/column/article/185502)的文章来看。这样他们的规模化敏捷工作就开始平稳地推进下去。
+
+最近我又对他们进行了电话回访，发现几年以后的今天，他们内部已经完成了规模化敏捷1.0，目前正在循序渐进地推进规模化敏捷2.0，重点放在DevOps方面的建设。据其核心负责人反馈，他们一直在做持续改进，我为他们的持续性探索而开心，因为这也是敏捷的本质所在。
+
+## 总结
+
+好了，现在我想总结一下今天这节课的内容，以利于你更好的理解。
+
+敏捷的规模化推广不是去简单拷贝试点经验，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在这个过程中，成熟的规模化框架可以给予我们参考。
+
+规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷这两点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局，从推广策略、文化、环境等方面完成整个规模化推广的持续改进。
+
+敏捷的推进不是一帆风顺，但是走到了规模化推广这一步，我想由衷地恭喜你，因为这意味着你的敏捷实践已经克服了很多困难并取得了一定成果，我相信只要你以更加坚韧的心态和努力的态度去不断检视、改善自己，坚持下去，你的敏捷实践一定会取得更大的成功。
+
+## 思考题
+
+现在，我想请你来思考一下，假设你在一个大型的研发组织里，你会怎么做敏捷规模化推广呢？你有成功或失败的经历吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。