主页

索引

模块索引

搜索页面

说透敏捷

开篇词

敏捷案例集:

左边写你以前在研发管理方面的做法和困惑
右边写你学习过程中了解到的做法以及你想到的新做法

原理篇 (2 讲)

01| 如何利用敏捷思维更好地解决实际问题

备注

我们现在已经进入了 VUCA 时代，我们正面对着一个易变（Volatility）、不确定（Uncertainty）、复杂（Complexity）和模糊（Ambiguity）的世界，而敏捷快速响应变化、允许试错、小步快跑的特点无疑是很能应对时代变化的。

瀑布模型

瀑布模型经常在以下 3 个方面饱受诟病:

1. 研发周期过长，导致研发跟不上业务发展的节奏
2. 研发不能很好地响应需求变化，导致客户满意度低
3. 不能很好地管控风险

人员培养的问题

态度转变:

让员工进到我们的转型过程，有参与感，同时也要意识到自己的能力需要提升，这样很多员工都有提升的动力

能力提升方法:

组织拆书会等等快速地了解一个领域的知识
互相之间分享，老带新，反讲，建立辅导机制，能力高的辅导能力低

思维方式转变:

仅靠口头说服是远远不够的
所以除了宣讲以外，采取的方式有很多：带他们参观已经转型的团队，有一些感性认识；必要的时候带他们打个胜仗，团队在不同阶段需要的辅助也是不同的

实例

2012 年，我到一家初创公司去做项目管理。这家公司的研发中心有七十多人，我一到任，就听到来自业务部门的各种抱怨。在和他们业务部门副总交流时，他对我说：“宋经理，你们研发部门交付特别慢，一个需求我们要等好几个月，等做好了，我们的推广时机也过了。做得慢不说，做的东西也真是不怎么好，做好了给我们看时，我发现做的根本不是我想要的东西……”他给我讲了一通问题，并殷切希望我的到来能给公司的研发带来新的改变。 我决定在接下来的一周，调研一下，看看怎么应对。看了一圈，我发现这个研发中心在刚开始运作时没有任何流程，也没有任何章法，研发过程很随意，出了很多生产 Bug。于是在公司总经理的要求下，大家做了一套流程，本想认真执行，结果执行下来效果也不好，不仅交付速度变慢了，做的需求也不符合业务的要求。 怎么回事儿呢？原来他们用的是瀑布模型，有了前面的经验，我说服了公司领导，带着这个研发中心做了敏捷转型。 那么，我是怎么做的呢？我先给研发中心和业务部门的所有人都做了培训，又将组织做了变革，将他们分成了一个个特性团队；接下来，我把大需求拆分成小需求，对需求列表进行梳理，排列优先级；最后，我又让业务部门参与进来，迭代地进行研发，每个迭代结束后交给业务人员验收和提反馈。 使用敏捷后的效果还不错，我们的需求流动快了，研发效率提升了，Bug 减少了，业务部门满意了，还博得了公司总经理的赞许。

02| 敏捷到底是什么

敏捷的价值观：正确理解敏捷的初心

2001 年，17 个轻量级方法论的大师在美国的犹他州，发布了敏捷宣言，阐释了它的 5 条价值观:

个体和交互胜过过程和工具。
可以工作的软件胜过面面俱到的文档。
客户合作胜过合同谈判。
响应变化胜过遵循计划。
虽然右项有价值，但我们更重视左项。

与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但要注意，这并不是说让你停止做右面的内容。敏捷的价值观并未否定或贬损 “右项” 的价值，“流程和工具”“ 详尽的文档”“ 合同谈判” 以及 “遵循计划” 这些右面的内容也很重要，在敏捷里并不是完全不做。

比如在敏捷实践中也是有计划的，只不过它计划的方式与传统瀑布模式的计划方式不一样罢了。敏捷重视可工作的、有价值的软件，减少一切不必要的文档。注意，是不必要的文档，而不是所有文档。

敏捷的价值观体现了敏捷的初心，只有正确理解它，你才能更深层次地理解敏捷。它的初心是通过一系列方法来让我们的研发工作更加灵活、有序和高效，所以它的价值观重视人的能动性，强调人与人之间的协作，也更重视对变化的应对，这些都是为了能够更好、更灵活地组织和管理研发工作。但如果 “流程和工具”“详尽的文档”“合同谈判” 以及 “遵循计划”，同样能让研发工作更有序和更高效，那敏捷是不反对的，也不会放弃不做，这才是敏捷的真谛。

敏捷的原则：正确理解敏捷的基石

备注

只有价值观还不够具体，为了能更具体地指导工作，由它的价值观又引出了 12 条原则

敏捷的 12 条原则:

我们最优先要做的是，通过尽早地、持续地交付有价值的软件使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率地传递信息方法，就是面对面地交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会针对如何才能更有效地工作进行反省，然后相应地对自己的行为进行调整。

敏捷中的 “快” 其实指的是反馈更快，反馈更及时。这样，我们就能更快、更准地得到客户的真实反馈，也能尽早修正。在这个过程中，客户也可能会更早一点想清楚自己要什么样的产品，你也可能更早达成客户的目标（这里你也要注意，是有 “可能”，而不是 “一定”）。但这绝不是通过快速写代码来完成的，而是通过不断检视客户的需求，总是优先做最有价值的事和减少浪费来完成的。

怎么才能保持 “可持续的开发速度” 呢？我看到能做到这一点的开发团队，通常都是这样做的:

他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。
严格遵守纪律。他们在迭代开始以后，原则上不会再增加需求，如果一定要往他们的迭代待办事项列表里增加其它需求，就要同时从中拿走等量的需求

敏捷的方法：正确落地敏捷的基础

初提出敏捷这个概念的时候，建立敏捷联盟的 17 位大师就创立了一些敏捷方法，这包括:

极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发，以及水晶方法等

关于规模化敏捷的方法，比如说:

SaFe 和 Less

技术实践，比如:

测试驱动开发

备注

凡是符合敏捷价值观和原则的方法论，都可以归到敏捷的大伞下。注意：这些方法从共性上来说都遵循了敏捷的价值观和原则，不同的是它们针对了不同的应用场景，比如说 Scrum 在新软件开发中更好用，而看板在维护类的软件开发中更胜一筹。

Scrum 框架:

3 个角色（产品负责人、团队、Scrum Master），
3 个工件（产品待办事项列表、迭代待办事项列表、产品增量），
5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议），
5 个价值（承诺 、专注、开放、尊重、勇气）

Scrum 的约束条件:

在迭代计划会议开始前，产品负责人需要准备好需求条目，使需求达到准入标准；
Scrum 讲究时间盒，包括迭代的周期、各个会议，这些都要遵守时间盒的约定。

针对敏捷的每一种方法，我建议你在使用前，都要问自己 3 个问题:

这个方法能解决什么样的问题？
有没有使用前提？
有没有相应的使用规则？

总结

备注

敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。

单纯说敏捷是一种方法，肯定是片面的；但只强调它的价值观和原则，而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了。

实战篇 (4 讲)

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

只有把这个第一步做好，对自身的情况有个清晰的认识，我们才能针对自身的问题找到适合自己的敏捷方法。

评估诊断的方法步骤

  1. 挑选代表性项目:

    类似抽样调查中的抽样
评估前你需要在企业里选一些具有代表性的项目，可以是业务上有代表性，也可以是研发模式上有代表性
如果只有一个项目，这个步骤可以省略

  2. 访谈评估:

    在划定了需要评估的项目范围后，你需要对这些项目中的团队成员进行访谈，
从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估。
这一步的目的是通过访谈有意识地探查项目的痛点。

  3. 制定转型计划:

    根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。

痛点不同，计划也不同，一定要有针对性地做计划方案。比如:
        团队的主要问题是跨部门、跨团队沟通协作不畅，那在计划中就要优先考虑团队组织的问题，必要时再做组织变革；
        如果团队的问题集中在从开发完成到上线前这一阶段，那么在计划中就要优先考虑建设 DevOps 流水线。

  4. 沟通:

    在访谈评估和制定计划后，在正式进行敏捷实践前，
你需要与相关人员，如团队成员、团队主管，以及推进敏捷的内部负责人等，沟通评估结果和相应计划，以便整个团队达成一致意见。

如果不沟通，大家对目前的现状理解不一致，那在互相配合上就会有偏差；
更严重的是，如果沟通得不好，大家说不定还会互相拆台，这样再好的计划也是没法真正落地的。

总结

评估诊断的目的是为了解自己的现状是什么，了解自己的痛点在哪里，并针对这些问题和痛点，结合短期要达成的目标，找到解决方案，制定合理的计划。

实践

如何让业务人员配合敏捷:

这是个好问题，是业务敏捷的初步问题，在实操中很多公司都有这个问题

有两种解决方式:
        一种是激进式的，把业务人员和开发测试划归到了一个部门管理，成立了事业部，甚至是成立了公司，目标绑定，从上至下推进
        一种是渐进式的，也是大部分公司采纳的，先把自己的研发的痛点解决了，有一些亮点，给业务看。
                把业务的领导前期请到参与到这里面来，给业务领导做宣讲，跟他们一起做业务规划，
                或者请业务领导来给研发讲解业务目标，说研发兄弟配合他们的工作，让业务领导派驻业务代表到研发团队，
                研发进度透明化，让他们定期可以看到产出，对研发有一些理解，可以积极的收集他们的反馈，需求前期业务与开发一起共创，产生创意等等。

在现实中，业务的工作不仅是支持研发，它非常重要的工作是要完成业务目标，所以要争取把这件事情排到他们的工作列表中。
这里面有很多内容，涉及的部门多，领域也比较广，也有跨部门合作的很高的艺术，业务敏捷是后面敏捷的重要趋势之一。

如何在外包项目中使用敏捷:

原则上来说，如果作为需求的提出方客户不关心敏捷的话，那么这个敏捷实施会非常困难

建议在采纳敏捷方法之前，跟客户做好相关沟通，包括:
        基本的敏捷理念传达，敏捷基础培训、在敏捷过程中双方的角色职责、客户的具体参与时点等都做好约定，
否则后面很难实施。

另外就是如果是乙方引导敏捷的话，也要时不时的让客户感受到一点成就感，才能持续下去。

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

试点工作的展开可以分为:

1. 试点前准备
2. 试点推进过程

备注

凡事预则立，不预则废

  1. 选择试点团队:

    采纳敏捷的意愿相对强烈；
业务价值高或采纳敏捷会在短期内给团队带来很大收益。

  2. 前期准备工作细则:

    从 6 个方面去准备：
        组织和人员
                “高内聚，低耦合”的组织适合敏捷
                高内聚指的是日常工作中，全功能小团队内部成员之间的沟通合作更紧密
                低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织结构才更适合推进敏捷
                本质都是为了让小团队内的沟通合作频度更多，也更加顺畅，而团队之间的沟通协作尽量少一些
        管控治理规则
                架构和设计的治理规则，质量管理策略规则
        需求范围
                项目的高阶需求范围、高阶发布计划；
                高阶的史诗级故事；
                近期 2 个迭代要开发的用户故事。
        架构
        方法和工具
        办公环境设施

关键词:

演进式架构
Scott W. Ambler” 提出的 “架构预测 Architectural Envisioning”

书籍推荐:

《Scrum 敏捷项目管理》
《硝烟中的 Scrum 与 XP》
《敏捷回顾：团队从优秀到卓越之道》
《敏捷教练：如何打造优秀的敏捷团队》

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

备注

在推进试点过程中，最重要的也可以说是核心的关键点，就是打造一支活力与战斗力并存的敏捷团队。

一起制订社会契约

  • 社会契约”（Social Contract）:它本指一个社会里的全体成员，为了更好地生活，制定了一些基本准则，大家一起来遵守。用在团队中，指的就是团队里的行为公约，也就是为了让团队中每个成员都能加强协作、发挥价值，一起来约定的一些基本准则。在工作中，如果有任何成员的行为影响了团队协作，其他成员都可以拿这个契约来约束他，这样就可以 “对事儿不对人”，在处理不良行为的时候更有说服力。

落地社会契约的过程，其实就是团队内部相互认可、磨合和协作的过程。

回顾会议，引导团队的自主性

要先说明会议目的，接着让大家讨论三个条目:

团队工作中做得好的地方是什么？
做得不好的地方又是什么？
除此之外，有没有什么其它疑问？

  • 实践方法是团队来用的，行为和习惯的转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易获得团队的认可和接受。所以重要的不是 “你想”，而是 “团队想”

  • 回顾会议是有时间盒的，一般不会超过 1 个半小时。

成绩墙与错题集，记录团队敏捷的成长

  • 首先团队会一直感觉到敏捷氛围的存在，有精气神儿

  • 其次，以后有团队请我们去做宣讲时，我们很快就能找到素材，也能绘声绘色地讲给大家

  • 还有，团队记录的心情曲线、“成绩墙” 和 “错题集”，这些都是试点结束后在做总结时，记录团队敏捷历程的鲜活素材，是团队敏捷实践的轨迹记录。

06 | 规模化推广: 复制粘贴试点的经验就够了吗

规模化推广的正确方法

做敏捷的规模化推广，当前有两个主流的框架:

SaFe（Scaled Agile Framework）
LeSS（Large Scale Scrum）

备注

要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，你就可以有选择地拿来使用

从下面这些方面考虑怎么去推广:

选择合适的规模化推广策略
做好敏捷文化铺垫，培养好敏捷的中坚力量
搭建适合敏捷的工作环境，做好必要的工具和自动化准备
组织级别的敏捷度量以及持续改进
重视大型团队的敏捷导入与推广

以项目” 为中心的管理和以 “产品” 为中心的管理，有什么差异:

产品管理强调 What，也就是做的什么产品。
        重点在需求管理，计划管理，发布管理。
        产品管理既关注产品的具体形式，也关注产品实现的过程，也要对最终使用产品的用户负责。
而项目管理强调 How，怎么做，
        主要是任务管理，侧重的是如何实现这些需求。
        项目管理更关心达成项目目标实现的过程。

策略篇 (2 讲)

07 | 填坑指南：填好这 4 个坑，快速做对敏捷

08 | 避雷策略：如何防止你的敏捷变为 “小瀑布”？

管理篇 (2 讲)

09 | 内部教练：守护敏捷实践，求人不如求己

内部敏捷教练为什么重要:

敏捷教练是帮助组织或团队推进敏捷实践的人:
教授（Teaching）
引导（Facilitation）
辅导（Mentoring）
教练（Coaching）

10 | 服务型领导：在敏捷中你该怎样提升自己的领导力

怎样成为服务型的领导:

给员工建立心理安全机制
掌握情境领导能力

给员工建立心理安全机制:

信任是必不可少的。要支持员工和他们的决定，在工作和工作之外都照顾好团队成员；
培养健康的分歧环境。允许分歧存在，在有分歧时虚心听取不同的意见；
建立正确的失败文化。失败是可以接受的，只要从失败中吸取教训，能够改进就好。

掌握情境领导能力:

领导者能在不同的情境下运用不同的领导力来指导和支持团队成员完成目标或任务。

4 种不同的情境:
        情境 1：热情的初学者：能力低、承诺高
        情境 2：幻灭的学习者：能力不是很高，承诺很低
        情境 3：有能力但谨慎的贡献者：能力处于中上等、承诺很低
        情境 4：自力更生的成功者：能力高、承诺高

有两种基本的领导行为:
        指导性行为：告诉其他人应该做什么，何时做，如何做，并经常提供结果反馈
        支持性行为：鼓励、表扬他人自力更生解决问题，倾听意见，并让他人参与决策

领导风格:
        风格 1：指导。高指导行为和低支持行为
        风格 2：教练。高指导行为和高支持行为
        风格 3：支持。低指导行为和高支持行为
        风格 4：授权。低指导行为和低支持行为

情境领导力:

设定目标。要运用好目标管理，设立正确的目标，目标的设定要与需要做的事情保持一致；
协同诊断。要会评估员工在特定任务上的能力和承诺，判断他们在这个任务上属于哪一种情境；
学会匹配。根据员工所处的情境，匹配自己所需要运用的领导风格，帮助他们完成工作任务，也为他们个人提供需要的帮助。

结束语

未来的人才一定要具备 6 个能力:

健康力、交往力、学习力、专注力、批判力和创造力

书单:

《敏捷教练：如何打造优秀的敏捷团队》
《敏捷软件开发：原则、模式与实践》
《Scrum 敏捷项目管理》
《硝烟中的 Scrum 与 XP》
《敏捷回顾：团队从优秀到卓越之道》
《团队协作的五大障碍》
《用户故事与敏捷方法》
《持续集成》
《持续交付》
《Devops 实践》
《有效的单元测试》
《测试驱动开发》
《重构》
《代码整洁之道》

主页

索引

模块索引

搜索页面