原文猛击→本论文题为《软件组织敏捷转型过程的研究与改进》，有删节。

（二）敏捷方法转型中的常见问题及原因分析

2001年以来，敏捷软件开发方法在软件行业的知名度和使用程度越来越高。据2008年VersionOne公司所进行的第三次敏捷方法年度调查显示[[i]]，其参与调查的2300多敏捷实践者分布于80个国家，其中80%有敏捷项目经验。相对于2006年来自47个国家的722个参与者有大幅的增加[[ii]]。敏捷方法在应对多变的业务需求、竞争剧烈的市场、以及越来越复杂的软件架构时所展现的高效率、低成本、快速的反应速度等优势越来越得到IT公司和团队的认可。93％的参与者认为敏捷方法使他们团队拥抱变化的能力得到了增强，74%的人认为其生产效率得到了提升。

据amsoft公司2008年所做的另一项敏捷使用情况调查显示[[iii]]，82%的参与者认为使用敏捷方法之后其生产效率得到了提高，77%认为系统质量得到提升，72%认为系统开发成本较之前降低，78%认为其客户满意度得到提升。与此同时，敏捷软件开发方法的使用比率从2006年的41%上升到2008年的69%。

中国IT业采用敏捷开发方法的情形有所不同。相比之下，中国IT公司对敏捷方法的接受度落后于国外平均水平。作者所在的公司专门从事敏捷方法实施咨询业务，据了解，在2005年及以前，在国内实施敏捷方法的开发团队屈指可数。从2005年起，逐渐有一批人意识到敏捷开发的好处并开始实践。自从2005年作者所在的公司ThoughtWorks在中国开设业务以来，明显的感觉到敏捷方法的接受程度以及传统团队对于向敏捷转型的意愿越来越强烈。到2008年，敏捷开发方法已经被很多团队所采用。从2008年起，国内一些大型IT公司陆续向开发者社区表示了对敏捷开发的兴趣或分享其经验，例如腾讯和华为分别在第三届敏捷中国大会上做主题演讲，报告其开发团队在最近一年实施敏捷的情况。

然而，由于对敏捷理解的不同，不同团队的实施结果也大相径庭[[iv]]。某些团队宣称其敏捷实施非常成功，而据笔者调查，这些团队所宣称的成功多数是因为政治原因，他们必须告诉高级管理层敏捷是成功的，否则团队的领导，即推行敏捷实践的责任人，将会因此而获得差评。另有一些团队虽然已经部分采用了敏捷实践，但实践效果比较差。这使得管理层认为敏捷方法不过如此，因而放弃了对敏捷方法的关注和支持，最终敏捷实施的尝试以失败告终，又回归到传统的方法。

根据VersionOne的第三次敏捷方法年度调查报告统计[2]，45%的参与者认为改变整个组织的文化是他们将敏捷方法进一步推广的阻碍。23%的参与调查者认为组织的价值观或文化是导致他们项目失败的原因。

随着敏捷理念的传播，一些团队开始认识到，在自己自主的学习和使用敏捷方法的实践的同时，必须开始尝试推动公司向敏捷组织进行转型，不仅要从过程上转型，更要从文化和价值观的方面转型，才能更好的保证团队级别的敏捷方法实施。

国外对于敏捷转型的研究始于2003年左右，Mike Cohn首先研究了将敏捷应用于组织的方法[[v]]，结果发表在《Computer》杂志。Michael Hirsch研究了从计划驱动的企业文化转向敏捷文化的经验[[vi]]并在国际软件工程大会上做了报告。Iva Krasteva, Sylvia Ilieva研究了敏捷实施过程中效果不佳的一些原因[[vii]]；Elke Hochmüller和Roland T. Mittermei对敏捷实施中的一些误解做了研究[[viii]]。

那么组织或团队进行敏捷实施的常见问题和原因是什么呢？

本文涉及到多个过程改进术语，在此特别定义如下，以避免混淆：

• 敏捷实施（Agile Adoption）：或称敏捷方法实施，指采用敏捷相关资料上所提及的实践，在开发团队内部推行敏捷方法的过程。
• 敏捷转型（Agile Transformation）：或称敏捷转型实施，指从组织或团队级别上进行敏捷思想和敏捷文化的改变，其涉及范围已经超出开发团队。

2.1        组织或团队进行敏捷实施的常见问题

在作者参与过的敏捷实施过程中，以下的问题和情景经常出现。这些问题是客户接受敏捷的顾虑和阻碍，有时候，这些问题甚至会直接导致敏捷实施的失败。这些问题可以归结为四方面因素：组织、文化、过程、技能。

2.1.1 组织因素：敏捷的转型无法获得高层管理的支持。

管理人员希望看到可以量化的指标，以证明敏捷方法的优势所在。而实施敏捷的团队很难给出具体的可以量化的指标。因而高层对全面采用敏捷会存在顾虑。

敏捷方法中鼓励结对编程等实践，但管理人员会质疑两个人做一个人的工作是在人力成本上的浪费。另一方面这种结对编程的方法使得管理人员无法就某一个人员的工作量进行跟踪。HR部门不支持IT部门的这种变化，认为这样无法衡量每个员工的个人绩效。

管理人员关心在敏捷团队中知识如何积累和传递。许多IT公司的人员流动率高，因此为了维护一个产品的生命，经理们往往希望开发人员多写文档和注释，把所有的信息都固化起来。然而有的项目经理听说敏捷“不写”文档，于是对敏捷方法是否能在其团队实行抱有疑虑。高层管理人员也认为软件的设计文档是公司资产，对于没有专人编写文档无法放心。

有的公司将测试人员和开发人员分为两个部门以便于管理，而敏捷鼓励测试和开发人员一起工作，高层管理人员认为这种混合在一起的工作方式会提高管理成本。因此对实施敏捷犹豫不决。

有的项目管理人员认为敏捷只适合于小型项目，而他们的项目大多是大型项目。因此在未能证实敏捷支持大型项目之前，拒绝尝试敏捷方法转型成为第一个吃螃蟹的人。

2.1.2 技能因素：敏捷实践的技能或经验不足。

有的团队自己开始实施敏捷，在没有任何人懂得的情况下开始尝试测试驱动开发或重构，最终由于种种原因不能坚持下去，于是认为敏捷不适合自己的团队。

有的团队没有专门的人做需求分析，项目经理同时负责需求管理，需求的格式采用纯文本的叙述。需求方法不适宜导致开发的时候觉得实施起来束手束脚，于是被迫放弃敏捷方法。

当出现需求变化导致需要代码重构时，开发团队专门拿出时间进行重构，但重构结果不理想，以至于开发团队开始惧怕重构和拒绝变化。最终导致代码积重难返而使得敏捷实施效果差。

有的项目管理人员希望给团队每个人分配任务。但发现敏捷方法鼓励员工自己选择任务，他们担心员工倾向于偷懒而选择简单的任务，最终导致复杂的任务没人认领。于是认定敏捷在此方面不能帮助他们。

有的团队认为2周的迭代太快太难以管理，于是决定用2个月或3个月进行迭代。等到发现这样的开发结果不理想时，又认为是迭代开发的问题。

有的团队对于需求量的估算精确到小时或代码行，仍然常常会出现估算不准确的问题。对于敏捷方法鼓励用一种更不精确的方式来进行估算表示重重疑虑。

2.1.3 文化因素：团队固有文化和敏捷所需要的交流反馈存在冲突

有的团队成员不愿意和别人交流，一直习惯于独立工作。于是项目经理认为敏捷的结对编程等实践无法执行。在迭代交流会议上由于大家不踊跃发言，最终演变成了向项目经理汇报的报告会。

某些团队成员不愿意进行变化，从内心抵触任何的改变，故意针对项目经理的敏捷实践意图进行抵制，以至于项目敏捷化阻力重重。

有些团队不能坚持做回顾总结，每次的回顾总结都成为批斗大会。大家纷纷指责某些人的错误，导致团队中矛盾重重。最终总结回顾会议暂停实施。

有的团队成员认为某些工作不在他的工作范围，于是也不理睬，也不碰别人的代码，专心的在自己的代码范围内耕耘。使得别人不懂得他写的代码，他也不懂得别人写的部分。

有的公司鼓励加班，认为加班的员工才是为公司奉献的好员工。于是团队成员纷纷效仿，哪怕没有事情也要在公司待到九点才会回家。有的公司为了赶工期，更是长期的加班加点。

2.1.4 过程因素：外部原因使得团队无法正常实施敏捷

有的开发团队无法得到客户及时反馈。有的根本见不到客户的人影。他们只好蒙着头继续开发，直到交付的那一刻客户才说开发的不符合要求。

有个开发团队和测试团队分开在两地，或其他的团队无法直接配合。他们的工作被空间分割为多个阶段。因此下个阶段要等待很久才能得到上一个阶段的产物。等出现问题反馈回去的时候，又是几个月过去了。另外分开的团队导致两边交流存在障碍，以至于团队倾向于用邮件交流，导致降低效率。

有的公司进行产品开发，需求到达开发团队的时候已经按照一定格式写好了。编写需求的产品经理忙着做其他的工作，开发团队按照这样的需求盲目的开发下去。

有的公司的技术架构需要和其他系统集成，而其他系统由不同的团队或公司开发，想要找到技术支持需要很久的等候。于是一个需求就被拖延了多个迭代导致开发效率大大降低。

2.1.5 敏捷实施中问题的原因分析

上述的这些问题都是发生于真实项目中的问题，这些问题的出现阻碍了开发团队和组织进行敏捷实施或转型的努力。为什么客户会有如此多的问题呢？原因可以归纳为两种。

一、忽视了敏捷实践之间的关系。敏捷实践不是孤立而成的，它们之间存在非常强的依赖关系。例如没有持续集成，测试驱动开发和重构根本无从谈起。很多组织以为可以简单的采用一种或几种实践，就可以开始敏捷，或者认为只要管理实践敏捷化，具体技术实践可以不敏捷。这样的误解导致了敏捷实践从一开始就阻力重重。

二、忽视了向敏捷价值观的转变。敏捷开发不仅仅是一系列实践，它同时还是一套价值观体系。而实施敏捷的团队和组织，往往忽视了敏捷实践背后的价值观，一味的按照教课书上的实践来应用，不考虑人的思想转变过程，导致的结果往往是从文化和根本上的不适应。

REFERENCE

[[i]] VersionOne, “3rd Annual Survey: 2008, The State of Agile Development Full Data Report” [EB/OL] ,http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf, June-July, 2008, 2009-04-20

[[ii]] Sims, Chris, “State of Agile Survey Shows Wider Agile Adoption” [EB/OL], InfoQ, http://www.infoq.com/news/2008/09/state-of-agile-results, 2008, 2009-04-20

[[iii]] Agile Adoption Rate Survey: February 2008 [EB/OL], Ambsoft, 2008

[[iv]] 李剑，Scrum在中国——企业实施情况调查实录，[EB/OL]，http://www.infoq.com/cn/articles/scrum_china_2008_investigate，InfoQ，2008, 2009-04-20

[[v]] Cohn, Mike and Ford, Doris. “Introducing an Agile Process to an Organization” [J], Computer, June 2003, vol.36, no.6, pp.74-78

[[vi]] Hirsch, Michael. “Moving from a plan driven culture to agile development” [J], ICSE ’05, May, 2005, pp.38-38

[[vii]] Krasteva, Iva and Ilieva, Sylvia. “Adopting an agile methodology: why it did not work” [J], APOS ’08, ISBN:978-1-60558-021-0, Leipzig, Germany, 2008, pp.33-36

[[viii]] Hochmüller, Elke and Mittermei, Roland T. “Agile rrocess myths” [J], APOS, 2008, pp.5-8