《说透敏捷》是极客时间上的付费课程，里面有很多案例，如果想学习敏捷知识，建议去购买。以下是我在学习过程中的笔记，并不是原文。
01 | 敏捷有很多益处，但不是万能的
敏捷是一场变革，它本身涉及人的习惯、团队文化的改变等等，它的核心点是持续改进。它有一定的章法，但是若想运用好它，又不能拘泥于它的章法。使用敏捷的目的是解决问题，若用其他办法能解决问题，也可不必使用敏捷的方法，千万不要为了敏捷而敏捷。总之，能够更好地解决问题就好。
1. 瀑布模型
研发的整个工作流程是按顺序进行的。即先做需求调研，再做开发、测试、验收和上线，所有工作都是串行的，只有达到下一步的准入标准，我们才进行下一步工作。瀑布模型是 1970 年提出的，盛行于20 世纪 80 年代。瀑布模型使开发人员感受到各种束缚，研发效率受到阻碍。
2. 瀑布模型的缺点
研发周期过长，导致研发跟不上业务发展的节奏。在瀑布模型中，所有的工作都是串行的，只有前序环节完成，才能展开后序环节，大量人力与时间成本都在这段时间里被白白消耗，等产品开发出来推向市场，很有可能市场已经没有了，或者业务已经发生了很大变化。
研发不能很好地响应需求变化，导致客户满意度低。我们很难在设计之初就把所有的需求想清楚，需求又是不断变化的，客户在看到真正的产品之前，对产品很可能是无感的。瀑布模型是在项目最后才一次性地向客户交付产品，这时客户才发现他们需要的不是这个东西，这是非常可怕的事情。
不能很好地管控风险。因为是研发最后一次性交付，所以项目中的很多风险在前期很难被完全识别出来，最后发现时再想处理就要付出更大的代价。
软件研发具有强烈的不确定性。而瀑布模型，其流程和步骤都是规定好的，且计划与生产分离，更适合确定性高的工作。在这种不确定性很高的研发工作面前，我们以处理确定性高的工作的方式和流程来进行管理，毫无疑问是不奏效的。
3. 针对瀑布模型的改进
组织结构：我们的团队应该由一个个小的团队组成。团队是固定的，成员也基本是固定的，这样我们不需要花费时间去组建团队，磨合团队。
需求梳理：边梳理边跟客户交流。不要花几个月去梳理并在最后才给客户看我们梳理的结果。要把需求按优先级排序形成需求池，迭代地进行研发。
让客户积极地参与我们的研发过程。包括前期的需求调研和后面的开发测试上线，迭代有产出时就让客户验收，让他们提意见，以便我们在后面的迭代随时调整。
4. 不适合做敏捷的情况
产品本身的容错率很低，不允许试错；用敏捷的话与投入产出不成正比；公司需要深远地考虑战略问题。
02 | 敏捷到底是什么？
敏捷的误区
1.敏捷就是再也不用写文档，不用做设计了。我们只负责写代码。
2.敏捷就是快。原来 6 个月才能完成的项目只用了3个月就完成了。
3.敏捷就是加班。采用敏捷后，我们比原来加班更严重了。
4.Scrum 就是敏捷，敏捷就是 Scrum。
5.敏捷是自由的、无约束的。不需要那么多条条框框，跟随自己的心来做就好了。
敏捷的价值观
1.个体和交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划
5.虽然右项有价值，但我们更重视左项（与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但并不表示停止做右面的内容）
拨乱反正
1.敏捷重视可工作的、有价值的软件，减少一切不必要的文档。注意是不必要的文档，而不是所有文档。不必要的文档：交接类文档，比如提测文档。必要文档：系统设计文档、接口文档、数据库设计文档等。
2.敏捷的快不是指敲代码的速度加快了。敏捷的快是针对交付，尽早交付可用的软件给客户，而不是最后一次性交给客户，并且交付的间隔时间越短越好。所以敏捷中的“快”指的是反馈更快，反馈更及时。敏捷的原则下，客户的目标达到才意味着项目可以结束，短迭代使客户对自己的需求更清楚了，有可能做的事情更少了，所以时间才减少了，交付也更快了。
3.“敏捷就是加班”这个理解有失偏颇。敏捷原则第8条：“敏捷过程提倡保持长期的、恒定的、可持续的开发速度”，不是为了加速开发而加班，透支团队成员的健康。
如何保持可持续的开发速度呢？
1.迭代开始的时候，不要过度承诺，能完成多少工作，就承诺多少工作。
2.严格遵守纪律。迭代开始之后，原则上不再接受增加需求，如果一定要增加，就要从迭代中减少等量的其他的需求。
敏捷的原则
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单——使未完成的工作最大化的艺术——是根本的。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷的方法和实践
敏捷方法包括：极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法等等。规模化敏捷的方法，比如SaFe 和 Less；技术实践，比如测试驱动开发。这些方法都遵守了敏捷的价值观和原则，不同的是它们针对了不同的应用场景，比如说 Scrum 在新软件开发中更好用，而看板在维护类的软件开发中更胜一筹。
Scrum 框架的“三三五五”：3 个角色（产品负责人、团队、ScrumMaster)，3 个工件 (产品待办事项列表、迭代待办事项列表、燃尽图），5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议），5 个价值（承诺 、专注、开放、尊重、勇气）。
Scrum 的约束条件：1.迭代计划会议开始前，产品负责人需要准备好需求条目，使需求达到准入标准；2.Scrum 讲究时间盒，包括迭代的周期、各个会议，这些都要遵守时间盒的约定。
建议使用敏捷每一种方法前问自己3个问题：1.这个方法能解决什么样的问题？2.有没有使用前提？3.有没有相应的使用规则？
敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。
03 | 敏捷成功第一步：评估诊断
评估诊断的4步
第一步：挑选代表性项目。可以是业务上有代表性，也可以是研发模式上有代表性的项目。如果企业的项目囊括了大、中、小型项目，建议把大、中、小型项目各选一个来进行评估。
第二步：访谈评估。对选定项目中的开发、测试、运维、需求、项目管理人员等人员，依次进行访谈，主要是为了全面了解项目的研发流程，了解每个角色在研发活动中的工作情况，也了解各个角色之间的协作情况。从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估，有意识地询问和探查项目的痛点。
第三步：制定转型计划。根据发现的问题和痛点，做推进敏捷的计划，痛点不同，计划也不同，要有针对性地做计划方案。比如团队的主要问题是跨部门、跨团队沟通协作不畅，在敏捷计划中就要优先考虑团队组织的问题，必要时做组织变革；再比如团队的问题集中在从开发完成到上线前这一段，在计划中就要优先考虑建设 DevOps 流水线。
第四步：沟通。在访谈评估和制定计划后，正式进行敏捷实践前，需要与相关干系人，例如团队成员、团队主管，以及推进敏捷的内部负责人等，就评估结果和相应计划进行沟通，以便整个团队达成一致意见。
04 | 试点前准备
选择两个或两个以上、采纳敏捷的意愿相对强烈、业务价值高或采纳敏捷会在短期内带来很大收益的团队进行试点。
前期准备工作细则：
组织和人员准备。组织结构要高内聚、低耦合。高内聚指全功能小团队内部成员之间的沟通合作更紧密；低耦合则指团队之间的沟通协作要远比团队内部的少。团队人数被限制在5-9个人，每个团队都有产品经理、开发、测试等人员。敏捷培训：进行敏捷思想基础和敏捷实践基础两门基础课程培训；组织拆书会，选择一些敏捷基础的书籍，每个人都来读一节，一起来分享。宣讲：如其他公司是怎么做敏捷的，取得了什么成效等。随时讲解：需求条目化、怎么做用户故事及如何拆分。
管理治理规则准备。如架构和设计的治理规则，质量管理策略规则等。
需求范围的前期准备。项目的高阶需求范围、高阶发布计划；高阶的史诗级故事；近期 2 个迭代要开发的用户故事。用户故事要有优先级排序，要有故事描述，还要有验收标准。
架构上的准备。通过召开建模的头脑风暴会议，讨论系统的功能特征，并思考实现这些特征的高层设计策略，从技术图表、用户交互流程图、领域图和变更流程图四个方面建模。
敏捷方法和工具的准备。管理实践上选择 Scrum 方法，在技术实践上可选择单元测试、自动化回归测试，还有搭建 DevOps 流水线。
办公环境设施的准备。如果项目中有人员是远程的，则需要准备必要的音视频设备，远程会议工具；如果项目都在一个区域，就还要有适用于敏捷开发的办公环境，如物理看板和开放式的工位等等。
05 | 试点推进过程
重组后的团队还不是一支无往不胜的团队，我们需要想办法唤醒、激发团队，让整个团队更有活力和战斗力。
一起制定社会契约
为了让团队成员加强协作、发挥价值，一起约定的基本准则。工作中，若有人的行为影响了团队协作，其他成员都可以拿出这个契约来约束他，从而做到“对事不对人”。
制定的过程：分发贴纸，静默5分钟，思考：“你认为加强协作、达成团队目标，需要哪些行为准则？”。一张贴纸只写一条准则，写好准则的贴纸贴到白板上；白板划分为不同区域，把内容相似的贴纸归在同一个区域。逐条读贴纸上的准则，询问大家是否同意，如果有人不同意，就停下来讨论，如果讨论的结果还是有人不同意，就放弃它；如果大家都同意，就将该准则保留下来。
落实契约。“社会契约”要张贴到所有团队成员都可以看到的地方，以便整个团队时时可以看到它，感受它带来的激励和约束。
回顾会议，引导团队的自主性
先说明会议目的：“检查调整”。接着讨论：团队工作中做得好的地方是什么？做得不好的地方又是什么？除此之外，有没有什么其它疑问？
分发贴纸，静默5分钟。一张贴纸只写一条，写好的贴纸贴到白板上；白板划分为不同区域，把内容相似的贴纸归在同一个区域。接着讨论这些问题，做得好的地方就可以保持下去，做得不好的地方可以头脑风暴去改善，并做一些行动计划。
会议时间不能超过90分钟。
成绩墙与错题集，记录团队敏捷的成长
06 | 规模化推广
规模化推广≠直接复制试点经验
一、两个框架
SaFe（Scaled Agile Framework）和 LeSS（Large Scale Scrum）。要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，我们就可以有选择地拿来使用。
二、如何做规模化推广
从痛点切入，再从以下五方面规模化推广敏捷：
1. 选择合适的规模化推广策略。推广时该选择激进式变革还是渐进式改革？这两种策略没有优劣之分，你需要结合企业变革的急迫程度、领导支持敏捷推广的力度以及团队能接受的方式来进行选择。
2. 做好敏捷文化铺垫，培养好敏捷的中坚力量。要做好必要的全员敏捷基础培训和核心敏捷人员的能力培养。
3. 搭建适合敏捷的工作环境，做好必要的工具和自动化准备。适合敏捷的工位布置，必要的物理白板和各种协同管理工具等。
4. 组织级别的敏捷度量以及持续改进。你要做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。
5. 重视大型团队的敏捷导入与推广。这一点是规模化敏捷的核心，因为有的产品需要多个团队共同交付一个产品，这就涉及到复杂的团队间的敏捷。
三、大型团队敏捷的导入和推广
1. 可能遇到的问题：敏捷走到业务那里就卡壳，业务人员参与度低；跨团队沟通不畅，协作效率低。大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。
2. 定制度。确立产品负责人制度，将以“项目”为中心的管理改为以“产品”为中心的管理。
3. 定反馈机制。在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。
4. 建立各团队间的敏捷实践，就需要提前安排支持工作。这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理。
07 | 填坑
坑一：团队说他们不想做敏捷
原因：
1.团队没有真正理解到底什么是敏捷、敏捷能给他们带来什么切实有效的帮助；
2.团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；
3.团队中有人一言堂，这个人的意见不改变，其他人不敢动。
解决：
不了解和分析现状就直接推进敏捷是非常不靠谱的，必须看清现实，摸清项目的痛点，在解决痛点的基础上导入并推进敏捷才是可行的。
坑二：不理解敏捷实践背后的意义，把敏捷当作一种新的流程，而忘记敏捷的核心是持续改进
原因：
1.公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；
2.缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。
解决：
基础培训；找一个靠谱的敏捷教练陪伴。
坑三：Scrum 过程被严重缩减，只剩下每日站会
原因：
没有培养出属于自己的合格的 Scrum Master。导致敏捷教练或scrum master撤出后，敏捷的火种无人守候，敏捷随之偃旗息鼓。
解决：
1.要认识到 Scrum Master 的重要性。团队还不成熟的时候，他负责宣讲敏捷的价值观、理念，也负责具体实践的导入和守护。好的 Scrum Master 在引导、教育、辅导、教练这四个方面都有很强的能力，并能根据具体的情景选择使用哪种能力来帮助团队体验敏捷带来的益处，坚定维持团队新养成的敏捷习惯。在领导力方面，他具有服务型领导的理念，是团队的主心骨，在构建敏捷文化等方面对推进敏捷具有很大的意义。
2.在基层留有敏捷的火种。在推进敏捷实践之初，团队就应该计划 Scrum Master 的培养活动，识别出优秀的 Scrum Master，然后相互配合着推进敏捷；每周举办 Scrum Master 工作研讨会，让 Scrum Master 学习和实践上文讲的 4 种能力。在敏捷实践后期，由 Scrum Master 来负责进行团队引导等工作，并听取敏捷教练的反馈意见，这样在敏捷教练离开之后，培养好的 Scrum Master 就会接过敏捷的大旗，专心引导和辅导团队，在团队遇到困难时及时帮助解决。
坑四：筒仓中的敏捷
筒仓指的是部门各自为政，不好协同。
可能遇到的问题：
1.产品业务部门没有协同，因此对需求的分析理解还是极其缓慢，每次到迭代开始时，需求都准备不好，打乱开发的节奏；
2.上线运维部门也与开发测试部门割裂，导致虽然开发测试做得很快，然而到了上线那一步又变慢了，最终拖慢了整个进程。
解决：
1.前期应该多宣讲敏捷的本质和好处，尤其应该推动对高管层面的宣讲，并成立更高级别的敏捷实践督导团队。当高管层面理解到敏捷的好处和他们应该做的事情之后，就不会成为推进敏捷的桎梏，而能及时为敏捷提供必要的帮助。
2.推进敏捷时要通盘考虑整个链条应该怎么推进。
3.敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，应及时去除。
08 | 如何防止敏捷变为小瀑布
小瀑布
大项目或需求做一个模块拆分，然后一个一个模块做下去，和瀑布模式相比，这种方式有了一点进步。然而，究其本质，仍然还是瀑布，我们一般称它为“小瀑布”。
真正的敏捷
团队会尽可能有效拆分需求，进入到迭代内的需求是多个独立的小需求。小到每个需求都可以在很短的时间内，比如 2～3 天内完成开发和测试，最长也不要超过一个迭代周期。
这样在开发人员写代码的时候，测试人员在写测试案例，或者在考虑使用自动化测试方案。由于需求拆分得足够小，很可能第一个小需求在迭代后的第二天就可以交付测试了，在测试人员测试这个需求的同时，开发人员继续开发下一个小需求，由此形成一个良好的循环。在这种情况下，大家都在热火朝天地工作，节省了很多等待的时间。
避免敏捷做成“小瀑布”？
首先要给予团队在敏捷知识上的宣贯，在使他们充分了解敏捷的基础上，对他们进行技能上的培养。
其次，挑选好并先从有价值的、优先级最高的需求开始做。
在敏捷实践中，我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完。这些工作不一定是之前就被纳入计划的，但却一定要是客户最需要的。
需求拆分
需求拆分的方法有很多，例如按照业务流程、按照业务规则的变化或按照数据的处理方式进行拆分等等。不管是使用哪种拆分方法，做需求拆分的目的，都是把大需求拆成一个个能够独立开发测试的小需求。只有这样，我们才能在迭代中同时做几个小需求，而不需要等待，并且在测试完成后，这些小需求也能独立上线。
若需求经过拆分后还是很大，无法在 2 周内做完，这种情况怎么办呢？这时就需要深度的挖掘一下背后的原因，采用相应的应对策略。如系统架构比较老旧，代码的耦合度较高，依赖性大，要完成一个需求甚至要改很多个系统，这对于产品交付来说明显是一个很大的障碍。
如遇以上问题，可在开发测试工作之余，对该产品进行架构演化，拆分微服务。为了能顺利开展这些工作，团队用 70% 的时间进行新需求的开发，用 30% 的时间进行架构演进。
08 | 参考资料
网络资源：scrum中文网
书单：《敏捷革命》《用户故事与敏捷方法》《敏捷教练：如何打造优秀的敏捷团队》《敏捷软件开发：原则、模式与实践》《scrum敏捷项目管理》《硝烟中的scrum和xp》《敏捷回顾：团队从优秀到卓越之道》《团队协作的五大障碍》《持续集成》《持续交付》《Devops实践》《有效的单元测试》《测试驱动开发》《重构》《代码整洁之道》
网友评论