开发工作中使用的敏捷开发模式

开发工作中使用的敏捷开发模式

来现在的公司有一段时间了，现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。

敏捷开发的定义及解释说明这里就略过了，想要详细了解的朋友可以猛点这里（敏捷开发详解）。

谈敏捷开发先从流程讲起吧。首先，每天早上我们会有一个晨会( 站立会议 )，主要汇报昨天自己所做的工作及自己在工作的过程中所遇到的问题，然后叙述今天计划的工作，组内成员依次汇报组长做好笔录。如果组内成员有遇到自己不能解决的问题，晨会上提出来大家共同探讨，但如果估计讨论时间会比较长的时候就会安排会下协调处理，毕竟每个人的时间是宝贵的。这是一个高效的会议意在了解组内各成员的工作进度及状态。

会议结束后大家就得忙各自的Story去了，说到Stroy可能有朋友会问了，什么是Story？下面我们就一起来了解下,说白了敏捷里面Story就是项目启动前你的项目经理或组长将项目划分出来的一个独立的功能模块。然后根据组内成员的特长安排的开发任务，在迭代中（通常两个星期为一个迭代周期）开发完成。一般测试人员会在开发人员开发Story的期间完成测试用例的编写，便于开发完成Stroy后showCase(开发人员在本地环境运行story供测试人员测试)时进行验收。showCase通过后Story算是初步通过，因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的，所以，功能代码在测试环境集成测试无误后该Story才算验收通过。

开发人员完成编码工作后并不意味着任务就结束了，这只是刚刚开始。是的，没说错，刚刚开始！测试人员会在测试环境对各个模块进行测试，如果发现问题会及时的在bug反馈系统中(用于跟踪问题的解决进度及完成情况)提出问题单进行跟踪，开发人员编码完成后最主要的工作估计就是和这个系统打交道了，需要及时的查看解决bug系统上面的问题单然后对问题单的状态进行变更，便于测试人员回归测试。

当然，让测试人员发现并反馈了很多的问题也是让我们开发人员比较苦恼的一件事情，毕竟不是什么好事儿。谁都希望自己交付的代码能够经得起考验，少出现或不出现问题(当然我们知道这是不可能的)，那么怎么办呢？敏捷里面针对类似的情况也有合理的应对流程，确保高效、高质、高产按时的交付。那就是我们常说的结对编程，通俗的说就是A和B两个人划分为一个编程小组，有问题及时沟通反馈。甚至A看着B或B盯着A写代码也是一件比较常见的情况。A在提交自己的Stroy时必须先让B检视Review一下自己的代码，发现了问题应修复完成后才能让测试人员去测试。这样可以避免一些不必要的错误和疏忽出现，提高开发效率的同时提高编码质量。

还有一种防范问题发生的措施，那就是集体检视代码。

迭代开发中一个星期后，团队成员的编码工作基本上完成了或完成了大半。这时候头儿会组织一个开发人员会议，就是开发人员坐到一个会议室里面瞪着大眼在投影仪上找bug或编码规范问题。团队的力量还是巨大的，一会儿功夫一个功能模块可能就给你揪出了十几个bug，大家一起发现的问题会议结束后会形成一个bug列表，按责任人给依次分配下去解决。相当于集体重构了一次代码，让系统更加的健壮、稳定。

经过九九八十一难般的两个星期就这样循环反复中一闪而过，这时候我们可以暂时的小憩一会儿了。

这一会儿是多久呢，大概也就是一天左右的时间吧。因为一个迭代周期结束后，项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。大家吃着零食边谈论总结这个迭代中做的好的部分及需要改进的部分，“嘿，那个谁上次那个地方我说应该XX做样吧！”、"这个迭代中XX同学给予了我很大的帮助，感谢"，大家你一言我一语就这样展开讨论开来...

回顾会议的第二天，开始了上面工作的第二次循环，直到整个项目交付......

原文链接：http://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html