• <em id="mu0vl"></em>

    1. 【原创】本人在一个大型项目中全面利用禅道进行软件项目管理的实践_2016年12月6日更新
      2016-04-20 09:15:31
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童

      以下是我在一个长期项目研发过程中采用敏捷思想进行项目开发管理的成功实践,供大家参考
       
      、项目背景    
      1、这是一个长期维护,需要不断扩展功能的O2O?#25945;ǎ?#31995;统本身包含多达13个子系?#24120;一?#22312;不断增加中
      2、系统采用了“组件化架构?#20445;?#21508;个组件之间实现了?#38597;海?#21487;以各自单独扩展
      3、开发资源?#29616;?#21294;乏,程序员?#29616;?#19981;足,且其中能独立工作的程序员比例很低
       
      、敏捷开发实践
      1、每一次版本迭代都包括:需求->设计->编码->测试->交付这四个阶段
      2、用禅道对开发全过程进行规范化管理
      3、每一次版本迭代的周期是2周
       
      岗位划分:
      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.0(当前版本)?#20445;癤XXXX系统V2.0.1(即将上线)?#20445;?#20351;得测试员、程序员在处理bug时选择版本的时候不用再动脑去想
      -- 在禅道里配置好异步自动发提醒邮件,实现“工作追人”
       
      具体开发工作流程如下:
       
      1、需求讨论
      采用静态原型法与?#36861;阶?#38656;求前期讨论
      负责人:产品/项目经理
      参与者:技术经理、测试经理及前端工程师、高级程序员

      外部需求讨论阶段不需要进禅道,用excel格式的会议纪要、邮件等进行?#20302;ǎ?#22312;需求相?#21592;?#36739;明晰之后, 安排前端工程师制作静态原型,以静态原型+?#24471;?#25991;档的方式来与?#36861;?#36827;行反复的?#20302;?#30830;认,直至最终?#33539;?#38656;求
       
      2、需求确认
      与?#36861;?#19968;起?#33539;?#19979;一次发版需要进行开发的需求及优先级
      负责人:产品/项目经理
      参与者:技术经理、测试经理、高级程序员
      把最终?#33539;?#30340;下一次发版的需求细化,并?#20005;?#21270;的需求录入到禅道并设定好优先级为3(在后续过程中,?#36861;?#26497;有可能会临时提出紧急需求,那些需求可以相应设置优先级为2或1),这里要注意一定是细化的需求,比如:原始需求是“支持多城市,定于4月15日上线区内其他4个城?#23567;保?#20174;这个需求细化出来的应该是具体到页面的需求,如:多城市_修改订单列表页面使之支持多城市...
      ?#33539;?#19979;一次发版后要完成的需求后,项目组内部开全会通报所?#34892;?#27714;, 测试经理开?#30002;急?#27979;试用例
       
      3、分配任务
      根据需求细化并分配开发任务
      负责人:技术经理
      禅道路径“项目-任务?#20445;?#20570;开发任务分配的时候,一般来说都会从一个需求分出多个开发任务, 任务是最原子的事务,一个任务只能指派一个执行人,如:
      需求为:修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
      分配出3个任务:
      1)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-详细设计
      2)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-后端编码
      3)修改XXX页面使之支持不同城市的操作员只能显示本城市的信息-前端编码
       
      4、详细设计
      根据开发需求做设计文档
      负责人:分配了任务?#30446;?#21457;组相应人员
      监督人:技术经理
      根据情况安排编码程序员做设计文档(没有太大难度的功能)或者是由高级程序员或技术经理做设计文档(有一定难度的功能),统一放到SVN/Git,如果是那种很简单的算法设计,可直接放到禅道-任务的备注。
      文档标题格式:设计文档_需求ID_需求标题,如:设计文档_需求001_修改XXX页面使之支持不同城市的操作员只能显示本城市的信息
       
      5、编码及单元测试
      负责人:分配了任务?#30446;?#21457;组相应人员
      监督人:技术经理、开发小组长
      1)程序员根据禅道上的任务按计划编码和做单元测试
      2)程序员每天早上上禅道去“开启”分配给自己的任务,任务完成后点击“完成”
      这里要特别强调: 采用禅道来分配任务并不是说不需要当面?#20302;ǎ?#24403;面?#20302;?#20381;然是最重要的
      禅道可与SVN/Git集成,使得技术经理可以直接在禅道上review代码(社区版无此功能)
      3)技术经理负责每天的代码review和解决技术难题
      4)产品/项目经理负责每天监控开发进度,发现情况及时?#20302;?#22788;理,产品/项目经理根据任务的完成情况,及时修改需求的进度,使得?#36861;?#33021;及时了解进度情况,需求的进度统一写在备注?#20445;?#26684;式如下:
      研发完毕时间:2016-04-08晚上7点
      测试完毕时间:2016-04-19晚上7点
      发布上线时间:2016-04-20凌晨2点

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

       
      6、版本定义
      在即将提交集成测试前,设置好各个组件的版本
      负责人:产品/项目经理
      每一次发版的版本号规范如下:
      1)版本号第二位加1,第三位为0,如:V2.2.0
      2)在正式发版之后如果?#34892;?#25913;,则第三位递增,如:V2.2.1,V2.2.2...
      在项目-版本中定义好版本,并把版本与这次发版对应的需求关联起来(一个需求可以和多个版本关联,比如:需求002:订单列表页支持多城市的不同操作员只能看到本城市的订单,此需求牵涉到:订单中心组件V2.2.0、商品中心组件V2.2.0、微?#22363;?PC?#22363;?#32452;件V2.2.0这几个版本,?#23478;?#20851;联上)
      这里要注意的是,要分组件定义版本,要求所有组件的版本号都保持一致,
      比如:要定义这么几个组件的版本:
      1)微?#22363;?PC?#22363;?#32452;件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,可查?#21019;?#29256;本下的bug的清单
       
      7、集成测试
      编码完成,提交集成测试
      1)技术经理自测后认为可以提交集成测试后,   在禅道路径“项目-版本”里,提交测试
      2)技术经理把代码部署到测试服务器上
      3)测试经理安排测试并提交bug(提交bug的时候,属于这次发版要修正的bug,?#29616;?#31243;度设为1,其他不属于这次发版的bug,设为2或3,每次提交bug,?#23478;?#35774;置“抄送人”为项目组管理层,使得管理层的每一个人都能了解测试的进度)
      4)如果测试进入收尾阶段,即将定版的,技术经理?#35757;?#21069;提交测试的代码在SVN上打一个对应版本的Branch分支(名称格式:V2.2.0_Testing),修改bug的人员集中在几个核心程序员上,减少引发新bug的几率,在通知核心程序员switch到此Branch后,立即修改SVN上的权限设置从Trunk上删除核心程序员的?#21015;?#26435;限避免人为错误,其他程序员在Trunk分支上继续后续?#30446;?#21457;
      注意:
      1)测试-bug中提交bug的时候,务必要选择对应的版本号
      2)每次技术经理更新文件到测试服务器,?#23478;?#22312;钉群里通告大家,并附上此次更新修复的bug清单
       
      8、验收测试
      集成测试完成,进行发版前的最后审核?#33073;?#25910;测试, 注意 :这里都是针对7所分出来的那个用于此次发版的Branch分支(如:V2.2.0_Testing)
      在测试经理回归完所有1级bug,认为可上线后
      1)测试经理报告产品/项目经理可以发版了
      2)产品/项目经理自己要再做一次测试,确保?#20998;?
      3)产品/项目经理测试后也认为没问题了,提交给?#36861;?#36827;行发版前的验收测试(如果有必要的,也可让?#36861;?#22312;阶段7参与测试)
       
      9、发版上线
      ?#36861;?#30830;认可以发版,正式发版, 注意 :这里都是针对7所分出来的那个用于此次发版的Branch分支(如:V2.2.0_Testing)
      在?#36861;?#36827;行验收测试认为可以发版后,
      发版当天:
      1)测试经理,进禅道路径“测试-版本?#20445;?#20462;改已测试好的版本,设为“已完成”
      2)技术经理把此次发版需要更新的代码、数据库SQL脚本打包出来
      3)产品/项目经理从禅道的项目-需求列表里导出(复制出)此次发版关联的需求为Excel文件,此文件就是提供给?#36861;?#30340;发版?#24471;鰨╟hangelog)文档,每次发版都在原文?#30331;?#37096;增加新一个版本的内容
      4)产品/项目经理向?#36861;教?#20379;changelog文档,并让?#36861;?#31614;署上线确认书
      5)技术经理把将要发版的文件小心谨慎地发布到生产服务器上
      6)产品/项目经理在禅道“产品-发布”中设定与项目-版本相同的发布,备注好发版时间和发版内容,并把版本和发布一对一关联起来
      发版第二、三天:
      1) 技术经理在发版第二天,在SVN上从Branch里导出一个Tag,名称格式:V2.2.0_Release
      2)技术经理在发版第二天,整理禅道-任务,属于本次发版已完成的任务,全部做 关闭处理,之前计划要做,但未完成的,可关联到下一个版本
      3)产品/项目经理在技术经理完成2)之后,对相应的本版本的需求,做 关闭处理
       
      10、版本维护
      在发版之后,一般来?#25285;?#36824;是会发现一些之前没注意到的Bug需要修改,因此,在下一次大版本发版之前,需要继续维护当前版本,具体做法如下:
      1)技术经理从之前发版的Tag下的Release导出一个Branch,如:V2.2.0_Fixbug
      2)测试经理根据客户处反馈的情况,继续发bug到禅道上,?#29616;?#31243;?#20219;?,版本号为V2.2.0
      3)技术经理安排相关人员在V2.2.0_Fixbug分支下修改bug(一般来?#25285;话?#25490;专职负责旧版本维护的程序员去处理这些bug,最好是技术经理自己负责处理),这里要注意SVN的权限,此Fixbug分支只给具体修改的程序员分配?#21015;?#26435;限
      4)测试经理安排做回归测试
      5)2、3、4步骤循环进行,直到认为可以发版了,则?#33539;?#29256;本号,比如为:V2.2.1,并从V2.2.0_Fixbug导出一个Tag为V2.2.1_Release,由技术经理更新的生产服务器上(发版前也要导出修改的bug清单给?#36861;?#30830;认)
      以上2、3、4、5步骤迭代循环,直到停止维护此版本
       
      11、中止维护
      在新版本即将发布前夕,一般是5天内,则停止上一个版本的维护
      1)技术经理在告知相关程序员把本地的工作目录switch到Trunk后,关闭svn上的老版本Branch的程序员?#21015;?#26435;限
      2)产品/项目经理关闭老版本的发布,禅道路径“产品-发布?#20445;?#35774;置此版本对应的发布为“停止维护?#20445;?#36825;个步骤不能忘?#29301;?#21542;则在bug里边选择版本的时候,没有被停止维护的发布对应的版本会一直显示出来) 
       
      这里要特别注意的是:  不是说这一次发版完成了才开始新的一次发版之旅,一般来?#25285;?#22312;步骤2完成之后,产品/项目经理就要开始和?#36861;?#19968;起?#20302;?#19979;一次发版的需求了,然后是技术经理从需求分配任务,程序员开始熟悉任务需要用到的技术,测试组开始熟悉具体的业务流程和细节,从而开始新一次发版之旅。这就是 螺旋状上升的敏捷迭代开发之路。。。。。。。
       
      PS:配套此开发流程的还有对应各个岗位的“岗位作业书?#20445;?#26356;进一步细化每个岗位的具体工作内容,我将在后续博文中放出
       
      欢迎各位同好一起?#25945;?#25935;捷开发的实践方法,大家好,才是真的好^_^
      ?#34892;?#36259;共同?#25945;?#30340;请加Scrum干货Q群:302304689


      dd_macle 最后编辑, 2016-12-06 08:32:26
      沙发
      2016-04-20 10:14:05
      春哥
      • 访问次数: 10572
      • 注册日期: 2005-04-30
      • 最后登录: 2019-09-11
      • 我的积分: 528074
      • ?#25490;?#31561;级: 幽灵 等级7 春哥
      很好的经验!加300积分。:)
      春哥 最后编辑, 2016-04-20 10:14:48
      板凳
      2016-04-20 13:47:10
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童

      项目经理岗位作业书

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

      每日例行工作:

      1、早上开始上班后立即召开朝礼

      2、写朝礼纪要并发给相关人

      3、在日志中制定今日工作计划并?#19994;?#20027;线

      4、上禅道检查任务完成进度是否与计划相符

      5、上禅道检查Bug修复情况是否正常

      6、处理各?#33267;?#26102;任务,加入到禅道的任务列表,如:?#36861;教?#20986;的紧急任务等

      7、如有必要,与技术经理、测试经理?#20302;?

      8、发现开发进度有?#29616;匮?#35823;的,立即与上级领导?#20302;?

      9、抽空参与测试,了解系统的真实情况

      ?

      周一例行工作:

      1、公司层面的项目组周例会

      ?

      周末例行工作:

      1、项目组周工作总结会

      2、发送项目周总结给项目组管理层及公司管理层

      ?

      分阶段工作:

      1 、需求讨论

      职责:总负责人

      协作人:技术经理、测试经理及前端工程师

      工作内容:

      组织召开会议与?#36861;焦低?#38656;求,根据?#20302;?#32467;果与前端工程师一起制作静态原型,然后拿给?#36861;?#32487;续?#20302;ǎ?#21453;复迭代,直至最终通过静态原型落实每一项需求

      ?

      2 、需求确认

      职责:总负责人

      协作人:技术经理、测试经理

      工作内容:

      1、把步骤1落实的需求逐条录入禅道:

      菜单路径:产品à需求à提需求

      必填项:所属产品、所属计划、需求来源、不需要评审、需求名称、优先级(设为1)、需求描述(需求的详细描述,并给出静态原型页面链接)、抄送给(项目组管理层)

      2、?录入完需求后主动通知技术经理、测试经理

      如有必要,则组织相关人召开会议研?#20013;?#27714;细节

      ?

      ?

      3 、版本定义

      职责:总负责人

      协作人:无

      工作内容:

      1)把即将发布的组件版本录入到禅道

      菜单路径:项目à版本à创建版本

      必填项:产品、名称编号、构建者、打包日期(计划提交集成测试的日期)

      每一次发版的版本号规范如下:
      a、版本号第二位加1,第三位为0,如:V2.2.0
      b、在正式发版之后如果?#34892;?#25913;,则第三位递增,如:V2.2.1,V2.2.2...
      一般来?#25285;?#25353;两周发布一个版本的周期发版,这里要注意的是,要分组件定义版本,要求所有组件的版本号都保持一致,以叫酒为例:
      目前至少要定义这么几个组件版本:
      a、微?#22363;?PC?#22363;?#32452;件V2.2.0
      b、订单中心组件V2.2.0
      c、商品中心组件V2.2.0
      d、门店系统组件V2.2.0
      e、呼叫中心组件V2.2.0
      f、门店APP组件V2.2.0
      ?

      2)把版本与需求关联

      菜单路径:项目à需求à关联需求

      必填项:并把版本与需求关联起来(一个需求可以和多个版本关联,比如:需求002:订单列表页支持多城市的不同操作员只能看到本城市的订单,此需求牵涉到:订单中心组件V2.2.0、商品中心组件V2.2.0、微?#22363;?PC?#22363;?#32452;件V2.2.0这几个版本,?#23478;?#20851;联上)在项目-版本-查看bug,可查?#21019;?#29256;本下的bug的清单

      ?

      4、分配任务

      职责:开始酝酿下一版的需求

      协作人:前端工程师?#32570;?#35201;人员

      工作内容:开始酝酿下一版的需求

      ?

      5、详细设计

      职责:有必要的话要开始和?#36861;教?#35770;下一版的需求

      协作人:前端工程师?#32570;?#35201;人员

      工作内容:有必要和?#36861;教?#35770;下一版的需求

      ?

      6、编码及单元测试

      职责:和?#36861;?#24320;始深入讨论下一版的需求

      协作人:前端工程师?#32570;?#35201;人员

      工作内容:和?#36861;?#24320;始深入讨论下一版的需求

      ?

      7、集成测试

      职责:基本上?#33539;?#19979;一版本的主要需求

      协作人:前端工程师?#32570;?#35201;人员

      工作内容:

      ?

      8、验收测试

      职责:总负责人

      协作人:技术经理、测试经理

      工作内容:对整个系统进行抽样测试

      ?

      9、发版上线

      职责:总负责人

      协作人:技术经理、测试经理

      工作内容:督?#25216;?#26415;经理的升级上线工作,负责向?#36861;教?#20132;上线相关的文档

      ?

      10、版本维护

      职责:与?#36861;餃范?#19979;一版的需求

      协作人:技术经理、测试经理及其他必要人员

      工作内容:一般来?#25285;?#22312;当前版本发版后的2天内,与?#36861;餃范?#19979;一个版本的所?#34892;?#27714;(开发内容)

      ?

      11、中止维护

      职责:总负责人

      协作人:技术经理、测试经理及其他必要人员

      工作内容:

      dd_macle 最后编辑, 2016-05-26 10:25:28
      #3
      2016-05-15 07:39:19
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童
      占位1
      #4
      2016-05-15 07:39:30
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童
      占位2
      #5
      2016-05-15 07:39:42
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童
      占位3
      #6
      2016-05-15 07:39:54
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童
      占位4
      #7
      2016-05-25 08:41:02
      wanxiang123
      • 访问次数: 4
      • 注册日期: 2016-05-16
      • 最后登录: 2018-12-19
      • 我的积分: 63
      • ?#25490;?#31561;级: 幽灵 等级1 幽魂
      6
      #8
      2016-12-06 08:35:32
      dd_macle
      • 访问次数: 12
      • 注册日期: 2007-12-17
      • 最后登录: 2017-11-30
      • 我的积分: 512
      • ?#25490;?#31561;级: 玄清 等级2 道童


      笔者第一篇阅读量过千的文章,?#26723;?#32426;念^_^

      #9
      2016-12-06 09:12:20
      石洋洋
      • 访问次数: 5603
      • 注册日期: 2011-04-06
      • 最后登录: 2019-09-12
      • 我的积分: 92513
      • ?#25490;?#31561;级: 幽灵 等级6 修罗
      1/1
      体彩11选五
    2. <em id="mu0vl"></em>

      1. <em id="mu0vl"></em>

        1. 神测网pc蛋蛋 永久固定公式规律出尾 时时彩前三跨度规则 肥牛牛布斯 一码中特图 老重庆时时彩计划开奖结果 黑龙江十一选五遗漏号 老重时时彩走势图360 发彩江苏快三平台 香港内部精准码料图片 什么大游戏好玩 皇冠ag 高频彩输 九阴真经岑九牌九 陕西十一选五快乐十分开奖结果查询结果