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

本文版权信息作者：Jake Lin（Jake's Blog on 博客园）
出处：http://www.cnblogs.com/procoder/archive/2010/02/10/About-Open-Source-4.html
本作品由Jake Lin创作，采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。 任何转载必须保留完整文章，在显要地方显示署名以及原文链接。如您有任何疑问或者授权方面的协商，请给我留言。

背景

随着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版本。

真实的版本

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

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

Future版本

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

Konwn Issues版本

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

状态

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

类型

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

举一个实例：

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

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

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

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

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

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

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

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

优先级

优先级很好理解，如下图：

组件

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

如何使用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的管理也是非常重要，后续讲。