项目开发管理 开发 测试循序渐进
每天早上我们会有一个晨会( 站立会议 )
会议结束后大家就得忙各自的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列表，按责任人给依次分配下去解决。相当于集体重构了一次代码，让系统更加的健壮、稳定。
