|
将变化进行到底——自适应模型项目管理者联盟
自适应模型是PMBOK第5版最新引进的，PMBOK把普遍流行的敏捷开发方法包含到体系中来了。项目管理者联盟
这种模型是针对原来的计划、设计、实施、测试、交付这样的流水线的工作模式的各种缺陷而提出的。其鼓励变革，反对机械的文档控制，反对教条的软件工程方法。这种方法的提出对于过去那些饱受项目管理部门折磨的技术人员来讲是一个福音，一经问世便得到了广大技术人员的追捧。所以在敏捷开始的时候，更像是一种程序员的宗教，其被追捧的狂热程度可窥一斑。而一些中小软件开发企业，因为被CMMI等重量级的体系实施的成本、周期和其复杂性所吓倒，从而转向这种轻量级的开发模型。最近几年，敏捷方法已经开始大行其道，好多原来的重量级的大型企业也纷纷引入这种方法。项目管理者联盟
那么这种方法为什么会得到普遍的认可?这其实也是软件企业一直以来面对的一种困惑，那就是，软件到底可不可以当做一个工程来进行管理?软件工程的提法到底是否合适?软件开发和传统行业最大的区别就是它可以把程序员的思想直接变成固化的代码，从而成为产品的一部分。这种把思想直接转化为人类使用的产品是人类以前除了创作艺术作品之外从来没有过的工作。人的思想如此复杂，难以量化和精确控制。所以连如何来衡量程序员的工作量这个在传统工程领域都称不上困难的事情在软件开发领域却都成了几乎无法完成的事情。从上个世纪50~60年代的软件工程危机开始，研究学者们一直试图通过工程的方法，把软件开发变成一个可以按照计划精确控制的行为。以此观点为中心开辟了软件工程这个学科，提出了许多种解决方案，但是都存在着各种各样的问题。我们熟知的软件产品，例如MS-Office、Visual Studio、Oracle数据库等，几乎没有哪个产品是在计划时间内完成的，延期半年完成都是十分常见的事情。而敏捷方法的提出，第一次从非传统工程的领域来看待这个过程。从软件本身的特点来看待这个问题。这在现在软件逐渐向移动终端转移，讲求碎片化、逐步完善的产品，“永远的测试版”的环境下，便迅速成为了主流开发方法。
这种方法最初鼓吹不要规范教条的文档，不要机械严格的设计，不要板起脸吓人的规矩或者合同，要的是灵活性、用户的体验和良好的用户合作关系。但是如何解决软件中需求变化，程序员经验不丰富，质量难以保证的难题呢?这种方法其实一开始只是提供了几个技术上的解决方案。例如，采用软件重构方法来解决代码需要中途改动的问题，采用测试工具(JUnit)来解决质量问题，采用用户故事卡片来解决需求准确表达问题，采用用户关心的特性点来解决用户体验问题等等，其他还有许多类似的方法。这些方法在技术上已经有了现成的实现框架，例如Martin Fowler写的一本书《企业架构设计模式》堪称经典。受其影响，软件架构师成为了一种时髦职业。关于测试，更是有人提出了测试驱动的开发方法。可以说，这些技术的发展，反过来也深刻地影响了敏捷方法的推广。好多设计模式成为了程序员的常用词汇。例如，工厂模式、面向切片开发(AOP)、反转控制(IOC)等。项目管理者联盟
1 业务和管理项目管理者联盟
这里我们不妨从两个角度来看待这种方法。在项目管理中，一直有两个相互不同的视角在影响着项目。一个是管理本身的需要，那就是可以精确控制，我们姑且称之为管控视角。另外一个是项目的工作本身需要，我们不妨称之为业务视角。项目管理者联盟
管理者有个本能，那就是希望知道项目中发生的每件事情，例如工作效率怎么样，有什么错误产生，如果有可能，他们一定喜欢知道你现在心情怎么样，昨天睡觉睡得好吗?现在工作的“战斗力”是多少?成为管理者这个事实意味着他们心里永远有那种一切事情我都想知道，一切事情我都可以控制这样的冲动。所以，当管理者站在管理的角度上来看的时候，他们会认为所有那些报告文档都很重要，所有详细的计划都必不可少。例如质量计划、风险计划、沟通计划、评审报告和项目进展情况报告等。在那些控制要求比较高的领域，这种现象就会变得更为严重，例如，ISO9000。当管理者觉得需要在某个环节加一个控制点，来检验这个节点的状态，进行管理控制的时候，这里往往就会产生一个管理文档。作者曾经和许多公司高层管理者讨论过一套国家软件开发文档标准指南里面提到的文档需不需要在公司中采用，这套文档有72个。我惊讶地发现，凡是关于管控的文档他们的回答出奇地一致，那就是如果这个不需花费很多力气的话，那么最好还是采用这个文档。这就是管理者最本能的冲动。而传统的重量级的体系，往往就是站在这样的一种管控视角。因此，让广大技术开发人员深受其害。blog.mypm.net
业务视角则不同，这个视角完全是站在实际工作需要的角度上进行。例如项目的设计方案和需求分析无论是不是以文档的方式表现出来，如果没有这些工件是不可能完成项目的。这些文档就成为业务视角上的文档。而技术开发人员最反感的往往就是那些管控文档。业务视角文档，因为是工作必需的，所以他们不会产生多大的抵触情绪。项目管理者联盟
这两种视角之间的矛盾也会体现在某个具体的文档中，管控要求的文档要面面俱到，业务的角度要求满足业务要求即可。所以在公司中，大量的技术人员在填写文档的时候往往就会出现为了填写文档而到处复制。或者把原来的文档进行修改交付了事。项目管理者联盟
知道了这两种视角的差别，也就深刻地理解了在实施这种自适应开发方法过程中，不同的人所持的心理。项目管理者联盟
管理者们总有管控的需求，因此永远希望过程可视化。技术开发人员则更希望抛弃这些影响，只做和业务直接相关的文档编写。以下的几个心理学技巧，可以根据情况参考使用。training.mypm.net
(1) 在实施的时候，为了避免一味地关注小块功能的开发而失去了整体的协调，可以在开发空间悬挂一个整个模块的逻辑图形，把不同模块按照完成程度画上不同的颜色。项目管理者联盟
(2) 团队中完全可以照搬团队软件开发过程(TSP)方法，建立公共角色，鼓励共享，形成“人人为我，我为人人”的文化氛围。要注意这种文化氛围的建立关键点在于第一步，就是如何让每个人感觉到他收到了其他人的帮助。这一步需要管理者人为的设计。项目管理培训
(3) 和语言口号相比，图形更有说服力。如果你想让项目小组成员更关注用户的需求和体验。你可以借鉴用户中心设计(UCD)的一些方法。club.mypm.net
2 虚拟用户的方法项目管理者联盟
这种方法要求你在项目需求采集的时候，和自己的团队为自己项目的最终用户虚拟未来的用户人物。PgMp.mypm.net
人物要有足够的代表性，可以是现实人物的翻版，也可以是几个人物性格的综合。项目管理者联盟
为这个人物取一个名字，注明年龄、性别和职业等。为了让人物更加真实，你可以编写一段此任务的传记。在网上搜索一个相关的头像，建立人物的相关档案。club.mypm.net
下面是一个例子，你可以参考。姓名：王志强项目管理者联盟
英文名字：David Wang
出生日期：1978年12月项目管理者联盟
座右铭：勤能补拙!项目管理者联盟
职务：信息中心主任项目管理者联盟
个人简介：项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
