这篇文章很长，刚写完，还需要继续整理。先发出来给朋友们看看。

结构如下：

1. 前言

2. 为什么是“战略”

3. 敏捷实践的基本原则

 3.1 组织为什么推动敏捷实践

 3.2 五环之歌：敏捷实践的基本原则

 3.3 追求多赢、单赢是底线

4. 技术团队敏捷实践的战略问题

 4.1 主动、灵活、有计划

4.1.1 主动性

4.1.2 灵活性

4.1.3 计划性

 4.2 与组织目标方向一致

4.2.1三种层面的方向一致

4.2.2与项目管理团队的合作

 4.3 建设敏捷根据地

4.3.1什么是根据地

4.3.2 建设根据地的条件

4.3.3 根据地的巩固发展

 4.4 敏捷实践的低调与高调

4.4.1 KPI指标和考核结果

4.4.2 低调阶段的高调

4.4.3 高调阶段的低调

 4.5 准备带更大的团队

4.5.1 掌握四门功课

4.5.2 拿下三面金牌

4.5.3 杀灭两股乱贼

5. 结语

1.前言

 

---

寻梦   撑一支长篙
向青草更青处漫溯
满载一船星辉
在星辉斑斓里放歌

互联网在我们面前改变了世界，我们也走进了VUCA时代。为了应对这种易变的、不确定的、复杂的、模糊的局面，在IT互联网领域，拥抱变化、应对复杂、迭代进化、快速交付就成了必然要求，这些美好的字眼被这个时代用“敏捷”来描述。“敏捷”这这样变成了一个大筐，IT行业所有美好的事物都被装了进来，被作为一种““济世良方”而被寄予厚望。

基于各种动机，众多企业在开展敏捷实践，我们的IT小伙伴则被裹挟在其中，主动或者被动地随波逐流。

一些公认的敏捷内涵包括“以人为中心、以价值为驱动、鼓励跨界合作、积极拥抱变化”，无论其中那一项，都要通过具体的实践行动来实现，都离不开“人”，尤其是IT技术团队。DP哥认为，敏捷实践中，最容易产生“被折腾”感觉的，是“技术团队Leader”；而最有可能从敏捷实践中直接获益的，也是“技术团队Leader”。

本文试图从平台型互联网企业“技术团队Leader”的角度和立场，从战略高度分析下在平台型互联网企业中，技术Leader如何带领团队在敏捷实践实现提高、走向进阶。

一些笼统说明：

怎么才算“平台型互联网企业”？

企业为用户提供长期互联网平台服务（SaaS、IaaS、PaaS等），有人员相对稳定的运营、产品、UX、IT技术、运维部门，IT技术人员至少在百人以上，平台系统为分布式系统架构。

怎么才算“小规模职能型技术团队”？

团队长期负责某些子系统的研发维护，一般不超过20人，团队会有一名Leader，负责这些系统的架构方案、业务逻辑、代码质量、工作量评估和分配、代码质量、团队绩效考核。

团队通常仅了解所负责系统的业务，而在业务项目中，团队通常必须与其他团队协同才能完成业务功能。

2.为什么是“战略”

---

一个人数有限、地位单薄的小技术团队，为什么会提到“战略问题”呢？

如果是身处小规模创业团队，一切技术研发都围绕着验证商业模式和实现业务应用，性能、安全、可用性的要求还没那么高，人也还没那么多，那么基于一些成熟的系统架构去开发业务代码就可以了，那么就谈不上什么战略问题。

如果是身处乙方团队，以一次性交付系统功能为主，按工作量收钱，那就只有“高质量一次性交付”的战术问题，也谈不上什么战略。

而对于大平台的职能型技术团队，要求“在固定人力资源成本下，既要交付新功能、又要维持现有功能稳定，还要持续解决系统负债，还要解决线上问题”，团队成员“既追求大平台的稳定和归属感，又希望能够不断进步、时刻惦记着加薪跳槽”，而团队Leader“同时被要求交付的功能要多、速度要快、架构要好、成本要省、系统要稳定、业务要灵活”。而组织则期望利用“敏捷实践”来实现这些美好的事物。

工作的长期性、资源的有限性、系统演进的复杂性、成员诉求的不统一性、团队间协同的不可控性、就需要技术团队从战略的角度去思考应对策略，否则很容易就变成了“碌碌无为”——整天忙忙碌碌、结果毫无作为。

此外，敏捷（Agile）是舶来的理念，从各种翻译来的资料里，我们会看到带来美好结果的很多案例。很多IT技术小伙伴虽然整天把这个词挂在嘴边，但仍然没有去进行深入的考虑。通常在浅尝辄止的情况下，如果运气好没碰壁，则不由自主形成了“敏捷速胜论”的观点，如果遇到阻力而又没能克服，则形成了“敏捷不适合我们论”。这两种观点都是不对的，敏捷实践是一场艰巨的持久变革运动，难以按时间规划，没有标准模板，没有最佳实践，别人吹的牛皮只有参考价值，想复制是不可能的。如果仅仅拿着所谓的“敏捷指南”照猫画虎，提出“敏捷套路很简单，Scrum可以先试点，各种会先开起来”、甚至休克式的直接切换成Scrum套路的的敏捷推动者，必然会吃亏碰壁，必死无疑。

这也是即使人数有限、地位单薄的小技术团队，开展敏捷实践也必须放在战略观点上加以分析的理由。

3.敏捷实践的基本原则

撑一支长篙，可以在青草更青处寻到一船清辉，可以在星辉斑斓的梦里放歌。那么我们往敏捷实践的青草更青处，能探寻到什么呢？

3.1 组织为什么推动敏捷实践

简单而深刻地说，组织把目标和需求进行拆解和分派，员工按照要求交付劳动成果，组织支付报酬；为了更好交付，组织也会付出额外成本用以提高员工的熟练程度和整体效率，但个人的进步本质上跟组织是无关的。

那么组织为什么要提倡敏捷呢？对技术团队又意味着什么？

是因为在这个VUCA互联网时代，情况已经变得更复杂，市场演变成了多对多模式，行业的转折点可能不经意就会来临，可能还没搞清对手是谁，就被干掉了。企业组织为了应对这种局面，除了同样强调交付以外，还会想方设法提高组织的应变能力，这样就把“调整组织架构、提高员工能力、鼓励创新尝试”放在一个比较重要的位置，并通过提倡“敏捷实践”来进行落地，在这个过程中，员工会获取到“创新、试错、验证”的机会，从而获得更多进步成长。对相关话题感兴趣的同学可以去交叉了解泰勒的“科学管理法”、畅销书《赋能》（Teamof Teams）、甚至是马克思的“剩余价值”理论，都是深刻而且有意思的话题。

根据2016年一份国外的调查报告，98%的组织认为从敏捷实践中获得收益，连续多年排名前三的收益是“增强应对需求变更的能力、提高了团队的交付效率、提升了项目的可视化程度”。

由于我们讨论的是技术团队的敏捷实践，而并非组织敏捷转型，因此，我们可以认为这三点是组织对技术团队敏捷的基本期望。从“Why-How-What黄金圈法则”的角度，这三点是组织的Why。再说简单点就是“提高能力、更好交付”。

3.2 五环之歌：敏捷实践的基本原则

多年来，我们清晰而“透明”地看到岳云鹏的进步，在全国相声爱好者的“检视”之下、他持续进行“调整”，并走向成功，但天知道这背后他经过了多少轮艰苦的Sprint，实现了多少“迭代和增量”、“快速反馈”和“持续改进”，这位大兄弟真是让人肃然起敬的敏捷实践者。从这个角度来说，敏捷根本不是什么新玩意，而是符合人的自然认知的，你可以没听说过这个词，但你在追求提升时不由自主会这么做。

站在技术团队Leader的立场上，应该以怎样的基本原则去实践呢？这个基本原则就是“更有价值地交付、带领团队成长 、提升自身能力” 。

从“Why-How-What黄金圈法则”的角度，这个基本原则就是技术团队Leader的Why。这个Why也是敏捷实践的目标，在我们向敏捷的“青草更青处”漫溯时，我们会探寻到这些；而这个Why之上，还有深层次的Why，是我们进行敏捷实践的核心原动力。DP哥用下面一幅图来描述这一点。DP哥将其整体命名为“敏捷实践的五环之歌。”

技术团队敏捷实践的基本原则是“更有价值地交付、带领团队成长 、提升自身能力”，但这个基本原则只是第四环，向内还有个“比四环多一环的五环”。

这五环从内到外，是“要想实现……，必须……”的关系。从外到内，是“只有……，才能……”的关系。

最核心的第5环，实际上是马斯洛需求层次理论的高层次需求，它是一种内在的激励力量。要享受到努力带来的收益、获得职场进阶、达到自我实现，从而获得“幸福感”要想得到这种“自我实现的幸福感”，你必须成长为“剑锋所指、所向披靡”的人，你需要有“聚沙成塔、炼石成钢”的带队能力，你的团队必须“敢打敢拼、充满韧性、干啥啥行”。

而要想“剑锋所指、所向披靡”，你必须带领团队“持续提升、持续改进”，你必须“不放过任何改进的机会”，而这个过程不但要“思路清晰、灵活善战”，还更需要“驽马十驾，功在不舍的长期坚持和积累”。

而要想“不放过任何改进的机会”并且能够实现“功在不舍”，你唯有把“精益思想、敏捷价值观、Scrum三个支柱”深入骨髓。并且拥有“运用之妙、存乎一心”的高超技巧，你需要用这些技巧来指导你的日常工作，并把这种思路和技巧传递给你的团队，变成团队的统一认知。

而要想“运用之妙、存乎一心”，你必须不断的学习和实践，不断地跟阻力斗争，灵活地选择适合自己团队的方法套路，“择其善者而从之”。当你不断的学习、思考和积累时，你终会领悟到很多道理是一通百通的。

3.3 追求多赢、单赢是底线

“更有价值地交付 、带领团队成长 、提升自身能力”的基本原则中，通俗的说，“更有价值地交付”代表着组织赢，“带领团队成长”代表着团队能赢，“提升自身能力”代表着自己赢。多赢自然是皆大欢喜的追求目标。

但你的团队是“人数有限、地位单薄”的，而组织面临的局面往往是复杂的，你通常不了解别的团队在做些什么，你难以判断交付内容的价值，难以理解组织的意图，搞不清楚自己在“明修栈道”还是在 “暗度陈仓”。

如果在业务上难以评估价值，那么只能退而求其次，在系统架构上追究改进，在技术方案上追求优化，在代码质量上不断打磨，在任务协调上追求透明，为团队创造进步机会，向伙伴分享知识经验，推动团队赢。

如果面临着组织动荡，团队不稳，局面艰难，那也要考虑自己如何“利用敏捷的思路去应对这种局面”，使得自己不断获取经验，获得自己的成长，这是你在这个组织中进行敏捷实践的底线。

4.技术团队敏捷实践的战略问题

这个问题详细的描述是：技术团队应该采取什么方针或原则，才能在敏捷实践中达到“更有价值地交付、带领团队成长 、提升自身能力”的目的呢？

总的来说，主要方针有下列各项：

主动、灵活、有计划

与组织目标方向一致

建设敏捷根据地

敏捷实践中的低调与高调

准备带更大团队

4.1 主动、灵活、有计划

在互联网平台企业中，技术团队通常是成本中心，所有的需求来自于业务部门，产品团队。在整个交付价值链中，通常处于被动地位。而主动、灵活、有计划，则是要求在“主动、灵活、有计划”在 “更有价值”地实现交付，在交付过程中争取自由空间和实现持续改进。

能够在大规模业务项目中，实现主动的小规模持续改进；能够在周期较长的交付过程中，灵活安排速战速决的系统改进项；能够在编写业务代码的同时，安排团队进行技术钻研。这些改进项可以是：用看板实现协同透明和沟通高效、和团队约定和调整DoR及DoD、在业务需求和团队意愿之间进行权衡、和团队一起脑暴存在的问题和优先级、集体争取出一天时间来共同攻克一个难题、让一名伙伴挑战一项高于其Lever的TASK、甚至是为某些“只能做不能说”的TASK约定统一的口径。

主动、灵活、有计划的实现持续改进，集合小的进步化为大的进步，两三个月回过头去看，也是能产生惊人的成绩的。这也是把“主动、灵活、有计划”称之为战略的原因。

4.1.1 主动性

说起去主动性，首先要说主动权，技术团队的主动权在于安排团队任务的自由权。既然所有的需求来自于业务部门和产品团队，同时又面临各种各样的问题，我们何来的自由空间呢？

我们通常会面临以下问题：

1）业务团队不关心技术架构及系统风险，只追求功能和交付速度

2）架构不合理导致团队间的系统耦合和协同低效

3）团队技术经验能力不足

4）团队思想的不统一

上述四点，都是需要在敏捷实践中一点点克服和解决的，而我们产生主动性的空间，也在其中。

1）由于单边交付主义，业务和产品通常不愿意了解系统架构，我们对于工作量的安排，是拥有话语权的。在这个过程中，可以灵活争取空间，对架构方案进行验证、或者加入改进任务。而业务方的对策只有一个，总是会预设一个Deadline而倒排计划，这使得我们时常在架构风险和交付时间上做出权衡，对于有心人来说，每次权衡和结果反馈都是一次主动提高的机会。

2）系统间通常会存在耦合，这会带来协同的低效，会出现互相等待的过程，我们可以适当加入一些系统改进项，或者想办法解决或降低发现的耦合。

3）业务发展有“高峰期、平稳期”的发展阶段，在业务的观察期或平稳期，我们可以在进行优化和改进，重新Review并补齐文档、或者集中分享知识经验。

4）在连续交付的间隙里，业务团队在某个阶段可能没有需求方向，我们抓住这个时机，速战速决的解决因优先交付而积攒的架构风险，这种风险越早解决成本越小。

当然从斗争手段的角度来讲，你也可以积攒下来，留着在关键时刻派用场。在DP哥的斗争史里，曾经有一次故意不去解决某个问题，等到产品意识到问题主动提起的时候，才集中吐槽，批判业务方“盲目压缩工期”的问题，然后乘胜追击，隔三差五就拿出来讲一次，给了业务方一次深刻的印象，并最终改善了协同。

对于在平台型企业的技术部门来说，跨团协同的问题、系统建设的问题、业务团队的问题，可能都是弱点和待改善点，但这些弱点却能够成为我们争取主动地位的条件，运用得当就能够争取到相当大的自由，我们要主动的去抓这些机会。

4.1.2 灵活性

灵活性就是具体地表现出主动性。我们应该深刻认识到，灵活地安排工作任务，是争取主动性最重要的手段。分配团队资源时，必须根据项目和任务的特点作灵活的变动，主要方法是“分散、集中、切换”。DP哥的思路是“分散要强、集中要快、切换要一致。”

团队资源化整为零的分散使用，大体上会有几种情况：

1）通过资源统筹，一段时间内隐蔽使用一部分余力来做团队想做的事

2）在需求交付间歇期，对技术方案进行预研探查

3）并行项目较多，要同时应对多方面的需求方和协同方

本来就单薄的团队，再分散开就更为单薄，从编码技术、业务领域、任务协同上就会有很多限制，对个人的全栈和横向能力产生了较高要求，同时对团队成员是难得的锻炼机会，每一名程序员都是这么成长起来的。作为Leader，要能够清楚的判断，哪些任务必须要hold住局面，哪些任务放手交给新人锻炼，而每一次的分散安排，都是Leader验证自己判断的机会。

集中使用资源，及所谓的“化整为零”，难度不高工作量较大的项目任务，这种任务交给个人不如交给集体，可以当做一个集体游戏来用来检验团队的协同，看看能否用超预期的短时间来完成交付。

按照情况灵活地分散或集中使用资源，是争取主动性的主要方法，但是还是必须灵活的切换，根据情况的变化，或者业务方交付压力的上升或下降，我们可以像流水和疾风一样，迅速切换我们的任务安排，你可以秘密而迅速，可以声东击西，总之可以采取巧妙的方法和口径。

分散、集中、切换，都是在敏捷实践中表现出主动性的动作，如果死板、放任地陷入被动地位，完全被单边交付主义所压制，你的敏捷实践是很难取得进展的。作为技术团队的Leader，练就这种善择时机和随机应变是不容易的，惟有在日常工作中勤于思考和实践才能够慢慢积累。

4.1.3 计划性

主动和灵活是离不开计划性的。前文提到了敏捷实践是无法按照时间来进行规划的，但这一点与敏捷实践战略的计划性是不冲突的，这个计划性指的是行动的预先准备工作。对于一段时期之内交付任务的了解、资源的负荷、团队认知的一致性、架构风险、代码质量等，都要包括在Leader的细致评估、检查确认的工作中。没有提前准备的计划性，是难以争取主动空间，也是无法灵活安排工作的。

另外，主动、灵活离不开团队成员的统一认知和高效协同，无论是分散、集中、切换，都需要团队伙伴的理解和支持，作为Leader，要把敏捷实践的战略思想，变成团队的统一指导思想，这样才能行动一致。这部分内容在后文“建设敏捷根据地”中会详细说明。

小小案例：

以往有两个团队，分别承担了一部分核心业务功能，两个团队都很繁忙，加班都很拼命，两个Leader分别是X和K，其中X被认为很难搞，敢于怼业务团队，偶尔会否决业务的方案，在评估工作量时又经报出与正常认知不符合的数字，在系统联调时偶尔也会延迟，但在业务项目中，也没有什么大的问题，能做到按要求交付，整体上业务对其有牢骚，但是也没什么本质不满。而K是好好先生，是劳模，总是能够满足业务的需求，满足业务的交付日期，获得了一致好评。

但经过了半年，我们盘点系统架构，发现X负责的大业务模块被拆成了5个子系统，互相耦合性很低，灵活度很高，能够分开上线，能够很方便的实现业务需求。而K负责的大业务模块仍然是一个系统，已经非常臃肿，架构已经愈发不合理，对接业务需求越来越辛苦。我们不能说K做错了，我认为X做的更对。

4.2 与组织目标方向一致

技术团队敏捷实践战略问题的第二个问题，是在敏捷实践中与组织目标一致，或者与组织目标任务相配合的问题。从某种意义上，组织为我们提供了一切，我们要怀着感恩的心为组织作出贡献，这也是无需赘言的价值观问题。

4.2.1三种层面的方向一致

与组织目标的配合有三种：

1）健壮的系统、坚韧的团队（战略层面）

2）高水平的项目交付（战役层面）

3）高效率的协同支援（战斗层面）

我们所负责的系统，都在平台上承担了独特的业务功能，系统平稳的运行、良好的可扩展的架构、方便灵活的接口、清晰友好的技术文档、赏心悦目的代码，恰到好处的注释，都会提高复用性、增加健壮性、减少后续研发资源的消耗，这才是对平台最优价值的支撑，做这些才是最正确的事。无论领导和业务方是否理解，我们都要通过主动、灵活、有计划地安排这些任务，这也会给团队提供好的锻炼机会，传递正确的技术观点，最终提高整体综合能力。这些是在组织战略层面做出的配合，技术团队的Leader要明确地认识到这一点。

在项目的交付任务中，各个系统团队承担不同的功能，但通常要组合起来，才能实现业务功能。团队间需要互相配合，共同实现高水平交付，协助实现组织目标。在项目中，经常会出现某些任务应该分配给哪个团队的问题，当缺乏主架构师时，团队间容易发生扯皮推诿，这个时候，团队Leader应该基于架构合理性进行客观分析，并根据交付压力、资源情况进行方案的折中权衡，积极参与配合，尽到配合义务，无论是否承担相关研发任务，哪怕是参与讨论评估，也是架构分析、技术穿刺、综合评估的锻炼机会。

在跨团队支援方面，团队应该依从统一项目协调，提供必要的配合，包括文档提供、接口解释、提供咨询、配合联调，对外支援越高效友好，越能节省自己团队的时间，从而增加自己团队的主动性。

4.2.2与项目管理团队的合作

较大规模的业务项目，往往会安排专职的项目经理去推进项目，项目经理往往承担多种使命，包括“横向协调、汇总情况、综合制约、解决问题”，从而分担领导的重点项目推进压力。

项目经理通常来自PMO团队，在互联网和敏捷的大背景下，弱矩阵项目管理团队也正在转型，往往负责推动敏捷实践，在这方面，聪明的Leader和聪明的项目经理是一拍即合的。无论对方的Title是SM、是敏捷教练还是项目经理，都要形成很好的配合，借对方的能力为我所有。

在项目中，项目经理的价值观是代表组织进行交付推进，计划一旦制定，就是刚性的。承诺交付的却没搞定，对他来说是失职，对你来说是无能；能够交付的却没做好计划，对他来说是无能，对你来说不靠谱。在任何组织里，都是不被许可的。

如果对方同样需要在敏捷实践中成长，你们可以组成100%互补的搭档。你验证套路并产生问题，他想方设法帮你解决问题，你实现了交付，他完成了项目，你在敏捷实践中得到提升，他获得了好的案例。

4.3 建设敏捷根据地

技术团队进行敏捷实践的第三个战略问题，是建设根据地的问题。这个问题的重要性和必要性，是伴随着敏捷实践的长期性和零碎性而来的。

理想状态下的团队和现实情况中的团队差距必然很大，到底我们能成长进步到什么地步，时间不能确定，但无疑是相当地长，这就是长期性。在需求、管理、质量、DevOps体系等方面会存在各种问题，都需要有针对性的去改善，这就是零碎性。

4.3.1什么是根据地

敏捷根据地是什么？它是确保技术团队能够完成交付任务的同时，达到“提升交付能力、实现团队成长、实现自我提升”的核心力量。

再描述的啰嗦一点，是基于“提升交付能力、实现团队成长、实现自我提升”的共同意愿、基于对长期性和零碎性的客观认知、基于对敏捷实践中看到的进步、基于对自己和团队的相信、从而能够在团队的“主动、灵活、有计划”中步调一致和付出努力，相信自己和团队能够实现持续改进的团队核心力量。

有了这种根据地，就能够“在不确定要做什么”的时候，很容易“Findout what to do”，能够在面临具体任务时，共同知道“How to do”。根据地是可以实现“自组织”的。对于技术团队，这个“自组织”的定义是“在完成交付任务的同时，能够主动、灵活、有计划的做正确的事，从而实现持续改进，实现团队综合能力的提高”

这个根据地建立的过程，就是“择其善者而从之”的过程，随着“运用之妙、存乎一心”，这个根据地就会稳固和发展。

4.3.2建设根据地的条件

最基本条件，是要有一个相对稳定的团队，并有基本的交付能力，并会基于所负责的系统持续承担需求任务。

第二个条件，是团队Leader对敏捷实践有一定认识，有意愿实现“更有价值地交付、带领团队成长 、提升自身能力”，并且有勇气去实践“主动、灵活、有计划”。

第三个条件，能够发动团队成员一起参与,一起学习。

有了这三个基本条件，就可以进行根据地建设了。

马云爸爸有句名言“因为相信、所以看见”，但小伙伴们都是境界没那么高的实用主义者。

团队小伙伴对Leader通常会有四种感觉：

1）因为你是Leader、所以才不得不听你的

2）因为你做到了、所以才服你

3）因为我真的长进了，所以才愿意跟你

4）因为我懂了，所以你说不说我都会这么做

作为团队Leader,你觉得你在小伙伴心中是哪一种。即使你为小伙伴们安排了培训、进行了动员、贴足了标语、设计了壮观的看板，如果你的小伙伴看不到改进，感受不到成长，敏捷实践就成了“一阵风”，很快消散，侥幸持续时间长一点，就变成了“看板晨会例行表演”，每个小伙伴都是群众演员，每天说一遍“昨天我写代码，今天我写代码，没有问题”。

只有你带领大家走向“主动、灵活、有计划”，才能建设属于你的敏捷根据地。

只有在你的根据地里发动群众，带领大家一起“择其善者而从之”，带领大家争取出“主动空间”、你才能实现灵活地“分散、集中、切换”、你才能在长期的斗争中，“有计划”的一项项解决掉“零碎”的问题。小伙伴们会持续得到成长，才会坚定地相信敏捷实践“能除一切苦、真实不虚”，从而成为根据地巩固发展的力量。而你，在会这个过程中会愈发的“运用之妙、存乎一心”。

4.3.3根据地的巩固发展

Leader要懂得赋能的道理，这是敏捷领导力里面重要的部分。根据地建设的过程也是给团队赋能的过程。

根据地建设本身也需要“主动、灵活、有计划”。有经验的Leader都会明白“团队是带出来的”，而不是“管出来的、哄出来的、训出来的。”每个团队成员的情况也不同，能不能把成员从雇佣军变成你的根据地，就看你是怎么带这只团队的。以下是三个观点：

1）避免啥都亲力亲为

Leader要学会放权、要让小伙伴顶上去试试。

2）想法设法让小伙伴自我成长

要相信“人皆可以成为尧舜”，给伙伴设定一些目标、给他提供进步的空间，小伙伴们会表现出动力和干劲的。

3）别挡人家的路

这个时代都是双向选择，互联网瞬息万变，有机会帮别人成长、有机会成人之美也是给自己多铺了条路。

通过你的赋能，如果实现了以下几点，就说明敏捷根据地的初步成型。

1）统一的敏捷基本认知、统一的沟通语境

2）已经通过你的“主动、灵活、有计划”获得了成长

3）相信能通过敏捷实践实现“更有价值地交付 、带领团队成长 、提升自身能力”

4）伙伴具备了有一些“主动、灵活、有计划”的勇气和经验

剩下的，就是发动更多伙伴，发展和巩固你的根据地。

4.4 敏捷实践的低调与高调

敏捷实践战略问题的第四个问题，是过程中低调与高调的问题。

4.4.1KPI指标和考核结果

首先聊下KPI指标和考核结果的问题。对于技术Leader来说,你的年终考核结是被量化出来的吗？项目是时刻变化的，业务指标是业务部门的，价值观文化都是领导的主管评价，OKR是难以落地的，它更可能只是为了证明人事部门在与时俱进。概括起来说，KPI是糊涂账，最终考核结果是领导主观平衡出来的。

再说下KPI度量数据的意义。当领导根据印象给了以一个定性结论，恰好度量数据与这个定性结论相符合是，这个数据才有意义。这一点不能说的太直白。

我们分析下对于考核结果来说，什么是重要的。

通过实现“更有价值地交付、带领团队成长 、提升自身能力”必然会呈现出一些现象，这些现象会包括“系统架构趋向合理、系统风险降低、系统运行指标稳定、产品业务至少会赞扬你的透明和沟通高效、团队会表现的积极和乐于沟通、小伙伴们会偷偷赞扬你”，这些迟早会让领导看到、听到、感到的，就是给你“好”的定性。当你定性为好的时候，你的一切都是好的。

当然线上BUG数可能是硬指标，又会被横向比较，还是要守住至少不能太差。不要让领导想表扬你都说不出口。

那些笼统的KPI，谁爱关心谁去关心吧，心知肚明就好。你大胆的去做正确的事吧。

4.4.2低调阶段的高调

在敏捷根据地建设阶段，还是很艰苦的。在顶住交付压力的同时，要带动团队走向思想认知一致，还要尽可能获得更多支持。这个阶段大家的认知往往不统一，团队也还没感受到进步，甚至在心生厌恶地被动表演敏捷。而领导和业务方却认为敏捷可以马上提高交付速度，并是希望你很快实现。

具体说明就是，为了证明敏捷可以提高交付速度，你武断地缩短了交付周期，同时带领团队持续加班，加速交付。一段时间之后，的确提高了交付速度，也得到了领导认可。此时业务团队把这个速度当成了常态，施加了更多交付压力，于是团队负荷很重、被迫走向研发死亡行军，从而大概率会发生这几个问题：质量下滑、架构风险上升、技术负债积累、团队内戾气上升、形成对立情绪。雇佣军心态的伙伴会离职、线上故障不经意间会爆发，你和你的团队会元气大伤狼狈不堪。

为了避免这一点，你要清醒的认识到，敏捷绝对不是为了提高交付速度，而是在持续交付的过程中，追求稳定速率下的高效和持续改进，从而提高团队能力。这个能力是为了组织在面对不确定的业务方向时，能够用这个团队相对低成本的试错，相对较快的纠偏，相对高效的摸索出相对正确的方向。

再比喻下，敏捷能力就是敢于跳坑并且可以再爬上来的能力，是一种基于能力和价值观的韧性。这种能力，只能通过交付过程中坚持持续改进才能获得。

在刚着手敏捷实践，你要明白你的目标，无论是看板、Scrum、还是极限编程，都是为了这个目标，你深入的去理解尝试，“择其善者而从之”。你做不到非常高调的展示你的成果，所以要低调的做事，甚至有些事“只能做不能说”。

但有一点，你可以非常高调的去做，那就是“透明”你的交付过程。“透明”（Transparency），可以暴露问题，可以形成标准，可以简化沟通，能够“涌现”（Emergence）出近期的“零碎性”目标。透明的一个好工具是看板，但凡是个有点周期的项目，但凡说起来有点费劲的事务，但凡是个需要跟踪的任务，都可以用看板。

跟业务方的定期沟通，可以建看板；跟产品的故事整理，可以建看板；团队之间的依赖，可以建看板，总之，看板是以“阳谋”的方式进行敏捷实践的好工具，DP哥有好多案例来诠释这句话。

某个研发团队，“产品、研发、业务”存在一些沟通差异和误解，但总是不能在一起沟通。产品Leader、研发Leader都在苦恼于三方理解差异的问题，DP哥精心设计了一个业务需求状态看板，约定每周一次，三方花20分钟时间在看盘前开站会，用来对齐思路。DP哥在建立这个看板时对伙伴说，“当所有路过的人看到看板，都会驻足若有所思和甚至发愁时，看板的目的就达到了”。结果从第三周开始，业务和产品就经常在看板前烧脑和讨论问题。此时，除了基本的对齐思路外，看板的拉动作用也已经发挥作用了。

团队会在透明中感受到沟通协同的进步，会在看板的内容中感受到存在感，当被积压的技术负债和带改善项也可以通过看板展示在业务团队面前时，讨价还价也会变得主动些。当Leader通过“透明”争取到一些“主动、灵活、有计划”时，团队可以感受到Leader的苦心和努力，也会体验到改进，也直观的感受到“少了些被折腾”。此时，敏捷根据地就会慢慢形成。

4.4.3高调阶段的低调

随着你的敏捷实践慢慢发挥作用，你会发现团队的伙伴变得主动起来，你的团队也会在组织中脱颖而出，受到各种好评，整体感觉会变得高调起来。

但是，你会发现，你的改进阻力越来越大，在你在可控范围内的改进似乎越来越少，甚至很产生无力感。比如企业的整体流程对你来说已经太慢，各种环节仍需要层层审批，或者发现你的改进结果并没有提升业务销售指标，或者组织的业务规划变换太快，业务长期路线图的决策者已经换人。

你内心可能会很茫然，你可能想止步不前。

这个阶段，在你不断“检视”和“调整”的过程中，你的团队已经很强，而组织的流程、制度、文化还没有发生改变，你深刻的体验到了这一点，但作为组织战车中的“单薄团队”，你根本没办法去改变。或者，由于你的进步，或者对其他团队提出的高要求，在别人眼里视作“侵略行为”。

没错，敏捷实践本来就是侵略式的变革行动。随着改进的深入，组织的流程、制度、文化都要随着发生改变，否则不能称为变革。而提倡敏捷实践的组织，实际上希望发生这些。

另外，即使我们的组织结构仍然是层级和职能结构，在职能边界上也存在着大量模糊地带，职责可能是清晰的，但边界是模糊的，它是一张自适应网络系统，随着你的触碰，它会跟你反馈，你可以利用反馈结果来调整后续的动作。你很可能会在模糊地带做了些工作，但这工作确是别人的职责，当你过于高调、甚至得意忘形、轻视别人时，你可能会造人嫉恨，人为给自己树立很多阻力，而当你轻视组织，忘记了团结一致时，你可能不顾大局、陷入单边团队主义的深坑。

聪明的Leader会非常谨慎和有耐心，会充分与组织沟通对齐，和组织一起，“主动、灵活、有计划”地推动流程、制度、文化的改变。这个时候，你已经进入了新的发展阶段。

4.5 准备带更大的团队

敏捷实践战略问题的第五个问题，是进阶的问题。人都是追求成长的，对于技术团队Leader，也需要在敏捷实践中实现成长和进阶。

首先说说领导力，这个东西是通过做事领悟出来的，如果有幸跟了好领导，会领悟得快一些。《管理3.0》的领导力模型包含了激励员工、赋能团队、统一目标、提升能力、结构成长、全面改进这六个部分。同学们可以按需去学习了解。

DP哥认为，技术团队Leader的进阶需要达到的要求是：掌握四门功课、拿下三面金牌、杀灭两股乱贼。

4.5.1掌握四门功课

相声讲究说学逗唱，技术Leader也有四门功课，那就是“需求分析、项目推进、质量管理、持续集成”，有经验的人会一点就透，相关的资料也浩如烟海。

说几句“质量管理”，大家都能理解仅仅依靠Scrum套路、看板方法等管理实践，而不在工程实践上下工夫，根本难以持续提高效率。从持续集成和DevOps的角度去讲，我们应该更频繁的发布、更频繁的交付。测试团队的人肉黑盒测试是根本满足不了频繁发布要求的，如果如果开发团队不自己做高覆盖率和高可靠的单元测试，根本无法实现高频发布。

对于技术团队来讲，不追求“高覆盖率、高可靠性、完全自动化的单元测试”的敏捷实践都是可耻的伪敏捷，这个话题同样是个深刻的话题，相关的任务要求我们学习掌握很多东西，领导和业务团队有时也不理解，但通常情况下，团队会只愿意享受自动化的好处，而不愿意多付出。

有位老师曾经这样比喻，跟一帮朋友打篮球，多打几次就形成了一定默契分工，这个是投射型的，那个是突破型的，这个是速度型的，那个是力量型的。但在会打球的人眼里，这不过是一帮菜鸡互啄，统统是两个型：攻也不行、守也不行。其实是基本功不行，说啥都没用。

作为Leader，要和团队一起，认清这四个方面的“长期性”和“零碎性”，在交付过程中“主动、灵活、有计划”持续提高，学好这四门功课，才能“说学逗唱”游刃有余。

4.5.2拿下三面金牌

“三面金牌”指的就是“交付得到好评、团队得到进步、个人得到提高”，当这三点获得外部肯定和自我肯定之后，进阶是水到渠成的。

4.5.3杀灭两股乱贼

而真正能使的技术Leader进阶的是诛灭两股乱贼。这两股乱贼是“单边交付主义”和“单边团队主义”。前者强调担当和技巧，后者强调格局和胸襟。是“心中贼”，王阳明说“破山中贼易，破心中贼难”。

单边交付主义的代表名言是“这个需求很简单，怎么实现我不管，明天上线”。聪明而勇敢的技术团队Leader会业务需求方充分沟通和评估轻重缓急，制定出可行的计划，确保按时按质交付。在这个过程中，要求Leader有担当、有勇气、有手段、有分寸。打倒单边交付主义与确保交付是相反相成的，技术Leader与需求方是要斗而不破，合作共赢的。在交付过程中，你能够“主动、灵活、有计划”的诛灭“单边交付主义”，你的能力自然就超越了“单薄技术团队的Leader”。

单边团队主义的表现通常为两个极端，一种极端是不思进取，“满足于团队小确幸、不愿担当、唯流程主义、不愿意踏出舒适区半步”，当组织比较僵化的时候，经常难以暴露出来。他们已经忘记了全局，躲在舒适的小空间。另一种是技术自嗨，团队Leader只愿意做自己的事情，凡事采取最新的技术，最高的配置，一有不满足就牢骚满腹或阳奉阴违，技术Leader要时刻警醒，避免在不经意之间滑向这个误区。

5.结语

敏捷实践是带有侵略性质的变革，充满了斗争艺术。跟自己斗、跟团队斗、跟需求方斗、跟组织斗，但我们的目标肯定是斗而不破，实现共赢。很多人在诠释敏捷，很多企业花了很多钱用于敏捷实践。我深信“太阳底下无奇事”，拨开那些高大上的敏捷名词和套路，在其天花乱坠的背后一定有简单朴素的本质。我们不要瞎折腾，我们要解放思想实事求是团结一致向前看，我们要“主动、灵活、有计划”的去实现共赢，走向提高。这篇文章是我对敏捷实践的认知，希望与大家共同交流，希望能为大家提供些勇气，打开些思路。