从CMMI到敏捷.docVIP

从CMMI到敏捷开发 贾晓东(MP1123016) 毕业后的第一家公司是一家做软件外包的公司，在我入职的时候已经通过了CMMI Level 4的认证，并且在入职培训的时候还有关于CMMI的培训和考核，当时的感觉是程序很繁琐但是并不知道为什么需要这么多的条条框框。 实际工作起来后发现，CMMI的确是有自己好的一面，比如说它把很多东西都量化了，在度量和评估工作负荷及绩效方面都做的比较得心应手。但是有时也感觉程序过于繁琐，而且在对应一些特殊情况的处理方面不能很灵活。比如说在对应需求变更方面，因为有的时候只有在实际开发的时候才发现最初的设计是有问题的或者是错误的，这时就需要通过邮件来和客户沟通，有时候发现对方客户负责人不太懂程序，仅仅是了解业务而已，对方的回答很暧昧而且基本上和没有回答差不多，一个问题拖了很久才有最终方案下来。 有的时候项目前期进展的还比较顺利，但是客户在项目快要收尾的时候又出了很多关于数据库方面的变更，这就给项目的如期结束增加了相当大的压力，有的时候对于软件测试方面的影响几乎是从头再来一遍，所以往往是项目快要结束的时候几乎是天天全员加班。 在CMMI的运行过程中，我觉得有SQA的不断的监督与督促是有很大的帮助的。因为有的时候项目忙起来的时候，人往往会忽略或者忘记一些流程上的东西，也就是说偏离了CMMI正确的轨道，这个时候会有SQA人员来提醒你或者纠正你的错误。 目前所在的公司是一家做产品的软件公司，使用的是敏捷开发模型。我所在的这个小组由8个人组成，一个PM，四个开发人员，两个QA还有一个BA，负责的是公司的ERP产品线的新功能的开发，我们的开发一般是以Sprint为最小的开发周期(两个星期)，若干个Sprint组成一个release。在每个Sprint开始之前产品经理会把新的功能点写成一个个的story,每个story会有比较详细的功能点的说明，然后我们在开plan meeting的时候会评估每个story的大小和完成它所需要的时间，然后大家一起来决定这个Sprint里能够完成几个Story。开发人员，QA之后会在每个story里面加上自己的task，在开发过程中，每个人在每天早上的站立会议上都会更新自己的task的状态(未开始，进行中，结束)，并和组员沟通一些相关技术问题。当一个Story下的所有的task都处于结束状态的时候，产品经理会来接收这个story，如果他觉得做出的产品符合他之前的需求说明，就会把这个story的状态更新为已被接收，如果觉得还有需要修改的地方则会把需要修改的点罗列，然后我们重新修改再让他接收。当一个sprint里的所有的story都被接收以后，这个sprint就算是成功的，否则就是失败的，在每个sprint的最后一天，整个小组会开回顾会议回顾整个sprint中间的经验和教训以及以后需要提高的地方。 个人认为敏捷开发需要个人非常自觉，因为没有像CMMI那样有SQA来监督和督促你的工作。另外就是敏捷开发中对文档的开发和管理都不是很重视，这也导致了有时候对之前做的东西再做修改的时候很大程度上取决于当时开发的那个程序员或者QA来回顾功能上的细节问题，这也给产品的开发引入了一些风险。