大型项目开发使用敏捷是否合适?不该问的问题

人们经常问笔者敏捷是否适合大型的项目,或者是否它只适合小型的项目和团队。笔者意识到这是一个很难解释的问题。您可能会问为 1000 个人准备食物,是否和为准备四口之家的食物没有本质区别。当然是这样的,但是您可以看到不同的方法,食谱以及器具。您可能会在一个 20 加仑的容器中混合沙拉,而不是一个小罐中进行的。

为什么这个问题是错误的?

 

 

Ron Jeffries,一个著名的极限编程(XP)开发员,宣称 XP 实践在任何范围内都能很好的工作。他说当人们对大型项目的敏捷反感时,他们实际上并不理解敏捷;因此,他们并不能评价大型项目的适用性。1 笔者赞成他的观点。笔者不会去讨论关于敏捷的定义,因为笔者已经在The Rational Edge 2007 年 5月的文章中做了详细的阐述。 2 笔者假设您已经阅读了这篇文章,还有《敏捷宣言》(Agile Manifesto)及其实践的内容。 3

 

《敏捷宣言》(Agile Manifesto)对项目的大小并没有做特定的限制。实际上,敏捷宣言是一种价值的定义,这种价值是宣告选择用以应用到软件开发中去的。如果您在一个拥有这些价值的公司中工作,或者您所在的项目团队拥有这些价值,那么您可能会决定使用敏捷实践。如果因为某些原因您没有或者不能采用这些价值,那么您就不需要为敏捷而操心了。与一些流行的看法相反,这并不意味着您是一个不思进取的人!

 

因为价值是公司的属性,所以现在就可以很容易的看出问题“敏捷适合任何项目规模吗?”是糟糕的问题了。价值决定了公司是怎样进行业务活动的,而不是公司或者项目的规模决定的。显然大型的公司拥有更多的过程和管理,但是核心的价值是不受影响的。

 

我想要做一个小型试验。我研究了一些大型和小型的公司。我查看了他们关于业务行为哲学的描述和信息。阅读下列信息,并查看您是否可以识别公司,或者至少是公司的规模以及它的软件项目。

 

公司 A 列出了一些他们信仰的东西,如下所示:

关注用户并尽力满足他们的需求。

 

 

快总比慢好。

 

 

您不需去等待一个答案。

 

 

保持认真。

 

 

很好就是不够好。

公司 B 的原则宣称“他们致力于快速并精确的构建软件。最成功的软件项目是强有力的管理,高级的技术技巧,以及使用定义良好开发方法学或者过程的混合体”。

 

 

公司 C 有三条强调的值:

服务每位客户的成功。

 

 

创新非常重要,对我们公司以及我们所处的世界都很重要。

 

 

所有关系中的信赖和个人责任感。

公司 D 看重整体性,诚实,开放性,个人的优异,构建性的自我批评以及相互的尊重。尊重员工和合作者,并拥有一定的技术。他们进行巨大的挑战,并为征服它们而骄傲。他们通过奖励客户,投资者,合作者,以及员工,提供结果,并为最高质量奋斗,而对他们负责。

 

 

公司 E 有一句话来描述他们的任务:“通过创新性,智能化,可用的数字媒体方案的概念和执行来服务客户。”

 

 

公司 F 相信:

最佳的方案从清晰和明了的方案开始。

 

 

最佳的地址是标准遵循者。

 

 

最佳的软件是迭代开发的,并有最好的客户参与其中。

 

 

最佳的代码从测试开始。

无须再说,他们对使命的理解和陈述值得我们的尊敬。现在,您是否已经可以决定公司的信息及其规模?在这里我不会提出公司的名字,但是我将会简单的介绍如下:

 

一家是我们每天都要与之打交道的跨国公司。

 

 

一家为客户编写软件和专业培训 XP 团队的小型公司。

 

 

世界最大的技术公司之一。

 

 

世界上最大的软件公司之一。

 

 

一家为其客户构建 Web 程序和其他系统的中等规模的公司。

 

 

一个从前是我学生的人创建的小型咨询公司。

当我在寻找这些公司,以及他们任务和价值的时候,我没有发现任何与规模或者“敏捷”相关的信息。

 

哪些敏捷实践能够适合大型的项目?

 

那么,针对大型项目的敏捷,什么才是应该问的正确的问题?我相信正确的问题是“哪些敏捷实践最适合支持大型公司或者大型项目?”

 

不同规模的公司可能会使用不同的过程和实践。与涉及到一个或者两个人的项目相比,涉及到数百人的项目肯定会有不同的控制和抑制因素。沟通频率会随着项目成员的增加而按指数增加。为了获取重要的交流信息,大型的团队必须以更加严格和正式的方式进行工作。上面所有我提到的公司,运行的是敏捷方法很适合的项目。可能并不是所有的项目都认同敏捷,但是许多公司确实是认同的。这样的项目与顾客有规则的交流,并且必须处理需求的快速更改。开发团队成员相互之间必须有紧密的合作,并要快速不带迟疑的对系统作出决定。

 

让我们看一下敏捷实践,并看看它们是如何适用于大型项目的。让我们承认大型的项目要有二十或者更多的人员参与,但是这是一个任意的门槛。您可以决定,我的标准根据您对大型项目的概念是否需要调整。

 

Ron Jeffries 说大多数的 XP 实践适合大型的项目。大多数对敏捷感兴趣的人都或多或少的对 XP 有一些了解,这就使得它成为一个好的起始点。Ron 的 XProgramming.com Web 网站识别十三种实践。 4接下来的是我对这些实践是否适用的评价。对于每一项实践我都指出了我是否认为它适用,并简单的呈现了我的意见。

 

整个团队(不)。这种实践需要所有的团队成员坐在一起进行商量。至少要有一个顾客代表在场。大多数团队都是分布式的,这样有可能每一个分开的地理位置都有一个顾客代表,所以可能它并不是经济上合理的。而且,找到一个可以容纳二十多人或者更多人的房间可能是非常困难的。大型的团队会在项目的生命周期内拥有小型的分团队。每一个这些团队可能都可以使用 Whole Team 实践。

 

计划策略(是)。计划策略让一个团队简单的计划和追踪。不管团队用以获取需求的工具以及迭代的长度,计划策略都让生产现实的迭代计划变得更加容易。

 

小版本(可能)。“小”是一个主观性的词语,取决于您的定义。但是,大多数的软件系统允许团队去选择最终系统的一部分,以完全执行一个小型的版本。它遵循迭代和增殖开发的原则,并在使用IBM®Rational®Unified Process (RUP)的各种版本的项目上运行良好。一些系统,特别是那些涉及到集成通用硬件和软件的系统,对与使用小型版本可能不太友好。

 

定制测试(是)。还有谁比客户更能知道系统必须去做什么?顾客代表可以书写测试用例,或者帮助书写任意项目的测试用例。实际上,对于一个更不敏捷的项目来说,顾客通常指定验收测试作为合约的一部分,或者它的补充物。

 

简单设计(可能)。设计应该尽可能的简单,这是理想化的。正如 Jeffries 描述的那样,这种 实践确实是不断增值的设计。项目需要的设计的数量,应该由项目的类型以及项目需求来决定。

 

配对编程(是)。成对编程看起来可以产生更好的质量且避免过大的压力。只要有两个团队成员可以一起工作,这种实践就可以进行。如果团队是完全地理分开的,那么这种实践就无效了, 5 但是它与团队的规模无关。

 

测试驱动开发(是)。对质量有严重责任的开发员,应该为他们的工作书写单元测试。如果他们书写单元测试的话,他们就可以在执行代码之前就去书写了。项目规模并不影响什么时候书写测试的选择。

 

重构(是)。好的程序员不停的工作,以创建更加强壮更具维护性和有效的代码。项目的规模再一次与此无关。

 

持续集成(可能)。小型项目可以使用简单的工具去执行持续的集成实践。拥有多个位置和多个代码库的大型项目,可能并不能构建完整的项目。显然他们会需要更高级的工具,以达到一个更加有效的集成过程。经济考虑可能会是决定是否采取实践最重要的因素。

 

集体代码拥有权(值得怀疑)。虽然小分队的团队成员可能会理解所有他们创建的代码,他们非常理解其他团队成员工作 的几率很小。一般的代码所有权会在开发员之间进行分配。

 

编码标准(是)。没有编码标准的任意规模的项目都注定会出问题。

 

隐喻(不)。坚定的 XP 支持者对这个问题很关心。有一些人做了长期的尝试,想要人们意识到隐喻的价值。我仍然没有被说服。显然,在我们开发结构时我们使用了很多的隐喻,但是它们并不能取代结构的作用。在笔者看来,随着项目的变大,试着得到隐喻的精确信息是十分低效的。

 

可持续步伐(是)。这不仅仅关系到公司和项目的规模,还关系到公司和项目的文化。

 

我赞成 Jeffries 的评价,他说大多数 XP 实践能够很好地适应大型的项目。那么其他的敏捷实践呢 ?

 

 

对大型的团队来说 Scrum 是否适合?

 

Ken Schwabe,Scrum 创作人之一,肯定地回答了这个问题。他指出通过“scrums of scrums”,可以适应大型团队。 8 Scrum开发员说这项技术适用于超过 500 人的大型团队。我并不能确定这些团队成员是否都只忙于一个项目。

 

还有许多其他我们会讨论的,关于对大型团队适用性的敏捷方法学。您可以自己去执行这些实践。在这里,我想要推荐一种更有效使用时间的方式。

 

 

重构问题

 

在试着决定怎样通过关注技术或者过程,而不是项目来应用“流行”技术,工具和过程时,我已经掉进了一个陷阱。当我在处理设计和开发 Rational Unified Process,也就是 RUP 时,我与我的客户进行讨论,并发现那些成功者,关注的是为项目的成功需要去完成的项目和工作。

 

关于 RUP 的一个微观概念,是这是一个过程而不是一个过程框架。成功的 RUP 采用从他们的项目开始,并定制 RUP 以使其适合他们的项目和公司。我想在我们试着对采用任意的方法学,包括敏捷技术的采用时,相同的方法也是有效的。

 

识别价值

 

任何向公司引入更改的尝试都将会失败,除非这种更改与公司的核心价值相协调。例如,试想一下,向您的公司引入一项软件再使用实践。软件再使用的益处总所周知。但是根据开发员所写代码的数量进行奖励,那么这种价值就很难引入。开发员知道他们是怎么评价的。程序员将可能抛弃这种方法,以确保他们并没有再使用模型,因为它将会使更少的代码被书写出来,这就意味着更差的性能。

 

如果我们假设采用敏捷方法时,您并不准备更改公司的价值,那么如果您想要使敏捷方法获得成功的话,您就必须选择与实际价值相匹配的实践。

 

识别背景

 

项目和公司存在于一个背景中。背景就是项目或者公司存在的环境。背景的一些典型特征是:

 

团队位置团队成员是否位于同样的地理位置(例如一个单独的区域)?团队成员是否可以有规律或者无规律的聚会?如果他们并不位于单独的区域,那么他们的地理分布如何?他们是否被一些时区或者地理因素所阻隔?

 

 

已存在的实践和工具如果您不断的引入敏捷方法的话,那么它们就必须执行已存在的过程和工具。更改必须以一种尽可能自然的方式进行整合。当一开始团队将更改整合到他们的工作方式中去时,一般都会引起生产效率的下降。如果更改与现存的实践并不协调的话,这种下降会更加的明显,而且新的操作可能永远不会产生想要的结果。

 

 

人员因为人才是最终使用新过程和实践的一方,所以他们的个性与工作习惯也必须在考虑范围之内。如果您的公司的成功是一群有独立意志的贡献者所做的话,那么引入一项需要大量合作的过程的话,这种组合很可能毁于交流不善良。

 

 

例程许多公司拥有大量的例程或者规范。特别是政府规划更是在这一中环境下进行的。定义良好的重大事件,需要正规的检查和大量格式正确以及准备充分的文件来支持检查。不强调例程以提高项目其他特征的实践,在这样的公司内将不会受到欢迎。

决定背景的其他因素取决于项目和公司。

 

定义成功

 

在您为您的公司和项目识别实践价值和背景之后,您仍然有一个最重要的问题要问:新实践或者新过程的最终目标是什么?换句话说,什么可以定义成功?

 

我认为“变得更加敏捷”并不是一个目标。因为它太容易了。今天许多的敏捷媒体文章对许多管理员和项目领导进行了狂轰滥炸。他们从开发员那里听到了关于敏捷的信息,这些开发员是在寻找书写代码更加省时的方法,而不是努力支持软件开发的其他方法。但是,努力变得敏捷并不是最终的目的。必须要有一个或者多大能够被认为是更改目标的可识别业务。

 

一旦您开始奋斗,您就可以问正确的问题了:“我们可以将什么样的实践,整合到与我们的价值相匹配的已存在的背景中去,这样我们的员工具可会积极的响应它,并最终到达预设的目标?”如果您的价值和背景指示一项敏捷位置的话,那么您就当然应该采用敏捷方法了。如我在上面所述的那样,项目规模的影响可以忽略。

 

 

 

应当重视的参考材料

 

我建议您要熟悉敏捷以及一些敏捷方法学,这样可以帮助您决定什么实践最能适合您的需求。据我看来,下面的书籍和网站将会给您一个关于这个问题的较好的原因。

 

Agile Software Development 2nd edition.: The Cooperative Game(《敏捷软件开发》第二版),Alistair Cockburn,Pearson Education,2007。Alistair Cockburn 对软件开发原则有一个广阔的视角。他定义了一系列的过程(他的 Crystal 家族),并分类了过程的应用性。该书为理解敏捷提供了一个好的基础。

 

Agile Software Development in the Large: Diving into the Deep(《大型的敏捷软件开发:深入研究》),Jutta Eckstein,Dorset House,2004。Jutta Eckstein 关注了怎样对大型的软件开发应用敏捷方法进行的咨询和研究。本书给出了她对大型项目应用敏捷方法,怎样达到这一点,以及怎样做到更好的观点。如果您要查看对大型的项目或者公司应用敏捷方法的话,那么这篇文章您就必须要阅读。

 

Martin Fowler 的网站,http://www.martinfowler.com/。我喜欢 Martin Fowler 的作品。在我看来,他和 Craig Larman 是软件开发方面的最好的两大学者之一。他们写的就是我想要读的。Martin 关于敏捷和 XP 的文章应该在您需读文章的列表上。

 

前面提到过的 Craig Larman,他的网站 http://www.craiglarman.com 是很有价值的。他的书,Agile and Iterative Development: A Manager’s Guide(《敏捷和迭代化开发:项目经理指南》),Addison-Wesley,2003,提供了四种方法学的精彩对比。在阅读这篇文章之后,您就会理解怎样去比较和对比其他的文章了。

 

结论

每一个专业的管理员和开发专业人士都想做的更好。现在敏捷方法看上去为一些小型团队和项目,提供了利益,这就让我们去思考,我们怎样让这种利益在更大的背景下仍然有效。方法就是首先关注想要的结果,然后决定什么样的实践将会最好,而不是在理解想要的结果之前去理解敏捷。

不管您做什么,如果可能的话,将您的实践建立在迭代开发的基础之上。很少有瀑布模型有效的情况发生。所有现代的方法都是建立在迭代,增值开发的基础之上。 9 使用这些作为一个基础,并添加与您的公司和项目文化相匹配的敏捷实践。

 关于作者:

Gary Pollice 是伍斯特市伍斯特工学院的一名实践教授,文学硕士。 他讲授软件工程、设计、测试以及其它计算机科学的课程,同时也指导学生设计。在进入学术界之前,他有 35 年多的开发各种软件的经验,从商业应用到编译器和工具。他的最后一份业界工作是在 IBM Rational 软件,他是有名的“RUP 倔老头”,同时也是最早的 Rational Suite 团队的成员之一。他是《小团队开发软件:一种以 RUP 为核心的方法》一书的主要作者,该书由 Addison-Wesley 于 2004 年出版。他在数学方面取得了学士学位,在计算机科学领域取得理科硕士学位。

作者:Gary Pollice

来源:IBM developerWorks