关于敏捷开发需要了解的重要事情

2001年，由17名软件开发人员组成的小组讨论了一种新的软件开发理念。他们认为，20世纪的发展实践在21世纪已不再合适。客户对缺乏沟通感到沮丧。开发人员对经常需要对已完成的项目进行修订感到沮丧。他们在一起的时代的产物是作为他们的“敏捷软件开发宣言”的一部分而发表的12条原则的清单。

这种发展方式的重点不是正在产生什么，而是如何产生。敏捷实践可以应用于任何类型的项目。他们专注于给予编程团队灵活性和高效的生产力。

敏捷价值

敏捷软件开发基于几个旨在增加开发人员之间以及开发人员与客户之间的沟通的价值观。它们还旨在使客户能够更好地了解项目进展情况，以便在此过程中能够更早地进行修订。

清晰沟通

编程团队成员需要定期沟通，以便快速回答问题并直接交付指令。这使得沟通更有效率，让每个人都在同一个页面上。它还简化了开发过程。

长期计划的短期目标

敏捷软件开发鼓励将项目分解成较小的部分。合作伙伴和团队被分配了一小部分的程序设计，有很短的截止时间。短期目标允许更大的灵活性。随着变化的出现，目标可以更容易地修改。

积极协作客户和开发人员

令客户感到沮丧的一个原因是无法看到项目的进展情况。同时，当一个已完成的项目被送回进行多个修订时，开发人员会感到沮丧。通过将客户作为合作伙伴引入，可以在构建阶段将修订作为目标设定过程的一部分。

短反馈环

在敏捷世界中，测试成为过程的一个常规部分。该项目的小部分定期进行测试和展示。这让每个人都能更好地理解项目的时间表。此外，这种频繁的测试允许开发人员在bug深入到代码中之前捕获它们。

敏捷实践

敏捷开发并不要求特定的实践，但是由于敏捷模型的价值，许多标准实践已经到位。一个常见的例子是配对编程。在这里，两个开发人员一起编写项目的一部分代码。一个程序员编写代码，另一个程序员在编写代码时对代码进行评审。

另一个常见的敏捷实践是每天的站立会议。在这里，每个团队将给项目经理一份状态报告。然后，为今天设定新的目标。

最后的练习是在冲刺中进行。许多敏捷模型不是设定一个长期的目标，而是鼓励在短时间内完成工作。许多办公室使用为期两周的sprint模型，开发人员试图在短时间内处理同样多的问题或处理多个用户故事。

敏捷开发中的问题

与任何开发模型一样，敏捷开发可能不是最适合每个工作场所或每个项目的。对于敏捷模型有一些常见的批评。

统一设计的损失

据说骆驼是委员会设计的马。当许多开发团队正在处理项目的各个部分时，您可能会失去原始愿景的整体统一性。

失去焦点

当开发人员只看到碎片时，他们可能会忽略整体。这可能导致项目的小部分占用太多时间。

最适合面向对象的编程。

由于OOP自然地将项目分解成块，所以OOP语言将是敏捷开发人员的自然选择。使用非面向对象语言的项目可能不太合适。

较大设置的难度

有些人担心，敏捷风格的开发在大型环境中不起作用，在大型环境中，编程团队可能会在洗牌中迷失方向，或者在非常大的项目上，许多小的编程块可能更难跟踪。