V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 572 天前的主题，其中的信息可能已经有所发展或是发生改变。

笔者从专职做程序员到现在管理技术团队，学习实践敏捷过程中一些感悟，分享给大家，一起交流。

同时，本篇文章英文版同步发布在 dev.io，技术分享无国界，欢迎大佬们指点。

======================== 正文 ========================

浅谈敏捷：你的团队在正确实践敏捷吗？

引子

“今天加一下班把这个需求做了吧，老板催得很急。”--某时某厂某项目经理

敏捷，这个曾经作为灵活速度的代名词，在过去 20 年里逐渐发展成为 IT 界中被程序员们时常挂在嘴边的看似深奥的专业术语。敏捷开发（ Agile Development ）作为很多开发团队的项目管理框架首选，因为其简单、灵活，更重要的是它字面上暗示着 “快”。想一想无数码农为了赶进度而无偿加班吧。

敏捷 = 快速交付？

当你的开发团队遭遇项目延期、产品质量降低、士气低下以及客户关系恶化时，你的朋友或许会推荐你使用敏捷开发：“嘿，兄弟。我听说最近敏捷挺火的，你可以试一下。” 但是，当你在团队中推行敏捷一段时间后，你很可能会发现它并不好使：产品发布后依旧大量的 bug 、无穷无尽的加班、源源不断的最高优先级需求。在与老板的日常会议中，老板问你：“听说你们正在用敏捷来提升交付效率，很棒！所以我下周能看到之前给你提的重要功能吗？”

“敏捷就是快速交付”，这是很多敏捷实践者中最大的误区。其实，敏捷并不一定意味着快；相反，它还会引入更多额外工作，从而可能导致更慢的交付功能。对，你没看错。严格意义来说，敏捷会降低交付速度。例如，极限编程（ XP ，敏捷框架之一）要求为每一个功能编写单元测试，这会引入 1-2 倍的额外代码。

所以，为什么还有人说敏捷是软件开发的项目管理神器呢？它既不能提升开发效率，也不能减少工作量，那它究竟有什么用？这是很多敏捷实践者遭遇最多的灵魂拷问。如果你无法及时作出令人满意的回答，开发团队最终会放弃敏捷，而回到他们最初习惯的工作模式。

什么在阻止项目成功？

作为管理过大型复杂项目的项目经理，你可能会觉得项目失败稀松平常。据 TeamStage 调查，2022 年中，项目失败率高达 70%，超支项目占比 55%，而有 75% 的项目经理对其项目成功没有信心。“胜败乃兵家常事”，话这么说没错，但长期的项目失败会导致严重的资源浪费、人才流失，甚至企业破产。

project-constraints

如果你考过 PMP 专业项目管理证书或学习过项目管理，你应该对上图比较熟悉。每个项目都由下面 4 个因素（维度）约束：

时间（ Time ）：时间节点，工作时长
成本（ Cost ）：人力资源，项目预算
范围（ Scope ）：功能模块，影响领域
质量（ Quality ）：缺陷，稳定性，性能

如果一个软件项目需要在 3 月份交付，预算为 $100k ，要求支持 1k 用户同时使用，那么它的约束维度就已经固定了。看起来一切按部就班。但是，一旦客户要求添加一个重要的新需求，项目范围就扩大了，而开发团队不得不在其他维度中寻求妥协。

如果你是该项目的项目经理，你会如何抉择？

时间：“这个功能非常重要，要不咱们周末辛苦加班吧。”
成本：“如果你做不了，我可以找人来帮你。”
质量：“说实话我还没测过，但进度催得紧，先上线再说吧。”

这些互联网黑话是不是很熟悉？作为程序员，你可能并不知道项目的全貌。但实际上，最主要的原因是项目约束因子变形的厉害，从而产生了一系列问题，最终导致项目失败。

敏捷到底是什么？

根据上面的分析，我们知道，很多项目因为制约因素的改变而导致了 “动作变形”，从而引发一些列问题，最终导致项目失败。传统瀑布流模式会保证时间维度不变（用炫酷的甘特图来保证），但其他因素形态各异，所以经常出现的症状为：超支（成本）、残次品（质量）、源源不断的需求（范围）。

然而，从经验上来看，成功的软件项目都建立在质量至上，也就意味着交付的产品必须是可用的、易用的、有价值的，这正是敏捷框架其中一个核心。敏捷框架要求固定质量、时间、成本这 3 个维度，唯留范围这个维度可变。例如，在敏捷框架 Scrum 中，某一个冲刺（ Sprint ）中的用户故事（ User Story ）在冲刺开始之前是可以根据情况灵活改变的，以保证单个冲刺中交付的价值最大；而极限编程中更是允许团队根据情况随时替换复杂度相同的用户故事。同一个敏捷团队通常是固定的质量保证（要求回归测试）、固定开发成员（一般 12 个以内）、固定的交付周期（两周一次的冲刺），不同的是上线交付给用户的功能。这样的结果就是：稳定、高质量、符合客户预期的持续交付，而且敏捷团队还是不断自我完善的。

我不期待这一篇几百字的文章就能让一个对敏捷不了解的 IT 从业者瞬间就能明白敏捷开发带来的好处，而且要推行敏捷到整个开发团队甚至整个组织也不是一朝一夕。但我可以肯定的是，正确实践的敏捷可以有效减少组织中恶性加班和低质量交付的问题，这也是大多数 IT 从业者想要解决的问题。

敏捷 = 开车

如果你经常开车（字面意思），稍加注意你应该会容易发现开车用到的基础动作：看道路，踩踏板，转方向盘。根据路况，不断重复这三个简单动作，让你能够去到任何城市中道路的任何目的地。如果不注意路况，或盲目开快车，很可能会导致车毁人亡。

敏捷也是一样，无非就是一个收集反馈、不断调整、小步快跑的开发流程。这种注重反馈回路的流程可以让整个团队在不断变化的竞争市场中增强反脆弱性，能够帮助团队企业存活下来甚至长期繁荣。这是一个注重人性、创新以及自由文化的流程。

不过，敏捷或许并不适合有雄心壮志的创业者，因为有些创业者开的是一辆外壳酷似超跑的踏板车，他们需要强壮的牛马日夜兼程的踩踏板而让其看起来像超跑，否则就会被身后真正的跑车给挤下山去。要让他们承认自己开的只是一辆踏板车是非常困难的一件事情。而殊不知，只有慢下来甚至停下来，他们才或许有时间去打造真正的跑车。