【《A公司软件产品研发流程管理现状及问题和优化设计案例》26000字】

A公司软件产品研发流程管理现状及问题和优化设计案例目录TOC\o"1-3"\h\u15578A公司软件产品研发流程管理现状及问题和优化设计案例 120881第1章A公司软件产品研发流程管理现状分析 3172031.1A公司概况 310641.1.1A公司简介 3205261.1.2A公司组织架构 336161.1.3A公司目前在同行中的对比分析 6169401.2A公司软件产品研发流程管理现状 783361.2.1软件产品研发流程管理介绍 723691.2.2软件产品研发流程管理现状效果评测 810564第2章调研结果分析 12189182.1A公司内部调研 12310242.1.1问卷设计 12159242.1.2确定专家 1290072.1.3流程准备 125292.1.4结果分析 15138932.2A公司软件产品研发项目管理存在的问题 18324972.2.1综合管理问题 18121522.2.2团队管理问题 1977952.2.3开发流程问题 20120942.2.4辅助工具问题 2113662.3本章小结 2117553第3章A公司软件产品研发流程项目管理改进 22290653.1综合管理改进 22238293.1.1组织结构改进 22275923.1.2项目开发方法改进 2245023.1.3采用Scrum技术体系 2263163.2项目开发团队管理改进 2339333.2.1加强相关方参与 23263963.2.2选择合适的产品负责人 24197973.2.3建设敏捷型团队 25121543.3项目开发流程改进 25294533.1.1采用Scrum主流程设计 26125423.1.2制定Sprint计划改进开发流程 27187183.1.3测试流程改进 2918173.1.4软件发布流程改进 3014113.4项目管理沟通机制改进 30160983.5辅助工具改进 31第1章A公司软件产品研发流程管理现状分析1.1A公司概况1.1.1A公司简介A公司是一家致力于信息技术应用创新的高科技企业；主营业务包含以打印机、复印机、扫描仪、手写签批屏为主的输入输出设备，以涉密载体全生命周期管理、智能管控和信息采集综合应用为主的管控类解决方案；是国内领先的集科研生产、市场营销、系统集成、运维服务为一体的输入输出设备和服务提供商。A公司经过多年的产品研发积累，拥有了自己的一套流程体系。A公司的产品研发流程总体上和其他流程类似，大致分为需求阶段、设计阶段、开发阶段、测试/联调阶段、预发/上线阶段。大概的流程就是项目管理部提出需求、制定计划、立项评审并由他们指定项目经理，接着项目经理进行研发团队组建和需求任务细分；再把产品概要设计说明书和详细设计说明书下发给相关开发人员进行开发测试，开发测试后进行项目验收上线。由于公司业务逻辑的复杂化，加上信息化建设脚步的加快，传统的项目管理方式已无法满足当下日益增长的需求。随着业务量的增长，越来越多的问题得以暴露：需求变更频繁、项目进度无法达到预期、产品战略没法落地、产品风险无法把控、研发人员分工不明确、跨部门协作困难、缺乏有效的研发人员考评和激励措施，是A公司目前迫切需要解决的问题。1.1.2A公司组织架构A公司的开发部是公司的核心部门，在公司组织中占有很大比重。如图3-1是A公司的组织结构图。总经理副总经理兼技术总监综合部总经理副总经理兼技术总监综合部财务部招商部运营部市场部客服部开发部开发组运维组需求美工前端后端移动测试Figure3-1CompanyOrganizationalStructure在A公司的组织结构中，总经理下设专职副总经理一职，兼技术总监，负责管理开发部的工作，对总经理负责。其他职能部门包含综合部，财务部，招商部，运营部，市场部，客服部，各部门由各部长负责直接管理。开发部是公司的核心部门，由技术总监直接负责管理。按照传统软件开发模式，技术部门分成开发组和运维组两个小组，由于工作性质不同和所需环境不同，这两个小组被安排在不同的办公区域中工作。根据开发技术特点，开发组又分成不同的小组。（1）需求。负责与业务部门或客户进行沟通，了解客户的需求，准确捕捉客户需求关键点，分析客户需求在技术实现上的可行性和经济性，负责制作原型设计图。协助项目经理制订设计方案、设计架构。（2）前端。根据设计方案和原型设计图制订客户端页面的详细设计文档，负责具体开发的客户端页面，并实现相应的各种功能，编写前端设计说明文档。（3）美工。根据原型图和前端的要求，对部分页面进行美化设计。（4）后端。根据设计方案制定业务流程和详细设计文档，负责构建逻辑功能模块，数据库表结构设计，创建负载均衡、数据存储、各类接口模块等，编写逻辑模块等后端的详细说明文档。（5）移动。编写移动端的详细设计文档。负责针对移动端系统进行相应的客户端软件开发，如Android或ios等。（6）测试。编写测试文档编制测试用例。负责对所有开发的功能模块进行各种测试，保证每个模块都能符合设计方案正常运行。而对于运维组，尽管组成员拥有不同的技术身份（如：系统工程师、网络工程师、DBA等），由于成员人数较少便被统一归为运维组，不再细分。依据A公司的组织结构，当启动一个软件项目时，根据项目的具体情况，由技术总监指定项目负责人担任项目经理，并从开发部的职能小组中抽取相应的人员组成项目组。项目负责人即项目经理会被正式任命，但是在整个项目过程中只起到协调的作用，而实际具体的分工则由职能经理负责，项目经理不参与项目成员的绩效考评工作。开发部中的运维组成员人数较少，因此基本上大部分人会参与所有的项目。运维人员只负责搭建系统环境，将操作系统以及数据库的用户口令通知开发组的有关人员并协助开发人员调试系统设置，很少与开发人员就技术或业务方面进行交流。项目组在项目成果交付后自动解散。A公司的软件项目组织结构如图3-2所示。

项目经理项目经理需求工程师美工工程师前端工程师移动工程师后端工程师测试工程师运维工程师图3-2软件项目组织结构Figure3-2SoftwareProjectOrganizationalStructure1.1.3A公司目前在同行中的对比分析国内输入输出设备行业起步晚、底子薄，各项技术严重滞后于美国、日本等国。从九十年代起，国内厂商逐步介入输入输出设备生产领域。目前，我国输入输出设备厂商大多通过进口机芯的方式进行组装生产，产品以低端产品为主，技术含量低，产品类型单一，而且同质化现象严重，在国内市场以价格竞争为主，毛利率呈逐年下降趋势。输入输出设备市场主要以国外品牌为主，占据重要市场份额。中高端产品产品价格稳定，低端产品市场竞争较为激烈。预计未来国产品牌的市场份额将逐步提升，随着消费升级发展，未来中高端产品的需求将保持持续增长需求，低端产品供过于求的形势将进一步加剧。2021，中国输入输出设备市场规模约为167.9亿元，较2019年同期上涨了2.16%。输入输出设备行业经过多年的发展，市场较成熟，发展速度较缓。行业中知名品牌较少，有很大的技术壁垒，大型企业研发能力较强，专利数量较多，对于产品的认知能力较高，优势明显。目前中国输入输出设备的市场份额每年在80万台左右，市场被十余个企业瓜分。虽然绝对的数量不是特别多，但是输入输出设备产品的特性是后续的耗材供应会源源不断的产生利润，这与其它产品一次性的利润是完全不同的，因此考虑到市场上已有的产品和新的增量，综合来说输入输出设备还是一个庞大的市场。输入输出设备行业市场统计数据显示，2022年1-3月中国输入输出设备市场中，万元以下的产品占据了近六成的市场关注度，其中5001-10000元价格段的产品关注比例最高，达33.1%，5000元及以下的价格段排在第二位，关注比例为21.2%。10001-20000元、20001-40000元和40000元以上价格段的关注比例均在一成以上，分别为16.0%、12.1%和11.6%。中国输入输出设备市场上，黑白输入输出设备依然占据市场主流，关注份额达到了81.4%，不过相比上月略有下滑。而彩色输入输出设备本月的关注度则是有所提高，为16.6%，较上月上涨了0.6个百分点。

1.2A公司软件产品研发流程管理现状1.2.1软件产品研发流程管理介绍计划阶段A公司软件开发项目计划阶段，一般由项目经理、技术经理、团队成员一起开会讨论决定。采用自上而下分阶段的开发模式，开发流程主要环节有需求收集、需求分析、系统设计、编码开发、系统测试、系统部署上线试运行和正式运行等。项目团队人员结构主要有项目经理、技术经理、团队成员，其中项目经理主要是进行项目的规划、项目的管控、进度控制以及需求沟通等；技术经理主要负责团队开发质量、技术设计、需求任务的分配和开发进度监控；团队成员主要从事软件编码、单元测试、集成测试等工作，同时在编码阶段之前，仍有部分团队成员参与系统的设计和需求调研工作。其具体流程是，项目经理传达出市场信息或者客户反馈，大家一起讨论，该产品或者该功能是否开发。若决定开发，会后则由技术经理指定某团队成员结合现有项目进度，来做需求规划，需求规划的内容主要包括：完成产品的时间和内容。然后相关人员开会，评审计划是否合理，不合理则继续修改，合理则进入下一阶段。这一阶段中，项目经理代表客户立场提需求，技术经理根据目前产品进度来做规划，项目经理把控全局，看似很合理，其实为后续开发埋下了不小的隐患，因为这一阶段中，测试经理等与项目开发最直接相关的人并没有参与。在一个项目的开发过程中，项目的进度、项目的质量、项目中遇到哪些问题，测试经理和产品经理是最清楚的，产品经理在规划需求任务时，往往并不非常清楚开发中的具体细节，只有等到原型出来，开发参与讨论时，才能发现问题，才能讨论修改计划，甚至产品经理还要向上反映具体情况，层层沟通下来，时间成本和人力成本都上去了。需求阶段项目确立后，首先由项目经理带领个别有经验的团队成员，到客户现场通过面谈形式在客户方进行需求了解，了解需求后，项目经理安排团队成员对收集的需求进行分析，对用户需求进行整理，通过文档形式整理出各个功能模块，如一级功能模块和各一级功能模块下的二级模块，有时候团队在时间充裕的情况下，还会根据整理出的功能模块进行相应的原型DEMO设计，项目经理拿着整理的需求文档或相关原型DEMO与再次和客户进行确认，经过多次确认后，项目经理安排参与了需求调研的团队成员编写《用户需求规格说明书》，编写后，项目经理组织团队内部进行需求评审，评审通过后，项目经理安排相关人员进行下一步相关设计工作，如概要设计、详细设计等。然而，在实际的项目执行中，由于项目时间紧，为了赶工，在具体设计还未完成时，就已经安排开发成员进行相关需求开发。在需求变更控制上，对于客户提出的变更需求则根据对项目影响程度进行不同方式的处理，对于影响小的变更，则直接安排开发成员进行修改，只有影响较大的变更，才会进行变更控制流程。编码设计阶段在编码设计阶段，开发团队依据上个阶段的设计文档和相关需求文档进行功能编码，公司项目较多，也有自身研发的MVC架构，对于简单的项目则直接采用公司标准框架进行开发，对于复杂的项目，在公司标准框架不适用时，开发团队则是在公司标准开发框架基础上进行相应的改动，即可开始功能编码的实现，公司并没有专门的架构设计团队。在编码开发中，要求开发成员对编写的代码进行单元测试，但是开发成员为了完成开发进度，基本上都是先完成开发功能，单元测试往往都是在检查时，才进行后补，没有起到单元测试的目的。同时公司也有相应的代码规范要求，但是开发团队在进行代码走查时，只是形式化，没有起到真正意义上的走查要求。测试阶段测试工作是从产品经理的需求评审会议后，测试人员根据产品经理输出的原型和文档编写测试用例开始的。在开发人员编码时，测试人员开始写测试用例文档，开发完成后，他们根据测试用例来对已开发的产品进行测试，先进行单元测试，发现问题时返回给开发，开发修改完后，再次提交代码给测试来测；单元测试后，进行联调测试，即对该产品上下游相关业务进行综合性测试，以保证上下业务正常有序的开展；联调测试后是集成测试，即将整个系统业务全部放在统一的服务器环境下，就全部业务进行真实用户场景测试；集成测试通过后，才标志着产品最终上线。从整个流程看来，测试环节一环衔接一环，它的目的就是要保证产品质量。但是实际情况中却问题诸多，在通常情况下，软件公司有专门的测试人员，且测试人员与开发人员占比为20%左右，而A公司一直以来，测试人员与开发人员占比不到10%，测试团队任务相对繁重。1.2.2软件产品研发流程管理现状效果评测A公司软件开发项目中的开发流程和人员分配看似严谨合理，实则从以往的开发项目看存在相当多的问题，例如：需求的不确定性导致项目返工率高，项目经常性延期，项目交付周期太长导致研发人员倦怠，管理层及项目干系人满意度不高，研发与运维团队之间的工作矛盾。这些问题涉及诸多因素，彼此之间又有纵横交错的联系。本文对造成A公司软件开发项目延期交付和开发效率低下的几个主要问题进行分析并做了总结。架构组织现状效果评测一是项目工作的职责界定不够清晰。项目经理在软件项目中的主要作用是协调项目工作并推动项目进行。他可以对项目成员的具体工作进行安排，也可以通过职能经理来进行这项工作，对项目的进展情况一般通过职能经理来了解，因此项目经理缺少对项目整体把控的能力。而且项目经理也没有对项目成员的考核权，无法通过奖惩机制对项目成员进行激励与惩戒，也就无法有效推动项目进行，进一步降低了对项目进度的控制能力。而对于项目成员来说则面临着多头领导的难题，遇到问题不知该向哪位领导汇报，而领导的意见不一致时又不知该如何选择，因此无法集中精力投入到开发工作中，从而导致开发效率降低。二是组织结构不合理，A公司开发一个项目，需要经手多个部门，部门与部门之间的衔接和沟通，上下级之间的层层汇报和审批，不仅耗时耗力，而且对项目开发进度有很大的阻碍。而且A公司采用的是临时组建项目团队的组织方式，软件项目成员从各个职能部门抽调进入临时性的项目组，项目经理由技术总监任命，对项目结果负责。当项目结束时，项目组便解散，所有成员会被分配到新的不同的项目中去，这种组织方式会导致软件开发项目缺少有效的工具或方法使项目组成员和所有项目干系人了解最新的项目进展情况，从而对项目进度进行有效监督。现有项目进度情况由项目经理每天从项目成员的汇报中进行收集整理，然后每隔一段时间将项目进度情况通过电子邮箱和在公司的项目管理平台进行发布。公司没有严格规定发布的时间和对象，项目经理可能会在较长时间段内不发布进度报告。而通过电子邮箱发送进度报告和相关文档给项目干系人，由于误操作或者电子邮箱发生故障等原因，收不到进度报告的情况也可能发生。客户、业务部门、项目组成员都对软件开发项目的进度情况了解有限，无法真正对项目进行监督。需求管理现状效果评测一是软件项目需求缺乏有效管理。在以往的软件项目中，由于涉及的部门人员较多，因此，同样的业务需求从不同的客户所得到的情况不一致，或者有的客户不是特别熟悉业务流程，在沟通交流中双方也会产生各种歧义。软件项目组所获的需求是分散而零碎的，开发人员无法准确确定开发的软件功能范围、质量的要求范围，并且无法有效地将各种技术、市场、用户的要求中得出明确的需求总结，这造成了项目组对于理解业务需求产生了很大困难，项目经理不得不多次向客户确认开发需求，在最坏的情况下，开发人员获得的信息仅有原来的8.4%，从而导致项目因需求的不明确而延迟。二是在开始进行需求调研时，由于客户不能对项目需求有个整体而全面的判断，无法提出详细的需求，从而遗漏了某些的需求，最终导致软件在可靠性、效率性、灵活性、安全性、兼容性、可维护性、多用转换性、稳定性、重复使用性、健全性等多方面存在问题。或者由于市场等其他外部情况的影响，客户的需求也在不断变化，项目后期会要求增加或修改一些开发内容。由此项目进度被一再推迟。协作配合现状效果评测一是内部协作配合效率低下。项目启动时，项目经理的主要工作集中在与客户沟通，制定项目范围和项目计划，较少与项目团队成员沟通。项目运行中，由于软件项目成员来源于不同的技术小组，每个小组的成员为了按时完成分配的任务，必然从自身利益考虑，强调系统要满足自身工作领域的标准或需求。软件项目成员缺少交流，甚至不愿意交流，担心需要调整自己的开发方式或开发标准以适应其他成员的开发流程，而采用自己不熟悉的工作方式则有可能影响自身的进度，进而影响自己的绩效考核。特别是运维组与开发组的交流更少，工作中的矛盾也更多。传统上运维人员与开发人员属于不同的组织结构分支，运维人员大部分属于基础架构部门或者运维部门，而开发人员属于研发部门。运维人员关心的是系统的稳定性、安全性、可维护性；开发人员关心的是软件系统的功能和开发进度。不同的工作目标导致了不同绩效考核标准，不同的预算导致了控制权的不同，这些因素也进一步放大了两个团队的对立性。开发组成员在编写代码时基本很少与运维组成员沟通，因为他们通常不考虑关于软件系统在正式生产环境中运行的稳定性和可维护性等部署和交付问题，因此，他们交给运维组成员的将要部署的产品通常是半成品，需要运维成员做大量的部署调试工作才能保证开发的软件系统能够正常部署上线，从而增加了产品交付时间。二是项目经理缺少对项目的领导能力。项目经理无法对项目的范围、进度、质量和资源等方面保持平衡，另外对于项目风险把控能力不足。项目经理对项目的控制能力直接影响了项目进度。有些项目经理对项目规划的重要性认识不足，认为计划没有变化快，所以不需要花很多精力制订详细计划。与项目干系人的沟通不够充分，只是敷衍了事，众多可能影响项目的因素没有被考虑，既无法与客户等外部千系人达成共识，也无法迅速应对项目的变更。而且，项目经理没有开发项目组成员的考核权，只负责项目的协调监督指导工作，项目团队存在多头领导。在项目具体执行过程中，项目经理无法获得项目成员的有力支持，对项目进度的控制很有限。研发流程现状效果评测软件项目需要在文档制作方面耗费大量时间，导致开发和测试时间被压缩。公司按照瀑布开发模型的基本规则和框架制定了详细的标准化模板，涵盖开发流程所有阶段的内容，每一阶段的产出成果就成为下一阶段的输入信息，这种制度可以保证开发流程的规范化和标准化。整个开发项目流程形成了以文档作为驱动的开发过程，所有开发阶段将会产生大量的具有版本标识的文档和代码库。这种模式在变更不多的情况下还不会出现太大问题，但是当需求变更变得频繁时，则会产生大量无效文档。基于文档传递的开发过程，在软件开发后期经常产生集成问题，对软件项目运行产生相当大的阻碍。软件项目成员进行设计、编码、测试、部署等一系列工作都要编写文档并等待文档审核。每次需求变更，相应地所有文档也需要修改。如果变更过于频繁可能会造成上一版本的内容还未修改完，便要修改的下一版本的文档了，开发人员忙于编制各类文档以至于没有足够时间进行开发工作。仓促修改的文档也可能会存在各种遗漏和错误，含有错误的文档将会被提交。运维人员在项目后期的部署和维护阶段使用最多的是《需求规格说明书》和《设计架构》，开发人员制作的大量详细设计和编码文档不会被运维人员使用，更不会被客户和业务部门等项目干系人使用，但是运维人员需要花大量时间对其进行维护。因此，文档编写及维护工作成为开发工作中任务占比极高又耗时的一项内容，其反过来又压缩了团队编码、测试的时间。软件项目的进度会受到多种因素的复合影响，如：确定项目目标和任务分工方面，项目需求变更方面，项目工期估算方面，进度偏差及纠正方面，进度管理工具方面，项目经理对项目进度控制方面等。公司业务现状效果评测一是软件项目开发开发复杂，流程长，无法根据客户需求变更和调整，无法适应需求快速变更的项目。A公司之前的项目开发周期通常是几个月甚至几年，需求调研分析、方案设计共占开发周期的五分之二，编码占五分之二，测试和部署发布共占五分之一。如果在项目组成员完全理解客户需求并且需求不做变更的理想条件下，严格按照项目计划执行，软件项目能够按时完成。但是，为适应市场需求的变化，电子商务平台必须快速应对这些需求。在A公司实际开发过程中，客户需求经常发生变更。如果需要变更，处于编码阶段、测试阶段甚至部署阶段的项目都需要被迫中断，产品需要重新设计，项目需要再从需求阶段开始进行。而且有些设计问题和对客户需求的理解问题也必须要到测试阶段才能被发现，如果是基本逻辑出现问题，则设计方案很可能要推倒重来，整个项目必然会延期。即使问题可以在编码阶段通过修改代码进行弥补，编码阶段所用的时间也可能占用软件项目开发周期的二分之一，甚至更多，严重压缩了测试和部署发布的时间。不论出现哪种情况，都会带来软件产品质量下降及用户满意度下降的不良后果。同时还会导致项目开发人员做了许多无效工作并且长期加班，这严重打击开发成员的士气和积极性。二是人员流失情况严重，A公司建立了人才激励、培养机制，出台了研发人员绩效考核制度，但是，A公司目前研发人员的状况却不容乐观，主要技术部门人员流失严重，究其原因，软件开发人员对企业没有足够的归属感。公司项目团队人员采用矩阵式管理方式，开发人员一方面受专业技术部门领导，同时也可能受不同项目经理调配。长此以往，软件开发人员对公司文化没有较好的理解和认知，也谈不上认可和归属感。软件开发人员的成就感低。软件研发团队中大多是年轻的技术开发人员，追求成就感，但软件产品研发大多是完成项目后交由甲方或者运营团队进行完善或者运作，开发人员基本上不能享受到产品成果，没有直接的成就感。由于竞争激烈，项目利润低，通常采用项目人员最低配备来降低成本。在这种情况下，研发人员往往被各项工作搞得焦头烂额，无暇顾及其他，缺乏对知识和经验的系统性整理和共享。

第2章调研结果分析本章采用德尔菲问卷调查将A公司的Scrum流程问题收集起来，结合Scrum的设计原则，对公司的敏捷管理提出相应的优化方案。经过德尔菲问卷调查结果可得：在A公司Scrum流程中，共涉及问题5个方面，即架构组织问题、需求管理问题、协作配合问题、研发流程问题、业务问题。具体问题共计10个，即人员职责、组织结构、需求变更问题、需求可视化、质量控制体系、沟通、领导力、Scrum流程认知、业务复杂、人员离职。根据问卷调查结果，专家认为其中最需要改善的问题是沟通问题。沟通机制改善将作为不可忽视的一个优化的节点，并对其他问题逐一提出建议。2.1A公司内部调研本研究过程选取公司深度参与项目的工作人员组成专家团队采用德尔菲问卷调查法进行问题收集收集结果和分析可以帮助公司更有针对性和可行性的制定优化策略。2.1.1问卷设计本论文旨在于对A公司在实施敏捷开发过程中遇到的问题进行收集，并以此为依据提出优化方案，为了不出现引导性表达误导专家，故确定调查问卷的主题为开放性问答，问卷问题为“A公司敏捷开发过程中的问题有哪些？”。为了不出现引导性的问答，问卷采用开放式调查问卷，制定开放性问卷。设定问题为“您认为公司当下敏捷流程中存在哪些问题？请指出存在问题的原因”。通过问卷集思广益，让专家给出在各自工作流程中发现的问题。对项目中涉及到不同的角色，均采用匿名邮件的方式进行回复，调查项目实施过程中遇到的问题和对策，丰富了本方案的研究方向和内容，使得方案更加具有可操作性2.1.2确定专家专家的选取要求：涉及整个项目开发流程的参与人员，且需要其具有完整流程的项目开发经验，不低于3年以上的本公司开发经验，熟悉业务流程，资深项目负责人。确定专家构成为：首席专家、研发总监、研发负责人、研发人员，测试总监，测试人员，共计10位专家。2.1.3流程准备为了让参与调查的参与专家能更全面、准确的发现公司敏捷开发管理过程中存在的问题，整理相关项目相关资料：以敏捷研发项目为分类，分别整理项目立项阶段、研发阶段、结束阶段等文档资料，以及评审会议纪要等各种形式的项目交流相关资料供专家参考。为保障调研结果的公允及质量，问卷调查的主要对象A公司项目经理、产品经理、测试经理、研发经理以及团队优秀成员等不同部门的专家。问卷调研一方面是调查A公司软件产品研发流程管理的现状；另一方面是根据专家组的经验，对在A公司软件产品研发流程管理中存在的问题进行识别和选择。具体的调研流程如下：图4-1德尔菲法流程图Figure4-1FlowChartofDelphimethodMethod在焦点访谈之后给专家小组发放调查问卷，进行问卷调查，调研专家对初步筛选的指标进行勾选。将调查问卷表分别发放至专家组调研人员，在规定时间内专家均反馈了调查问卷，回收率为100%。表4-1专家调查问卷Table4-1ExpertSurveyQuestionnaire目标一级指标二级指标在您认为重要的栏中打√A公司软件产品研发流程管理问题架构组织问题人员职责组织结构组织管理需求管理问题需求变更后问题需求可视化质量控制体系需求预估协作配合问题沟通领导力团队合作研发流程问题Scrum流程认知流程变更业务问题复杂性多样性人员离职对各位专家进行焦点访谈之后，将调研问卷分别发给10位调查专家，请专家对初步选定的指标进行评价、选择。在规定的时间内，10位被调查者均提交了问卷。通过对专家小组提交的问卷进行统计，结果如表4-2。表4-2第一轮意见征询统计表Table4-2StatisticalTablefortheFirstRoundofOpinionConsultation目标一级指标二级指标勾选人数A公司软件产品研发流程管理问题架构组织问题人员职责10组织结构6组织管理3需求管理问题需求变更后问题7需求可视化8质量控制体系8需求预估2协作配合问题沟通9领导力7团队合作4研发流程问题Scrum流程认知8流程变更10业务问题复杂性6多样性1人员离职8经过统计，第一轮调研没有专家提出其他一级指标或二级指标，根据专家小组提交的第一轮调研结果，指标的筛选剔除了勾选人数低于5人的指标，形成第二轮调研问卷。表4-3为第二轮意见征询统计表。表4-3第一轮意见征询统计表Table4-3StatisticalTablefortheFirstRoundofOpinionConsultation目标一级指标二级指标勾选人数A公司软件产品研发流程管理问题架构组织问题人员职责10组织结构6需求管理问题需求变更后问题7需求可视化8质量控制体系8协作配合问题沟通9领导力7研发流程问题Scrum流程认知8业务问题复杂性6人员离职8通过焦点访谈及对专家意见征询，专家针对性地对A公司软件产品研发的流程管理指标进行筛选，意见基本保持一致，对流程管理问题因素进行了精准的选择，因此，未继续第三、第四轮的意见征询。通过综合焦点访谈和专家意见，最终提炼出十个主要因素。2.1.4结果分析第一次调查问卷结果首轮将调查问卷与3个项目相关的资料通过邮件方式发放给选中的14位专家，并在一个周内获得专家的回复，回复率100%。回复问题个数为21个，产生问题原因14个，通过整理分析，将问题归纳为4个方面：架构组织问题、需求管理问题、协作配合问题、Scrum流程问题。问题表现为8个方面：人员职责、组织结构、需求变更问题、需求可视化、质量控制体系、沟通、领导力、Scrum流程认知。现将第一次调查问卷结果整理如下表4-4和柱状图4-2所示：表4-4第一次问卷调查表Table4-4FirstQuestionnaire方面架构组织问题需求管理问题协作配合问题研发流程问题业务问题问题人员职责组织结构需求变更后问需求可视化质量控制体系沟通领导力Scrum流程认知复杂人员离职专家人数91175121351279问题占比0.6430.7850.4290.3570.8570.9290.3570.8570.50.643方面占比0.7140.5480.6430.8570.571图4-2第一次问卷调查柱状图Figure4-2HistogramoftheFirstQuestionnaireSurvey第二次调查问卷结果第二次问卷，仍是将同样的问卷内容发给14位专家，同时发送的还有第一次调查问卷的结果。但是这次问卷，可以允许专家在下方备注中增加对第一次调查问卷结果的修改，也可以新增或者删除。邮件发送后，在一个周收到14位专家的回复，回复率为100%。其中9位专家维持原答案。5位专家对第一次调查问卷进行了问题的新增、修改和删除。还有4个问题的人员认同发生变动。现将第二次调查结果进行归纳统计如表4-5所示：表4-5第二次问卷调查Table4-5SecondQuestionnaireSurvey问题占比0.6430.7850.4290.3570.8570.9290.3570.8570.50.643方面占比0.7140.5480.6430.8570.57第三次调查问卷结果第三次问卷依旧是同样的问题同时将第二次调查问卷的结果以邮件形式发给14位专家。邮件发送后，在一个周收到14位专家的回复，回复率为100%。其中5位专家对第一次调查问卷进行了问题的新增、修改和删除。问题数量并没有新增，部分问题的人员认同发生了一些变化。如表4-6和柱状图4-3所示：表4-6第三次问卷调查表Table4-6ThirdQuestionnaire方面架构组织问题需求管理问题协作配合问题研发流程问题业务问题问题人员职责组织结构需求变更后问题需求可视化质量控制体系沟通领导力Scrum流程认知复杂人员离职专家人数91164121361278问题占比0.6430.7850.4290.2860.8570.9290.4290.8570.50.571方面占比0.7140.5240.6790.8570.536图4-3第三次问卷调查表柱状图Figure4-3HistogramoftheThirdQuestionnaire2.2A公司软件产品研发项目管理存在的问题A公司在软件开发项目管理中存在综合管理、团队管理、开发流程、辅助工具共四个方面的问题。2.2.1综合管理问题在综合管理方面，A公司的主要问题有4个，分别是：组织结构不合理A公司中市场部和研发部是两个独立的部门，互相之间缺乏交流，而这两个部门在项目规划阶段的职能和任务也不同，即市场部更侧重于市场需求调研，技术部则更侧重于方案可行性与方案可获利性的调研。因此A公司在研发项目流程规划阶段无法整合两个部门的信息并从全方位角度作出决策判断。A公司在研发项目流程阶段看问题过于片面，忽视某些问题的综合性考虑。另外，市场部虽然对当前市场需求进行了调研，但是对于后期产品的相关数据例如应用潜力，研发进度等都无法与研发部进行沟通，这导致市场部对于市场中该类研发产品的调研信息不足。如果前期市场部对于市场需求调研不充分，而产品在研发过程中也将缺少相关需求改进，甚至出现无法满足对应市场需求的情形，进一步在市场中失利。另外，市场需求也是不断变动，即便市场部在前期调研非常充足，但缺少两个部门之间的沟通与接触，也会使研发部门在之后的研发中存在信息差距，导致市场需求骤减，产品研发处于两难底部，前期投入大量资源进行产品研发而无法获取市场需求利益。A公司项目开发技术体系不合适在现有研发过程中，主要只有研发部门和市场部门两个部门参与，其他综合部门，财务部门，招商部，运营部等都几乎没有参与，或者对于市场调研以及开发环节的责任感欠缺，而实际上产品的设计研发并不只是市场部和研发部门的职责，从市场调研到后期生产、售后服务等环节都需要其他部门进行协调参与，因此产品的研发过程需要全员参与。A公司当前正在实施的品质计划更是与现有产品研发流程规划不相匹配。产品研发规划阶段是这个产品研发设计的初始阶段，也是改进产品实施的关键点，因此企业当前的产品研发流程将其他部门排除在产品研发流程之外是完全不可行的方案，这将导致各部门之间无法配合与合作，也无法充分发挥其他部门的作用与研发部，市场部的应有职能，最终导致研发规划流程中出现漏洞。现有研发体系中没有统一的部门研讨会议，仅仅研发部和是市场部独断决策，其他部门没有参与，也难以表达其他部门在研发规划流程的看法，也不能交换其他部门的关键信息，导致研发规划阶段问题审核过于片面化。软件开发方法模型不合理A公司软件产品开发流程仍然依靠传统的瀑布流式开发流程，这种瀑布式开发流程在产品进入市场初期有非常大的优势，是目前主流的开发流程。这种瀑布式的研发流程是通过设计一系列按顺序展开的环节从系统可行性分析到产品的发布与维护，规定了它们自上而下、相互衔接的固定次序，一般软件公司一个产品版本的发版周期需要6个月左右，而真正进入市场需要6个月之后，因此当前开发模型研发周期过长。缺乏对问题的回顾和预防相关讨论回顾和预防都是非常重要的环节，能够帮助团队不断优化和改进自己的工作流程，提高开发效率和质量。A公司的团队中对于回顾和预防的重要性意识不足，没有重视改进过程的重要性，团队领导者应该重复强调，并鼓励团队成员参与。团队中对于预防问题的流程不完善，对于回顾和预防问题没有明确的目标和议程，且团队中没有对于问题的会议分析和开放讨论相关的习惯，团队领导需要创造并维持团队对于问题的敏感性，以及积极讨论问题的工作环境，鼓励成员提出问题并分享观点。不仅如此，团队中成员对于问题分析相关思维辅助工具以及分析技术了解较少。2.2.2团队管理问题在团队管理方面，A公司的主要问题有3个，分别是：项目相关方参与度不够当前研发流程对变更管理严格，产品一旦进入研发阶段，就无法接受新的需求，也无法变更研发环节。项目相关方只有在产品研发结束后才能对产品进行检验，而产品开发一般与用户的真实需求都会有一定的差别，因此导致返工率较高。同时，在开发过程中产生的偏差，不能及时纠正，或者反映较慢。因此对于这种情况，当前研发流程并不适合。产品负责人选择过程不合理当前产品研发流程下，项目内部缺乏产品统一处理流程，项目内部重复处理，过度消耗资源，项目上发现的产品漏洞问题，产品负责人并没有发挥自己的职能，在项目上各自处理，处理方式也没有产品负责人进行统一规定，导致产品版本不一致或引发其他问题，造成人力成本的浪费。另外，对于产品负责人缺乏问题处理考核机制，导致问题处理由开发员工全权负责，问题处理时效性大幅降低。同时，由于项目开发资源有限，如果项目中的问题无法由产品负责人去协调，则问题得不到及时解决，没有人为问题处理时效性负责，导致问题解决慢，资源浪费多。对新需求的反应较慢这些问题都需要进一步改进。目前A公司产品后续运维服务仍然由开发部人员负责，实施人员兼顾软件开发和售后工作，因此对于市场中提出的新需求无法立即解决，需要开发部在完成其他项目开发工作之后才能进行解决新需求问题。2.2.3开发流程问题在开发流程方面，A公司的主要问题有2个，分别是：软件开发的主流程设计不合理A公司产品研发流程在研发设计阶段涉及开发组和运维组，其中开发组的职能包括测试和前端和后端。研发产品整体设计方案确定好之后，由开发组根据各自的任务进行产品研发设计，设计完成之后又由开发组进行测试，测试完成之后又需要开发组进行问题分析与改进与优化。因此软件开发流程中主要有两个问题：一是软件产品开发全流程几乎全由开发组承担，并没有任务分担，同时，运维组无法参与在产品设计阶段。二是运维组和开发组的测试存在重复工作，软件开发过程需要由开发组进行测试，测试完成之后无法将测试信息报告给运维组，因此运维组无法对软件产品获取足够的信息，无法对软件中的问题进行预先管理，导致运维组需要重新进行测试以熟悉软件产品，因此，开发组和运维组存在重复测试的问题，这也是因为运维组没有参与到软件产品的开发流程中，开发组和运维组之间没有信息交换，最终会造成内部资源的浪费并且会延长产品设计研发周期。软件测试流程不合理A公司在测试流程中最明显的问题就是测试范围不够清晰，如果测试范围不够清晰，则测试人员可能会错过一些关键的测试点或功能，导致产品质量下降。A公司的软件测试缺乏测试用例，测试用例是测试人员用来验证软件是否符合规格和需求的文档。如果测试用例不充分或不够详细，测试人员也会错过一些关键的测试点或功能。另外，A公司的测试流程中测试结果不及时，测试人员无法及时向开发团队报告问题，从而导致问题在软件中存在更长的时间。因此，测试团队需要制定有效的测试报告机制，并与开发部及时分享测试结果。2.2.4辅助工具问题在辅助工具方面，A公司的主要问题有2个，分别是：软件开发的系统持续集成以及持续交互水平较低系统持续集成需要依赖自动化测试，A公司的自动化测试不完善，导致集成时出现较多的问题，持续集成流程失败。同样，A公司的持续交互过程中自动化测试设计不完善，导致无法及时发现和解决问题。另外，A公司持续集成和持续交互的代码库管理不完善，包括没有合理的分支管理、没有规范的代码审核机制等，导致代码库混乱，集成和交互的失败率增加。前面也说过，A公司团队的交流较少，而系统持续集成和持续交互涉及多个人员的协作，因此，团队的职责边界不清，导致集成和交互过程出现问题。系统部署有待优化当前A公司开发工具系统配置长时间没有更新，而软件开发工具与技术更新速度极快，因此A公司的系统部署已无法满足高复杂度的开发流程，使用未更新版本系统对于开发效率与开发周期影响极大，不仅增加软件产品测试难度，同时软件产品与当前市场中的系统环境无法兼容，这将导致软件产品跨系统开发，从而又会增大开发难度。2.3本章小结本章着重介绍了A公司软件的开发流程并总结A公司软件开发流程和管理中存在的问题。针对这些问题后续章节将会提出解决方案。第3章A公司软件产品研发流程项目管理改进3.1综合管理改进通过问卷调查发现，A公司综合管理过程中的问题点为：组织结构不合理，需要进一步改进；A公司项目开发技术体系不合适，需要引入新的技术体系；软件开发方法模型不合理，有待进一步改进方法应用。可以针对性从改进组织结构、改进项目开发方法以及采用Scrum技术体系三个方面进行应对。3.1.1组织结构改进A公司当前的组织结构中设置了运营中心、财务中心，以及重庆、成都、武汉、兰州、西安、三亚等地运营分公司。在软件开发中，技术团队由专业人员及兼职业务人员组成，这种固定团队结合兼职业务方的方式属于混合型组织结构。混合型组织结构不利于项目内的协作，在兼职成员内驱力不足的情况下，项目经理一人协调所有的人员比较困难。具体的改进措施为，A公司改进当前的混合型组织结构，设置直线职能制组织结构。各个职能部门负责各个分公司的专业业务工作，如技术开发、财务控制、人力资源统筹规划等。而各个分公司则主要负责市场运营和属地的售后服务工作。改进以后，公司的专业化能力将得到极大强化。而重庆、成都、武汉、兰州、西安、三亚等地的运营公司也能将重心完全投入到市场业务开拓，一定程度上避免了之前混合型组织结构带来的困扰。3.1.2项目开发方法改进A公司需要从项目开发方法层面进行改进。针对当前存在的项目开发方法问题，最佳的改进思路在于选择合适的模型。当前A公司的软件开发中采用瀑布模型从上而下进行，一般来说一次交付内容会比较多，持续周期长，对于需求变更不友好。这种模型属于单体模型，系统复杂以及耦合度高是单体程序到一定规模必然出现的问题。而随着A公司的业务不断扩展，也遇到了类似问题，极大的影响了项目开发效率。通过文献和案例研究发现，项目开发方法可以参考敏捷开发的思路，通过集成功能模块，同时优化各个功能模块的组合以及信息采集来解决上述问题。3.1.3采用Scrum技术体系敏捷是一种思想，而Scrum是一个遵循了敏捷思想，追求迭代研发、持续集成的研发管理方法。经过国内外大量的软件项目管理研究发现，应用Scrum的软件研发项目能快速感知变化并作出反应，形成快速反馈循环，因此，项目生产效率高、成功率高、应用价值良好。Scrum的精华有两点，第一是短迭代，第二是自组织。Scrum将项目分成了若干个迭代周期，可以在需求变化的情况下快速感知变化并作出反应，通过快速迭代和增量开发系统和产品来适应需求。并且Scrum在项目中通过不断的沟通来收集和反馈理解上的差异，便于快速发现问题，促使团队持续改进。短迭代让团队可以形成节奏感，并在每个迭代后有机会进行回归，并在下一个迭代中提高。相比传统的瀑布流程，因为缺乏这样的反馈机制，团队的改进相对困难。同时，Scrum专注于在最短的时间内实现最有价值的部分，当利益和需求冲突导致混乱时，Scrum可以有效控制需求，抓住重点。在研发过程中，Scrum通过三个活动进行需求检验和适应，即每日晨会检查每天目标的进展情况并进行调整，进行次日工作的优化；评审和计划会议检验发布迭代周期目标的进展并进行调整，从而优化下一个迭代周期的工作；并通过对己经完成的Sprint的回顾，明确需要进行改善的内容和行动，以便使后续的Sprint更加高效、更加令人满意。因此，Scrum能快速感知变化并作出反应，及时的适应新的需求，形成快速反馈循环，保证了产品方向的正确性。A公司需要从技术体系层面进行改进。敏捷体系中应用广泛并且成功案例较多的有极限编程和Scrum，两种体系各有特点和各自适应的场景。目前，A公司主要采用极限编程的技术体系，这种体系在海外有较多成功案例，但是极限编程较为激进，从传统瀑布模式转换风险较大，最佳实践推荐的结对开发，会增加开发人员配比，导致成本上升，对于公司难以接受。相比之下，Scrum在国内外都有广泛应用，可落地性更强。因此，对于A公司来讲，将当前的技术体系改进为Scrum推动将更容易获得成功。3.2项目开发团队管理改进通过问卷调查发现，A公司项目开发团队管理的问题点为：项目相关方参与度不够；产品负责人选择过程不合理；对新需求的反应较慢。有待进一步改进团队组织形式和领导者选择。可以针对性从加强相关方参与、选择合适的产品负责人、建设敏捷型团队三个方面进行应对。3.2.1加强相关方参与A公司需要从相关方参与方面进行改进。以ABus业务为例，该业务涉及到的相关方包含业务方（运营、财务等部门）、产品中心、研发负责人、研发组、测试工程师、运维工程师等，不同的相关方参与项目的程度、时间投入、诉求、影响力都不同，为成功推进敏捷开发在ABus项目的落地，应对相关方进行梳理分析，并形成相关方参与度评估矩阵。（1）业务方：需求发起者，一般为财务人员、运营人员、司机甚至是公司老板。需求方在经营实践中发现系统的不足或需要新增的功能，如财务人员需要一个全新的财务报表功能，运营人员需要对派车功能增加车辆筛选功能，老板需要一个手机可以看到的可视化的经营面板。（2）产品中心：原始需求方一般不具备信息化相关专业知识，这就导致其提出的需求很难直接用于开发活动，产品中心的产品经理，通过聆听需求、调研需求，将原始需求方的想法汇总、归纳，进一步形成原型设计、需求文档、交互设计等专业材料，为开发工作提供依据。（3）研发负责人：开发工作的直接负责人，负责冻结开发内容和确定开发时间，以及协调管理相关开发的工作，在组织内部充当敏捷教练的角色。（4）研发工程师：研发工程师是开发任务的最终执行者，负责将产品中心设计的产品实施落地，最终将软件产品呈现给用户。（5）测试工程师：软件质量的检查者和最终确认者。项目开始，测试工程师按照产品设计文档进行“测试用例”编写，测试用例应覆盖全部需求设计。功能开发完毕后，测试工程师按照测试用例进行功能进行测试，检查是否符合设计要求，发现不满足设计要求的功能时需要将问题记录并告知开发者整改。（6）运维工程师：运维工程师是ABus项目生产环境服务器和应用程式的管理者，负责服务器和应用程序的检查、更新、安全。通过座谈会的形式组织了相关方一起讨论敏捷开发在ABus项目中落地的难点和障碍，分析各方诉求和利害关系，得出相关方参与度评估矩阵，如表5-1所示：表5-1方参与度评估矩阵Table5-1ParticipatoryEvaluationMatrix相关方不知晓抵制中立支持领导业务方C产品中心C研发负责人C研发工程师CD测试工程师CD运维工程师CD可以看出，开发团队对于项目管理模式变革是持保守态度的，过程中需要我们加强对相关方的管理，做好相关宣传和培训，使整个团队思想一致，行动一致。3.2.2选择合适的产品负责人A公司需要从产品负责人选择标准方面进行改进。根据敏捷开发思想，其中有一条为“经常地交付可工作的软件”。为了实践这个目标，需要一个产品负责人确定每次迭代的方向和目标，并且定义迭代将要发布的内容和时间，以及需求条目的优先级，同时可以将Sprint团队进行有效管理。当前对产品负责人的选择较为随意，在专案小组讨论的基础上，并参考相关文献研究，本文制定了A公司产品负责人选择标准。ABus项目团队中产品负责人从产品经理中选择（不同迭代不一定是同一个产品经理做产品负责人），其主要工作如下：（1）确定迭代的用户故事或需求范围，并细化为可开发的具体需求，为开发团队提供产品设计原型和需求规格说明书。（2）确定迭代的发布时间。（3）根据功能价值和公司需要，对需求做优先级排序。（4）验收开发团队完成的软件产品。（5）协调并且管理Scrut团队所有成员，使成员始终向着Scrut目标前进。（6）参与或主持Scrut计划会、站会、回顾会，统领Scrut团队向着迭代目标前进。总结来说，产品负责人是Scrut团队的舵手，其掌握着产品开发走向和团队努力方向，负责告诉团队做什么，怎么做，什么需要优先做，什么需求可以延后做，同时需要决策迭代过程中的需求变更、或者不可避免的延期。3.2.3建设敏捷型团队A公司需要从敏捷型团队建设方面进行改进。在团队内推行变革，除得到公司高层支持外，团队成员的认同和支持以及团队结构至关重要，关系到可否顺利将敏捷推行落地。A公司开发的产品涉及到Android、iOS、Web三种终端类型，研发中心工种包含后台开发工程师、Android开发工程师、iOS开发工程师、前端开发工程师、测试工程师、运维工程师几个工种。为了方便协作的同时，更好的拥抱变化，研发中心正式的组织架构调整为如图研发中心下设三个部门，平台部、前端部、测试运维部。平台部：平台部全部为后天开发工程师，为了更好的适应敏捷开发，业务平台将采用微服务架构，故后台工程师分为两个小组，微服务组和网关组；前端部：前端部包含Android开发工程师、iOS开发工程师和Web工程师，产出物包含移动端App、H5网页、微信小程序等，较平台部开发内容业务逻辑较简单，但是一定程度关系用户体验；测试运维部：测试运维部包含测试工程师和运维工程师，较开发工作相对独立，主要负责成果的测试和运维。研发中心组织架构调整后，还需要建立强矩阵类型的Scrut团队。强矩阵的组织结构中团队负责人权限更大，项目管理敏捷性更强，能够更好的跨部门安排和调配职能单位的资源，从而有利于完成难度较大的软件开发项目。Sprint团队由产品负责人领导，其除了确保开发团队所开发的内容是Scrut定义中的外，还需要做好团队协调管理，确保强矩阵中业务部门和研发中心、产品中心全职人员一样为Sprint目标冲刺。敏捷转型是一项系统性工程，需要团队的认识同步、行动一致。为了达到良好的预期，需要在团队内部进行了团队建设，参考PMP中团队建设内容，A研发中心对公司员工展开了相关培训和开展团队内部沟通会，最终有利于让团队一起向着敏捷转型奋力。3.3项目开发流程改进通过问卷调查发现，A公司项目开发流程问题点为：软件开发的主流程设计不合理；需求分析流程不合理；软件测试流程不合理；软件发布流程不合理。Scrum过程是迭代循环开发过程，为实现更好的管理效果，ABus项目需要将Scrum流程细化，在主流程之外定义了开发流程、测试流程和发布流程。因此，A公司可以针对性从采用Scrum主流程设计、制定Scrut计划，优化开发流程、优化测试流程、优化软件发布流程四个方面进行应对。3.1.1采用Scrum主流程设计A公司需要从主流程设计方面进行改进。根据敏捷开发的思想，需要制定符合Scrum方法的流程，经过文献学习、实际调研，本文按照标准Scrum流程制定A的内部开发主流程。整体过程可以划分四个阶段：需求获取原始需求来自用户、市场、公司各个部门乃至老板。需求方在系统使用或者经营实践中发现系统的不足或需要新增的功能，如财务人员需要一个全新的财务报表功能，运营人员需要对派车功能增加车辆筛选功能，老板需要一个手机可以看到的可视化的经营面板，用户认为登陆过程太过繁琐，原始需求往往较为粗糙，更多时候是用户故事的形式，需要在产品团队分析、梳理、挖掘、设计，然后按照商业价值依次排序，最终如表5-2所示：表5-2用户认为登陆流程Table5-2Userperceptionofloginprocess需求编号产品Backlog用户故事商业价值工作量初评优先级备注1用户模块-用户登陆用户故事15552用户模块-修改密码用户故事2353需要短信验证3用户模块-商品上架用户故事3554（2）形成产品迭代任务产品经理、开发团队和业务部门一同组织“计划会议”，会上由产品经理展示最新的产品，开发团队从中选择并细化，最终由开发团队确认形成表5-3。开发内容确定后，开发团队拆分开发任务，并评估工作量，最后优化任务间排序和优先级，形成可以执行的产品迭代任务，如表5-3所示：表5-3计划会议Table5-3PlanningMeetingsPB编号一级功能点二级功能点优先级备注估算时间1用户模块-用户登陆用户注册55用户登陆53权限检查432用户模块-修改密码验证码发送3需要图形验证码3设置新密码323用户模块-商品上架商品上下架54（3）迭代开发周期：本阶段由开发团队主导，开发团队按照产品迭代任务进行开发工作，为确保整体开发进度不会偏离计划太多，应组织“每日站会”，将各个团队的开发进度情况和开发难点明确出来，让每个团队成员对于迭代情况有较为全面的认识。同时要强调迭代团队的自我组织和管理，跨职能团队要保持良好的沟通，确保顺利实现目标。（4）验收发布并做评审回顾：本阶段由Sprint团队成员整体参与。首先产品和开发团队通过实际演示的方式展示本次目标中完成的功能，项目负责人根据之前确定的产品验收开发交付的迭代版本，最终发布产品迭代版本。为了以后更好的开展工作，还应收集问题反馈，并且分析寻找出现问题的根本原因，团队一起讨论解决方法，并将结果纳入改善过程。3.1.2制定Sprint计划改进开发流程A公司需要从需求计划及开发流程方面进行改进。Sprint确定后进入开发阶段，这个大阶段包括需求宣讲、制定计划和开发三个子阶段，如图5-4所示：图5-1测试流程Figure5-1TestingProcess需求宣讲会针对需求条目配合产品原型、需求规格说明书逐一讲解，做到开发人员深刻了解该需求的价值和目的以及要达到的效果。制定Spint计划是将需求分解为开发任务，并且将其根据任务依赖关系排序。主要包含两个活动，任务工作量评估和任务排序优化。工作量评估方法较多，如类比估算法、专家判断法，三点法等。为了较好解决前文所总结的“项目排期不准确”问题，A公司将采用三点估算法进行工作量评估。在完成工作量评估的基础上，进行任务优先级排序优化，最终确定整个项目开发计划，实现开发流程的优化。A公司项目开发的分支管理能够满足多迭代并行开发能力需要进行改进。版本控制中重要内容为分支管理模型，目前互联网产品开发常用模型有Git-flow、GitHub-flow、GitLab-flow、TBD-flow等。几种模型尤其各自的特点，在互联网行业应用普遍，但是不能满足多迭代并行开发、灵活增删待发布功能的需求，因此，本文在ABus项目中建立了新的分支管理模型。新的分支模型设定功能分支（feature）、开发分支（dev）、发布分支（release）、个人开发分支、主分支（master）。功能分支：一个迭代（Sprint）一般会包含若干功能点，为了方便任务管理发布管理，并且实现功能的灵活组合和独立发布，每个功能点建立独立分支，如feature-订单评价、feature-会员头像更换等。开发分支：ABus为分布式微服务系统，开发中需要各个微服务之间进行联调和集成测试，本地进行费时费力，为了方便团队开发，配置开发分支，联调代码在开发分支进行，配置自动发布，当需要联调或集成测试是只需要将所需代码合并到开发分支既可触发自动发布。发布分支：发布分支对应着一个迭代（Sprint）最终确认的发布内容，迭代启动时定义的发布内容因运营需要调整、开发未完成、功能设计缺陷等原因有可能进行调整，在迭代发布前两周再次确认迭代内容，评估可以发布的功能点进行版本冻结，建立对应发布分支，将功能点合并入功能分支，至此开发工作围绕分布分支展开。迭代发布后对应的发布分支仍旧需要保留一定时间以备修复缺陷。特别注意的是发布分支需要进行保护，普通开发人员不能直接提交代码，需要进行“合并请求”，开发负责人进行代码审核后方可将代码并入发布分支，从而保证发布分支的稳定和可靠。个人开发分支：ABus项目是一个多人合作、协同开发的项目，多人同时对一个分支进行开发文件提交时出现冲突概率较大，而且会导致分支代码频繁更新不利于开发进行，也不能保证核心分支的稳定和健壮，故核心分支是保护状态的，不能直接提交代码。日常开发中每个开发人员应建立自己的开发分支，开发时每个人签出自己的开发分支，用自己名字命名，待具备阶段性成果时通过“合并请求”的方式并入功能分支或者发布分支。主分支：主分支是代码仓库的初始分支。日常开发中不会对主分支进行操作，有版本发布时会通过“合并请求”的方式将发布的内容并入主分支，从而保证主分支的代码是对于最新的生产环境的可靠稳定版本。代码仓库建立后会有默认的起始分支（一般为主分支），启动一个Scrut后，会包含若干功能点，为了发布灵活，将每个功能点设置分支，如图中的Featrue1、feature2等，开发人员在功能分支进行开发，需要连调时将代码合并到连调分支并且发布到调试环境。在Scrut发布前会对开发中的功能点进行完成情况审查，可以如期发布的功能将会合并入发布分支（一般标记日期或周数），待开发完成进入测试阶段，测试通过后会进入发布流程，发布成功，代码会合并到主分支，完成一次循环。3.1.3测试流程改进A公司软件测试流程需要进行改进。软件测试在软件开发中起着质量保证的作用，通过测试可以及早发现软件开发中的功能性错误、对交付物是否满足设计要求，以及是否符达到约定好的技术要求，进行相关验证并且评估交付物的质量，最终实现高质量的软件系统交付。早年软件测试工作经常由开发人员兼任，随着信息产业的成熟，分工越来越精细，软件测试已经成为一个独立学科，绝大多数软件公司也设置了独立的测试岗位。软件测试已经形成成熟的理论体系和实践总结，A公司需要结合既定的Scrum流程和测试团队情况才可以达到良好的测试效果。如图5-2所示：修改用例修改用例修改BUG修改BUG逐条执行测试用例逐条执行测试用例否评审用例是是否通过开始需求学习撰写用例评审用例是是否通过开始需求学习撰写用例结束等待发布结束等待发布图5-2Scrum流程Figure5-2ScrumProcess根据Scrum流程，一个完整的开发周期内会进行若干小的迭代，每个迭代都是可以独立交付的，所以测试工作的组织也需要按照迭代进行。改进后，A公司的软件项目的每个迭代内执行测试流程如图5-4所示。（1）需求学习：测试工程师从用户故事入手，通过用户故事展开场景，最终进行细致的需求学习，做到从大处上手、从小处执行。需求学习的内容应包括但不限于业务功能、权限控制、辅助功能、数据约束、交互需要、表单约束、参数约束、性能要求等。（2）撰写用例：指对特定软件产品进行测试时具体测试任务的说明或描述。测试用例应该体现出测试方案、方法、技术和策略。具体内容应该包含测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并最终形成文档。可以简单认为，测试用例是为指导测试工作的一组输入数据、执行条件以及预期结果，从而检验交付物是否满足设计需要。一份可以完整体现需求的测试用例是测试工作有效的基础，所以应在全面深刻理解需求后，科学的编撰。（3）测试用例评审：如上文所述，测试用例是否完整、是否科学一定程度可以决定测试工作的有效性，所以当一份测试用例撰写后应组织相应的评审工作。评审一般需要组织会议，参会者包含产品经理（负责人）、开发工程师（负责人）以及测试工程师（负责人），现场由撰写测试用例的测试工程师逐条讲解测试用例，其他参会者对其进行评估，通过集体智慧避免测试用例的重大纰漏。（4）执行测试工作：待迭代开发完成提交测试后，测试工程师开始具体测试工作。测试工作需要对照测试用例，逐条验证，并作详细记录，必要时需要详细记录问题复现步骤，方便修复。待全部问题（或重大问题）修复完毕后，本次迭代内容测试完毕，可以进步发布流程。3.1.4软件发布流程改进A公司软件发布流程需要进行改进。迭代发布是每个迭代收尾步骤，将开发好的迭代发布到生产环境标志着本次迭代开发结束。为了更好的完成工作任务，本文对A公司软件发布流程进行了优化设计。考虑信息安全、操作熟练程度、分工明确等因素，生产环境由运维工程师专人操作，发布前开发工程师编写发布操作手册，运维工程师按照发布手册操作。改进后的发布过程涉及到运维工程师、开发工程师、测试工程师一起参与。（1）发布开始前运维工程师应确认本迭代具备发布条件，也即没有问题（或没有重大问题），如不具备条件应中止发布，迭代重新进入测试流程，进行修复完善，待问题解决后再行发布。（2）发布程序由运维工程师对照着发布操作手册进行操作，一般会涉及到程序更新、数据库更新和数据迁移等环节，需要运维工程师仔细谨慎操作，并作好的必要的备份以防不测。（3）程序发布结束后，测试工程师将对生产环境进行最终的测试，整体过程沿用测试流程，当生产环境没有问题（或没有重大问题）时表示本次迭代开发并发布成功。3.4项目管理沟通机制改进根据问卷调查结果，A公司沟通机制中的问题来自三个方面：软件开发的计划阶段缺乏沟通；项目组成员对其他相关组员的工作状态缺乏了解；缺乏对问题的回顾和预防相关讨论。这些问题都需要进一步改进。根据敏捷开发思想，沟通机制是很重要的建设内容，当我们将团队定义为强矩阵后，良好的沟通机制是敏捷方法执行好的基础。本文将从建立计划会议机制、建立Sprint站会机制、建立回顾会机制三个方面进行沟通机制的改进。在项目启动阶段，明确定义沟通渠道和频率，包括项目团队内部和团队与项目利用相关者之间的沟通。使用在线协作平台、邮件、即时通讯工具、会议等工具和技术。确保所有团队成员都清楚应该在何时、何地和如何进行沟通。指定明确的沟通流程，包括沟通的目的、内容、参与者和时间安排等。例如，每周固定的项目进度会议、每日的团队站会等。确保沟通流程简洁、清晰，并与项目目标和项目计划相一致。提供及时和明确的信息，确保项目团队成员之间能够及时和明确地交流信息。避免信息不准确、不完整或传递不及时等情况。倡导开放和透明的沟通文化，鼓励团队成员之间的开放和透明的沟通文化，鼓励各种意见的表达和交流。鼓励团队成员提出问题、分享想法和提供反馈，以促进更好的理解和合作。定期与项目利益相关者沟通项目的目标、进展、风险和问题等。通过项目报告、项目仪表板、项目演示等方式，项项目干系人提供项目的关键信息，以确保他们对项目的了解和参与。在项目中涉及多个职能团队时，建立跨职能沟通渠道，以促进不同团队之间的合作和协调。例如，设立定期额跨职能会议、创建跨职能团队共享平台等，以促进信息流动和知识共享。及时识别和解决项目中的沟通障碍。例如，语言障碍、文化差异、时区差异、信息部队等都可能影响沟通效果。采取积极的方法解决。3.5辅助工具改进根据问卷调查结果，A公司辅助工具的问题来自四个方面：当前的软件开发采用的分支管理不够理想；当前项目组软件开发的系统持续集成以及持续交互水平较低；当前采用的系统架构有待优化；系统部署有待优化。这些问题都需要进一步改进，如引入和优化一些辅助工具，如看板、版本控制、持续集成与持续交付等。不同的项目可能需要不同类型的项目管理辅助工具。确保选择的工具与项目的性质、规模和需求相匹配。例如，对于小型项目，可以选择简单的任务列表工具；对于大型复杂项目，可能需要功能丰富的项目管理软件。确保团队成员了解并能够正确使用项目管理辅助工具。提供培训和支持，帮助团队掌握工具的功能和操作。同时，考虑简化工具的使用流程，减少繁琐的步骤，以提高团队的使用效率。定期额审查和更新项目管理辅助工具，以确保其与项目需求保持一致。随着项目发展和变化，可能需要调整和更新工具中的项目计划、任务分配、进度跟踪等信息，以保持工具的准确性和有效性。考虑将项目管理辅助工具与其他团队使用的系统和工具进行整合，以促进信息的流通和共享。例如，将项目管理工具与团队的协同办公平台、版本控制工具、报告系统等整合，可以减少信息的重复输入和手工操作，提高工作效率。优化项目管理辅助工具以提供实时的项目信息和报告。通过仪表板、图表、报表等方式，项团队成员和项目干系人提供项目的实时状态、进展和关键指标，帮助他们更好地了解项目的状态和做出决策。考虑项目管理辅助工具的移动端和云端