注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

玉树临风

石滴水

 
 
 

日志

 
 

【转帖】华为敏捷项目管理  

2011-01-13 20:50:09|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

【石滴水那话儿】

       CAT软件需要极限编程,cat软件各有千秋,但是能够做到听取意见,迅速改进的,应该算是雪人翻译软件了。

    译员大多数都是软件白痴,真正真懂的特别少,操作,使用,问题,代码。不仅仅是不会,还不会学。

     cat软件不仅是不好用,而且还很不好学。从容易使用的角度,培训,跟进,提高,对开发也是很有益处的。

      教学相长,用户和开发者一起互动,应该是比较好的流程。正好无意中看见了这篇文章,发现很符合历史潮流,特此推荐此文。想学cat的,不如从雪人入手,学会之后,触类旁通,也是不错的道路。

不是给雪人做广告,只是有感而发,特此说明。

雪人CAT教学视频:
1.[特色介绍]    http://www.flash8.net/flash/60193.shtml
2.[快速入门]    http://www.flash8.net/flash/58117.shtml
3.[对Word的支持]   http://www.flash8.net/flash/58116.shtml
4.[双语对齐——快速创建大型记忆库视频]   http://www.flash8.net/flash/59349.shtml
5.[本地术语库与在线翻译结合视频]       http://www.flash8.net/flash/60516.shtml

【废话完毕】

 

 


  有一个图在业界流传比较广泛,也叫洋葱图,共分三圈,也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。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的方式运作下来;项目团队成员,包含开发、测试、质量等等所有的人。
转自项目管理者联盟
  二、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更多的充当教练的角色,充当的角色,他去指导项目团队该如何去开这个站立式会议,该怎么去做迭代的计划等等指导性的工作,这样QA也觉得挺好,这样他能参与到在不同的团队中去,这样他见得也多,所以在敏捷的实践里面是需要这么一些人来干这么一些事情。第二个就是要营造一个一体化的团队,也就是将所有有墙的部门通通打掉,直接按照项目型运作,把大家拉到一起,不要考虑你原来是什么部门,先把项目做出来再说,这就是在XP的外圈中的Whole Team实践,因为大家就真正是一条船上的。在很对项目中,总是存在这样的一些人,项目成功不成功对他们是无关紧要的,但是有些人项目不成功对他们是非常重要的,而真正的敏捷项目就要这些人来挂帅,并且这些人是站在一条战线上的,所以就叫拉到一体化的团队里面来,大家都对交付负责。第三个就是办公环境最好也能够随着改变。以前大家都是那种小格间的方式,但是这种方式是非常不利于做交流和做项目的。第四个就是现身说法。前面讲到有很多这样的人会到团队中去说敏捷怎么怎么好,但是如果你让一些对项目成功不成功都不相关的人去讲是没用的,因为大家一听,首先就会质疑50%,所以华为当初经常搞的活动就是让项目经理他们在讲,将他们当时是怎么开展敏捷的,这样别人一听才能理解到原来你是这么这么做的。  项目管理者联盟

  评论这张
 
阅读(1387)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017