UML软件工程组织

软件项目的“管理之痒”

在国内,不少做过几年程序员,被同事、圈内的朋友公认为技术水平不错的人,在考虑自身职业发展的时候,可能会想当然的认为:“我可以做项目经理了,感觉做个项目经理也没啥特别难的”。

但如果你真的有机会,去尝试带一个团队,哪怕是只有几个人的一个小TEAM的时候,你就会发现,你必须面对一系列的问题和麻烦,而这些事情的处理结果,基本上和个人技术水平无关。

举一些例子:

“自己每天被领导施压,忙忙碌碌,累得吐血,可手下的几个人,却让人觉得他们闲的发慌”。

“给他们布置的任务,好像怎么也做不完,一拖再拖,个人感觉是很简单的事情”。

“好容易分工做完了几个模块,整合起来却怎么都不对,老是出现错误,还得我自己亲自动手修改处理”。

“交给了客户一个测试的版本做展示,客户第一句话就是:这个不是我们想要的”。

“眼瞅产品交付的最后期限逼近,可软件的问题层出不穷,错误百出,这怎么能让客户满意并且验收签字呢?”。

“天天加班,把人搞得生理时钟失调,昼夜颠倒,做这个项目的人怨声载道,整天怒气冲冲,威胁辞职、罢工”。

……

在具体的软件项目运转中,这些令人头痛的问题接连不断,常常把人搞得焦头烂额,心烦意乱,任你技术水平再高,都没用。俗话说的好:“你浑身是铁,能碾几颗钉”。事必躬亲,大包大揽的结果只能是把自己累垮,工作还没做好。在软件越来越复杂,需求多变的情况下,个人英雄主义、单打独斗是行不通的,干活还得靠大家。

痛定思痛,你也会很聪明的想到:我必须使用软件工程方法、开发流程来管理我的团队。但你真的要在团队中套用上鼎鼎大名的CMM,更令人沮丧的事情还在后面:CMM中光是那一堆名词和文档,就够大家理解好久的了。而且,这些标准、指南更像是评分手册,可操作性不足。项目组好像整天在忙,老是开会,烦不胜烦,搞出一大摞文档,真正的软件却总是出不来。

还有不少其它的项目管理方法、指南,也是难以在实际环境中操作应用。

你必须找到适合自己公司团队的开发流程、框架,不仅要完整,而且必须有良好的可操作性,比较灵活,适应范围广泛。所以,向在软件项目管理上成熟、完善的公司学习,是个很有效的办法,能让你迅速掌握在项目管理上的各种方法和技巧,并且上升到理论水平。

在软件行业,微软公司的软件产品众多,产品线齐全。这个软件巨人在各个市场上取得的成功也是有目共睹,其软件项目的开发、管理过程也一直是大家很感兴趣的焦点。

笔者有幸参加了一次软件项目管理的培训,由微软中国顾问咨询部门的讲师主讲,为期三天,大有斩获。好多困扰已久的问题和疑惑得到了解答,有种豁然开朗的感觉。

课程内容是MSF-Microsoft Solutions Framework,微软解决方案框架,所谓MSF,就是微软公司定义的用于软件项目管理的一套完整的流程、方法。讲义是从英文教材翻译过来的,MSF的版本是3.0。你可能会觉得奇怪,怎么这个框架还有版本。嗯,没错,微软公司的讲师声称,当Visual Studio .net 2005发布的时候,会整合、携带MSF 4.0一起面市。

因为MSF自身也是根据软件产业环境,根据新的思想、新的理念、新的实际项目经验不断调整,不断演进的,并不是教条。如3.0版本的过程模型中,就比2.0版本多了一个称为部署阶段的过程。

MSF是由微软公司的全球产品组、咨询服务部门、信息技术部、微软的合作伙伴共同协作,分析、总结经过实践检验的正确经验,对比业界的方法,汇总而成,是关于“人和过程”的指南。它的特点就是实战性很强,对项目整个过程的指导很完整。而且,它是通用的体系,不管你用什么技术,做什么项目,都有可以参照的准则。

MSF主要包含了两套模型、三个准则。模型正好涵盖了“人和过程”:团队模型、过程模型。三个准则:项目管理准则、风险管理准则、就绪管理准则。

在讲师讲述团队模型的时候,很有趣,让我们5个人一组,分组做了一个让人印象深刻的实验。这也是这套课程的独到之处,讲师上课,并非照本宣科的讲,而是在学习过程中,穿插了多个实验和具体的项目实例,让大家在一个临时组织的团队中,体会理论的含义,加深消化理解。

这个实验并不复杂,就是模仿大家日常工作中最常见的、项目小组的结构化组织形式,小组包含一个“老板”,一个项目经理,多个团队成员。由“老大”发号施令,让项目经理指挥自己团队的人执行,然后看结果。等15分钟的时限过去,“老板”揭示“成果”,小组成员要当众发表感想。难以想象,平时我们认为那么自然的组织结构,竟然有这么多缺陷!

老板感言:我以为大家知道的事情,原来他们根本不了解,不知道,信息完全不对称。

项目经理:太累,不懂领导到底要啥。

团队成员:闲得无聊,不知道要干什么。对工作没有积极性,不主动。

这样的结果就是:领导和项目经理的个人能力,基本决定了项目成功的可能性。

然后大家开始分析为什么会这样,原因在哪里,于是就引入了MSF的团队模型。

当然这个实验模型为了突出问题,做了很多简化,但在实际环境中,这些缺陷是确确实实存在的。

MSF的团队模型中,分成了6个角色,这6个角色是:程序管理、开发、测试、发布管理、用户体验、产品管理。每个角色之间是平等的关系,没有上下级的行政差别。

这几个角色并非一定要和人一一对应,当你没有足够的人手时候,一些角色可以重叠,由一个人兼任,但开发不推荐和其它角色兼任,这是因为要保持开发的封闭性。

当你的团队人数众多,规模比较大的时候,可以把大团队划分成小团队,再由核心团队总揽。既可以按照软件功能、特性来分成功能团队,也可以根据职能划分,例如,程序管理角色有多个人担任。这充分体现了MSF非常灵活、务实的一面,适应性很强。可以用于几个人的小TEAM,也可以适用于规模很大的团队。

敏捷软件开发理论适应性就弱些,大家公认不太适合超过10人的团队组织,而且,对成员的要求更高。

在另外一个模型-过程模型里面,MSF敏捷的一面又显露了出来。通过把复杂的项目分成多个版本进行迭代开发,来充分的简化项目难度。每个版本都有自己要完成的功能范围,可以看成一个“小项目”,项目小了,复杂度、难度自然大大下降,当然成功的概率就高的多。而且,和项目相关的人能很快的评估项目成果,来决定项目的“下一版本”方向。

在每个项目过程中,都包含一个很完整的阶段,项目构思、项目计划、项目开发、项目稳定、项目部署。从项目构思到项目部署结束,每个环节都有很多的所谓“里程碑”成果。就是每个阶段都有很明确的要求,到底要拿出什么成果。而这些成果,是需要团队成员共同努力来取得的,正好和团队模型相互结合。

在项目的任何一个阶段,每一个团队成员都要有成果,大家是并行工作的。这样一来,就避免了传统组织方法的很多弊病,如开发没结束,测试难以进行。在这样的模型中,不再是一个上司发号施令,下面的人去被动执行,已经演变成了大家都能积极主动的参与进来,每个人都有事情可以做。不同的角色在不同的项目阶段,分别起到主导作用。

课程中还有一个很重要的MSF原则贯穿其中,那就是风险。所谓风险,简单的说就是事件有可能发生,但是不确定何时何地。

团队最早开始做的事情之一就是管理风险,我们通过分组,在课堂上模拟了一遍,很有意思。每个人根据实验要求,挖空心思,冥思苦想,想象在项目过程中到底会发生什么事情,判断可能性和后果。连团队成员怀孕,无法继续工作这种事情也被找了出来,戏剧性的是,一个学员就承认,自己的团队就遇见了这样的麻烦,而且还不知道到底应该怎么办。

管理风险的目的就是把握主动权,在风险发生的时候能迅速处理,从而保证项目能顺利进行下去。这样一来,客户会对我们更有信心,更信任我们,项目成功的可能性会进一步提高。

课程的后面,就是具体的项目执行过程了,如项目计划的制定、开发、稳定、部署等等。其中不乏精彩的观点和指导方针,让你有法可依。
这就是我在MSF培训结束后的体会和总结。

理论和实践从来都是相互交织的,没有理论,做事情就没有章法,没有后劲。缺乏实践,理论就变得十分空洞,陷入空谈。你必须把理论不断的应用于项目管理实践,才能不断的成长、成熟。


版权所有:UML软件工程组织