摘要:敏捷软件开发模式已经跨过创新阶段，快速跨进早期采用阶段。你注意到每个所见之处都有提到敏捷和Scrum技术吗？这篇短文将描述关键的敏捷/Scrum 概念，在一个敏捷项目里使用Scrum管理的不同阶段的情况和作为一个质量保证工程师或测试专业人员应当考虑的首要的三件事。如果你的机构公司正在关注敏捷/Scrum，或者你想要跟上行业最新趋势，请接着读。
敏捷软件开发方法是一种将增加的功能通过较小的循环逐步添加到项目中，工作是由自我组织的团队以高效合作的方式拥抱和适应变化来保证客户需求被真正满足的方式来完成软件开发项目的方法。敏捷软件开发方式不是新生事物，事实上在20世纪90年代他就被引进作为一种减少成本，最小化风险和确保最终产品是客户真正需求的方式来使用了。敏捷方法背后的思想是取代创建功能巨大的版本（常常延后与市场需求），一个机构可以通过将每个版本分裂成更小更短的1到6周的循环来适应快速变化的要求和条件。每个循环被称作一个迭代，或者冲刺，而这几乎就像项目本身的一个迷你小型软件项目，因为他包含所有发布增加的新功能的必要的项目功能任务。在理论上，每个冲刺结尾，产品应当被备好做一次总版集成。敏捷方法强调实时沟通，相比较书面文档和生硬的流程沟通，更偏好面对面的沟通。除此之外，敏捷流程方法引进了一个广泛使用的技术之一---将产品需求以讲用户故事的形式表达出来。每个用户故事都有各种各样的字段如"主角"，"目标"或者他们需要执行的一个任务，一个解释。
大多数敏捷团队版扩所有发布软件的必要人员。最少程度上，这要包括程序员和他们为之开发程序的组或团队，通常被称作他们的
"顾客"（顾客是定义产品的人，他们可能是产品经理，业务分析师或者实际的顾客）。一个典型的敏捷团队还将会包括一名Scrum大师，测试工程师，交互设计师，技术作者和经理。
什么是Scrum？Scrum是一个真正的能够便捷敏捷开发软件的项目管理方法，他使得自我组织的敏捷团队诞生。
一名Scrum大师就像一个传统的项目经理，他/她俯瞰团队沟通，需求，时间安排日程和项目进度的中心。但是它也是跟传统项目经理很不一样的，因为他/她的主要责任在让团队之间的沟通更简单便利，同时提供指导和教练，去除阻碍团队能力发挥的障碍来达成目标。不像传统的项目经理，Scrum大师不主管团队，因为一个敏捷团队是建立在这样一种哲学思想上---团队成员与其他团队成员之间互有承诺，而不是对管理权威。
使用Scrum敏捷开发项目的各阶段
敏捷可以定制为就大小，迭代时间，经验等要求而适应每个公司的方法，但是典型的敏捷项目会有这些阶段和里程碑。
1、启动会议。尽管这看起来对任何项目都是例行事务，对敏捷开发项目，这是一个让项目运行的关键要素。这个启动会议的目标是让团队里的每个成员一起来评审产品备份单（即产品拥有者在用户故事形式里起草的产品需要的所有需求的清单），和用户个人习惯偏好（或者叫每类产品用户的描述）。在我看来，这种方式更友好也更清楚地介绍产品需求，因为你真的能在一开始就能对谁在使用这个产品，他们试图达成什么以及为什么这样做有更多的预见能力。一个启动会议通常持续至少半天时间，每个成员一起浏览一个"故事编写工作商店"--在这里选择故事然后将之解构成克编程的任务，与时间估算放在一起写进一个白板里以完成。如果你从来没见过产品积压代办事项，可以在QAZone这里看几个例子。有时候真正的顾客会被邀请来参加启动会议，和敏捷团队一起评审和搞清楚产品的代办事项。
2、冲刺/迭代规划的下一个步骤，是团队共同决定冲刺目标和冲刺的代办事项（为那个特定的冲刺按照优先顺序排列要做的的工作清单）。在团队成员共同创建冲刺代办事项时，需要将故事分成子故事或较小的任务。在这种集体团队活动中，你真的可以看到项目管理的差别（至少如果你使用比较生硬和正式的瀑布模型如背景模型时会看到），因为这里没有管理权威分配任务给团队成员。在一个敏捷团队里，所有成员联合将困难级别连写到特定的任务上，他们可以移除故事和/或任务，也可添加额外的故事和/或任务，而任务基于自愿基础在团队里分配。不像传统的项目经理功能，这个会议里的Scrum大师角色是基于会议中团队反馈和共识维护产品代办事项，确保每个成员在自愿基础上拿到的任务没有超负荷，同时简化成员对团队效力的流程。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/69/n-2432769.html
一名质量保证专业人士应当想到的首要的3 件事，当一个机构采用敏捷/Scrum开发技术时，敏捷和Scrum真的在改变测试在项目里被认为和看待的方式。测试不是最后的一个阶段；它真的是在集成整个迭代循环中，而且与编程任务肩并肩一同进行。在我的经验里，当在一个敏捷项目里比较测试角色时，或者当使用那个更死板、正式的方法时，我发现在敏捷方法里是这样：
1、质量保证和开发团队间更好的沟通和更好的合作。"给我需求"，"我会返回给你缺陷和报告"的日子不复返了，质量保证工程师在项目的一开头就介入---与开发团队同步，而且他们对产品需求和顾客需要的相同信息同时有权限进入。这种从开头进入的参与，结合开发和质量保证工程师现在是相同的敏捷团队的部分，他们每天一起工作，他们对彼此对冲刺整体的成功要执行的任务有完全的可见性的事实，意味着他们之间的更好更频繁的沟通。除此之外，因为整个团队满足了每日（开发，测试，产品管理等等），有更好合作的机会和更多执行某个特定任务的观点。而且传统的你会在QA和开发之间发现的"竞争对抗"现象也消除李因为现在是一个单一的敏捷团队工作来达成一个共同的目标。
2、一种新的开发和测试人事之间的"同行对同行"的关系 你应当准备好更多地"说出来"。敏捷方法都是有关组建自我组织的团队，QA工程师或测试员的话语跟开发人员同等重要。思考一下这种方法。在每日的Scrum会议中，每个团队成员问有关他们的成果（测试，开发，写作产品文档等等），将来计划和障碍，对所有成员一视同仁。在敏捷团队里，如"我们将怎样去测试它"的问题跟"我们将怎样去建造它"同等重要。另外，因为测试人员倾向于特别擅长挖掘需求和辨识不断变换的场景，（尤其是当他们完全可以看到产品需求和用户需要时），他们提供了有价值的设计观点和架构决策，从项目一开始。而这些贡献换来了更多的尊重和他们的开发同僚的欣赏。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/69/n-2432769.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
