【IT168 专稿】

    SearchSoftwareQuality.com最近一次读者调查显示，开发组织在敏捷方法方面的经验越来越多——这些方法通常以Scrum或Scrum和其他方法（包括瀑布）的混合为主。他们受益于过程改进和快速交付，而在分布式团队中，敏捷也得到更多的应用。尽管如此，这些组织认为许多老问题依然存在，比如文档、需求以及对改变的抵制等。虽然许多公司刚刚向敏捷转型，但可以看到，一种新的敏捷已经悄然开始形成。

    当问及公司所采用的开发过程时，被调查者的56%都回答敏捷过程，而去年该比例为45%。测试驱动的开发(TDD)所占比例也有所提高，从2008年的19%上升到今年的21%。瀑布式也从44%升高为48%，但RUP的使用却从15%下降到10%，UML也从14%下降到10%。

    IT也有类似的结果。与去年的39%相比，敏捷过程的使用增加到52%；瀑布式则多年以来都是36%。TDD也稍有增长，从18%到21%，而RUP和UML的使用稍有下降。

    虽然对于大部分被调查者来说敏捷是一种相对较新的概念，但是各组织的经验越来越丰富，今年的“新手”也比去年少。 比如在2008，有66%的被调查者报告说刚使用敏捷不到一年的时间，而今年这个数字下降到46%。两年以上的比例从18%上升到29%，三年以上的比例则从15%上升到24%。

    James Shore认为这种经验还比较肤浅。被调查者认为敏捷上的最大挑战是文档、交流和对改变的抵制。这与去年的三种最大挑战是相同的，虽然当时第一位的是交流。

    Shore认为，“这反映了敏捷采用上的不成熟。敏捷团队强调高带宽的交流，通常是面对面的、实时的，而不是使用书面文档。如果文档很重要，那么他们就做不好交流。我觉得，接受新概念时，采用熟悉的方面而抛弃困难的方面正是人的本质。只采用两星期的sprint和每日站立会议是一种肤浅的方式。”

    JP Steffen是Wells Fargo的项目管理承包商，作为被调查者之一，他认为虽然他所在机构正在引入一些敏捷实践，但是文档“真的非常糟糕。 因为项目和需求采集是多部门共同进行的，项目在文档阶段的习惯也都根深蒂固。等采用了更加敏捷的方式之后，对文档的依赖会成为更大的难题。”

    Joel Cranford是Healthstream的一名业务分析师，他们公司为医疗保健业提供培训和研究解决方案，并于去年开始向敏捷转型。他认为他们对文档的把握“恰到好处”。

    福里斯特研究所的分析师Dave West说，虽然早期敏捷项目以软件构建为主，而不是以编写文档为主，但随着时间的推移，各组织逐渐发现为了维护软件的生命周期，某些类型的文档还是必须的。不过文档的方式还是会变的。他说“Wiki的效用和Word文档是一样的。”

    Voke公司的分析师和创建人Theresa Lanowitz说，总体来说，仍然有许多庞大、昂贵、冗长而且由许多组件构成的项目，“在很大程度上文档仍是必须的；对于那些监督严格的组织，比如药物公司和金融企业等更是如此。”

    关于敏捷开发工具的重要性，今年的调查显示其排序为：漏洞跟踪、需求管理、项目管理和功能测试。而在2008这个顺序是：需求管理、漏洞跟踪、项目管理和单元测试。

    Shore认为这还是反映了“敏捷的采用现状。许多人都是在还没完全弄懂它的情况下采用敏捷。 我们应该直接与客户合作，需求是活的，因此需求管理并不是必须的。另外我们还应该使用可减少缺陷的敏捷工程实践；这样缺陷减少，漏洞跟踪也就不会排在那么高的位置了。我认为，如果您真的充分利用了敏捷，那么单元测试才应该位于首位。”

    而福里斯特的West则认为：“许多组织开始的时候都使用漏洞跟踪工具，但是慢慢地他们就会转向ALM（应用生命周期管理）工具，比如Rally或VersionOne。” 特别是对于那些跨部门的敏捷团队，他们的非开发人员也是很难使用像JIRA和Rational ClearQuest这种产品。
 

    关于敏捷的优势，相对去年的68%，今年有80%的人认为敏捷帮他们改善了过程。其他优势还有更快的上市时间（67%，相对去年的近50%），以及更少的漏洞（42%）。但有意思的是，只有28%的人报告了更低的开发成本，而去年则是34%。

    Burton Group的分析师Kirk Knoernschild认为：“推动敏捷实践的一个因素就是改善开发过程，但是，采用敏捷的目标并不仅仅是改善过程，还要提高生产力、质量、交付速度，并与利益相关人和客户建立更好的协作关系。”

    但是Shore认为，过程改善并没有长久效果。“从短期来看，部分敏捷实践确实可以带来管理上的不同，能够提高士气，透明性也更好。但是几年后，肤浅的敏捷工程问题会让你筋疲力尽。”

    从团队构成上来看，敏捷更受到地理位置分散的团队的欢迎，这一比例从去年的48%上升到55%。

    West认为：“我们可以看到，现代的工作方式确实在影响着敏捷。”理想的情况下我们应该处于同一场所，这也Skype、IM等工具和技术流行的原因，因为它们可以让我们靠得更近。而且，他又说道，Facebook文化使得地理上的分散更容易让人接受。

    Knoernschild说，分散的团队“绝对”可以有效地利用敏捷，但是他强调必须准备好基础设施。“如果你坐在团队中其他两名开发人员的旁边，可能你们不需要太多基础设施，但是如果你们相隔2000英里又有时差的话，可以方便协作的基础设施的重要性就体现出来了。”

    根据59%的调查对象，典型的敏捷团队有4-9个成员（去年为54%），然后23%为10-20成员（去年为20%）。3名及以下成员的比例减小，从2008年的23%降到今天的8%。

    Knoernschild说：“我并不认为团队应该有一个什么‘正确’的大小。这取决于项目的规模和范围。随着团队的成长，实践的规范化和基础设施的重要性就变得越来越明显。”

    对于那些未完全转向敏捷方法的企业，有43%认为他们在同时使用敏捷和瀑布。至于原因，有24%的被调查者认为他们的员工缺乏敏捷技能。其他原因还有员工的瀑布技术更为熟练（18%）、认为瀑布仍然有用无需改变(14)。

    Steffen的团队正是这种情况。他说，瀑布是一种协作性很强的过程。“我们并不是开始的时候和利益相关人开一个会，采集需求，然后解散。我们的项目经理认识到了这种方法的局限性，因此他们继续和开发团队进行交流甚至进行每日讨论。所以，利益相关人和开发团队之间的协作环境恰是我们加进瀑布过程中的东西。”

    对于真正使用敏捷的团队来说，Scrum是最主要的方法。大约有一半的团队使用Scrum（去年为 40%），而Extreme Programming(XP)、Crystal和DSDM的比例则有所下降。Knoernschild说：“Scrum是目前最流行的项目管理方法。 你可以在项目管理的各个层面上看到Scrum应用，组织扩展的时候也使用Scrum 中的Scrum方法，然后在开发层，比如单元测试、连续集成和结队编程上使用一些XP实践。”

    Cranford说，Healthstream使用的是Scrum与瀑布的结合。“我不会说这是一个成熟的敏捷过程：因为虽然我们已经用了一年多的Scrum，但我们还有许多未解决的难题。我们在寻找最适合我们的敏捷方法——这是主流Scrum和部分瀑布的混合，而我们差不多已经快要到达目的地。”

    Shore认为：“实际上大部分人在做的都是Scrum加瀑布。“在开始的几年这会比较有效，但是然后软件质量和设计质量问题就会慢慢出现。”

    根据Shore和福里斯特West的观点，非常好的结合应该是Scrum/XP。 但是，West还认为，可以从更传统的方法中提取到其他优秀工程实践。West说：“我们现在不再执著于一种方法，而更易于接受最好的东西，虽然仍然有给它定一个框架的习惯。”

    就在各组织尽力寻找最适合自己的敏捷实践的时候，Knoernschild称一些新的方法已经悄然出现，比如Kanban。“虽然不能说它是另一种敏捷，但是我目前还没有更好的词来形容它，它是新一代的敏捷方法。可以说是一种精益思考。 而这正是新一代敏捷方法和软件过程的中心。”