职业与工作方法media.defense.gov
DIB 指南：识别敏捷废话（2018）
DIB Guide: Detecting Agile BS (2018) [pdf]
2019 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是美国国防部国防创新委员会(DIB)2018年发布的一份指南，教人识别打着“敏捷”旗号实为形式主义的伪敏捷项目，列出了诸多警示信号，例如开发团队从不与真实用户接触等。文档因出自国防部而颇具分量，多年来反复被 Hacker News 社区引用。
为什么经久不衰：它把“敏捷已沦为管理表演”这一普遍痛点用官方文件的口吻一针见血地写出来，无论行业如何变化，伪敏捷问题始终存在，因此常年被重新翻出。
HN 评论精选
敏捷转型往往把开发当成流水线管理，估算不准时责任全推给开发者
现代软件开发中“敏捷”流程令人沮丧之处在于，真正的敏捷是有价值且可实现的。但过去20年里我经历了至少十几次敏捷“转型”，结局都一样：管理层请来缺乏实际开发经验的“敏捷顾问”，把软件开发当成流水线来优化。在这种模式下，开发者只是组装零件的工人，管理层开出工单让他们“组装”。既然只是“组装电脑玩意儿”，每个任务都应可预测：有经验的流水线工人看一眼工单就该能精确估算工时，超过一天的工单必须拆小。如果做不到，模型就崩了——而既然不能让模型崩，那错一定在流水线工人身上……
commandlinefan查看英文原文
What makes the state of “agile” processes in modern software development so depressing is that actual agility is worthwhile and – if anybody were actually to adhere to actual agile project management principles – achievable. However, I’ve been through at least a dozen agile “transformations” over the past 20 years or so since XP kicked off this whole trend and they all end up going like this: management hires some “agile consultants” who don’t have much (or sometimes any) actual software development experience, so they see software development as sort of an assembly line process to optimize, Taylor style. Under that model, software developers are skilled (or semi-skilled) widget assemblers, and management creates tickets for the software developers to “assemble”. The agile consultant’s role, then, is to make that happen as fast as possible. Since it’s just a matter of assembling some “computer stuff”, every task is predictable: an experienced assembly line worker with one or two years of experience ought to be able to look at a widget/ticket and estimate +/- 5% exactly how many hours it should take to complete. Any widget/ticket that’s estimated > 1 day can be broken into multiple smaller tickets of < 1 day each. If this isn’t the case for any of the tickets, the whole model breaks down and, since we don’t want the model to break down, this must a priori be true: if one of the assembly line workers takes too long on a task, the fault must lie with the assembly line worker, because, the assumptions have already been established to be accurate.
团队不接触真实用户，根源在于走出舒适区需要付出真正的努力
这份文档很棒，尤其有国防部的名头加持。文中指出项目并非真正敏捷的关键信号之一：开发团队没人与真实用户交谈、观察他们实际使用软件。我认为这主要是“舒适区”问题：招募用户很难，管理层不放心让开发者直接接触客户，开发者得离开舒适的办公室，远程团队更难安排，在办公室里凭空想象并设计功能又很满足自我。我见过很多地方连产品负责人都从不接触用户，整天只管着待办列表。
harryf查看英文原文
This is a great document, especially with the DoD name on it to give it weight. > Key flags that a project is not really agile: Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code. This one is a largely a "comfort zone" problem IMO; - Recruiting users, especially for B2C products is tricky - Management get nervous about "unwashed developers" talking to customers - Developers have to leave cosy offices - In remote teams it's even harder - It's tricky to schedule without disrupting normal work - Imagining the world and designing features for it in a cosy office is a great ego trip - Nobody really knows how best to interact with users - Business people get nervous about developers having opinions ... etc. Many places I've seen even Product "Owners" never talking to users and basically spending all time managing the backlog. All very comfy and getting out of that comfort zone takes significant effort. I once gave a talk about the fundamental flaw of much mobile app development which is summarized in this slide - https://i.imgur.com/v1qmR8m.jpg ... the "older generation" making apps on big screens, fast networks while sat a desk for a younger generation on the move, that barely knows what a mouse is.
敏捷并非普适，它适合 Web 类项目，不适合安全关键和硬件工程
我们有没有证据表明敏捷真的有效？适用于什么项目？这是份国防部文件，但战斗机显然不能用两周冲刺来设计，机体没法那样改，所以飞行软件也不该用敏捷开发。安全关键系统更不该代码先行，而应做建模和形式化验证。我认为敏捷很适合做电商网站。XP 确实源自 NASA，但那是具体的东西，不加班很重要；而“现代敏捷”的 MVP 和迭代那套源自网络创业环境，未必该强加到工程领域。
shubb查看英文原文
Do we have any evidence that Agile actually helps, and for what kind of projects / companies it helps? It's just I note this is a DOD document, and I don't think we should be desiging jet fighters in 2 week sprints. Airframes probably can't be modified like that. So it follows that, within a waterfall project, the flight software shouldn't be developed agile either. Beyond that, I don't think safety critical systems should be produced code first. We should probably be doing modelling and formal verification and stuff like that. I think agile is a great way of making e commerce websites. Sure, XP came out of NASA, but XP is a specific thing. Not working overtime is important in XP. 'Modern Agile' on the other hand cares about things like producing an MVP and iterating, which originated in and are appropriate in a web startup context. I'm not sure they should be forced in an engineering context.
文档内容过于直白，在组织内部反而难以传播
这份文档里说到点子上的地方太多了，但我没法分享给公司里合适的人，因为会被视为攻击和冒犯。不知道该怎么委婉地表达，它实在太扎心了。
aristophenes查看英文原文
There are so many spot-on things in this document that I cannot share it with the appropriate people in my organization as it will be seen as an attack and offensive insult. Not sure how I could be gentle about it, it's quite damning.
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com