浅谈敏捷与CMMI

发表于:2013-9-03 11:21

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:ddqhf    来源:51Testing软件测试网采编

  今天有幸看到一篇名为【CMM已经落伍了,敏捷才是王道】的帖子,本来想就在帖子上面直接回复的,后来担心那样的受众有限,所以选择了新开一篇帖子,来谈谈我认识的敏捷与CMMI,希望能够对大家有所裨益。当然,也欢迎大家与我共同来讨论!

  首先,可能还会有人质疑敏捷是什么,CMMI是什么。不过这已经不是我想说的重点,所以对于他们的定义,大家就自己找度娘和谷娘吧!

  开篇,我给大家一个私人的总结。大家可以试着去找找各自所在公司的项目,其根本的问题出在哪里?是不是主要集中在管理方面和人员沟通方面?而技术欠缺,其实只是占了一小部分。于是,我们的前辈们通过不断的摸索,便总结出了这两个东西(为什么不是方法??)。

  1.敏捷是做什么的?敏捷其实是为了解决沟通的问题而生的。

  2.CMMI又是做什么的呢?CMMI是为了解决管理的问题而生的。

  说到沟通,这里势必要明确一下。对于一个项目而言,沟通无非这三方面的沟通:1)项目团队内部的沟通;2)项目团队与公司内部人员的沟通;3)项目团队与客户的沟通。

  好了,先弄清楚两者的目的,然后我们再来仔细分析。

  为什么说敏捷是为了解决沟通的问题呢?

  首先,很多人都知道敏捷提倡以人为本对吧?为什么以人为本?因为项目是人在做,方案是人在提出。而以人为本则是体现在敏捷的最佳实践的方方面面:团队成员素质、团队稳定性、团队规模限制、和客户坐在一起、结对编程、快速迭代和快速交付、每日例会、(团队)坐在一起、自发组织、职能交叉等(凭经验随想随写,可能不够全面,欢迎补充)。

  1.团队成员素质的要求,是保证良好沟通的一个前提条件,这就像中国的一句古话:秀才遇到兵,有理说不清。

  2.团队稳定性,是保障沟通无遗漏或少遗漏的一个要素。如果团队成员一直相对稳定,那么彼此沟通会越来越畅通,且不会有或者少有工作交接的情况。为什么这样说,大家看看我们自己身边工作交接的效果如何就知道稳定性的重要性了。(但对于短期公司、短期项目而言,这一块是可以弱化的)

  3.团队规模限制,敏捷的各类方法,都会有成员规模的限制,一般是从4~9人不等。为什么这样限制?道理很简单,人少了,彼此互相提升少,且一旦人员变动,其相对变动比例高,工作交接这块的成本高;人多了,则增加了沟通对象,从而加大的沟通负担,增加沟通难度。

  4.和客户在一起,很多人忽略了这一点,这一点其实是敏捷之所以成功的至关重要的一点,怎么说?敏捷里面的需求怎么来的?是不是一条一条的backlog(有的地方时一条一条的feature的描述)?但这样的信息通常都是不够的(为什么这样说?试想,如果这样的信息都已经足够开发、测试了,那把这样的信息拼凑起来就已经是我们完整的需求文档了,大家说对不?),信息不够的话怎么办?把客户拉来和我们坐在一起就尤为必要了。对于信息里面有任何的疑问都可以随时从客户那里得到解答,这样我们的开发速度是不是大大加快了?当然,这只是“和客户在一起”的其中一个要点,另一要点是,“和客户在一起”,客户可以极大程度的便利的提出他的变更,同时项目团队也能快速的理解变更,然后快速的与客户沟通变更的影响并达成一致,进而才是快速的响应变更。敏捷的拥抱变化便是这样来的。试想,如果你仅仅只是客户有变更我们就做,根本不去理解变更,并且将变更的影响反馈给客户,你是打算找死还是你有耗不完的资源?

  5.结对编程,这是解决什么的呢?我们先看看传统的开发里面,是不是有代码评审这个环节(如果你觉得不需要,那可以不用继续看下去了)?很多急功近利的项目经理,会完全忽视代码评审这个环节,认为代码评审太耗时间,并且收效不大。诚然,很多项目的代码评审,其结果确实会是花了很多时间,但收效不大,为什么呢?很多人没有仔细去想想。你的代码评审是怎么评审的?是一个团队的人坐在一起一行一行的过?还是一对一的去看?(这里我不说方法论,因为没有绝对好的方法)不管什么方式,你有去找过自己没做好的原因吗?好了,这时候,敏捷给大家指了一条明路——结对编程。让开发人员在编程中就学习了,同时让我们的代码在编程中就得到了修正,而及早的修正了代码中的问题,可给后续工作带来的好处,相信不用我说大家都懂。

  6.快速迭代和快速交付。这又怎么与沟通联系起来呢?相信大家都明白,如果项目做完了,产品交给客户,客户这时候验收不过关,我们再来返工,成本可谓巨大,影响可以致命。而如果短周期交付客户,那么客户可以及早发现问题,我们也可以及早的进行修正,避免后续的连锁反应。而这期间,客户能(相比传统工作方式)提前与我们反馈问题,这就是一种沟通程序上面的优化。同时结合第4点,这样的快速交付成本也比传统的交付成本要低很多。

  7.每日例会,这个就太容易理解了,它不仅仅只是汇报的一种方式,更是团队内部固定沟通的一种方式。这里可能会有人质疑,因为每日例会通常要求不超过15分钟,汇报内容无非就那么三条,怎么沟通呢?我想说的是,大家不要把沟通想得那么狭隘。每日例会的真正目的也不是汇报工作,而是向团队介绍你的工作,当你弄明白怎么向他人介绍自己的工作,你才能开好每日例会。而既然每日例会是向他人介绍自己的工作,那么其他人在例会上需要做什么呢?显而易见,每个人都应该仔细倾听他人工作的介绍,并不断思考。为什么要这样做?目的在于,当某一时段出现必不可免的人员缺失时,其他成员可以迅速补上,这样说出来,相信大家就明白了,为什么每日例会同样中心在人员沟通。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号