艾伟也谈项目管理,项目管理利刃之MSF

简介:   MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。  本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理、开发工程师、系统架构师、顾问、质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助。

  MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。

  本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理、开发工程师、系统架构师、顾问、质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助。

  MSF为成功地规划、设计、开发和部署IT解决方案提供了一套成熟的方法论。与具有固定框架的方法相反,MSF提供了一个可以伸缩的灵活框架,以满足任何规模的组织或者项目开发团队的需要。MSF指导由原理、模型和用来管理人员、项目和技术元素的准则(大多数项目都会碰到)组成。MSF模型本身来源于微软公司在大规模软件开发和服务操作项目上的宝贵经验积累,来自于微软公司的顾问在为企业客户实施项目时所获得的经验,以及融合了来自于全球IT行业的先进理念,最终形成的一套方法论。

  MSF为软件开发团队提供了一套可自定义、具有良好扩展的软件开发指导原则。MSF包括既灵活又具有逻辑的方法,允许软件开发团队中的成员使用这些方法选择最适合的方式完成个体的任务。采用MSF灵活的框架可以满足任何软件开发项目的需求,同时不必考虑项目的大小与复杂性。根据MSF的实现理念,没有一个单独结构或流程可以非常好地适用于所有项目的需求和环境。

  MSF框架于1994年被首次提出,最初被提出来是因为微软顾问咨询部门为了微软公司的一个产品开发项目提供项目管理咨询服务而产生的一套理论。从那时起,MSF开始逐步发展,这来自微软公司的产品组、微软服务中心、微软公司的内部操作和技术组(OTG)、微软公司合作伙伴和客户那里成功的和实践的最佳做法。MSF是基于一整套成熟的软件管理方法论,并融合了微软公司在IT行业内超过25年的项目周期管理经验。MSF框架中提供的方法论被设计帮助Microsoft的顾问、合作伙伴和客户来解决技术生命周期过程中碰到重大挑战。

  MSF使用这套经过内部和外部检验的真实最佳做法,并对这些其中部分方法进行简化、整理和检查,使得MSF具有更广泛的通用性,以便更多的合作伙伴和客户理解和采用。MSF由Microsoft里一个专门的产品小组在管理和开发,它同时还得到了国际顾问理事会该方面专家的指导和评论。MSF目前还在继续吸收微软公司当前的经验。同时微软公司在其发布的开发平台VisualStudio2005中提供了实现MSF的基础工具支持,VisualStudio2005已经不仅仅是一个开发的平台,更是强大一个软件项目团队管理和软件生命周期管理的工具。

  MSF的核心有八个基础原理,本文中将对几个和团队管理结合比较紧密的原理进行分析。

  推动开放式沟通

  在一些项目开发过程中经常会遇到这样的问题,项目开发周期较短工作量却很大,开发人员开发出来的软件和最终用户的需求在功能上吻合度很高,但是最终用户却觉得这个不是他们想要的软件。实际上这是交流与沟通的问题,项目的开发人员在时间紧迫的情况下,往往是只看到眼前的工作,而忽略了与团队成员及最终用户的沟通,结果就是从功能上完成了工作,但是软件产品或解决方案的易用性大打折扣,导致最终用户觉得最终提交物与他们的预期相距甚远。

  在一些国内的大型软件项目开发中,很多情况下是项目组成员可能根本都不在一个城市,他们有的来自于总部的研发中心,有的来源于测试中心,有的在遍及全国各地的各个实施地点负责具体实施,有的可能以顾问的角色参与到项目中来,这样就要求整个团队有一个良好的沟通方式,保证项目的顺利进行。

  软件项目和信息类解决方案都是由人的活动来构建和交付的。从事软件项目的每个人都会给项目组带来自己的智慧、能力和观点。为了将开发团队中成员的个人效力最大化,同时优化其工作效率,团队成员的交流和沟通就显得尤为重要。如果在客户和开发团队之间或团队成员之间没有一种很好的沟通形式,那么团队成员就无法有效地完成其任务,或是不能找到最正确的方法来完成任务。随着项目规模和复杂性的增加,对开放式沟通的需要就变得更加紧迫。完全基于开发团队内部个人意志的工作成果可能导致软件产品的缺陷,以至于削弱软件产品的可用性,甚至会产生软件产品本身的缺陷。

  MSF框架中最重要的一个基础的原理就是倡导团队内部和最终客户之间的沟通,团队成员之间的协作是项目进程中最重要的环节,MSF推出了一种开方式和包容式的沟通方式,既最大限度了团队成员的智慧和创造性,同时也在宏观上保证项目朝着正确的目标前进,并且能够符合诸如时间约束和特殊环境等条件的限制。很多可能在最终提交产品时候发现的问题,可能都会因为增强团队成员的沟通而及时发现和改进,这样不仅最大程度上降低了项目的风险,同时也提高了团队的协作能力。

  为共同的前景而工作

  在国内的软件行业中,多数的一线技术人员往往都是技术领域的专家,但是同时也缺乏对项目大局观的把握。他们知道如何正确的使用技术来完成自己当前的工作,却对项目的共同目标缺乏认识。这往往会导致软件项目在一致性上的不足,也会影响团队的协作。而项目的领导者通常是对团队成员的具体工作进行了布置和安排,但是忽略了对团队成员大局观的培养。
  项目经理在对开发人员布置任务的时候,通常要讲“你只要把某某功能实现就可以”,“你的程序要达到一个很高的稳定性和效率”,但是至于实现该项功能在整个项目中的作用,程序的稳定性直接关系到项目的哪些模块的稳定程度,都是没有最终传达给开发人员。这些都导致了团队成员缺乏对项目共同前景的了解。共同的前景是MSF小组和过程模型里的一个关键组件,它强调团队成员理解项目目标的重要性。当所有的参与者都理解了共同的前景并为之而工作的时候,他们才能清楚的认识到自己所做的工作在项目整个生命周期中的作用,进而调整自己的决定和工作重点。MSF过程模型中特别强调要求有一个共同的前景存在,以便指导解决方案朝着最终的业务结果前进。

  保持灵巧,预测变化

  很多项目经理或是团队的领导者经常犯的一个错误就是过于理想化。例如在做计划的时候将工作量估计的太过保守,殊不知团队中的成员有可能因为各种各样的其他原因不能在计划的时间中全部投入到项目中,或是最终用户的需求临时发生更改,所做的项目计划缺乏足够的灵活度,导致的结果就是项目计划抵御不了突然的外部条件变化,当这种变化真正发生时一切都已为时过晚。

  传统的项目管理方法和“瀑布”式的解决方案交付过程模型会假定某一层次或项目的某一个进程的可预测性,在软件项目中这样的假设是不可行的。常见的情况是,很多项目因为实现的预测没有成为现实而导致项目的进程受阻。软件开发项目本身就是一个创新的过程。在这个过程中有很多的未知因素是不可预测的,解决方案必须顺应新的变化。在面对这种不确定性的时候要假装或者要求确定性(至少)将会是不现实的,或者(至多)是不正常的。MSF主张软件项目的混乱有序的本质。它的一个基本假设是,连续的变化应该能够被预计到,而软件项目本身就是与这些变化分不开的。例如,它认为项目的一些计划可能从一开始就很难说清,而且会随着项目进展会越来越难以预测。

  MSF已经将其小组和过程模型设计成能够预计和管理变化的形式。MSF小组模型通过在关键决策中实现所有小组角色的参与从而加强了处理新挑战的灵巧性,因此确保了从所有重要的角度去探索和审查这些问题。近几年来,产生了一些开发软件的专门方法,这些方法致力于将灵巧性的原理和为变化而做好准备的原理最大化。有了这一理念,MSF会鼓励在合适的地方应用这些方法。

  质量投资

  在国内一些规模不是很大的开发团队中,质量管理投资往往是没有被重视起来,原因可能是多方面的,项目时间紧张,人员紧张,调配不出更多的人员来进行专门的质量保证工作,但是其中最重要一条是团队的领导者对质量管理投资的重视程度不够。必要的质量投资会为项目的实施与正式上线之后节省很多成本,而且质量投资是随着项目的进展一直进行的。

  MSF团队模型要求团队里的每一个人都要对质量负起职责,同时承担起测试过程管理的角色。测试角色会鼓励团队在项目期间进行必要的投资,以确保最终交付的软件产品或解决方案质量水平能够满足期望。在MSF过程模型里,由于项目交付内容是逐步生产和审查的,所以测试就成为了质量的一部分。该模型定义了关键里程碑,并提出了中间里程碑,供测试角色和相关角色使用团队建立的质量标准对解决方案进行量化的测试。在软件项目进行的过程总,不断的对这些里程碑进行检查可以确保对质量的不断关注,并为在必要的时候进行中途的修正提供机会,避免风险,提高项目最终成功率。

  技术的提高让一个团队获得了更大的发展潜力。大多数团队都依靠技术本身来实现提高,而一个真正优秀的团队的闪光点不仅仅在于技术的领先,还在于怎么样将优秀的技术转化为生产力。

  MSF框架有助于指导团队来实现这种转换,完成自我提高。通过使用MSF框架对软件项目管理进行重新定位和规划,软件开发团队不仅仅获得是生产力的提升,同样可以获得团队整体水平的提升,团队成员之间形成一种良性的协作习惯,在项目周期管理上获得共同的价值观,保障项目开发的顺利进行。这一切都会形成一种良性循环,周而复始,软件开发团队的整体水平积累了从量变到质变所需要的资本。

  但是,在项目团队里使用MSF是一项要求相当高的计划,它需要团队领导的大局观和周密的规划,同样需要团队成员对MSF理论的深刻认识,同样需要一种机制来保证新的团队管理方式的推行顺畅。而MSF框架的使用也会为团队带来活力与战斗力,有利于团队精神的发扬和延续,不仅仅是项目管理水平的提升,更有利于团队知识管理框架的建立,积累宝贵的项目管理经验。

  实际上,软件开发项目不仅仅是为了给最终用户交付一个可以运行的软件产品或是解决方案,更深层次的成功则是通过一个有一个项目的开发,团队能够得到知识积累和成熟工作模式的形成,这已经超出了项目管理的范畴,提升到软件企业管理的层次,只有企业内部的所有软件开发团队都朝这个方向努力,才能真正为企业带来知识积淀和持久的生命力。

  MSF经验知识库主要内容

  ◆企业结构设计方案—采用交互的方式,侧重于制定长期规划,同时也能完成短期目标。
  ◆项目开发准则—包含组队模型和过程模型,用于建立高效的项目组,管理项目的生命周期。
  ◆项目设计过程和多层结构的应用程序模型—用于支持设计复杂的分布式企业应用。
  ◆企业信息基础设施的实施方法—使用组队模型和过程模型支持实现、操作和技术上的方案。

  MSF三个关键的成功因素
  ◆一种帮助提供技术决策指南的观点。
  ◆一组反复跟踪、监控和管理项目及其进展的参考方法。
  ◆一致的重用性保证在灵活的计算环境中有效的利用已有的知识和技能。

目录
相关文章
|
自然语言处理 监控 项目管理
PMP项目管理引论介绍 1
PMP项目管理引论介绍
99 0
|
监控 项目管理
PMP项目管理引论介绍 2
PMP项目管理引论介绍
65 0
|
监控 数据挖掘 BI
项目管理PMP过关总结
经过近两个月的漫长等待,昨日终于成功上岸。由于去年受疫情影响,本来原定于去年11底的PMP考试延期到了今年3月才进行考试。在获得结果后的第一时间,趁着还有些许记忆,准备分享下整个PMP一路下来的心路历程。
199 0
|
测试技术 项目管理
艾伟也谈项目管理,项目做完了,总结一下
  在连续封闭N个月以及再后来的N个月的加班后,项目终于以延期N个月的结果结束了。不管曾经发生过什么,不管项目是否延期,重要的是项目结束了,所有的项目成员都可以松一口气了。曾经和同事开玩笑说:在我经过过的失败项目中多了一个项目,以后就能避免同样类型的失败了。
1023 0
|
测试技术 项目管理
艾伟也谈项目管理,大项目的思考
  引言:进入现在这个我们内部号称“豪门”的项目已经两个多月了。现在回想起进入项目前一位前辈的话:“大项目有大项目的问题,但大项目也有很多东西可学“,自己此时深表赞同。两个月的时间,自己从刚来前两周的观察学习,到现在的基本融入,在这个过程中自己有了很多的想法和思考。
952 0
|
项目管理
艾伟也谈项目管理,技术管理中常见的几个问题
  前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题。
988 0
|
程序员 项目管理
艾伟也谈项目管理,较大型项目的产品工作心得
  最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。   立项前   1、统一元素设计需考虑周全   也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
1294 0
|
项目管理
艾伟也谈项目管理,项目经理要向唐骏学习
  中国人性喜围观,然而在中国,大部分新闻并没有围观的价值,这未免让人失望。但是,只要是加上“唐骏”这个名字,新闻总是能让我们围观者觉得值,觉得得到某种满足,从这一点上来讲,唐骏牛!真的很牛!!   这一次,唐骏给大家带来的是“假文凭事件”,整个事件的发展,真是一波未平一波又起,可谓波澜壮阔,最后发展成为事关“诚信”的大事件。
1025 0
|
测试技术 项目管理
艾伟也谈项目管理,基层管理杂谈
  几乎每种行业都有基层主管(或基层管理人员),而软件行业的基层主管一般是项目经理、技术经理、开发经理、组长等。其职责是资源协调、风险预估、项目管控、团队建设,说白一点大多数的企业现状就是项目负责人带领团队攻下一个又一个项目的过程。
1074 0
|
项目管理
艾伟也谈项目管理,我的项目管理观点
公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面。我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得。
1032 0