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

Takeawys

敏捷是在信息化时代下端着咖啡的泰勒计件制工厂模式，可以进行一些快餐任务的开发。

作者的“敏捷”经验

• 在H司有18级以上的2位领域专家的直接且长期的指导。成功，失败与争吵都有
• 曾经开发并迭代了多年DevOps的Agile系统，对无数竞品进行过体验分析，亲自设计与落地。协助过复杂工程问题的自动化。
• 自身作为基层Scrum Master，并使用自己开发的Agile系统，双手沾泥地带领10名以上组员进行招聘和交付
• 做过集群调度器等复杂任务的编排方案

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

什么是敏捷

关于方法论

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

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

关于敏捷自称的“文化”再补充一点，企业文化与明确的流程规范不一致，它是隐形的，且与创始人强相关。即使是创始人后期也难以改变隐形的文化，更不要说外部文化或流程了。

Scrum的历史

Scrum最开始由经营学家竹内弘高 (Hirotaka Takeuchi) 和野中郁次郎 (Ikujiro Nonaka) 提出，其中野中郁次郎的模型SECI模型在另外文章介绍过，是知识论入门的很好材料。

然而后续Ken Schwaber对敏捷的贡献就很尴尬了

• 其本人并没有双手沾泥的管理经验可以背书
• Scrum理论无法证明或证伪

业界对敏捷的定义

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

在微软的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.

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

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

这些定义都非常散乱

• 是递归定义
• 缺少准确的指导度量，到底是计件，精益生产，还是最优调度？验收的标准是什么？
• 根据反脆弱理论的《风险共担”和尾部概率”》推演，任何系统都不可能同时拥有“灵活性”和“确定性”，比如你无法让一家制造商同时保持“定制强”与“大规模”。

同时，此定义也产生了很多歧义，假如按照大厂的定义

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

业界软件分析

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

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

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

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

个人对敏捷的定义

结合实际工作经验，本人对敏捷定义如下

The agile methodology is a set of high-frequency leverage management that gains the certainty with trade-offs.

它最终的作用

• 为组员提供了确定性。作为雇佣关系的一环，只要包工头能提供高工资，高效率与高确定性，那么工作满意度就会上升。
• 为上级领导提供进展的确定性，比如燃尽图是否有大范围弯曲，可以理解为一种情绪价值。
• 敏捷仍然无法对抗至上而下的官僚惯性与KPI，比如流程可信，看板监督。

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

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

敏捷的可度量性

即使很多咨询项目的敏捷变革号称成功了，敏捷这种“高频操作”并不能证明其可以提高速度，原因如下

• 项目变革是否成功，取决于时代下的大环境，风口，运气与机遇。
• “变革”的定义是业务结果成功，还是过程正义？谁来当裁判？
• 只要涉及变革，就一定有内斗，“变革者”可能基于“敏捷”的名义，对你的项目过程进行指手画脚却不承担失败后的责任。

项目实践的难度

回到项目管理本身

• 多阶段小迭代本质上是充分提高Master的管理杠杆，要求管理者能在有限时间内，对事项的拆解、估算、解释与验收的过程进行高频管理，这种管理模式必然需要精英模式（meritocracy），才能产生高执行力。然而问题是在大厂，这种工作是只有大头兵才干的“杂活”。

• 如果所有任务能够像燃尽图中那样理想地估算时间准确，那么意味着

  • 保守主义与强KPI策略，即工作内容是重复可预测的（最少动作组合，消除无用动作，增加产出数量）。既然是重复工作，为什么不封装为库函数呢？反之，如果工作估算是不可预测的，凭什么估算的时间最终就成了交付承诺？
  • 无法进行POC/MVP/高阶设计流程，同样，新特性的设计/会议/需求/验证等时间是难以估算的。

• 带项目超过6个人后，就需要牺牲确定性或质量，来换取杠杆率了

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

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

在我可观测范围内，即使很多工作多年的Leader

• 带领的项目仍然陷入在债务的泥潭中无法脱身，导致组员提桶跑路。
• 年复一年进行新项目立项，然后老项目等死，和城市年底突击花预算的挖路一样

进度管理的核心要素

进度管理中需要工时与节奏来降低不确定性。

工时管理

工时本身是制造业术语，然而我们刻舟求剑地将计件制度引入了软件开发中。

当然，我们并不应该排斥工时估算与进展管理。

• 工时类似于分支预测中的cache，就算估算工时有偏向（命中失败），也会作为缓存为下次估算提供对比借鉴。通过后期改进总结就可以发现与理想估算间的GAP，进而持续改进。

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

最后，通过将所有工作进行估算，可以生成依赖有向图，就可以一定程度上解决"不可控"的紧张，也能每天对比计划反省是否达成目标。

我推荐的流程如下，投入仓位占比为3:2:1

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

那么在成熟重复的任务中是如何估算时间呢？

我一般将具体的Task分解到1～2Day，并遵循SMART原则，避免估算出现较大偏差。比如，任务描述必须写"登录模块的前端菜单录入与对UI界面的实现"，并指定某个前端开发人员；而不是"前端登陆模块"这种模糊的不可度量的任务。如果某个人长期都做不好分解，而且培训也没用的话，赶紧换。

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

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

节奏管理

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

投资的不可能三角

我们期望降低系统的方差，提高系统总体的效率，而非单个节点的高效。然而根据投入的“高收益、高流动性、低风险”不可能三角，我们不可能同时做到人力投资的最优点，况且找到系统编排的的最优解（排队论）成本非常高。

关于收益的度量标准，一般有如下

• 总体交付吞吐量
• 单个需求的平均等待时间
• 管理成本：比如审批，验收与会议等

从风险管理角度看，项目中并不需要像机场航班那样的精益调度去追求最优解，而是风险排除，最优先考虑的是低风险下的总体交付吞吐量。

风险与流动性

由于风险永远不会消失，在收益保持不变的情况下，我们只能牺牲流动性去降低风险，其中最常见的近似解就是固化项目节奏，降低人力流动性，让系统步调一致地拉链式前进。

其主要方式为，如同央行调整准备金一样对速度进行间接控制，让供给与需求侧去适应承受不确定性

• 需求侧：业务需求方，要求其必须在某天之前录入，否则延期要下个月。
• 供给侧：具体IT功能的设计，开发与测试必须按期完成，并预留冗余，可以接受停工待料。

这样做的原因是，权力与责任是相等的，既然你对进度与质量负责，那么你有权拒绝供给侧的需求插队。

同时，人力出现空转是可接受的

• 确保一定冗余以方便承接临时需求
• 更底层问题可能在于需求不足，比如顾客不认可，竞争加剧，或者售价过高
• 实在不行就分一些永远干不完的任务，比如开源软件升级，运维，运营，宣传文案等，最好是免测试投入的改造工作

常见管理问题

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

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

How to program if you cannot？

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

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

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

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

至于如何三选一，假如你是为了创业而提高速度，选型上优先找外援，不要陷入到技术细节中，而要重点投入在用户场景的匹配与验收标准，因为业务侧需要反复试错才能找到真正方向。

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

边想边做还是先想后做？

很多需求与方案可能在排期阶段都不清晰，然后拍脑袋估工时，最终产生延期。

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

当然作为工程商人，我们也可以使用更灵活抽象的“金字塔式承包制度”，但是它需要组员的高度密切配合。这种高杠杆的管理方法也曾经实操过，虽然效率高，但是管理太累。

质量

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

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

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

读者看到这里可能会问，为啥招聘时不能提高员工的素质？客观大环境如此。针对员工熟练度较弱的情况，此刻就不得不花费你的管理时间。

Stand-up meeting有没有用？

stand-up meeting是手段，不是目的。

• 开会的人力成本极高，大部份都是在挂机，这样scrum master会很心累的
• 要求你实施开站会流程的上级，管理重心一般过高，自己双手不沾泥

如果你的团队当前还在每日站会，可以进行如下改造

• 不要围一圈依次说自己干了啥，而是让你作为主持人去按照KPT原则提问
• 后续改造成隔日会或周会，然后进展需要AI化总结/报表化，最终让项目从pull based的迁移到push based

外包人员咋敏捷？

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

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

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

如何进行二次授权？

作为管理者，要明确度量标准，降低反馈延迟，授权不授责。

• 功能按照Story-task两层进行划分，Story是场景，task是具体的搬砖任务，测试基于场景Story进行验收。
• 每个Story成立临时小组，授权组长进行二次管理
• 需求固化到文字中，减少会议，可度量验收

敏捷与DevOps的关系是什么？

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

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

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

• JFrog/Azure/Rally/TeamCity 全家桶，注意此类产品可能涉及到出口管制，大公司采购或使用要慎之又慎
• 国内的Coding、简单云以及各种被云包养的平台，但是体验还是比较弱，感觉没有招到很牛的产品经理
• 通过拼装开源产品（Jenkins/Gitlab）自己定制一套，有定制成本，仅适有钱养工具团队的大公司。

scrum master是啥？

在Scrum的文档中，敏捷master是方法论专家，他只帮助组员如何使用管理工具，但是却对项目进展不兜底。这种无实权的角色很难在公司站稳。

在大型组织中，敏捷master就是大头兵，带着一群螺丝钉搬砖，坐在办公室干着类似富士康里工厂领班的工作。

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

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

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

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

总结

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

• 适用于10人左右的Team，人数大于小作坊，然而比不过Enterprise
• 敏捷管理对Scrum Master的技术与决策要求，团队间的语境要求极高，需要一个通才
• 更加复杂的组织可以参考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/