在一个大型项目中全面利用禅道进行软件项目管理的实践

转载自博客：https://group.cnblogs.com/topic/74568.html

原创文章，欢迎拍砖，欢迎转载，但请全文转载，谢谢

感谢禅道团队开发了这么好的一套软件开发管理配置系统，使得软件项目经理可以轻松的管理大型团队，致谢！

2016年5月16日最新修改。。。

======================= 

全面采用禅道的敏捷开发模式进行整个软件开发生命周期的管理，

需求->设计->编码->测试->交付这四个阶段全部用禅道对应的功能进行规范化管理。

岗位划分：

1、项目经理PM

2、技术经理TM

3、测试经理QM

4、高级程序员(一般担任开发小组长)MC

5、程序员GC

6、前端工程师FE

以上2、4、5、6属于开发组，3属于测试组

 

具体开发工作流程如下：

 

特别注意：禅道里的“项目”对应的就是每一次的发版，比如：下一次要发版的版本号是V2.4，则就需要新增一个项目“XXXXX项目V2.4”，相应的，每一个“项目”下只会有对应的一个“版本”，如：“XXXX组件V2.4.0”，在开始每一个版本开发周期前就要在禅道上新建对应的“项目”

 

1、需求讨论

采用静态原型法与甲方做需求前期讨论

负责人：项目经理
参与者：技术经理、测试经理及前端工程师
外部需求讨论阶段不需要进禅道，用excel格式的会议纪要、邮件等进行沟通，在需求相对比较明晰之后，安排前端工程师制作静态原型，以静态原型+说明文档的方式来与甲方进行反复的沟通确认，直至最终确定需求

 

2、需求确认

与甲方一起确定下一次发版需要进行开发的需求及优先级

负责人：项目经理
参与者：技术经理

把最终确定的下一次发版的需求细化，并把细化的需求录入到禅道并设定好优先级为3（在后续过程中，甲方极有可能会临时提出紧急需求，那些需求可以相应设置优先级为2或1），这里要注意一定是细化的需求，比如：原始需求是“支持多城市，定于4月15日上线区内其他4个城市”，从这个需求细化出来的应该是具体到页面的需求，如：多城市_修改订单列表页面使之支持多城市...

确定下一次发版后要完成的需求后，项目组内部开全会通报所有需求，测试经理开始准备测试用例

 

3、版本定义

确定好将要发版的组件版本

负责人：项目经理

每一次发版的版本号规范如下：

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的清单

 

4、分配任务

根据需求细化并分配开发任务

负责人：技术经理

禅道路径“项目-任务”，做开发任务分配的时候，一般来说都会从一个需求分出多个开发任务，任务是最原子的事务，一个任务只能是一个执行人，如：
需求为：修改XXX页面使之支持不同城市的操作员只能显示本城市的信息

分配出3个任务：

1）修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-详细设计

2）修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-后端编码

3）修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-前端编码

 

5、详细设计

根据开发需求做设计文档

负责人：分配了任务的开发组相应人员

监督人：技术经理

根据情况安排编码程序员做设计文档（没有太大难度的功能）或者是由高级程序员或技术经理做设计文档（有一定难度的功能），统一放到SVN，如果是那种很简单的算法设计，可直接放到禅道-任务的备注。

文档标题格式：设计文档_需求ID_需求标题，如：设计文档_需求001_修改XXX页面使之支持不同城市的操作员只能显示本城市的信息

 

6、编码及单元测试

负责人：分配了任务的开发组相应人员

监督人：技术经理、开发小组长

1）程序员根据禅道上的任务按计划编码和做单元测试

2）程序员每天早上上禅道去“开启”分配给自己的任务，任务完成后点击“完成”

这里要特别强调： 采用禅道来分配任务并不是说不需要当面沟通，当面沟通依然是最重要的

禅道可与SVN集成，使得技术经理可以直接在禅道上review代码（社区版无此功能）

3）技术经理负责每天的代码review和解决技术难题

4）项目经理负责每天监控开发进度，发现情况及时沟通处理，项目经理根据任务的完成情况，及时修改需求的进度，使得甲方能及时了解进度情况，需求的进度统一写在备注”，格式如下：

研发完毕时间：2016-04-08晚上7点

测试完毕时间：2016-04-19晚上7点

发布上线时间：2016-04-20凌晨2点

特别注意：数据库变更的脚本，要统一放到SVN的“开发文档-版本目录”下，如：\01开发文档\V2.2.0 ，命名格式：脚本文件_V2.2.0.txt，这个脚本文件由技术经理进行维护

 

7、集成测试

编码完成，提交集成测试

1）技术经理自测后认为可以提交集成测试后，   在禅道路径“项目-版本”里，提交测试

2）技术经理把代码部署到测试服务器上

3）测试经理安排测试并提交bug（提交bug的时候，属于这次发版要修正的bug，严重程度设为1，其他不属于这次发版的bug，设为2或3，每次提交bug，都要设置“抄送人”为项目组管理层，使得管理层的每一个人都能了解测试的进度）

4）如果测试进入收尾阶段，即将定版的，技术经理把当前提交测试的代码在SVN上打一个对应版本的Branch分支（名称格式：V2.2.0_Testing），修改bug的人员集中在几个核心程序员上，减少引发新bug的几率，在通知核心程序员switch到此Branch后，立即修改SVN上的权限设置从Trunk上删除核心程序员的读写权限避免人为错误，其他程序员在Trunk分支上继续后续的开发

注意：

1）测试-bug中提交bug的时候，务必要选择对应的版本号

2）每次技术经理更新文件到测试服务器，都要在钉群里通告大家，并附上此次更新修复的bug清单

 

8、验收测试

集成测试完成，进行发版前的最后审核和验收测试

在测试经理回归完所有1级bug，认为可上线后

1）测试经理报告项目经理可以发版了

2）项目经理自己要再做一次测试，确保品质

3）项目经理测试后也认为没问题了，提交给甲方进行发版前的验收测试（如果有必要的，也可让甲方在阶段7参与测试）

 

9、发版上线

甲方确认可以发版，正式发版

在甲方进行验收测试认为可以发版后，

1）测试经理，进禅道路径“测试-版本”，修改已测试好的版本，设为“已完成”

2）技术经理把此次发版需要更新的代码、数据库SQL脚本打包出来

3）项目经理从禅道的项目-需求列表里导出（复制出）此次发版关联的需求为Excel文件，此文件就是提供给甲方的发版说明（changelog）文档，每次发版都在原文档前部增加新一个版本的内容

4）项目经理向甲方提供changelog文档，并让甲方签署上线确认书

5）技术经理把将要发版的文件小心谨慎地发布到生产服务器上

6）项目经理在禅道“产品-发布”中设定与项目-版本相同的发布，备注好发版时间和发版内容，并把版本和发布一对一关联起来

7）技术经理在发版第二天，在SVN上从Branch里导出一个Tag，名称格式：V2.2.0_Release

 

10、版本维护

在发版之后，一般来说，还是会发现一些之前没注意到的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清单给甲方确认）

以上2、3、4、5步骤迭代循环，直到停止维护此版本

 

11、中止维护

在新版本即将发布前夕，一般是5天内，则停止上一个版本的维护

1）技术经理在告知相关程序员把本地的工作目录switch到Trunk后，关闭svn上的老版本Branch的程序员读写权限

2）项目经理关闭老版本的发布，禅道路径“产品-发布”，设置此版本对应的发布为“停止维护”（这个步骤不能忘记，否则在bug里边选择版本的时候，没有被停止维护的发布对应的版本会一直显示出来） 

 

这里要特别注意的是: 不是说这一次发版完成了才开始新的一次发版之旅，一般来说，在步骤2完成之后，项目经理就要开始和甲方一起沟通下一次发版的需求了，然后是技术经理从需求分配任务，开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。。。。。。。