《项目管理心理学实战》之项目生命周期模型（三）

申请免费试用、咨询电话：400-8352-114

　　自适应模型是PMBOK第5版最新引进的，PMBOK把普遍流行的敏捷开发方法包含到体系中来了。项目管理者联盟

　　这种模型是针对原来的计划、设计、实施、测试、交付这样的流水线的工作模式的各种缺陷而提出的。其鼓励变革，反对机械的文档控制，反对教条的软件工程方法。这种方法的提出对于过去那些饱受项目管理部门折磨的技术人员来讲是一个福音，一经问世便得到了广大技术人员的追捧。所以在敏捷开始的时候，更像是一种程序员的宗教，其被追捧的狂热程度可窥一斑。而一些中小软件开发企业，因为被CMMI等重量级的体系实施的成本、周期和其复杂性所吓倒，从而转向这种轻量级的开发模型。最近几年，敏捷方法已经开始大行其道，好多原来的重量级的大型企业也纷纷引入这种方法。项目管理者联盟

　　那么这种方法为什么会得到普遍的认可?这其实也是软件企业一直以来面对的一种困惑，那就是，软件到底可不可以当做一个工程来进行管理?软件工程的提法到底是否合适?软件开发和传统行业最大的区别就是它可以把程序员的思想直接变成固化的代码，从而成为产品的一部分。这种把思想直接转化为人类使用的产品是人类以前除了创作艺术作品之外从来没有过的工作。人的思想如此复杂，难以量化和精确控制。所以连如何来衡量程序员的工作量这个在传统工程领域都称不上困难的事情在软件开发领域却都成了几乎无法完成的事情。从上个世纪50~60年代的软件工程危机开始，研究学者们一直试图通过工程的方法，把软件开发变成一个可以按照计划精确控制的行为。以此观点为中心开辟了软件工程这个学科，提出了许多种解决方案，但是都存在着各种各样的问题。我们熟知的软件产品，例如MS-Office、Visual Studio、Oracle数据库等，几乎没有哪个产品是在计划时间内完成的，延期半年完成都是十分常见的事情。而敏捷方法的提出，第一次从非传统工程的领域来看待这个过程。从软件本身的特点来看待这个问题。这在现在软件逐渐向移动终端转移，讲求碎片化、逐步完善的产品，“永远的测试版”的环境下，便迅速成为了主流开发方法。bbs.mypm.net

　　这种方法最初鼓吹不要规范教条的文档，不要机械严格的设计，不要板起脸吓人的规矩或者合同，要的是灵活性、用户的体验和良好的用户合作关系。但是如何解决软件中需求变化，程序员经验不丰富，质量难以保证的难题呢?这种方法其实一开始只是提供了几个技术上的解决方案。例如，采用软件重构方法来解决代码需要中途改动的问题，采用测试工具(JUnit)来解决质量问题，采用用户故事卡片来解决需求准确表达问题，采用用户关心的特性点来解决用户体验问题等等，其他还有许多类似的方法。这些方法在技术上已经有了现成的实现框架，例如Martin Fowler写的一本书《企业架构设计模式》堪称经典。受其影响，软件架构师成为了一种时髦职业。关于测试，更是有人提出了测试驱动的开发方法。可以说，这些技术的发展，反过来也深刻地影响了敏捷方法的推广。好多设计模式成为了程序员的常用词汇。例如，工厂模式、面向切片开发(AOP)、反转控制(IOC)等。项目管理者联盟

　　1 业务和管理项目管理者联盟

　　这里我们不妨从两个角度来看待这种方法。在项目管理中，一直有两个相互不同的视角在影响着项目。一个是管理本身的需要，那就是可以精确控制，我们姑且称之为管控视角。另外一个是项目的工作本身需要，我们不妨称之为业务视角。项目管理者联盟

　　管理者有个本能，那就是希望知道项目中发生的每件事情，例如工作效率怎么样，有什么错误产生，如果有可能，他们一定喜欢知道你现在心情怎么样，昨天睡觉睡得好吗?现在工作的“战斗力”是多少?成为管理者这个事实意味着他们心里永远有那种一切事情我都想知道，一切事情我都可以控制这样的冲动。所以，当管理者站在管理的角度上来看的时候，他们会认为所有那些报告文档都很重要，所有详细的计划都必不可少。例如质量计划、风险计划、沟通计划、评审报告和项目进展情况报告等。在那些控制要求比较高的领域，这种现象就会变得更为严重，例如，ISO9000。当管理者觉得需要在某个环节加一个控制点，来检验这个节点的状态，进行管理控制的时候，这里往往就会产生一个管理文档。作者曾经和许多公司高层管理者讨论过一套国家软件开发文档标准指南里面提到的文档需不需要在公司中采用，这套文档有72个。我惊讶地发现，凡是关于管控的文档他们的回答出奇地一致，那就是如果这个不需花费很多力气的话，那么最好还是采用这个文档。这就是管理者最本能的冲动。而传统的重量级的体系，往往就是站在这样的一种管控视角。因此，让广大技术开发人员深受其害。