很多公司做不好敏捷，其根本原因只停留在理论阶段，只知道MVP,TDD等抽象概念。不知如何结合公司的实际情况，从哪个节点或项目引入敏捷项目管理。
本文主要分3个部分进阶的方式讲解敏捷项目管理。

结合腾讯内部的敏捷案例来了解敏捷方法（比如Scrum、DSDM等），从实际中系统化的理解敏捷。
讲解公司是否适合做敏捷导入、如何找到适合公司的敏捷方法、如何让团队具备敏捷思维、如何让团队自组织、如何做好敏捷的实践落地。
聚焦敏捷导入的常见问题及解决方案。比如敏捷团队的绩效度量怎么做、如何说服领导从0到1导入敏捷，帮你解决敏捷导入过程中的“形而上学”和“无法落地”的问题。
最后讲解ACP认证攻略。

你将get到以下思维

快速试错思维，不断去审视自己，用成长思维成就个人。
价值驱动思维，认清自己对于公司的价值，明确职场道路。
自组织型方法，巧用授权，放手让团队去干，优化分工协作。
客户合作思维，让客户参与产品的改善中来，真正站在客户的角度理解需求。
透明化的工具，帮助异地团队打破沟通壁垒，高效协同。

哪些人适合敏捷思维

想转型或者已经被推上项目经理或管理岗位的技术人，你可以在这里掌握敏捷方法，用敏捷实践帮助提高团队效率，把控全局。
项目管理从业人员，但是项目管理知识并不系统，实践中缺少灵活性，需要敏捷实战案例丰富自己，这个课程可以帮助你系统复盘敏捷知识，灵活运用敏捷。
敏捷实践者，虽然项目经验丰富，但是缺少统一的行业语言和坚实理论支撑，你可以系统化学习敏捷思维，并学以致用，形成自己的方法论。
想要转型做咨询的敏捷教练，这个课程可以让你掌握敏捷实践落地的技巧，让你的敏捷理论变得更加“实干”。

初识敏捷

腾讯敏捷管理的心路历程

马化腾在访谈中说过"腾讯做战略从来只看3年"。也就是说，现在这个时代唯一可以确定的就是他一直在变化中。我们称这个时代称为VUCA时代。

Volatility（易变性）：我们需要考虑如何适用这种多变的环境。
Uncertainty（不确定性）：我们的产品越来越具有不确定性，用户今天可能昨天喜欢我们的产品，今天竞品出来可能就不喜欢我们的产品了。
Complexity（复杂性）：影响产品成功有非常多因素，包括好产品，品牌，营销，市场，资本等。每一个因素都可能直接影响产品的成败。
Ambiguity（模糊性）：因为左右产品是否成功的决定性因素太多，那么团队对需要达成的目标就会非常模糊，领导对团队所做的事情能否达成目标也会没有信心。

也就是说，当下的商业格局和企业生态就处于 VUCA 环境中，所有的公司或团队都有可能正在面临着上述困境而无法破局。如果想要在这次变革中获得胜利，那么往往需要具备快速交付价值及灵活应对变化的能力，我们来看看腾讯是怎么做的。

腾讯怎样落地敏捷

从我党的“解放思想”开始。当时敏捷在Google及Facebook公司都已经取得了不错的成就。腾讯决定向国外学习，引入国外咨询教练团队，让有经验的专业团队帮助导入敏捷思想。
从“试点”项目开始。具体的做法是从一个试点项目开始导入，一个试点初显成效以后再逐步推广到其他部门。这个推广过程并不是自上而下的，也就是说没有任何一位领导指定必须做这些事情，而是各个部门按照自己的需求和实践情况进行导入。
预先善其事必先利其器。腾讯自研TAPD，辅助敏捷导入。
（1）看板，能够直观地展示团队的进展。
（2）流程配置，能适用不同团队的敏捷过程。
（3）任务流转，能让团队更好地自组织起来。
（4）报表系统，能让领导更清晰地看到团队的目标和执行过程。

腾讯的敏捷是从QQ空间开始的。为什么是从QQ空间开始，这主要有三因：
（1）QQ 空间是 Web 页面开发，发布方式很灵活，不需要更新客户端，随时可以发布新版本，用户无须手动更新或者下载，也就是做到了用户无感知；
（2）QQ 空间不是主营业务，如果转型没有成功也不会影响公司的主营收入。
（3）QQ 空间作为一款新出的产品，没有稳定的用户群，也没有类似的产品可以参考， QQ 空间在挖掘用户需求方面比较困难，也就是说无法精准地找到用户的痛点，因此这个团队都希望引入新的方式来改变现状。

QQ空间团队首先运用了敏捷的Sprint，从滚动迭代开始做起，团队保持每周一个新的版本，发布完后，取得用户反馈，再根据用户反馈快速响应和优化。因QQ空间取得了不做的效果，随后QQ农场和QQ浏览器团队也相继进行了敏捷转型，最后在整个tencent推广开来。

细看腾讯游戏部门敏捷转型

手游的特点让它天然就合适以敏捷方式进行开发，我们来看看手游开发的特点：

团队规模小，开发周期短：三五个人的团队，两三个月，就可以做一款简单的单机游戏；
需求变化快：由于手游下载很方便，所以用户很容易获取，也就很容易放弃，如不能持续满足用户新的需求，很容易被淘汰。

主要方式：
3. 把控手游质量。我们引入了敏捷“客户合作”的价值观，通过短周期迭代，尽早发布版本让用户体验，让用户加入我们的整个产品生产环节。这样做的好处是：
（1）让用户有参与感，他们感受被需要了；
（2）能尽早验证我们的产品是否是用户满意的；
（3）及早优化需求，降低了需求优化的成本；
（4）减少因为返工带来的浪费；
（5）对外提高了产品质量。

把控迭代效率。腾讯研发了名为SODA的持续集成工具。它可以帮助我们在代码提交的那一刻让程序自动编译，编译成功自动测试，测试完后自动部署，这样节省了人力，提高了迭代效率。这样做有如下好处：
（1）自动编译测试部署一步完成，时间至少减少了三分之二。
（2）开发人员能及早发现并解决问题，降低了修复问题的成本。
（3）产品人员每天都能验收版本，大幅度减少了需求实现完成不合格的返工时间。

这样我们开发周期从过去的两年缩短到8个月，并且也满足了客户的需求。

敏捷内容

区分：敏捷、精益和看板方法

精益方法多用于企业管理，是面向全局的战略级的方法。而敏捷和看板方法多用于产研团队，是面向组织级的。可以把敏捷方法和看板当做精益法的子集。因为敏捷和看板方法是精益思想的具体实践。都反应了“关注价值”，“批量”和“消除浪费”等概念。

而它们的区别在于：看板方法适用于局部改善，更加关注团队的瓶颈和关键点。并逐个消除瓶颈来提升效率，像升级打怪一样。对组织结构不会有影响，所以实施阻力小。但是敏捷是面向组织全体的，对产品团队的项目组织结构有要求，需要改变原来职能型的组织结构，以项目制的方式，把产品、开发、测试、运营等组成一支为业务目标负责，可以端到端交付的团队，敏捷更注重最后交互的结果。
在这里插入图片描述

敏捷的三把利剑：价值观、原则和实践

敏捷的最终目的是让我们形成敏捷思维，并将该思维结合实际付诸实践。
敏捷思维是由价值观和原则构成，并在敏捷实践中体现出来的。其中，价值观定义敏捷思维模式，敏捷是以最终产生的价值为导向的。原则作为行动方针。实践就是具体应用的过程。

敏捷的内容包括：四大价值观、十二大原则和实践

四大价值观

四大价值观即是敏捷宣言的内容：

个体和互动高于流程和工具。（所以鼓励团队内成员相互间多交流）
工作的软件高于详细的文档。（软件如接口文档，可以写到conflunce上，或者直接使用swagger，而不一定是doc文档）
客户合作高于合同谈判。（产品是让双方利益达成高度合作的）
响应变化高于遵循计划。（只有不断变化才能快速满足客户需求）

敏捷开发是用来应对 VUCA时贷不确定性商业环境的方法和实践。敏捷宣言是敏捷的价值观，它告诫我们：

敏捷方法是源于实践积累，我们需要把握敏捷的核心，在实践中不断探索更好的方法。
敏捷方法来源于实践，它应该归于实践，帮助我们解决实际问题，而不是框住我们思维的框架。

十二大原则

敏捷宣言是高度凝结的思维，而后依据这4条思维衍生出了更具体的十二大原则。如下：

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求的变更，即使在开发后期也一样要接受。不要沮丧而影响进度。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。在京东，一个月一个产品一般大好几十个版本需要上线。记得有一个月上线了70多个版本。
业务人员和开发人员必须相互合作，每天都必须如此。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。一定要保持消息畅通。文字沟通因表述不清而产生歧义。
可工作的软件是进度的首要度量标准。保证交付物的质量为首要前提。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。刚去一个新公司时，当时任务艰巨，导致整个团队一个项目下来，心身疲惫。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。良好设计必须是以开放包容的心态为前提，吸收团队中每个人的精华。
以简洁为本，它是极力减少不必要工作量的艺术。要有极简的追求，往往最好的产品就是最简单易懂的产品。
最好的架构、需求和设计出自自组织团队。只有该团队对自己的业务更加了解。
团队内定期反思如何提高成效，并依此调整自身的举止表现。

敏捷实践

敏捷方法主要包括了 Scrum 方法、DSDM 方法、水晶方法、特性驱动方法和 SCRUMBAN 等等。

Scrum

Scrum是现在最流程的敏捷方法，它主要是面向开发和复杂产品的。可以通过3355来全盘概括。意思是3种角色、3种工件、5种仪式和5种价值观。Scrum的难点不在于框架知识，而在于如何运用实践。想要掌握 Scrum，就需要你坚持使用，在不断的实践中升级本领，丰富的实践经验就会帮你见招拆招，解决遇到的问题。
在这里插入图片描述

DSDM

DSDM 就是动态系统开发方法。它的具体实施思路是这样的：在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一般需求固定，时间和资源可变），然后交付所需的系统。对于交付系统的要求，必须达到足够的稳定程度，确保可以在实际环境中可靠运行；对于业务方面的某些紧急需求，必须做到在足够短的时间内满足，并在后续迭代阶段中对这些功能进行完善。这个在医美项目中就是用的这种方式，最大程度保证业务及市场试错能力。

特性驱动方法

特性驱动方法简称 FDD，它是一个模型驱动（model-driven）、短期迭代（short-iteration）的过程，也就是说 FDD 是一个开发过程，过程就有起点和终点，FDD 的起点是创建一个全局的模型轮廓，通过两周一次的"特性设计-特性实现"的迭代，逐渐丰富模型功能内容。

特性驱动方法在平常地工作中使用较多。它最大的特点是需要一个全面的架构，这意味着设计和建模已经非常清晰了，所以它比较适合不需要试错的产品，也就是说需求范围很确定的项目。比如合同制项目中，乙方承接甲方的开发项目时，乙方会清晰的告知你需求，而你只要按照需求做出产品即可。腾讯的很多游戏就是采用的这个方法，比如欢乐斗地主这款游戏。

自适应软件开发方法

定义
（1）基于复杂自适用系统理论，改善软件推测、协作和学习过程，建立新的价值观：自适用比优化重要。
（2）关注人（技能）和交流，将开发过程放在第二位，关注工作的软件而不是文档，它强调和客户协作及对变更的适应；
（3）定义以人为本的、领导-协作管理模型。领导的重点不是指令，而是创造一个文化氛围，使自适应和协作能够有效运行，除此之外，还要创造一个协作结构，使多个团队能够进行有效沟通。

它是更加适合需求多变、开发期短的软件项目。可以说它就是敏捷的雏形。

持续集成方法

持续集成方法是一种工程实践方法，具体来说就是每当开发人员提交一行代码，就能通过机器自动编译、自动测试，然后自动发布。开发团队通常每天集成一次，就能产生一个新版本供团队和用户体验，其目标是通过快速产生的版本可以尽快把问题暴露出来，进一步提高开发生产效率。
腾讯内部有叫SODA（Software Development Accelerator）的持续集成工具。

敏捷的最佳实践

我们通常通过以下条件来判断是否是敏捷的最佳实践。

稳定的团队：我们需要稳定、有默契的团队，即在很长一段时间内团队成员是固定不变的。
可预见的速率。需要一个迭代当中形成团队的速率，并一直保持这种专属速率，就可以快速评估下一个迭代周期。
单件流：我们需要集中精力一次做好一件事情，所以不欢迎并行任务。同时踏两条船，迟早是要栽在河里的。
质量内建：我们需要在每一个环境保证自己的质量，不让质量问题留到下游。
日事日毕：我们需要把任务粒度拆分成至多1天，一般为0.5天。以方便每天知道我们的工作进展。
设有紧急停车带。我们需要预留人员对紧急问题的插入处理。
滚动迭代：我们需要通过迭代交付来完善我们的产品。
持续改进：我们需要通过回顾和总结，不断强化我们的团队能力。
尽早交付：我们希望尽早交付版本，更快得到用户反馈，以便更快满足用户需求。

需要注意的是，我们要认清自己与最佳实践的差距，不可一蹴而就。要针对自己的实际情况，按照需求进行裁剪，避免形式主义，不要为了敏捷而做敏捷。

敏捷项目管理思维及实践-初识篇