如何用敏捷方法开发出色的软件？

客户满意度的卡诺模型定义了不同类别的产品功能。其中有

1. 必须具备的质量：如果未实施这些质量，则客户将不会接受该产品。

2. 吸引人的品质（愉悦）：客户通常一开始并不期望的功能，但被发现时会引起兴奋和愉悦。

有吸引力的品质显然具有很大的商业价值。当使用不到5.000欧元的菲亚特汽车可以满足所有必不可少的条件时，他们会让人们以500.000的价格购买法拉利。

但是，我知道所有敏捷过程都强烈赞成必须满足的要求。这些总是获得最高优先级。似乎甚至没有在敏捷中获得吸引人的品质的地方。

我相信敏捷流程在软件开发中非常有用。但是，如何将它们应用于创建令人愉悦的高质量软件产品，而不仅仅是满足勉强满足最低要求的最低要求？

附录：正如前两个答案所指出的那样，将必须满足的要求给予最高优先级确实是有意义的。但是我们（和客户）是否真的总是事先知道什么是必须满足的要求。我有几次这样的经验，即一开始就被高度重视的要求后来变得不那么重要了，即使不是毫无用处的。因此，我认为不应盲目地将注意力集中在必须满足的要求上。

正式的答案是您误解了敏捷，敏捷并不决定要求，利益相关者却做到了。敏捷的核心不是将您的要求刻板刻画，而是随着您的前进与客户密切联系而受益，并从渐进的见解中受益。

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

问题在于，听取客户意见并迅速响应客户的需求往往很快就会导致他们根本没有对产品进行任何思考或进行任何设计。过去由视野和专业知识提供的主动过程可能并且经常会恶化为由客户的意愿提供的被动，完全被动的过程。这将导致仅仅制造“将完成工作”的必需品。

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

但这并不会使敏捷变坏。这有点像共产主义。一个很好的主意，因为人们只是人，在做人的事情，所以很难奏效。而且方法/意识形态/宗教使他们陷入只要做运动和/或遵循规则就可以做得很好的想法。

[编辑]

雪人：

具有讽刺意味的是，敏捷已经从自动化行业（即丰田）中脱颖而出。

还记得自动化的黄金法则吗？“首先组织，然后自动化”。如果您将损坏的流程自动化，则可能发生的最好情况是您加速所有出错的步骤。丰田的人不是白痴。

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

开发人员可能会认为：“嘿，这可能行得通。我们将更多地参与业务问题，我们可以提供信息来填补此积压订单。这可能是使销售和客户服务了解我们所做的事情，为什么必要的机会，当我们透明地烧毁我们所同意的东西时，我们会把它们从头发中脱下来。” 不想让您推迟在办公桌前弹出的某些家伙不再“停止您正在做的事情，这需要立即完成”。

另一方面，销售，客户服务或所有者可能会将其视为对部门的黑匣子进行控制的一种方法，该部门可能正在做必要的事情。他们看不到那里发生了什么，但是他们很确定问题的核心埋在那里的某个地方。因此，他们介绍了Scrum，安装了他们选择的产品负责人，突然之间，他们有了全部控制权，所有的字符串都掌握在手中。现在呢？

真正的问题通常是商店一开始的组织不佳，而且情况没有改变。人们被赋予了他们无法处理的责任，或者也许可以接受，但是老板先生一直在干涉和破坏他们所做的事情，或者（根据我的经验，这常常是至关重要的），根本的责任没有被认可或分配给任何人。

有时随着时间的流逝，非正式组织会出现在正式机构之间。然后，这可以部分弥补形式结构的缺乏。不管有没有名片来证明，有些人最终只会做自己擅长的事情。敏捷/ Scrum的过时介绍可能会立即破坏这一点。因为现在人们期望遵守规则。他们觉得自己过去做的事不被赞赏，而是得到黄色的小论文，上面写着小故事，信息将是：“无论您做什么，都没有人关心”。不用说，这不会对那些人产生特别的激励作用。他们充其量只能开始等待订单，不再采取任何主动行动。

因此情况变得更糟，结论就是敏捷糟透了。

敏捷不会吸引人，它对维护项目非常有用，如果仔细应用，它甚至可能对新开发有利，但如果错误的人不理解它或出于错误的原因而采用它，那么它可能最具破坏性。

似乎甚至没有在敏捷中获得吸引人的品质的地方。

您正在比较苹果和桔子。在传统瀑布中，如果您的需求说您需要必备品，那么您将获得菲亚特。如果要求说它必须是一流的，那么您就可以得到一辆法拉利。

在敏捷中也是如此。如果您的要求不满足于需求，您将获得菲亚特。如果您有出色的故事，您将获得一辆法拉利。敏捷真正要执行的所有事情是，您必须先做到必备。两年不制造超酷的扰流板，然后错过发动机的截止日期。

长话短说：满足您的要求。如果您计划跑车，那么您会得到一辆跑车。敏捷根本不会改变。如果您的敏捷过程提出了菲亚特的要求，请不要责怪敏捷，只怪责那些只要求菲亚特的家伙。

但是，我知道所有敏捷过程都强烈赞成必须满足的要求。这些总是获得最高优先级。

如他们所愿-再次查看您的Kano模型：如果不能满足必须的要求，则客户将不会接受该产品。然后，您的喜好者就没关系了。

似乎甚至没有在敏捷中获得吸引人的品质的地方。

没有东西会离事实很远。

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

• 经常交付您可以获取反馈的有效产品。
• 将功能分为小部分，可以在短时间内完成。
• 优先执行那些部分。

没有什么能阻止您赋予“愉悦”功能高优先级的。这完全取决于负责确定优先级的人员。

如今，许多这样的人确实不愿意冒险，因此可能不会对“欢欣鼓舞”给予高度重视。但是在非敏捷项目中，情况仍然如此。

敏捷没有说要先做什么，只是应该增量地编写代码，并尽可能使代码保持可释放状态，而不是计划在几个月后直到下一个可释放状态都无法使用。

我既在敏捷流程中工作，又在BDUF（前期大设计）流程中工作，虽然您肯定可以从这两个流程中获得创新，有吸引力的功能，但是在BDUF中，毫无疑问，您必须预先计划它们。这意味着创新通常必须在设计过程中由具有影响力的人提出或至少由其赞助。

这是因为距下一个发行版还有六个月（或其他时间），并且项目经理会对该发行版产生什么压力，因为如果他们的功能无法使用，则距离下一个发行版还有六个月的时间。 。因此，在拥挤的日程安排中有一系列拥挤的功能，如果低档次的文件在凉爽的东西上工作了两到三天，他们只是认为客户会喜欢，而不是清单，他们冒着整个时间表的风险，将要付出地狱的代价。

在敏捷过程中，我们努力将软件保持在可发布状态，并且项目经理的压力减轻了，因为如果功能失误，他们只需两周就可以得到它。因此，如果开发人员从会议中回来后提出了一个很不错的主意，并花了几天时间做某事，那么他们就不会危及六个月的书面计划。

基本上，您收获的是自己的种子。如果您鼓励创新并给予团队足够的自主权来实现，那么您会得到的。如果您不断要求捷径以便在最后期限之前完成，则无论您采用哪种方法，都将获得匹配的软件。

优秀的软件来自两方面：

• 满足客户需求

• 成为专业人士

开发软件时要遵循各种原则。与客户需求无关的DRY，可读，SOLID等。顾客要一辆跑车。如果客户了解使跑车表现出色所需的条件，他们将不需要您。由您自己决定还有什么重要的。

我们的工作之一是维持客户从未体验过的标准，除非事情出了错。

如果您做得正确，那么只有在客户真正想要的时候，敏捷才趋向于稳定。并非如此，他们认为自己必须解决。

瀑布之所以不同，是因为一旦解决了对高端跑车需求的误解，它就会持续存在。如果事实证明他们真正需要的是一辆子弹自行车，那么敏捷可以应对新信息并做出调整。

到目前为止，许多商店仍在使用瀑布。这些商店之所以成功，是因为它们的要求每年变化不到2％。

您的工作不仅仅是给客户他们想要的。这也是照顾您知道您根本不会获得任何荣誉的事情。除非您让事情变得严重错误，否则客户永远都不会提出这些事情。最好选择这些东西，否则您会浪费很多时间。

任何白痴都可以用无限的预算建造一座桥梁。专业人士搭建一座桥梁，几乎永远不会倒下。

因此，我认为不应盲目地将注意力集中在必须满足的要求上。

当然可以。除非估计您的时间。因为那些必须要的条件不是唯一的考虑因素。

好，

在敏捷中，程序员可以创建软件，但最终是由产品所有者来创建产品。（通过使用软件开发人员。）

关于“有吸引力的品质”，这取决于产品所有者。

如果产品所有者要求“性感设计”，则可以提出这一要求。开发人员不必担心这些选择。

另外，软件与实际的物理产品差异很大，我认为许多Kano模型都不适用。例如，为什么我要使用Facebook？唯一的原因：因为我的朋友愿意。如何将其放在下一个冲刺中........而且，软件最吸引人的品质之一是，它实际上完成了应有的功能。（这就是敏捷帮助很大的地方：P）

我的经验与上述评论一致- 敏捷中没有固有的东西可以阻止优秀软件的开发-但是，敏捷（经常）在实践中有很多方面导致软件仅“足够好” 。”

• 敏捷强调尽快使某些东西起作用。但是，这意味着简化假设和偷工减料，尤其是在用户看不见的基础架构中。如果纠正简化假设的成本很低，那么这天生就没有错。但是，这种“技术债务”通常在产品投入生产之前并没有消除；
• 敏捷地提出，在冲刺结束时，您应该始终拥有尽可能接近可交付的东西，以便利益相关者和项目经理可以确定“他们所拥有的”足够推进生产。同样，如果没有您已经清除了所有的“技术债务”（或与您拥有的债务和债务状况并存。）但是，以我的经验，太多的技术债务投入生产，并得到经理的承诺：“我们“一旦消除运输压力，便将其清理干净”，迅速变成“生产中，我们必须非常小心现在所发生的变化”，最终变成“您从来没有告诉过我，我们经历过这种危险！下次我们必须做得更好！” 本·弗兰金（Ben Frankin）关于“质量低劣的苦味在忘记了低价的甜蜜之后仍然存在很长时间”的教训似乎从未被吸取；
• 然而，即使有信任的管理人员和训练有素的开发人员，有一个简单的太少了正确的分析，设计，和常见的问题设计审查时之前在实施预计将启动并完成了冲刺的开始。无法深思熟虑地考虑替代方案UI的隐喻和设计很大-在项目开始后，对其进行重大修改通常过于昂贵。初级团队未能仔细研究其竞争对手的产品，或者没有优先考虑基础设施技术（例如I18N，通知框架，日志记录，安全性和API版本控制策略）的定义和实施，这意味着他们最终将拥有更高的错误，与他们刚花了前2到5个冲刺进行必要的培训，分析，设计和原型制作相比，它们的生产率较低，并且会产生更多的技术债务。简而言之，敏捷团队必须抵制骇客的许可证。
• 我有一个二级经理（由100多个开发人员组成），他劝阻他的开发人员不要花时间写下他们的计划设计，即使是最基本的级别。他的推理-“我希望人们互相交谈”-具有讽刺意味，因为他们分别在5个不同的时区和3个国家/地区。不用说，一旦发现每个人都认为每个人都认为另一个人负责实现某些功能（或重新实施，因为供应商和消费者的设计没有啮合。）

归根结底，这取决于项目经理和利益相关者是否要交付高质量的产品。如果他们致力于这样做，那么敏捷将启用它。OTOH，因为Agile只是将进度计划决策权交给了利益相关者和项目经理，所以Agile使得开发团队很难在没有这种支持的情况下交付出色的项目。简而言之：对产品质量的责任几乎完全由项目经理负责。

TL; DR

实际上，敏捷开发可帮助您提高软件质量，保持客户满意度并交付高价值的产品。

敏捷开发是由一些聪明的人引入的，旨在解决许多软件项目在传统流程中面临的问题。

敏捷宣言（1）定义的敏捷开发的关键价值是：

• 个人与流程和工具之间的互动
• 工作软件胜于完整的文档
• 合同谈判中的客户合作
• 响应计划变更

因此，敏捷开发不会阻止您创建高质量的软件。敏捷开发支持您交付高质量的软件。

但是我们（和客户）是否真的总是事先知道什么是必须满足的要求。

这就是重点。通过专注于个人，客户，工作软件和需求变更的敏捷开发可以帮助您在交付最终产品之前弄清楚客户的需求。

这就是为什么像Scrum这样的敏捷框架具有较短的迭代周期（其结果是有效的产品）的原因。您已经可以根据客户的期望在早期阶段验证您的工作，并根据需求调整目标/要求。敏捷开发可帮助您确保实现产品的必备质量。

过去-今天仍然如此-用传统方法开发的许多软件项目都失败了，没有成功，或者由于未达到必不可少的质量而引起了客户不满。

此外，敏捷开发还可以帮助您达到有吸引力的质量。每次迭代后对产品进行反映都会启发新需求，而这些需求在项目开始时就未被客户关注（有吸引力的质量）。这样可以使客户满意。

我还要提及卡诺模型的反向质量 -导致不满意的属性。

在每个项目中都有一些要求，这些要求在项目开始时似乎是个好主意。一段时间后，它们变成相反的方向并引起失望。

在传统的软件开发过程中，经过长时间的项目运行后，您会在最终产品中意识到这种要求。为避免客户失望并改变他们，跟进项目为时已晚。

敏捷开发可帮助您及早发现不起作用或不满意的需求，并在项目期间对其进行更改。

正如我所说，敏捷开发可帮助您提高软件质量，保持客户满意度并交付高价值的产品。

我参加这个聚会很晚，但是我想在这个问题上分享另一个角度：

但是，如何将它们应用于创建令人愉悦的高质量软件产品，而不仅仅是满足勉强满足最低要求的最低要求？

有一个时间方面的敏捷软件开发从结果迭代方法，并考虑客户的反馈，这是敏捷方法的两个重要元素。示例：在迭代t中被标识为有吸引力的质量的特征可能在下一次迭代t + 1中成为必不可少的质量。

应用敏捷方法可以动态更改要素的质量类别。如果将迭代t的计划特征与某些后续迭代t + n的完成特征进行比较，您将确切地体验到您提到的内容：

我有几次这样的经验，即一开始就被高度重视的要求后来变得不那么重要了，即使不是毫无用处的。

考虑到这个时间方面，敏捷方法可以产生令人愉悦的高质量软件产品， 同时专注于最低限度是有可能的。该迭代方法与配对的客户反馈随时间变化的游戏规则。

结论

如何用敏捷方法开发出色的软件？

应用迭代方法并听取客户反馈。抛弃这些元素之一，您将获得不太成功的敏捷软件开发形式。

   > How to develop excellent software with agile methods?

• 在生产客户特定的单独软件时：
  • 找到一个成本无关紧要的客户，因为“令人愉快的”功能会花费额外的钱，并且客户必须决定是否要为此付费。
• 生产软件产品时：
  • “令人愉快的”功能可以吸引新客户，如果产品的销售量超过1000次，则实现“令人愉快的”功能的成本并不重要。
• 在“足够好（最便宜）最好”的环境中，您将无法获得实现“令人愉快”功能的钱

在Scrum团队中，产品负责人负责选择要实现的功能。因此，定义一个“足够好”或“优秀”的软件取决于他（并且取决于他的预算）

您提出了一些好点。但是我不认为这些问题仅限于敏捷过程/方法论。

对于基本功能与非基本功能有不同的看法。以您的示例为例，购买汽车的人可能会将吸引注意力作为一项基本功能，因此将菲亚特视为不满足此必备条件。
更现实地讲，软件产品可能需要具有某些功能才能满足其实际最终用户的需求……但是它可能还需要具有某些其他功能才能被出售。因为授权购买的人通常不是最终用户。
因此，对于最终用户来说，“非必需”的功能对于销售产品可能是必不可少的……因此对于创建产品的公司也必不可少。

所有这些都归结为以下事实：拥有一个好的产品开发团队来适当地设置需求和优先级至关重要。但这不仅适用于敏捷商店。

让产品所有者/利益相关者有权做出决定也很重要。如果您的产品负责人的决定不断被其他人否决，那么我将第一个同意这是一个问题，但是，敏捷不是问题。

您的产品所有者还需要其他东西...我听到的一个描述是“ CRACK”（协作，代表，授权，承诺和知识渊博）。缺少这些领域的产品所有者可能会给项目带来麻烦。但是我首先在瀑布环境中听到这个首字母缩写词，因此显然，不良客户/产品所有者的痛苦并不仅限于敏捷商店。

敏捷可以（帮助）做的是将其中一些问题浮出水面。

例如，XP的文献是IIRC的相当明确的内容，即“客户”知识渊博，团队可以访问并有权做出决策。术语“产品所有者”意味着一定程度的知识，承诺和权威。

如果您发现自己所处的大多数交付功能都由喜好者而非必备功能组成，那么在每台交付正常工作或接近工作的软件时，提出该问题会更容易（并且更容易确定原因）。相较于分开交付数月或数年的情况，则需要2-3周。

如果您要进行小规模的迭代-并经常检查积压的工作（包括重新划分优先级），那么团队将有机会学习以前的错误。“现在感觉这真的很重要，但是还记得我们确定我们不需要最终使用的动态导航吗？” 正如其他人指出的那样，如果一切都已预先计划，那么进行这些讨论的可能性就小得多。

相比之下，前期设计方法假定（默认情况下）对产品和功能的了解是静态的。那不是我的经验：拥有切实可行的东西几乎总是会改变商人对问题的理解。因此，强调快速反馈。（开发人员的理解也会发生变化，但这不会影响优先级。）

推迟一些计划还可以使您响应业务需求的变化。“您知道您正在建立的网站吗？我们真的需要它成为一个能够断开操作的移动应用程序。” 这不是特别要问的问题……但是，您是否不希望您的流程能够应对业务格局的变化（至少在理论上如此）？

敏捷并没有说“不要建立不必要的功能”。它确实说“允许企业决定（而不是）构建哪些功能”。
……（同等重要）“让技术人员告诉您要构建一个功能要花费多长时间”。

1. Must-be qualities通常很难确定。人们把它们置于潜意识中。敏捷的迭代和客户的参与有助于找到大多数必需品。那就是敏捷的力量，而忽略它是愚蠢的。
2. One-dimensional qualities这意味着必须履行的承诺得到瀑布行的支持，直到它们没有改变。在这里，敏捷只会有所帮助，而没有那么强大。
3. Attractive qualities是不错的功能。它们可能会成为下一代的必需品。但是在当前这一代，他们甚至还没有达成共识-否则它们将是一维品质。那些假定客户代表参与的敏捷方法很好地支持了这些素质。因为我们可以在工作中轻轻改变范围。我们可以在一个地方讨价还价，而在另一个地方讨价还价。在瀑布中几乎是不可能的。没有组织上的重大延迟，我们只能免费添加功能。如果以前在预算中安排了一些额外的时间，则有可能。

因此，敏捷过程可以支持Kano模型，其中一些可以很好地支持它，并且绝对比最佳的瀑布项目好得多。

要在您的理解范围内做得更好，您应该与负责任的客户代表参与者建立敏捷的流程。