諺
对敏捷与估算工时的看法
2019-03-16 / modified at 2024-10-26 / 5.5k words / 19 mins

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

作者的敏捷经验

  • 在H司有18级以上的2位领域专家的直接且长期的指导。成功，失败与争吵都有
  • 曾经开发并迭代了多年DevOps的Agile系统，对无数竞品进行过体验分析，亲自设计与落地，协助复杂工程的自动化。
  • 自身作为基层ScrumMaster，并使用自己开发的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软件包为例，它主要有Board规划功能与Kanban计算功能，它在现实中是参考了泰勒与丰台JIT的两套管理体系，实现了一套统计与推送的经验框架。

$2还原论(与整体论对立)敏捷框架泰勒科学管理The Principles of Scientific Management生产计划标准工时统计トヨタ及时制度(Toyota JIT)看板(かんばん)其它噪音细节质量流程

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

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

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

个人对敏捷的定义

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

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

它最终的作用

  • 为组员提供了可确定的工作量，因为职员都非常抗拒临时塞需求，而更喜欢确定性。作为雇佣关系的一环，只要包工头能提供高工资，高效率与高确定性，那么工作满意度就会上升。
  • 为上级领导提供进展的确定性，比如燃尽图是否有大范围弯曲。
  • 敏捷仍然无法对抗至上而下的官僚惯性与KPI

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

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

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

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

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

    • 意味着保守主义与强KPI策略，即工作内容是重复可预测的（最少动作组合，消除无用动作，增加产出数量）
    • 没有POC/MVP/高阶设计流程，本质上与工厂中打螺丝加快流水线转速是一样的

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

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

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

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

进度管理的核心要素

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

工时管理

敏捷的工时管理本质上就是刻舟求剑的计件制度。

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

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

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

我推荐的流程如下

  • 成熟重复的任务：基于工时研究与标准工时统计进行估算，半天为最小的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%的员工就不了了之

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

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

Stand-up meeting有没有用？

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

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

外包人员咋敏捷？

在敏捷开发中，讲究的是"特种部队”式，“外科手术”式的全能开发团队，然而在现实，很多企业事实上并不重视自己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等预算非常多的大公司。

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由于人员与需求变动必然会膨胀，最后是否会变成一个垃圾堆？

其它参考