是什么使敏捷软件开发如此吸引人？

如今，敏捷软件开发已成为一个非常有趣的流行词。

作为开发人员，我了解迭代开发的实用价值，但是（通常），并不是开发人员选择采用敏捷方法进行软件开发的选择。这是自上而下的管理选择！无论是水晶，敏捷方法，dsdm，rup，xp，scrum，fdd，tdd，您都可以命名。这不是开发人员的选择。

对于所有在那里的经理来说，当大多数经理甚至没有接触过一段代码时（根据我的经验），选择进行敏捷开发的最大原因是什么！

需求变化，交货速度更快

敏捷之所以吸引人，是因为它提供了更快（或根本）适应不断变化的需求并更快地将这些变化交付给客户的可能性。

这就是为什么许多公司在使用Agile / Scrum时会失败的原因：经理们不明白，依靠强大的力量（设置更快的发布日期和经常更改需求）来承担依靠开发人员进行估算的责任。为了敏捷地工作，经理必须愿意缩减范围。

他们想要两者的力量。

跟随趋势

有时候人们做事情，不是因为他们从事的事情的优点（敏捷），而仅仅是因为它很流行，而其他人也在尝试这样做。

“什么？Macrojam在做敏捷？我们为什么不？我们不慢，我们敏捷，该死！”

有些人并没有很好地说明敏捷实际上意味着什么。这仅仅是证明其存在的一种手段。尖刺，同伴压力等

编码本身并不是说服经理选择敏捷作为一种方法的主要原因。您可以对不断变化的需求和优先级做出更快反应的事实很吸引人。最终，“经理”需要向最终用户/客户/他的经理提供解决方案。

如果可以在项目开始时取消似乎在启动项目时似乎很关键的功能，并用新的，更相关的需求代替，那就是主要优势。

同样重要的是，大多数（例如像在Scrum中一样）每个中间交付都应该准备好投入生产。同时，最紧急的功能首先被开发出来。因此，万一该项目因某些公司决策而被取消，管理层可以确保您最终得到了可行并可以投入生产的产品。

希望这可以帮助。

提高知名度上有什么是怎么回事，并提高生产效率

1. 经理通常会对可见性敏捷带来的兴趣，特别是对于Scrum。这是针对管理人员的研讨会中最常用的卖点之一。

2. 由于易于演示（由于可见性），因此通常还可以使用更高的生产率来吸引它们。一些敏捷的福音传教士向他们保证，他们现有的员工将提供出色的生产力。“什么？我已经像柠檬一样压着它们，你告诉我我还能得到更多 ”？

许多经理人使用敏捷来压抑他们的员工，而我已经看到他们在一个大公司中使用烧毁图表作为较懒散的狩猎机器。

结果？许多团队在distress。他们认为敏捷可以解决所有问题，但事实恰恰相反。问题出在其他地方。

我正在积极反对这一点。这就是为什么有时perverted管理层提出比敏捷方法更高的可能性的原因，我建议不要在公司内部提及。

这个问题的答案可以写一本书。

我认为主要原因之一是敏捷开发专注于可交付成果。它始终专注于提供当前和现在最紧迫的任务。

另一个原因是，敏捷过程遵循的基于故事的计划和估计实践可以更好地估计可以交付的内容和时间。

我参与的项目就是一个很好的例子，说明了基于故事的计划是多么有效。几个月（在我们采用敏捷开发之前），项目负责人认为我们可以按时交付，距截止日期约18个月。所有开发人员都认为这可能是不现实的。在开始敏捷计划之后，项目负责人仍然对情况进行了乐观评估。但是仅仅经过几次冲刺，项目负责人就意识到团队根本没有能力在预期的时间内交付所有需求。距截止日期仍超过12个月。

因此，敏捷实践也使现实变得更加清晰。

最后，敏捷团队倾向于更多地采用能够创建更好代码质量的实践，例如测试驱动开发，频繁重构，持续集成，对等代码审查/对编程等。并非传统软件项目禁止这些实践，他们只是倾向于没有那么多关注。

大多数经理甚至一生都没有碰过一段代码！

我从事开发工作已有12年，现在担任过5年的经理。在这5年中，我逐渐从仍然编码的经理过渡到主要是纯粹的经理（我有时仍会修正错误或进行原型设计练习）。

选择进行敏捷开发的最大原因是什么

• 可视性或快速成功/快速失败-我们是一家产品开发商店，周期为6个月至24个月。具有可测试功能的迭代开发在反映项目状态方面做得更好。
• 变化-在我们的环境中，要求和时间往往是固定的。但是，业务过于定期地经历了迅速而剧烈的方向变化。迭代的，可见的开发使项目更容易改变方向。
• 通过基于故事的需求进行迭代开发，使与并非总是了解需求的技术方面或无法完全了解某些细节的业务驱动因素的业务的合作变得更加容易。在我们过去的努力中，高级规范或市场需求文档并不总是足够的。现在，随着项目的发展，可能会有一些并行的市场和客户研究。
• 流程更改还带有许多其他开发属性，例如TDD，自动测试与手动测试，更严格的测试周期（我们不再有QC小组，而只是一个QA小组），以及与质量相关的更高的赞赏和努力（我们使用很多工具和指标）。

我们可以通过其他方式实现这一目标，但是利用敏捷的方法论和想法极大地帮助了我们。

我们还将继续完善我们的流程。例如，前期设计工作与实施之前的设计之间的平衡。我们会定期审查所有决策，以确定是否可以推迟过去的设计决策。而且，当出现问题时，在确定错误之前，还需要进行更多的前期工作。通常，失败是需要深入分析的极端情况。弄清楚细节的努力通常与解决问题和重构的成本相同。团队不会因此类错误而受到处罚，并鼓励他们更具攻击性。

我已经看到许多公司“在做”敏捷。不幸的是，其中很少有人采用敏捷。我的意思是仅仅进行迭代开发和日常站立（团队中大多数人都坐在那里）并不能使团队敏捷。TDD，重构，持续集成，客户存在，SOLID实践使团队变得敏捷。没有这些，您就只能绕圈转。

敏捷的信息带来了很多吸引力。变化的适应能力最大。不幸的是，您的代码并不能仅仅因为您更改了项目管理方式而变得更具适应性。直到更多的公司意识到这一点，我们才会听到越来越多的失败敏捷项目。

我不知道流行词部分。我确实一直在一个不那么正式或确定的过程中一直这样做。在建立他们的网站时，我确实让客户望着我的肩膀。保存了大约50封电子邮件，客户了解了有关此过程的一些信息-这并不容易。

整个想法是，我们将花费很长的时间来记录用户希望软件执行的所有操作，然后花费更长的时间来构建我们认为他们只想在尝试该应用程序的两秒钟内发现的内容不是他们所期望的令人恶心。在构建另一个项目或应用程序之前，将任何项目或应用程序分解为合理的部分有多难？

我知道这是一个过分的简化，并没有解决实际的开发人员实践，但是即使将其出售给大多数非技术经理或客户也不难。还有什么其他方法更具吸引力？客户真的喜欢程序员在瀑布项目中进行开发时会花掉6到12个月的时间吗？您会雇用某人来盖房子吗？

管理层不会将这些事情强加给开发人员。开发人员和团队应采取主动并努力使他们做得更好。管理层的工作是为这些计划提供支持。

作为一名在我的职业生涯中写过很多代码的经理，我可能不是您想要找到答案的人。无论如何，我认为如今吸引敏捷的大部分与更快地响应客户需求以及缩短规格，编码，测试和客户之间的反馈循环有关。由于这些原因，我们正在朝着更敏捷的发展迈进。

我认为您不应该混淆敏捷过程和编码/开发实践。例如，Scrum不会告诉您如何开发代码-都是关于欢迎更改的过程。

归根结底，这是要赋予开发人员权力。这是要承认这样一个事实，即处于层级最底层的那些人是唯一真正了解需要完成的程度以及如何做到的人，因此，如果您已经聘请了他们以获取专业知识，为什么？还是不让他们完全控制自己，还是为什么要让他们远离实际决策呢？