敏捷测试的时候测试流程_敏捷什么时候适合您？

敏捷测试的时候测试流程

人们经常问我：“什么时候敏捷适合一个项目？” 我之前说过，如果团队想要敏捷，那就太好了。 如果团队不这样做，请不要使用敏捷。

这个答案是不够的。 除了团队之外，我们还需要管理层不要为敏捷创造不良的环境。 您可能没有一个好的开始环境。 但是环境不好？ 那是恐怖的表演。

我最近有一次教练对话。 我的客户有一个典型的问题。 他看到完成工作的多种方式。 他从敏捷和精益中汲取灵感，并将它们融合在一起，以创建一种适用于他们公司的项目方法。 它不是很敏捷。 而且，这就是症结所在。

他的管理层想要“变得敏捷”。 他们不知道这意味着什么，他们认为敏捷是一种以更少的成本更快地获得更多好东西的方法。 通过敏捷方法，他们有可能将其作为副产品来实现。 老实说，任何阻止人们等待阶段完成的方法都会有所帮助。 那不一定是敏捷的。

管理团队确实了解其中一种众所周知的方法。 他们希望每个人都接受该培训。 我的客户认为这行不通。 他有许多担忧：

• 管理层希望控制人们在项目级别的工作方式。 管理层希望定义迭代持续时间，站立问题是什么，谁在哪个团队中以及团队将做什么。 （在那里就足够了，但还有更多。它们分散在全球各地。采用现成的解决方案是没有意义的。）
• 管理层希望使用团队评估来进行个人补偿。 具体来说，他们想使用个人速度来补偿人们。 （这是愚蠢的，危险的和错误的。）
• 与客户交谈过的每个经理都认为他或她不需要更改。 只有技术人员才需要改变。 （他们再误会了。）

如果您在敏捷组织中工作，您将了解这些假设的问题。

团队管理自己的工作：他们的录取是通过产品负责人进行的。 他们决定如何工作，并在团队中进行工作。 希望团队专注于吞吐量，而不是谁在做什么。

请记住， 速度不是加速度。 当经理滥用速度并用它来衡量团队成员（甚至不是整个团队！）时，他们会创建日程安排游戏和有害的团队环境。 充其量，经理滥用速度会导致人们走捷径并招致技术债务。 更糟的是，它破坏了团队合作。

管理者可以创造一个人们可以成功的环境。 尤其是在敏捷和精干的环境中，管理人员不必“激励”人们或推动人们做得更好。 人们会做得很好，因为他们经常获得反馈并且愿意。 当经理们试图操纵一个环境，以更少的工作交付更多的东西（他们认为敏捷是什么）时，我不确定是否有人能够成功。

我问客户，经理们是否理解敏捷对于他们来说意味着什么。 他确信经理们不知道。

我建议在这种环境下尝试敏捷将给敏捷组织带来坏名声。 我建议了这些替代方案：

• 询问可能有助于管理人员阐明其目标的三个问题。 请参阅定义敏捷成功。
• 与管理层进行模拟，以使他们感受到敏捷的感觉。
• 解释敏捷系统以及管理思想如何无济于事。
• 在较短的时间范围内（我想过一个月，也许两个月）请求一个合理的环境，以向管理层表明他们的想法并不是唯一可行的想法。 我提出了客户可以建议其管理层采取的一些措施。

不要在有毒的环境中开始敏捷。 这不值得。 敏捷对您来说是错误的。 请记住， 敏捷不是灵丹妙药 ， 敏捷并不适合所有人 。

请记住，敏捷是一种文化变革，而不仅仅是项目管理框架。 与其考虑敏捷，不如考虑使用所有敏捷思想来显示稳定的进步并决定如何影响您的经理。

与其考虑敏捷，不如考虑使用敏捷的所有思想（例如，团队合作来交付少量价值）来显示稳定的进步并决定如何影响您的经理。 当管理层希望保持指挥与控制时，不要要求团队保持协作。

翻译自: https://www.javacodegeeks.com/2016/05/when-is-agile-wrong-for-you.html

敏捷测试的时候测试流程