实习阶段性总结（一）

       此博客用以记录自己对技术总结的一些思考和回答。

1、项目管理类

1.1 如何合理的制定开发计划？

       1.理性看待项目计划制定工作。制定有效的项目计划看上去似乎是一项棘手的工作。但事实上，它拥有一套简便的程序。制定项目计划的过程，就是对按时在预算内获得期望结果所必需资源的理性审查。

       2.列出项目清单。尽管每个主管处理和跟进项目的方式可能千差万别，但列出一个实际有效的项目设计清单是最起码的基础步骤，通常适用于众多行业、公司和不同的业务部门。长期从事项目管理的经理人使用最普遍的，可能是通用的项目计划清单；类似地，每个经理人也可以添加自己的意图和立场。

       3.分解项目计划各个部分。制定富有竞争力的项目计划可以分解为以下步骤和条件：项目的目标应当简洁明确，它是主导项目发展的灵魂。同时要明确采用什么措施来评估业绩增长和最终结果。

       4.进行风险分析。创建高效的项目计划同样必须进行风险分析。在分析时要考虑风险因素。掌握项目实施过程中可能存在哪些阻碍和损失，并明确应对措施。

       5.及时调整。随着项目计划的实施，必须按需回顾和调整计划，直到团队相信计划能有效实施和投入应用。

       6.列出清晰时间表，为所有工作制定明确的期限。根据对工作质量的要求和项目的复杂程度，为工作成果制定明确期限。

1.2 你了解项目的任务估算吗，请说明一种估算方法

       了解 Delphi 估算：专家估算

       分配任务
       1、请要估算的专家
       2、为每位专家讲解要估算的项目情况，包括要估算的功能模块，内容，技术，算法
       3、每位专家根据你们公司的估算标准，进行估算，并填写个人估算表
       4、收集各专家的估算结果，求平均值，和偏差，偏差＝最大值-最小值/平均值，偏差超过20％（或不可接受的范围内），则需要进行下一论的估算
       5、一般不超过四轮

1.3 如果你是leader你是如何来保证项目进度？

       1、要求每周产出，每天检查

       2、合理估计

       3、适当降低项目质量，同时增加成本

1.4 项目风险有哪些，如果你是leader如何管控？

       （1）合同风险
       签订的合同不科学、不严谨，项目边界和各方面责任界定不清等是影响项目成败的重大
因素之一。
       预防这种风险的办法是项目建设之初项目经理就需要全面准确地了解合同各条款的内容、尽早和合同各方就模糊或不明确的条款签订补充协议。

       （2）需求变更风险
       需求变更是软件项目经常发生的事情。一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风
险）。
       预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。

       （3）沟通不良风险
       项目组与项目各干系方沟通不良是影响项目顺利进展的一个非常重要的因素。预防这种风险的办法是项目建设之初就和项目各干系方约定好沟通的渠道和方式、项目建设过程中多和项目各干系方交流和沟通、注意培养和锻炼自身的沟通技巧。

       （4）缺乏领导支持风险
       上层领导的支持是项目获得资源（包括人力资源、财力资源和物料资源等）的有效保障，也是项目遇到困难时项目组最强有力的“后台支撑”。
       预防这种风险的办法是主动争取领导对项目的重视、确保和领导的沟通渠道畅通、经常向领导汇报工作进展。

       （5）进度风险
       有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风险），项目进度的延迟意味着违约或市场机会的错失。
       预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。

       （6）质量风险
       有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。
       预防这种风险的办法一般是经常和用户交流工作成果、采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。

       （7）系统性能风险
       有些软件项目属于多用户并发的应用系统，系统对性能要求很高，这时项目组就需要关注项目的性能风险。
       预防这种风险的办法一般是在进行项目开发之前先设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作。

       （8）工具风险
       软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑的风险因素。
       预防这种风险的办法一般是在项目的启动阶段就落实好各项工具的来源或可能的替代工具，在这些工具需要使用之前（一般需要提前一个月左右）跟踪并落实工具的到位事宜。

       （9）技术风险
       在软件项目开发和建设的过程中，技术因素是一个非常重要的因素。项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。
       预防这种风险的办法是选用项目所必须的技术、在技术应用之前，针对相关人员开展好技术培训工作。

       （10）团队成员能力和素质风险
       团队成员的能力（包括业务能力和技术能力）和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。
       预防这种风险的办法是在用人之前先选对人、开展有针对性的培训、将合适的人安排到合适的岗位上。

       （11）团队成员协作风险
       团队成员是否能齐心协力为项目的共同目标服务，是影响进度和质量的关键因素。
       预防这种风险的办法是项目在建设之初项目经理就需要将项目目标、工作任务等和项目成员沟通清楚，采用公平、公正、公开的绩效考评制度，倡导团结互助的工作风尚等。

       （12）人员流动风险
       项目成员特别是核心成员的流动给项目造成的影响是非常可怕的。人员的流动轻则影响项目进度，重则导致项目无法继续甚至被迫夭折。
       预防这种风险的办法是尽可能将项目的核心工作分派给多人（而不要集中在个别人身上）、加强同类型人才的培养和储备。

       （13）工作环境风险
       工作环境（包括办公环境和人文环境）的好坏直接影响项目成员的工作情绪和工作效率。
       预防这种风险的办法是在项目建设之前就选择和建设好适合项目特点和满足项目成员期望的办公环境、在项目的建设过程中不断培育和调整出和谐的人文环境。

       （14）系统运行环境风险
       目前，大部分项目系统集成和软件开发是分开进行的（甚至由不同公司承接）。因此，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具有相当大的影响。
       预防这种风险的办法是和用户签定相关的协议、跟进系统集成部分的实施进度、及时提醒用户等。

       （15）分包商风险
       有些项目可能会涉及到将系统的部分功能分包出去，这时项目组就需要关注项目的分包商风险。
       预防这种风险的办法一般是指定分包经理全程监控分包商活动、让分包商采用经认可的开发流程、督促分包商及时提交和汇报工作成果、及时审计分包商工作成果等。

       世间万物总是发展变化的，风险亦可能随时出现和变化。项目经理应该将“防患于未然”牢记于心并作为自己日常项目工作的“座右铭”。项目经理不断培养和强化项目整个团队成员的风险意识，是确保项目顺利进展的最有效方法之一。
       以上列举的这些风险，应该是软件项目建设中经常出现的主要风险，但由于项目本身的个性化特征，针对具体的项目，肯定会出现一些我们上面没有列举甚至是事先根本无法预期的风险，这就需要我们项目经理有敏锐的“嗅觉”去识别它们，从而更好地预防和控制它们。

1.5 项目执行过程中有哪些评审工作，你如何看待评审？

评审点	评审人员	评审文档	评审内容
需求调研评审	l    用户 l    管理人员（PM） l    软件开发人员 l    （质量管理人员）	l         （初步）需求规格说明书 l         （初步）项目开发计划	l    用户需求调研的完备性 （关键需求点及潜在需求点） l    用户需求深度的（准确）界定性；需求实现的周期性； l    初步的项目开发计划（资源、周期、模式）
软件需求评审	l    软件开发人员 l    用户 l    管理人员 l    标准化人员 l    特邀专家 l    质量管理人员	l    软件需求说明书 l    数据要求及数据字典 l    项目开发计划	l    软件需求说明书是否覆盖了用户的所有要求 （用户需求调研报告  软件需求说明书） l    软件需求说明书和数据要求说明书的明确性、完整性、一致性、可测试性、可跟踪性 （软件需求说明书  数据流图  数据字典） l    项目开发计划的合理性 （用户方 公司技术委员会 项目组（包括QA） 等） l    文档是否符合有关标准规定 （包括公司的ISO QMS 有关规定）
概要设计评审	l    软件开发人员 l    管理人员 l    标准化人员	l    概要设计说明书	l    概要设计说明书是否与软件需求说明书的要求一致（概要设计  软件需求规格说明 对比“测试”） l    概要设计说明书是否正确、完整、一致 l    系统的模块划分是否合理 ** （逻辑上、系统后期拓展上、用户应用需求上） l    接口定义是否明确 l    文档是否符合有关标准规定
详细设计评审	l    软件开发人员 l    管理人员 l    标准化人员	l    详细设计说明书 l    测试计划 l    数据库设计说明书	l    详细设计说明书是否与概要设计说明书的要求一致 （概要设计 与 详细设计 的“测试”） l    模块内部逻辑结构是否合理，模块之间接口是否清晰 l    数据库设计说明书是否完全，是否正确反映详细设计说明书的要求 l    测试是否全面、合理 （测试计划） l    文档是否符合有关标准规定
测试阶段评审	l    软件专家组成人员（管理人员 l    软件测评单位 l    科研计划管理人员 l    开发组成员 l    业主单位代表	l    软件测试计划 l    软件测试说明	l    软件测试说明对各测试用力进行详细的定义和说明，审核测试用例、环境、测试软件、测试工具等准备工作是否全面、到位。 l    在测试过程中，填写“软件测试记录”。发现软件问题，则填写“软件问题报告单”。测试记录包括测试的时间、地点、操作人、参加人、测试输入数据、期望测试结果、实际测试结果及测试规程邓2.
验收评审 （鉴定）	l    软件开发人员 l    用户 l    管理人员 l    标准化人员 l    承办方与交办方的上级领导	l    成套文档	l    开发的软件系统是否已达到软件需求说明书规定的各项技术指标 l    使用手册是否完整、正确 l    文档是否齐全，是否符合有关标准规定

1.6 如何提高项目开发过程产出物（包括文档代码等）的质量？

一、代码质量

版本控制提升研发代码质量

       代码管控的工作有很多种，早期大家使用SVN，现在大部分企业都用Git，使用GitLab建立企业自己的代码仓库服务器。为了契合企业自身的业务发展，有多种使用分支提交代码的方式，分别适用不同的业务发展特征。博主所在公司使用的是这种分支开发模式：Mast分支创建Dev分支，Dev作为过程版本分支每半个月一个，过程版本分支是用于不同项目交付使用的。新的Dev分支是在最新交付的Dev分支中拉取产生的。这种Git版本管控模式适合博主所在企业的业务发展模式(企业服务)。究竟哪些分支演进模式适合读者所在的企业，需要读者根据自己公司业务特征做选择。

功能设计规范化提升研发代码质量

       要想研发的需求功能更可控适用，就必须把需求功能设计文档做好，设计文档分成两部分：一：PRD(产品需求文档)，此文档做好了，可以让开发者很清楚待开发的需求是干什么的，此需求将给谁用，解决什么业务问题。二：SRS(需求研发设计文档)，此文档作为研发人员针对PRD做的详细设计文档，此文档经过研发经理或者SE评审通过后，直接进入研发阶段，有了评审后的SRS护航，研发做的代码风向就不会错，再配合Code Review、自测、测试人员验证，产品需求质量就可以得到有效保障。根据博主多年工作经验，要想PRD\SRS产生较大的价值，必须要包含如下这些内容：

       1）PRD：最后面一定要有针对此功能的实际业务人员使用的带场景的示例流程，这样可以给研发、测试指明此功能最终的服务形态，也是研发自测的依据。

       2）SRS：SRS做的越细越好，但是究竟要多细呢？究竟要包括哪些内容呢？ SRS内容至少要包括如下内容：详细的接口文档、物理模型PDM、新增修改类的UML图、指明是新增类/方法 还是 利旧已有的原子化类方法、要实现的业务逻辑的详细描述。

二、文档质量

高质量的文档应当体现在以下一些方面：

       ①针对性；文档编制以前应分清读者对象，按不同的类型、不 同层次的读者，决定怎样适应他们的需要。例如，管理文档主要是 面向管理人员的，用户文档主要是面向用户的，这两类文档不应 像开发文档(面向软件开发人员)那样过多地使用软件的专业术语。

       ②精确性：文档的行文应当十分确切，不能出现多义性的描 述。同一课题若干文档内容应该协调一致，应是没矛盾的。

       ③清晰性：文档编写应力求简明，如有可能，配以适当的图 表，以增强其清晰性。

       ④完整性：任何一个文档都应当是完整的、独立的，它应自成 体系。例如，前言部分应作一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。同一课题的几个文档之间可能有些 部分相同，这些重复是必要的。例如，同一项目的用户手册和操作手册中关于本项目功能、性能、实现环境等方面的描述是没有差别 的。特别要避免在文档中出现转引其它文档内容的情况。比如，一些段落并未具体描述，而用“见××文档××节”的方式，这将给 读者带来许多不便。

       ⑤灵活性：各个不同的软件项目，其规模和复杂程度有着许 多实际差别，不能一律看待。图6所列文档是针对中等规模的软件而言的。对于较小的或比较简单的项目，可做适当调整或合 并。比如，可将用户手册和操作手册合并成用户操作手册；软件需求说明书可包括对数据的要求，从而去掉数据要求说明书；概要设 计说明书与详细设计说明书合并成软件设计说明书等。

       ⑥可追溯性；由于各开发阶段编制的文档与各阶段完成的工 作有着紧密的关系，前后两个阶段生成的文档，随着开发工作的逐步扩展，具有一定的继承关系。在一个项目各开发阶段之间提供的 文档必定存在着可追溯的关系。例如，某一项软件需求，必定在设计说明书，测试计划以至用户手册中有所体现。必要时应能做到 跟踪追查。

文档的管理和维护

       在整个软件生存期中，各种文档作为半成品或是最终成品， 会不断地生成、修改或补充。为了最终得到高质量的产品，达到上 节提出的质量要求，必须加强对文档的管理。以下几个方面是应注意做到的：

       ①软件开发小组应设一位文档保管人员，负责集中保管本 项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续，办理借阅。

       ②软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。这些一般都应是主文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。

       ③开发人员个人只保存着主文本中与他工作相关的部分文档。

       ④在新文档取代了旧文档时，管理人员应及时注销旧文档。 在文档内容有更动时，管理人员应随时修订主文本，使其及时反映更新了的内容。

       ⑤项目开发结束时，文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有差别时，应立即着手解决。这常常是未及时修订主文本造成的。

       ⑥在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响，并且要按照：提议、评议、审核、批准和实施等步骤加以严格的控制。

1.7 你能说明什么是需求基线吗？

       基线（base line）是软件工程活动从一个环节转入另外一个环节时对阶段产品或组件的标识。因为软件规模的膨胀和分工的细化，软件开发过程变得越来越复杂，每个阶段可能由不同类型的角色和人员来完成，因此有必要清晰标识上一阶段完成的成果和下阶段开始工作的基础。这种标识活动就是建立基线。

       根据同行评审或阶段评审的结果建立基线是质量保证人员（Quality Assurance，QA）的职责，项目参与人员（设计、开发、测试、配置管理、PSO）有责任配合QA建立各项基线。
通常一个项目（工程）需要建立如下几种基线：

        需求基线

        设计基线

        测试基线

        发布基线

       需求基线在需求分析规格说明书通过同行评审后建立，此时客户需求和产品需求应该是全面、清晰、准确并且文档化的。必要的文档包括《需求分析规格.doc》和《功能清单.xls》。通常这些文档由需求调研人员或设计人员提供。

       设计基线在详细设计完成并通过同行评审后建立。此时产品需求的实现方式应该是全面、清晰、准确和文档化的。必要的文档包括《总体设计规格.doc》、《详细设计规格.doc》、《数据库设计.pdm》。通常这些文档由设计人员提供，《详细设计规格.doc》可能由开发小组中的核心开发人员提供，面向对象的设计必需提供oom文档。

       设计基线建立后，开发人员可以根据设计基线确定的成果进行代码开发。在开发过程中必然会遇到需求变更和设计变更的活动，这些变更需要被完整记录并且变更的内容要及时反应到需求文档和设计文档中。保证需求和设计文档内容完整的有效办法是指定文档的唯一责任人，比如数据库设计的变更只能由一个人控制。

       测试基线是开发人员完成开发后，将软件系统交给测试人员测试时对之前所有开发成果的标识。建立测试基线需要设计、开发人员提供《功能清单》、《需求分析规格.doc》、《总体设计规格.doc》、《详细设计规格.doc》、《数据库设计.pdm》、《数据库初始化脚本》、《系统安装配置说明》和源码（含ant编译脚本）。在建立测试基线时，根据测试人员的要求，设计、开发人员还应该提供相应的讲解和培训。

       发布基线是在测试人员完成测试工作后建立。建立测试基线时，测试中发现的所有bug应该已经fixed或者未fixed但不影响系统使用。未fixed的bug作为遗留问题被记录下来。软件发布时，测试人员应该提供的文档包括《readme.txt》（描述软件产品信息）、《用户手册.doc》、《安装配置手册.doc》、《软件产品质量报告.doc》和产品安装包。

       产品发布后，所有产品的安装根据用户需求从已经发布的版本中选择或者进行增量开发，不能直接从cvs上check源码编译后交付用户。

       所有文档、源码、程序包都放在cvs server上，参与软件产品设计、开发、测试、配置管理人员提交的文档以cvs上最新版本为准；每次建立基线时需要打tag并通知软件系统所有参与人员。