在和一个朋友聊天下发现是应该整理下自己在这方面的东西，其实以前零散的也整理过其中的一些，只是完整的一直就没很好的整理，现在贴出的这个也只是相当于目录结构式的：

　　

　这份基本是个目录式的，明天按照这个结构完整的写出一篇关于软件过程规范的文章，主要是完整的进行描述，对于软件过程规范，我还是那么认为，每个team有每个team适合的过程规范，要灵活和不断的调整，不能顽固不变！
　
　一. 概述

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

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

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

二. 软件过程

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

2.1. 里程碑计划制定

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

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

2.2. 迭代计划制定

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

2.3. 迭代过程

2.3.1. 需求分析

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

2.3.2. 设计

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

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

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

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

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

2.3.3. 开发

开发过程中涉及的有：

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

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

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

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

2.3.4. 重构

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

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

2.3.5. 持续集成

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

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

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

三. 任务规范

3.1. 任务分配

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

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

3.2. 任务完成

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

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

3.3. 任务跟踪

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

四. 工具

涉及的工具主要有：

　任务跟踪工具

　版本控制工具

　持续集成工具

　Bug跟踪工具

　开发工具

五. 制度

5.1. 早会

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

5.2. 发布会议

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

5.3. 迭代会议

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

5.4. 设计会议

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

5.5. 项目周报

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

5.6. 项目成员积分制度

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

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