zoukankan      html  css  js  c++  java
  • {Agile},{CMMI},现状

       最近一直在忙,好久没上来看看了,本人在深圳工作,公司在深圳来说也算是比较大的公司。开发人员在200以上,总公司是美国的,干.NET快三年了,别人说程序员3年,5年都是坎,也就是月薪6K,8K的坎,听说迈过去就好了。本人现在只迈过第一个坎,第二个还在努力中。。。前一家公司项目经理在我临走的时候曾经叫我做基础开发再做两年,以后就好办了。我现在也是这么做的。

       十一在家没事干,看了看敏捷软件开发。现在,在软件行业我们会经常听到软件开发过程:敏捷软件开发(Agile Software Development)和CMMI(集成软件能力成熟度模型),那么,公司内部的软件开发过程、敏捷软件开发及CMMI,它们是一回事儿或是有什么不同?这里不对其进行细致的讲解,只是就我的理解讲讲Agile CMMI,现状。如果什么地方理解有误,欢迎大家拍砖。

    敏捷宣言

    1 人和交互重于过程和工具

    2 可以工作的软件重于面面俱到的文档

    3 客户合作重于合同谈判

    4 随时应对变化重于循规蹈矩

     

    Agile   人和交互重于过程和工具。

    CMMI: 人的沟通很重要,但是cmmi似乎更加偏向过程和工具。

    现状:    公司还是比较注重员工之间的沟通,至于过程,我可以说CMMI2的水平可能都没有,管理比较混乱。工具还是用了一些。

     

    Agile   可以工作的软件重于面面俱到的文档。

    CMMI: cmmi是比较注重文档的,编写文档将会耗费很多时间但是项目开发更加规范。

    现状:   这点公司做的还是挺敏捷的,不知道管理者是按照敏捷开发流程来呢,还是由于上级的压力造成的。文档可以说非常的少。

     

    Agile   客户合作重于合同谈判。

    CMMI: 我相信cmmi在这点应该还是和agile很接近。

    现状:  公司这点基本上也是这样的,先拿下合同再沟通。

    Agile   随时应对变化重于循规蹈矩。 

    CMMI: cmmi应该更加注重他的流程,这样可能导致比较循规蹈矩,缺乏随机应变的能力。现状:    公司这点基本上谁也不遵循,需求一天一小变,一周一大变,完全是被逼出来的。

     

    敏捷软件开发的12条原则

    我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意。

    在敏捷开发的世界有这么个说法:初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高。交付得越平凡,最终产品的质量就越高。经常的进行交付,我们努力在项目刚开始的几周内就交付一个具有基本功能的系统,然后我们努力坚持每2周就交付一个功能渐增的系统,如果客户认为目前的功能已经足够了,客户可以选择把这些系统加入产品中,或者他们可以简单的选择在检查一偏已有的功能,并指出他们想要的改变。在我认为CMMI应该是初期设计的很好,完成大部分模块,并经过很好的测试后交付给客户使用,然后一个发布一次,这个间隔随着时间的推移而拉长。公司的现状就是需求经常改,导致发布很平常,一个月一次。

    即使到了开发后期,也欢迎改变需求。

    CMMICMMI是有自己一套流程,需求一般在项目准备期就完成的差不多,后期即使改也不是很大。        

    现状: 这点我还是比较赞同CMMI的,但是公司的模式有点象敏捷开发,常常在发布后期前几天修改一些需求,搞得人很疲惫,时间也很紧张,也没什么准备。

    经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。

    CMMI:发布如此频繁,势必导致流程混乱。应该不是CMMI所要求的。

    现状: 本人还是比较同意CMMI的,毕竟发布一个版本也不是很容易的,比如我公司发布很麻烦,由于项目是全球性质的,所以经常半夜还在公司发布,测试。时间长了员工都有怨言。

    在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。                                    

    CMMI:与敏捷相同

    现状:比较赞成这点,公司也符合这点。

    围绕被激励起来的个人构件项目,给他们提供所需要的环境和支持,并且信任他们能够完成工作。

    CMMI:俗话说万事具备,只欠东风。CMMI的准备工作还是做的很充分的。

    现状:公司这点很含糊,有时齐全有时就没考虑到。个人比较喜欢好的环境和支持。

    在团队内部,最有效果的信息传递方式是面对面的交流。

     CMMI:也是要求这点。

    现状:沟通是决定一个团队能否成功的完成项目的一个很大的因素,我想大概没有公司不去强调这点吧。

    工作的软件是首要的进度度量标准。                                         

    CMMI:也是要求这点。现状:公司最终就是实现商业价值,经济利益,产品的成功在很大程度上是衡量工作成功与否的标准。

    敏捷过程提倡可持续的开发速度。

    9   不断地关注优秀的技能和好的设计会增强敏捷能力。

    10 简单。

    这三点就不用多少了,应该都是一样的想法。

    11 最好的架构、需求和设计出自于自组织的团对。               

    CMMI:标准的软件开发流程应该都是这么要求的。                 

    现状:可能由于个人的利益或者上级的不信任使这些内容往往就那么几个人参与。本人公司也是。

    12 每隔一段时间,团队会在如何才能更有效地更有效的工作方面进行反省,然后相应地对自己的行为进行调

    CMMI:类同。 

    现状:及时的总结和反省能更早的发现问题发生的地方和原因,可以避免下次错误的重犯,这点在项目进行过程中是很需要的。可惜公司缺少这些。

    总之:个人感觉敏捷软件开发应该更加注重人,时效,快捷,激情。CMMI:准备充分,更加流程化,严谨。他们各自有自己的优点缺点。采用什么模式完全取决与你的上级。^_^

    版权所有归"布衣软件工作者".未经容许不得转载.
  • 相关阅读:
    Apache Spark 2.2.0 中文文档
    Apache Spark 2.2.0 中文文档
    Apache Spark 2.2.0 中文文档
    Apache Spark 2.2.0 中文文档
    Apache Spark 2.2.0 中文文档
    Apache Spark RDD(Resilient Distributed Datasets)论文
    Apache Spark 2.2.0 中文文档
    Apache Spark 2.2.0 中文文档
    【机器学习实战】第10章 K-Means(K-均值)聚类算法
    [译]flexbox全揭秘
  • 原文地址:https://www.cnblogs.com/gjcn/p/1305729.html
Copyright © 2011-2022 走看看