开源那些事儿(四)-如何使用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版本。

真实的版本

例如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的功能不够完善。