http://www.zentao.net/dynamic/80027.html
Author: Li Shixin
Source: https://www.zhihu.com/question/21518108/answer/96043412
ZenTao's agile development model is fully adopted to manage the entire software development life cycle. The four stages of requirement->design->coding->test->delivery are all standardized and managed with the corresponding functions of ZenTao.
Position division:
1. Project manager
2. Technical manager
3. Test manager
4. Senior programmer (generally serving as the leader of the development team)
5. Programmer
6, front-end engineer
and above 2, 4, 5, 6 belong to the development team, 3 belongs to the test Group
The specific development workflow is as follows:
1. The person in charge of the preliminary discussion of requirements with Party A
: project manager
Participants: technical managers, test managers and other personnel who need to participate in the
external requirements discussion stage, there is no need to enter Zen Tao, and the meeting is in excel format Minutes, emails, etc. to communicate
2. Work with Party A to determine the requirements and priorities that need to be developed.
Person in charge: Project Manager
Participant: The technical manager
refines the final requirements and enters the refined requirements into ZenTao and sets the priorities. Priority 1 is the requirement to be implemented in the next version. Here, we must pay attention to the requirement of refinement. For example, the original requirement is "support for multiple cities, and the other 4 cities in the area will be launched on April 15". This requirement should be refined to the requirements specific to the page, such as: multi-city_modify the order list page to support multi-city...
After determining the requirements to be completed after the next release, the project team will hold an internal plenary meeting to inform all requirements, the test manager starts to prepare test cases
3. Determine the person in charge of the component version to be released : The version number specification for each release of the
project manager is as follows: 1) The second digit of the version number is incremented by 1, and the third digit is 0, such as: V2.2.0 2) In the official If there are minor changes after the release, the third digit will be incremented, such as: V2.2.1, V2.2.2... Generally speaking, a version is released on a two-week cycle, and the version is defined in the project-version, and Associate a version with a requirement (a requirement can be associated with multiple versions, for example: requirement 002: The order list page supports multiple cities. Different operators can only see orders in this city. This requirement involves: order center component V2. 2.0, Commodity Center Component V2.2.0, Micro Mall/PC Mall Component V2.2.0, these versions must be associated)
It should be noted here that to define the version by component, the version numbers of all components are required to be consistent, for example:
1) Micro Mall/PC Mall component V2.2.0
2) Order center component V2.2.0
3) Commodity center component V2 .2.0
4) Store system component V2.2.0
5) Call center component V2.2.0
6) Store APP component V2.2.0
In project-version-check bugs, you can view the list of bugs in this version
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点
7、编码完成，提交集成测试
1）技术经理自测后认为可以提交集成测试后， 在禅道路径“项目-版本”里，提交测试
2）技术经理把代码部署到测试服务器上
3）测试经理安排测试并提交bug（提交bug的时候，属于这次发版要修正的bug，严重程度设为1，其他不属于这次发版的bug，设为2或3）
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完成之后，项目经理就要开始和甲方一起沟通下一次发版的需求了，然后是技术经理从需求分配任务，开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。