问如何用敏捷的方法开发优秀的软件？

EN

正式的答案是你误解了敏捷，敏捷并没有支配需求，利益相关者这样做。敏捷的核心不是将您的需求刻在石头上，而是让它们随着您的发展而出现，并与您的客户密切联系，从中受益于进步的洞察力。

但这都是理论。您所看到的确实是许多采用敏捷工作方式的软件生产线的共同特点。

问题是，倾听客户的意见并迅速响应客户的需求往往很快就会导致根本不考虑产品或进行任何设计。过去由远见和专业知识提供的一个积极的过程可能而且经常会恶化为一个被动的、完全被动的过程，由客户的愿望来满足。这将导致仅仅制造“将完成工作”的最基本的必需品。

如果当时的制造商是“敏捷”的话，汽车就永远不会发明，因为所有的客户都要求一匹更快的马。

不过，这并不会使敏捷变得糟糕。有点像共产主义。这是一个很难实现的好主意，因为人们只是在做别人的事情。这种方法/意识形态/宗教诱使他们产生这样的想法:只要他们通过运动和/或遵循规则，他们就会做得很好。

编辑

苏莱特曼：

具有讽刺意味的是，敏捷从自动化行业(即丰田汽车)进化而来。

还记得自动化的黄金法则吗？“首先组织，然后自动化”。如果你自动化了一个失败的过程，最好的结果就是加速所有出错的事情。丰田的人不是白痴。

采用任何新方法的典型原因是事情进展不顺利。管理层承认这一点，但他们可能不理解核心问题。因此，他们雇佣了这位专家，他们发表了关于敏捷和Scrum的富有弹性的演讲。每个人都喜欢它。因为他们自己的原因。

开发商可能会想：“嘿，这可能管用。我们会更多地参与业务问题，我们可以为填补积压工作提供投入。这可能是一个机会，让销售和客户服务部门了解我们做什么，为什么有必要，我们会让他们在我们达成的协议被透明地烧掉的时候，把它们从我们的头发里拿出来。”不要再“停止你正在做的事情，这需要现在就做”的一些人，你不想拖延突然出现在你的办公桌。

另一方面，销售、客户服务或业主可能认为这是一种获得(回)控制一个部门的黑匣子的方式，据推测，该部门正在做一些必要的事情。他们不知道在那里发生了什么，但他们很确定问题的核心是埋在那里的某个地方。因此，他们引入Scrum，安装自己选择的产品所有者，突然之间，他们就拥有了所有的控制权，所有的字符串都在他们的手中。现在呢？..。艾尔..。

真正的问题往往是商店一开始就没有很好的组织，而且这种情况并没有改变。人们被分配了他们无法处理的责任，也许他们可以，但博斯先生一直在干预和破坏他们所做的事情，或者(根据我的经验)，关键的责任根本没有得到承认或分配给任何人。

有时，随着时间的推移，非正式组织会出现在正式界限之间。这可能会部分弥补缺乏正式结构的问题。有些人只是做他们擅长的事情，不管他们是否有一张名片来证明。敏捷/Scrum的直截了当的引入可能会立刻毁掉这一切。因为人们现在被要求遵守规则。他们觉得他们过去所做的事情是不被欣赏的，他们得到黄色的小文件，上面写着一些小故事，相反，他们的信息是：“不管你在做什么，没有人在乎”。不用说，这不会对这些人产生特别的动机。他们最好开始等待订单，不再采取任何主动行动。

所以事情变得更糟了，得出的结论是敏捷糟透了。

敏捷并不糟糕，它对于维护项目是很好的，如果谨慎地应用，它甚至可以对新的开发有好处，但是如果错误的人不理解它或者因为错误的原因而采用它，那么它可能是最具破坏性的。

在敏捷中，似乎根本没有吸引人的地方。

你在比较苹果和橘子。在传统的瀑布中，如果你的需求说你需要必须拥有的东西，你就会得到菲亚特。如果要求说它必须是一流的，你会得到一辆法拉利。

在敏捷中也是如此。如果你的需求必须停止，你就会得到菲亚特。如果你有优秀的故事，你就会得到一辆法拉利。敏捷真正的力量就是你先做必须拥有的事情。没有建立一个超级酷扰流板两年，然后错过了最后期限的发动机。

长话短说:你得到了你想要的。如果你计划一辆跑车，你就会得到一辆跑车。敏捷根本改变不了这一点。如果您的敏捷过程提出了对Fiat的需求，不要责怪敏捷，而应该怪那些只需要Fiat的人。

然而，我所知道的所有敏捷过程都强烈支持必须满足的需求。这些都是最优先考虑的。

正如他们应该-再看看你的卡诺模型:如果必须满足的要求没有得到满足，客户将不会接受该产品。然后你的快乐就不重要了。

在敏捷中，似乎根本没有吸引人的地方。

任何事情都不能离事实更远。

敏捷过程通常强调以下几点：

• 经常交付的工作产品，你可以得到反馈。
• 将特征分成可以在短时间内完成的小部分。
• 按优先顺序执行这些部分。

没有什么能阻止你给予“愉悦”的特点一个高度优先。这完全取决于那些负责确定优先事项的人。

现在，确实有许多这样的人不愿意冒险，因此可能不会给予“快乐者”高度优先考虑。但在一个非敏捷项目中，情况依然如此。