敏捷可以使测试人员的能力更弱吗

#1 楼

对于初学者来说，敏捷不是演员。

人们不会“与敏捷一起工作”，“使用敏捷”或类似的东西。此外，敏捷不采取行动，它“不做/做事情”。

敏捷是敏捷宣言和其他文档中描述的一种心态。简短的描述，看来您以前的工作方式比现在更接近于敏捷宣言。

原理：和设计来自于自组织团队。


之前：“选择工具的自主权”，“做出独立的决定”


持续关注技术卓越性和良好的设计可增强敏捷性。 >将信息传达给开发团队并在开发团队内部进行的最有效的方法是面对面的交谈。

现在看来，这些适合您的情况的实践开始走下坡路了。

但是，正如您所说的，富有的人们扮演着不同的角色。您现在可能与他们没有相同的关系。在团队的组织结构图部分，您可能会被视为团队的一部分，但在实践中，由于这种弱势的关系，您可能不是。团队思考如何提高效率，然后相应地调整和调整其行为。




在团队中，任何人的角色都是发现他/她的技能如何最好地为团队服务，即使该角色并未探索一个人拥有的所有技能。为此，您需要观察，交谈和试验。不仅要调整您的工作，还要向其他人建议不同的工作方式，以使贡献者朝着相同的方向工作。发现它是您的角色，也是您的队友（遵循上面的自组织原则）。

足球中可以找到类似的东西：哈维·埃尔南德斯（Xavi Hernandez）曾经说过，他的打法永远不会使他成为年度最佳球员，但它将创造许多年度玩家。 Xavi了解了他所处的环境，并与队友一起进行了调整和调整。在实践中，您和您的团队成员可以使用PO知识来发现对您的组织重要的内容，然后实施旨在最大化该价值的开发实践。不专注于此的实践显然会受到高层管理部门的反对-这意味着，如果有人为此目的而担任老板，则与业务价值相抵触，团队将能够进行反击。 br />
很可能“所有流程和决策都是由PM和高级开发人员制定的”，这种做法并没有喊出最好的业务价值（遵循自组织原则）。也许不吧。取决于您的上下文。同样，您和您的团队是负责发现情况的人，并提出/实施必要的更改以进行改进。利用您的社交能力来实施您认为适合业务的更改（无论任何人的“权力”，当前，过去或将来）。

#2 楼

它可以双向运行，取决于情况。
在某些公司中，敏捷是一堆流行词，用来掩盖瀑布和命令与控制实际上是在发生什么的事实。在授权模型中为包括质量检查人员在内的所有人员提供更多的发言权和投入。当然，您现在还有其他任务，成为传福音的人/老师，传播好话。

#3 楼

可悲的现实是，正如Michael和Joao指出的那样，敏捷或DevOps等流行语掩盖了组织或团队的毒性。

他们错过了敏捷的主要原理：（http://agilemanifesto.org/principles.html）为他们提供环境
和他们所需要的支持，并信任他们能够完成工作。


如果正确地实施这些方法，那么对于他们来说这是一个巨大的机会。整个团队。但是有时您最终会遇到有毒的团队策略。

我也有过这样的经验，我被聘为测试自动化工程师，实际上，团队希望我做测试自动化作为辅助工作。这种心态的原因是：


不知道QA的价值
仅出于流程考虑而拥有QA
思考敏捷就是将PBI传递给完成并从不重新访问它们。
如果缺少一项功能或不起作用，则不了解对客户群的影响
产品通常是内部的
将客户视为理所当然，对市场份额充满信心没有明显的竞争对手
心态是质量保证人员是缺乏技术技能的人（不授予访问DB的权限，不授予创建回购协议的权限，不授予CI / CD的配置权限等）。
职业自我，并试图将质量责任从团队转移到质量保证，从而打怪游戏。

仅举几例....

做这里是：


进行概念证明工作
询问数据库和CI / CD的本地设置，并在您的空闲时间创建概念证明。
开始学习新工具，并逐一实施它们。
不在定期的冲刺会议中展示演示，而是在重要的团队会议中展示演示，在这些会议中您可以看到其他利益相关者。您工作并在内部新闻稿和文章中发布的文档。
帮助其他对您的提案感兴趣的团队，帮助他们建立项目并将该项目用作衡量您的解决方案如何提供更高投资回报率的指标。 />将所有发现和观察结果记录下来，但不要一get而就。如果您从客户那里得到相同的反馈，只需将它们用作参考。

我知道旅途会很艰难，但这是您学习更多的人际技巧的机会，而不仅仅是技术。尽力而为

#4 楼

是的，当“敏捷”被用作流行语而不是实际使用时，它可以使任何人失去能力。听起来好像您现在处在这种情况。我无法告诉您如何使您的情况与下面的内容保持一致，但是至少知道目标是什么可以帮助您至少将组织的一部分朝这个方向发展。

敏捷团队

在敏捷中，或者至少在XP中，只有两个团队：客户团队（也称为产品所有者，业务人员或类似人员）和开发团队。每个人对开发的特定区域都负有不同的责任和控制权，并且彼此之间不跨步。某人可能在两个团队中都扮演角色，但是她必须小心翼翼地将这些角色分开，一次只戴一顶“帽子”。显而易见的原因是，客户必须至少进行最少的测试，才能查看他是否得到了与他所要求的故事相似的东西。如果客户感到需要，客户团队配备专业的全职测试人员并非不合理，但这将表明对开发团队的某种程度的不信任，应该对此进行研究。由开发人员进行的测试要比单独进行的测试便宜得多，因为如果开发人员知道需要什么，则可以将代码设计为更容易地进行测试。

开发团队将进行广泛的测试，无论是否正式。在最坏的情况下，这是由单个开发人员在编写程序时只是“手工”运行事情来完成的，直到他决定完成故事的工作为止。但是通常会进行各种类型的自动化测试（单元，功能，UI，系统），讨论测试策略，可能进行持续集成等等，所有这些旨在使开发人员和客户都对他们所拥有的东西充满信心

在这个世界上，专职的专业测试人员既是开发人员，又是开发团队的正式成员。他们是否不编写受测代码也没关系：他们仍在与团队的其他成员一起完成故事，为系统的设计做出贡献（特别是在使系统更容易和更便宜方面）测试），经常在甚至编写测试框架上工作，等等。据我所知，这就是您想要的位置。技术方面的“项目经理”通常是敏捷方面的坏消息，因为他们的传统工作是由开发中的实际工人和敏捷中的客户团队完成的。¹客户和开发人员制定案例，开发人员对其进行估算，然后客户选择构建它们的顺序，然后开发人员跟踪故事进度和团队速度。特别地，唯一应该为故事的估计做出贡献的人是实际上正在（或愿意）对故事进行工作（是编写，测试或部署软件）的人。 br />
PM经常有意识地意识到，在这种情况下，他们并不需要太多。这通常会导致这样一种情况，即他们（试图，有意或无意）试图通过为未完成的工作设置估算值来颠覆流程。要阻止这种情况的发生，这是一个困难且往往非常政治的过程。但是，如果您不能避免这种情况，那就是要远离敏捷，而不是朝着敏捷发展。 >
让非开发项目经理进入客户团队，帮助处理他们的工作细节（与开发人员谈判故事，弄清楚执行这些项目的顺序，以及估算和跟踪总体长期发展
开发中的项目经理将他们所做的工作分散到开发团队的所有成员中，这样开发团队中不再有“项目经理”，而项目经理的工作则分散在所有开发人员中。

摘要

您想要的东西以及行之有效的（如果执行得当）可能会成为开发团队的正式成员，为开发做出贡献在您擅长的特定领域。我无法为您提供具体建议，因为这完全取决于您公司的特定情况，并且其他人也愿意接受“测试人员”也是开发人员。但是，我希望这些想法至少可以为您提供一个框架，以尝试朝着这个方向发展。

#5 楼

信息通过PM / BA流向TA。


声音对我来说就像小瀑布。诸如Scrum和XP之类的敏捷框架具有以下价值：勇气和尊重。

勇于回顾性地解决这个问题。移交容易出错，我认为最好早点进行测试。在开始处理积压项目之前，一种常见的模式是进行三个Amigo会话。让团队尝试一下。我认为，如果您从一开始就参与工作，将会使您感到更有力量。团队。


至于尊重，我认为团队应该尊重您的意见。了解它不是要把工作推到角色上，而是要把角色拉到工作上。告诉人们做什么意味着对自治的尊重。您听起来不太自组织。