敏捷CMMI解释

网友投稿 763 2022-05-30

首先,需要解释敏捷是什么,CMMI是什么。

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

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

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

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

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

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

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

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

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

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

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

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

敏捷和CMMI解释

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

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

8.         (团队)坐在一起 ,说这个话题前,先问大家一个问题。各位对于以下几种沟通方式的效果排序有差到好是怎么排序的?

a)        文字交流(如QQ、短信、 邮件 等)

b)        语音交流(如QQ语音、微信语音、电话等)

c)        视频交流(如QQ视频、视频电话等)

d)        面对面交流

当你排好序之后,再来看我们这个“(团队)坐在一起”,后面的话应该都不用我说了。

9.         自发组织 ,这个要和沟通联系起来,可能会有点抽象,但是大家想想,你通常和爱说话的人关系更好,还是和沉闷的人关系更好(记住,是通常情况,千万别跟我说特例)?一个人,必须要有主动(自发)意识,才能更好的把自己展现给他人,才能更好的让他人走进(不是走近)自己,如此一来,彼此的沟通才会更顺畅。除此之外,自发组织还有个暗含的要求,即项目不受外部人员的干扰,而外部人员也不得干扰项目的 运行 。这一点,则是为了减少项目与外部(非客户)之间的利害关系,以此来弱化这两者之间沟通的影响。

10.         职能交叉 ,说到这一点,我又要说这是敏捷里面非常关键同时极易被大家忽视的一点。职能交叉,直白来说就是开发和测试是同一个人,亦即同一个人既做开发又做测试,这样的好处是什么呢?减少了人员沟通的环节!如果敏捷的项目里,开发和测试是分开的,必然需求需要开发理解一次、测试理解一次,而如果两者合二为一,则只需要理解一次即可(注:这里的理解包含有与客户确认需求的过程)。可能又有人会为,这样做岂不是自己验证自己?可以说是,也可以说不是。是,是因为他必然需要对自己的模块做单元测试;不是,则是因为我们传统的 系统 测试,其用例执行可由大家“自发组织”去选择,即你自己可以决定你应该去做哪个模块的系统测试。如果大家都选择自己做自己的系统测试,我只能说,其结果比较令人担心。

在以上分析的10条中,第1、2、3、5、7、8、9、10主要是在解决团队内部沟通的问题;第9则是在解决团队与公司其他人员的沟通问题;第4、6则是解决项目组与外部(客户)之间的沟通问题。而敏捷,则是通过这一系列的措施,来保障人员之间沟通的有效性,以此达到降低项目失败风险,提高项目效率(沟通成本降低,效率自然提高)及成功率。

说了敏捷,再来说CMMI。了解CMMI历史的人都知道,CMMI本身就是因管理而生的。没有管理的混乱无序,就没有CMMI的出生并成长。我们先来看看CMMI的22个PA:RD, TS, PI, VER,VAL, IPM, PP, SAM, RSKM, PMC, REQM, QPM, CM, PPQA, MA, DAR, CAR, OPF, OPD, OT, OPP, OPM(v1.3的叫法)。其中有5个是针对组织的体系建设的PA,5个针对工程(项目实施)的PA,7个管理类的PA(v1.3将REQM列入了管理类),5个辅助的PA。然而除了7个管理类的PA以外,5个辅助的PA可谓是完全为了更好的管理项目而 服务 的,5个工程的PA则只是简单的指出了项目实施过程中必须的活动,5个组织级的PA,其实是对组织的管理做出了要求。由此可见管理在CMMI当中的分量。(注:如果想要详细了解各PA,请大家自行官网吧,有问题倒是可以到这里来讨论- -)

说了这么多,也让大家看累了,还请各位恕罪!

只是归根结底,敏捷也好、CMMI也罢,其目的都是为了降低项目失败的风险,提高项目效率及成功率。只是途径一个是解决沟通的问题,另一个是解决项目管理的问题而已。

从另一个角度理解则是,二者都不是银弹,并不能保证项目一定成功,只是提高其成功的概率而已。

语音通话 敏捷开发

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:excel绘制散点图的方法步骤图
下一篇:【我的物联网成长记7】物联网主流通信协议解读
相关文章