团队组成及各部分人员职责与开发规范.doc

名品街团队开发规范 2012-02-02 制作人：孙路桃1 团队组成及各部分人员 职责与开发规范 名品街团队开发规范 2012-02-02 制作人：孙路桃2 文档信息：文档信息： 文档名称团队开发规范 描述该文档详细定义了团队开发的角色及职责、项目开发流程、开发过程 控制的约定、协作开发的约定、代码版本控制、交流机制等 负责人孙路桃 状态最终版 文档变更历史：文档变更历史： 时间时间修改人修改人章节章节描述描述 2007-02-15孙路桃所有章节创建文档初稿 2012-02-02孙路桃代码管理添加签入（Check in）报告模板 审核结果：审核结果： 审核人审核人意见意见签名档签名档 孙路桃通过孙路桃 名品街团队开发规范 2012-02-02 制作人：孙路桃3 目录目录 1团队组成.4 1.1产品管理.4 1.2项目管理.5 1.3开发.5 1.4测试.6 1.5用户教育.7 1.6发布管理.7 1.7角色共享.8 2开发流程.9 2.1达成共识.10 2.2完成项目计划.10 2.3完成功能.11 2.4稳定与发布.11 3代码管理.11 3.1代码规范.11 3.2版本管理.11 (1)概述.11 (2)代码管理.12 名品街团队开发规范 2012-02-02 制作人：孙路桃4 1 团队组成团队组成 整个团队由六种角色组成，分别为 产品管理（Product Management） 项目管理（Program Management） 开发人员（Development） 测试人员（Test） 产品管理：孙路桃 项目管理：孙路桃 具体分工： UI 布局：陈嘉文 C#代码功能编写：钟广瑜，谢家勇，连健萧，王刚 服务器管理与维护：连健萧 数据库管理与维护：谢家勇 团队日常管理：王刚 项目于产品及构架策划：孙路桃，王刚 各角色在团队的地位相当，各司其职。各个角色的具体目标、职能以及责任在以下的 小节中进行详述。 1.1 产品管理产品管理 (1) 目标 满足客户需求。 产品管理的目标就是满足客户需求。一个成功的项目必须要能够满足客户和用户的要 求。即使项目达到了预算和时间的目标，只要未能满足客户需求，那这就是一个失败的项 目。首先必须认清和理解客户。有时，使用方和投资方的目标需求并不完全相同，因此就 需要清晰地区别和分析所有的需求。 (2) 职能 市场 推动市场和公关，以对目标客户发生效用 突出产品与其他竞争对手的区别性，以利于竞争 分发解决方案，以便用户能够容易地获得 为用户提供支持，以使其无论在购买还是使用过程中都留下正面的印象 业务价值 定义并维护项目的业务正确性 定义并衡量业务价值的实现和评价 发展客户 推动项目和解决方案的远景目标 名品街团队开发规范 2012-02-02 制作人：孙路桃5 负责客户期望值和沟通 产品计划 收集、分析客户和业务需求，并区分其优先级 执行市场调查、市场开拓和竞争对手分析 确定业务和成功的标准 识别多目标的发布计划 1.2 项目管理项目管理 (1) 目标 在项目的约束条件下完成解决方案。 整个团队的一个主要目标就是在项目的约束条件下完成项目。项目的约束条件包括预 算和进度等。大部分项目会根据时间和资金的使用来衡量项目的结果。为了实现这个目标， 项目管理负责并推动进度表、功能集和预算资金。他必须保证能够在正确的时间发布正确 的项目或产品，保证正确理解了项目投资方的期望，并自始至终贯穿于项目执行过程中。 (2) 职能 项目管理 跟踪和管理预算资金 管理主进度表 推动风险管理流程 加强团队沟通和协调 跟踪进度和报告项目状态 管理资源分配 解决方案构建 推动整体项目设计 负责功能规范 负责解决方案范围和重要决定 流程控制 推动流程质量控制 定义并推荐可改进处 管理服务 实现项目的管理流程并提供支持 提供管理服务以保证高效的团队运作 1.3 开发开发 (1) 目标 按照功能规范说明进行开发。 功能规范说明详细描述了整个团队将要提供给客户的交付物。对整个团队来说，应该 名品街团队开发规范 2012-02-02 制作人：孙路桃6 尽可能精确地按照功能规范说明来实现整个项目，因为功能规范说明可以看成是整个团队 和客户之间所达成的共识。开发人员必须按照客户需求和功能规范说明来构建整个解决方 案。同时，开发人员还需要为整个团队提供技术方面的咨询，这样在设计和技术选择时可 以尽量减少开发风险。开发人员提供较低层次的功能设计，并预估完成设计所需的时间。 (2) 职能 技术咨询 为团队提供技术咨询服务 评估并验证所用技术 积极参与功能规范说明的创建和审核 定义开发标准 实现架构和设计 提供针对解决方案的应用程序、数据和技术细节，以便将企业架构映射 到解决方案架构的实现上 负责并实现解决方案的逻辑和物理设计 应用程序开发 根据设计规范编写代码以实现功能 在开发过程中进行代码审核，并共享知识和经验 在测试人员的帮助下，根据测试计划执行单元测试 架构开发 为自动安装开发脚本 开发安装文档 1.4 测试测试 (1) 目标 在确认所有的产品质量问题都得到妥善处理后，批准产品发布。 所有的软件产品在发布时都存在着缺陷。最重要的是，在发布前，必须清楚地认识和 鉴别出这些问题，可以以问题的形式给出解决方法，或者是给出如何绕开该问题的文档记 录。宁愿对于已知的问题，提供了文档或解决方法，也不要存在一些未知的问题。因为这 些未知的问题，可能会带来不可预知的后果。 (2) 职能 计划测试 开发测试方法和计划 参与设置质量标准 开发测试说明 测试 开发并维护自动测试案例、工具和脚本 执行测试，以确定产品开发过程的状态 负责定义构造流程 名品街团队开发规范 2012-02-02 制作人：孙路桃7 测试报告 为团队提供与产品质量相关的数据 跟踪所有缺陷，并保证在发布前得到妥善处理 1.5 用户教育用户教育 (1) 目标 提高用户使用效率。 为了使得产品取得成功，必须要增强用户工作和操作的方式。即使产品具备了丰富的 功能或内容，但只要对目标用户的可用性差，那么这还是一个失败的产品。 (2) 职能 技术沟通 为技术支持设计和开发文档 开发帮助文档 培训 开发和执行学习策略 可用性 收集、分析用户需求，并区分优先级 为解决方案设计提供反馈和输入 开发使用场景和用户案例 在团队中扮演用户的角色 图像设计 推动用户界面设计 国际化 改进解决方案在国际市场上的质量和可用性 辅助功能 推动在设计时加入辅助功能的概念和需求 1.6 发布管理发布管理 (1) 目标 顺利发布和后期运作。 不能忽略顺利的发布过程。如果安装过程错误百出，那么用户可能认为安装的产品也 是同样的。所以对于整个团队来说，发布并不是目标，需要的是一个顺利而平滑的发布过 程。必须确认在发布以前，培训、基础架构和技术支持已经全部就绪。 (2) 职能 名品街团队开发规范 2012-02-02 制作人：孙路桃8 架构 企业架构计划 协调物理环境的计划和使用（数据中心、实验室、分公司等） 为团队提供持续的架构管理和标准政策以及手续 管理团队的硬件和软件需求 支持 为 IT 用户提供联络和客户服务 提供问题解决方案，快速回应用户并记录发生的问题 为开发和设计提供反馈 开发故障转移和恢复流程 运作 账户和系统安装控制，管理用户账户和权限 消息传递、数据库、通信运作、网络运作 系统管理、批处理操作 防火墙管理、安全管理 应用程序服务 主机集成服务 目录服务运作 商业发布管理 产品注册码、注册验证流程 许可证管理 打包 管理分发渠道 印刷和电子出版物 1.7 角色共享角色共享 尽管团队组成包含了六种角色，但并不意味着一个团队至少需要六个成员，也不意味 着一个人只能承担一种角色，重要的是这六种角色必须在一个团队中体现。一般情况下， 团队成员常常共享角色。在一些较小的团队中，不同的角色只能进行兼任。角色共享有两 条重要原则： 一是开发组成员不能共享角色。开发人员是项目的构建者，他们不应该从他们的主任 务中分身。如果对开发组成员要求额外的角色，往往会使得他们无法按时完成进度要求。 二是不要试图组合具有一定利益冲突的角色。比如，产品管理和项目管理的利益具有 冲突点，所以他们的角色不能组合。产品管理注重满足客户需求，而项目管理主要关心在 时间和预算的限度内完成项目。如果这两个角色组合在一起，那么在需求发生变更时，可 能会发生一些情况，诸如没有足够地考虑客户满意度而忽略该变更，或者是没考虑对项目 的冲击盲目地接受变更。让不同的团队成员担任这样的角色有助于确保每个方面得到相当 的考虑和重视程度。同样，这也适用于组合开发人员和测试人员。 图 1 显示了可能会引起风险（N 和 U）以及可能产生协作作用（P）的角色共享。 名品街团队开发规范 2012-02-02 制作人：孙路桃9 图图 1 角色共享角色共享 2 开发流程开发流程 在开发过程中，采用多里程碑式的过程模型，如图 2 所示。而其中每一个循环均包含 四个里程碑。 图图 2 多里程碑模型多里程碑模型 这四个里程碑组成的循环放大后如图 3 所示，称为“过程模型” 。 名品街团队开发规范 2012-02-02 制作人：孙路桃10 图图 3 过程模型过程模型 2.1 达成共识达成共识 基本完成需求调研和分析（产品管理负责） 确定大方向和长中短期目标 所有角色都参与讨论并真正认同结论 产生的文档 常见用户情景：覆盖 80%以上功能 前景：言简意赅地说明大方向，并有激励团队的作用 2.2 完成项目计划完成项目计划 编写详细的功能规范（项目管理负责） 在编程前想清楚所有功能流程，并引导用户明确需求 所有角色都参与审阅功能规范 制订开发计划和进度表（开发团队） 制订测试计划和进度表（测试团队） 分配资源（人力和预算） 形成项目综合计划和综合进度表 名品街团队开发规范 2012-02-02 制作人：孙路桃11 2.3 完成功能完成功能 开发人员分别完成自己的功能 使用版本控制工具 对每一项可测试的功能进行测试，无需等待 通过测试用例，对功能进行完整和重复的检验 记录所有程序问题 实现解决缺陷的自动流程 按照综合进度表不断检查进度 2.4 稳定与发布稳定与发布 测试组全面地测试功能，包括性能和稳定性 开发组全力配合解决缺陷 监测质量情况 预测发布日期 专家会诊机制 决定缺陷的优先度 决定哪些缺陷可以在下个里程碑或版本中解决 决定由谁解决某个缺陷 3 代码管理代码管理 3.1 代码规范代码规范 请参看相应的代码规范文档。 3.2 版本管理版本管理 (1)概述概述 版本控制有如下好处： 可以获得连续的受版本控制的项目，并保存不同版本的区别以作比较 能获得版本控制工具中保存的任何版本 能够把出错或误操作的最新版的项目恢复到正确的历史版本 获得历史版本的详细信息 在开发过程中，使用 Visual SourceSafe 6.0 进行版本控制。它能够防止用户文件意外丢 失，并能对以前版本跟踪；对源文件进行分支(branch)、共享(share)、合并(merge)操作，同 时对整个项目进行版本控制。Visual SourceSafe 6.0 的具体使用方法，请参看 VSS 使用手册。 名品街团队开发规范 2012-02-02 制作人：孙路桃12 (2)代码管理代码管理 Microsoft Team Foundation2010(以下简称 TFS)是将文件保存在网络上的一个中央数据 库中，而不是保存在一个普通的文件夹下。当通过 TFS 观看时，这个数据库看上去包括了 以项目层次树方式组织的所有文件和历史记录。 当获得了一个文件时，TFS 会在它的数据库中将该文件标记为已被你签出（Check out） ，而后允许你在你的机器上对该文件进行修改。当你将文件签入（Check in）时，TFS 会更新它的数据库并把你机器上的该文件的访问权限改回为只读。针对每一个改动， Visual STFS 数据库都会记录和跟踪项目信息。每当从项目中添加了一个文件，修改了一个 文件或者共享、移动、删除了一个文件，TFS 都会同时共享文件和项目的历史记录。 在开发之前先从 TFS 服务器上获得最新版本的源代码，对代码做修改之前先要签出 （Check out） ，在代码修改完成之后签入（Check in）之前需要完成一系列的如下步骤： 1)从服务器上获得最新的源代码（获得最新版本，Get Latest Version） 必须从服务器上获取整个项目的所有的源代码整个项目的所有的源代码到本地，对于自己已经签出 （Check out）的文件，TFS 会提示是覆盖、不覆盖、还是归并。必须选择归并 （Merge） 。 2)重新编译本地的所有源代码（Rebuild All） 允许签入（Check in）到服务器的源代码的最低要求就是能够通过编译，否则是 不允许签入（Check in）的，同时最好能够去掉编译警告。 3)代码审查（Code Review） 在 TFS 中对签出（Check out）的文件选择版本比较（Show Differe