背景
随着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的管理也是非常重要，后续讲。
关于iToday项目
可以参考
本文转自Jake Lin博客园博客，原文链接：http://www.cnblogs.com/procoder/archive/2010/02/10/About-Open-Source-4.html，如需转载请自行联系原作者
