前段时间刚跳公司的SPM研发项目，在即将离别之际自己总结了在项目所得所失，感慨万千呀,虽然该项目在我个人心中应该算一个失败的项目（研发项目吗，都说是无底洞），但项目的一些规范与管理方式我个人认为还是可以借鉴，比如基于Team Fundation Server的Task项目管理！言归正传，首先简述一下什么是SPM(Software Procedure Manage)，SPM即软件过程管理，我在上一篇文章中提到过软件规范化生产，如果一个公司要实现软件规范化生产除了资金链和业务线以外，最重要的就是能支撑这些生产流水线的一个平台，更深层次应该包括对这些项目生产过程中的一些宏观与微观的管理。
Team Fundation Server:TFS（Team Foundation Server ）是一个工作流协作的引擎，它允许一个团队使用他们自定义的流程，并使用在项目历史中实时收集起来的一个集中的数据仓库。Team Foundation Server 和 Visual Studio Team System 中其它的部分一起，组成了软件开发过程中的核心部分。我们的方法是唯一的，因为前端的设计有良好的可用性，而后端的设计集成了整个生命周期。我们主要关注于可用性，以及为个人和团队以一种无缝的方式进入软件开发周期。客户关心的另外一个方面是灵活性和审核。Team Foundation Server 支持 Software Engineering Institute 的 CapaBIlity Maturity Model (CMMI) 的报表和审核的功能。通过 Team Foundation Server，组织可以自动收集必要的信息，并生成自定义的报表，它可以帮助在工业管理中定位增长点。
Task:即工作项，我们在TFS中我们可以看到TFS是通过工作项来对不同工作项还区分软件过程的一些任务的，比如用户情景、Bug、任务等。
上面简单的简介了，面下我们正式讨论是如何基于Team Fundation Server的Task进行软件生产与管理,首先我们把软件生产按敏捷开发的方式，以迭代进行划分。然后我们对软件的生产人员进行划分，我们初步定义为项目经理、程序经理、开发人员、测试人员等。而这人员在按照敏捷模式进行工作时或多或少的会接收到一些工作任务。比如分析需求、编写用户场景、进行设计、编码代码、测试功能点、修改bug等。我统统将这工作称为Task，并且这些Task可折分，可更改的。我可以对大的Task折分成小的Task,而这个折分过程实际上就是工作任务的细节，我对这此Task添加一些属性，比如：
标题:用来明确工作任务的人
工分：量化工作任务的价值
指派给：接收任务的人
区域：附于的项目
状态：标识任务的进展情况
优先级别、预计开始时间、实际开始时间，工时等等属性。
有了这些属性我们可以过些属性对项目的一些KPI值进行微观的调整，并能对通过对这些KPI调整使项目回归正式，另外我们可以统计这些属性很好的形成软件生产报告。
下面以一个例子还描述：
假如一个项目中有一个开发组长与一个开发人员，这里开发组长除了进行基本的开发工作外还负责一些项目的基本的管理：
1、根上面的需求我们需要开发一个记事本。
2、开发组长拿到需求后，对这些需进行折分，将其折分为能在短时间（这个时间应该根据公司的情况与客户的情况与界定）完成小Task.并将其指派给开发人员。当然所有Task属性均为初始状态。
3、开发人员收到相应Task，根据需求进行相关的开发，并即时更改Task的状态，一直到任务完成。
4、开发人员完成任务，并关闭这个Task，随之将后产生另一个task（测试人员的工作）,测试人员开始进行测试（如果测试完成就可以更改这个工作项的状态），如果测试过程产生bug,我们这些bug与这个开发人员的task进行连接。因为我们在修改bug过程中会使用工时，也是一种工作任务。
5、项目进行到一定阶段后，我们可以对这些属性统计比如工时，我们共计使用的多少工时，项目的预工时是多少。
6、最后形成的报告，不仅可以进行汇报也是使管理人员对软件生产与管理提供一个提导。
当然这些功能我们完成可以由Project Server来做，但是我们知道Project Server主要是面向管理人员的提供项目的人员，资源，进度的管理。而Tfs除了面向管理人员进行基本的管理外，还面向工程人员进行软件生产的代码管理等功能。另外如果我们在外围开发一些功能，形成一个大的功能集功。这样就可做软件规模代生产的机器了，这上面提出的这种管理方式只是基于这种机器的一种模式。
欢迎大家讨论！