【原创】笔者在项目中进行软件项目管理的实践

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

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

岗位划分:

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完成之后,项目经理就要开始和甲方一起沟通下一次发版的需求了,然后是技术经理从需求分配任务,开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。。。。。。。

PS:配套此开发流程的还有对应各个岗位的“岗位作业书”,更进一步细化每个岗位的具体工作内容,我将在后续博文中放出

时间: 2025-01-05 16:41:15

【原创】笔者在项目中进行软件项目管理的实践的相关文章

项目中的软件需求说明书的访谈部分

博主的项目小组上周已进入正途,上周在小组讨论下,作出了软件需求说明书功能描述的大概模块,并且确定了项目的目标和范围——针对大学生市场. 根据目标需求,我们设计出了调查问卷,便于了解用户需求以及市场需求. 调查问卷的链接如下:http://www.sojump.com/jq/7476545.aspx 下一步,我们将根据调查结果,进一步完善功能需求,再者完成我们的需求说明书.

教你如何快速定位项目中慢查询[项目管理]

1. 使用对象: 项目经理或者项目管理者 2. 数据库: mysql 3. 快速定位慢查询: 启动mysql时,启动慢查询日志:3.1 Window系统:第一种:bin\mysqlId.exe  --safe-mode  --slow-query-log (可在my.ini中配置地址,默认存放位置:datadir=C:/ProgramData/MySQL/MySQL Server 5.6/Data):第二种(建议):修改mysql的配置文件my.ini,找到my.ini文件,在[mysqld]里

[书目20150309]成功的企业级软件项目管理:优化绩效完美交付的最佳实践

本书旨在解决困扰软件行业的一个问题: 如何组织软件项目管理以实现优化绩效.完美交付.作者尼尔.怀特(PMP,项目管理领域的专家)介绍了一种新的方法:Enterprize组织. 本书描述了Enterprize组织所定义的项目中的关键角色与责任,包括产品经理.项目经理.业务架构师.产品架构师.过程架构师.资源经理.团队带头人和团队成员. 本书还讨论了如何利用Enterprize组织大型项目.小型项目.多个项目和维护性项目,并通过设置的“问题与答案”栏目回答了项目管理过程中常见的一些问题. 目录 第1

最近一个项目中关于NGUI部分的总结

最近一个项目中关于NGUI部分的总结           在自己最近的一个项目中,软件的界面部分使用了NGUI来进行制作.在制作过程中,遇到了一些问题,也获取了一些经验,总结下来,作为日后的积累. 1.NGUI图集的使用. 此次是第一个自己正儿八经的制作完整图集的项目,感受颇深.在使用NGUI制作界面时,图集的选用是一个关键,因为它直接关系到了drawcall的数量.最好就是自始至终都只使用同一个图集中的元素,这样的话,在界面制作上drawcall的消耗就只会受到Panel的划分以及字体与图集的

(转)最近一个项目中关于NGUI部分的总结(深度和drawCall)

在自己最近的一个项目中,软件的界面部分使用了NGUI来进行制作.在制作过程中,遇到了一些问题,也获取了一些经验,总结下来,作为日后的积累. 1.NGUI图集的使用. 此次是第一个自己正儿八经的制作完整图集的项目,感受颇深.在使用NGUI制作界面时,图集的选用是一个关键,因为它直接关系到了drawcall的数量.最好就是自始至终都只使用同一个图集中的元素,这样的话,在界面制作上drawcall的消耗就只会受到Panel的划分以及字体与图集的混合使用这两部分的影响. 在制作图集时,可以分为两个制作方

[课程分享]IT软件项目管理(企业项目甘特如是评价、维护管理、文档管理、风险管理、人力资源管理)

[课程分享]IT件项目管理(企业项目甘特图案例评价.维护管理.文档管理.风险管理.人力资源管理) 对这个课程有兴趣的朋友能够加我的QQ2059055336和我联系 课程讲师:丁冬博士 课程分类:Java 适合人群:中级 课时数量:32课时 用到技术:IT软件项目配置.IT软件项目模板的制定 涉及项目:IT软件企业项目甘特图案.IT软件项目可行性报告分析.基于svn的IT软件项目配置管理案例 更新程度:完毕 课程背景: 该课程是北风品牌项目管理课程系列之中的一个<IT项目管理>课程.通过本课程的

在软件项目管理中如何把时间估算的靠近真实值?

我们在开发一个软件项目的时候,大老板或者客户经常需要我们给他们某个项目估算的工时,我们一般的做法就是把当前的项目按照WBS进行自上而下,自顶而底,自外而里的进行分解:然后根据一个详细的可个人实施的任务作为一个最低的估算时间的单元,这个时候问题,就来了,如何让这个最低的估算时间的单元逼近它的实际真实值,同时也不让员工太闲或者太累?这里给大家介绍一种我们以前用过的乐观估计,悲观估计和期望估计的算法,供大家参考. 任务最终的估算时间=(乐观估计+悲观估计+期望估计*4)/ 6(中庸), (1)乐观估计

[课程分享]IT软件项目管理(企业项目甘特图案例评价、维护管理、文档管理、风险管理、人力资源管理)

对这个课程有兴趣的朋友可以加我的QQ2059055336和我联系 课程讲师:丁冬博士 课程分类:Java 适合人群:中级 课时数量:32课时 用到技术:IT软件项目配置.IT软件项目模板的制定 涉及项目:IT软件企业项目甘特图案.IT软件项目可行性报告分析.基于svn的IT软件项目配置管理案例 更新程度:完成 课程背景: 该课程是北风品牌项目管理课程系列之一<IT项目管理>课程.通过本课程的教学,使学生掌握IT项目管理的基本原理和基本技能,能够根据项目干系人的特征需求,确定项目的范围,经过计划

软件项目管理三国启示录01 群雄争霸之项目经理的自我修养

序 话说天下大势,合久必分,分久必合:写代码也一样,写着写着就想做做管理,作为一名码农,我就有过这样的心态,而且还机缘巧合这几年做了几个项目,因此有机会与不同的人.不同团队打交道,也或多或少有些积累了一些体会(谈不上经验),因此想纪录下来,与朋友们一起分享,以求共同进步. 为了防止有多心的朋友.同事或合作伙伴对号入坐,我就借用三国演义中的人物故事,并结合自身的一些项目体会来浅谈一下软件项目管理中的一些心得体会,这其中有的故事或大或小,大的故事我们权且认为是大项目,小的故则认为是小项目.本系列初步