附录A 有关敏捷思维、敏捷转型的常见问题和回答

以下收集了和朋友、客户、同事的探讨中常见的一些问题以及解答。

1.有关自动化测试和测试ROI的探讨

Q:读了你在IBM developerworks发表的《敏捷开发的最佳实践第4部分:自动化测试的ROI》一文,有一个问题想请教您:自动化ROI有标准吗?比如大于50%?如果没有标准,那么应该怎么衡量这个值呢?

A:亲爱的Sydney,据我看来,没有一个放之四海皆准的指标,在不同情况下,你可以灵活设定目标。例如,当自动化测试团队刚刚成立时,不建议设立严格的ROI要求。同时,如果团队为了自动化而自动化,甚至有重复发明同一个轮子的行为时,或许可以给一个严格的ROI指标来进行控制。我的ROI文章仅仅讲述当我们计划投入自动化测试时应该考虑的因素,而远非自动化测试的技术和自动化测试的覆盖率本身。所以,我给你的建议是逐步提高你所监管的自动化测试团队的ROI目标,以持续提高其效率和作用。

最后,我还想补充两个观点,第一,在考虑度量必要性时要从为什么度量出发,也就是你的目标;第二,在设计任何指标作为度量标准时,要考虑清楚是否会有伤害团队的可能,例如团队之间的互信,过往经验告诉我们,过多的度量会丧失团队的信任,一个没有信任力的团队所提供的数据以及度量结果往往是用来隐藏问题而不是帮助改进的。

Q:衡量自动化测试指标的问题,能否建立关于自动化ROI的指标,如何制定这个比例比较公平呢?

A:可能“公平”不是我们衡量的重点,ROI是体现投入产出是否合理的指标,虽然计算起来也较复杂,中间加入了人为设定的标量,但我们仍可以认为它是一个客观指标。要根据团队职能、技术条件、项目复杂度等因素差异调整你的指标,而不设定一个一顶百的标准,但是可以要求他们不断改进ROI,要求工作效果不断提高,团队生产率不断提高。

Q:开发自动化测试脚本和执行手动测试比较起来,自动化价值不大,请问如何衡量自动化测试的收益?哪些是自动化测试的重点?

A:这也是我最早选择研究自动化测试ROI的一个初衷,而回归测试应该是自动化测试的重点之一。

Q:单元测试(Unit test)是自动化测试的一部分吗?

A:单元测试多用于开发工作,不论是测试驱动开发(TDD)还是单元测试,它们都将更早地发现缺陷,不至于让其遗留到软件开发后期。而关于自动化测试指标,还是与单元测试分割开来看比较合适。

Q:如何用自动化方式发现更多的缺陷?

A:经验告诉我很多问题发生在集成部分,每个组件的独立测试似乎都很完备,但是一旦集成接口、数据、标准,各种问题就暴露出来了。在敏捷测试中,我会提倡在软件项目进展后期完成一个独立测试,以发现中间集成的问题。而自动化测试期望做好自动化BVT和问题解决后的回归,发现新问题的工作还需交给测试者自己。

Q:对于反复验证的问题是否需要自动化?

A:这点非常赞同,当我们发现某个问题多次被检查出来时,为了将测试者从程式化的重复性工作中解放出来去做真正有价值的工作,我们就应该用自动化的方法来解决。另外,当第三方代码出现问题时,我们通常期望第三方来修复,而这部分又需要通过软件才能验证,为避免沟通成本,我们也可以将自动化脚本发给第三方,让其修复后自行检查一遍。还有,当客户经常发现某一类问题而测试者没有发现时,这种测试就需要补充到原测试计划中,并最好实现自动化。

2.有关文档的探讨

Q:敏捷就是少文档、去文档吗?

A:敏捷开发强调working software重于light document,然后便产生了两种甚至更多的理解,这两种极端的理解是:

1)保持一定细节的文档,例如一个登录组件测试设计,只要写明测试一组有效的用户名和密码登录成功,并且测试另一组无效用户名和密码无法正常登录即可,而留给测试人员更多的空间在测试时选择“有效和无效”的数据。

2)压根就不需要测试设计和测试用例,仅仅用用户故事(user story)就可以,因为如果需求都只是简单的记录,为什么希望测试用例是详细的呢?

这两种理解我认为不能完全推翻,都有合理的地方,而且第一种相对来讲要合理些,但两种极端的理解都必然会带来一些弊端,一个不完整的、模棱两可的测试设计是不能被执行的,你期望你的测试人员怎么工作呢?另外,如果对场景(scenario)的要求过粗,不同的人将采用不同的数据和方式进行测试,得到的结果将大相径庭。而且,这样的测试将给产品带来漏测的质量风险。

我建议的做法是light documenting而不是light document,传统的测试文档,工件(artifacts)可能过于繁多,但我们宁可有一个繁多的文档也不愿意缺少足够的信息。但是我们也希望文档的更新工作可以足够light weight,我们的精力应该放在真正核心的测试设计和增加测试覆盖率等工作上,而把文档的更新、组织交给计算机系统。现在Rational Publishing Engine可以帮助实现light documenting。

总之,在敏捷开发过程中我们仍然需要文档、需要存档、需要通过文本的形式做些必要的沟通。我们应该让工具来解放documenting工作,把宝贵时间投入到必要的事情上去。

3.有关监控与管理的探讨

Q:传统团队通过审查监控的手段来确保项目的顺利运行,而敏捷团队更多的是依靠什么呢?

A:审查和监控的手段对于项目的顺利进行有帮助,这一点毋庸置疑,但是如果这是一个“垃圾产品”,为什么需要顺利进行呢,能不能不生产“垃圾”,让“垃圾”快速“失败”,让我们的有限生命投入到真正对社会有价值的项目中去呢?这就是敏捷的真谛。在敏捷项目里,我们很少需要“Manager”的监督和控制,因为员工可以做到三点:“自我组织、有自知之明、自律”。但我们关注产品本身传递的价值,产品负责人(Product Owner)需要“控制”项目的开发优先顺序,确定交付和开发的进度表,拍板决定何时能够发布产品。对于复杂的产品,如大型企业应用开发、大型用户群行业应用开发,则不仅仅是一个产品负责人和一个小团队能够完成的,我们既要保障团队的敏捷能力,又要降低企业在项目中的投资风险,因而我们需要项目有足够的企业透明度,这就是IBM Rational敏捷的服务宗旨。

Q:如何对一个项目需求并不清晰的新系统进行敏捷需求管理呢?

A:敏捷需求管理可以分成简单和复杂两类,如果团队很小,可以集中管理,建议使用普适的“白板note便签”方式;如果项目不得不牵扯到更多的人、更多的团队,则建议你选择Rational企业级应用,RTC/DOORS/RRC/CLM解决方案都可以帮助你驾驭敏捷需求管理。

Q:在顾客强调不能接受项目逾期、不能够接受项目超支的前提下,如何保持敏捷的鲜活呢?

A:没有人能够提前预估一个未知领域的产品是什么样、将来的市场在哪里、盈利点在哪里,也绝对不清楚我们需要花费多少时间才能完成最有价值、最重要的产品组件。我能够理解投资人从风险角度的考虑,如果客户在完全未知的因素里,还要勇敢地投入一笔资金,说实话,那样风险太大了。因此,无论如何,保守型的客户选择了固定项目周期,限制项目支出,甚至会干涉你的研发、管理、财务来确保这两项投入的精确或者最小化。但是,项目管理的基本元素——资源、范围、时间有着相互牵扯的金三角关系。即一旦任何一项发生变化都将带来其他两个维度的调整。因此,在顾客强调不能逾期或者项目超支的前提下,又需要保持足够的敏捷和项目需求变更的灵活,我们的客户需要接受一个事实,那就是项目的范围必须调整。而越是采用新技术、越是与第三方团队和个人产生依赖关系,项目范围的调整越可能超乎你的想象。

4.有关敏捷转型的探讨

Q:对于整个软件项目主线采用瀑布式开发,对于每个功能的开发采用敏捷开发是否可行?

A:对于你的问题,我想加一个问题,为什么要在局部采用敏捷开发呢?

Q:我比较习惯传统方式,在我的团队里应用敏捷开发,我希望从局部开始尝试,视其发展,再全面应用。

A:我也很喜欢传统模式,在我先按部就班做事情的时候,产品线固定,不期望创新和改变,或者没有新技术的引入,使用传统模式极具帮助,因为传统模式源于“制造业”。而敏捷开发的真谛是如何做到始终给客户传递最高价值的交付,从局部开始创新,得先保证我们的进度是可行的,我希望你不要考虑是否在用敏捷方法,而是考虑以下几个方面:如何让团队众志成城;如何将项目的透明度提高,即弱化Commond&Control的传统方式带来的诟病;有效地使用敏捷方法中的具体实践解决你当下最为关心的问题。

Q:为什么使用敏捷开发模式?优点是什么?

我在很多场合说了敏捷思想、敏捷开发的优点,多从企业、组织角度出发,之前在微博里也多次论及。对于你的问题,我希望从人成长的角度来回答。很多人曾认为,敏捷是高大上的,不是一般人能够做好的。但是,从我在公司带领的多个开发、测试的敏捷项目和敏捷团队来看,这些说法未免言过其实。敏捷的成功的确和人才这个要素分不开,但是,任何企业的成功难道不都取决于人才吗?人才素质和职业修养左右着企业成本,直接影响着企业的运转效率,甚至决定着企业的存亡。但是,我们看到的敏捷成功案例、本书中说到的故事,对其人才的要求也不过三点:自我管理、自律和自知之明。做好敏捷教练,除了流程,更多的工作是需要用教练的方式培养人才,敏捷转型为人才的培养提供了良好的平台,而人的成长确实需要经验的累积,所以,我鼓励所有国内的企业都学习并推广敏捷模式。

Q:国外的理论是高手才能玩的东西,一般的团队是不行的,你们这是什么节奏?

国内企业的软件富强之路还很长,敏捷思想在国内的发展还很短暂。我参加过这几年的年度敏捷中国大会,看到过数以千计的敏捷粉丝和嘉宾,这些让我感到学习敏捷并不是抄袭国外的理论或者说敏捷只是高手的玩意儿,更不是只有大企业在谈。但是,的确在一些场合听到朋友们谈起敏捷实施遇挫的遭遇,有的是因为摸着石头过河,没有专业的教练和系统的考虑,导致中途而返;有的是没有学习敏捷的道和术,为了模仿敏捷而敏捷,因为一知半解而自己耽误了前程。我想提问者所指应该是后者。我是一名有着多年敏捷研发、测试、咨询、管理经验的实践者,从2006年开始做第一个敏捷项目,我已经练就得将敏捷思想深入骨髓了,我想将我的理解、经验和国内的朋友分享,确实想帮助那些想学习敏捷、想学习成功经验的国内企业正确地实践敏捷。

Q:敏捷团队容易过分关注眼前的短期目标,而忽视长期的战略目标。

A:这是一个陈述句,我却希望这是一个疑问句。目标应该是可度量、可抵达的,否则目标不成立。长期的目标在那里吗?我们要问问团队,这个目标,大家的理解清晰一致,可抵达吗?随着环境的变迁和行业趋势的发展,我们的长期目标是不断修正的。IBM的RTC产品就是使用敏捷开发的产品,我们的产品经理已经为产品规划了极致的未来,一种将体验、协同、过程融于一体的未来工具,我们因此做了非常高级但完全可能被取缔的发布计划。而为了最快将产品价值产生出来,我们为这个产品的长期计划增加了一些小周期的、目标明确的里程碑。经过客户和使用者对迭代发布的体验反馈,通过当下时刻对趋势的预测,我们将当下判断为最有价值的功能作为短期目标先实现。如果以上情景作为我们下结论前的一个前提,我认同提问者提出的观点。

5.有关实践的探讨

Q:在实际业务中,事先可能对需求框架没有理解,也就无法确定一个大的框架,这个问题该如何解决?

A:在Rational敏捷方案里,我们有两级敏捷计划。第一步,我们对预计的范围、时间/预算、资源会有个预估,叫做发布计划,这个计划实施之后误差会很大。预估是为了更好地和项目的上线沟通,以获得批准;而到了第二步,也就是产品清单展开细节,团队选择任务做迭代计划的时候,产品负责人一定要给出一个先后顺序,价值高的先做,价值低的后做,在保障价值前提下,技术风险高的先做,这样我们便有了迭代计划,迭代计划是一个具体的承诺,一旦承诺就需要付诸行动,确保完成,这里所有涉及的范围/时间/预算/资源都是具体和清晰的。但等到第一个迭代完成,客户反馈后,我们发现还未做过的特性或功能里有许多调整,那么产品负责人需要重新调整第二个迭代的产品清单优先级,团队又从新的产品清单里选择重要的工作放到第二个迭代,以此类推。

Q:我看到您介绍的那个全家出游的故事,他是按照a-b-c顺序的过程,但实际开发过程往往会有些并行进行的开发,那么敏捷开发如何平衡顺序开发、并行开发呢?

A:这里的“并行开发”是个敏感词汇,并行如果是指一个人同时在做两个项目,这就不是敏捷开发了。我们允许将复杂项目拆分成多个独立的、可耦合的小单位,分给不同的团队,它们是可以并行开发的。

Q:产品清单达到所要求的功能确实时间会较长,且无法再拆分,如何解决?

A:其实,拆分产品清单并没有你想象的那么难,先别给自己设限。工作项既可以按照功能点拆分,还可以按技术、结构、过程拆分。原则上,迭代时间越短,单个工作项能够分配的最大时间越小。试着和开发者沟通,既要理解拆分工作给开发者带来的额外压力,又要讲清楚敏捷开发重在协同,1个人走100步,不如100个人走1步,拆分工作项是每个人都需要做的,设定一个团队成员、团队负责人都能接受的工作项最大粒度,做成团队规则,团队会接受的。

Q:还有一个问题,敏捷模式下是不是要求客户充分参与?

A:是,但这并不容易做,在与客户沟通和交互时,对于项目层面来说,客户说了算,那么频繁接洽,请客户参与验收测试和“审阅&反馈”顺理成章;但是对于行业应用和产品开发,你面对的将是100个客户,IBM除了请以上客户参与外,我们还有一些客户项目和反馈机制,这个是我今年的工作重点。

Q:敏捷方法与传统方法的利弊?如何甄别何时何地需要采用敏捷而不是传统方法呢?

A:在纠结变化的利弊之前,我想分析下敏捷和瀑布,当你的客户要求你建一座大楼,蓝图、效果图都出来了,你为什么不用瀑布开发方法按部就班呢?可是当客户连自己要什么都不清楚,比如一个方舟或者绝世地堡,此时,你还是得用敏捷,因为没法瀑布。这么说来,是否你对变化的利弊就不再纠结?

6.有关新技术的探讨

Q:敏捷开发如何应对云时代?

A:我感到云服务、企业移动、大数据和敏捷开发很快将成为一体方案,针对云与敏捷开发,在2009年~2011年的项目中,我自己所从事的开发和测试工作就已大量运用。在项目里,云提供了轻量级的环境构建、配置管理服务,将敏捷开发中的规模测试部分缩减了近90%的硬件和时间成本。

Q:敏捷开发的目标是提高开发效率,和现在的DevOps概念的区别大吗?

A:敏捷开发目标和DevOps的目标均是在加速从产品初步想法到最终价值交付的过程,并在过程中平衡投入、时间、质量和风险。而DevOps除了横跨产品研发的完整生命周期外,还涵盖了“交付”后的“部署、监控、优化”,见图A-1。

00017.jpeg

图A-1 DevOps贯穿产品的完整生命周期