:华为的IPD,我在朋友的电脑上也看过这个资料

IPD – 集成产品开发,华为花重金从IBM购买的一套产品集成开发流程,业界有一本书,PACE讲的就是这一套IPD流程,而IPD并不去讲你的开发要怎么做,IPD做的就是“投资决策、市场驱动”,更多的是决定做不做这个事情,做这个事情对于投资人员是不是受控的,所以在IPD里面会有DCP点(决策评审点),每个点上都会去考虑该不该做、值不值得去做,在引入这个东西以前,华为实际上是技术驱动的,并不是市场驱动的,就是说以前华为听说有个新技术,然后就开始做,做了很多这样的东西,但是后来都卖不出去,所以后来就引入了IPD,以市场驱动。在引入IPD后,是解决了做什么的问题,但是怎么做,还是按照自己的想法去做,后来就引入了CMM,引入CMM后对华为确实起了非常大的作用,其产品开发的质量确实是比起前提高了,所以在前几年,通过IPD+CMM使得华为走向了一个非常成熟的过程。在这个基础之上,关于质量管理、项目管理华为提出一些自己的体系,比如从项目的开始到项目的结束,有项目review、度量分析、根因分析、缺陷预防等一系列活动,在项目管理方面有风险管理、问题跟踪管理等活动,同时还会有质量审计以及相关的推动等事情,通过这些项目管理和质量保证使得IPD和CMM很正常的运作下去,但是现在行业已经发生了一些变化,比如需求变化快等方面华为也碰到了一些问题,以前产品质量是可控的,大多数产品的发布周期也是稳定的,比如对客户承诺什么时间提交产品基本上是有保证的,另外项目在管理层的进展也是非常清晰化的,你在向某某领导汇报的时候只用告诉他比方项目到了SRS阶段了,基本上这个项目的老大就知道这个项目还有多少事情需要去做,比如告诉他到单元测试阶段了,他就知道快搞定了,这样确实使得这个进展能够口头化。其实,流程存在的价值,就是能够给我们的管理层提供进展的可视化,所以从目前来看,对于客户、员工、管理层这三个利益相关人来讲确实达到了这样一个目的。
但是现在行业中,需求变化太快,不管我们怎么努力去做,发现还是不能满足客户的需要,不管需求搞得多么细,到交付产品给客户的事情,总是有这样那样的问题,这个时候就不得不去修改我们的软件,这是华为面临的一个挑战,如何解决这个问题? 软件开发中有三个要素:人、过程、技术和工具。对于一个软件项目成功来说,这三个要素都不可省,而在以前大家强调IPD和CMM,更多的是强调大家规范的把它运作起来,对于人、技术和工具基本上不提了,忽略了,所以后来就反馈出一个问题,就是很多项目,看起来那个过程做的那个漂亮,那个报告写得那个完美,但是交出去的产品那个烂,其实这三个因素是缺一不可的,你必须得均匀的发展,还有一个是人的方面,因为人是具备创造能力的,所以从华为的教训给我启发,过度的关注过程而忽视人、忽视技术和工具,我们就得要思考和反省了。 针对这些问题,华为也就提出了敏捷。华为在99年之前基本上都是土生土长游击队的做法,到了2001年的时候就引入了IPD和CMM,到2006年的时候,就发现了瀑布模型的问题,如交付周期特别长,就是每做一个客户的需求,然后一分析,这样一走半年就过去了,所以就引入了RUP,最初的想法就是加速我们项目的交付周期,能够快速的给客户响应,但是敏捷实际上已经进入了一个低谷期,所以当时就引入了迭代,实施了一年之后也发现,RUP里面的东西实际上也是挺多的,所以后来就接触了XP、SCRUM这些方法,这样就从07年开始向敏捷这个方向在走。
有一个图在业界流传比较广泛,也叫洋葱图,共分三圈,也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。XP为什么叫极限编程?如果你觉得这个软件开发的实践是一个好的实践,那么你就把它发挥到极致。比如,结对编程,一个在编,一个人在看,实际上看的人不会白看,其实起到了一个review的作用,既然review这个作用有效,那么为什么不把这个作用发挥到极致,所以就采用了结对编程将review这个作用发挥到极致。在敏捷中有一个8个字的原则:沟通、反馈、交流、勇气。它认为项目团队中的成员这个沟通是比较重要的,既然你非常重要,那么我也要把你发挥到极致,所以两个人一起在干活的时候就会不停的有交流与沟通,所以,结对编程是一个典型的把review、沟通交流发挥到极致的实践。另外,TDD也可以认为是那刚好够用的事情发挥到极致。我们以前传统的软件开发的做法是,先做好这个软件,然后去测,看看是不是实现了这样一个功能,但是我们总会发现这里面有很多代码其实是从来就没有用过的,只是在下代码的时候顺手就把它写了,在分析那些产品的时候发现有的产品这样的没用到的代码高达50
%,而TDD的思想是,我既然要实现什么功能,然后我就先写对应的用例来验证它,然后在开发的时候就开始写代码,使得这个用例刚好通过,这样就使得我们写出来的代码是刚好满足这个系统的功能的代码,这样,前面出现的50%就可以不用做了,这就是把刚好够用发挥到极致。其他的就不一一讲了。XP在2001年到2003年之间非常的红火,过了之后又相对的沉寂了一点,现在又冒出来一个新的敏捷的方法论,就是SCRUM。XP是过分的强调将软件开发里面的实践发挥到极致,而这些实践都是同编程实践相关,但是在管理方面就比较弱,所以,在用了几年之后,大家发挥XP不是起到那么大的作用,所以就开始沉寂下来。这个时候就出现一个流派,就是SCRUM。SCRUM其实就是一个非常非常轻量的项目管理框架,基本上没有什么编码实践方面的东西,你说看到的都是管理上的活动,这个管理上的活动很多人就会有一种似曾相识的感觉,记得前不久,同华为的一个项目团队在聊,就谈到这个项目的backlog,一讲,项目团队的人就说其实他就是那样子做的,他以前也没与听说过什么SCRUM,就是把这些需求一条一条的列出来,镍镉优先级,估个工作量,一看,就是这个东西。SCRUM的核心其实比较简单,2分钟就能讲出来,就是3个3。
一、3个角色。Product Owner,负责决定产品要做什么,做成什么样子;SCRUM Master,保证项目能够遵循SCRUM的方式运作下来;项目团队成员,包含开发、测试、质量等等所有的人。
二、3种会议。迭代的计划会议、中间的站立式会议、迭代的评估会议,属于三个管理的活动。
三、3个交付件。待开发的任务列表、待修复的缺陷任务列表、项目的进度图。SCRUM就是通过这3个3将项目非常简洁的管理起来,有一个思考就是关于PMP里面讲到的9大领域多少活动不一定对这种敏捷项目适用。那么大家可能提出一个疑问,就是项目的进度是不是就不可视了。其实,敏捷项目的进度可视很简单,就是通过一个白板(进度墙、任务看板),将每个人的进度情况这么一贴,这就是最简单最直接的管理方式,一看,所有人都知道,就算你去开发一些什么复杂的一些IT支撑系统,可能都起不到这个白板的作用。在华为关于敏捷的一些项目管理工具,用Scrumworks、Bingo这些管理工具也能够把项目的进度管理起来,但是你要做的就是必须得把电脑打开,要把浏览器打开,这样才能看到你的进度是什么样子的,而在办公区直接树一个白板就能够很简单、很方便的知道我的这个进度情况。所以,在华为,对于敏捷项目,管理的框架上是采用的SCRUM,指导如何编码实现上就采用了一些XP的实践,当然XP的实践不会全部去选,会根据项目的实际情况去选一些实践,如果你把所有实践都选的话,实际上的效果是非常差的。那么如何来选择就得根据项目的实际情况去评价。华为在实践的过程中也引入了精益、消除浪费的思想。比如,在平时的工作中存在停工等活的浪费。什么是停工等活的浪费呢?比如我们开发在做开发的时候,我们的测试就会轻松一点,那么测试在做测试的时候我们的开发就会轻松一点,大家觉得这样也挺好的,但是你从整个组织角度去分析,实际上是停工等活的,开发时测试在等着,测试时开发在等着,如果你从精益的角度考虑的话,为何不通过迭代的方式把开发和测试等待的时候整合在一起来工作,使得效益得到提升。有很多项目团队自己去做了,确实效果比较明显。其实在2006年实践RUP的时候就感觉到这样的好处了是非常明显的。引入敏捷之后,自然而然的就会想到同公司已有流程之间的关系,原来是IPD+CMM,所以就有同事问到是不是我这个就不用了。分析可以知道,IPD是决定做不做,决定之后如何去做就可以采用敏捷开发,所以对于敏捷产品的流程就是IPD+敏捷的方式,所以有很多以前采用瀑布型的团队逐步的被敏捷代替了,还有些团队正在代替中,还有些团队就觉得原来那套玩得很流畅就继续采用原来的方式。所以目前在华为,项目团队是可以自己来选择采用哪种方式进行,现在可以发现,那些愿意选择敏捷方式走的往往就是原来那些顽固不化的烂项目,因为以前在推流程的时候,那帮人整天在那里叫,有问题,我不干,我不愿意做,实际上,后来做深入分析发现,他的那种模式并不适合按照瀑布型去做,但现在成了积极分子,所以每个项目的模式是不一样的。
在做敏捷的时候也存在一些容易做的事情和不容易做的事情。比如说SCRUM的项目管理是比较容易去实践的,就是3个3,对于那些想敏捷的,我建议可以先做这个,还有也会做一些结对编程、持续集成的实践。比较难的,有这么几点。华为从99年开始都是按照开发、测试等团队去运作的,团队与团队之间就会形成部门的墙(华为有一个外籍员工给起了一个名字叫Chinese Wall),对每个部门来说,希望把这个墙树高一点,这样能获取更多的资源非常顺利的开展工作,所以墙就会越树越高,很多部门甚至还有checklist,你只要给我什么东西,我就按照checklist打勾,打勾不通过的就要干啥干啥,这样通过约束管理层,罚款的制度就来了,而这个问题就很难搞,涉及到很多很多的人员,涉及到部门角色定位的问题,这是华为觉得最难的一点。第二难的问题就是TDD,在很多项目都试过,但是试过之后,很多项目都无疾而终,或者诉苦说这个我实在搞不下去,分析后发现,是涉及人做事情方法的改变,这个挺难的,以前写代码都是边想编写,就能写出来,现在你就得先想好、验证好等等,然后再想办法填进去,就发现这个很难,这是一个开发习惯的改变,这也是很难的一件事情。第三个,就是Customer Tester,就是要客户参与验证,可能对于互联网企业可以部署一个系统,用户参与测试就可以做起来了,但是对于华为而言,客户是电信企业,而电信是买方,买了之后再供他们的客户去用,这个里面客户就存在好几层,所以要客户真的参与进来还是比较难的。第四点,也是很难的,我们有一个团队,要到各个团队去宣传为什么做敏捷,这涉及到观念的转变,所以这也是非常难的事情。(一夜的引入,长时间的改变。)比如你说你这个团队敏捷了,明天就开始站立式会议,但是你最后会发现,要真正敏捷实际上是一个漫长的过程。
在华为实施敏捷的过程中,也有一些经验性的东西。第一个是QA从警察的角色转变到一个教练的角色。在以前,团队实施CMM的时候,QA更多的是一个警察的角色,他整天拿着一个checklist、报告什么的到处去团队里面看,你是否ok,不ok就要怎么怎么样,整天就干这个活,但是引入敏捷之后,QA就觉得有点失落,都敏捷了,我都不知道该怎么下手了,然后,在华为,就把QA转变了一下,将QA更多的充当教练的角色,充当SCRUM Master的角色,他去指导项目团队该如何去开这个站立式会议,该怎么去做迭代的计划等等指导性的工作,这样QA也觉得挺好,这样他能参与到在不同的团队中去,这样他见得也多,所以在敏捷的实践里面是需要这么一些人来干这么一些事情。第二个就是要营造一个一体化的团队,也就是将所有有墙的部门通通打掉,直接按照项目型运作,把大家拉到一起,不要考虑你原来是什么部门,先把项目做出来再说,这就是在XP的外圈中的Whole Team实践,因为大家就真正是一条船上的。在很对项目中,总是存在这样的一些人,项目成功不成功对他们是无关紧要的,但是有些人项目不成功对他们是非常重要的,而真正的敏捷项目就要这些人来挂帅,并且这些人是站在一条战线上的,所以就叫拉到一体化的团队里面来,大家都对交付负责。第三个就是办公环境最好也能够随着改变。以前大家都是那种小格间的方式,但是这种方式是非常不利于做交流和做项目的。第四个就是现身说法。前面讲到有很多这样的人会到团队中去说敏捷怎么怎么好,但是如果你让一些对项目成功不成功都不相关的人去讲是没用的,因为大家一听,首先就会质疑50
%,所以华为当初经常搞的活动就是让项目经理他们在讲,将他们当时是怎么开展敏捷的,这样别人一听才能理解到原来你是这么这么做的。

 

你可能感兴趣的:(华为)