团队开发规范.docx

团队开发规范.docx

《团队开发规范.docx》由会员分享，可在线阅读，更多相关《团队开发规范.docx（14页珍藏版）》请在冰点文库上搜索。

团队开发规范

团队开发规范

文档信息：

文档名称

团队开发规范

描述

该文档详细定义了团队开发的角色及职责、项目开发流程、开发过程控制的约定、协作开发的约定、代码版本控制、交流机制等

负责人

佘及仁

状态

最终版

文档变更历史：

时间

修改人

章节

描述

2003-2-15

佘及仁

所有章节

创建文档初稿

2003-5-8

佘及仁

代码管理

添加签入（Checkin）报告模板

文档路径：

$/BlueHill/HR/Documents/

审核结果：

审核人

意见

签名档

佘及仁

通过

佘及仁

1团队组成

整个团队由六种角色组成，分别为

∙产品管理（ProductManagement）

∙项目管理（ProgramManagement）

∙开发人员（Development）

∙测试人员（Test）

∙用户教育人员（UserEducation）

∙发布管理（ReleaseManagement）

各角色在团队的地位相当，各司其职。

各个角色的具体目标、职能以及责任在以下的小节中进行详述。

1.1产品管理

（1）目标

满足客户需求。

产品管理的目标就是满足客户需求。

一个成功的项目必须要能够满足客户和用户的要求。

即使项目达到了预算和时间的目标，只要未能满足客户需求，那这就是一个失败的项目。

首先必须认清和理解客户。

有时，使用方和投资方的目标需求并不完全相同，因此就需要清晰地区别和分析所有的需求。

（2）职能

∙市场

▪推动市场和公关，以对目标客户发生效用

▪突出产品与其他竞争对手的区别性，以利于竞争

▪分发解决方案，以便用户能够容易地获得

▪为用户提供支持，以使其无论在购买还是使用过程中都留下正面的印象

∙业务价值

▪定义并维护项目的业务正确性

▪定义并衡量业务价值的实现和评价

∙发展客户

▪推动项目和解决方案的远景目标

▪负责客户期望值和沟通

∙产品计划

▪收集、分析客户和业务需求，并区分其优先级

▪执行市场调查、市场开拓和竞争对手分析

▪确定业务和成功的标准

▪识别多目标的发布计划

1.2项目管理

（3）目标

在项目的约束条件下完成解决方案。

整个团队的一个主要目标就是在项目的约束条件下完成项目。

项目的约束条件包括预算和进度等。

大部分项目会根据时间和资金的使用来衡量项目的结果。

为了实现这个目标，项目管理负责并推动进度表、功能集和预算资金。

他必须保证能够在正确的时间发布正确的项目或产品，保证正确理解了项目投资方的期望，并自始至终贯穿于项目执行过程中。

（4）职能

∙项目管理

▪跟踪和管理预算资金

▪管理主进度表

▪推动风险管理流程

▪加强团队沟通和协调

▪跟踪进度和报告项目状态

▪管理资源分配

∙解决方案构建

▪推动整体项目设计

▪负责功能规范

▪负责解决方案范围和重要决定

∙流程控制

▪推动流程质量控制

▪定义并推荐可改进处

∙管理服务

▪实现项目的管理流程并提供支持

▪提供管理服务以保证高效的团队运作

1.3开发

（5）目标

按照功能规范说明进行开发。

功能规范说明详细描述了整个团队将要提供给客户的交付物。

对整个团队来说，应该尽可能精确地按照功能规范说明来实现整个项目，因为功能规范说明可以看成是整个团队和客户之间所达成的共识。

开发人员必须按照客户需求和功能规范说明来构建整个解决方案。

同时，开发人员还需要为整个团队提供技术方面的咨询，这样在设计和技术选择时可以尽量减少开发风险。

开发人员提供较低层次的功能设计，并预估完成设计所需的时间。

（6）职能

∙技术咨询

▪为团队提供技术咨询服务

▪评估并验证所用技术

▪积极参与功能规范说明的创建和审核

▪定义开发标准

∙实现架构和设计

▪提供针对解决方案的应用程序、数据和技术细节，以便将企业架构映射到解决方案架构的实现上

▪负责并实现解决方案的逻辑和物理设计

∙应用程序开发

▪根据设计规范编写代码以实现功能

▪在开发过程中进行代码审核，并共享知识和经验

▪在测试人员的帮助下，根据测试计划执行单元测试

∙架构开发

▪为自动安装开发脚本

▪开发安装文档

1.4测试

（7）目标

在确认所有的产品质量问题都得到妥善处理后，批准产品发布。

所有的软件产品在发布时都存在着缺陷。

最重要的是，在发布前，必须清楚地认识和鉴别出这些问题，可以以问题的形式给出解决方法，或者是给出如何绕开该问题的文档记录。

宁愿对于已知的问题，提供了文档或解决方法，也不要存在一些未知的问题。

因为这些未知的问题，可能会带来不可预知的后果。

（8）职能

∙计划测试

▪开发测试方法和计划

▪参与设置质量标准

▪开发测试说明

∙测试

▪开发并维护自动测试案例、工具和脚本

▪执行测试，以确定产品开发过程的状态

▪负责定义构造流程

∙测试报告

▪为团队提供与产品质量相关的数据

▪跟踪所有缺陷，并保证在发布前得到妥善处理

1.5用户教育

（9）目标

提高用户使用效率。

为了使得产品取得成功，必须要增强用户工作和操作的方式。

即使产品具备了丰富的功能或内容，但只要对目标用户的可用性差，那么这还是一个失败的产品。

（10）职能

∙技术沟通

▪为技术支持设计和开发文档

▪开发帮助文档

∙培训

▪开发和执行学习策略

∙可用性

▪收集、分析用户需求，并区分优先级

▪为解决方案设计提供反馈和输入

▪开发使用场景和用户案例

▪在团队中扮演用户的角色

∙图像设计

▪推动用户界面设计

∙国际化

▪改进解决方案在国际市场上的质量和可用性

∙辅助功能

▪推动在设计时加入辅助功能的概念和需求

1.6发布管理

（11）目标

顺利发布和后期运作。

不能忽略顺利的发布过程。

如果安装过程错误百出，那么用户可能认为安装的产品也是同样的。

所以对于整个团队来说，发布并不是目标，需要的是一个顺利而平滑的发布过程。

必须确认在发布以前，培训、基础架构和技术支持已经全部就绪。

（12）职能

∙架构

▪企业架构计划

▪协调物理环境的计划和使用（数据中心、实验室、分公司等）

▪为团队提供持续的架构管理和标准政策以及手续

▪管理团队的硬件和软件需求

∙支持

▪为IT用户提供联络和客户服务

▪提供问题解决方案，快速回应用户并记录发生的问题

▪为开发和设计提供反馈

▪开发故障转移和恢复流程

∙运作

▪账户和系统安装控制，管理用户账户和权限

▪消息传递、数据库、通信运作、网络运作

▪系统管理、批处理操作

▪防火墙管理、安全管理

▪应用程序服务

▪主机集成服务

▪目录服务运作

∙商业发布管理

▪产品注册码、注册验证流程

▪许可证管理

▪打包

▪管理分发渠道

▪印刷和电子出版物

1.7角色共享

尽管团队组成包含了六种角色，但并不意味着一个团队至少需要六个成员，也不意味着一个人只能承担一种角色，重要的是这六种角色必须在一个团队中体现。

一般情况下，团队成员常常共享角色。

在一些较小的团队中，不同的角色只能进行兼任。

角色共享有两条重要原则：

一是开发组成员不能共享角色。

开发人员是项目的构建者，他们不应该从他们的主任务中分身。

如果对开发组成员要求额外的角色，往往会使得他们无法按时完成进度要求。

二是不要试图组合具有一定利益冲突的角色。

比如，产品管理和项目管理的利益具有冲突点，所以他们的角色不能组合。

产品管理注重满足客户需求，而项目管理主要关心在时间和预算的限度内完成项目。

如果这两个角色组合在一起，那么在需求发生变更时，可能会发生一些情况，诸如没有足够地考虑客户满意度而忽略该变更，或者是没考虑对项目的冲击盲目地接受变更。

让不同的团队成员担任这样的角色有助于确保每个方面得到相当的考虑和重视程度。

同样，这也适用于组合开发人员和测试人员。

图1显示了可能会引起风险（N和U）以及可能产生协作作用（P）的角色共享。

图1角色共享

2开发流程

在开发过程中，采用多里程碑式的过程模型，如图2所示。

而其中每一个循环均包含四个里程碑。

图2多里程碑模型

这四个里程碑组成的循环放大后如图3所示，称为“过程模型”。

图3过程模型

2.1达成共识

∙基本完成需求调研和分析（产品管理负责）

∙确定大方向和长中短期目标

∙所有角色都参与讨论并真正认同结论

∙产生的文档

▪常见用户情景：

覆盖80%以上功能

▪前景：

言简意赅地说明大方向，并有激励团队的作用

2.2完成项目计划

∙编写详细的功能规范（项目管理负责）

∙在编程前想清楚所有功能流程，并引导用户明确需求

∙所有角色都参与审阅功能规范

∙制订开发计划和进度表（开发团队）

∙制订测试计划和进度表（测试团队）

∙分配资源（人力和预算）

∙形成项目综合计划和综合进度表

2.3完成功能

∙开发人员分别完成自己的功能

∙使用版本控制工具

∙对每一项可测试的功能进行测试，无需等待

∙通过测试用例，对功能进行完整和重复的检验

∙记录所有程序问题

∙实现解决缺陷的自动流程

∙按照综合进度表不断检查进度

2.4稳定与发布

∙测试组全面地测试功能，包括性能和稳定性

∙开发组全力配合解决缺陷

∙监测质量情况

∙预测发布日期

∙专家会诊机制

▪决定缺陷的优先度

▪决定哪些缺陷可以在下个里程碑或版本中解决

▪决定由谁解决某个缺陷

3代码管理

3.1代码规范

请参看相应的代码规范文档。

3.2版本管理

（1）概述

版本控制有如下好处：

∙可以获得连续的受版本控制的项目，并保存不同版本的区别以作比较

∙能获得版本控制工具中保存的任何版本

∙能够把出错或误操作的最新版的项目恢复到正确的历史版本

∙获得历史版本的详细信息

在开发过程中，使用VisualSourceSafe6.0进行版本控制。

它能够防止用户文件意外丢失，并能对以前版本跟踪；对源文件进行分支（branch）、共享（share）、合并（merge）操作，同时对整个项目进行版本控制。

VisualSourceSafe6.0的具体使用方法，请参看VSS使用手册。

（2）代码管理

MicrosoftVisualSourceSafe是将文件保存在网络上的一个中央数据库中，而不是保存在一个普通的文件夹下。

当通过VisualSourceSafe观看时，这个数据库看上去包括了以项目层次树方式组织的所有文件和历史记录。

当获得了一个文件时，VisualSourceSafe会在它的数据库中将该文件标记为已被你签出（Checkout），而后允许你在你的机器上对该文件进行修改。

当你将文件签入（Checkin）时，VisualSourceSafe会更新它的数据库并把你机器上的该文件的访问权限改回为只读。

针对每一个改动，VisualSourceSafe数据库都会记录和跟踪项目信息。

每当从项目中添加了一个文件，修改了一个文件或者共享、移动、删除了一个文件，VisualSourceSafe都会同时共享文件和项目的历史记录。

在开发之前先从VSS服务器上获得最新版本的源代码，对代码做修改之前先要签出（Checkout），在代码修改完成之后签入（Checkin）之前需要完成一系列的如下步骤：

1）从服务器上获得最新的源代码（获得最新版本，GetLatestVersion）

必须从服务器上获取整个项目的所有的源代码到本地，对于自己已经签出（Checkout）的文件，VSS会提示是覆盖、不覆盖、还是归并。

必须选择归并（Merge）。

2）重新编译本地的所有源代码（RebuildAll）

允许签入（Checkin）到服务器的源代码的最低要求就是能够通过编译，否则是不允许签入（Checkin）的，同时最好能够去掉编译警告。

3）代码审查（CodeReview）

在VSS中对签出（Checkout）的文件选择版本比较（ShowDifference），向自己的同事解释本次对源文件做的修改。

同事帮助其确认是否的确解决了需要解决的问题、是如何解决的，以及算法是否还可以优化、代码是否符合编程规范、是否还有潜在的错误。

4）签入（Checkin）

完成了代码审查之后可以签入（Checkin）源代码。

如果代码审查的时间过长，则还需要重复做一次以获得最新的源代码和重新编译，来保证这段时间内别的同事所做的操作不会与自己做的操作发生冲突。

5）发签入（Checkin）报告

签入（Checkin）之后需要给整个开发团队发一个报告，为的是让别的同事知道现在项目的进度。

报告中必须注明：

本次签入（Checkin）的目的、和自己一起做代码审查的同事的名字、代码审查的具体内容、是否做过单元测试、签入（Checkin）的所有文件的列表。

格式如下：

目的描述：

[描述该次签入（Checkin）的目的]

产生的影响：

[对其他模块代码可能的影响]

审核人：

[帮助审核的同事姓名]

步骤：

是否从VSS获得最新版本（GetLatestVersion）？

[Y/N]

是否重新编译所有源代码？

[Y/N]

代码是否符合编程规范？

[Y/N]

代码中是否存在潜在的缺陷可能性？

[Y/N]

是否有解决问题的更好方法？

[Y/N]

是否通过了单元测试（Unittest）？

[Y/N]

文件列表：

[签入文件的列表]