以下是我在一个长期项目研发过程中采用敏捷思想进行项目开发管理的成功实践，供大家参考
一、项目背景
1、这是一个长期维护，需要不断扩展功能的O2O平台，系统本身包含多达13个子系统，且还在不断增加中
2、系统采用了“组件化架构”，各个组件之间实现了脱藕，可以各自单独扩展
3、开发资源严重匮乏，程序员严重不足，且其中能独立工作的程序员比例很低
二、敏捷开发实践
1、每一次版本迭代都包括：需求->设计->编码->测试->交付这四个阶段
2、用禅道对开发全过程进行规范化管理
3、每一次版本迭代的周期是2周
4、采用SVN把所有文档也管理起来
岗位划分：
1、产品/项目经理PM（Product/Project Manager ）：负责产品、项目的整体管理，重点抓需求、进度的管控
2、技术经理TM（Technical Manager ）：负责技术团队的管理，重点抓技术架构、开发进度
3、测试经理QM（Quality Manager ）：负责测试团队的管理，是保障项目出品质量的第一责任人
4、高级程序员(一般担任开发小组长)MC（Master Coder）：负责带领开发小组，重点负责技术难点的攻关
5、程序员GC（General Coder）
6、前端工程师FE（Front Engineer）
7、测试员QE（Quality Engineer）
以上2、4、5、6属于开发组，3、7属于测试组
禅道使用的几个小技巧：
-- 禅道里的“项目”是指一个产品生命周期中对某一个阶段性的工作的定义。 我的做法是把一个大版本定义为一个项目，V2.0是一个项目，V3.0就是另一个新项目
-- 版本的定义在细节上如果能注意的话，会让程序员、测试员在使用过程中更加顺畅，举个例子：目前上线正常运行的是“XXXXX系统V2.0.0”版，当前提交测试的是“XXXXX系统V2.0.1”，下一个要提交测试的是“XXXXX系统V2.0.2”版，那么在集成测试阶段，就应该编辑一下这两个版本的名称，改为：“XXXXX系统V2.0.1-当前测试版本”，“XXXXX系统V2.0.2-下一个版本”，使得测试员、程序员在处理bug时选择版本的时候不用再动脑去想
-- 在禅道里配置好异步自动发提醒邮件，实现“工作追人”
禅道使用流程图（摘自禅道官网）：
具体一个迭代周期的工作流程如下：
1、需求讨论
采用静态原型法与甲方做需求前期讨论
负责人：产品/项目经理
参与者：技术经理、测试经理及前端工程师、高级程序员
外部需求讨论阶段不需要进禅道，用excel格式的会议纪要、邮件等进行沟通，在需求相对比较明晰之后，安排前端工程师制作静态原型，静态原型可以用Mockplus、墨刀、Axure等快速原型工具来制作，以静态原型+说明文档的方式来与甲方进行反复的沟通确认，直至最终确定需求
2、需求确认
与甲方一起确定下一次发版需要进行开发的需求及优先级
负责人：产品/项目经理
参与者：技术经理、测试经理、高级程序员
把最终确定的下一次发版的需求细化，并把细化的需求录入到禅道并设定好优先级为3（需求的优先级很重要，必须设置！在后续过程中，甲方极有可能会临时提出紧急需求，那些需求可以相应设置优先级为2或1，产品/项目经理要及时调整需求优先级，完成了一个1级的 ，就要及时把2级的给设为1级），这里要注意一定是细化的需求，比如：原始需求是“支持多城市，定于4月15日上线区内其他4个城市”，从这个需求细化出来的应该是具体到页面的需求，如：多城市_修改订单列表页面使之支持多城市...
确定下一次发版后要完成的需求后，项目组内部开全会通报所有需求，测试经理开始准备测试用例
3、分配任务
根据需求细化并分配开发任务
负责人：技术经理
禅道路径“项目-任务”，做开发任务分配的时候，一般来说都会从一个需求分出多个开发任务，分配任务的时候一定要设定起止时间（设定起止时间其实就是设定了“工作计划”），任务是最原子的事务，一个任务只能指派一个执行人。一定要记得设置每个任务的优先级，具体任务执行人从优先级高的开始做，技术经理需及时调整任务优先级，使得任务有序被处理，一般来说，分配给某个具体人的1级任务不要超过3-5条，如：
需求为：修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
分配出3个任务：
1）Task#231 修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-详细设计（优先级1，指派给高级程序员A）
2）Task#232 修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-后端编码 （优先级2，指派给后端程序员B）
3）Task#233 修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-前端编码（优先级2，指派给前端程序员C）
待详细设计完成后，技术经理要把Task#232、233这两条的优先级改为1，然后程序员B、C就知道要开工了
4、详细设计
根据开发需求做设计文档
负责人：分配了任务的开发组相应人员
监督人：技术经理
根据情况安排编码程序员做设计文档（没有太大难度的功能）或者是由高级程序员或技术经理做设计文档（有一定难度的功能），统一放到SVN/Git的文档目录下（最新版禅道的“文档”功能也比较完善，支持权限控制，也可采用禅道来管理开发文档），如果是比较简单的算法设计，只需要文字描述即可的，建议直接写到禅道-任务的备注里。有一点要特别强调的：设计有变动的时候，一定要通过添加新备注来及时更新到禅道上，详设一定要标注版本，如：详设V01、详设V02
文档标题格式：设计文档版本号_需求ID_需求标题，如：设计文档V01_需求001_修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
这里要特别讲一下关于前后端分离开发模式下，如何编写接口文档：
1）必须要有一份详细的接口文档编写规范
2）接口文档建议是用SVN/Git统一管理起来，在禅道上备注说明此任务对应的是具体哪些接口
5、编码及单元测试
负责人：分配了任务的开发组相应人员
监督人：技术经理、开发小组长
1）程序员根据禅道上的任务按计划编码和做单元测试
2）程序员每天早上上禅道去“开启”分配给自己的任务，当天不能完成的任务，在下班前要记录工时，根据需要用“备注”记录开发过程遇到的情况，如： 今天在处理XXX算法的时候遇到了问题，通过请教XX得到了解决，得到的教训是，在写代码的时候要细心细心再细心
3）代码自测通过后提交到SVN/Git，提交的时候的message请复制禅道上的任务标题进去，这一点很重要，这么做的目的在于让产品/项目经理通过禅道就能掌控全部状况，包括每一次代码的变动，message的格式如下：任务#23 重新设计XXX子系统的数据库，使得能满足货、人、车分离管理的基本需求
3）任务完成后点击“完成”
这里要特别强调： 采用禅道来分配任务并不是说不需要当面沟通，当面沟通依然是最重要的
禅道可与SVN/Git集成，使得技术经理可以直接在禅道上review代码（社区版无此功能）
3）技术经理负责每天的代码review和解决技术难题
4）产品/项目经理负责每天监控开发进度，发现情况及时沟通处理，产品/项目经理根据任务的完成情况，及时修改需求的进度，使得甲方能及时了解进度情况，需求的进度统一写在备注”，格式如下：
研发完毕时间：2016-04-08晚上7点
测试完毕时间：2016-04-19晚上7点
发布上线时间：2016-04-20凌晨2点
特别注意：数据库变更的脚本，要统一放到SVN/Git的“开发文档-版本目录”下，如：\01开发文档\V2.2.0 ，命名格式：SQL脚本_V2.2.0.sql，这个脚本文件由技术经理进行维护
6、版本定义
在即将提交集成测试前，设置好各个组件的版本
负责人：产品/项目经理
每一次发版的版本号规范如下：
1）版本号第二位加1，第三位为0，如：V2.2.0
2）在正式发版之后如果有小改，则第三位递增，如：V2.2.1，V2.2.2...
在项目-版本中定义好版本，并把版本与这次发版对应的需求关联起来（一个需求可以和多个组件的版本关联，比如：需求002：订单列表页支持多城市的不同操作员只能看到本城市的订单，此需求牵涉到：订单中心组件V2.2.0、商品中心组件V2.2.0、微商城/PC商城组件V2.2.0这几个版本，都要关联上）
这里要注意的是，要分组件定义版本，要求所有组件的版本号都保持一致（方便日后快速找到相互能匹配的组件版本），
比如：要定义这么几个组件的版本：
1）微商城/PC商城组件V2.2.0
2）订单中心组件V2.2.0
3）商品中心组件V2.2.0
4）门店系统组件V2.2.0
5）呼叫中心组件V2.2.0
6）门店APP组件V2.2.0
在项目-版本-查看bug，可查看此版本下的bug的清单
7、集成测试
负责人：测试员、开发组员
监督人：测试经理、技术经理
编码完成后，开发组提交到测试组进行集成测试：
1）技术经理自测后认为可以提交集成测试后， 在禅道路径“项目-版本”里，把步骤6创建的版本提交测试（加后缀“当前测试版本”），同时，新增下一个发布版本（对当前版本发现的bug，将在下一个版本解决）
举例说明：
微商城/PC商城组件V2.2.1-即将发布版本
微商城/PC商城组件V2.2.0-当前测试版本
2）技术经理把代码部署到测试服务器上
3）测试经理安排测试人员测试并提交bug（提交bug的时候，属于这次发版要修正的bug，严重程度设为1，其他不属于这次发版的bug，设为2或3，每次提交bug，都要设置“抄送人”为项目组管理层，使得管理层的每一个人都能了解测试的进度），提交bug的对象为测试经理，测试经理先审核bug是否需要提交给开发组并提交给技术经理
4）技术经理负责分派Bug给具体的开发人员，技术经理在分派bug的时候 ，一定要设置bug优先级，具体bug处理者只需要处理1级的bug，技术经理有序的把2级、3级的bug提级，一般来说，分配给具体人的1级bug不要超过3-5个。如果解决某项bug需要牵涉到多个开发人员的，请先指派给与此bug关系最近的那一位（第一责任人），其完成自己份内工作后再指派给第二位，依此类推，如果是多人可以同时并发处理的，则把其它相关开发人员放到“抄送”对象里并口头沟通好，由第一责任人负责点击“解决”，并备注其它人具体做了怎样的处理
5）开发人员解决完bug提交到SVN/Git，提交的时候的message请复制禅道上的bug标题进去，如：bug23 分销中心-佣金订单列表页显示的排序有问题，应该是按照订单生成时间降序排列
6）如果测试进入收尾阶段，即将定版的，技术经理把当前提交测试的代码在SVN上打一个对应版本的Branch分支（名称格式：V2.2.0_Testing），修改bug的人员集中在几个核心程序员上，减少引发新bug的几率，在通知核心程序员switch到此Branch后，立即修改SVN上的权限设置从Trunk上删除核心程序员的读写权限避免人为错误，其他程序员在Trunk分支上继续后续的开发
7）代码同步问题，原则上，在一个短周期内（3天内），就要把Branch分支的代码Merge到Trunk上一次
注意：
1）测试-bug中提交bug的时候，务必要选择对应的版本号
2）每次技术经理更新文件到测试服务器，都要在钉群里通告大家，并附上此次更新修复的bug清单
8、验收测试
负责人：甲方人员
集成测试完成，进行发版前的最后审核和验收测试，注意 :这里都是针对7所分出来的那个用于此次发版的Branch分支（如：V2.2.0_Testing）
在测试经理回归完所有1级bug，认为可上线后
1）测试经理报告产品/项目经理可以发版了
2）产品/项目经理自己要再做一次测试，确保品质
3）产品/项目经理测试后也认为没问题了，提交给甲方进行发版前的验收测试（如果有必要的，也可让甲方在阶段7参与测试）
4）代码同步问题，原则上，在一个短周期内（3天内），就要把Branch分支的代码Merge到Trunk上一次
9、发版上线
负责人：测试经理、技术经理
监督人：产品/项目经理
甲方确认可以发版，正式发版,注意 :这里都是针对7所分出来的那个用于此次发版的Branch分支（如：V2.2.0_Testing）
在甲方进行验收测试认为可以发版后，
发版当天：
1）测试经理，进禅道路径“测试-版本”，修改已测试好的版本，设为“已完成”
2）技术经理把此次发版需要更新的代码、数据库SQL脚本打包出来
3）产品/项目经理从禅道的项目-需求列表里导出（复制出）此次发版关联的需求为Excel文件，此文件就是提供给甲方的发版说明（changelog）文档，每次发版都在原文档前部增加新一个版本的内容
4）产品/项目经理向甲方提供changelog文档，并让甲方签署上线确认书
5）技术经理把将要发版的文件小心谨慎地发布到生产服务器上
6）产品/项目经理在禅道“产品-发布”中设定与项目-版本相同的发布，备注好发版时间和发版内容，并把版本和发布一对一关联起来
发版第二、三天：
1）技术经理在发版第二天，在SVN上从之前的工作Branch（如：V2.2.0_Testing）导出一个Tag，名称格式：V2.2.0_Release，记得之前要把代码先Merge到Trunk
2）技术经理在发版第二天，整理禅道-任务，属于本次发版已完成的任务，全部做关闭处理，之前计划要做，但未完成的，可关联到下一个版本
3）产品/项目经理在技术经理完成2）之后，对相应的本版本的需求，做关闭处理
10、总结会议
Very important！ 项目组所有人员都要参与
目的：总结经验与教训
成果：形成改进计划
11、版本维护
负责人：测试组员、开发组员
监督人：测试经理、技术经理
在发版之后，一般来说，还是会发现一些之前没注意到的Bug需要修改，因此，在下一次大版本发版之前，需要继续维护当前版本，具体做法如下：
1）技术经理从之前发版的Tag下的Release导出一个Branch，如：V2.2.0_Fixbug
2）测试经理根据客户处反馈的情况，继续发bug到禅道上，严重程度为1，版本号为V2.2.0
3）技术经理安排相关人员在V2.2.0_Fixbug分支下修改bug（一般来说，只安排专职负责旧版本维护的程序员去处理这些bug，最好是技术经理自己负责处理），这里要注意SVN的权限，此Fixbug分支只给具体修改的程序员分配读写权限
4）测试经理安排做回归测试
5）2、3、4步骤循环进行，直到认为可以发版了，则确定版本号，比如为：V2.2.1，并从V2.2.0_Fixbug导出一个Tag为V2.2.1_Release，由技术经理更新的生产服务器上（发版前也要导出修改的bug清单给甲方确认）
6）代码同步问题，原则上，在一个短周期内（3天内），就要把Branch分支的代码Merge到Trunk上一次
以上2、3、4、5步骤迭代循环，直到停止维护此版本
12、中止维护
负责人：技术经理
监督人：产品/项目经理
在新版本即将发布前夕，一般是5天内，则停止上一个版本的维护
1）技术经理在告知相关程序员把本地的工作目录switch到Trunk后，关闭svn上的老版本Branch的程序员读写权限，记的之前要Merge代码到Trunk上
2）产品/项目经理关闭老版本的发布，禅道路径“产品-发布”，设置此版本对应的发布为“停止维护”（这个步骤不能忘记，否则在bug里边选择版本的时候，没有被停止维护的发布对应的版本会一直显示出来）
这里要特别注意的是: 不是说这一次发版完成了才开始新的一次发版之旅，一般来说，在步骤2完成之后，产品/项目经理就要开始和甲方一起沟通下一次发版的需求了，然后是技术经理从需求分配任务，程序员开始熟悉任务需要用到的技术，测试组开始熟悉具体的业务流程和细节，从而开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。。。。。。。
PS：配套此开发流程的还有对应各个岗位的“岗位作业书”，更进一步细化每个岗位的具体工作内容，我将在后续博文中放出
欢迎各位同好一起探讨敏捷开发的实践方法，大家好，才是真的好^_^
