为何谷歌之类大厂程序员认为敏捷开发是瞎扯淡？
敏捷开发又不是万能的，它也有不适合的场景。
原问题已经描述的很清楚了：
因为Google项目有极端简单的外部界面，以及极端复杂的内部。因而，大部分工作对“客户”来说几乎是不可见的，所以，没有办法写关于它的客户可见的故事。
Google的项目基本上是反Scrum的。
还「知乎程序员」，难道「知乎程序员」能把这个问题解决了吗？
首先，我认同问题描述中引用的 Quora 答案，主要是其中描述的 Google 的运作方式，以及这种运作方式背后的理由。
其次，我不会把 Google 的运作方式叫做反敏捷。我不在 Google，但我会把我见到的 Facebook 运作方式叫做敏捷的成功落地。尽管 Facebook 内部的做法跟教科书里面定义的敏捷很不一样，但我觉得从敏捷的原则来说一切都是说得通的，只是实践不一样。不过敏捷说的不正是，教科书里的实践不一定行得通，你需要根据你的实际情况进行调整吗？能够成为大厂，意味着实践落地非常成功，所以才能获得巨大的商业成功。
最后，这些大厂成功落地的敏捷，不一定适用于你的公司，你还是要自己折腾。
我觉得最重要的点是: responding to change over following a plan. 这是很多号称敏捷的公司做不到的， 因为稳定性大于一切， 生产环境的不可预料的错误意味着商誉，真金白银的损失。 这是不可接受的， 于是在指导思想上，这些公司也无法做到 change over following a plan。
我听说Facebook的有一点实践是：move fast and break things。 我觉得这是”敏捷“的， 这样的信念并不是稳定毫不重要， 只是在权衡稳定和变化的时候，把变化放在第一位。 这是有很大差别的。
实践敏捷的公司总是会遇到这些两难矛盾的权衡， 当权衡的天平倾向稳定，敏捷完全被流程和制度抑制， 于是敏捷就扯淡起来。
链接没看，只是从题目表述上就觉得题主的逻辑有问题。
“X人物认为Y行为是瞎扯淡，所以Y行为确实是瞎扯淡”的命题，表达的逻辑是以下哪一种：
- A.“X人物认为Y行为是瞎扯淡”是“Y行为确实是瞎扯淡”的充分条件
- B.“X人物认为Y行为是瞎扯淡”是“Y行为确实是瞎扯淡”的必要条件
- C.“X人物认为Y行为是瞎扯淡”是“Y行为确实是瞎扯淡”的充要条件
- D.“X人物认为Y行为是瞎扯淡”与“Y行为确实是瞎扯淡”毫无关系
最有可能的理解是，在google公司的一个/一些特定项目中，敏捷开发无法达到团队的预期，所以他们不选择敏捷开发，仅此而已。Y行为不是X专属的，而是适用于所有人的，那么X的个人经验不能作为Y的定性结论。所以上面的命题解读，只有D是正确的。
而与此同时，我们都知道，敏捷开发是由小厂推广普及的，还是由大厂推广普及的呢？
所谓的彼之蜜糖，吾之砒霜，大概就是这么个情况了！
老祖宗不是说好的兼听则明吗？以单方面的观点提问，相当不明智。如果题主提出的问题类似于“quora上有人说敏捷开发是瞎扯淡（链接1）同时也有人认为敏捷开发有很强的实用价值（链接2），大家觉得哪一种说法更合理”这样的对比，不失为一个好问题。因为业界大佬老早就说过了——没有银弹！
顺便一提，逻辑能力差是做技术（不限于IT技术）的硬伤，直接决定了天花板的下限高度。题主好自为之
每个公司每个项目差异性太大，适合自己就行，但是某些成天吹牛逼的咨询师和教练，他们看到会不爽的
在入职 Google 之前，我以前所在的公司基本上都是敏捷开发，因为组比较小，业务相对比较简单，敏捷开发可以很好的执行。我也已经基本习惯了敏捷开发，直到来到 Google。
我同意大多数答案，由于 Google 代码的复杂程度，除了部分 UI 相关的组，很难在一个 sprint 内做出可以度量的进度。因为大部分 feature 的复杂度和整体度，也很难将其拆分为更细的 ticket。
如果是这样，每一个 sprint，甚至连续好几个 sprint 都在做一个 ticket，那实际上敏捷开发那一套就失去了其意义。相反，每周的各种 sprint planning，sprint close 以及 retrospective meeting 等实际上浪费了更多时间，我认为倒不如给回到开发者，让他们更高效地产出。
最大的不习惯就是每天早上没了 standup 感觉真是很有意思，这样大家都可以按照自己的作息来工作，以至于不到开会基本上看不到所有人。另外如果不是 TL，会议也相对比较少，感觉可以专心的码代码。各种 NB 的 infra 可以让你开心地解决各类复杂的问题，期间也很少有人来骚扰你，我想这也是工程师文化的一种体现吧。
利益相关：我的言论仅代表我自己的理解和感受，与我所在的公司无关。
感觉微软作为一个大厂已经被开除了（逃
自从加入了Office之后，我发现我以前对Office的印象都是错的。作为一个开发古老企业软件的部门，竟然在自己的每一个地方都在实施一些激进的政策，包括但不限于
- 想办法让VC++编译还没支持的版本的STL
- 搞前端
- 敏捷开发
- 不先写spec而是先写代码
- 测试不管覆盖率
等。既然Office都可以敏捷，那还有什么东西是不能敏捷的呢？所以我现在越来越倾向于，敏捷失败的原因只有两个
- 你的项目实在是敏捷了没有用，譬如说写火箭的驱动程序，因为火箭的驱动程序的需求是不会有变化的，而敏捷的诞生是为了对付需求不断变化（含实际需求并没有频繁变化但是甲方脑子进了屎表达不出来只好频繁更改自己的表达的情况）的项目。
- 你的人不行，实施不了。
Google里面有些部门不敏捷也可能是有原因的，譬如说他的需求没有不断变化，举个例子天国的GFS，就不需要敏捷，谁要去频繁地改需求呢？
相比之下，我觉得google reader就是一个可以敏捷的项目（逃
不知是有意还是无意，原文的标题就有点引战的味道。
其实仔细看内容的话，作者对于敏捷的基本价值观是认可的，问题在于以研发为主的项目没法以客户驱动的方式去工作，而敏捷的倡议者原来设想的主要场景是“为客户开发定制软件”。从这个角度看，作者的观点应该没什么大问题，不同领域的工作方式本来就应该是有所不同的。
之所以说有引战的味道，一是原标题用了 "nonsense" 再翻译成“无稽之谈”，其中包含的褒贬色彩有点过于强烈；二是 Agile 现在范畴已经太大了，很容易一蒿子打翻一船人；要是你认为 SCRUM 代表了 Agile，那 XP 或其他流派的拥护者多半有话要说。
不过这篇文章揭示的问题还是应当注意的。那就是现代软件开发领域已经覆盖很广、也分化得非常厉害，不同行业的情况可能千差万别，想用一套理论（哪怕只是作为模板）去指导所有开发领域，确实不太现实。这不光是敏捷，也是所有软件开发理论都要面对的问题。
曾几何时，敏捷已经成为软件开发流程的标配了，软件开发管理必谈敏捷，不按照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就能做出好产品，你必须要有一个大的长远计划。
最早发现这些问题的，往往是大厂的人士，因为他们真正在实操超大型软件项目，他们真的能体会到所谓敏捷开发真的是一个虚伪的皇帝新衣。
从一个method，一个tool应该是高内聚，低耦合的。
越是完整的application，product，越应该是低内聚，高耦合。(office 99%的功能你都不用的，你就用最核心的1%功能，核心体验设计是非常内聚的)
敏捷开发适合前者，快速出一大堆没人性体验的理性工具，但是你要让产品有人性，有体验，敏捷开发做不到。
高耦合的设计一般很难抄袭，敏捷开发用来抄也只是抄个皮，没灵魂。
引用的Quora的答案写的很清楚了，但并不代表谷歌没有反例。很不幸，我个人认为Android就是一个错误应用敏捷开发的案例，虽然有其历史原因。
Android是一个复杂系统，拥有Quora答案里面说的simple interface and ton of internal complexity的特质。这注定了直接套用敏捷开发就会出现简单功能堆砌造成缺乏整体设计的毛病。
Android组内的文化并不注重设计文档。他们缺乏开发前讨论整体设计的环节，所以即便出于某些其它原因有了事先写好的设计文档，也不会受到Android组的足够重视，不会有充分的讨论。而且在后续执行的过程中会因为一些口头交流较为随意地修改（甚至推翻）文档中的结论，造成文不符实的情况。
Android的细节设计大体上是在代码审阅的过程中完成的，故而时常出现设计审查的范围仅仅限于前后一段时间内的相关代码，而与历史代码不能够有机地融合起来。又由于缺少文档解释大面上的设计，使得一些比较复杂的系统的构造只存在于一些骨干的脑中，使得一旦这些人完全无法离开Android开发项目，并且成为系统重构的瓶颈。这也造成了新人上手极为困难，往往需要半年的时间才能够对整体有一个大概的认识。
曾经的Android为了快速发布，不重视自动化测试，使得Android每个版本之间的行为总有些许差异，又对现在重构祖先代码造成了障碍。现在的Android组因为仍然需要发布新功能与iOS竞争，不得不在代码重构与新功能之间做出平衡。又因为代码高度耦合，超出了人脑处理的极限，使得新功能的开发变得困难，反而影响了新功能的发布。
这也是有原因的。当年老乔拿出iPhone的时候，Android组感到了无比的压力，必须要尽快发布。所以他们仓促间牺牲了这些似乎可有可无的东西，发布了第一代产品。后来为了在和iOS竞争的过程中不落后，很长一段时间都没有改变开发模式。
现在Android组在努力做出一些改变，只不过10年的沉疴又岂是一朝一夕能够挽救的。
面对公司现在所谓的敏捷开发我真的是要吐血：
- 项目启动阶段，需求不明确，又赶着出东西，各种功能使劲怼。
- 一个礼拜上线一次，添加杂七杂八的新功能，修改老功能。
- 老功能改着改着就成 bug，客户周周报 bug。
- 一个礼拜上线一次，修复 bug。
- ...
到现在我都没想明白，一周上一次的意义何在。
互联网产品的特点就是马太效应明显，不在头部，九死一生都不止，神级pm存量历历可数，期待救世主pm降临本身就是一种虚妄，所以敏捷或者精益创业更实实在在的价值是让众多拍脑袋不靠谱的产品定位产品需求快速腐烂，避免纯面相boss编程，避免0的愚勇，避免过度设计，从而减少浪费。但是敏捷从来也不是银弹，敏捷实施的本身也需要敏捷迭代着进行，这样坚持下去离正确的方向就会更近一些。
另外敏捷有几个维度，不仅仅是项目需求管理，对研发团队本身素质要求也较高，比如技术框架的选型开发测试交付模式是否满足敏捷开发框架的基本要求，持续集成的基本要求，还有研发团队是否是全栈式研发团队，团队成员是否有开放的心态和良好的协作沟通精神，也许正是基于这些要求，部分习惯传统瀑布式舒适区的研发人员对敏捷精益创业等新的方法论表现出比较偏激，排斥的倾向。
当然，谷歌等大厂自身就自带pm属性的神级程序员群体另当别论，一些技术创新驱动的产品，需求稳定的传统toB产品另当别论，别问我为什么，先看看自身公司现有的文化、流程和制度特点，差不差钱，团队能力和业务类别，对号入座一下，到底哪个环节在扯淡就有答案了。
我不是来回答的只是想问问这是啥情况
问了下其他人也有
https://www.zhihu.com/video/1146760342788075520bug么？看到了土拨鼠？别说挺可爱的。有好心人分享一下这个表情包么？
？？？土拨鼠是什么操作？
不觉得扯淡，但从我入职场开始，就超级反感这种反伦理的开发模式。俗话说，欲速则不达啊
天天用着敏捷开发（甚至混沌开发）的过程中，习惯成自然的同时，不要忘记了：
- 敏捷开发只是众多开发流程的一种；
- 敏捷开发要解决的是“无法很好一开始就确定怎么开发才能得到用户满意的程序，因此无法一开始就可以把一切都设计得很好，然后照着实施“的问题。如果问题本身已经很成熟，或者不会乱变，那就没必要“敏捷”；
- 敏捷之源头是需求提出方（比如PM）一开始搞不清楚自己想要什么，或者做成什么样才能让用户满意。如果能够碰到一个一开始几乎就能想明白的PM，其实就犯不着浪费生命和资金去Sprint来Sprint去的。我们可以承认现实并不完美，但是不需要把应对不完美的方式当作至高追求；
- 敏捷开发宣言只是大略的定了几个原则。到了落地时，根据场景，组织文化，人员水平，行业特性等的不同，具体怎么敏捷还得好好沟通和协调；
- 敏捷对PM、开发、测试、设计、运营的能力要求非常高，尤其是沟通能力；
- 敏捷是有代价的，即最后软件会写的七零八落，用A需求的基本设计，做了B需求的功能，再适配到C场景上。敏捷了一段时间，代码七扭八拐之后，不做架构重构，将会对维护性产生灾难性后果；
- 有些场景下，真的无法在1～2周内取得可以度量的进展，这种项目是不能用敏捷的方式管理的
总之，要解决的问题用敏捷有效就用，用敏捷不好就换更适合的。不用上纲上线。
敏捷不是瞎扯淡。
把敏捷等同于开站会、画看板、写周报、使用某种特定工具或产品，是瞎扯淡。
我在某外企的时候，旁边有个组每天10点开半个小时站会，5点半又开半个小时站会。 这种开会的制度是瞎扯淡，你要问相关负责人为什么这样开会，他会告诉你这是敏捷开发的做法。 敏捷开发：这锅我背咯？
客户和PM都没法一次性完美描述出他们的整体真实需求，经常是每次提出部分有代表性的需求。
既然如此，那我们何不每次就做好一部分？
就比如下图，先做个前半身就去上线，后半身等下个阶段在做……
（图自：推特网友marmot_wild）
