敏捷方法已经风靡软件开发世界并迅速巩固其作为“黄金标准”的地位。敏捷方法论都是基于敏捷宣言中概述的四个核心原则开始的。这些方法植根于适应性规划，早期交付和持续改进，所有这些都着眼于能够快速，轻松地响应变化。
敏捷 是一种项目管理方式，而不是一种工具。
敏捷宣言核心原则
敏捷宣言有四个核心原则，对于测试人员来说很重要：
1、个人和流程与工具之间的互动
2、通过综合文档工作软件
3、响应遵循计划的变更
4、通过合同谈判与客户合作
什么是用户故事
用户故事 不是另外一种写需求的方式，故事是用来讲的，不是用来写的，用户故事主要是为了建立共识机制。
用户故事同样也不是需求，是关于问题解决方案的讨论，公司的问题、客户的问题、用户的问题。
目的是对要开发的功能，达成共识。
什么是建立共识
产品经理写了一份文档，邮件同时发送给了 设计、研发、测试。大家看到文档以后，每个人的理解各不相同。有人理解的是方的，有人理解的是圆的，有人理解的三角形的。大家都觉得自己的理解是正确的，然后回邮件说：我理解了。
当开会大家坐在一起讨论时，才发现 oh my god，完全不是那么回事。
然后大家经过一系列的沟通交流，不断的去纠偏，不断的产生新的问题，不断的去解决。
最后大家达成了统一的意见，建立了相同的认知共识。
这张图是目前达成共识的一个敏捷流程。
MVP & 最小可行方案
MVP 是指可以产生预期成果的 最小可行产品。
MVP一般都是新的产品为了快速验证市场的可行性，而发布的最小可行产品。 但大部分公司都是在已有的产品上进行功能迭代，我们把这种功能迭代叫做最小可行方案。
最小可行方案是可以产生预期成果的最小可发布方案。
最小可行方案，也是我们在拆分版本迭代任务时，需要考虑的点。以下两种图可以解释最小不可行方案与最小可行方案 ：
最小不可行方案
最小可行方案
用户故事地图 & OKR
地图 的作用有两个：寻找路径，了解全貌。
l寻找路径
我们一般想要去一个地方，现在都会使用电子地图，输入起点和终点，APP会自动帮你规划出路径。以前使用纸质地图的时候，也是在地图上要起点和终点，然后自己谋划一下路径。
这个是我们比较常用的功能了。
l了解全貌
上学那会儿，地理课老师用世界地图也好，中国地图也好，来给我们讲解几大洲几大洋，地质情况等等。
我们在知道了地球是圆的基础上，还知道了中国就是雄鸡，意大利是靴子。
这就是了解全貌。
OKR （Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，由英特尔公司发明。OKR是努力的方向和目标，代表你到底要去哪里，而不是你要去的地方具体在哪里。
三只猎狗追一只土拨鼠，土拨鼠钻进了树洞。树洞只有一个出口。突然从树洞里钻出一只兔子，飞快地爬上一颗大树。兔子在树枝上没站稳，掉下来砸晕了正在仰头看的三只猎狗。最后，兔子逃脱了。
这个故事的关于目标有什么问题？
有人说：兔子不会爬树。
有人说：一只兔子不可能同时砸晕三只猎狗。
都是好问题，但是：土拨鼠那里去了？土拨鼠才是目标。
下两张图是使用 OKR ，结合用户故事在敏捷方法的运用。
敏捷方法论
每个组织都是独一无二的，面临着不同的内部因素（即组织规模和利益相关者）和外部因素（即客户和法规）。为了帮助满足不同组织的不同需求，可以在其中一种敏捷方法中使用各种敏捷方法。哪种组合适合团队取决于项目的内部和外部因素，需求和目标。
让我们来看看一些最流行的敏捷方法：
lScrum
l看板
l行为驱动开发（BDD）
1）Scrum
Scrum采用高度迭代的方法，专注于在每个sprint之前定义关键特性和目标。它旨在降低风险，同时快速提供价值。
Scrum从一个需求或用户故事开始，概述了功能应该如何执行和测试。然后，该团队通过一系列冲刺循环，以快速提供小规模的价值爆发。为了帮助团队以这种灵活的方式工作并避免改变优先级，Scrum要求从一开始就回答问题。
它和瀑布有什么不同？瀑布包括在发布产品之前的几个测试和错误修复周期，而Scrum更具协作性和迭代性。其中一个最大的区别是瀑布早期需要大量文档。这个文档使得在过程继续进行时更改功能变得更加困难，这在某些环境（例如消费级软件）中可能是负面的，而在其他环境中则是积极的（例如团队试图发射火箭的那些）没有人想要经常危险移动的要求）。
也就是说，您可能会认为Scrum就像许多“迷你瀑布”一样，因为每个冲刺开始时需求都很明确，不应该在其中移动。不同之处在于，下一个冲刺的详细要求不是提前几个月设定的。
Scrum为来自瀑布环境的团队提供了最简单的转换之一，因为它基于时间的冲刺和发布仍然可以提前计划。也就是说，它确实需要更快的迭代和更强的协作。由于其快速迭代，Scrum最适合那些客户和利益相关者希望通过在展示会议上定期查看工作产品而积极参与的团队。此协作允许团队对即将到来的陈列柜进行更改。在采用Scrum方法时应该参与的主要团队成员包括：
l产品拥有者
lScrum Master
l开发商
l自动化工程师
l测试者
l利益相关者
最佳做法除了强大的沟通，协作和适应性之外，遵循Scrum方法的测试人员的其他最佳实践还包括根据销售代表或客户的通信（通常以用户故事的形式）确定验收标准（注意：此直接连接应有助于减少误传）。
使用验收标准开发代码并确保团队批准该代码。
2）看板
看板是一种非常简单的基于敏捷的方法，植根于制造业（它由丰田公司开发，旨在帮助提高工厂的生产率）。在它的核心，看板可以被认为是一个大的，优先的待办事项列表。与Scrum一样，看板中的需求由其当前阶段（待办，开发，测试，完成）跟踪。
与Scrum不同，看板不是基于时间的。相反，它完全基于优先权。
当开发人员准备好完成下一个任务时，他/她将其从待办事项列表中拉出来。由于计划会议较少，这种方法意味着团队需要非常接近。在这种类型的环境中，如果开发人员的工作速度比测试人员快得多，那么就会出现瓶颈。在这些情况下，团队中的任何人都应该跳进并帮助不同的领域。当然，满足这种需求需要很大的灵活性和适应性。
相比之下，瀑布是基于时间的，在计划中有很多开销。在某些情况下，在瀑布环境中进行繁重的规划是很好的，
例如在建造昂贵的东西时，但并不总是必要的。使用看板，版本仍然有计划，但团队通常不会在某些日期向任何人提供功能，除非相关项目位于待办事项的顶部。
看板为正确的团队提供简单的过渡。为了顺利过渡到看板，业务分析师，开发人员，测试人员和利益相关者应该坐在一起并定期沟通。转换到看板时，重要的是要记住这种方法提供了将代码投入生产的最快方法，但代码可能会有一些技术债务。这是因为开发时并不总是知道接下来的内容并不一定能够生成最可重用的代码。
看板最适合不为公众制作功能和/或承诺发布某些日期的小型团队或团队。此外，它是主要专注于维护工作的任何产品或团队的首选方法选择，因为错误并不总是直截了当，往往需要研究解决，这使得时间管理具有挑战性。根据Scrum或Waterfall方法，不能最小化问题规划量的团队可能会更好。
应参与看板环境的主要团队成员包括：
l产品拥有者
l专案经理
l开发商
l自动化工程师
l测试者
3）行为驱动开发（BDD）
BDD使用Gherkin Given / When / Then语法从功能规范开始。然后，该规范指导跨功能的开发人员，测试人员和产品所有者。正如他们所做的那样，他们使用自动化测试功能来确定完整性，改进代码直到通过测试，就像TDD方法一样，除了团队级别。为了确保测试通过（并且通常需要多次尝试），开发人员应该只重构代码，而不是添加任何新功能。
当团队习惯于传统的方式时，更改为BDD方法可能具有挑战性。它需要开发人员要在代码中编写规范。这是团队内部的一种新型协调方式，但非常积极的是团队合作为一个单元，包括业务用户。
BDD方法非常适合从事以功能为中心的软件和/或将用户体验放在首位的团队的团队。
应参与BDD环境的主要团队成员包括：
l产品负责人/业务分析师
l专案经理
l开发商
l自动化工程师/测试员
网友评论