自适应软件模型——敏捷模型

　　将变化进行到底——自适应模型

　　这是PMBOK第五版最新引入来的一种模型，这是PMBOK把普遍流行的敏捷开发方法包含到体系中来了。

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

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

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

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

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

　　业务视角则不同，这个视角完全是站在实际工作需要的角度上进行。例如项目的设计文档，需求文档，无论是不是以文档的方式表现出来，但是没有这些工件是不可能完成项目的。这些文档就成为业务视角上的文档。而技术开发人员反感最大的往往就是那些管控文档。业务视角文档，因为是工作所必须，所以他们不会产生多大的抵触情绪。

　　这两种视角之间的矛盾也会体现在某个具体的文档中，管控的要求文档要面面俱到，业务的角度要求满足业务要求即可。所以在公司中，大量的技术人员在填写文档的时候往往就会出现为了填写文档而到处拷贝。或者把原来的文档进行修改交付了事。

　　知道了这两种视角的差别，也就深刻的理解了在实施这种自适应开发方法过程中，不同的人所持的心理态度。

　　管理者们总有管控的需求，因此永远希望过程可视化。技术开发人员则更希望抛弃这些影响，只做和业务直接相关的文档编写。以下的几个心理学技巧，可以根据情况参考使用。

　　1、在实施的时候，为了避免一味的关注小块功能的开发而失去了整体的协调，可以在开发空间悬挂一个整个模块的逻辑图形，把不同模块按照完成程度画上不同的颜色。

　　2、团队中完全可以照搬小组软件开发过程(TSP)方法，建立公共角色，鼓励共享，形成人人为我，我为人人的文化氛围。要注意这种文化氛围的建立关键点在于第一步，就是如何让每个人感觉到了他收到了其他人的帮助。这一步需要管理者人为的设计。

　　3、和语言口号相比，图形更有说服力。如果你想让项目小组成员更关注用户的需求和体验。你可以借鉴用户中心设计(UCD)的一些方法。

原文转自：http://blog.sina.com.cn/s/blog_43ec0f600101q4sq.html#bsh-24-248512253