敏捷，敏捷，敏捷。 敏捷开发人员和测试人员有何不同？

敏捷一词已席卷软件界。 敏捷已经远远超过了它的炒作周期。 人们对敏捷有了越来越多的认识，但是仍然存在一些疑问，尤其是开发人员和测试人员。 那么，敏捷有何不同？如果您是开发人员或测试人员，这有什么关系？

快节奏的环境

通常，敏捷环境是快速发展的。 这并不意味着将没有呼吸空间。 不，不是这样。 在良好的敏捷环境中，输出速度更快。 在良好的敏捷环境中交付相同功能所需的时间更少。

更集中的结果

许多人关注的问题是他们试图一次做太多事情。 很多时候，多任务处理适得其反。 对于个人或项目来说都是如此。 因此，敏捷更加重视对真正重要的事情给予适当的关注。

关注客户而不是技术上的便利

在让客户容易还是我们容易之间做出选择，我们几乎选择了后者。 有时但并非总是如此，这是有道理的。 但是，在敏捷项目中，客户为王，如果有对客户来说更容易的事情，即使这样做意味着从技术上讲它并不容易，我们也会这样做。 当然存在技术上不可行的方面，但这是完全不同的一点。

工作软件超过全面的文档

您可能已经在《敏捷宣言》中看到了这一点。 这意味着，与其花大量时间记录我们将要做的事情（过多的计划和文件记录），我们将专注于开发实际的产品或软件。

以这种方式考虑，在三个月内拥有一个可以供实际用户使用的工作软件（甚至是一个非常简单的版本）比编写非常详细的需求规格，编写高级设计文档，低级设计文档，测试计划要好得多。文档，详细的测试用例可以说3个月。 可以运行的软件可以提供用户反馈，而过多的文档则不能提供反馈。

另一个常见的误解是敏捷=没有文档。 这远非事实。 敏捷建议的是，工作软件要胜过全面的文档。 因此，我们将记录任何真正需要的东西或将来有意义的东西，但是如果我们觉得将来没有用，我们就不会在记录上浪费时间。 它是如此简单。

用户故事而非详细规格

由于主要重点是软件的用户，因此将定义用户故事，而不是详细的需求规范。 这使每个人都非常简单，但是让开发人员和测试人员可以更详细地了解用户故事的含义。 因此，我们实际上不是在定义实际的屏幕和字段来定义软件，而是试图定义用户将要做什么。

估计变化的方式

通常，开发人员和测试人员非常熟悉小时数估算。 我们遵循流行的方法，如功能点估计，测试脚本点估计等。但是，在敏捷开发中，我们将做一些非常相关的事情。 通常在Scrum（敏捷方法之一）中，我们有一个基于故事点的估计的实践，其中我们将基于用户故事所需的工作量进行估计。 一种流行的估算方式是Scrum中的Poker Estimation。

6个月没有详细计划

同样，这里的重点是工作软件，而不是长时间尝试过度规划。 因为在软件开发生命周期中，由于业务需求经常变化，所以事情可以相当Swift地发生变化。

长期解决方案，而不是快速解决方案

在敏捷中，我们专注于问题的长期解决方案，而不是构建快速解决方案。 有时我们倾向于快速修复，但是我们也认为可行的长期选择。 我们知道短期修复会在以后产生更大的问题，因此我们将减轻这种风险。

专注于自动化

我们提高敏捷性的方法之一就是专注于自动化。 您可以从单元测试执行，代码构建，代码部署，代码分析，运行各种测试等方面基本上实现所有操作的自动化。自动化的巨大优势在于，我们可以节省大量多余的手动工作，这些工作可以用于改善产品或软件的质量。

Craft.io效率

在敏捷中，重点将更多地放在提高整个流程的效率上。 这意味着要尝试自动化所有值得自动化的东西。 这也意味着要仔细检查出什么问题，什么是正确的，等等，如果不起作用，则尝试进行更改。

更多合作

敏捷项目的本质是协作，无论是与客户还是团队成员之间的协作，都不应有开发人员与测试人员之争。 不应有项目经理。 团队战斗。 实际上应该是相反的。 每个人都应相互补充，以便他们能够协作并朝着一个共同的目标努力。

增量较小

传统开发方法的问题在于它试图一次做太多事情。 因此，当我们试图解决越来越大的问题时，我们正在采取重大步骤。 但是现在有了敏捷，我们会将更大的问题分解为更小的问题，并采取更小的步骤。 一次解决一个小问题比一次解决一个大问题要容易。 因此，我们以较小的增量（通常为2周的增量）开发和运输产品，但是该软件可以完全正常工作。

更少的自我，更高的生产力

对于团队而言，自我绝对是团队精神的杀手。 而且，由于敏捷专注于协作及其人员方面，我们将需要撇开自负，并着眼于团队解决当前的问题，从而提高自我和整个团队的生产力。

拥有权而非责备游戏

如果出现任何问题，整个团队将拥有所有权，而不是玩指责游戏。 这提高了团队士气，并强调了团队对问题和软件的所有权。

这是关于团队合作而不是孤岛

通常，在传统团队中，您倾向于看到人们在孤岛上工作。 在敏捷中，重点再次放在团队合作上，而不是孤岛上。 不在孤岛上工作的优点是团队成员在遇到麻烦时会互相支持并立即解决问题。

您是否认为我在这里没有提及任何要点？ 如果您是开发人员或测试人员，那么您认为敏捷还有什么不同？ 请发表您的评论。

参考： 敏捷，敏捷，敏捷。 敏捷开发人员和测试人员有何不同？ 来自我们的JCG合作伙伴 Rajaraman Raghuraman在“ 开发人员和测试人员-新敏捷世界”博客上发表的文章。

翻译自: https://www.javacodegeeks.com/2013/12/agile-agile-agile-what-is-so-different-about-agile-for-developers-and-testers.html