IBM 软件开发中心的敏捷测试实践分享51611049.doc

IBM 软件开发中心的敏捷测试实践分享 从游戏开始…… 有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是“老板”，另一个是“员工”，在 2 分钟内，“员工”需要在“老板”的完全指挥下，即“向前一步，向后一步，停，向左一步，向右一步”，完成 60 步移动的任务。“员工”需要执行“老板”的每一个指令，不允许做出相违背的动作。“老板”则不参与行动，只发出指令指挥“员工”的活动。我们体验这个游戏时，当场 60% 的参与者成功完成了任务，大致估计出我们的工作效率是 50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是“员工”还是“老板”都表示非常不满。 接着，大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务，在这次游戏里，所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现所有参与者不但毫无折扣的按时完成了任务，因而工作效率也达到 100%*100%=100%，而且所有人对于这种新的工作方式更是产生了极大的兴趣。 以上两个游戏方式的对比就折射出传统开发（前者）与敏捷开发、测试活动方式的对比，其中优劣不言而喻。 而敏捷开发、敏捷测试又是怎样一个概念呢？他们是否能够帮助我们的团队突破束缚，在日益激烈的竞争环境里表现得更为出色呢 ? 请参考我的这个系列文章——“敏捷测试的最佳实践”。 敏捷的价值 首先我们解释一下什么是敏捷，在字典中我们得到解释，敏捷，即反应迅速、可以快速变化。如今敏捷开发已成为众所周知的时髦 IT 词汇，在这个领域里敏捷又被诠释为迭代的，快速应对需求变化，轻量级，并且简洁。 图 1. 面对客户业务复杂度问题提出敏捷解决方案 IBM 重视敏捷开发，敏捷的软件开发策略之也被广泛推广开来。中国软件开发中心是 IBM 软件部部署敏捷开发方法的重点实验室之一。我们也是 IBM 中国软件开发中心最早使用敏捷方法的开发、测试的团队之一。这篇文章主旨为帮助那些愿意采用敏捷，和正在采用敏捷开发、测试的团队正确了解敏捷的实质。 笔者做敏捷项目已经近两年时间，对于敏捷的理解，认为最为关键的是需要注意两个方面，它们是“高度迭代”和“持续不断的客户反馈”。 高度迭代：迭代就是指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周期活动的叠加中不断得到更新和加强。甚至指在一个迭代周期内产品活动也具显著的周期性。同时，团队间、团队内部成员的高度协作及时帮助解决了各成员的依赖性问题，因此，也促进了各个成员工作的顺利开展，保障了产品活动稳定的持续性、周期性。以测试为例，传统开发模式下，测试人员可以因进入测试阶段的条件不完全满足而继续的等待。而在高度迭代的敏捷项目里，不同的是，我们希望测试人员能够尽可能的做能够做的工作，尽可能的早工作。“等待”在敏捷开发、敏捷测试范畴里已是一种错误概念了。 持续不断的客户反馈：指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润。 敏捷开发的商业价值 敏捷开发自 2001 年《敏捷宣言》（“AGILE MANIFESTO”） HYPERLINK /developerworks/cn/rational/r-cn-agiletesting1/ \l resources1#resources1 1 的创生，经过多年的打磨和退火已经成为今天非常流行和有过许多成功案例的开发模式。正如前人所说，传统的东西就是用来打破的，传统的瀑布式开发模式必然逐渐退出历史舞台，敏捷开发、敏捷测试是在新环境里产生出来的打破传统的新开发模式。而敏捷也将会在将来，甚至现在转化成更适合现代化软件开发、测试团队的方法和实践。在本文的第一部分，我们以两个游戏类比了敏捷和传统开发的差异，这里为了进一步帮助大家对敏捷的价值有更清晰的理解，我们借鉴前人的研究结果： 图 2. 敏捷与传统开发的比较 首先敏捷开发过程比传统开发要为项目和产品带来更低的风险（RISK）。为什么呢？传统开发缺乏持续的客户反馈 , 产品一旦从需求阶段退出，整个开发团队近似封闭工作，团队虽努力去实现曾经认定的目标，但因月有阴晴圆缺，市场需求也瞬息万变（例如提出需求的客户已经退休）。这使得产品在数月后，数年后发布时已经失去了占领甚至进入市场的最佳契机。 而如果你还在考虑使用传统开发模式用现在乃至将来一、两年的时间来开发一个结构复杂，精益求精而又功能庞大的产品，那么你得好好做好失败的准备了。而正是因为出于对这种风险的考虑，越来越多的人认识到敏捷开发要比传统开发能