敏捷对QA部门有何益处？
　　传统方法中，直到产品快要发布了QA工程师才参与到项目之中。QA工作被理解为项目结尾的工作，这样明显会对产品质量产生很大的风险和不稳定。传统方法中，黑盒测试优先于用户界面，且每个测试用例和测试计划都不得不记录下来。敏捷框架的引进使工程师收益，因为它们变得更重要了。它们需要一开始主动参与，想出合适的方法确保产品质量。总而言之，敏捷中的QA应该：
　　--帮助业务分析师明确故事以及它们的接受标准，这样他们可以知道有没有满足顾客的要求。
　　--与开发团队整合，使用代码标准并通过重构改进代码库。
　　--在编码前给开发员提供高质量的测试用例和场景，遵循计划应对改变。
　　--确保用户界面上的黑盒测试和白盒测试以了解应用程序内部的工作。
　　--增加自动化测试以增加团队速度。
　　--将质量控制落实到每次迭代中去。
　　敏捷对管理有何益处？有没有敏捷经理？
　　敏捷经理
　　负责支持开发团队，去除障碍，并保持敏捷流程顺利进行。敏捷经理是开发流程的推动者，他/她的主要任务是大化团队的效率，而非控制他们如何工作，后者更多地出现在项目经理作为权威人物的传统项目管理中。敏捷经理确保项目上的都是合适的人，训练、引导、并激励每个人实现共同的目标。这项重要任务大大激励了他们实现他们的目标。

　　那么，敏捷是完美的吗？
　　当然不是。首先要注意，敏捷并不是完美，它是用有效透明的方式为你的组织和顾客带去价值。因此，使用敏捷框架时你需要有耐心。执行团队相信敏捷方法这一点很重要。如果这样，你项目成功的可能性大大增加了。
　　此外，敏捷还有一些缺点。因为它侧重于人，如果某些人离开了你们团队，你很有可能会失去很多团队的信息和凝聚力。另外，因为团队是自我管理的，需要所有成员都成熟，通常这很难。后，使用敏捷时有一些会带来更多不方便的常见错误。一个常见错误是：试着让你的组织适应敏捷。敏捷是一个为变得更加高效而提供方法的框架，因此关键在于明确敏捷提供的哪些方法适合你个人和团队的需求。另一个错误是：相信敏捷意味着一切随时可以完成。敏捷是关于灵活度的，但是一个功能的开发一旦开始，不可能在它完成前改变它。
　　它是适用于软件环境吗？
　　不，它可以用于不同的环境，比如，想想看我们用敏捷方式写的这篇文章。我们首先明确了我们想要做的，并开始为期一周的编写循环。每次循环后，我们都需要来自专家和重要利益相关者的反馈。用这种方法，我们提高了我们的文章并继续编写。完成十次循环后，我们的利益相关者告诉我们它很不错。很明显，我们并不是敏捷，因为在它终完成前我们还没将产品发布出去。确实，敏捷并不仅仅只适用软件项目，但是它更适用于小的预算项目，因为每次循环都修复你的产品或许会产生预料外的花费。此外，敏捷在为了各种理由而需要经常变化的环境中很高效。
　　结论
　　过去敏捷并不是公司开发过程的一个方面。它是一个通过团队合作，透明和不断的进步经常帮助为终端客户提供高质量的开发原理。这些益处表明了敏捷的转变，这并不是一个轻松的任务。一旦遇到第一个问题，并不完全相信敏捷使用的团队和公司将会放弃他们对敏捷的使用。
　　一个良好的敏捷团队了解敏捷的益处并相信它的使用，选择适合他们的敏捷框架提供的管理和技术方法。这样的话，敏捷的使用基本成功了。

版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/201579142241.html
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。