毫无疑问， 灵活性是一件好事，而敏捷的体现很有意义。 与称为瀑布的脆弱实践相比，敏捷明显更好。 但是，在实践中，灵活的方法通常会造成深远的伤害，实际上，敏捷/瀑布二分法在这里并不适用。

我看到了多少个名为Scrum的敏捷变种真正杀死了公司。 我所说的“杀人”并不是指“文化恶化”，而是当公司的股价在两年内下跌近90％时。

什么是敏捷？

敏捷源于Web咨询环境，它带来了一些好处：与不知道自己想要什么的挑剔的客户一起工作时，通常必须从两个选项中进行选择。 还是打败客户：建立期望，为变更支付适当的费用，保持平等关系，而不是从属关系。 或者接受客户的不正确行为（例如，许多设计人员必须这样做），并针对客户功能障碍来确定工作流程。

程序员通常无法与客户很好地合作。 我们太过直率了。 我们喜欢行为明确的系统。 这使我们与人文学科的互动变得复杂，因为我们倾向于按字面意思接受每个请求，而不是弄清他们真正想要的是什么。 在公司一级，敏捷方法（在咨询环境之外）走得更远，这表明工程师不够聪明，无法理解内部“客户”的需求。 这意味着将工作喷洒在“用户故事”和“迭代”上，这常常使我们对完成的工作不满意，也失去了对事情发展的长远前景的希望。

通常，通常会创建两种类型的工作，无论是在公司内部还是承包商。 高层聘请了高素质的专家。 在底部-他们不想做的所有工作都扔到一边。 显然，一类顾问会受到尊重，而另一类则不会。 管理不善的咨询公司通常最终沦为低技能工作的垃圾槽。 Scrum似乎是为那些客户关系如此糟糕以至于每天都需要监视工程师的组织而创建的，因为它们已经成为基础工作的沉淀池，对于没人愿意做的职业毫无用处（可能这不是一项非常重要的工作） ，因此利率和尊重度较低）。

暴力透明

IT工作场所中有许多趋势使编程职业极度缺乏吸引力，尤其是对于富有创造力的聪明人。

最令人震惊的例子是开放式办公室。 他们没有生产力。 很难专心于它们。 他们是反知识分子的，因为人们害怕在工作中被看书（或只是思考）。 当您使人们假装要有生产力时，他们实际上会失去生产力。 开放式办公室通常不是为了提高生产力。 这是企业形象。 风险投资的初创公司使用这些布局向投资者演示，以使办公室看起来很忙。 （简而言之，开放式程序员更看重是办公家具，而不是所编写的代码）。 由于各种文化原因，这使开放式计划变得“酷”和“肮脏”，现在它感染了整个企业界。

众所周知，如果要求有创造力的人在工作中进行解释，他们就会失去创造力。 与软件相同。 程序员通常不得不单方面透明地工作。 尽管缺乏互惠性，但这些敏捷系统经常被滥用，并且要求羞辱操作的透明度。 他们没有从事某个人可能会喜欢的实际长期项目，而是沦为处理雾化的，功能性的“用户故事”，并且经常被禁止从事与业务的短期，近期需求无关的改进（通常从上而下）。 这种不正确但通用的敏捷版本排除了所有权的概念，并将程序员视为可互换的相同组件。

Scrum是最糟糕的选择，因为它有两个星期的“迭代”愚蠢。 这引起对人类行为中微波动的不必要关注。 绝对没有证据表明这种方法从长远来看确实可以加速或改善开发。 这只会让人感到紧张。 商业中的许多人认为这是一个很好的方法，因为工作“进展得更快”。 我已经在IT行业工作了十年，担任过经理和工作蜂。 这是不对的。

敏捷和Scrum特定缺陷

1.以业务为导向的发展。

与“瀑布”相比，敏捷通常可以发挥作用。 什么是瀑布？

瀑布方法确实很糟糕。 在其中，“工作滚动”，组织层次结构的每个级别在其中选择他认为是“有趣的材料”，然后继续进行下去。 项目由经理确定，体系结构由建筑师设计，个人期限由中层经理确定，实施由顶级工作人员（程序员）执行，然后将操作和测试转移到较低级别的工作人员。 这是一个极不实用的方案。 当人们感到所有重要的决定都已经做出时，他们就没有动力去做得最好。

瀑布再现了具有一定等级的功能失调的组织的社会模型。 反过来，敏捷通常会在没有明确定义的层次结构的情况下复制功能失调的组织的社会模型。

对于“高级”和“导演”等职位，我有不同的看法。 他们很重要，我本人可能不会接受低于董事级别的职位，但我讨厌他们的重要性。 如果您查看Scrum，它特别剥夺了高级，最有能力的工程师的权利，因为在这里，他们必须遵守既定流程（仅在创建的任务上工作，每周在滑翔机上工作5-10个小时）。 这些过程是为一个月前开始编程的人设计的。

就像一个失败的共产主义国家一样，它通过分散贫困来平衡人们，它以最纯粹的形式将整个发展置于一个较低的水平：没有明确定义，但明显低于被赋予全权决定工作的商人的水平。

在通常的实现中，敏捷增加了反馈的频率，但仍然没有赋予工程师任何真正的力量。 这是一笔失败的交易，因为这意味着当工作所花费的时间比预期的长时，程序员更有可能受到拖延或惩罚。 这会产生很多焦虑和仓促，但实际上与真正重要的事情无关：创造出色的产品。

硅谷犯了许多错误，尤其是最近五年，但做得对。 包括介绍“工程”公司的概念。 工程师管理整个公司并不总是更好，但是当工程师管理开发并确定优先级时，每个人都会取胜：工程师对分配给他们的工作感到满意（甚至更好的是，分配给他们自己），并且业务得到了更高的开发质量。

但是您有一个“商业公司”，那很好。 如果您需要人才，那就不要雇用工程师。 您可以聘请最优秀的人才作为顾问（起价为每小时200美元，并从此水平急剧上升），但不能成为“商业公司”的全职员工。 优秀的工程师希望在由工程师运营的公司中工作，在那里他们将参与工作计划，而不必找借口“ scrum masters”，“ product owner”和几层人文管理人员。

最终，敏捷（实践）和瀑布是面向业务的开发形式，因此，它们都不适合开发高质量的软件或激励员工。

2.年轻人的从属地位。

不幸的是，尽管几乎没有最好的工程师是年轻的，而且绝大部分优秀的工程师都不是男人，但是在软件开发中，已经出现了（绝对错误的）编程概念，即“年轻人的玩具”。

两周的敏捷迭代（或冲刺）和用户案例的问题在于，没有退出策略。 没有选项“到达[X]时，我们将不再需要这样做。” 该系统应该永远存在：面向业务的集会永远不会消失。 架构，研发和产品开发使程序员无法完成工作，因为它们不适合原子化的“用户故事”和两周的冲刺。

结果，对于或多或少有经验的程序员来说，以这种方式工作是不舒服的，因为他们想要承担这种结构中被忽略的项目类型，并且就短期业务价值而言，这类项目很难证明。 卓越的技术很重要，但是如果人们固执地不想被说服，很难说服人们这个事实。

我曾经在一家公司工作，该公司的产品经理说高级工程师和初级工程师之间的区别在于能够给出更准确的时间估计。 好吧，实际上不是。 而且甚至是侮辱。 我讨厌评估，因为它们会制定政策，而实际上并不能更快或更好地完成工作（实际上，通常情况恰恰相反）。

评估中最糟糕的部分是，它们会刺激可以评估的工作绩效。 这使程序员可以优先选择业务真正不需要的低级简单事物（即使笨拙的中级经理有不同的想法），但它是“安全的”。 真正值得做的每一件事都有不零的失败机会，以及太多的未知参数，无法合理估计时间范围。 敏捷对短期业务价值的关注最终使人们远离了公司真正需要的工作，以便实时管理每个程序员的声誉。

这种文化表明编程是幼稚的，您需要在35岁之前摆脱它。 我不同意这种观点。 实际上，我认为这是一个坏主意。 我已经30岁多了，我觉得自己才刚刚开始编程。 仅仅因为他们有足够的经验来骚扰高级程序员，就知道这种灵活的/混乱的过程与计算机科学无关，并且它不会增加价值，所以这是一个可怕的想法。

3.过于短期的做法，这既愚蠢又危险。

敏捷旨在用于没有足够信誉来与同等地位的同行进行谈判，并且面临紧迫的期限且每个客户项目都是存在风险的二级咨询公司。 他是针对“边缘”局外人的。 但这就是问题所在：Scrum通常部署到大型公司和有资金的初创公司。 但是人们之所以去这样的公司，是因为他们不想成为局外人 。 他们想要安全。 这就是为什么他们在这些公司工作而不是创建自己的公司的原因。 如果没有重大的个人利益，谁也不想落后。 在公司中敏捷意味着没有回报的痛苦和风险。

当每个客户项目都存在生存或严重的声誉风险时，敏捷可能是合适的解决方案，因为当公司面临风险时，关注短期迭代会很有用，并且从长远来看可能会消失。 在紧急情况下，积极的项目管理是有意义的。 作为永久性安排，这没有任何意义； 至少对于那些压力较小，娱乐性更好的才华横溢的程序员而言，并不是这样。

作为敏捷的一部分，技术债务会累积起来并无法解决，因为分配任务的业务人员要等到为时已晚或修复起来至少太昂贵才能看到问题。 而且，单个工程师仅根据当前的两周“冲刺”获得奖励或惩罚，也就是说，没有人会提前查看五个“冲刺”。 敏捷只是一个毫无意义的，短视的“冲刺”，一个接一个：没有进步，没有进步，只是一张一张一张一张地票，一张张一张票。

同意无意义的任务改组的人可以接受，但是真正好的工程师讨厌星期一早上去工作，却不知道那天他们会做什么。

4.他与建立事业无关。

单个用户的故事不利于工程职业。 到30岁时，您将有望在整个项目级别上工作，并且至少已准备好在基础架构，体系结构，研究或领导力方面超越该级别。

在紧急情况下，无论是寻求向重要客户或公司“作战室”放心的咨询，有关简历的想法都可以等待。 如果这对公司真的很重要，那么很少有人会放弃与职业发展无关的几周不愉快的工作或其他工作。 在这里，工作的重要性是重中之重。 如果您可以说：“我坐在总部，每天与首席执行官交谈20分钟，”这就是做愚蠢的工作的理由。

但是如果没有紧急情况，程序员希望他们的职业受到重视。 否则他们会离开。 “我曾在Scrum团队工作”表示您是一个出气筒。 做一个愚蠢的工作是一回事，因为首席执行官承认，一项不愉快的任务会增加数百万美元的价值（他会相应地予以奖励）。 但是，如果您只是被分配了“用户故事”和Jira门票，那么您将被视为输家。

5.目标是确定较低的比率，但假阳性结果的水平却高得令人无法接受。

建议将Scrum作为识别“落后员工”的好方法。 问题在于，它创造了更多的效率低下的程序员。 这是一个总跟踪系统，其中各个工程师详细显示了他们的工作进度并评估了生产率。

在有关公民自由的辩论中，经常提到一个常见的错误：“无所不能”。 有些人喜欢争辩说，例如通过执法来侵犯隐私不是问题，因为他们本身不是犯罪分子。 这些人错过了一些关键的事情。 例如，法律正在改变。 询问任何在1930年代是中欧犹太人的人。 即使对于受人尊敬的人，监视的状态也是焦虑的状态。

观察的事实改变了人们的工作方式。 在创意领域，这很痛苦。 如果您需要每天报告工作情况，几乎不可能进行创造性的工作。

我想到另一个话题： 对状态的敏感性 。 程序员喜欢假装自己已经克服了与社会地位有关的灵长类动物进化了几百万年的事实，但是事实是，社会地位很重要，承认这一事实并不令人尴尬。 老年人，妇女，少数民族和残疾人通常对工作场所的状况敏感，因为这是他们生存的问题。 持续监控工作表明缺乏信任和较低的社会地位，并且对地位最敏感的人（即使他们是最好的员工）也最先受到越来越多的监控。 如果他们觉得自己不被信任（以及文化还传递了什么，应该认可工作的每个要素？），那么他们很快就会失去动力。

敏捷，尤其是Scrum易受“无所不能”错误的影响。 如果您不是“坏工人”，那么您就不会每天滑行吧？ 唯一会就短期业务价值拒绝日常工作报告的人是想从公司偷钱的“懒汉”，对吧？ 好吧，不。 显然不是。

暴力透明文化的设计是对地位最不敏感的：从未受到工作压力的年轻，通常是白人或亚裔的特权男人。 对于那些认为人力资源和管理是浪费时间的人，员工应该简单地忍受屈辱和侮辱。

最好的员工通常会因实施敏捷/ Scrum而受苦，因为有效地消除了研发。 对短期“迭代”或冲刺的痴迷意味着无法尝试新事物，冒险行为。

关于落后员工的事实是，您无需敏捷即可识别他们。 人们知道他们是谁。 有些团队中充斥着懒汉，无能或有毒的人的原因是因为没有人对他们有所作为。 这是员工级别的管理问题，而不是工作流程级别的管理问题。

6.醉酒效果。

积极进取的管理似乎可以使一些稍微不称职的人有足够的工作能力。 我称之为醉酒效果：当女孩变得如此健康，但真正可爱的时候不再想要与您有任何关系。 — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .