开源那些事儿(四)-如何使用CodePlex进行项目管理

背景

随着iToday项目的发展,人员的扩展,需要一定的项目管理流程来保证项目不会流产。一个具有一定规范的开源项目,单靠个人激情和能力来完成项目的几率非常的低,没有项目管理流程,后续开展会变得困难,项目的可延续性也得不到保证。因此需要想办法实施有效的项目管理。

 

简介

本文讲述如何使用CodePlex进行开源项目的管理。

 

项目管理理论与个人理解

书本上的项目管理定义了九大关键域,包括范围管理 风险管理 沟通管理 质量管理 时间管理 成本管理 人力资源管理 采购管理 整合管理。包罗万象,林林种种。但是到了实施过程中每个人都有自己的理解,我对项目管理的理解是:有效利用有限的资源,使用一定的控制手段,达到预定的目标。 由于人力资源,资金成本等是永远都有限,特别是开源项目,主要由有兴趣的贡献者参与,人员不能保证,所以如何有效利用有限的资源很重要。在有效的资源下,通过计划,沟通等手段保证把有限的资源能充分的发挥作用,例如做开源的时候把贡献者安排到其最感兴趣的领域,发挥其最大的作用。这些控制手段同时包括风险控制和质量控制,使用版本管理工具一定程度的减低风险。完成预定的目标这个很重要,资源本身有限,时间也是有限,制定一个可预见的目标十分重要,我会使用版本管理来指定目标。下面讲述如果通过Codeplex实施项目管理,来达到我理解的项目管理目的。

 

项目管理原则

我的原则是尽量减少所有Stakeholder(项目干系人)的工作,同时最大程度的保证项目的可延续性。这本身就是博弈,世界没有银弹,只能尽量均衡。这里说的stakeholder包括开发者,测试者,协调人员等等,大家都是无偿的贡献,没必要走一个很完美的流程,例如CMMI那些来增加大家的工作量,所以我尽量的简化项目流程,使得大家可以专注于自己喜欢的事情上。在尽量少的项目管理工作来保证项目的延续性。

 

Codeplex Issue Tracker

我使用Codeplex 的 Issue Tracker功能进行项目管理,地址如下: itoday.codeplex.com/WorkItem/List.aspx ,因为Codeplex本身带了这个系统,不需要另外找项目管理系统,尽管这个系统不是很完善,我们还是可以在其基础上使用。

 

Issue Tracker是一个问题跟踪系统,一般用在bug处理上,但是也可以用到需求管理,任务分配,版本控制等功能,下面讲述每个Issue包含了那些内容。

 

版本

我认为版本是Issue最关键的信息,代表着目的与目标,任何Issue都是有目标而做的。当前我把版本分成三类,真实的版本,Future版本和Konwn Issues版本。

open-source-project-management-9

真实的版本

例如V 1.0.0, V2.0.0那些,就是需要发布的版本,在开源软件里面是提供给用户下载的版本,也是需要完成的目标。

 open-source-project-management-6

上面是Version 1.0.0的需要完成的功能,我们把需求作为Issue关联到Version 1.0.0,一旦完成了这些需求,就可以发布Version 1.0.0了。当然在开发过程中如果发现bugs,而且这些bugs关联到Version 1.0.0,那么发布之前也需要修改这些bugs,发布版本的标志是完成该版本下所有的Issues。

 

Future版本

由于资源的有限性,不可能在一个版本内完成所有的需求,那么一些需求需要放到Future版本中去了。这些需求可能在未来的版本中实现。

open-source-project-management-8

Konwn Issues版本

有些问题在当前版本中存在,但是由于某些客观条件限制,不能在当前版本中实现,可以归类为Known Issues。

 open-source-project-management-7

 

状态

每个Issue都有状态,包括计划的,活动和已经修改的,创建Issue的时候是Proposed,Assigned to的人会开始处理这个Issue,修改为Active,如果Issue完成了就改为Fixed。发布版本之前所有Issues都应该为Fixed。在我看来,这些状态是不够的,太简单了,至少需要Won't Fix和Duplicate,Cannot Reproduce,有些所谓的bug是不需要fix的,有些Issue是重复的,有些bug是不可重现的。所以我说Codeplex Issue Tracker的功能不够完善。

 open-source-project-management-2

类型

类型分Feature,Issue和Task。Feature是软件具备的功能,可以理解为需求。Issue是一些问题,可以理解为bug。Task表示一些任务,包括各种任务,例如实现需求的子步骤,编写文档,一些项目管理工作等等。

open-source-project-management-3

举一个实例:

我们需要完成Weather Panel的功能。

我新建了一个“新增Weather Panel”的Feature。

open-source-project-management-11

链接在http://itoday.codeplex.com/WorkItem/View.aspx?WorkItemId=5992

 

同时实现这个Feature至少需要下面两个子任务(Task),可能更多Tasks,但是先列举两个。

open-source-project-management-12

链接在 http://itoday.codeplex.com/WorkItem/View.aspx?WorkItemId=5993

open-source-project-management-13   

链接在 http://itoday.codeplex.com/WorkItem/View.aspx?WorkItemId=5994

 

作为类型,我觉得只有Feature,Issue和Task是不够的,我们使用的另外一套系统中,类型包括下面那些:

open-source-project-management-10

但是CodePlex只是提供那么多,我们先用吧。

 

优先级

优先级很好理解,如下图:

open-source-project-management-4

 

组件

当前iToday有两个组件,一个是Panels,表示应用,如何Home,Weather,Contact Panel那些。而UtilityLib表示一些非UI的公开库,例如WebService属于UtilityLib。

open-source-project-management-1   

 

如何使用Codeplex Issue Tracker进行项目管理

流程

项目开始之初收集需求,所有需求都记录下来作为Feature。

然后定义版本,例如定义Version 1.0.0,把需要实现的需求作为Feature绑定到Version 1.0.0中,分派任务。

得到任务的开发者可以根据需求自己定义子任务,例如上面例子的封装WebService等等。

开发人员把任务变成Active,开展自己的开发工作。

任务完成后,把任务变成Fixed。

版本Version 1.0.0下所有Issues变成Fixed以后,项目协调人统一发布版本。

定义版本Version 1.0.1,作为Version 1.0.0的完善版本。

测试人员开始测试,使用Issue Tracker提交bug,类型为Issue,关联到Version 1.0.1。

修改Version 1.0.1下所有问题,Fixed所有Issues,发布Version 1.0.1。

周而复始(Version 1.0.1,Version 1.0.2……),一直完善当初Version 1.0.0下的所有Feature。注意不需要把新功能加入Version1.0.1,否则Issue会越来越多,新需求是Version 2.0.0或者Future版本。

与此同时可以定义Version 2.0.0,从Future版本中的一些Feature移到Version 2.0.0,重复Version 1.0.0的步骤。

 

Version 2.0.0和Version 1.0.0需要同步,这里包含了如何使用SVN等细节,但是不影响Codeplex Issue Tracker的项目管理流程,我先不在这里讲述了。

 

贡献者责任

各种贡献者如何使用Codeplex Issue Tracker来完成项目管理流程如下:

项目协调人:定义版本的Feature。分配任务(Feature和Task)。发布版本。

开发人员:定义子任务(Task)。开发。提交版本。

测试人员:提交bug(Issue)。

 

我觉得流程很简单了,如果可以简化继续简化。这是一个蓝本,大家在实施过程中做流程完善。有问题及时提出,及时修改流程。

 

还有SVN的管理也是非常重要,后续讲。

 

关于iToday项目

可以参考

开源(Open Source)那些事儿 (一)

开源那些事儿 (二) - iToday开源项目计划

开源那些事儿(三)-iToday的总体设计 

 

 

posted @ 2010-02-10 07:14  Jake Lin  阅读(4562)  评论(10编辑  收藏  举报