|
1 概述 目的与概述 本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。 整体说明 在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范，Coding开发规范阐述了在一个框架中的各个层的开发规范 （注：在第一版中不包含对工作流开发的规范制定） 覆盖范围 阅读对象 1. 项目管理人员 2. 系统设计人员 3. 系统开发人员 参考资料 略 2 项目开发流程规范 2.1 业务需求调研阶段 l 调研的目标 系统层面： 客户的系统运行环境 业务层面：了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。 l 调研的准备工作： 行业知识的准备： 了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。 业务专家需求： 在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的 在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。 l 调研的流程： 第一步 ，项目启动阶段 了解客户的IT环境。 第二步， 讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息 第三步， 整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。 第四步， 发放调研问卷，再次进行业务调研（直接转到三） 第五步，卷写调研问卷，并内部评审 第六步，调研问卷客户评审并确认。 l 调研阶段的交付项（可配置项） 软件需求说明书 软件需求说明书的目录： 1 客户行业背景 2 客户系统的意义 3 客户系统运行的环境 4 业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等） 5 客户的操作习惯，页面风格习惯。 2.2 概要设计阶段 概要设计阶段主要分两个步骤： 1 框架设计 2 业务模块概要设计 ,下面分别对两个步骤进行描述： 2.2.1框架设计 （注：这边的框架设计是按照传统的开发方式进行阐述，基于平台的开发方式待补） l 框架设计的目标： 根据客户需求，设计系统的后台架构，前台界面框架，数据模型。在设计之前要考虑客户的业务特点，性能要求，已有的IT环境，同时还要考虑将来业务的增长，保证系统一定得可扩展性。 l 框架设计包含的内容： 后台框架： 各层的职能划分，技术实现的方式，层之间的交互规则，异常处理规则，目录定义规则 界面框架：操作主界面定义 页面整体风格的定义，页面流转关系等 数据模型： 系统基础数据（组织人员结构，权限设置，字典参数设置） 业务数据 l 框架设计阶段交付项： 文档 ：系统架构 界面框架 数据模型 注：三份文档可以融合在一份文档之中。 2.2.2业务模块概要设计 系统设计人员根据业务分析人员的业务需求文档，进行概要设计。在概要设计过程中主要关注三个关键点 1） 业务模块的页面显示内容：信息显示的内容，显示的方式；交互接口的定义，等 举例：查询人员信息模块 操作说明，查询条件，显示字段，排序和显示方式。 2）业务逻辑描述 对业务逻辑进行详细的描述。 3）业务数据项 业务模块涉及到数据的描述。 具体的描述包含 数据项名称 ，显示方式，是否必填，输入方式，相关逻辑 l 概要设计阶段的交付项 概要设计文档 2.3 业务需求理解阶段 2.3.1系统设计人员理解需求 在系统设计人员理解需求之前，业务分析人员必须提供相关模块的客户需求文档。 系统设计人员阅读并理解客户需求文档。 l 理解需求文档的交付结果（可配置项） 业务需求对于客户来讲，目的是什么，解决什么问题，有什么意义？ 具体业务的执行逻辑是什么？ 在业务流转过程中的业务数据有哪些？ l 需求理解时间要求： 简单的需求，理解时间为2-3 小时 复杂需求：理解需求时间4-8小时 l 复杂的业务需求需要需求分析人员确认。 复杂的业务需求按照涉及到的业务的复杂度来决定的。 2.4 详细设计阶段 详细设计阶段分两个步骤 l 第一步骤，系统设计人员根据业务需求的理解,详细设计业务模块，并出详细设计文档 l 第二步骤，核心设计人员对系统设计人员的详细设计文档进行技术评审。 2.4.1系统设计人员详细设计阶段 系统设计人员根据业务需求，详细设计模块。 l 详细设计阶段的交付结果（可配置项） 详细设计文档： 业务接口定义 数据库的数据项定义 Web页面和Js接口定义等 注：对于复杂的模块可以在详细设计文档中可以包含了UML类图，和时序图 ，从而进一步描述设计的内容 l 详细设计时间要求： 简单的业务需求：2-4小时 复杂的业务需求4-12小时 l 详细设计文档的书写原则： 系统设计人员在文档中能描述清楚业务模块的详细设计，不拘泥于格式。 2.4.2 技术评审阶段 l 技术评审流程： 1）系统设计人员在技术评审之前，将自己的详细设计文档分发给技术评审的与会人员。 2）在技术评审过程中，系统设计人员首先讲述详细设计文档 3）评审人员对详细设计中各个环节进行询问和确认，提出修改方案。 4）最后项目技术负责人确认调整后的设计方案。 l 技术阶段的交付结果（可配置项） 业务确定的详细设计文档。 注：此文档是交付确认的标准之一。 2.5 Coding阶段 系统开发人员根据业务的项目详细设计文档，进行实际Coding过程。 在Coding过程中的注意事项 1） 在Coding过程中严格按照Coding开发规范来执行。 2）在Coding过程中，发现详细设计文档中的严重缺陷，则需要和项目设计人员确认，如非常复杂，则需重新技术评审。 3）在详细设计发生改变时，需要及时更新详细设计文档。 2.6 业务模块确认交付阶段 项目技术负责人和业务分析人员共同对业务模块进行验收。 验收步骤： 1）业务分析人员确认功能模块实现功能和客户需求一致 2）技术负责人对功能模块进行技术上的确认。 3）测试人员的测试报告 注：第三步主要看公司的具体的情况和业务复杂度， 第三步完成流程如下： 1）准备测试阶段 测试人员根据业务需求，设定一个业务环境，写成测试脚本， 2）测试阶段 根据测试环境和业务需求 进行测试 3）根据测试的结果，出测试报告。 2.7 系统集成测试 根据客户业务需求，测试人员设定一个测试环境，编写测试脚本，在测试服务器上部署好系统。按照测试用例进行业务功能上测试。 测试人员准备工作清单： 测试用例 测试脚本 当前实现模块 硬件设备： 等同条件的客户运行环境 系统集成测试阶段交付项（可配置项）： 系统集成测试报告 系统集成测试报告格式 功能点 测试人 测试脚本 测试结果 异常原因 2.8 系统打包部署 客服安装人员将系统打包成一个安装文件，供在客户的系统环境中部署系统 系统集成测试阶段交付项（可配置项）： 系统安装文件 个人项目管理计划及实施建议个人项目管理计划及实施建议 一、项目启动（项目开工会） 了解项目干系人及其利害关系。 所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。 根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。 根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。 确定各种软硬件需求，如：版本控制服务器、数据库服务器、开发服务器、缺陷管理软件服务器、开发工具等。 参与人员： 项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人 项目启动会议的目标： 让整个项目组的成员相互认识 建立项目的工作关系和沟通关系 让大家明确团队的工作目标 让大家了解项目的当前状态 一起审阅项目计划 找出项目的难点或可能出问题的环节 分配小组和个人的角色与责任 获得小组和个人的承诺 实施建议： 对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立项可行性分析报告》、《立项评审报告》进行配置管理。 做好必要的保密工作。 由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。 输出文档包括： 项目风险管理计划、工作任务分解结构（WBS）、项目进度计划、配置管理计划、质量保证计划、TimeSheet、开发规范文档、测试计划 二、需求分析 需求调研：与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人。 列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中的人员、资源、时间的要求。 虽然有些因素是客户方造成的，但应该站在其角度上，为其考虑一些存在的客观及主观因素。 注意与项目成员之间的沟通方式及对团队的建设。 把握需求分析的进度及质量是否符合要求。 根据交互设计原型与客户交流需求分析是否达到要求及功能点是否有遗漏。 有哪些文档或数据是由客户提供的，这些数据是否需要在新开发的系统中维护等。 实施建议： 先对项目成员进行培训，让他们掌握必要的需求开发技能。(比如需求开发要做什么，做到什么程度，需要注意哪些问题等) 对需求开发过程域产生的所有有价值的文档进行配置管理。 需求的建模分析有较高的技术难度，项目成员应当根据自身水平进行取舍。 交互设计中应以用户的易用性为前提然后考虑在这样设计的前提下技术上实现是否有难度或者工作量超过前期设计的百分之二十. （多用TAB形式，尽量让客户的某个角色的任务可以在一个页面中完成，一般用上下文菜单，避免用系统的菜单，一个功能块一般只需要一个入口） 输出文档包括： 产品需求分析说明书、数据流程图、系统应用架构图、交互设计原型、需求分析模型(RQM) 三、概要设计 确定影响系统设计的约束因素：本系统应当遵循的标准或规范、软件、硬件环境（包括运行环境和开发环境）的约束、接口/协议的约束、软件质量的约束、隐含约束等。 确定设计策略：扩展策略、复用策略、折衷策略。 系统分解与设计：将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系；将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 数据库概要设计。 输出文档： 产品概要设计说明书、数据概要设计模型(CDM) 四、详细设计 确定功能模块的参与者、数据库表、输入参数说明、前置条件、基本流程、异常流程、日志等信息。 各层次结构的接口定义 数据库设计：逻辑设计—>物理设计－>安全性设计－>优化 实施建议： 先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。 由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的 界面设计。 对系统设计过程中产生的所有有价值的文档进行配置管理。 输出文档： 产品详细设计说明书、数据物理设计模型(PDM)、自定义数据类型及BO数据类型文件、数据字典、系统测试用例、对象模型(OOM) 五、Coding 软件编码，各接口的实现。 单元测试。 实施建议： 对开发人员进行“高质量程序设计”培训，让他们掌握编写高质量程序的技能。 对开发人员进行“版本控制、代码审查、测试、改错”等方面的培训，提高他们的工作效率。 开发小组根据项目的资源、时间等限制因素，可以适当地减少测试的工作量。 对实现与测试过程中产生的所有代码和有价值的文档进行配置管理。 输出： 单元测试报告、代码评审报告 六、集成测试 根据系统测试用例测试系统的功能性需求，保证系统的正常功能处理及异常处理是否正确。 用户界面测试，重点是测试软件系统的易用性和视觉效果等。 健壮性测试,测试软件系统在异常情况下能否正常运行的能力。(容错能力和恢复能力) 安全性测试(这种测试一般能通过建行的fortify 软件评测即可) 如果产品需要安装，那么还得经过安装与反安装测试 实施建议： 对系统测试人员进行必要的培训，提高他们的测试效率。 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。 系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。 对系统测试过程中产生的所有代码和有价值的文档进行配置管理。 为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。 输出： 系统测试报告、缺陷管理报告、操作手册 七、客户验收 成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确有效的。 验收测试。验收人员对交付的产品进行全面的测试，确保产品功能、质量符合需求。 及时解决客户方发现的问题。 输出： 客户验收计划、验收测试用例、客户验收报告、验收操作手册 实施建议： 在客户验收之前，开发方对验收人员进行必要的产品培训。 开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。 开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很 好的印象。 对验收过程中产生的所有有价值的文档进行配置管理。 八、结项 计划与实际情况对比:产品功能、工作成果、产品质量、投入人员、工作量、成本等 申请结项理由和项目自我评价 对项目进行综合评估，总结经验教训。 有价值的结项管理至少包括三项内容： 一、对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。 二、对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。 三、总结经验教训，使整个机构受益。 实施建议: 对结项管理过程域产生的所有有价值的文档进行配置管理。 做好必要的保密工作。 结项评审工作不能简化。 对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关 输出： 结项申请书、结项评审报告 下面是这些核心工具的运用经验： 1.必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则： 1)程序员尽量每天只在下班前提交一次; 2)提交的代码必须是在自己的机器上是正常运行的； 3)每次提交都必须用简短的话说明自己提交代码的功能描述。 2.建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。 3.用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码 ，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考） 4.测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况 ，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。 5.开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。 6.管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本， 随时掌握产品的走向。。。等等。 7 楼 caoyanbao 2009-11-06 引用 cs_sehu 写道 一般的软件公司能做到一半很不错了. 我个人认为这是做好一个项目最基本的流程，如果说一般的软件公司只能做到一半，可以试想下为什么我国的软件人才那么便宜的原因所在了：（ 6 楼 cs_sehu 2009-10-21 引用 一般的软件公司能做到一半很不错了. 5 楼 cs_sehu 2009-10-21 引用 我做过ISO质量认证,上面的流程跟跟ISO质量认证的流程一样 4 楼 andongoop 2009-10-15 引用 这个流程真是太好了，太值得借鉴了。 尽信书不如无书，谁也没说必须按这个规定，只能说一个比较详细的过程是这样我们可以根据自己的实际情况自行调节吗 3 楼 seeckt 2009-10-13 引用 大老板当然不需要关心，这个是项目经理关心的事情 2 楼 hereyouare 2009-10-09 引用 我们公司是项目经理分析，建数据库，安排任务编码，测试，写文档，验收~~ 1 楼 yuther 2009-10-05 引用 国内有这样执行的软件公司吗？我见到的公司都是老板只关心尽快初验，回款。 最近做完了一个项目，感慨颇深。根据做项目的经验，现初步拟了一个项目开发过程及成员组成。还请各位多多指教。 项目过程 1、项目启动 1）、项目组成立（公司成员、客户成员） 2）、制定项目预期目标 3）、制定项目计划周期 4）、建立好项目组成员沟通机制 2、需求调研 1）、创建调研计划、协调调研时间 2）、收集客户资料，获取客户需求 所有的资料都需要保留一份，资料中存疑的需要及时询问 3）、编写需求文档 重点描述出客户的业务流程和性能要求。 采用Word、Excel、Rose等形式。 4）、需求变更记录 5）、确定开发环境和运行环境 6）、扩展性要求 7）、与旧系统的接驳要求。 8）、估算出项目工作量 本阶段需要一套需求管理系统来进行需求的管理。 本阶段的需求文档也是用户测试的依据。 3、系统设计/详细设计 一个系统可以分为基础平台和应用模块两部分。 1）、选择基础平台，无论是采用第三方平台还是自行开发平台，都需要深入了解，查看是否符合要求。 2）、应用模块设计（针对业务流程） 3）、中间件的采用或自行开发，需要深入了解。 4）、用户界面的设计 如果用户界面设计完毕并确认，即可初步写出用户使用手册、管理员使用手册。 5）、变更记录 本阶段的系统设计是集成测试的依据。 4、程序开发 创建开发任务计划表、开发计划日程表 1）、优先编写测试用例 2）、按照编码规范编写代码 3）、按照文档注释规范注释 以上形成开发文档。 本阶段需要一套版本管理系统。 本阶段的测试用例也是单元测试的依据。 如果能做到，最好每日构建。 5、测试 本阶段需要一套Bug管理系统，形成需求、设计、开发、测试互动。 1）、编写测试计划和测试方案 2）、功能测试 单元测试、集成测试 3）、性能测试 集成测试、压力测试 如果能做到，最好能进行自动化测试。 如果能做到，做分析统计工作。 最后形成测试报告。 6、试用、培训、维护 本阶段需要解决： 1）、解决异地修改和公司修改的同步问题。 2）、用户测试中的Bug修改问题，按照级别分为 a）、程序Bug b）、设计变更 c）、需求变更 尽量按照a b c的顺序来进行修改，尽量避免b、c级的修改。 最后形成安装手册、维护记录。 项目成员组成 根据以上过程，一个项目组中，需要： 1、需求工程师，其要求 善于与客户沟通，能快速了解客户的需求，对客户所在的行业比较熟悉。 善于学习新知识。 熟悉Word、Excel、Rose等工具的使用。 熟悉开发语言和开发框架 熟悉已积累的产品的功能、性能等。 2、系统分析师/设计师，其要求 精通开发语言和开发框架，部分需要精通数据库 精通已积累的产品的功能、性能等 深入了解客户行业特点 能根据客户的要求分析出其实质 能做出优秀的设计 熟悉Word、Excel、Rose等工具的使用 3、开发工程师，其要求 熟悉开发语言，熟悉开发要求和注释规范，部分需要熟悉数据库。 熟悉单元测试。 能根据设计做出良好的编码，保证功能和性能。 部分需要有一定的设计要求，因为涉及到将来的维护。 4、测试工程师，其要求 熟悉测试工作，能按照测试计划进行测试。 熟悉开发语言，能协助开发工程师找错。 能独立完成黑、白盒测试。 如果是高级测试人员，还要能够对系统能深入进行分析并能制定出优秀的测试方案。 5、管理人员 一般由以上人员兼任，主要有 项目经理：负责整个项目 开发经理：负责系统设计、开发工作 测试经理：负责测试工作 6、其他人员 一些项目涉及到其他人员，如页面设计人员、页面制作人员。 部分大的项目，还有专门的维护人员。 由于目前国内很多公司并没有严格这么区分，如果项目小的话，可以一人兼任多项职位。关于项目管理的一点体会 标签：项目管理 心得 it 分类：IT项目管理 前段时间，我负责了一个项目的管理与开发。在时间短、任务紧，而团队人员又大部分是没有经验的菜鸟的恶劣情况下，我带领接近40人的团队，终于在客户规定的时间范围内如期交付产品。这其中，经历了需求变更、人员变动（因为其它任务，先后有近10人离开团队）等诸多问题，项目仍然取得了成功，不能不说有几分侥幸，但此外也有一些经验与教训可以与大家分享。 项目开发方面 项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于EAS项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。 需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。EAS项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。 项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从EAS项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。 项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。EAS项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。 注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。 注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了EAS项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用) 控制需求变更。重视CCB的作用，同时应建立需求变更的响应机制。EAS项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱) 设计 重视架构设计。EAS项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一) 善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，EAS项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从 EAS最初的架构设计来看，我们引入了 Castle与AOP，试图简化ORM以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用WCF，利用SOA思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用WCF的构想，同时又克服了技术困难，坚持了对Castle与AOP的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。 重视UI原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在EAS 项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、UI设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的UI设计人员，因此，这一工作还存在很大的缺陷，甚至于UI的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于UI的bug是最多。因此，我们认为在开发类似的WEB应用程序时，应尽早确立UI设计规范，以约束所有的UI设计。同时，必须培养专门的UI设计师，在开始原型设计时，就尽快完成UI交互的设计。并且，必须成立专门的UI 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的UI设计人员，原型设计可以由需求分析师来完成) 测试 测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉) 测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。 进度管理 保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 RUP或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。 其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。 要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。 及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。 制定项目计划时，必须考虑阶段评审与同行评审的时间。这一点在EAS项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及QA及时掌握项目进度，有利于对项目进度的管理。 变更管理 变更包括需求变更、人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而EAS项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。 如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。 人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。 风险管理 要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，而一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。 成员管理 不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。 持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班，只能降低项目成员的工作效率。项目过程中，如能适当地开展一些活动，无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻，项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。 必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外，一个好的领导也是至关重要的。因此，必须选择合适的项目组长，通过他们掌握整个项目团队成员的工作进展。同时，还要了解每个成员的能力，以安排合适的角色与岗位。 重视开发组与测试组以及项目管理小组的合作。项目组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。 作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。 |
|
|
