一.  概述

本文主要对于软件过程的整体规范进行较为完整的描述，来源于个人的项目经验、所在team使用的软件过程以及个人的一些想法总结而成。

文章按照对项目中采用的软件过程进行描述，之后对保证整个软件过程有效执行的工具、制度等进行描述。

本文意并不在标明这个软件过程是多么的优秀，关键是要找到适合自己团队的软件过程，没有最优秀的，只有最合适的。

二.  软件过程

此软件过程是根据Team以及XP制定的，图示如下：

2.1.       里程碑计划制定

控制在一个月范围内，每个里程碑应有突出性进展的部分，里程碑版本的发布具有很强的意义，每个里程碑版本在功能或非功能性方面应有明确的对比。

在每个里程碑结束时发布里程碑版本并同时给予项目组一定的休息时间。

2.2.       迭代计划制定

控制在一至两周范围内，每个迭代周期结束后对客户发布迭代版本。

2.3.       迭代过程

2.3.1.       需求分析

在迭代的需求分析中主要为对划定在此迭代阶段的需求进行详细的分析，产生出用户故事。

2.3.2.       设计

设计主要通过对用户故事进行OOAD产生出符合此用户故事的领域设计，以此建立的领域模型结合架构构成完成用户故事的设计，产生CRC Card，最后进行情景测试(Scene Test)。

设计时需要遵循的三个原则：

l         Domain Model驱动

以Domain Model作为驱动进行设计，通过对用户故事的OOAD产生用户故事的Domain Model，基于此根据架构完成整个用户故事的设计。

l         Simple

简单够用，这个是最为难掌握的，说的直白点就是先采用能够想到的一个最简单的设计去实现功能，至于这个设计是不是那么的合理先不要太多的去理会，在完成了功能后可以不断的对其进行重构，其实其原理就是”一步一个台阶，直至云霄，而不是一步登天”，每个团队的不同仅在于这一个台阶能迈多高而已。

l         集体参与

迭代过程的设计由项目组共同参与，项目组成员可随意的发表各自对于系统实现的设计的想法。

2.3.3.       开发

开发过程中涉及的有：

l         编码规范

编码规范需在项目开始时即制定，这个需要根据每个公司以及团队的情况来决定，在Java编码规范中通常要涉及的有类文件规范(主要是文件的版权、文件格式等)、命名规范(包名、类名、方法名、变量名等)、注释规范。

l         TDD

按照先编写单元测试后进行代码编写的原则，在单元测试中主要需要对代码的逻辑、性能以及边缘进行测试。

l         PP

双人编程，在进行代码编写时必须两人一起进行，一人操作键盘，一人旁边观看，同时进行思考。

l         Code Review规范

代码复查规范需要按照各个公司以及代码规范来进行制定。

2.3.4.       重构

在开发结束后需要考虑代码的重构，主要从OO的各原则以及设计原则来进行提升，复用性、性能等都是考虑的因素。

重构时可采用IDE提供的重构支持来快速完成，对于设计的重构可以通过设计会议来共同讨论，在重构时甚至可考虑推翻原有所有的设计而进行。

2.3.5.       持续集成

持续集成采用感应版本控制工具变化而进行的原则，即有变化提交至版本控制工具时即进行持续集成，在持续集成失败或成功的情况下均发送邮件通知相关人员，项目组所有人员均可通过网站查看持续集成的情况。

持续集成中主要需要进行的工作是编译所有源码、运行单元测试、按照系统手动部署方式自动完成部署工作、运行功能测试、发布测试报告并通知相关人等。

持续集成的原则为谁造成失败谁负责。

三.  任务规范

3.1.       任务分配

在对用户故事完成设计时即可进行任务的分配，每个任务拆分到1—2天的范围内，对于难以估计的任务先进行spike之后再行分配，spike的时间限制在1周以内。

由项目组成员自行挑选任务。

3.2.       任务完成

在完成任务的过程中成员需进行任务完成时间的跟踪，原则为在开始任务时填写任务开始时间，在停止编写任务的时候填写时间点，在任务完成时勾选完成任务。

此时间也将作为将来分配任务时时间的估计，以使得对于任务的完成时间的估计能够越来越精确。

3.3.       任务跟踪

任务跟踪通过任务跟踪工具来完成，主要是任务完成的时间、任务统计等。

四.  工具

涉及的工具主要有：

l         任务跟踪工具

l         版本控制工具

l         持续集成工具

l         Bug跟踪工具

l         开发工具

五.  制度

5.1.       早会

早会时间大概在10---15分钟，主要是对昨日任务的回顾、难点的提出、今日的计划以及partner的挑选。

5.2.       发布会议

发布会议为里程碑计划的宣布，以使项目组成员能够明确里程碑的目标以及时间点，同时也听取项目组成员的意见。

5.3.       迭代会议

迭代会议为每个迭代周期前进行召开，以使项目组成员明白迭代目标以及时间点，同时听取项目组成员的意见。

5.4.       设计会议

设计会议在每个迭代周期开始的时候进行召开，以确认迭代中需求的设计实现、任务分配等。

5.5.       项目周报

项目于每周五下班时提交项目周报，主要是向客户、公司相关人员、项目组通报项目的进展情况、下一步工作计划。

5.6.       项目成员积分制度

项目成员积分作为对项目组成员的考核以及奖金分配的依据。

项目成员积分主要从任务的完成时间、质量、任务过程中表现出的团队合作、责任心、态度等进行评价，对表现特别出色或不合人意的进行适当的奖惩。

       项目成员积分制度作为项目成员工作评价以及项目奖金分配的唯一依据。

       积分采用如下方法进行考核，以项目任务为考核点，基于任务的技术难度、时间紧急性来作为任务的客观分数，对于任务承担人则结合客观分数进行任务完成的时间、质量、在完成任务中表现出的责任心、造成日构建的失败次数作为评估依据，表格如下所示：

产品过程之产品规划篇

本文针对产品过程中的产品规划过程进行描述，说明此过程的要点、注意事项等。

一.  概述

任何事情在开展之前往往都有一个规划，规划又分为长期规划、中期规划和短期规划，在规划中制定了在当前阶段需要达到的一个目标、基本的工作思路以及工作计划，对于事情的顺利开展具有方向性的指导意义。

产品规划作为产品过程的第一个正式的过程，此过程对于产品的发展方向、发展过程等具有指导性的意义，产品规划所做的是一个长期的规划，所以在制定的时候需要考虑多方面的因素。

二.  要点

产品规划作为产品发展方向、发展过程等的指导性文件，产品的起因、产品的定位、产品的蓝图规划、版本规划、里程碑规划、市场同类产品的对比、推广方式是其要点。

2.1.       产品的起因

此部分中阐明对于产品的构思的来源，产品的起因通常来源于两种，一是公司项目的积累，二是市场潜力的挖掘。

对于公司项目的积累的起因则需要阐明历史项目的经验并说明为什么可发展成为产品。

对于市场潜力的挖掘方面则需说明市场潜力体现在了哪些地方。

2.2.       产品的定位

产品的定位至关重要，在一开始有个明确的定位能帮助产品按照一定的方向进行，而不至于偏离方向或临时摸索方向，虽然在产品的后期发展中适时调整方向也是必须的，但至少在一开始的时候树立一个定位不至于在说起这个产品的时候还说不出它的一个适用方向。

2.3.       产品的蓝图规划

产品的蓝图规划则为产品按照未来发展方向制定的一份发展蓝图计划，在蓝图中需要有效的描述产品的未来，至少要让人觉得这个产品的将来确实是非常的光明，如果连蓝图都不能给别人信心的话，那这个产品是否要做真的需要仔细商酌。

产品的蓝图规划中甚至可以举些吸引人的场景，让人觉得产品确实非常的实用。

产品的蓝图规划中还需要有对于产品优点的一些突出描述，这些描述也就成为产品将来的卖点，也是开发过程中首先需要把握的部分。

2.4.       版本规划

产品往往是一个长期战略目标，虽然可能已经想到了很多的可做的有前途的部分，但不可能划分在一个时期内全部做完，需要按照产品的卖点进行重点的攻关，往往来说对于产品的第一个版本在于突出产品的卖点所在，之后的第二个版本在易操作性、友好性等方面进行加强，之后的版本也许是更加的突出产品的优势。每个版本都需要有非常明确的目标和令人感觉明显的差别，并且在每个版本中都应该有突出的卖点。

2.5.       里程碑规划

产品的里程碑规划是指对于版本规划的分解，毕竟版本规划是一个大的目标，对于版本的里程碑规划主要按照产品的软件过程制度来进行划分，里程碑的划分同样需要依照一个重要的思想，保证每个里程碑的到达都是那么的振奋人心。

2.6.       市场同类产品的对比

根据产品的定位以及目标和市场同类产品进行对比，在对比中最好列出一份关于两者功能的对比点，分析清楚对方的优势以及己方的优势，并需要分析对手的潜在走势。

2.7.       推广方式

推广方式则主要针对产品的宣传、推广、市场营销策略进行规划，产品是否能够带来实际的利益依靠于此阶段的制定。

三.  总结

产品规划文档作为产品发展过程中的指导性文档，其重要性体现在以上的几个要点部分，产品规划文档至关重要，在后期产品发展过程中产品的需求文档，产品的理念文档，产品的发展计划文档，产品的白皮书文档等都需要从此文档中诞生。

软件界经过多年的发展，一直都朝着一个搭积木的目标，希望软件能够通过对积木的拼凑快速的搭建出应用软件或者说产品，当然和搭积木并不完全相同，一个比喻而已，如今流行着各种各样的这样的思想，如基于插件式的、构件式的，Portal中的Portlet式的，无非都是希望软件的重用性以及可快速使用性得到提升。在这些思想中，Portal的Portlet式以及Eclipse的Plugin机制无非是其中的佼佼者，非常的显眼，一定程度上来说也是这个推动了之前的面向组件、面向服务的软件思想的推广，也做到了以前希望做到的和硬件一样的程度，即插即用。

Plugin机制的好处不言而喻，但基于插件式系统在插件交互的问题上好像一直就没有得到很好的解决，这点就和搭积木不同，积木之间不需要共享数据等等，^_^，而Plugin之间则相对不同，Plugin的互相通讯、共享数据这个是很正常的需求，我们并不能指望Plugin完全独立的实现一个部分，这个在少部分的Plugin可以如此，但绝大部分是不行的，想必大家还记得IoC的一个原则："don't call me"，Plugin之间的相互通讯也通过IoC类似思想去解决？？？？通过IoC容器注入所依赖的Plugin？？？？？

其实说起来如今有很多插件式的系统，这也不是什么新概念，象media player的插件、Maven的插件等等，太多了，在Plugin的通讯、数据共享方面好像都还需要进步，不知道各位有什么看法？？？