为何谷歌之类大厂程序员认为敏捷开发是瞎扯淡？
以下是一些谷歌等大厂程序员可能认为敏捷开发是“瞎扯淡”的详细原因：
1. 对“敏捷”本身的误解和教条化执行：
“敏捷”不等于“混乱”或“无计划”： 很多时候，团队在推行敏捷时，将“拥抱变化”和“快速迭代”理解为不需要前期规划，随心所欲地修改需求。这导致项目缺乏明确方向，代码质量下降，返工率高。
“Scrum是唯一的敏捷”： 有些团队将Scrum奉为圭臬，不顾项目特点和团队情况，强制执行Standup、Sprint Planning、Review、Retrospective等所有仪式。但对于一些高度专业化、需要深入研究和长期规划的领域（如底层系统、AI算法研究），这种短周期迭代可能并不适用，反而会打断思考流程。
忽略敏捷宣言的“精神”： 敏捷宣言强调“个体和互动高于流程和工具”、“可工作的软件高于详尽的文档”、“客户合作高于合同谈判”、“响应变化高于遵循计划”。然而，很多团队只抓住了“快速迭代”和“交付软件”的字面意思，忽略了对“个体”、“协作”、“文档”和“计划”的必要性和价值。
2. 对大型复杂项目和技术挑战的适应性问题：
系统复杂性导致“快速迭代”的局限： 在开发大型分布式系统、操作系统、编译器、数据库等复杂项目时，系统的各个部分之间存在高度耦合。一个微小的改动可能引发连锁反应，需要大量的测试和重构才能保证稳定性。在这种情况下，短周期的、频繁的“快速迭代”可能无法有效管理风险，反而会增加不稳定性。
技术研究和探索需要时间： 很多创新和前沿技术的研究需要长期投入和深度思考，无法在两周的Sprint内看到明确的成果。将研究项目强行塞入敏捷框架，可能会迫使研究人员为了“可交付”而牺牲深度，扼杀创新。
依赖性和接口管理的挑战： 在大型组织中，一个项目可能依赖于多个团队开发的多个服务。如果这些服务遵循不同的敏捷节奏，或者接口设计不清晰，那么整合和依赖管理将变得非常困难。迭代的“快速”可能难以跟上外部依赖的变化。
3. 对“个体和互动”的过度强调与专业团队的价值冲突：
忽略专业知识的积累和传承： 大型公司通常拥有高度专业化的团队，成员在特定领域拥有深厚的知识和经验。敏捷强调“个体和互动”，但如果执行不当，可能会导致知识碎片化，难以形成系统性的技术深度和架构设计能力。
“全能型选手”的悖论： 敏捷常常鼓励“全栈开发”和“团队成员互相支持”，这在小型创业公司或许可行。但在大厂，这种模式可能稀释个体的专业优势，导致在某些领域缺乏足够深入的专家，影响高难度问题的解决。
低估文档和知识沉淀的重要性： 尽管敏捷宣言提到“可工作的软件高于详尽的文档”，但在大型项目和知识传递中，高质量的文档（如架构设计文档、API文档、技术指南）至关重要。如果团队为了追求“快速交付”而牺牲了文档，日后的维护、 onboarding 新成员、以及技术复用都会变得异常困难。
4. 组织文化、流程和政治的制约：
大型组织的官僚主义： 即使团队内部尝试敏捷，但如果整个组织依然是瀑布式管理，决策流程漫长，需求优先级经常变动，那么敏捷的优势就难以发挥。
管理层对敏捷的误读： 有些管理者将敏捷视为提高生产力的“灵丹妙药”，要求团队“做得更快更多”，但没有理解敏捷的核心在于“适应性”和“价值交付”，反而将其变成了一种绩效考核的工具。
“敏捷教练”的误导： 有时，一些未经深入实践或理解的“敏捷教练”会推广一套僵化的方法论，而不考虑实际情况，反而让团队感到束缚和困惑。
资源分配和规划的冲突： 敏捷强调灵活调整优先级，但在大型公司中，资源分配通常需要更长期的规划和审批。这使得敏捷的灵活性常常受到现实的掣肘。
5. 对“客户合作”和“需求收集”的现实挑战：
“客户”定义模糊： 在大型企业内部，真正意义上的“客户”可能非常多，且需求复杂且经常冲突。谁是真正的客户？他们的优先级是什么？这些问题在大厂内部往往没有明确的答案。
“客户”的专业度不足： 有时，所谓的“客户”可能对技术细节和可行性了解不深，提出的需求不切实际或充满矛盾。如果敏捷团队盲目响应这些需求，可能会导致项目走偏。
需求的变更成本高昂： 在某些领域，需求一旦确定并开始开发，后期变更的成本可能非常高昂，涉及多个子系统、合同、合规性等。此时，敏捷的“响应变化”就不再是轻描淡写的事。
总结来说，谷歌等大厂的资深程序员认为敏捷开发是“瞎扯淡”的主要原因，并非否定敏捷的理念，而是对以下几点的批评：
教条化、僵化的敏捷实践：不分项目类型、团队特点地套用统一的敏捷框架。
对复杂项目和技术深度的低估：认为敏捷的“快速迭代”难以应对大型系统和前沿技术的研究。
忽视专业知识和文档的重要性：导致知识碎片化和维护困难。
组织文化和流程的阻碍：敏捷的灵活优势被大厂的官僚主义和复杂流程所稀释。
对“客户需求”的模糊和挑战的忽视：盲目响应客户需求可能导致项目失控。
这些程序员并非反对“适应变化”和“快速交付有价值的产品”，而是认为 敏捷开发更像是一种哲学和原则的指导，而非一套万能的、需要照本宣科的流程。在实际操作中，需要结合项目特点、团队能力、组织环境等多种因素，灵活应用敏捷的原则，甚至需要借鉴其他开发模式的优点，才能真正实现高效和高质量的软件开发。他们看到的更多是那些 为了“敏捷而敏捷”的无效实践，而非敏捷开发本身。
网友意见
曾几何时，敏捷已经成为软件开发流程的标配了，软件开发管理必谈敏捷，不按照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……
咱们就别自欺欺人了好不好，对于超大型项目，你可以搞一些敏捷概念，但是别把敏捷当做挡箭牌，你需要敏捷之外的一些东西来保证项目做好。
让我更直白一点：
- 你不要甘心做一个无能的产品设计者，傻呵呵看每个demo的结果才想出新的需求，你一开始就应该对产品的最终形态有把握；
- 你不要指望各自为政的Scrum Team真能把自我运转的很好，需要有一个制度来协调多个Scrum Team之间的关系。
- 你不要指望一个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的战场。
不要以为敏捷这种东西很高级。敏捷就是搞出来快速改需求用的，每个sprint都给一次改需求的机会。
不懂需求的客户太多了，在瀑布开发那会改需求极其痛苦，所以敏捷的那帮人干脆拥抱改需求，把改需求制度化了。
谷歌之类的大厂看不起敏捷，是因为他们又不搞外包没有外部客户，内部客户也非常专业，不会搞不懂需求。
因为大厂的程序员遇到的问题是整个太阳系只有自己会遇到的问题。
什么软件适合敏捷开发？？？就是那种已经被人反反复复开发过一万遍的软件。
比方说，开发一个网站。。这种东西的系统架构是什么样子。
三层架构呗。前端有页面。后端写组件。底下架设一个数据库。
需要多长时间？？？
之前其他项目需要多长时间，就多长时间。
需要哪些功能？？
客户要啥功能，就有啥功能。
好了。到了大厂。请问一下：
开发一个支持并发两亿用户的12306交易系统，需要几个模块？？需要多长时间？？？
开发一个可以逆向执行程序的编译器，需要几个模块？？需要多长时间？？？
实现一个和Word一样的文字处理系统。需要几个模块？？需要多长时间？？？
估计敏捷开发架构师们一个都回答不上来吧。
为啥，因为没有任何经验可以遵循。
感觉现在这个答案下的回答，基本没有看原题目的内容啊。
原来答案说的很明白啊，并且举了例子来说明差别：
1，Scrum 是很好的流程，只是google 觉得不适合其企业文化。
2，一般公司是工业化模式，也就是各自模块，Scrum是很好的。这类似于工厂生产模式，大家水平差不多。所有员工是围绕着项目的。
3，google 的企业文化是主工程师文化，如果无法理解，可以理解为球星文化，整个项目是围绕这个主工程师的。这在美帝类似XX工作室的建筑师等设计师方式。
原文说得很明确，google 是店大欺客，不存在在工程师级的天天改需求。他们工程师是要求8-20个月，然后出一个革命性产品。
这样的公司当然把以定需求、求沟通、补短板等的Scrum 模式是瞎扯淡了。
对于中国目前的绝大部分公司和工程师，你不是这个水准。还是Scrum 最好。
因为客户和PM都没法一次性完美描述出他们的整体真实需求，经常是每次提出部分有代表性的需求。
既然如此，那我们何不每次就做好一部分？
就比如下图，先做个前半身就去上线，后半身等下个阶段在做……
就比如用户提出要求“给我做头牛，看起来非常有活力，并且斗志十足”
我下面这个不就完美的按照用户需求，快速制作出来了吗？而且还非常完整。
毕竟你提需求的时候又没说让我按隔壁老王家的那头牛做……
现在PM经常就是我有一个绝妙的创意XXX，其实你直接说我这个功能要抄XX多少好……
（图自：推特网友marmot_wild）
七月在线为了助力秋招，现在不光送出ML、DL、Python、概率论等4大精品课程；
还将送出1500元京东卡、5本《西瓜书》等，并且人人都有好礼！
可以在七月在线官网参与哦
目前绝大部分的“敏捷”项目都是披着敏捷外皮的传统项目，特别是在传统行业。
- 非技术高层管理者看到敏捷，想到的是可以更快出成果更快刷KPI，更快的抓住风口
- 非技术中层管理者看到敏捷，想到的是可以随便改需求，更好的PUA码农去加班
- 非技术的基层PMO看到敏捷，想到的是我代表用户做你爹，我负责的调研原型设计都可以能省则省，朝令夕改又不用我写代码
在某些积累深厚的传统行业，所谓的敏捷团队都是过去那些老人参加了一波短期培训混了一波证书凑出来的，项目的扯皮耍锅的本质没有改变，只是换用了敏捷方式的扯皮，和敏捷方式的甩锅。
项目管理的本质难题在于评估成本，获取资源和预算，制定计划，和执行。
有高手管的情况下，成本和周期评估准确，风险可控，出了问题高手兜底，那么想敏捷就能敏捷，想瀑布流就能瀑布流，
没有高手管的情况下，所有问题都可以甩锅给后续周期或者用ppt解决问题
而且敏捷的成果是需要时不时做阶段性重构的，否则一路quick and dirty 搞下来最后就是一大坨shit hill
比如我见过某个银行的“敏捷”项目，所有需求没有正式的完备的文档，没有原型（低保真的都没有），搞清楚需求要靠读user story，搞清楚业务需求需要一个个人的打电话聊天，有个wiki但是十次有8次找不到需要的东西，一个输入框的交互大概前前后后加起来有三五十个user story，全读下来几万字是肯定有了。
所以我当时发了个朋友圈：
管理混乱的项目有两种：
- 一种需要一份文档
- 一种有了文档，但是还需要一份《如何读文档》
这还只是混乱的一部分，sprint的规划瞎搞，任务耗时瞎估算也不搞投票，单个任务边界模糊随口定，周期完成了只复盘情绪，不复盘具体工作，另外还不做代码review。
这破玩意儿就算是挂着敏捷的名义，由scrum master带着，跟敏捷有一毛钱关系了？
很多所谓的敏捷项目如果不是一开始就参与，那基本上就约等于在信息黑洞的漩涡里逐渐被吞噬，老人觉得什么都是不言自明的，新加入的新人或者接手的新人完全找不到头绪，还要敏捷地快速出活
所以说是纯粹扯蛋
敏捷开发不是扯淡，但适用范围比较有限，而且很容易被用坏
我在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的诡异模式
至少我经历过的其他的部门，无一例外都陷入了下列几种情况之一（或者不止）：
- 一切从demo出发，demo频率过高
- 随意修改sprint定好的计划
- 无视任务复杂度，强行压缩时间
- retro提出的问题不去解决，导致同样问题重复出现
- 重feature轻operation，tech debt从不处理或极少处理
- scrum相关会议太多且时间太长
我个人认为，一个团队的scrum想要运转良好，需要两个条件，缺一不可——
一是scrum master具备充分的知识和经验，知道怎么根据组里的人员构成，项目特点等因素选择合适的scrum模式
二是老板自己需要理解并认同agile的内涵，而不是简单地认为agile = rush或者agile = infinite flexibility
然而实际操作中，大部分团队二者都不具备，所以你懂的
一方面来说，敏捷方法有用，而且是全范围的有用。所谓全范围，是指选择开发方法这件事不能按照项目类型去划分。请大家 Google 一下「Code is Design」。软件业的所有所谓「制造」过程对应到其它行业都是「设计」步骤。而在其它行业中，就算你造帝国大厦或者土星五号，在设计蓝图阶段也是采用快速迭代演进的。更不用说软件本身的实际测试成本更低，根本没有不迭代的理由。
但另一方面，敏捷方法的原旨里像 Sprint、burndown 这些概念在实践中发现比较多余。比如说 burndown，看起来是一种量化方法，但要发挥作用，需要有人对 estimation 做大量的 calibration。而现实中就没见过有 team 花人力做 calibration。结果只能是瞎猜、压力、和政治斗争的混合物。费了精力去应用所谓自动化工具，但这些工具的输入是主观垃圾，输出更是垃圾。
真正应用的也就是 backlog，standup 而已。
敏捷的核心在于价值观，结果被咨询公司和畅销书作者们搞成了SOP……
而敏捷的价值观其实是废话，一句话总结就是创造性工作没有SOP……
对于谷歌微硬这类大厂的程序员来说，谈敏捷有可能是瞎扯淡，因为对于螺丝帽来说，哪里还需要什么敏捷？人很多，工作分的很细，好好搬砖就可以了。对于创新项目，中小项目，敏捷开发的优势是毋庸置疑的。这就像小马过河，谷歌程序员说的不一定错，但是可能并不适合你，要自己根据自己的情况来决定。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有