1 简介
现在,即使在IT预算被大幅度地削减的情况下,IT管理人员的压力仍然在不断增大。同时,业务环境正以非常高的速度持续改变,这使IT艰苦奋斗,以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又高质量的维护为承诺”的敏捷软件开发方法论产生了很大的兴趣。
敏捷方法(XP、SCRUM、Feature-Driven Development)努力在软件开发过程当中减少变化带来的成本。例如,XP使用快速迭代计划和开发循环尽早地产生最有价值的特性。另外,XP中的持续的、系统化的测试确保高质量,尽早发现缺陷和相应的解决方案。
尽管敏捷方法带来了早期的一些成功案例,但还是有很多因素阻碍它们被广泛采纳。敏捷方法的倡导者经常发现:在应用开发中,对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式。例如,XP实践中的结对编程、TDD、持续集成以及on-site 客户代表等是很难让人接受的。而且,这些方法论更倾向于以开发者为中心,似乎并不太重视管理角色。
然而,实践证明,加强管理是敏捷方法被成功采纳并应用的关键,而传统项目管理方法学和工具与这些新的敏捷方法缺少关联。而这种低关联性就是深层次问题的症状。这些深层次问题表现在:对于处理变化、控制、命令、组织、人员以及解决方案等方面的基本假设方面的不同。传统管理理论假设:
l 管理变化是需要严格过程的
l 分层级的组织结构是建立秩序的途径
l 加强控制可以得到更好的秩序
l 在“项目组”这个机器中,人员是可以互换的“零件”
l 问题主要是通过任务细分来解决
l 通过事前详细复杂的计划可以对项目和风险进行充分的预言,并被管理
在这个上下文环境中,新方法论所表现出来的无序性、平等性和解决问题的无方向性就没有什么奇怪的啦。在这种传统管理与敏捷开发方法论之间的不重合性中,敏捷方法会被逐渐采纳。同样,这些假设的变化和敏捷方法过程中新的管理框架也是非常重大的需求。
在寻找这种新框架的过程中,我们强烈地认识到:出现了基于“复杂性理论”这个新学科的
管理原则。
“复杂性理论”这个新学科实际上在对现存系统进行研究的过程中产生的,它主要是探寻对人类自治行为的理解。
.
尤其是,我们已经开始将一种复杂适应系统(
CAS
)的概念融入到我们的管理假设与最佳实践中。
“
复杂性理论”的科学家已经研究了现存系统中的集体化行为,如鸟群、鱼群、蚁群和蜂群。他们发现,当这些复杂适应系统中的个体拥有局部的战略原则和能力时,它们的集体化行为比个体的总和表现出更完全的秩序化、自组织性和更高的智慧性。这种CAS理论被成功地应用于经济和生命科学,现在也被用于管理方面。
这种CAS的概念使我们产生一种灵感:在XP团队中,项目经理也需要一系列的简单的指导实践来提供一种框架,并在这种框架下进行管理,而不是一系列的严格的指令。根据这此实践,管理者成为一名适应性领导者--确定方向、建立简单的产生式的系统准则,并鼓励持续反馈、适应性改变和协作。这个管理框架为团队提供一系列的内容来实现敏捷方法论,这些内容包括:
l 在团队管理中,组员是熟练地有很高价值的stakeholder
l 自治性团队的集体能力是解决问题的基本机制
l 在不可预言的假设面前尽可能地使事前计划最小化,而加强适应变化的能力
2 问题:作为传统的任务分配者所面对的项目管理
传统软件生命周期开发方法论的产生是因为我们要控制不断增大的开发项目,以及对产生可靠的产品的工作量的评估和管理。这些方法论来源于建筑工程管理中的一些原则。结果,它们是强调可预言性的(在建一座桥时,工程设计师必须设计桥的每一个细节),并且是一个线性开发周期(即需求、分析、设计、开发)。根据这种可预言性,它们沿用了确定性的简化了的方法,这些方法依赖于任务分解,并且是基于稳定性的(即稳定的需求分析和稳定的设计)。作为项目控制的一个手段,这种刚性表现为顺从性。
在过去,一些公司使用这些方法,并且现在也可能在使用。对于许多来说,这些方法论只是增加成本和复杂性,却给人们一种错误的安全感――管理就是通过详细的计划、度量和控制来做事。巨大的成本被过早的计划浪费了。我们认识到快速的迭代式开发和从用户那里得到不断的反馈是今天项目达到成功的前提。
下面这个例子被公认为是原有方法论失败的代表案例:“伦敦救护系统”和“但佛航空行李系统”,巨大的成本超支和拖期。让我们来看一下
Standish组织关于CHAOS的调查。在第一次调查中,成功项目
18
%,
31
%失败,
53%
挑战。在
1998
年的调查中有所提高,但也是
26
%成功,
46%
挑战,
28
%失败。研究还表明,在成功的这些项目中,它们的项目大小都控制在使用小团队就可以完成的级别上。这个结果很明显与敏捷方法论的原则一致。而且,我们还发现,很多已经确立的项目管理实践仍可应用于敏捷开发项目,只需要进行一些适应性改变并加强对其进行领导就可以达到。
当管理者在使用传统方法论努力控制项目时,技术社区开始用敏捷方法来对付传统管理带来的挫败以及对他们的产品品质和士气所带来的影响。例如,那时的XP就几乎完全聚焦于开发过程。当技术社区支持这些实践时,却很少涉及敏捷开发项目的管理方面。这就暗示着:由于XP团队开发并管理他们自已的任务,对于项目经理的需求就很小。这并不奇怪,公司管理一直怀疑敏捷方法,不太接受它们。管理者希望着一种场景出现:满屋子的开发者做着他们各自的事情。。。。
而“eXtreme”这个词并没有什么意义。
抛开具体的方法论,传统的项目经理经常是作为制订并控制主要计划的人,这些计划详细地描述了任务、它们之间的依赖关系以及为完成最终产品而必须的资源。然后,项目经理监控任务的状态,对计划进行必要的调整。这种做法是建立在这样的假设基础上的,即组员是可以互换的个体,就象同一型号的螺丝。
所以,对于熟悉传统方法论的经理,是很少有勇气在他们的项目中使用敏捷方法的。但这也不是必须的。事实上,敏捷方法的独立性使管理社区和技术社区在项目管理中趋于同一个焦点。
3 答案:做为愿景领导者的项目经理
最好的项目经理并不只是组织者(
organizers
)-他们使业务愿景、沟通能力、软管理技巧和技术头脑与他们的计划能力、协调能力和执行能力相结合。从根本上说,他们应该是领导者
(leaders)
。敏捷项目管理要求更高的领导技能。
例如,
XP
团队在与客户的协作中,创建并监控他们自已的迭代计划。当
XP
团队工作时,对每一次迭代结果(等时长迭代)进行度量,并根据需要与用户一起调整计划。那么,如果项目不再需要一个详细的项目计划时,为什么还要项目经理呢?
因为每个项目都需要一个领导者(
leader
)。敏捷方法把项目经理从工头的位置上解放出来,使项目经理可以专心作一个领导者(
leader
),把主要精力放在项目愿景上,激发团队勇气,促进团队协作,排除项目过程中的障碍,使项目开发过程顺利进行。项目经理不仅是项目运作的控制者,更应该成为适应性领导者――如果他放弃对旧风格的管理方式的依赖。
敏捷开发项目的基本阶段与其它项目没有什么不同。项目经理还是必须定义和初始化项目,作项目计划,执行计划,监督并控制结果。但是完成这些步骤的方式却是不同的,需要项目经理去采用新的思考方式进行管理――思考
CAS
。
4 指导原则:团队是一个复杂适应系统
象前面提到过的,传统的命令&控制的管理方式大部分来源于泰勒的“科学管理”原则。泰勒的“科学管理”原则是基于十七世纪牛顿的观点,即世界可以看作是一个巨大而且有序的“时钟结构世界”,由大自然的经典法则所管理。科学管理被认为是20世纪在发达国家中可以把体力劳动(Working masses)提高到新的富足水平的主要动力。
然而,今天我们在团队中使用C&C管理的过程中遇到了麻烦。因为体力劳动已经被知识工人(Knowledge worker)所取代。例如,在软件业中,对于他们的老板来说,熟练的软件开发人员比他们的经理更有价值。在Taylor那个时代,管理者是来解决知识难题的。 而在我们的时代,解决知识问题的关键是知识工作者,而不是经理。所以,我们如何采用项目管理技术去处理这个关键问题呢?
科学世界已经变了。牛顿以后的两个世纪中,他的理论在很多其它的学科中也找到了广泛的适应性。科学界后来的发现(从爱因斯坦的相对论到量子论)在很多学科中开始取代牛顿的观点。实际上,新的科学理论“复杂论”现在已经开始改变传统的管理方式。
过去的二三十年里,科学家已经在很多领域发现了这样的系统,并去探索其共同的属性,去解释复杂现象。他们已经发现,很多自然系统(大脑系统、免疫系统、生态系统、社会系统)和很多人工系统(并行分布式计算系统、人工智能系统、人工神经网络)以复杂行为为特征,这种复杂行为是在它们组织的不同层次上,各组成系统交互的结果。
在自然界,这些结论被用于解释活的系统(如鱼群、鸟群等)的群体行为,而这些群体中会有某个个体拥有特殊的原则和能力,他们的群体行为就会以这种全序、自组织和集体智慧为特征。另外,这些系统常常表现出不平常的适应复杂的动态环境的能力。
总而言之,复杂性理论包括一些有生命特征的系统的基础思想:
l 有生命特征的系统是复杂的,他们由多个个体组成,并以多种方式进行交互
l 个体的交互以简单性、局部性为原则
l 系统中的个体之间的丰富交互使系统作为一个整体进行自发性的自组织,并伴随着系统自身产生的复杂有序性,而不是由外界强加于系统。
l 这些复杂、自组织的系统是适应性的,因为在不同的环境下会有不同的反应。
l 整个系统表现出那个领导者的个体行为
l 这些系统会和他们所在的环境一同进化(环境的变化引起他们行为的变化,他们行为的变化反过来会引起环境的变化),并达到一种新的平衡。当达到一定的变化后,又引起新的平衡点。
如果我们把我们的团队看作一个复杂适应系统,那么CAS的相关知识就可以应用到我们新的管理哲学中。特别是传统项目管理的规则可以被变化后用于新的CAS模型。