每日必读DZone News—什么是敏捷真实的含义？
每日坚持必读，就是紧随时代发展的步伐，技术之路虽艰辛，但终会有所收获。每天进步一小步，程序的世界已然不同。Java Zone成就每个程序员的不同。英文原文地址：https://dzone.com/articles/what-does-agile-really-mean?edition=347123&utm_source=Daily%20Digest&utm_medium=email&utm_campaign=Daily%20Digest%202017-12-26
最近的一项调查发现，将自己定义为敏捷的团队与使用瀑布的团队的发布周期之间没有显著差异。
什么是“敏捷”？
如果你已经涉足软件世界，那么你可能已经听说过“敏捷”这个词了。你可能听说过这个词与持续的合作，持续的交付，更快的释放，不断的适应，或者任何其他的“敏捷”特征有关。很明显，参与软件开发生命周期所有阶段的团队都开始采用这种“敏捷”方法，因为它的普及率在不断提高。
今年早些时候，软件开发，质量保证和测试领域的5000多名专业人员对SmartBear 2017年度软件测试状况做出了回应，调查结果中最令人感兴趣的领域之一就是“敏捷”。通过这次调查，我们要求团队将他们的开发风格归类为敏捷，DevOps，瀑布，依赖于项目或其他，我们发现的一些结果是预期的，而另外一些令人惊讶。
我们的第一个发现是，DevOps团队每天都会发布多次;比那些把自己定义为除DevOps之外的东西要快得多。然而，这确实是值得注意的事情，对于将自己定义为敏捷的团队与使用瀑布方法将团队定义为团队的团队，发布周期之间没有显着差异。事实上，遵循非敏捷模型的团队（不包括DevOps团队）比基于敏捷的团队每天更可能每天发布或多次发布。这让我们震惊！是不是被敏捷释放更频繁的关键部分？这让我们退一步思考...在软件开发世界中，敏捷这个词的真正含义是什么？
简史课程
“敏捷”一词来自“敏捷宣言”，十七名领导人在雪鸟滑雪胜地聚集在一起。在这次聚会上，领导们开始思考一个软件项目的新方法。这种方法的重点在于反馈驱动，在那里开车的人是做这项工作的人。 “宣言”的作者来自许多软件开发领域，从极限编程（XP）到动态系统开发方法（DSDM），以及Scrum的共同创造者，然而，Brian Marick总结了这些想法：已经想出了如何建立系统，请让他们这样做。“
组成“宣言”的十二条原则描述了敏捷包括变化的需求，频繁的运输软件以及面对面交谈是传递信息的最有效途径的想法。有了这个敏捷方法，需要以更有效和更高效的方式进行测试。敏捷测试流程需要完全融入到敏捷软件开发方法论中，真正实现敏捷宣言中的12条原则。这怎么可能？一些解决方案可能包括使测试套件多样化，在可能的情况下整合自动化测试，持续测试，并能够适应不断变化的条件和要求。
快进到今天
许多团队已经开始采用策略来加速他们的测试流程。首先，团队已经开始使用测试自动化金字塔作为参考来自动化更多的测试，自动化更多的单元测试以及更少的API和UI测试，同时仍然认识到完全摆脱探索性测试几乎是不可能的。另外，团队已经开始使用持续集成工具，所以他们不必不断地重建车轮，并且可以将他们的工作流程与他们已经使用的工具集成在一起。团队试图更快地测试的另一种方式是通过不断的合作，比如举行三友会议，让开发者，测试者和产品所有者聚在一起，不断地向对方提供哪些方法可行，哪些方法不起作用。
但是我的团队真的敏捷吗？
所以，这引出了我们今天提出的问题：您是否需要满足所有12个原则才能真正被视为敏捷？是说Jira的行话，在Sprint中工作，并且在项目的所有参与方之间保持不断的沟通，这意味着您正在实践一种敏捷方法？与詹金斯整合，拥有小团队，快速学习，不断调整意味着你是敏捷的？如果你正在做11项原则，但是你仍然按季度发布，该怎么办？你是敏捷吗？
我认为所有团队都要考虑他们对敏捷的真正定义是非常重要的。随着敏捷不断普及，每个团队都应该知道他们想要练习的敏捷。也许使用敏捷销售工具，结合持续集成工具和使用所有敏捷最佳实践的团队确实认为，即使他们不能更快地发布，他们也是敏捷的 - 如果是这样的话，没关系。但是，如果团队认为明确需要成为敏捷，那么要真正成为敏捷的唯一方法就是满足敏捷宣言的所有12个标准，团队需要考虑未来的最佳实践。
正如我上面提到的，从我们的研究中得出的一个发现是，团队不像他们认为的那样敏捷。这没关系。我挑战所有认为自己是敏捷的团队，不管你是否参加了这个调查，反思和思考敏捷的重要原则。也许你以为你把所有这些都包括进去了，但是还有改进的空间。也许你认为你是一个敏捷团队，但实践更多的瀑布方法，这意味着你可以找到更好的工具来支持你在这些努力。无论如何，重要的是退一步，看看你的团队是如何运作的，并问问自己......我们今天工作的方式是最有效率和最有效率的。
