为何谷歌之类大厂程序员认为敏捷开发是瞎扯淡？ 第1页

曾几何时，敏捷已经成为软件开发流程的标配了，软件开发管理必谈敏捷，不按照Sprint来展开进度都不好意思说自己有项目管理，不搞迭代式开发似乎就搞不了产品开发，不过，这个行业也该醒醒了。

敏捷这玩意，最开始就是所谓“定制软件开发”(Custom Software Development)界的人搞出来的概念，之后主导敏捷的大佬们，也都是这个圈子里人，那么什么叫“定制软件开发”呢？用大白话说，就是软件外包。

当然，外包也有高端和低端之分，低端被压榨得吐血，高端的知道怎么驾驭反复无常的客户，这种高端外包人士，往往有个名字叫做“咨询师”，嗯，是不是一下子高大上了很多！

这些咨询师在和翻脸比翻书还要快的客户打交道过程中，总结出了对策，他们意识到客户都难（shi）以（mei）给（yuan）出（jian）明（de）确（da）需（sha）求（bi），指望客户一次想明白产品怎么做是不现实的，所以，干脆这样，让客户一点一点提出需求，我们也就一点一点做，做出来一点东西，让客户看一看，也许客户很满意，也许客户终于想明白真实的需求，那我们慢慢改。

打个比方，客户说他想要造一座金字塔，你作为“咨询师”，认为这座金字塔要造10年，肯定不能指望一次设计好就一口气做完，于是问客户这个金字塔是要干什么？客户说要当坟墓，于是，你提出先做一个小坟墓的功能，能装木乃伊那种。客户同意了，你哐哧哐哧做了一个月，制造了一个小型地下墓室，演示给客户看，客户看了，一拍大腿，说看到这个墓室才想明白，其实他要的不是金字塔，要的是一个有排场的墓地，这样简陋埋在地下的墓室不够牛逼，于是你和客户达成第二阶段设计，做一个带兵马俑方阵来让这个墓地显得有排场，客户同意了，于是你又哐哧哐哧做了一个月，做了一个小型兵马俑方阵。客户看了兵马俑方阵，又一拍大腿，说这个方阵还真牛逼，但是能不能增加一些现代元素，把古代兵马俑换成现代装甲兵团，你于是又……

如此，周而复始，每个阶段只完成客户一个需要，当然，我上面只是一个荒诞的例子，但是你应该能够get到敏捷的含义。

最重要的是，客户虽然说不清最终的目标，但是同意每个小阶段的目标，也就是说，客户要为每个小阶段付钱。既然他愿意付钱，那他反复无常又怎样，毕竟，最后的产品是客户的，“咨询师”获得的是报酬。

敏捷开发就是这么一回事。

然后，不光是外包行业，是整个IT行业的开发者都发现，“产品设计者”和“客户”有很大的共同点，那就是，他们都是一样的无法一次描述清楚产品的最终形态，也一样的傻逼。

于是，可以用来对付无能客户的敏捷开发，也别用来对付无能的产品设计了。

既然产品设计者都讲不清楚具体需求，而且需求还总变，那就用敏捷方法哄你开心好咯，这也就是“敏捷”一下子流行起来的原因。

还好，这实际上还有明白人，《启示录》的作者Marty Cagan就觉得这是搞笑，如果产品设计者自己脑袋里都没有清晰的模型，那么怎么控制最终产品的形态呢？Marty Cagan一针见血地之处，敏捷开发也就能在定制软件方面糊一糊，真正合格的产品经理，必定会交给开发团队清晰严谨的产品说明。

当然，这世界上大部分客户和产品经理依然无能，他们达不到Marty Cagan的要求，所以，就继续这么得过且过吧。

我们也不要那么绝对，我们要接受这世界上有无能的从业者的事实，或者说，要接受这世界的复杂性和变化性超过了一些从业者的掌控能力，所以，敏捷开发依然有市场。

那么，大厂里是否可以用敏捷呢？

以我个人的体会，可以搞敏捷，但是很容易陷入“伪敏捷”的陷阱。

我在微软Exchange工作的时候，也是按照2周一个Sprint的周期前进，但是，并不是每个Sprint都有可demo的进度，产品设计者并不会根据sprint的反馈澄清不清晰的需求，每个team的燃尽图(burndown chart)都好漂亮，但是最后release却总是要delay……

咱们就别自欺欺人了好不好，对于超大型项目，你可以搞一些敏捷概念，但是别把敏捷当做挡箭牌，你需要敏捷之外的一些东西来保证项目做好。

让我更直白一点：

1. 你不要甘心做一个无能的产品设计者，傻呵呵看每个demo的结果才想出新的需求，你一开始就应该对产品的最终形态有把握；
2. 你不要指望各自为政的Scrum Team真能把自我运转的很好，需要有一个制度来协调多个Scrum Team之间的关系。
3. 你不要指望一个sprint接一个sprint就能做出好产品，你必须要有一个大的长远计划。

最早发现这些问题的，往往是大厂的人士，因为他们真正在实操超大型软件项目，他们真的能体会到所谓敏捷开发真的是一个虚伪的皇帝新衣。

敏捷开发是手段，提高开发效率才是目的。

要了解敏捷开发产生的背景，它是针对过去那些庞大复杂低效的开发流程的，它试图解决研发效率问题。

google目前的开发效率已经很高了。

基于互联网开源协作的开发模式，持续集成，持续发布，自动测试，code review等等敏捷开发的一些思想和方法已经渗透到Google等众多互联网公司的研发体系里了，自然没必要再强调敏捷了。

支持者鼓吹敏捷是包治百病的万灵药，反对者轻蔑地声称敏捷的唯一用处是对付那些永远搞不清需求的傻X客户——两者我都不认同。

至于敏捷到底好不好，我觉得很简单：

如果项目是一个big clean problem，敏捷是瞎扯淡；

如果项目中有很多small dirty problems，敏捷就算不是万灵药，也是特效药。

谷歌等大厂程序员为什么说敏捷是瞎扯淡？

因为谷歌做的是big clean problem（貌似谷歌也只擅长做big clean problem）。

比如搜索引擎，就是一个典型的big clean problem。无论你用什么技术去实现，它的核心功能只有一个：输入关键词，返回尽可能相关的搜索结果。

这种事情，你必须在写下第一行代码之前，就得有完整的思路，项目从始至终都瞄着一个目标前进。按敏捷那种小步快跑、想到哪做到哪的风格，一辈子也别想做成。

但是还有另一类项目，恰恰相反，功能并不明确，只能沿着一个大方向前进，随时做好调整的准备。

比如facebook早期、社交网络刚兴起的时候，大家一窝蜂地做社交应用。但具体是做熟人社交？陌生人社交？用户到底想要什么？聊天？约X？

这些需求、方向上的问题，不仅开发者不知道，连用户自己都不知道。只能双方互相摸索，各自找到突破口了。如果你还坚持big clean problem那种一根筋的做法，那最后连怎么死的都不知道。

其实，现实中大部分项目，既不是纯粹的big clean problem，也不是纯粹的small dirty problems，而是介于两者之间。

所以我对敏捷的态度，不是好或者不好、用或者不用，而是搞清楚在什么地方用，把最敏捷的团队和技术，放到最dirty的战场。

---

  damon-dance-for-me 网友的相关建议: 
      

不要以为敏捷这种东西很高级。敏捷就是搞出来快速改需求用的，每个sprint都给一次改需求的机会。

不懂需求的客户太多了，在瀑布开发那会改需求极其痛苦，所以敏捷的那帮人干脆拥抱改需求，把改需求制度化了。

谷歌之类的大厂看不起敏捷，是因为他们又不搞外包没有外部客户，内部客户也非常专业，不会搞不懂需求。

---

  lu-luce 网友的相关建议: 
      

因为大厂的程序员遇到的问题是整个太阳系只有自己会遇到的问题。

什么软件适合敏捷开发？？？就是那种已经被人反反复复开发过一万遍的软件。

比方说，开发一个网站。。这种东西的系统架构是什么样子。

三层架构呗。前端有页面。后端写组件。底下架设一个数据库。

需要多长时间？？？

之前其他项目需要多长时间，就多长时间。

需要哪些功能？？

客户要啥功能，就有啥功能。

好了。到了大厂。请问一下：

开发一个支持并发两亿用户的12306交易系统，需要几个模块？？需要多长时间？？？
开发一个可以逆向执行程序的编译器，需要几个模块？？需要多长时间？？？
实现一个和Word一样的文字处理系统。需要几个模块？？需要多长时间？？？

估计敏捷开发架构师们一个都回答不上来吧。

为啥，因为没有任何经验可以遵循。

---

  xie-dan-9 网友的相关建议: 
      

感觉现在这个答案下的回答，基本没有看原题目的内容啊。

原来答案说的很明白啊，并且举了例子来说明差别：

1，Scrum 是很好的流程，只是google 觉得不适合其企业文化。

2，一般公司是工业化模式，也就是各自模块，Scrum是很好的。这类似于工厂生产模式，大家水平差不多。所有员工是围绕着项目的。

3，google 的企业文化是主工程师文化，如果无法理解，可以理解为球星文化，整个项目是围绕这个主工程师的。这在美帝类似XX工作室的建筑师等设计师方式。

原文说得很明确，google 是店大欺客，不存在在工程师级的天天改需求。他们工程师是要求8-20个月，然后出一个革命性产品。

这样的公司当然把以定需求、求沟通、补短板等的Scrum 模式是瞎扯淡了。

对于中国目前的绝大部分公司和工程师，你不是这个水准。还是Scrum 最好。

---

  julyedu.com 网友的相关建议: 
      

因为客户和PM都没法一次性完美描述出他们的整体真实需求，经常是每次提出部分有代表性的需求。

既然如此，那我们何不每次就做好一部分？

就比如下图，先做个前半身就去上线，后半身等下个阶段在做……

就比如用户提出要求“给我做头牛，看起来非常有活力，并且斗志十足”

我下面这个不就完美的按照用户需求，快速制作出来了吗？而且还非常完整。

毕竟你提需求的时候又没说让我按隔壁老王家的那头牛做……

现在PM经常就是我有一个绝妙的创意XXX，其实你直接说我这个功能要抄XX多少好……

（图自：推特网友marmot_wild）

七月在线为了助力秋招，现在不光送出ML、DL、Python、概率论等4大精品课程；

还将送出1500元京东卡、5本《西瓜书》等，并且人人都有好礼！

可以在七月在线官网参与哦

---

  jetwaves 网友的相关建议: 
      

目前绝大部分的“敏捷”项目都是披着敏捷外皮的传统项目，特别是在传统行业。

• 非技术高层管理者看到敏捷，想到的是可以更快出成果更快刷KPI，更快的抓住风口
• 非技术中层管理者看到敏捷，想到的是可以随便改需求，更好的PUA码农去加班
• 非技术的基层PMO看到敏捷，想到的是我代表用户做你爹，我负责的调研原型设计都可以能省则省，朝令夕改又不用我写代码

在某些积累深厚的传统行业，所谓的敏捷团队都是过去那些老人参加了一波短期培训混了一波证书凑出来的，项目的扯皮耍锅的本质没有改变，只是换用了敏捷方式的扯皮，和敏捷方式的甩锅。

项目管理的本质难题在于评估成本，获取资源和预算，制定计划，和执行。

有高手管的情况下，成本和周期评估准确，风险可控，出了问题高手兜底，那么想敏捷就能敏捷，想瀑布流就能瀑布流，

没有高手管的情况下，所有问题都可以甩锅给后续周期或者用ppt解决问题

而且敏捷的成果是需要时不时做阶段性重构的，否则一路quick and dirty 搞下来最后就是一大坨shit hill

---

比如我见过某个银行的“敏捷”项目，所有需求没有正式的完备的文档，没有原型（低保真的都没有），搞清楚需求要靠读user story，搞清楚业务需求需要一个个人的打电话聊天，有个wiki但是十次有8次找不到需要的东西，一个输入框的交互大概前前后后加起来有三五十个user story，全读下来几万字是肯定有了。

所以我当时发了个朋友圈：

管理混乱的项目有两种：

• 一种需要一份文档
• 一种有了文档，但是还需要一份《如何读文档》

这还只是混乱的一部分，sprint的规划瞎搞，任务耗时瞎估算也不搞投票，单个任务边界模糊随口定，周期完成了只复盘情绪，不复盘具体工作，另外还不做代码review。

这破玩意儿就算是挂着敏捷的名义，由scrum master带着，跟敏捷有一毛钱关系了？

---

很多所谓的敏捷项目如果不是一开始就参与，那基本上就约等于在信息黑洞的漩涡里逐渐被吞噬，老人觉得什么都是不言自明的，新加入的新人或者接手的新人完全找不到头绪，还要敏捷地快速出活

所以说是纯粹扯蛋

---

  yhnolh 网友的相关建议: 
      

敏捷开发不是扯淡，但适用范围比较有限，而且很容易被用坏

我在Amazon和Microsoft的多个不同的部门工作过，其中只有一个部门对agile的用法我认为是比较成功的，而且是有效率的。国内我暂时没有发言权，但我想应该不会比这个更好

那个组用的是类似kanban的模式，大致有如下特点：

• 不设置整个项目的deadline，不设scrum周期
• 没有固定的backlog grooming，sprint planning和retro会议（由组里大佬在线下完成，当然一般会和这个module/feature的负责人讨论），每个人自己有一个backlog
• 每个任务没有estimate，每个人如果做完当前任务，第二天自动去领自己backlog里的下一个任务来做（对，如果当天提前做完，可以直接划水），否则就继续做当前没做完的任务
• 每天standup只解决一件事，有没有被block，有的话如何unblock（因为你现在做到哪个任务在scrum board都一眼可见）

最后我们整个项目比预计提前了一个月完成，效果非常好，上线3个月，零sev-2

这种模式唯一的缺点就是，需要有一个非常牛逼，软硬实力俱佳的大佬带着整个项目团队，所以极难推广。即便Amazon和Microsoft这种大厂，这种人至少也是千里挑一，可能一个VP下面顶多有一两个，对于普通程序员来说，参与进这种大佬带的项目的机会本就不多，所以很多人对于agile的理解也就仅限于自己组里那个既繁琐又残疾，为了agile而agile的诡异模式

至少我经历过的其他的部门，无一例外都陷入了下列几种情况之一（或者不止）：

1. 一切从demo出发，demo频率过高
2. 随意修改sprint定好的计划
3. 无视任务复杂度，强行压缩时间
4. retro提出的问题不去解决，导致同样问题重复出现
5. 重feature轻operation，tech debt从不处理或极少处理
6. scrum相关会议太多且时间太长

我个人认为，一个团队的scrum想要运转良好，需要两个条件，缺一不可——

一是scrum master具备充分的知识和经验，知道怎么根据组里的人员构成，项目特点等因素选择合适的scrum模式

二是老板自己需要理解并认同agile的内涵，而不是简单地认为agile = rush或者agile = infinite flexibility

然而实际操作中，大部分团队二者都不具备，所以你懂的

---

  feng-dong 网友的相关建议: 
      

一方面来说，敏捷方法有用，而且是全范围的有用。所谓全范围，是指选择开发方法这件事不能按照项目类型去划分。请大家 Google 一下「Code is Design」。软件业的所有所谓「制造」过程对应到其它行业都是「设计」步骤。而在其它行业中，就算你造帝国大厦或者土星五号，在设计蓝图阶段也是采用快速迭代演进的。更不用说软件本身的实际测试成本更低，根本没有不迭代的理由。

但另一方面，敏捷方法的原旨里像 Sprint、burndown 这些概念在实践中发现比较多余。比如说 burndown，看起来是一种量化方法，但要发挥作用，需要有人对 estimation 做大量的 calibration。而现实中就没见过有 team 花人力做 calibration。结果只能是瞎猜、压力、和政治斗争的混合物。费了精力去应用所谓自动化工具，但这些工具的输入是主观垃圾，输出更是垃圾。

真正应用的也就是 backlog，standup 而已。

---