接触敏捷开发差不多一年了，对它也有了一些自己浅显的认识，写这篇文章来给自己梳理梳理工作中的敏捷开发流程。
迭代周期
工作中根据项目普遍任务的耗时，采用10个工作日作为1个迭代周期，包括迭代计划会议、迭代开发和迭代回顾会议
迭代任务
迭代任务通常在feature到task的级别，任务主要由以下几个方面来产生：产品功能开发计划、产品功能研究计划、测试提交的上轮迭代未解决的bug和客户反馈的产品问题
1) 开发任务由产品专员在上一轮迭代中确定产品功能点，并产出功能设计文档，由开发在本轮迭代完成的任务，任务目标是完成功能开发
2) 研究任务是以前迭代中遗留的存在一定困难、架构不合理和新功能开发难度不确定的任务，任务目标是输出研究文档，文档确认该功能的技术可行性和技术实现方案
3) bug修复任务是在之前的迭代任务中未完成的测试提交的bug和客户反馈的问题，任务目标是修复该bug
迭代过程
迭代过程中主体有三种角色：产品、开发和测试。产品负责根据客户的需求制定长中短期的产品需要开发的功能并输出产品设计文档，开发负责进行功能实现的研究和开发，测试负责产品的测试及版本发布。
迭代流程遵循三者迭代任务不冲突的原则，即
1) 产品在迭代中定义下一轮迭代的开发任务，并输出产品设计文档
2) 开发在迭代中先根据主干拉取出迭代分支，该分支用于测试人员进行测试，并在计划会议认领迭代任务，在主干进行迭代开发，如该任务是研究任务，开发任务顺延到下一轮迭代
3) 测试在迭代中负责在迭代开始时根据计划会议录入迭代任务，对上一轮迭代开发的功能进行测试，并对本轮的开发任务编写测试用例
迭代计划会议
1) 参加人员：产品、开发和测试
2) 开发任务估时：由每个开发独立估时，同时展示各自评估时间，分歧较大时，有分歧开发进行迭代耗时评估阐述，分歧较小时，取耗时中值。
3) 开发任务领取：任务优先采取认领方式，提升开发人员积极性，每个开发认领的总任务量要基本符合10个工作日的有效开发时间。
4) 迭代Bug修复：每轮迭代开发预留上一轮bug修改时间，bug修复在上一轮分支进行
迭代开发：
总体采用轻文档重代码的方式，设计产出设计文档，开发产出研究文档和架构相关文档，测试产出测试用例
产品、开发和测试每天晨会说明昨日工作内容、进度和今日的工作计划，每日下班前更新任务耗时
1) 产品的主要工作：制定开发人员的下轮开发计划并产出设计文档
2) 开发的主要工作：进行任务研究、开发和自测，自测关键代码编写单元测试，自测需覆盖所有测试用例，自测完成所有开发集体进行代码检视
3) 测试的主要工作：进行上一轮迭代分支测试，对本轮迭代任务编写测试用例
迭代总结：
1) 参会人员：全体产品、开发和测试
2) 任务偏离值评估：评估任务估时和实际消耗的偏差，偏差大需要对该偏差进行情况说明
3) 迭代问题总结：每个人对本轮迭代任务进行总结
4) Bug评审：针对开发的上一轮迭代版本bug进行评审
迭代注意事项：
客户不提倡直接和开发沟通，客户反馈的bug最好作为新开发任务添加到下一轮迭代中