为了账号安全,请及时绑定邮箱和手机立即绑定

从版本管理看项目管理入手

2018.05.14 18:46 3659浏览

摘要: 版本管理是项目管理知识条线绕不过去的挑战。这里根据实际需要,整理一些笔记,请大家指正。理论指导实践,实践不一定要拘泥于理论。你不照着做,SVN也工作正常,只是照着做后实践出真知,更有体现工作的意义。

从版本管理看项目管理入手

[TOC]

概要

版本管理是项目管理知识条线绕不过去的挑战。这里根据实际需要,整理一些笔记,请大家指正。理论指导实践,实践不一定要拘泥于理论。你不照着做,SVN也工作正常,只是照着做后实践出真知,更有体现工作的意义。

成熟的管理方案

  • SVN 版本管理规范

  • Git Flow

版本管理相关知识科普

名词不计其数,先认识下,看看能不能混个脸熟,下次碰到就不会陌生了:

项目计划、检查点、里程碑、基线、路线图、蓝图、版本、需求分析、原型、数据库设计、评审、项目章程、组织结构、岗位职责说明书、干系人

如果没时间,看这个图就足够了

路线图-RoadMap			:蓝图:发展方向、目标、概要、阶段、步骤
|__检查点-Checkpoint	:周例会是检查点的表现形式
|__里程碑-Milestone	:重要的检查点是里程碑
|__基线-Baseline		:重要的需要客户确认的里程碑,就是基线;高层的阶段汇报会是基线的表现形式;
|__版本-Version		:在软件开发中,路线图就表现为一个个的版本迭代;每个版本描绘好feature;
	|__开发库-Trunk	:最稳定的前提下,保持最新。主干库;
	|__受控库-Branches	:可以是以组为单位建分支;也可以是针对某个投产版本修复bug;测试通过后合并到主分支;
	|__产品库-Tags		:正式投产的版本,不可更改。

RoadMap为啥重要

一个项目拿到手中,首先要解决的是RoadMap,翻译成路线图或者蓝图。主要是对项目的生命周期做一个规划,比如8个月工期的项目,采用迭代的方式开发,迭代多少版本合适,每个版本实现什么功能,新功能增加,旧功能迭代等。

简洁地说,RoadMap就是项目整体的规划图,产品的每一代都有什么功能都可以从中纵览全局。见着明了。有共同的目标才有努力的方向。

检查点(CheckPoint)

检查点是定期的抽检,一般以周为单位,体现在周例会和周报中。

包括但不限于:需求评审、原型评审、数据库设计评审、开发计划评审、

开发跟进、CodeReview、单元测试、集成测试、UAT测试、发布打版等

里程碑(Milestone)

阶段性产生重要交付物,需要组长确认的检查点儿,就可以是里程碑;不同的项目粒度划分不一样。

完成阶段性工作的标志,不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义,我们用一个例子说明:

情况一:你让一个程序员一周内编写一个模块,前 3 天你们可能都挺悠闲,可后 2 天就得拼命加班编程序了,而到周末时 又发现系统有错误和遗漏,必须修改和返工,于是周末又得加班了。

情况二:实际上你有另一种选择,即周一与程序员一起列出所有需求,并请业务人员评审,这时就可能发现遗漏并即 时修改;周二要求程序员完成模块设计并由你确认,如果没有大问题,周三、周四就可让程序员编程。同时自己准备 测试案例,周五完成测试;一般经过需求、设计确认,如果程序员合格则不会有太大问题,周末可以休息了。 第二种方式增加了 “ 需求 ” 和 “ 设计 ” 两个里程碑,这看似增加了额外工作,但其实有很大意义:首先,对一些复杂的项 目,需要逐步逼近目标,里程碑产出的中间 “ 交付物 ” 是每一步逼近的结果,也是控制的对象。如果没有里程碑,中间 想知道 “ 他们做的怎么样了 ” 是很困难的。其次,可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题,降低后期修改和返工的可能性。另外,还可根据每个阶段产出结果分期确认收入,避免血本无归。第三,一般人 在工作时都有 “ 前松后紧 ” 的习惯,而里程碑强制规定在某段时间做什么,从而合理分配工作,细化管理 “ 粒度 ” 。

版本

落地到软件开发中来说,RoadMap由一个一个版本迭代而成。

基线

通过评审的需求、原型、设计、测试案例最终形成一个release版本,就可以是一个基线。

重要的里程碑,需要客户正式评审确认的就可以是基线。

主干(trunk)、标签(tags)与分支(branches)

目的:多个版本中并行开发,提高开发效率;保证各个版本和各个环境(开发、测试、主干)的独立,避免相互影响;通过分支与主干的合并,这样主干永远是最新、最高版本,并且都在后面的测试中,保证了质量;用分支进行bug修改,而主干上进行新功能的开发。分支上的bug修改完合并到主干上;分支是给源项目创建副本,让每个工作组在各自的副本上进行开发,最后再将各个工作组的副本合并到源项目中。在此,各个副本被称作分支(branches),源项目被称为主干(trunk);branches测试完成后,修复完bug,通过branches生成tags。

  • 开发库(Trunk)是开发人员修改代码的地方。(开发人员可以随意修改)

  • 受控库(Branch)是测试版本代码存放的地方。(需要开发组长提交测试申请修改)

  • 产品库(Tags)是测试通过版本存放的地方。(需要测试报告来驱动修改)

SVN通过对三个文件的操作,主要目的还在于对历史版本的备份,三个版本相互独立,trunk负责保存当前稳定版本;branches 负责保持你开发分支版本,进行新需求开发;tags则保存最终发布上线版本,所以不可再修改。各司其职,各尽其责,使得开发过程中版本控制有条不紊,几十个人的合作开发也不成问题。

案例

比如:开发进行到1.0版本测试完成,要进行对外软件发布了,同时项目组后续会拆分成两个小组,一个小组负责1.0版本的BUG维护,另一个小组开始在1.0基础上进行2.0版本的开发。此时,就可以把当前版本从trunk拉到tags下一份,标记为release1_0,然后对外发布时就从这个文件夹获取;然后再把当前版本拉到branches下一份,标记为bugfix1_0,负责1.0版维护的小组以后就在这个文件夹下进行修复工作,负责2.0版开发的小组继续在trunk下工作;

Tags的定义规则

project name + 版本号,版本号定义为三段数字编号

 ***.***.***
  |   |   |______ 修正bug
  |   | _________ 新功能版
  | _____________ 革命性的产品升级版

分支定义规则:

project name + 日期时间 + 版本号,比如:project_20150202_v1.0.3,在创建每一个分支时,必须增加标注。

结论

重要的检查点是里程碑,重要的需要客户确认的里程碑,就是基线。在我们实际的项目中,周例会是检查点的表现形式,高层的阶段汇报会是基线的表现形式。

岗位职责说明书

其实也是干系人管理的基础。

如何解决开发质量?

各司其职,各负其责。靠自觉,上工具,靠自主,靠自助往往是有问题的。人是没有下限的,尤其是新人,没见过好的,就不知道什么是标杆。每个人除了“写代码”,还有什么必须要做的符合职业道德的素质体现的“本职内”事情么?这个问题谁来明确?这个时候依赖什么?依赖检查。谁来检查?岗位职责说明书的作用就体现出来了。

角色职责检查清单
PM制定推广流程、检查改进工作、组织协调、风险识别、汇报工作CodeReview
大拿需求、设计、原型、DB、汇报工作CodeReview
组长详细设计、任务拆分、计划跟进、代码审查、上线评审、汇报工作CodeReview
骨干攻坚克难、扫清障碍、带出副手、汇报工作CodeReview
成员打击敌人、保存自己:集中优势兵力横扫战场。带新人;、汇报工作CodeReview
新人服从安排、听从指挥:努力开发、集中求教。学习职场、开发基础常识。写笔记、汇报工作CodeReview

PM工具:引入Redmine管理

新建项目“XX项目建设-管理平台”

在Redmine中管理需求

新建子Project“需求分析”,需求组长负责,管理需求跟踪矩阵。每一个需求除非孵化成熟,否则不能进入下一个环节:概要设计。

需求需要拆分到每一个feature。每一个孵化成熟的需求都对应一个正式的需求编号。

在Redmine中管理概设详设

新建子Project“概设详设”,开发组长负责,需求、大拿支持。

要求关联对应需求子任务feature;

概设和详设完毕,拆分任务单到开发任务;

在Redmine中管理开发任务

新建子Project“开发管理”,以项目原型一级菜单为基础,建立问题类别。以二级菜单为问题类别下的功能包,三级菜单作为feature。若预估人月大于2天,建议拆分到0.5天或更小的子任务;

在Redmine中管理测试和缺陷

新建子Project“测试和缺陷管理”,由测试组长负责;

最好是搭配testlink集成到redmine统一管理测试:有待验证;

测试和缺陷一般都是不分家的。如何协调好测试任务和缺陷任务的关系,是一个不小的挑战。甚至还会追溯到需求任务管理。有熟悉的大神,希望能指教一二。

新需求管理

"变更治理"或许更合适。

新建子Project“新增需求管理”,或者合并到“需求分析”project中。以问题类别来区分。

涉及到版本迭代和新功能增加和旧功能迭代,这个是要平衡的艺术。

新增需求,或者从缺陷中反馈的需求,需要整理集中起来,定期或不定期开评审会议:接受或拒绝;

接受则走需求新一轮流程;

拒绝则明确发文给出反馈;

最烦混沌状态:热情隆重又啥也没说,不接受不配合也不拒绝;

遇到这种项目,如果不能通过努力影响之、改变之,还是尽快撤退换地方吧。

PM技能:开会

会议是沟通的桥梁。牢记会议的目的。会议的主要形式及产出物有:晨会、周例会、周报、里程碑汇报、项目启动会、结项会议。主要涉及干系人和沟通计划。

编号类别作用
1项目启动会“名正言顺”
2晨会站立会议,短平快。
3周例会跟进计划,通报和表扬。
4周报任务跟进、风险识别
5里程碑汇报评审,基线
6结项会议“职责交接清晰,不留后遗症”

作者:蛮大人                    

来源:https://my.oschina.net/hexie/blog/1359042


点击查看更多内容
4人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消