说起敏捷(Agile, /'ædʒl/)开发，有很多组织把它看作能够管控项目，实现将人转变为可替换零件的银弹；王垠认为它与软件工程一样是扯淡，是浪费资源的祸根，提出者应该被开除。

作者的敏捷经验

• 在H司有18级以上的2位领域专家（含外籍华人专家一位）的直接且长期的指导，成功与失败都有
• 曾经开发并迭代了多年DevOps的Agile系统，对无数竞品进行过体验分析（最值得参考学习的是微软的AzureDevOps），亲自设计与落地，甚至细化到表结构等设计，并长期接纳用户对敏捷管理的反馈。
• 自身作为ScrumMaster，并使用自己开发的Agile系统，双手沾泥地带领组员进行招聘和交付

因此，关于敏捷，有些好的坏的过程与经验，作者认为是有发言权的，特此分享

省流量

敏捷是基层管理的一种玩具级管理工具，比拍脑袋好一点，但是仍然不是成熟体系化的工具。

什么是敏捷

关于方法论

方法论（methodology），尤其是西方的方法论，一般采用了一套基于笛卡尔还原论的经验框架。首先我们不要一开始就对这种务虚名词有排斥，而应该积极试用后再评价；也不要认为只要拥有一套流程就能实现将码农变为流水线员工，毕竟方法论只是经验公式，而且编码也是一种需要思考的工作；

对于一个项目来说，能够即快又好地完成工作当然是非常棒的，但是众所周知，受限于项目管理三要素：时间、质量、成本，只能折衷选择。因此「敏捷（Move with ease）」作为一种方法论（虽然Agile自称为一种Culture和empiricism）被提出，其中Scrum(/skrʌm/，一种球类比赛)是比较知名的实现类之一。

业界对敏捷的定义

由于敏捷的定义很模糊，为了避免歧义，我们以两大顶尖软件的定义进行分析

在微软的Azure的介绍中，定义如下

Agile approaches software development by emphasizing incremental delivery, team collaboration, continual planning and continual learning.

在Atlassian的定义中

Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.

在Scrum的官网定义中，参考如下

Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

这些定义都很狡猾，是不可证伪的政治正确的定义，因为不可能同时拥有“灵活”和“确定性”，尚且这些没有具体的流程规范和度量标准。

但是大致要求为将瀑布式开发流程转为多阶段小迭代，它本质是在保持时间、质量不变的情况下，通过投入经理人的管理成本降低开发过程的空转成本，进而提高产能的方法，类似格鲁夫的经理人杠杆率理论。

这里产生了很多歧义，假如按照大厂的定义

• 每周9117，并迭代上线2次的拼夕夕是优秀敏捷典范；以心脏跳动为代价，多个产品并行试错的也是敏捷。
• 只写Excel/PPT的日系sler公司，也是敏捷
• 领导开始敏捷地拍脑袋提出了模糊需求，最后觉得你做的不好也是敏捷。

业界软件分析

以Azure软件包为例，它主要有Board规划功能与Kanban计算功能，它在现实中是参考了泰勒与丰台JIT的两套管理体系，实现了一套统计与推送的经验框架。

它的实际运作过程大致如下，以一个月迭代为例

• 月初通过人员估算总工时容量；接着规划能够落地的任务的标准和耗时，并分配给组员，直至全部分配完成
• 每天盯着燃尽图看下任务是否完成，落后的任务需要解决

项目管理用Excel也是能实现的，只是无法在线编辑而已。

个人对敏捷的定义

基于实际产品而不是纯理论对敏捷定义，它是如下的管理动作

• 定义：The agile methodology is a set of high-frequency policies that gains the certainty with trade-offs.
• 用户画像
  • 决策者：只关注敏捷报表指标
  • 组长：作为包工头，通过微操提供确定性。
  • 组员：纯粹的产能数字。

它最终的作用

• 为组员提供了可确定的工作量，他能看到工作渐渐减少，而不是老是临时塞需求。
• 为上级领导提供进展的确定性，比如燃尽图是否有大范围弯曲。
• 敏捷仍然无法对抗至上而下的官僚惯性与KPI
• 由于缺少精确的定义，大部分敏捷实践后会缩短研发周期，加班变多

个人在真实项目中更喜欢使用PERT的编排方法，曾经对关键复杂项目进行了高达半年的规划排期。

敏捷工具用户是谁？

敏捷无论如何吹爆，最终也要有工具作为承载。而ToB工具的特点是自上而下的压力传递，无论你是敏捷教练，还是软件销售，你的用户只是有决策权的人，而不是Scrum Master等小组长。

与工厂中推行JIT精细化管理类似，管理改进的举措都是自上而下的强制推行，而组员等搬砖用户没有选择的权利的，他们的反馈更像是“场景细节”，而这些结果是可以统计操纵的。

虽然上述有些政治不正确，但是toB业务的核心是以管理为中心，提高生产率，但是如果你抓不到核心用户的“管理”价值点，而反复耗费在细节的话，项目注定没有sponsor而失败，所谓的敏捷也是无法推行的。

大公司敏捷真的可以提速吗？

当然不能证明，“高频操作”并不能证明提高了速度，原因如下

• 多阶段小迭代本质上是充分提高Master的管理杠杆，要求ScrumMaster是一个全知全能的Hero，这个人能在有限时间内，进行高频度的拆解、估算、解释与验收，这个要求是在招创业Leader！
• 如果所有任务能够像燃尽图中那样理想地估算时间准确，意味着保守主义与强KPI策略，工作内容是可预测的（最少动作组合，消除无用动作，增加产出数量），导致团队的低成就感与乏味感
• 工时估准的前提是重复的经验，即没有POC/MVP/高阶设计流程。所有组员的敏捷工作流如果都提速，本质上与工厂中打螺丝加快流水线转速是一样的
• 带项目超过6个人后，Master就几乎没有时间编码了，天天动嘴甚至能产生咽喉工伤的问题。

事实上，根据我个人经验，就算H司是海归遍地的员工，能同时达到如下标准的Master已经少之又少

• 能够明确需求和项目定位，而不是自我感动或者自嗨（意味着产品经理能够理解折衷之道）
• 能够基本准确估算项目时间而且燃尽图斜率接近线性（意味着技术水平已经不低，能够不被忽悠）
• 能够建立验收与缺陷跟踪流程体系（意味着能砍掉不清晰需求，过程明确）

很多工作多年的Leader，带领的项目仍然陷入在债务的泥潭中无法脱身，导致组员提桶跑路。

敏捷与预测

为何要估算（预测）时间？

很多开发比较抗拒估算时间这个工作 ，认为项目总是领导拍脑袋，反正从来没有算准过，所以估计工时是没用的。这种认知需要纠正，因为估算工时类似于分支预测中的cache，就算估算工时有偏向（命中失败），也会作为缓存为下次估算提供对比借鉴。通过后期改进总结就可以发现与理想估算间的GAP，进而持续改进。

此外，估算时间还可以协助发现任务不明确的问题，如果任务定义比较模糊，缺少验收标准，那么就会导致时间估算更加无从谈起，因此估算时间相当于提高了实施任务分解的管理者的要求。

最后，通过将所有工作进行估算，可以生成依赖有向图，就可以一定程度上解决"不可控"的紧张，也能每天对比计划反省是否达成目标。不要陷入非黑即白，只要看ROI录入耗时不赔本，就可以搞。

在电影中，有经验的狙击手会开两枪来校正风力，项目中估算时间也如此。

我推荐的流程如下

• 成熟重复的任务：基于工时研究与标准工时统计进行估算，半天为最小的Task。
• 形而上的（未知）任务：找出研究工具（比如拍2天脑袋） + 2天后再估算拆解任务（投资组合理论）
• 含pre-sale的非确定性任务：要基于L2C(Lead To Cash)等流程，这种可能失败，需要有信心

如何估算成熟重复任务的时间

这里是纯搬砖的结构化知识工作，我个人一般将具体的Task分解到1～2Day，避免估算出现较大偏差。

比如，任务描述必须写"登录模块的前端菜单录入与对UI界面的实现"，并指定某个前端开发人员；而不是"前端登陆模块"这种模糊的不可度量的任务。如果某个人长期都做不好分解，而且培训也没用的话，那么说明这个人脑子全是浆糊，建议赶紧换。

具体的时间估算，比如静态网页这类指标，可以考虑用过去积累的EMA指标来预测，这可能是后续AI的热点。

虽然这种搞法本质与工厂中的“规划部”没有太大的区别，即使被复杂系统领域的专家批评，但是本处重点在于控制质量，做出来就行了。

人力没排满

每月人力是固定的沉没成本，出现部分空转是可以接受的。

• 核心问题在于需求不足，可能是顾客不认可，竞争加剧，或者售价过高
• 实在不行就分一些永远干不完的任务（比如开源软件升级，运维，运营，宣传文案等，最好是免测试投入的改造工作），人不要外借，很可能有去无回。

如何估算未知内容/不确定的时间

（此章节不属于敏捷的贡献）

How to program if you cannot？

我们以经典的“学游泳”为例，假如现在领导要求你“下周我们要进行游泳比赛，你评估下组员学游泳的时间”，你自己也不会游泳，那么应该如何解决呢？

这时那些画燃尽纸片的敏捷专家就没法教你了，因为他们只会照搬僵化的管理框架。这里本质上是形而上学 + 复杂系统 的问题，你无法精确估算未知内容的时间，但事实上，你拥有的解决方法是可以枚举的

• 找外援：比如咨询公司、商业服务或开源项目，并指定验收标准，SWOT分析后进行采购
• 亲自思考：基于理性主义与经验主义的方法，亲自学习、亲自培训、亲自部署
• 作为二传手，把问题抛给组员，但是要描述清楚细节，并兜底

我们要基于上述背景拍脑袋估算时间，拍脑袋也是有管理指标意义的，它可以帮你BinPacking排序时调整人员与任务的Mapping，人毕竟还是畏惧不确定性的。后续无论是否做出来，Burn down也对项目整体进展有决策作用。

至于如何三选一，假如你是为了创业而提高速度，选型上优先找外援，千万不要陷入到细节里面了，重点时间应该投入在设计用户的场景匹配程度与验收标准，因为需要反复试错才能找到真正方向。

其实再深入演绎的话，如果想投入更少的时间，做更多的事情，你将会进入“不确定与反脆弱”的领域，比如买股票。

边想边做还是先想后做？

很多需求与方案可能在排期阶段都不清晰，然后拍脑袋估工时，最终可能导致估算与事实不一致。

• 原则上应该先想后做，即牺牲SE/管理人的管理工时换取可预测性的方案，提高并行效率
• 边想边做不适合敏捷这种快餐模式，而应该给一个总包时间定期汇报

质量

为何管理者总是最后才知道风险？

经过多次失败尝试，我发现了一个二八定律：

• 当面对困难时，只有20%的员工选择主动告知，而80%的员工从来不说
• 当自己工作完成后，只有20%的员工选择主动告知，而80%的员工就不了了之

读者看到这里可能会问，为啥招聘时不能提高员工的素质？客观大环境如此。针对员工熟练度较弱的情况，此刻就不得不花费你的管理时间了，你需要每天早上开会过进展，做起包工头监工的工作，才能降低风险，等到新的惯性形成后，再降低开会次数。

关于如何开会，我以前已经写过，不要围一圈依次说，而是让你作为主持人去按照KPT原则提问

外包人员咋敏捷？

在敏捷开发中，讲究的是"特种部队”式，“外科手术”式的全能开发团队，然而在现实，很多企业事实上并不重视自己IT团队的开发，比如波音请外包做飞行软件，日本创业/IT请外包做，某五百强请精英OD干实际的活。这类如果要达到“真敏捷”的水平，需要根据员工的“熟练度”进行管理

• 通过管控（每日过进展/考试）手段进行管理：虽然大家都不喜欢过进展，但是没办法，先"固化"，后"改进"。
• 通过Wiki等知识管理，提高外包员工的熟练度，降低新员工入门周期
• 通过激励手段提高工作时间：我个人不赞同，但是这个活总要人来干。
• 对于熟练度较低者，技术管理者需要投入大量时间分解细节做需求与实现，外包只负责编码。后期熟练度提高后再考虑降低设计耗时。
• 如果某外包的培训成本与招人成本一致，那么考虑换人。

这样做下来后，软件开发犹如快餐一样，你作为维护需求与实现的桥梁将非常累，可能写代码都没时间了

强化质量管控

由于你将自己的工作分给了他人，对方不一定了解你想要什么，这是质量可能就有问题。你的价值是收集与处理信息，要明确度量标准，降低反馈延迟。

• 功能按照Story-task两层进行划分，Story是场景，task是具体的搬砖任务
• 每个Story成立临时小组，安排组长进行分工实施
• 基于文字的形式传递，可度量验收
• 测试基于场景Story的验收与关闭

敏捷与DevOps的关系是什么？

• DevOps指从需求跟踪、代码、流水线、测试、交付件到运维发布一套流程的管理手段，以及平台工具
• 敏捷主要是需求与进度相关的管理手段，它最终落地到用户可能只是DevOps平台的一个菜单（比如叫做Board/kanban），并可以与具体的Git/CI/CD进行绑定关联

总而言之，这些工具可以自动化或者量化团队的项目进展，但是不能代替核心管理能力与节奏能力。

常见的敏捷/DevOps工具有哪些？

• JFrog/Azure/Rally/TeamCity 全家桶，注意此类产品可能涉及到出口管制，大公司采购/使用要慎之又慎
• 国内的Coding、简单云以及各种云投资的平台，但是体验做的还是比较弱，感觉是没有招到很牛的产品经理
• 通过拼装开源产品（Jenkins/Gitlab）自己折腾一套，有定制成本，但是全部自主可控而且对内服务态度好，仅适用于BAT等预算非常多的大公司。

stand-up meeting有没有用？

stand-up meeting是手段，不是目的，ROI后期很低

• 假如有6个人开会15分钟，人工成本最低也有近500元，但是讨论内容却只有一些进展，说明团队仍然是pull based的沟通惯性，这样scrum master会很心累的
• 要求你实施开站会流程的上级，管理重心一般过高，自己双手不沾泥
• 等项目从pull based的迁移到push based后，一般来说，开周会就足够了

scrum master是啥？

在大型组织中，敏捷master就是大头兵，带着一群螺丝钉搬砖，坐在办公室，拿着比富士康里工厂领班高的工资，工作难度不一定高。

在创业组织中，敏捷master又啥都干，我认为更加接近经理人的角色

敏捷流程在POC阶段有用吗？

在POC阶段（比如验证项目可行性），由于高不确定性，还没有迭代的概念，因此作用不大。比如我在POC场景下，内部细节是不会采用敏捷工具链的，管理中只记录一个stub作为deadline/demo day，内部细节的整理是耗时的，暂时不会在工时维度上整理。

敏捷只能做确定性强的高周转任务，不确定性的任务需要一个hero来完成

总结

敏捷是一种快餐式的经验框架，经验意味着重复且体力的劳动，它能够帮助team形成惯性。

• 适用于10人左右的Team，人数大于小作坊，然而比不过Enterprise
• 敏捷对Scrum Master的技术与决策要求，团队间的语境要求极高，需要一个Hero人物
• 更加复杂的组织可以参考IPD/JIT/ERP/ALM/PERT等专业协同系统
• 未来一定是系统工程、统筹/统计学、控制论（器官学）的场景，当前已经有替代趋势

然而，无论多么强大高效的管理手段，都需要基于本身能力就很强的基础。本文只能帮助存在效率瓶颈的技术团队引入敏捷进行改进，如果项目已经空心化，债务多，一将无能累死三军，那么敏捷也救不了。

附录

• 总架构师，开发者和Master的边界分别是什么？

• 敏捷管理如何处理task间的依赖关系？

• 功能点到底是按照功能拆解、还是按照前后端代码拆解？

• Backlog由于人员与需求变动必然会膨胀，最后是否会变成一个垃圾堆？

其它参考

• GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas: https://www.youtube.com/watch?v=a-BOSpxYJ9M
• Backlog软件教程: https://backlog.com/project-management-guide/task-management/#assigning-tasks
• 岛国某公司的Agile介绍: https://www.yumemi.co.jp/agileoi/