一个测试者眼中的敏捷和Scrum方法

Posted 2021-04-25 51Testing软件测试网

摘要:敏捷软件开发模式已经跨过创新阶段，快速跨进早期采用阶段。你注意到每个所见之处都有提到敏捷和Scrum技术吗？这篇短文将描述关键的敏捷/Scrum 概念，在一个敏捷项目里使用Scrum管理的不同阶段的情况和作为一个质量保证工程师或测试专业人员应当考虑的首要的三件事。如果你的机构公司正在关注敏捷/Scrum，或者你想要跟上行业最新趋势，请接着读。

　　敏捷软件开发方法是一种将增加的功能通过较小的循环逐步添加到项目中，工作是由自我组织的团队以高效合作的方式拥抱和适应变化来保证客户需求被真正满足的方式来完成软件开发项目的方法。敏捷软件开发方式不是新生事物，事实上在20世纪90年代他就被引进作为一种减少成本，最小化风险和确保最终产品是客户真正需求的方式来使用了。敏捷方法背后的思想是取代创建功能巨大的版本（常常延后与市场需求），一个机构可以通过将每个版本分裂成更小更短的1到6周的循环来适应快速变化的要求和条件。每个循环被称作一个迭代，或者冲刺，而这几乎就像项目本身的一个迷你小型软件项目，因为他包含所有发布增加的新功能的必要的项目功能任务。在理论上，每个冲刺结尾，产品应当被备好做一次总版集成。敏捷方法强调实时沟通，相比较书面文档和生硬的流程沟通，更偏好面对面的沟通。除此之外，敏捷流程方法引进了一个广泛使用的技术之一---将产品需求以讲用户故事的形式表达出来。每个用户故事都有各种各样的字段如"主角"，"目标"或者他们需要执行的一个任务，一个解释。

　　大多数敏捷团队版扩所有发布软件的必要人员。最少程度上，这要包括程序员和他们为之开发程序的组或团队，通常被称作他们的

　　"顾客"（顾客是定义产品的人，他们可能是产品经理，业务分析师或者实际的顾客）。一个典型的敏捷团队还将会包括一名Scrum大师，测试工程师，交互设计师，技术作者和经理。

　　什么是Scrum？Scrum是一个真正的能够便捷敏捷开发软件的项目管理方法，他使得自我组织的敏捷团队诞生。

　　一名Scrum大师就像一个传统的项目经理，他/她俯瞰团队沟通，需求，时间安排日程和项目进度的中心。但是它也是跟传统项目经理很不一样的，因为他/她的主要责任在让团队之间的沟通更简单便利，同时提供指导和教练，去除阻碍团队能力发挥的障碍来达成目标。不像传统的项目经理，Scrum大师不主管团队，因为一个敏捷团队是建立在这样一种哲学思想上---团队成员与其他团队成员之间互有承诺，而不是对管理权威。

　　使用Scrum敏捷开发项目的各阶段

　　敏捷可以定制为就大小，迭代时间，经验等要求而适应每个公司的方法，但是典型的敏捷项目会有这些阶段和里程碑。

　　1、启动会议。尽管这看起来对任何项目都是例行事务，对敏捷开发项目，这是一个让项目运行的关键要素。这个启动会议的目标是让团队里的每个成员一起来评审产品备份单（即产品拥有者在用户故事形式里起草的产品需要的所有需求的清单），和用户个人习惯偏好（或者叫每类产品用户的描述）。在我看来，这种方式更友好也更清楚地介绍产品需求，因为你真的能在一开始就能对谁在使用这个产品，他们试图达成什么以及为什么这样做有更多的预见能力。一个启动会议通常持续至少半天时间，每个成员一起浏览一个"故事编写工作商店"--在这里选择故事然后将之解构成克编程的任务，与时间估算放在一起写进一个白板里以完成。如果你从来没见过产品积压代办事项，可以在QAZone这里看几个例子。有时候真正的顾客会被邀请来参加启动会议，和敏捷团队一起评审和搞清楚产品的代办事项。

　　2、冲刺/迭代规划的下一个步骤，是团队共同决定冲刺目标和冲刺的代办事项（为那个特定的冲刺按照优先顺序排列要做的的工作清单）。在团队成员共同创建冲刺代办事项时，需要将故事分成子故事或较小的任务。在这种集体团队活动中，你真的可以看到项目管理的差别（至少如果你使用比较生硬和正式的瀑布模型如背景模型时会看到），因为这里没有管理权威分配任务给团队成员。在一个敏捷团队里，所有成员联合将困难级别连写到特定的任务上，他们可以移除故事和/或任务，也可添加额外的故事和/或任务，而任务基于自愿基础在团队里分配。不像传统的项目经理功能，这个会议里的Scrum大师角色是基于会议中团队反馈和共识维护产品代办事项，确保每个成员在自愿基础上拿到的任务没有超负荷，同时简化成员对团队效力的流程。

　　3、既然冲刺规划工作在冲刺代办事项形式下准备好了---这个过程是动态的，非固定的，事实上很可能他会基于新故事，新任务和/或在迭代中发现的阻碍来调整和改变---Scrum会议会在同时同地每天开设一次。如果你从未参加过Scrum会议，这些会议属性是变化十分快速的，从不超过30分钟，理想的为10到15分钟。目的是来回巡视，如此每个团队成员可以回答3个问题：自从上次会议以来我完成了什么（开发了什么，测试过什么，编写过什么故事等），接下来我会要去做什么，以及阻碍我完成我的目标的问题是什么，如果有的话。这些会议很重要，他们确保团队围绕着他们的冲刺目标活动，或者适应/旋转和变化优先级和任务如果遇到新的故事，阻碍或者新场景的需要的话。

　　4、在冲刺或迭代结尾，通常一个最终验收会议会召开，这主要是展示团队已经完成的东西，向顾客或者更大的观众发送一个产品展示。

　　5、在一次迭代末，还有一个冲刺回顾会议，类似于其他传统项目的事后讨论会议，这样团队成员聚在一起评估哪些做得好，哪些工作需要在下次迭代中改善。

......

(本文收录于《51测试天地》电子杂志第37期）

猛戳阅读原文，直接在线阅读杂志全部内容