掌握Scrum 实现敏捷

Scrum是敏捷的，所以它具有其它敏捷方法具有的好处。第一，交付的是客户所想要的，因为客户是非常投入的，不只需求开发过程参与其中，而是从概念到交付的整个过程。敏捷开发的另一大方面是所谓的测试优先，在过程早期就将测试和质量引入其中。

　　Joh scumniotales是Scrum早期开发者之一，现任Serena Software公司生命周期管理副总裁。scumniotales介绍了Scrum和Agile的商业及技术发展趋势，同时描述他在Scrum初期研发阶段所积累的经验，以及目前Scrum发展的现状。最后，对于大众及管理层对Scrum应抱有哪些期待、是否应该采纳Scrum等，John Scumniotales也提供了重要建议。

　　

 

　　你能从体育运动中学到什么？比你想到的更多！你是否知道敏捷开发可能源自橄榄球运动吗？

 

　　在一篇极具创新和影响力的文章《新产品开发新游戏规则》（哈佛商业评论，1986年1-2月） http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml?id=86116中，作者Takeuchi和Nonaka指出，项目采用小型跨功能团队在历史性上创建更好的结果。作者将这些高效团队喻为橄榄球Scrum团队。

 

对外行人而言，Scrum是什么？

 

　　Scrum是一种敏捷开发方式和方法。如果你完全熟悉敏捷运动，你就知道这是一种快速增量交付软件产品的能力。在构建产品过程中构建产品的内部团队与客户高度协作。因此，根据有益于客户的原则，它的一个主要好处是，您有客户或客户代理内嵌于开发团队。所以，构建满足客户需求的可能性会更高。

 

Scrum的独特之处在哪里？

 

　　当然，Scrum过程中的协作和沟通使其独具特色。比如，我们有一个跨功能开发团队，测试、技术、文档、客户和产品经理，他们每天举行会议，对项目进展进行讨论与分析。举例来说，我昨天做了什么，我今天要做什么，我有什么问题，我该如何解决，我如何将从客户实时反馈过来的信息反映到产品中去。

　　他们具有在更高层次上做好增量交付产品质量能力。以一个月为基础，两周至5周，他们向客户提供有质量的产品，所以说这是一个更为渐进开发的过程。

　　另一不同是与其他敏捷方法相比较SCRUM侧重于项目管理和人，极限编程XP或者是另一种受欢迎的敏捷方法更关注于软件开发人员层面及如何写代码及测试。

　　Scrum聚焦于价值流和信息沟通。

 

Scrum团队是怎样的？谁应成为Scrum团队一员？

 

　　Scrum团队是拥有测试人员、开发人员、文档专家和客户的跨功能团队。在Scrum，你采取多阶段的交付方式。而在传统的模式，在不同生命周期阶段你有不同的团队成员参与。在一个Scrum项目中，跨功能团队参与整个生命周期，比其他规程融入其中要早（这里指所有的需求，设计、编程、测试等开发活动在项目早期就出现，而不是像传统方法那样分布在不同阶段）。

 

从商业角度看实施Scrum有什么益处？

 

　　Scrum是敏捷的，所以它具有其它敏捷方法具有的好处。第一，交付的是客户所想要的，因为客户是非常投入的，不只需求开发过程参与其中，而是从概念到交付的整个过程。因此，它更有可能满足客户需求。

　　敏捷开发的另一大方面是所谓的测试优先，在过程早期就将测试和质量引入其中。其结果是更高质量的交付。对客户而言，得到价值更为迅速。它不是一个经过18个月的漫长开发周期，发布给客户和市场，而客户需求和市场已经发生变化的过程。它是敏捷的，采用增量方法，快速地将价值增量地交付给客户。

 

Scrum方法有什么局限性？

 

　　它难以用于管理大项目，是这样吗？管理任何大型复杂项目都是有难度的。当然，在可扩展性方面有挑战。但我认为，在传统项目的可扩展性方面上同样会遇到这些挑战，例如管理相互依赖的跨国团队，异地分布团队的沟通。

　　对于分散在全球各地的分布式团队，它的挑战是确保不会受距离和时间影响的协作（及协作工具）。

 

如果想在公司推行Scrum方法实现高效开发，首先他们应做些什么吗？什么又是他们坚持的？

 

　　我总是建议那些没有内部专家的公司，至少要聘请些有专门知识及技术的领域内专家，以着手实施Scrum。我同样建议它们进行一些试验计划，而这需要你得到上层管理者及与你协同工作的项目组的支持，尤其是那些将成为试验计划成员之一的团队们的支持。

 

如果公司内存在遗留系统，Scrum的方法将带来多大影响（请从积极及消极两方面谈论影响）？

 

　　如果存在遗留系统，很可能你将遇到以往那些遗留系统的缺陷及其突出特性产生的较大阻碍，但好消息是你可以使用Scrum彻底削弱这一阻碍。

　　总的来说，在遗留应用中应用Agile的不利点在于它更依赖于早前介绍过的test-first （测试优先）方法。而采用test-first，则不得不极大地依赖于测试及构建的自动化。在与客户工作的过程及对前景的预测中，我发现常规情况下遗留应用并未构成大规模自动化或测试自动化，因此，我想这才是遗留所带来的主要挑战。

　　毋庸置疑，遗留应用必将带来遗留机构，而这是必须处理的人力变动的管理问题。因为Agile是构建软件的最佳方式之一，因此对于Agile及开发团队而言，人员问题正变成一个越来越微不足道的问题。很有趣的一点在于往往“遗留”的程序员及分析师，相对于那些更现代的应用者，对Agile及Scrum表现地更为兴奋。

　　我相信，挑战更多地存在于管理层，尤其是更高级的管理者们。而我们需要得到他们的支持，帮助驱动这一改革及应用的实现。

　　Agile与Scrum的基本特性意味着，你将看到当它的部分价值融入公司后，几乎不可避免地公司就会向Scrum过渡。它通常在团队中发展起来，而后渗透到整个公司。当然，我也见到过很多由管理层率先倡导而后在团队中普及开的案例。

 

本着节约成本的原则，在坚持原有规范和转向Agile两者间谁的开销更为昂贵？

 

　　成本涉及到转换问题，因此根据具体过程的不同具体开销有所差异。但如果你的操作方法正确，则没有太大的成本问题，我曾见过一些公司在转向Agile的6个月内即实现收益回报。

　　关于这一问题我的看法是，不进行切换的成本远高于切换的成本，你可以看到传统的流水线导向的项目存在的种种问题，如较长的开发周期等；同时，其交付的产品不能满足客户或市场的需求，而质量问题也一直是某些传统方式的顽疾。因此，对我而言，这些成本远大于任何短期的切换成本。

 

在一个典型的大环境下，引入这些想法并让它们真正发挥作用的整个流程，需耗费多长时间？

 

     如果它得到了从管理者到实践团队的极大支持，大概只需3到6个月的时间。在大型公司中，很难低于这个时间段；而在小型公司，譬如说团队规模的，在出色的领导者的带领下，大概只需几个月的时间即可以完成过渡。制定些小规模的试验计划，在一个团队内、一小部分中间先开始试验，得到一部分测试实践结果。

 

如果作为咨询顾问服务于新的潜在客户，并试图让他们相信Agile正是适合他们的方式，你会向他们介绍哪些内容？

 

　　一般地，我会关注：一、跨团队、跨功能协作的特性，这是成功的要素之一；二、增量式开发；三、测试与构建的自动化。这三点即是部分核心内容。