XX公司软件开发流程优化研究

摘要
随着信息技术的快速发展和社会经济环境的变化，为了快速响应随之变化的市场，如何推出更有竞争力的产品，是现在所有软件开发企业普遍面临的核心问题。为了寻找有效的解决方案，越来越多的企业开始把焦点关注在软件创新与软件开发管理上，并且开始学习和尝试在企业内推行当前业界流行的软件开发管理模式。XX公司作为一家初创型科技公司，软件开发是公司的主营业务。目前XX公司正处于小型企业转变到中型企业的过渡期，研发的项目从最开始的轻体量、多数量的模式，逐渐在转化为中大型自营项目与周边项目相结合的模式，之前基于瀑布模型的软件开发模式已不再适应现有的项目规模，因此，在这一段时间内的开发过程中各种问题也开始显现出来，所以优化现有的软件开发流程成为了XX公司现阶段目标中的重中之重。
本研究旨在寻求较有效益的软件开发方法和流程，能使有限的XX公司人力资源充分发挥，并提升XX公司人WT项目的开发效率与质量。本文通过Scrum及Extreme Programming(XP)两种敏捷开发方法来优化XX公司软件开发过程，从初始阶段对于各项软件开发问题的发掘及应对、研究评估、订定目标、计划导入、到归纳出WT项目采用敏捷开发流程架构，希望使得WT项目可以加速软件开发速度及质量。本文的研究结果显示：1. 通过导入Scrum与XP混合方法，可以解决WT项目开发管理不佳、软件项目资源不足、软件项目需求不完整、缺乏用户参与及技术能力不佳等问题。2. Scrum与XP方法都提供明确的实践，但若仅照搬将无法达到很好的效果，而Scrum指导员角色相对上较重要，主要是因其在导入每个实践的过程都让所有的人都了解其目的及精神，在执行过程遇到问题时更要以实践的目的及精神为依据，不可随意更改实践方式，也不可任意的取消某个实践。3. 通过这些实践及流程确实帮助团队的形成，例如实施搭档编程，且一起工作的开发团队，开始常常一起讨论以找到最好的解决方案达到系统的功能。当开发团队被授权在开发出最好的产品的要求前提在可以自己决定完成工作的方法及时间后，开发团队开始了解许下承诺及完成承诺的重要，并依承诺交出最好的产品；产品负责人也从原本不信任开发团队到信任开发团队。

关键词：软件开发 ；流程优化； 项目管理 ；敏捷开发
Abstract
With the rapid development of information technology and changes in the socio-economic environment, how to quickly respond to the changing market and launch more competitive products is a core issue that all software development enterprises are currently facing. In order to find effective solutions, more and more enterprises are focusing on software innovation and software development management, and are beginning to learn and try to implement the current popular software development management models within the enterprise. As a start-up technology company, software development is the main business of XX Company. At present, XX Company is in the transition period from a small enterprise to a medium-sized enterprise. The R&D projects are gradually transforming from the initial lightweight and majority model to the combination of medium and large self operated projects and surrounding projects. The previous software development model based on the Waterfall model is no longer suitable for the existing project scale. Therefore, various problems have begun to emerge in the development process during this period of time, So optimizing the existing software development process has become the top priority of XX Company’s current goals.
This study aims to seek more effective software development methods and processes that can fully utilize the limited human resources of XX Company and improve the development efficiency and quality of XX Company’s human WT project. This paper optimizes the Software development process of XX company through Scrum and Extreme Programming (XP), two agile development methods. From the initial stage of the exploration and response of various software development problems, research and evaluation, setting goals, plan import, to the induction of the adoption of agile development process architecture for WT projects, we hope that WT projects can accelerate the speed and quality of software development. The research results of this article show that: 1 By introducing a hybrid method of Scrum and XP, problems such as poor development management of WT projects, insufficient software project resources, incomplete software project requirements, lack of user participation, and poor technical capabilities can be solved. 2. Both Scrum and XP methods provide clear practices, but simply copying them will not achieve good results. The Scrum instructor role is relatively important, mainly because it allows everyone to understand the purpose and spirit of each practice in the process of introducing it. When encountering problems during the execution process, it is necessary to be based on the purpose and spirit of the practice, and it is not allowed to change the practice method arbitrarily or cancel a practice arbitrarily. 3. Through these practices and processes, it is indeed helpful to form a team, such as implementing partner programming, and the development team working together often begins to discuss together to find the best solution to achieve system functionality. When the development team is authorized to decide on the method and time to complete the work based on the requirements of developing the best product, they begin to understand the importance of making promises and fulfilling them, and deliver the best product according to the promise; The product owner has also shifted from initially distrusting the development team to trusting the development team.

Keywords: Software development; Process optimization; Project management; agile development
目录
摘要 I
Abstract II
第一章 绪论 1
1.1 研究背景 1
1.2 研究意义 1
1.2.1 理论意义 1
1.2.2 实践意义 1
1.3 国内外研究现状 2
1.3.1 软件开发模型国外研究现状 2
1.3.2 软件开发模型国内研究现状 3
1.3.3 流程优化国外研究现状 4
1.3.4 流程优化国内研究现状 4
1.3 研究方法与研究内容 5
1.3.1 研究方法 5
1.3.2 研究内容 6
1.3.3 技术路线 6
第二章 XX公司软件开发流程现状 7
2.1 公司概况 7
3.1.1 基本情况 7
3.1.2 组织架构 7
2.2 主营项目介绍 8
2.3 软件开发流程现状 9
2.3.1 软件项目系统开发的生命周期 9
2.3.2 公司软件项目开发的项目管理流程 11
2.4 软件开发过程中存在的问题 12
2.4.1 调查设计 12
2.4.2 需求产生与分析阶段问题 13
2.4.3 系统分析与设计阶段问题 14
2.4.4 系统构建及测试阶段问题 15
2.4.5 系统上线与运维阶段问题 16
2.5 本章小结 16
第三章 XX公司软件开发流程问题分析 17
3.1 软件开发流程影响因素分析 17
3.1.1 外部环境因素 17
3.1.2 内部环境因素 18
3.2 软件开发流程问题分析 19
3.3 本章小结 21
第四章 XX公司软件开发流程优化方案的制定 22
4.1 流程优化原则 22
4.2 流程优化目标 22
4.3 软件开发流程优化方法 23
4.3.1 敏捷开发方法 23
4.3.2 Scrum方法 25
4.3.3 Extreme Programming简介 26
4.4 软件开发流程优化方案 27
4.5 软件开发流程优化方案实施 30
4.5.1导入流程 30
4.5.2 敏捷开发流程架构设计 31
4.5.3 敏捷开发流程导入流程 33
4.6 本章小结 34
第五章 XX公司软件开发流程优化方案的保障措施 35
5.1 人员保障 35
5.2 制度保障 35
5.3 组织保障 36
5.4 信息化系统保障 37
5.5 软件开发流程优化效果 38
5.6 本章小结 39
第六章 总结与展望 40
6.1 总结 40
6.2 展望 41
参考文献 43
致谢 47

第一章绪论
1.1研究背景
随着企业信息化的不断推进，软件需求呈现出多样化、异构化、变化快等特点，传统的软件开发过程已经无法满足市场及客户的需求。加之软件开发周期长、人力成本高、质量总体难以保证等问题，使得很多企业在软件开发领域面临不小的挑战。随着信息技术的快速发展和应用，越来越多的企业开始重视软件开发的效率和质量问题。为了提高软件开发的效率和质量，研究人员们开始探索如何优化软件开发流程，以更好地满足市场需求和客户需求。传统的软件开发流程通常是基于瀑布模型，即线性的、依次执行的开发过程。然而，在当今竞争激烈的商业环境下，这种开发模式已经无法满足企业的需求。因此，研究人员在寻找更有效的软件开发方法，逐渐形成了敏捷开发、迭代开发等新的开发模式。因此，需要通过优化软件开发流程，提高软件开发的效率和质量，从而更好地满足企业的业务需求。软件开发流程优化不仅能够提升软件开发效率和软件质量，还能够提高市场竞争力：快速、高效、质量保证的软件开发流程能够使企业更快地推出符合客户需求的软件产品，提高市场竞争力。公司软件开发流程进行优化是当前软件行业所关注的一个重要问题。通过实施有效的优化策略，可以提高软件开发效率、保证软件质量、降低开发成本、提高客户满意度等多方面的绩效，推动企业软件开发领域的创新和发展。
1.2研究意义
1.2.1 理论意义
国外关于软件开发模型的研究开展较早，研究已较为成熟，许多知名的大型互联网企业在不断优化软件开发项目管理的过程中，都曾尝试使用过敏捷开发、DevOps等较为先进的软件开发理论，比如Google、Azure、Facebook等；而国内的相关研究起步比较晚，但随着用户需求的越来越多样化，国内很多软件开发企业在各种交流和学习中，也开始逐渐引入敏捷开发模型，其中带头的有阿里、腾讯等。这些企业在实践出成功的案例后，开始通过沙龙等方式向外推广，这给其他类似的企业在运用这些模型优化项目管理时提供了借鉴。
1.2.2 实践意义
本文通过研究XX公司在企业规模过渡期间，如何使用软件开发模型和流程优化方法优化项目管理，以保证企业在技术和需求快速变化的背景下做出准确、及时的响应，最终提高用户的满意度，帮助企业在激烈的竞争中提高竞争力。通过对XX公司的探索、研究和总结，给其他类似正在实施或者准备尝试优化软件开发流程的公司提供参考思路。
1.3 国内外研究现状
1.3.1 软件开发模型国外研究现状
1913年，福特开发出了世界上第一条流水线，打破了汽车制造业的手工作坊式生产方式，这一模式的出现改变了世界。标准化和规模生产将汽车带入了寻常百姓家。在软件开发陷入生产效能无法满足日渐扩大的需求的困境中时，福特的“流水线”概念或许多多少少启发到了当时的软件开发者们[1]。
1970年，温斯顿·罗伊斯（Winston Royce）在论文《管理大型软件系统开发》（Managing the Development of Larger Software Systems）中提出，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落[2]。瀑布式开发（Waterfall Model）由此出现。
1978年，Kevin Forsberg和Harold Mooz 提出了 V 模型。V 模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。经过不断地进行改进，考虑系统架构和系统元素实体的并行开发，在1991年，他们在NCOSE第一届年会上发表的《The Relationship of System Engineering to the Project Cycle》论文中提出系统工程双V模型，双V模型增加了一个维度，以一种立体的视角看待系统开发过程。双V模型强调并发机会与风险管理；重视用户在开发过程中的持续验证；强调集成、验证与确认规划，通过验证解决问题[3]。
1988年，巴利·玻姆（Barry Boehm）在他的文章《一种螺旋式的软件开发与强化模型》提出螺旋模型（Spiral Model）。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统[4]。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。
1991年，彼得·道格拉斯（Peter DeGrace）和莱斯利·斯塔尔（Leslie Stahl）在《Wicked Problems, Righteous Solutions》中第一次提出了Scrum的概念[5]；1995年，杰夫·赛瑟兰（Jeff Sutherland）和肯·施瓦布（Ken Schwaber）在OOPSLA大会上首次公开演讲Scrum[6]；2001年，马丁·福勒（Martin Fowler）与吉姆·海史密斯（Jim HighSmith）等17位轻量级工程方法代表人物，在美国犹他州雪鸟度假村举办了一次研讨会，发布了敏捷宣言《Manifesto for Agile Software Development》[7]并在后来建立敏捷联盟（The Agile Alliance），敏捷开发的概念由此诞生。敏捷概念的出现，立即在当时发展成为了一场运动，被迅速地推广和应用。在早期，敏捷专注研发交付，目标是帮助产品和研发团队提升敏捷响应能力。但是，之后敏捷开发开始向用户靠拢，成为以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发[8]。
2009年，比利时独立IT咨询师Patrick Debois在比利时根特市组织了第一届DevOpsDays，DevOps（Development and Operations）正式登上舞台[9]。此后，DevOps发展迅速，已经为企业数字化的核心能力之一，是对IT交付和运行的基本要求。其中，以容器化和自动编排调度为代表的云原生技术的出现极大加速了这一进程。
1.3.2 软件开发模型国内研究现状
1991年6月，中国项目管理研究委员会(Project Management Research committee, China，简称PMRC）成立，挂靠在西北工业大学，是我国惟一跨行业的、非盈利性的全国性项目管理专业学术组织[10]。
2001年，参考美国项目管理学会（PMI）项目管理知识体系和国际项目管理协会（IPMA）的项目管理资质标准（ICB），PMRC正式推出了《中国项目管理知识体系》（C-PMBOK）。
2006年，第一届敏捷中国大会成功举办，与近千名与会者分享敏捷与软件价值的关系。这是敏捷第一次在中国被正式推广给IT本地社区。2007年，ThoughtWorks以“塑造敏捷企业”为主题主办第二届敏捷中国，将敏捷系统性的推广至中国IT企业[11]。
2016年和2018年，刘博涵，张贺和董黎明对国内DevOps从业人员进行了两次问卷调查。问卷从IT性能表现、组织文化及相关实践、开发与运维实践、工具支持、领导力、工作比例、员工敬业度及满意度、障碍这8个方面进行了调研。结果显示，随着DevOps实验经验的增长，团队在IT性能表现等方面可以得到显著提高[12]。目前，国内DevOps团队在敏捷方法和DevOps相关工具的采用实践较好，不同团队在具体方法和工具的选择上呈现出了多样性。
综上所述，随着互联网技术的迅猛发展，产生了一系列的软件开发模型，它们各有优点也有缺点，并随着软件设计思想的改变而发展。国内外的研究者对软件开发管理的方法和理论进行了大量研究和改进，一批以国内外科技巨头为首的软件开发企业都纷纷开始尝试使用合适的开发模型优化项目管理。
1.3.3 流程优化国外研究现状
1990年，哈默迈克尔（Michael Hammer）基于相关研究提出了再造性的流程优化理论，首创性的将企业流程再造的概念应用在企业工作管理范畴，企图用企业流程重建帮助企业快速成长，可最终结果并没有达到理想的预期效果，却给企业进行各项经济活动造成的剧烈的波动影响，对企业经营发展带来了不利的影响[13]。
1993年，Davenport首创性的开发了企业流程创新的理论概念，指明在企业发展过程中进行业务流程的创新活动，不但可以保障相关的信息技术和劳动力资源进行最优化的分配和利用，并且企业的成本、实践、质量等各个维度的重点指标都可以取得最大化的提升[14]。
2010年，Forrest在相关研究中指出，进行产品开发的工作环节，除了要积极应对市场消费需求的变化，另外在其他竞品新技术迭代升级的过程中，也要对市场风险进行合理规避，依托合作发展的模式建设起高效合理的企业工作组织结构[15]。
2012年，迈克尔·E·麦克哥拉斯（Michael E McGrath）等基于产品开发过程中生命周期的发展视角联合提出了产品开发理论：产品及生命周期优化法（Product And Cycle Excellence,简称PACE）[16]。
2018年，UY Dong和EH Hong等人经过深入研究后表明随着企业规模的增加，整个企业的业务流程系统也将变得越来越复杂，因此合理的过程管理工作需要企业可以识别流程中固有问题并且可以不断改进，对企业有限资源下做好过程管理工作十分有帮助[17]。
2019年，Aicha Wannes 等人提供了一个基于业务流程管理中重要绩效指标的标准业务流程优化方案，首先明确了重要绩效指标的生命周期，进而将重工业绩效指标体系添加为标准业务流程模型中和符号原模型的概念，是用关键业绩指标对流程工作进行的绩效评价，并提出了一些建议以支持管理任务和改进所采用的方法方式[18]。
1.3.4 流程优化国内研究现状
2000年，水藏玺在其知名著作再造优化流程中曾经详细阐述了流程的定义、流程优化的原则、流程管理的重要性以及方法等内容，在对于企业产品开发流程的市场价值分析的过程中，综合性利用ASME以及案例分析等策略开展，将工作流程优化的同时，通过改善商品价值，提升研发团队的工作效率，以期达到预期目标[19]。
2002年，梅绍祖、黄艾舟在他们的论文中提出原有的工作流程并不必全部进行推翻，而是需要结合企业客观的运作情况，通过科学的策略分析以及规范化的工作环节设计将流程进行持续改造，系统升级[20]。
2006年，张彦卿提出，对于一些高科技企业来说，研发流程的设计与优化已经成为加快创新速度，减少浪费，消除不增值时间的关键办法[21]。
2012年，金今经过研究针对我国企业流程优化中普遍存在的问题，提出了增强流程优化的观念、注重流程优化的实际应用效果、流程优化方案要视企业的实际情况而定、流程优化要持续不断的进行等四个方面的内容[22]。
2017年，鲁晓兵、孟兆荣等人认为流程优化主要来源于国内外市场的环境和企业内部的实际运作状况，如果企业产品在市场上失去竞争力，当职工们有怨言或者企业内部的组织流程等因素无法满足企业发展的时候，都可能启动企业业务流程优化[23]。
2019年，鲁月峰认为想要让企业发展得更好、更快、更稳，就必须不断地优化和改善公司自己内部新产品研发流程[24]。
2020年，师旭丽、唐定全、郭红峰等人将企业流程优化分为收集信息、识别问题、优化方案设计三大阶段，逐步进行流程改善或者优化设计[25]。
综上所述，流程优化，需要以提升企业绩效为目标，对现有的业务流程进行分析、梳理，对其中存在的问题进行完善、改进，从而实现组织间的无障碍沟通，增强组织间的横向协作，提升企业运作效率，降低企业运营成本，增强企业的竞争力。流程的制定与修改与公司的发展要相适应，初创公司基本没有流程或者只有很简单的流程，随着公司的发展和市场需求的变化，公司越大，业务越复杂，对于流程的依赖性就越强。一些公司在流程实施的过程中发现当前流程效率低下，部分环节甚至成为业务发展的障碍，必须通过流程优化才能使公司运转的更高效。
1.3研究方法与研究内容
1.3.1 研究方法
1．文献研究法
通过查阅诸多与软件开发流程优化有关文献资料，深入梳理国内外关于软件开发模型的理论和项目流程优化的方法，为解决XX公司软件开发方面遇到的问题提供坚实的理论支撑。
2．案例分析法
通过以典型案例作为研究素材，总结分析寻找问题的一般规律。本文以XX公司之前完成的项目为例进行研究，通过在这些项目开发过程中产生的问题进行分析总结，用以制定优化开发流程的方案。
3．调查研究法
通过与XX公司中拟参与到开发流程优化试点项目的相关人员进行沟通，了解他们对流程优化的看法和理解程度，并系统地分析XX公司以往项目的管理文档资料，对收集的信息资料进行归纳、比较和分析，找到XX公司项目开发流程方面存在的主要问题和产生的影响，能够客观全面地落实方案在试点项目的执行。
1.3.2 研究内容
本文梳理软件开发流程模型的优势和劣势；分析XX公司现阶段的开发模式和遇到的问题，选用合适的开发模型和流程优化方法设计软件开发流程优化方案；选择试点项目应用方案；总结分析，为软件开发流程项目的优化提供保障方案。
1.3.3 技术路线

图1-1 技术路线
第二章 XX公司软件开发流程现状
2.1 公司概况
3.1.1 基本情况
XX公司，是在A公司、XX公司的基础上，引入战略资本重组后设立。主要业务包含：社交电商app、小程序，社交沟通软件开发、供应链系统开发、游戏等软件开发；服务器租赁及安全防护业务；一站式聚合供应链服务等。XX公司以技术开发为核心，服务器硬件服务做支撑，供应链服务做赋能，专注于为社交新零售行业提供一站式服务。
目前，XX公司拥有专业软件工程师150余人，市场人员100余人，拥有软件著作权50余项。通过自主研发，已经形成了八大系列软件技术产品，包括：社交电商系统（单商户版、多商户版）、聚合供应链系统、云直播系统、即时通讯系统、第三方服务系统、仓储管理系统、商品溯源系统。
XX公司，秉承以“做好每一件小事”，为客户提供“聚合式服务”的宗旨，努力成为社交新零售第三方服务行业的领军企业，基于“超级工具+超级社群+产业生态”三大核心引擎，我们重新定义私域流量的商业架构和数据共享，助力中小微企和商界精英实现数字化营销转型。
3.1.2 组织架构
XX公司的主要人员与职能部门的主要职责如下：
1．总经理：负责全部经济类合同的最终审核；
2．资产物资部：负责材料采购类合同、硬件设备租赁类合同的招投标程序或比价程序的监督审核，合同价款合理性的审核，及监督以上述类合同的结算工作，及合同对方单位的专业资质的审核；
3．市场经营部：负责全部经济类经营性相关条款的审核和合同价款合理性的审核及工程（专业）分包类合同对方单位的专业资质的审核，监督工程（专业）分包合同和其它类合同的结算工作；负责全部经济类合同在其它部室审核通过后存档前的合同及附件的验收核对。
4．项目经理：协调项目层级采购部门之间的统筹工作，审定采购计划，参与价格谈判、对采购价格及合同进行初步审核。
5．项目工程部：根据项目计划，编制开发计划。
6．项目物资部：根据工程部提供的物资、制定采购计划并编制物资、硬件相关的采购、租赁招标文件。施工过程中的材料入、出库管理，材料使用记录，硬件进出场记录与台班使用记录。开发过程中的材料、硬件设备使用签认及验收后的结算工作。
7．项目经营部：根据工程部提供的劳务、专业分包需求，编制招标文件，向公司申请招标。与劳务、专业分包单位进行过程中的议价与验收后的结算。
8．项目质控部：在材料、硬件招标准备时提供相关技术参数，材料进场后负责检验、试验。施工过程中，对分包作业进行全过程质量控制、形成质量控制数据。
2.2 主营项目介绍
在社交软件方面，XX公司主营的自研软件WT，目前注册用户约500万人。
1、WT项目是一款基于区块链技术开发的加密商务即时通讯软件。是全球商务社交人士首选，具有安全加密、便捷稳定的特点.用户可以毫无顾虑地表达自己，认知他人，探索世界，交流兴趣观点，商业洽谈等。
2、特色功能：多方式登录注册、多语言(支持支持英文、简体中文、繁体中文三种语言)、聊天(支持一对一单聊、多人群聊、多人社群聊)、群会议、社群、区块链钱包、多账号管理、VIP会员管理、第三方代理、游戏中心等。
3、WT支持图片文字、语音、视频、群聊和文件传输等多种即时通信功能；打破了传统短信长度限制，实现了文、图、音视频、表情等融合的富媒体通信,让用户在WT中自在畅聊；通讯采用多种安全加密方式，防止用户个人信息被监控,为用户提供安全私密的畅聊场所，全类型消息收发，满足多种聊天场景。聊天内容支持文字、表情、图片、语音、视频、语音通话、视频通话、群会议、文件、地理位置等。
4、用户可以随时查看自己的好友是否在线,也可查看自己发出的消息对方是否已读,提升沟通效率；群会议:支持万人同时在线开会.可以提前预约会议,会议通知以卡片的形式发送给成员,保证即时通知到个人。
5、WT具有区块链技术保障，采用NAT穿越、端到端的多次加密等技术手法，实现安全私密畅聊.从而延伸出阅后即焚、消息上链、双向撤回、全球加速，等特色功能。
6、阅后即焚，在聊天前开启后,消息会在对方已读后自动销毁。正确使用阅后即焚能够有效保护用户的聊天隐私以及个人信息安全。而且阅后即焚还能增加聊天的趣味性，无需担心重要信息被留存或者外泄，能够让人更放心的讲八卦、更安全的发送重要的资料。
7、通讯录特色：可以方便使用扫一扫邀请新朋友 ，快捷与好友沟通交流；管理查看我的社群；发现页特色功能：拥抱社群、朋友圈、应用、游戏体验美好生活;特色会员功能：会员铭牌、昵称设置、等级加速、隐身、超级百万群、超长语音、优先人工客服等。
8、企业级社群特色功能:
（1）精细化社群管理：N层社群管理、无限子社群管理.根据社群关系，实现多级社群管理； 每个人都可以设子社群；主社群群主及管理员可以管理子社群。
（2）社群标签分层，多种方式建群，群精准推送，社群动态管理等，实现社群高效运营。
（3）社群公告,主社群的群主及管理员在发布社群公告的时候可以一键同步到子社群。
（4）社群动态：支持多社群同时发布一条动态；为社群管理提供灵活便捷的使用方式；多类型动态内容同发（图片、视频、语音、文字、表情等）（不限制数量及时间）。
9、WT拥抱开放,即将开放 游戏平台 商城 数字金融 行业咨询 钱包等 接入功能，各行各业各应用均可通过认证授权对接，共建WT商务沟通资源平台。在聚合供应链方面，系统提供“厂家入驻”及“商家API端口接入”功能，产品涵盖家居用品、母婴用品、个护美妆、食品保健、家用电器、服装鞋包、生鲜食品、电脑数码、家庭清洁、日用百货、跨境产品等20余万个SKU产品，以及包含京东仓等平台式供货渠道在内的一个综合性供应链平台。在游戏开发方面，技术团队凭借十余年的游戏开发经验积累，打造让游戏回归本该有的样子，让玩家享受更纯粹的游戏，想玩就玩，想走就走。游戏中所付出的每一点努力将都可以获得相应的物质和精神回报。
2.3 软件开发流程现状
2.3.1 软件项目系统开发的生命周期
软件项目发会经历一系列的工作包含需求分析、系统设计、程序开发、安装测试、后续维护，称为系统开发的生命周期，如图2-1。

图2-1 软件项目系统开发的生命周期
1．需求分析：一般而言，需求调研为项目开发过程中最重要的一环。根据组织架构，指派一专责团队，由项目经理带领系统设计分析师与用户单位进行结构式访谈。在此阶段，系统设计分析师持续和客户进行访谈以进一步了解系统的工作及信息流程，并通过上阶段的系统环境图，进一步开发出高级系统流程分析图。本项目在经过本阶段后，功能需求及产品需求将被定义。
2．系统设计：在系统设计中，客户访谈应持续进行，以再确认客户需求以针对最新变更作早期快速反应，并且进一步确认与功能需求(来自上阶段)的一致性，或通过组织的变更管理。项目在经过系统设计后，系统数据流程将被定义，并且开发出符合此系统及客户希望显示的数据的模型。系统设计大体上包含使用者界面设计、数据库设计和细节规格设计。本阶段重点之一为系统雏型的开发。此系统雏型在此时非能完全被操作，然而客户却能从雏型获得未来系统的轮廓，并作进一步的产品沟通，以确保客户的原创需求的彻底实践。如此与客户不断的进行产品界面的沟通与确认即为本阶段所采用雏型式项目进行模式的原因。
3．程序开发：程序水准与撰写质量关系到整体系统合适的成败。任何一个潜在的规模程序错误都必须在这时期充分找出并除错。针对由上阶段产生的模块化系统设计，再根据 workbreakdown structure (WBS)，来展开程序开发工作。
4．安装测试：客户将针对其使用模式来做验收前的测试。一旦测试不合格，项目组织将针对不完善处进行变更需求来修改系统，直到测试合格。一旦测试合格，则进行系统移交。
5．后续维护：一般而言，项目组织都提供项目完成后一定期间的产品服务及使用者教育上线保证。在这保证期间内，对于使用手册等相关客户拥有的文件所无法回答的问题，项目组织都将尽力协助解决，并安排专业人员至系统现场进行维护及解说。
2.3.2 公司软件项目开发的项目管理流程
项目管理的五大流程为起始（Initial Process）、规划（Planning Process）、执行（Executing Process）、监视与控制（Monitor and Control Process）、结项（Closing Process），如图2-2 所示。

图2-2 软件项目管理流程
1 起始（Initial Process）：起始程序组是指确认一个项目应开始进行或进入另一个阶段，并获得对它执行的承诺。主要选择出值得做的项目，接着是发展项目的愿景（Vision）与建立项目的目标（Goal）。
2 规划（Planning Process）：规划主要清楚的定义在这个项目中有那些工作要做，以及要识别需要那些资源及专业人力才能完成这个项目。主要产出是完成一套具体可行的项目计划书（Project Plan），作为后续项目工作执行的依据及成效控制的基准。
3 执行（Executing Process）：执行是指运用人力及其他资源，共同去完成预定的计划。
4 监视与控制（Monitor and Control Process）：监控程序组是指借监督与进度评量及采取必要的修正行动，以确保项目目标的达成。主要任务就是依据项目计划所定的项目工期、质量及成本的基准，来衡量项目进度、工作的成效、与预算的支用，并采取必要的改进措施，以确保进度不落后、预算不超支、及需求能在合理掌管下方能变更，并使其能与项目目标相符。
5 结项（Closing Process）：结项是指项目最后的收尾动作，包括人员的归建、相关剩余资源与工作的善后处理、最终产品或结果的接受与移转、文件的存档与结项报告的撰写等。
目前公司软件项目开发，配合项目管理的五大流程，在起始阶段初步评估，依项目规模召开会议，以便评估该项目是否可以参与，实际取得项目时，规划所须资源的作业方式和配合时间，制作项目管理计划书，接着开始执行项目，团队成员建立、沟通方式的建立、外包商的选定，以利项目的进行。由启始、规划、执行、项目结项，从项目起始阶段至结项阶段，同步监控项目进行，对质量、需求、绩效、风险监控与管理。
2.4 软件开发过程中存在的问题
2.4.1 调查设计
本章以深度访谈（in-depth interview）方法，采用开放式问题进行数据收集。通过访谈主要了解受访者对于XX公司现行信息开发的经验与流程，并从访谈过程中的逐步拼凑信息开发各阶段的问题与脉络。受访者包括XX公司软件部门经理与一般软件开发人员，受访者的挑选是根据本研究议题与信息的丰富程度，首先挑选数位具代表性的资深软件开发人员（年资10年以上）作为首轮受访对象，接下来分别针对信息经理与较资浅（年资3年以下）为受访对象，受访者名册如表2-1。
访谈过程持续至新的受访者不再对研究关注议题提供新的信息而停止。每位受访者时间从30分钟到1小时不等，访谈地点多选在软件部门会议室与休息室等让受访者不会感到拘束的场域，访谈进行方式为研究者先向受访者表明研究议题与目的。在访谈的过程中，研究者以纸笔记录受访者的回应。
表2-1 深度访谈名册
代码 性别 年龄 年资 主要工作
MIS01 男 39 11 软件开发人员
MIS02 女 46 20 软件开发人员
MIS03 女 36 10 软件开发人员
MIS04 男 44 14 软件开发人员
MIS05 女 38 13 软件开发人员
MIS06 女 29 2 软件开发人员
MIS07 男 32 2 软件开发人员
Lead01 女 42 18 AP经理
Lead02 女 42 10 AP经理
Lead03 女 45 21 AP经理
Lead03 女 47 13 AP经理
软件部门单位约63人，其中负责系统程序开发的程序设计师约有43人。由于近年来随着客户的不断扩增，软件开发人员也有扩编场景。软件开发人员年龄组成与年资分布由下表(表2-2)可得知近50%人力为35-45岁之间，且年资多数在5-15年之间，而近3年人员流动比率约4.7%，人力素质应属常态分配，人力流动少、稳定性足够。
表2-2 XX公司软件开发人力年龄与年资表
年龄 人数 年龄比率 年龄 人数 年龄比率
25岁以下 3 7% 5年以下 15 35%
26-35岁 12 28% 6-15年 17 40%
36-45岁 18 42% 16-25年 8 19%
46-55岁 7 16% 26年以上 3 7%
56岁以上 3 7%
合计 43 合计 43
在信息开发技术方面，主要使用的程序语言多达5种之上，因此造成人员技能不足、信息架构及开发工具老旧，其直接的影响就是维护的复杂度增加，使得运维的风险增加、创新性与灵活度不足。XX公司软件开发系采用传统的瀑布式(Waterfall Model)软件开发模式分为需求分析、设计、实现、测试等阶段，每一阶段结束才可进入下一阶段。信息系统开发方式多采自行开发为主，自制系统约占八成。每项软件开发项目或信息系统需求的负责人多数仅1个人负责，多者则不超过8个人。每位程序设计师同时间皆须负责超过2项以上的软件需求，每项需求自系统开发初期至系统上线的完工时间少则1天、多则数月不等。
2.4.2 需求产生与分析阶段问题
根据XX公司实际状况分析，其信息需求来源大多来自各式各样的会议、电话沟通、公文要求与信息需求系统等，有些需求产生则是直接由高层经理口头要求，有些需求甚而来自移动社交工具（如微信、QQ等）。再者，在系统需求分析方面，可分为需求访谈、可行性评估、轻重缓急评估三方面来分述：
一、需求访谈：XX公司软件部门并无规范需求访谈格式，程序设计师可自由发挥。另一方面，XX公司的软件开发人员多为资深员工，其与用户多已有长期合作关系，用户往往直接从系统功能面要求系统的运作方式，因与用户的长期累积默契下，有时候这可以减少沟通的成本，因为程序设计师可直接自用户处明确地得到软件需求，但是往往却不知道这个功能的用处，而产生不知为何而做，且不了解其开发工作价值的状况。
二、可行性评估：XX公司软件部门需求可行性评估通常可分为数据收集可行性评估、工期可行性评估，与信息技术面评估。在数据收集可行性评估部分，数据收集可行性会影响软件开发人员评估系统复杂度，若数据已曾经于其他系统被收集，则系统可行性较高，而若数据须从新流程重新收集，则系统较不易被设计，且范围较大。而工期评估与信息技术方面（如开发技术人员的能力和技术的成熟度以及能否将产品实体化的能力，包括硬件开发能力、软件开发能力与资源可用性等）皆仅仅以程序设计师平常的工作经验做判断基准。
三、轻重缓急评估：XX公司软件部门对于需求的处理优先顺序则无一定标准，通常都是根据XX公司最高级经理或组织现行迫切需求为主，其余多数需求则都以程序设计师的个人经验判断为基准，根据个人工作的安排为其需求开发的顺序。
最后，需求分析文件产生并没有一定的形式，所采用的工具皆为简单的文书工具（如Word、Power point、Excel、Visio等）或纸本文件所制作。需求访谈所产生的文件为简单笔记或会议记录，需求分析所产生的文件则无实际产出文件，多数皆储存在程序设计师或用户记忆中，而少数较佳的做法，则为产出流程图。需求分析后，若为软件开发人员1人独立开发的项目，则虽会再与用户再次确认，但多仅为口头确认，而非书面确认；若有多人开发者，则仅有简易需求作业流程图，但因多数用户看不懂软件开发人员所沟通使用的系统流程图所表达内容，而无法达到落实与用户再次确认的重要步骤与效果。
2.4.3 系统分析与设计阶段问题
XX公司软件开发人员多数为1人开发某项功能，由于多为单人独立作业，因此在系统分析与设计层面，大多仅以设计用户界面(User Interface，UI)为系统分析与设计阶段的产出文件，并在UI画面中再辅以各种元件的功能描述，用以帮助用户能快速地了解未来系统开发完成后的界面。少数系统开发项目会进一步依需求整理出功能清单（Function List），其主要用以搞清系统范围，以确保需求访谈阶段的产出，能接续至系统分析阶段。功能表的内容多数仅为功能项目的描述，并未详细其功能项目所涵盖的作业流程。
再者，在系统设计阶段，将需求转换成有组织的信息系统开发规格与文件是系统开发过程中最为重要的一关键环节。然而，在XX公司中软件部门多数软件开发人员并不喜欢使用实体关系图（Entity-Relationship Diagram, ERD）来处置数据库设计部分，且更不喜以新增数据库表（Table）方式来解决某些功能问题。因此，若碰到需要以新增数据库表（Table）的时候，由于新增数据库表（Table）时，为了不增加系统复杂度，则多数以原有参数文档的形式来解决，因此造成数据定义模糊且各自解读不同的场景发生。
若有需要绘制ERD的情事，大多为启动较大项目（是指跨团队项目），或全新项目系统时，才会使用。另外，少数人会在设计时，会自发性找出不同系统间的相同的功能，并将信息系统功能模块化，但往往仅为自己负责的系统所使用，无法提供其他系统使用，多数原因主要为不愿再因其他系统所需要的功能，花费多余时间再次重构该模块。
2.4.4 系统构建及测试阶段问题
在系统构建阶段，可分为程序编程（Coding）与系统测试两个层面说明。程序编程阶段是指信息系统的建立、修改、扩充或更新等程序，该阶段最关键产出即为可交付使用执行的系统。要判断系统是否能交付执行，程序质量是相当重要的依据，但程序质量通常会随系统不同而有差异；多数特性是共通的：可用性、易于维护、以及可扩充性。
XX公司对于易于维护与可扩充性则根据软件开发人员的个人经验与信息技术程度不同而有所不同，若个人经验丰富或信息技术程度较高者，多数能在设计阶段就注意到系统日后的可维护性与可扩充性的议题，并较愿意多花点时间思考系统结构间互相搭配程度。另外，也有部分人员是根据个人喜好或时间因素的问题来评估是否要考虑维护性与可扩充性。个人喜好通常是指软件开发人员对在系统的熟悉度、用户或同事间的合作程度，而时间压力也是影响软件开发人员是否能有适当时间思考很重要的因素。
再者，对于信息系统质量可用性部分，则多数软件开发人员会重视系统回应速度，但对于信息系统是否有根据需求规格，完成可以交付用户的程序，则完全依赖软件开发人员个人经验来判断系统可用性程度。
系统测试是一种用来促进鉴定信息系统的正确性、完整性、安全性、和质量的过程。系统测试的目的主要是指尽可能地找到软件中的多一点错误，而不是完全证明软件的正确性。XX公司惯在系统完成后，软件开发人员简单测试后，直接请用户操作信息系统，有些时候甚至直接由用户测试，但操作信息系统后，略微查证系统所产生的数据的步骤是有的，但完整性则见人见智。
2.4.5 系统上线与运维阶段问题
在软件生命周期中最后一个阶段，即为系统上线与运维阶段。XX公司软件部门在系统运维中，各系统的源代码皆统一放置规范位置，且代码为所有软件开发人员共用，若有问题，则多采取直接读取代码逐一检视方式。前述曾提过，XX公司多数为单人独立开发，因此多数系统较无备份人力，然而重要的系统，如WT项目则会配置多名软件开发人员共同运维。
2.5 本章小结
在XX公司担当应用系统的软件开发，为客户量身订做开发应用系统，配合客户的需求，从现有的经验经由访谈和讨论，必须了解客户语言才容易清楚了解客户表达，在沟通上才能顺畅，以利规划出符合客户预算、工期和范围的应用系统。而在实际的开发过程中，XX公司的软件开发存在大量的问题，需要后续进行研究和优化。

第三章 XX公司软件开发流程问题分析
XX公司中信息系统上线多数无法准时上线，依据XX公司自行统计结果，其信息系统准时交付比率仅为50%。再者，XX公司在信息系统上线后，少数系统会发生使用率不佳的场景发生，此类系统被归称为蚊子馆。本小节将进一步针对XX公司软件开发流程问题进行详细研究。
3.1 软件开发流程影响因素分析
软件开发流程影响因素主要可分为外部环境因素与内部环境因素，外部环境因素主要区分为用户与使用组织两种；内部环境因素则区分为人员问题与技术问题。
3.1.1 外部环境因素

1. 用户
   (1). 信息需求改变
   用户根本没有需求冻结的概念，需求确认只是形式，跟他们谈变更管理也无济于事。以上类似的抱怨固然有其个别的情况因素与困难，因此，用户常随着项目开发时间的递移而会有因情况与状况的改变而需求有所改变。另外，由于XX公司提出信息需求的用户多数并不了解信息化过程中，传统作业流程应随的改变，因此，再提出信息需求的过程中，皆以原作业流程为其需求依据而导致信息系统产生与实际运作不符合，难免需要再三调整设计而延误项目上线工期。
   (2). 设计不符合用户需求
   软件开发人员设计出不符合用户所需的系统是常见的场景，主要的原因来自于多数系统需求仅仅通过电话、需求单或会议的告知，而未能让关系人密切参与开发过程。再者，也有部分软件开发人员会因为自己设计的方便性，而说服用户或忽略用户真正的需求本质，而做出不符合实际的系统。
   (3). 用户要求上线时间与实际需要上线时间相差太远
   XX公司曾发生过数起信息系统完成后，用户却认为目前无上线的必要性而延缓实际上线时间，造成软件开发人员认为系统完成却无法验收的窘境。除此之外，等到系统真正上线时，往往又因为需求情况改变，而系统不符合设计。
   (4). 用户尚未准备好
   延续上述信息需求改变原因，主要是作业流程改变，而作业流程改变过程除了信息系统本身以外，尚有许多配套措施，如标准作业程序(Standard Operating Procedures，SOP)修正、用户教育训练等。因此，系统真正上线的时间一再修正。
2. 组织
   （1）信息需求插单
   俗话说：计划永远赶不上变化，变化抵不上老板一句话。这世界变化的速度永远比我们想象得还要快，无论我们做了多详细的计划，过了几天以后，可能发现又需要调整。为了应对各项客户变化，莫不以信息技术来作为策略工具。因此，每年信息需求规划皆赶不上政策变化，导致原规划工期一再延误。
   （2）软件开发人员与用户对在系统上线认知不同
   在软件需求分析的过程中，所遭遇的主要困难，在于通常需求都是以自然语言表示；然而，自然语言的语意在本质上是极为模糊及不确定的。尤其软件开发人员能否有效地了解用户所表达的需求程度，发展出符合其需求的信息系统是信息系统关键成功因素之一，但实际上，却往往与用户在信息需求的认知上，可能因沟通、协调上的不足或是对问题定义不清楚而产生认知上的差距，以导致所开发出的系统未能符合用户的需求，而未能达到预期的效果。
   软件开发人员及用户对在系统可上线的认知不同，主要是软件开发人员认为系统开放后，就可视为上线，但用户却不这么认为，主要原因是缺乏验收机制，而容易造成双方对在系统可交付的标准存在认知冲突。
   3.1.2 内部环境因素
   1.人员问题
   （1）项目时间预估错误
   任何一项工作的工期安排，都需要具备三项条件：起始日期、结束日期以及与其他工作的依存关系。XX公司软件开发人员常使用甘特图(Gantt Chart)、工作分解结构（Work Breakdown Structure,WBS）来描述工作项目与时间安排。但XX公司多数信息工程的工期估算大多为执行者根据个人经验自订工期，而无一定预估工期的合理的判断准则。
   （2）跨团队或多人开发时，项目工期不易掌控
   跨团队或多人开发比起单人开发更多了沟通复杂度，XX公司软件开发人员平常大多习惯单兵作战。而且跨团队或多人开发时，项目的任务相依性更高。项目间互相等候，只要中间有工作步骤延迟了，项目就延迟。
3. 技术问题
   （1）程序质量太差
   测试的过程中，用户常发现系统对于例外处理有许多没有考虑周详的地方。主要由于当初的系统分析，设计几乎都只有写出正常流程（normal scenarios）的处理方法，对于例外鲜少描述。为什么软件开发人员不做足够的测试呢？主要是写程序的时间都不够了，那有时间去测试。
   另外，在运维阶段也常发生功能异动时，改完程序之后原本可以动的其他程序却不能动了，而软件开发人员可能不知道原因，且需要再耗费额外时间debug。改程序（因为需求不清或是需求改变而改程序）、ebug以及testing的时间加起来绝对是远远超过所谓的coding（写第一遍程序）的时间。
   （2）未考虑到用户环境与设备合适性
   随着信息科技不断的演进，现在使用的先进技术和架构，在未来都有可能会被淘汰。该问题发生主要是软件开发人员并未对于用户现状有所了解，导致在开发过程中，未将相关的环境特性和需求考虑进去。例如需要考虑硬件、软件和网络状况三者间应如何调配—增加PC电脑一台或更换操作系统为Microsoft等。
   3.2 软件开发流程问题分析
   XX公司在现行需求产生与分析阶段，发现信息同事在需求访谈往往忽视需求本身的价值，只关心要做出什么功能，此类问题可归纳于非企业价值导向的问题根本原因。而在可行性评估与轻重缓急评估期间，主要问题多因于个人技术及经验不足，造成评估结果不佳与未符合经理的期望，且在需求分析时，也会发生需求分析错误，却也没有再与用户确认，上述几类问题皆可归纳于学习及成长不足的根本原因。
   在系统分析与设计阶段，软件开发人员多数为单人负责系统，且因个人方便或技术不足，设计出不易扩充，弹性差的架构，此种问题可同时归纳于缺乏监督与学习及成长不足的根本原因。
   在系统构建与测试阶段，也同时因单人负责系统，所以经常因为个人方便或技术不足而撰写出扩充性低，阅读性差的代码，且因个人技术或经验不足，而导致测试质量不良，或者因时间不足，无法完整测试，影响代码质量，此类问题亦可同时归纳于缺乏监督与学习及成长不足的根本原因，而时间不足则是归纳于缺的合理时间的根本原因。而在系统上线与运维阶段，最常见的问题系为因备份实施不确实，造成运维效率不佳，甚至产生孤儿系统，此类问题则归纳于备份制度不佳的根本原因。
   而项目延期的问题则可梳理出下述问题描述与问题根本原因对应：1. 用户的需求根据时间而环境的改变而发生变化，造成开发出来的系统不符需求，对应未即时反馈用户的根本原因；2. 用户不了解信息化的意义，而提出不正确的需求，造成开发出来的系统不符实际运作场景，对应用户信息知识不足的根本原因；3.与用户沟通不良，造成开发出来的系统不符需求，对应未即时反馈用户的根本原因；4. 其他信息需求插单，造成原有工程延期完工，对应需求优先顺序变动的根本原因；5. 因认知的差距及沟通不良造成对系统完成及上线的定义有所不同，对应未即时反馈用户的根本原因；6.项目时间预估错误，则对应 学习及成长不足与软件开发是复杂的工作本来就不易预估的根本原因。
   最后，根据相关研究指出，项目管理五大风险包含项目需求不完整、项目资源不足、管理不佳、缺乏用户参与以及技术能力不佳。因此，再以项目风险管理观点呼应XX公司在软件开发上所遇到的问题根本原因，整理结果如下表(表3-1)。
   表3-1 XX公司根本原因问题与风险观点对应表
   软件开发阶段 问题根本原因 项目风险管理观点
   需求访谈 非企业价值导向 管理不佳
   可行性评估 学习及成长不足 技术能力不佳
   轻重缓急评估 学习及成长不足 技术能力不佳
   需求分析 学习及成长不足 技术能力不佳
   系统分析及设计
   缺乏监督
   学习及成长不足 管理不佳
   技术能力不佳
   系统构建 缺乏监督
   学习及成长不足 管理不佳
   技术能力不佳
   系统测试
   学习及成长不足
   时间不够 技术能力不佳
   项目资源不足
   项目延期
   未即时反馈用户 管理不佳
   项目需求不完整
   缺乏用户参与
   用户信息知识不足 技术能力不佳
   需求优先顺序变动 管理不佳
   学习及成长不足
   软件开发是复杂的工作本来就不易预估 管理不佳
   技术能力不佳

运维 备份制度不佳 管理不佳
其他
无建立团队机制
非企业价值导向 管理不佳

搞清XX公司软件开发问题后，下章节将针对XX公司现状问题分析结果选定适合的敏捷软件开发方法，并进行敏捷开发实践导入的规划设计与研究。
3.3 本章小结
本章主要研究了XX公司软件开发流程问题，主要分为内部因素和外部因素。XX公司软件开发流程是保证软件质量，提高开发效率的重要手段。然而，不完善的软件开发流程可能会导致许多问题，如时间管理、质量控制、成本预算等方面不足，影响公司的竞争力和业务增长。目前XX公司软件开发流程问题的主要原因有学习及成长不足，时间不够，未即时反馈用户，用户信息知识不足，需求优先顺序变动，学习及成长不足，软件开发是复杂的工作本来就不易预估，备份制度不佳等。

第四章 XX公司软件开发流程优化方案的制定
4.1 流程优化原则
在XX公司软件开发中，深入的了解和实践良好的软件开发流程，可以大幅度提高研发效率和项目质量，缩短研发周期，并为客户提供更高品质的服务、广阔的市场前景等优势。下面是一些公司软件开发流程优化的原则。
1.灵活性：开发流程应该具有灵活性，以适应各种需求和逆境。为了满足不同的产品和需求，建立一个可扩展和可自定义的开发流程模板，并加强管理层到实际业务组间的数据、规范交付。
2.防范错误：应采取必要的措施来避免错误的产生（例如在各种测试中），并加强与其他项目部门或团队的沟通，及时纠正问题。
3.代码复用：鼓励最大限度地重用程序代码。这将促进更快的开发和测试、加强修改版本的可维护性和不断提高系统健壮性。
4.技术选型：及时采用和推广行业前沿技术和方法。随着新技术的不断涌现和更新换代，企业必须保持敏锐度和创新才能跟上市场或行业趋势。
5.流程改进：持续迭代其人身员、流程方案，以提高开发流程的效率和响应及时性等。同时建立现代管理理念的企业文化并由审计机构进行衡量大的质量标准。
总之，以上原则是为了满足不断变化的市场需求和自身技术感知而提出的。优秀的软件开发流程需要灵活、防范错误、发挥代码重用价值、积极探索创新技术和持续改进等原则的支持，在日常开发中得到切实的应用。
4.2 流程优化目标
优化公司软件开发流程的目标是提高效率、降低成本、加强质量控制和提升信任度，从而使企业获得更高的竞争力，更好地为客户服务。
1.提高效率：通过改进软件开发流程，能够减少需要重复操作，统一规范接口和协议，提高工作效率。简化过程，防止手动操作中的错误，自动化代码提交、构建、测试和部署等环节也能快速实现。这有助于更快、更智能、更精密地完成开发工作，并缩短上市和更新时间。
2.降低成本：采取更有效的软件开发方式将同时优化成本控制。例如，通过使用敏捷开发模式及其相应的自动化和管理工具，可以提高生产效率并避免无意义的延时和过重的裂项。另外，通过统一资源分配，优化人员资源配置和项目规划，能够大幅降低IT部门预算和相关项目成本。
3.强调质量控制：由于从事核心业务和建立公司品牌形象的软件存在多个依赖链、风险点和安全隐患，因此软件质量和可靠性是企业核心优势。在进行软件开发时，应该充分考虑质量控制并采用各种合规标准和工具进行代码测试、审查等环节。这有助于降低错误数、加强方案操作完整性及得到客户更高的信任度和满意度。
4.提升信任度和建立口碑：顾客和公众对公司的信誉是企业保持市场竞争力的关键元素之一。通过优化开发流程并提供高品质软件产品可以增强用户体验，同时，通过持续性改进和优化流程执行，可以树立在"可靠来自专业服务队伍" 的品牌形象。
总之，提高软件开发流程效率、降低成本、强调质量控制和提升品牌形象感知，这些目标可以结合实际情况来确定和评估，并不断追求开发流程的改进和优化，为企业自我价值和行业竞争带来相应的有利影响。
4.3 软件开发流程优化方法
4.3.1 敏捷开发方法
敏捷开发是一种以快速响应需求变化和灵活开发为目的的软件开发方法。它是一种迭代式、协作式和自我组织的方法，旨在缩短开发周期和提高项目质量。以下是敏捷开发方法的特点如下：
1．迭代开发：敏捷开发采用迭代开发的方式，在每个迭代期间内集中精力完成部分功能，而不是在一个长时间段内完成整个项目。每次迭代都可以得到客户的反馈意见并进行相应的修改，操作简单、容易理解。
2．灵活变通：敏捷开发鼓励团队在软件开发过程中灵活变通，适应需求的动态变化。进一步确定需求时会根据实际情况做出调整或者重新制定优先排期，通过及时地沟通，更好地满足客户需要以及克服项目管理上的挑战。
3．紧密合作：敏捷开发强调紧密合作的原则。这种合作包括和客户、业务部门、质量保证团队等不同团队之间的协作与沟通,保证业务一致、工序有效，减少不必要的工作反复、浪费和沟通成本。
4．自我组织：敏捷开发队员具有自我组织能力，通过制定迭代目标、分配任务来自我管理团队，有效降低中间层管理人员的数量。这样可以使团队更加灵活地响应变化，灵活将重心转移到一些关键任务上面，爱护团队，新的设想也能快速地加入和实现。
5．持续交付：敏捷开发致力于持续交付高质量产品。项目开发过程中持续性几乎是敏捷开发的中心思想，客户或最终用户在开发过程前期可以获取个别功能而不必等待全部境况完整后组合使用。此外，利用各类编译工具和自动测试工具为指导团队更好的控制和保证软件代码质量。
总之，敏捷开发是一种注重团队内部协作、快速且质量不亚于传统开发方法的软件开发模式。它已广泛应用于许多领域，特别是在应对快速变化的业务需求方面，可大幅提升软件开发的效率和有效性。
敏捷软件开发宣言中还包含了12项敏捷开发原则（Agile Manifesto）：
1.软件开发团队最优先的任务，及早并持续地交付有价值的软件来满足客户需求。
2.软件开发团队竭诚欢迎改变需求，甚至已处于开发后期亦然，敏捷流程掌控变更，以维护客户的竞争优势。
3. 经常交付可用的软件，频率可以从数周到数个月，以较短时间间隔为佳。
4. 业务人员与开发者必须在项目全程中每天密切合作。
5. 以积极的个人来建构项目，给予他们所需的环境与支持，并信任他们可以完成工作。
6. 面对面的沟通是传递信息给开发团队及团队成员之间效率最高且效果最佳的方法。
7. 可用的软件是最主要的进度量测方法。
8. 敏捷程序提倡可持续的开发。赞助者（利害开发者）、开发者及用户应当能不断地维持稳定的步调。
9. 持续追求优越的技术与优良的设计，以强化敏捷性。
10. 精简（或最大化未完成工作量的技艺）是不可或缺的。
11. 最佳的架构、需求与设计皆来自于能自我组织的团队。
12. 团队定期自省如何更有效率，并适当地调整与修正自己的行为。
综合上述，敏捷开发方法论就是为了拥抱改变应运而生，敏捷开发是一种以人为而核心、反复开发（迭代）、持续验证、持续整合的开发流程。敏捷开发模式虽然是一套最能容忍需求变更的软件开发模式，却仍有三项待改善的缺点，分别是不重视分析与设计阶段、缺乏一套完善的建构管理与版本管制措施、与未考虑文件可追溯性。仔细分析这三种缺点，主要系对开发完成后，系统后续的维护及需求变更作业（含版本控制、需求可追溯性等），将形成非常不利的影响。因此，开发团队在推行敏捷开发方法时，如何能兼顾快速开发与后续长久的维护，是值得深思的问题。
敏捷开发的方法论有许多种，如XP、Cockburn的水晶系列方法、开放式源码、High smith的适配性软件发展方法（ASD）、Scrum、Coad的功用驱动开发方法（FDD）、动态系统开发方法（DSDM）、以及Lean Programming等都可以归入敏捷开发方。目前最普遍的敏捷开发方法为Scrum与XP，或者两者混搭亦为常见的方式。Scrum和XP有许多共通点，包括它们都是反复式（Iterative），项目被拆分成许多迭代，敏捷团队执行所有完整项目所有的活动，在每次迭代最后产出可用的、可部署的软。
4.3.2 Scrum方法
Scrum是一种敏捷开发方法，主要用于软管理和迭代式开发。以下是对Scrum方法的简介：
1．团队角色：Scrum方法中有三个重要角色，分别是产品负责人、开发团队和Scrum主管。产品负责人将客户需求转换为产品特性列表（Product Backlog），确保团队明确项目目标并准备好迭代，同时任何可能阻碍完成产品目标的障碍。开发团队则执行工作，并通过持续积极反馈来形成自我最优化。Scrum主管团队则支持团队，以确保他们理解并适用Scrum框架中的实践。
2．迭代周期：Scrum方法使用时间盒（Time Box）来控制每个迭代周期的长度，称之为Sprint。每个Sprint周期通常从1到4周不等，根据一个事先确定的特性列表来进行工作。迭代周期结束时，开发团队必须向团队展示其完成的功能。
3．产品特性列表：通过制定一个产品特性列表，产品负责人可以更好地了解哪些特性应该作为Scrum迭代开发的任务。这个列表通常是根据客户需求和商业目标来组织的，包括通常被称为用户故事的短语，并与对应的开发任务关联起来。
4．日常Scrums：每个Sprint周期，开发团队都会举行日常Scrums或站会议（Daily Scrums/Stand-ups）。这是一个15-30分钟的例会，用于讨论进展、团队反馈和任何可能会影响项目成功的全面事宜。
5．回顾和迭代：在Scrum中，每个Sprint结束后，Scrum团队都会召开回顾和迭代会议。这个会议记录、总结如何提高产品特性列表和Scrum过程中的缺陷，并确定了下个Sprint周期中需要改进的地方。
总之，Scrum方法主要采用了一系列敏捷思维，强调增量式的开发和快速响应变化的能力，为团队提供了一个灵活，高度可见的迭代开发框架。它已成为管理和执行软件开发项目的流程规则的有效手段，各类规模的企业都可以按照自己所需对其进行适当定制。
4.3.3 Extreme Programming简介
极限编程（Extreme programming, XP）是敏捷开发中最普遍最被接受的几种方法学之一，其与传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；与传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，XP有能力在项目，周期的任何阶段去适应变化。因此，信息开发导入XP能符合高变动性、高复杂性、定制化程度高的特质。
XP的价值帮助团队改变心态，如果团队抵制改变，回绝客户的需求而一味建构团队自己想象的软件，不相信建构易于(或可能易于)改变的软件，则不能算上有在采行XP。拥有正确心态的团队总会使用最好的实践，如同Scrum一般，XP也拥有五种价值标准：沟通(Communication)、简化(Simplicity)、反馈(Feedback)、勇气(Courage)以及尊重(Respect)。沟通是指每位团队成员都知道其他人正在做的工作；简化是指开发人员集中精力撰写尽可能最简单和直接的解决方案；反馈是指持续的测试和反馈回路可以确保产品的质量；勇气是指每位团队成员都专注于为项目做出最好的决策，即使这意味着必须丢弃失败的解决方案或用户完全不同的方来着手处理；尊重是指每位团队成员对于项目来说都是非常重要且有价值的。
总体来说，企业导入敏捷开发于软件项目开发前，帮助团队理解Scrum与XP的价值与原则是非常重要的。团队成员真正理解价值时，他们将会拥有正确的心态，而实践才会开始有意义，而原则帮助团队自我反省，让团队思考自身是如何工作的，如此才能让团队拥抱改变。而许多价值和原则是Scrum与XP共有的，不过也有很多不一样的处，如表4-1所示
表4-1 Scrum与XP比较表
敏捷方法 相同的处 不同的处
Scrum
[实践]
故事、回顾
白板/信息化
工作空间
承诺/整个团队
冲刺/每周循环
[价值与原则]
公开/沟通
专注/充满活力的工作
尊重
勇气 [实践]
每日 Scrum 会议
燃尽图
故事分数
速度
[角色]
Scrum主持人
产品负责人

XP
[实践]
测试先行程序设计
渐进式设计
简单设计
持续整合
坐在一起
[价值]
简化
反馈
其他
[原则]
改进
质量
重复性
共同利益
人性
自我相似
小步伐

4.4 软件开发流程优化方案
由于WT项目具备高变动性、高复杂性、定制化程度高的特质，因此，适合使用敏捷开发来解决，使用环境变化与不确定性高的问题。再以敏捷开发最普遍的二种方法Scrum与XP来看，Scrum着重于项目活动的管理，特别适用于需求不明与经常变动的WT项目，而XP特性为持续整合、重构、与小型发布，着重在软件技术管理。
XP的实际作法有以下12个：客户为团队成员(Whole Team)、用户故事(User Story)、短周期(Small releases)、搭挡编程(Pair Programming)、测试(自动化测试, 单元测试, 测试驱动开发法(Test-driven Development))、代码共有(Collective code ownership)、持续整合 (Continuous Integration)、持久稳定的步调(Programmer welfare: Sustainable pace)、规划游戏(Planninggame: Release Planning, Iteration Planning)、简单设计(Simple Design)、重整(Design Improvement: Refactoring)、隐喻 (System Metaphor)。
(一)、客户为团队成员：要求客户或用户要在一开始就参与开发团队中。随时可以回答开发人员的问题，并决定开发的方向。其实这部分就像Scrum要求的产品负责人的角色及职责一样。
(二)、用户故事：是一个需求评估的工具，要求内容包含角色、做什么及达到什么价值。这工具可以帮助提升用户及开发团队间的沟通成效，也可以让用户思考该功能及需求的价值是什么，而不会一味地想要一些空想出来的功能。还可以让开发团队更深入的了解该功能及需求可以帮助用户达到什么价值，开发团队不会陷入不知为何而战的地步，也会更有成就感。
(三)、短周期：就如Scrum的Sprint一样，要求开发团队要在短而固定的时间内完成一个可执行的程序功能，展示给用户看。目的在尽快的获取用户的反馈，因为用户常常无法很明确的了解系统将会是什么样子，也不知道自己是否真的是要这样的功能，所以在短时间内就可以看到可执行的系统功能，就可以很明确的知道自己的需求是什么，进而调整需求。也让开发团队检验开发方向是否正确，如果不正确，将立即修正方向。
(四)、搭挡编程：目的是可以增进系统质量，增加系统的可扩充性，促进人员的成长，同时还完成了备份的机制。作法顾名思义就是由两个人搭档一起设计一起写程序，同时看着同一份代码，一起思考、设计、讨论，在大多数情况下，一位人员打字，另一位观看并不断讨论。因为有两双眼睛一起看着代码，所以可以减少缺陷注入到代码中，且直接通过代码沟通，所以也增进了代码的可读性，当然也增加了可扩充性及可维护性，相关研究指出实行双人编程可以减15%的错误，且92%编程人员会更享受他们的工作，同时96%编程人员对自身表现更有信心，且在提高程序质量的前提下，为了要达到跟搭档编程环境相同的程序质量时，单人编程会比双人编程多花费40%~50%编程时间。在思考、设计及讨论的过程，同时也是在做知识传达及教授。最后由于系统是由两个人一起开发出来的，所以两个人都可以轻易地维护及修改。
(五)、测试：传统程序设计中的测试目的当然是为了增加系统的质量及可用性，在XP 中当然也包含这个主要目的。但是除此之外，XP要求撰写单元测试程序，除了增加系统质量及可用性外，还为了常常变动的需求，而为了不断提升系统质量所做的重构动作，提供一个可以维持系统质量的方法，在任何的代码修改后，只要通过所有的单元测试，就可以相信这些修改是没问题的。因此开发团队就愿意积极的去改善系统的质量，系统质量会持续的提升。XP 还提出测试驱动开发法，提出一种测试先行的观念。传统程序开发方法都是在写完程序之后，再开始写单元测试。但是测试驱动开发法要求在开始写一段程序前，就要先把测试单元写出来，当然一开始测试都是不通过的，然后再开始写程序一一通过这些测试，当全部测试都通过后，系统功能也完成了。测试驱动开发法有二个好处，一是直接把写单元测试程序的工作放在程序设计过程中，不会再因为时程等因素而不写单元测试程序。第二个好处是先写单元测试程序，表示会先思考该如何使用这个将要写的function、class或功能，这样一来就会以使用的角度来思考，会写出最有价值最必要的功能，而不会浪费时间做出过度设计的动作。
(六)、代码共有：程序源代码是由整个开发团队共同拥有的，任何人都可以依需要去修改任何部分，目的是在于开发工作在进行时，其阻碍最少，不会因为某一个人的个人原因(例如休假、没时间、个人喜好等)而造成某个功能无法修正或新增。甚至有人发现代码某部分可以重构时，就可以立即动手重构，因为代码是属于大家的，这样对于提升整个团队重构的能力也有很大的帮助，进一步也可以让系统质量持续变好。
(七)、持续整合：开发团队每一个人修改或新增任何的代码，都要随时的整合到唯一的产品代码中。目的是为了把未来系统整合的问题及风险降到最低。因为不断的把变动过的程序及功能整合到产品中，一发现问题立即修正及沟通。就不会因为开发人员各别的程序开发很长一段时间后，才发现彼此的代码无法整合在一起，才发现一开始的沟通及认知不良，这时候再来修正则必需花更多的时间及人力，当然也造成了更多的浪费。
(八)、持久稳定的步调：XP认为软件开发工作是一个高脑力密集且富创造力的工作，而这种工作如果超过一定的工作时间，就会无法思考，因而生产力也会变低。不只如此，更容易在代码中注入缺陷，不只在短时间内降低生产力，更因为缺陷造成未来的Bug变多，扩充性变差，可维护性变低，这些都会让开发团队必须花更多的时间及人力来处理。所以XP要求每个短的开发周期时间必须固定，不可随意的增加，让团队了解自己真实的生产力为何，让用户可以知道系统开发进度并预估其完成时间。
(九)、规划项目：XP不做一个完整的规划，而是建议一小段一小段的规划。项目一开始只有一个很粗略的纲要，所有的细节都是到了要真正开始开发系统时才开始去推敲及规划。这些需求在XP中是利用用户故事来描述，就像Scrum的产品待辨清单一样，需求事项是有顺序性的，顺序越高的项目表示越是要接着开发出来的功能，所以顺序越高的项目也必需要有最足够最充足的信息，让开发团队可以把需求转换成系统功能。
(十)、简单设计：这项实践简单的说就是在开发过程要尽量用最简单的设计，整个代码及系统架构都是如此。目的在于产生简单易读的代码。代码越简单易读，就越容易了解、修改、Debug及扩充。XP有二个建议，1. 不要过度设计：只针对目前的用户故事作必要的最简单设计，不用去假想未来可能会如何，开发团队总会把”你将用不到它＂这句话放在心中，谨慎地考虑何时该把不久的未来需要的设计于到这次开发中，会去评估如果现在没有于进去，到时候真的需要时会有什么后果，只有在有足够的理由说明应该加到这次设计中，才会把它加进来。2. 仅只一份代码：努力的去除重复的代码，因为重复会增加代码，同时也增加了系统复杂度。甚至在修改时也容易注入错误及缺陷。所以会要求团队建立抽象化来降低耦合性。
(十一)、重整：在不改变代码外在的行为下，修改代码的内部结构。代码在经过一段的时间上线及运维后，会开始老化，这里指的代码老化是因为不断的修改代码后造成的结果，无论是Debug或修改功能都会慢慢的把原来的代码变糟，把原来计良好的架构搞差。如果一直放着不管，代码会变得越来越难阅读，越来越难维护及扩充。所以经由重构的动作来把代码变得简单易读，变得容易维护及扩充。
(十二)、隐喻：利用在某个领域的词句来表达系统，使团队较有一致的概念，以达到比较优值的沟通为目的。例如微软的操作系统桌面有一个叫资源回收桶及剪贴簿的功能，都很容易让大家理解及联想其功能，都是一个很好的隐喻。

4.5 软件开发流程优化方案实施
4.5.1导入流程
本章以XX公司导入敏捷方法后为时间切点，本阶段执行期间为2021年11月至2022年5月，以参与式观察法（participant observation）针对XX公司导入敏捷方法的实际情况进行第一手数据采集，数据收集持续进行至论文撰写，并通过实地观察、互动、记录的连续过程融入XX公司的实地情况，观察过程中本研究不操作研究现象与研究对象，仅以研究参与者的相对客观角色进行观察记录。
本研究基于参与的研究伦理，在研究进行前先取得XX公司软件部门经理同意，明确揭露研究者的身分与研究进行的目的。本研究在研究场域进行参与者观察作为数据收集的目的有两类，其一系为观察参与敏捷开发的人员，及其之间的工作互动与关系，其二为观察导入敏捷开发过程中，其开发团队的运作与工作成果呈现。具体在研究场域参与观察的方法，研究者自2021年11月至2022年5月期间，参与每次敏捷开发会议，除与团队各类角色互动外，也参与每日会议，观察时间从15分钟至2.5小时不等。在观察的过程中，研究者以纸笔记录现场景况及重要参与者之间的互动与对话。
4.5.2 敏捷开发流程架构设计
依据XX公司现状问题分析结果，以及研究者在XX公司多年对其文化和开发人员的认识，选定适合的敏捷软件开发方法，并进一步建构敏捷开发流程架构。下列针对项目管理五大风险与根本原因选定敏捷软件开发方法，并描述预期成果
一、针对管理不佳观点，导入Scrum与XP，预期达到：
(一)、以企业价值来制订需求顺序
(二)、在软件开发过程有监督机制提升质量
(三)、建立可执行的备份机制
(四)、调整企业文化强调团队合作
(五)、建立团队打破工程师个人主义
二、针对项目资源不足观点，导入Scrum，预期达到：
(一)、建立合理的项目时间推估方式
(二)、给予项目团队足够的时间
三、针对项目需求不完整观点，导入Scrum，预期达到：
(一)、以企业价值来提信息需求
(二)、建立更适合的沟通模式
四、针对缺乏用户参与观点，导入Scrum与XP，预期达到建立更适合的沟通模式。
五、针对技术能力不佳观点，导入XP，预期达到：
(一)、建立互相学习成长的机制
(二)、建立提升用户信息能力及认知机制
表4-2 导入敏捷开发方法计划表
风险 问题根本原因 导入方法
管理不佳 1. 需求优先顺序变动
2. 缺乏监督
3. 备份制度不佳
4. 非企业价值导向
5. 无建立团队机制 Scrum
XP

项目资源不足
1. 缺的合理时间
2.软件开发是复杂的工作本来就不易预估时间 Scrum

项目需求不完整
1. 非企业价值导向
2.软件开发是复杂的工作3 本来就不易预估 Scrum

缺乏使用者参与 1. 未即时反馈用户 Scrum
XP
技术能力不佳
1. 开发人员学习及成长不足
2. 用户信息能力不足 XP

导入方式是以Scrum软件项目开发流程为基底，结合适合的XP实践方法，建立一套适合XX公司的开软件开发流程。如下图4-1所示。

图4-1 Scrum结合XP流程图
项目开始后第一件事就是建立团队，包含决定产品负责人，选定开发团队，选定Scrum指导员。团队的建立人选非常重要，团队里的成员要包含完成项目目标所需所有的技能，例如产品负责人对产品应该产出什么企业价值要有能力去了解。也要有把企业价值转换成功能的能力，最重要的是能分辨那一个功能最有企业价值，而决定项目开发的方向。
需求访谈及分析主要产出为产品待辨清单，产品待辨清单由用户故事组成，产品负责人要负责建立产品待辨清单，并且排定顺序，高优先权的先进行开发。这边要注意这和传统瀑布式开发方法有一个不同的地方，这份产品待辨清单不需要是完整的，也不需要每一个用户故事都是仔细分析过的，不需要知道每一个细节，只有在最高优先权的用户故事，接下来一两个Sprint要开发的用户故事才需要最完整的细节。整个项目未完成前，产品负责人可以持续的增加用户故事到产品待辨清单中，也可以调整顺序，甚至删除用户故事。
Sprint开始就举行计划会议，产品负责人说明用户故事给开发团队，开发团队在了解用户故事后决定这本Sprint要完成那些用户故事。这部分要注意的是开发团队自己要能决定这个Sprint可以完成多少个用户故事，任何人都不能干涉。而产品负责人则可以决定那些用户故事要先完成。
接着开发团队将开始程序设计工作，包含分析、设计、测试等。在此也导入了搭档编程以提升程序质量、强化备份、增进学习及成长。每天都会举行每日站立会议，以达到开发团队间的信息交流。代码是整个团队共有的，开发团队会持续的把新增或修改过的代码整合到版本控制主机上，并要求商业逻辑层的程序都必需撰写单元测试程序。
Sprint结束前要举行评审会议，由开发团队向产品负责人(必要时还可以包含用户)展示本次完成的系统功能，让产品负责人了解开发团队的开发速度，且可以通过可以执行的系统功能确认产品方向是否正确，必要时可以修改产品待辨清单。
Sprint结束后应马上举行回顾会议，帮助开发团队找出本次Sprint中影响团队工作的因子及障碍，加以检讨、改善及排除，并且在回顾的最后阶段，请团队成员互相说出值得讚许的处，这些皆为协助团队能自我组织及自我成长的重要活动。
最后产品负责人可以决定现在的产品是否已足够满足用户，如果已足够了就可以结束本项目，如果不足够将继续下一个Sprint直到项目完成。
4.5.3 敏捷开发流程导入流程
导入前准备工作：分三个部分，一是针对经理，需要说明敏捷开发方法的优点，让经理接受及认可。二是针对PM，除了让他们了解敏捷开发的好处及精神外，更要教导他们如何成为产品负责人。最后则是针对程序设计师，同样的要让他们了解敏捷开发的好处及精神，还要教导他们熟悉简单设计、重构及隐喻等观念，以便在开发过程谨记在心，才可开发出较高质量的代码且可适应多变的需求及环境。
4.6 本章小结
本文采用敏捷开发进行软件开发流程优化。敏捷开发强调团队合作、客户需求、快速反馈和持续交付，能够更加适应变化的需求，并提供更快的上线时间。XX公司需要根据具体业务需求和情况，选择适合的方案进行优化。同时，还需要根据实际情况，制定合理的规范和准则来管理各项流程和资源，以确保整个优化过程的实效性和持续性。

第五章 XX公司软件开发流程优化方案的保障措施
5.1 人员保障
在公司软件开发流程优化方案中，人员保障是必不可少的一环。以下是一些保障方案：
1．培训和技能提升：公司需要为员工提供相关技术的培训和学习机会，以期提高员工的技能水平和知识储备。营造良好的学习氛围，鼓励员工刻苦学习，成长进步。
2．合理的流程和规范：公司需要建立完善的流程和规范，确保每个环节都有具体的责任和路径。员工能够在规范、统一的环境下工作、协作和交流。
3．高质量的工作环境：提供一个舒适、宽敞、安全和高效的办公环境，让员工充分发挥个人潜力，并增加员工之间的互动和合作。
4．典型案例和成功经验：有针对性地总结和分享成功的案例，激发员工的工作热情，并为他们提供更多的参考和借鉴。
5．绩效考核和福利带动：制定合理的绩效考核标准，并在业绩达到一定水平时给予相关的奖励和福利，促进员工积极主动地参与和贡献。
6．扁平化管理：公司应打破原有的等级和权威体系，建立一种扁平化管理模式，在尊重人性和价值的基础上优化整个组织结构。建立开放、互相信任和协作的团队文化。
总之，优化公司软件开发流程中，从人员保障方面入手是至关重要的。通过给员工提供各种保障，能够激励员工的工作热情和创造力，使他们更高效的完成任务，从而提高软件开发效率和质量。
5.2 制度保障
在软件开发管理体系中，软件开发管理制度尤为重要，它是所有软件开发管理工作开展的基础及规则。因此，XX公司WT项目积极从制度体系入手，逐步制定和完善了各种制度。
（1）完善体系文件。XX公司WT项目自成立以来，制定并发布实施了《软件开发管理制度》、《软件开发人员守则》等软件开发管理各项制度与规定。然而，单靠这些制度显然并不能满足一个完整的软件开发管理体系的要求，因此，有必要对现有制度进行进一步细化和完善，同时还要补充制定相关制度。XX公司WT项目现行的一些软件开发管理制度是在公司成立之初编制的，随着企业内外部环境的变化，有些内容已经不符合当前工作需要，因此，要根据企业发展战略、发展现状和制度实施情况，对现有的软件开发管理制度规定进行补充和完善，做到有章可循、切实可行、环节清晰，确保软件开发管理工作正常开展。例如，《软件开发管理制度》需要补充和完善软件开发管理考核等内容。同时，XX公司WT项目不仅对现有的规章制度进行了完善和补充，还根据公司的发展需要制定了新的规章制度。如《软件开发管理规范》、《新软件开发管理规定》、《软件开发管理分析报告》、《软件开发管理测试规定》等制度规定，并且在实施过程中不断增加和完善。同时，在软件开发管理体系实施过程中，XX公司WT项目加强了软件开发管理组织部门与各部门软件开发管理负责人的沟通，并以制度的形式规定了对各个部门软件开发管理制度实施情况的指导、监督及考核。
（2）加强绩效管理结果应用。绩效管理结果应与人才使用相结合，通过信息化手段。建立员工考核档案，充分发挥绩效管理结果在目标工资分配、专业技术职称评定、优秀人才选拔、岗位变动、评优评模、职务变动方面的重要参考作用，形成能力与业绩并重的用人向导。首先，用绩效管理的结果指导员工工作业绩和工作技能的提高，通过发现员工在完成工作过程中的困难和工作技能上的差距，制定有针对性的、合理的员工培训计划。其次，在重点关注员工“业绩、能力、态度"三方面的综合考评结果，客观、公正的反映出员工对公司做岀贡献的大小，以此为据，将员工的业绩成果与目标薪酬挂钩，合理分配。同时要注重绩效管理的薪酬量向岗位艰苦的一线倾斜，引导员工合理流动，解决企业员工队伍的结构性矛盾，为防止企业人才流失的问题打下一个良好的基础。绩效管理制度实施后，员工的薪酬就应当根据其绩效管理的结果而定；当期绩效管理结果岀来后，各部门应根据本单位员工的考核结果进行强制排序，与绩效管理周期相同，原则上部门内员工的目标名次应每半年排序一次，每次都分别确立优秀人员、合格人员和需改进人员3个考核等级，并分别实施相应的薪酬激励政策。
5.3 组织保障
建立科学合理的软件开发管理组织体系是建立科学的软件开发管理体系的首要任务。软件开发管理组织体系作为从管理层到基层的组织结构框架，是整个软件开发管理体系优化的基础和前提。软件开发管理组织体系要求从最高领导层到最低层员工对各级软件开发管理进行层层计划和落实，加强管理层对软件开发管理的组织领导，形成软件开发管理体系的组织保障。软件开发管理组织的设立应根据行业特点、企业规模等内容来确定，可分为专职的软件开发管理组织和兼职的软件开发管理组织。XX公司WT项目主要负责新技术的开发，员工人数较少。因此，可以通过建立兼职软件开发管理组织来满足这一需求，具体如设立软件开发管理部门，并由客户经理、项目经理、开发总监三人组成。人力资源部内部设软件开发管理经理1名，各部门均设专业软件开发管理经理1名。XX公司WT项目软件开发管理组织机构由软件开发管理部门、人力资源部部长、人力资源部软件开发管理经理、各部门专业软件开发管理经理和软件开发管理师五部分组成。总之，通过XX公司WT项目的不断改进和探索，已经形成了一个全方位、立体化、层次清晰、分工明确的软件开发管理组织体系。优化后的软件开发管理组织体系，解决了公司现有组织存在的层级不全、职责不清、组织松散、人员不足等问题。整个组织体系是垂直管理，人员充足，职责明确，为软件开发管理体系的进一步优化提供了组织保障。
5.4 信息化系统保障
XX公司软件开发流程优化技术保障的手段主要是通过XX公司WT项目软件开发管理信息化系统。XX公司WT项目通过这个系统来管理软件开发管理的各个过程，从而更加有效的完成软件开发管理。XX公司WT项目希望能全方位且多管道的满足软件开发管理需求，提供软件开发管理定制化服务，以增加员工对企业的信任度。为将大量的员工数据做充分的利用与管理，XX公司WT项目建立了软件开发管理信息化系统，其汇集了所有的软件开发管理需要的软件开发管理指标、调查数据、软件开发管理反馈数据等，以利公司内部进行分析。XX公司WT项目软件开发管理信息化系统主要由个人化网页服务、软件开发管理指标与反馈模块所组成。在公司软件开发流程优化方案中，信息化系统保障也是至关重要的一环。以下是一些保障方案：
1．信息安全保障：建立专门的信息安全保障机制，对涉及公司业务和数据的信息进行加密和保护。防止业务数据泄露、受损、遭到攻击或而导致的影响。
2．质量管理系统建设：建立完善的质量管理系统，在整个开发过程中，严格按照制定好的规范和准则进行管理，确保产品质量达标。
3．全生命周期管理：从项目前期的需求分析到最终的完成上线，全程进行完整记录和追踪，以便后期的数据统计和不断优化。
4．故障管理：针对可能出现的故障进行打包，提前设立应对策略，并在故障出现时，能够快速定位、定解决。
5．知识管理系统：实现知识的集中管理和分享，包含一些开发人员在工作中遇到的问题、解决方案等信息的汇总，以供大家参考。
6．高效通讯协作平台：打破原有的阶级和权威限制，公司应该建立简单高效的沟通渠道、开发团队，建立开放、互相信任和协作的团队文化。
总之，通过信息化系统保障，可以加强公司对软件开发流程的管理。建立完善的信息安全保障措施、质量管理体系、故障管理机制、知识管理系统等等，是推进公司软件开发流程优化的关键措施。同时，还需要注重员工相关知识储备的过程管理，建立能够支持映射业务需求和IT系统开发中需求分析/设计与评审的方法。
5.5 软件开发流程优化效果
通过优化软件开发流程，可以减少冗余工作、自动化操作、提高开发团队的协同和配合效率。优化后的软件开发流程能够提高开发效率和质量，从而可以减少开发和维护的成本。优化后的软件开发流程能够更加符合客户需求，提供更好的用户体验和交互性。通过严格遵守开发规范和质量管理流程，减少代码缺陷和产品故障，提高产品的稳定性和可靠性。通过软件开发流程的不断优化，可以使企业拥有更高的产品质量和更快的开发速度，增强企业的市场竞争能力。总之，优化公司软件开发流程可以提高软件开发效率、降低成本、保证产品质量，同时加强信息安全保护，从而使企业在市场竞争中更具有优势。通过合理运用这些优势，能够带来更多意料之外的优势，为整个企业打造出一个强大的产业生态。
WT项目成功于三个月完成，由成果来看，敏捷开发方法导入也非常地顺利。不过这是一个中小型的系统，且比较少用户操作的界面，主要是和各信息系统的介接及各种模块的建立。还包含各式 Web 系统开发规则的建立，及各种开发工具及函数库的选用决定，所以比较少验证用户及程序设计师的沟通状况。研究者观察到程序设计师间很明显地增加彼此沟通及学习的时间，产品负责人也更容易的通过每一个一周一次的功能展示，了解到项目的进度。
根据研究者实际参与团队运作的观察结果，可以梳理出下列导入敏捷开发方法解决问题根本原因的成效：
一、找出产品负责人，并利用规划游戏及用户故事让需求的执行是以企业价值为导向，较高价值的功能先行开发。此部分做法可解决软件开发人员与用户对于信息需求常忽视需求本身的价值，只关心要做出什么功能的问题。
二、推行搭档编程制度，建立互相学习成长的机制，让开发人员可以不断成长，且同时完成备份制度。亦系为共同开发系统撰写代码，所以无形中有监督的效果，提升代码质量。据研究观察，导入搭档编程过程中，遭遇到许多问题与阻碍，但经过不断地调整后，已经能依不同的人员组合排定不同比例时间的合作。开发团队也都非常肯定搭档编程确实可以提升代码质量、且认为较能落实备份。
三、执行Sprint，以短而固定的周期开发系统，并以同样地短周期给予用户可执行的系统操作展示，并接受用户的反馈。这様不仅产品负责人可以通过每个短周期交付的可执行功能来了解开发团队的开发速度及对产品的认识是否一致外，对产品负责人来说项目开发进度非常的透明可受监督，也能因此更能对项目开发工期做更精准的预估。对用户来说除了可以和开发团队频繁且良性的沟通外，也可以通过可执行的系统增进信息能力，以提出更符合企业价值的需求。若需有更进一步的修正则依沟通结果再修正产品待辨清单，以确立需求优先顺序变动。
四、建立开发团队并给予自我组织的权利，让开发团队自己承诺一个Sprint要完成多少工作，决定如何做好自己的工作，并自己决定每项工作要花多少时间，每个Sprint的系统展示成败皆由整个团队共同承担。有了承诺及权利后，开发团队就会形成团队的力量，做出最好的成果。开发团队也因为有承诺明确的交付目标，在短周期内持续不断的完成这些目标且从展示过程中知道产品负责人及用户是满意的，成就感慢慢地在开发团队萌芽。开发团队间也很明显地更常沟通，不像过去工程师都只会埋首在工作中，完全不和其他人互动及沟通。
5.6 本章小结
公司软件开发流程的优化方案必须有一个相应的保障措施来确保优化过程的有效性和长期性。针对不同的岗位需要进行不同的培训和技能提升，让员工获得必要的知识和技能，并不断激励员工持续学习和自我提升。建立完善的流程和规范，让各个环节都有具体的责任，同时制定合理可执行的计划和标准，加强行为监管和结果评估。建立完善的质量与安全保障机制，防止业务数据泄露、受损、遭到攻击或而导致的影响，并按照研发和运维规范实现生命周期管理，在故障出现时快速响应和解决。建立合理的协作机制，营造良好的工作氛围，加强员工之间的信任和沟通。同时，关注员工的心理健康，提供心理咨询和支持，避免产生过度疲劳、压力和负面情绪。总之，在软件开发过程中，优化公司软件开发流程需要有相应保障措施的配套。保障与优化同等重要，两者相辅相成，能够全面促进公司整体的生产力和市场竞争力。建立一种可持续性的保障思路和各项配套方案是必须的。
第六章总结与展望
本研究综整国内外文献探讨敏捷开发知识体的理论基础，选定XX公司进行敏捷开发方法论实践研究，通过近距离观察整个敏捷流程导入过程，从初始阶段对于各项问题的发掘及应对、研究评估、订定目标、计划导入、到发展出一个新的开发流程、以及导入流程过程中，所面临的挑战以及获取的宝贵经验。将本研究的结论与研究建议汇整如后。
6.1 总结
随着信息化进程的不断推进，软件开发在企业的重要性越来越受到关注。采用有效、高效的软件开发流程，能够提高开发效率和质量，降低开发成本，改善客户体验，增强市场竞争力。因此，对公司软件开发流程进行优化研究显得尤为重要。
1．本文首先分析了公司软件开发流程目前存在的问题，如繁琐的开发工作流、低效的开发周期、多次修改导致的代码质量下降，以及不可控的风险等。基于以上研究结果，本文综合提出了适用于公司软件开发流程优化的方案。
2．本文通过导入敏捷开发方法来优化软件开发项目流程。敏捷开发以迭代化、交互式和协同工作为核心，将产品开发过程重新切分片段，提高了整体开发效率，快速响应客户需求的变化，同时保证代码质量，降低重构成本和精细度成本。本文通过导入Scrum与XP混合方法，可以解决XX公司软件开发管理不佳、软件项目资源不足、软件项目需求不完整、缺乏用户参与及技术能力不佳等问题，达到在软件开发过程设有监督机制提升质量；建立合理的项目时间推估方式；建立更适合的沟通模式并可以保证项目质量和工期。
3．本文通过这些实践及流程确实帮助团队的形成，例如实施搭档编程且一起工作的开发团队，开始常常一起讨论以找到最好的解决方案达到系统的功能。开发团队被充分授权以开发出最好的产品的前提下，团队必须自己决定完成工作的方法及时间，开发团队开始了解许下承诺及完成承诺的重要，并依承诺交出最好的产品。产品负责人也从原本不信任开发团队到信任开发团队。通过结合WT项目案例，验证了优化方案在实践中的可行性和有效性。我们相信，通过这些优化方续推进，可以更好地促进公司软件开发流程的优化工作，增强公司的市场竞争力，提高企业运营效率，加速公司在技术上创新能力和领先性。
6.2 展望
本研究于评估XX公司导入敏捷开发方法论的研究，已初步取得成效。但由于XX公司导入项目样本数尚不足，实无法取得全面性的建议，故对后续的研究有下列的建议：
1．本研究为单一项目导入的研究，后续可以本研究作为基础，选择多个相同甚至不同企业的个案，进行比较研究，例如以不同项目且属于公司MIS部门自行开发的软件为个案，与信息委外公司加以比较，将对不同项目的开发模式的差异有更深切的认知。
2．本研究只针对软件开发项目进行探讨，未来可以将其研究范围扩大至软件维护项目。由于信息系统使用年限越久的信息系统其复杂度相对会增加许多，也会增加其维护上的困难。本研究受限XX公司刚开始导入敏捷开发方法论，建议后续研究者，可依不同的研究个案，再做长期、更深入的研究。
3．构建敏捷开发环境，强调高度合作的团队，富于弹性的组织，友善的工作环境及有效的客户关系管理。若没有经过良好的规划，例如：明确工作优先顺序、良好的沟通模式等，将可能会得到反效果。建议后续研究可针对软件开发人员人力编制较完整、信息开发主导权较高的组织导入敏捷开发，较为适切。
公司软件开发流程优化是一个持续的过程，需要不断地进一步研究和改进。当前，许多新兴领域如人工智能、云计算、物联网、区块链等技术在软件开发中到了大力推广，更需要针对不同业务场景和不断变化的市场需求来进行不断地探索和创新。因此，未来公司软件开发流程优化方面可能会从以下几个领域展开：
1．智能化软件开发：将人工智能、机器学习等技术应用于软件开发流程中，自动化代码生成和质量检测，Automation Coding and testing，提升软件开发效率和准确度。
2．数据驱动的质量控制：通过精准的数据分析，针对性地发现和解决软件开发过程中存在的问题和优化机会，运用数据科学等手段对软件质量进行全方位管，提高开发质量和效率，并且针对部分复杂情形带给治理某些新思路。
3．云原生应用的软件开发：随着云原生应用架构不断普及，公司的软件开发流程也将朝着云下化、虚拟化、标准化和自动化的方向发展。越来越多的公司采用云原生技术，将应用程序设计为微服务，以实现高度可伸缩性、弹性等优势，同时也可以更好地支持跨平台开发。
4．DevSecOps理念的应用：IT领域正在出现一种安全文化的变革，即将安全原则融入到 DevOps并秉持这种基本原则日益水涨船高。DevSecOps能够提高开发质量和安全性，加强安全意识和保障措施，能从第一线开始让所有人都有更先进的安全意识，并全程促进系统的泄漏扫描和漏洞修复过程，使信息系统具备更强的安全性和稳定性。
总之，未来公司软件开发流程优化面临着更广泛和深入的挑战，同时也充满了前景和机遇。我们相信，随着技术的不断更新迭代和不断尝试创新，公司的软件开发流程将朝着更加有效、智能、自适应、敏捷、安全和高效的方向不断发展完善，为企业业务发展持续注入新动力及保障。

参考文献
[1]Jiangming H, Ling D, Zhengyan C. Enterprise niche building business ecological competitive advantage: Comparison between Yutong and Baic[J]. Management Review, 2016,28(5):220.
[2]Royce W W. Managing the development of large software systems: concepts and techniques[J]. 1970 WESCON technical papers volume 14, Western electronic show and convention, 1970:8.
[3]Forsberg K, Mooz H. The relationship of system engineering to the project cycle[C], 1991. Wiley Online Library, 1991.
[4]Boehm B W. A Spiral Model of Software Development and Enhancement[J]. Computer, 1988,21(5):61-72.
[5]DeGrace P, Stahl L H. Wicked problems, righteous solutions[M]. Yourdon Press, 1990.
[6]Sutherland J. Business object design and implementation workshop[C], 1995.1995.
[7]Fowler M, Highsmith J. The agile manifesto[J]. Software development, 2001,9(8):28-35.
[8]高伟坤. 以用户为中心引入敏捷开发的方法探究[J]. 轻工标准与质量, 2018(6):2.
[9]Debois P. Devops: A software revolution in the making[J]. Journal of Information Technology Management, 2011,24(8):3-39.
[10]应尚军, 王炎. 项目管理的研究现状与研究前景[J]. 科技进步与对策, 2005,22(11):131-133.
[11]张恂. 敏捷方法也要“中国特色”[J]. 软件世界, 2006(10):56-57.
[12]刘博涵, 张贺, 董黎明. DevOps中国调查研究[J]. 软件学报, 2019,30(10):3206-3226.
[13]Hammer M. Reengineer Work: Don’t Automate, Obliterate[J]. Harvard Business Review, 1990,67:104-112.
[14]Davenport T H. Process innovation: reengineering work through information technology[M]. Process innovation: reengineering work through information technology, 1993.
[15]Forrest J E. Japanese/U.S. technological competitiveness and strategic alliances in the biotechnology industry[J]. R & D Management, 2010,26(2):141-154.
[16]Mcgrath M E. Setting the PACE in Product Development[J]. Estrategias de comunicación y marketing, 2012.
[17]Dong U Y, Hong E H, Choi B S, et al. Improvement Plan of Daily Work Accomplishment Index based Process Management based on Lean Construction Principles[J]. Architectural Research, 2018,20.
[18]Aw A, Saga B. KPI-Based Approach for Business Process Improvement - ScienceDirect[J]. Procedia Computer Science, 2019,164:265-270.
[19]水藏玺. 流程优化与再造[M]. 流程优化与再造, 2000.
[20]黄艾舟, 梅绍祖. 超越BPR—流程管理的管理思想研究[J]. 科学学与科学技术管理, 2002,23(12):3.
[21]张彦卿. 研发管理的流程设计与优化[J]. 上海信息化, 2006(5):3.
[22]金今. 浅谈企业业务流程优化[J]. 商业经济, 2012(17):2.
[23]鲁晓兵, 孟兆荣, 郭红锋, 等. 企业流程优化实施步骤的探讨与分析[J]. 中国管理信息化, 2017(3):2.
[24]鲁月峰. 新产品研发的流程管理优化研究——以MD公司为例[J]. 商场现代化, 2019(20):3.
[25]师旭丽, 唐定全, 郭红锋. 浅析企业如何进行流程优化[J]. 中国管理信息化, 2020,23(3):3.
[26]姜霄雪,严建平,蒋剑伟.基于CMMI的过程和产品质量保证过程研究与应用[J].广东通信技术.2017,(4).77-79.
[27]吴猛.CMMI技术在IT项目管理中的应用与研究[J].信息与电脑.2018,(22).38-39.
[28]孔晓.软件工程中的常用软件生命周期模型[J].电子技术与软件工程.2017,(14).58.
[29]刘建敏.基于CMMI的医疗器械软件开发和设计[J].信息与电脑（理论版）.2013,(11).31-32.
[30]王司洋.X公司软件项目质量管理流程优化研究[D].首都经济贸易大学.2017.
[31]王阳.基于CMMI的A公司软件项目过程管理优化研究[D].燕山大学.2017.
[32]匡麟杰.基于CMMI的腾讯IT研发流程优化研究[D].电子科技大学.2014.
[33]李彦新.基于CMMI的软件过程度量及原型系统研究[D].2020.
[34]刘原序.面向CMMI模型的软件项目开发质量管理方法研究[D].2018.
[35]潘春光.软件项目风险计划与过程控制模型研究[D].2006.
[36]Proenca, Diogo,Borbinha, Jose.Formalizing ISO/IEC 15504-5 and SEI CMMI v1.3-Enabling automatic inference of maturity and capability levels[J].Computer Standards and Interfaces…2018,60(1).13-25.
[37]Goncalves, Taisa Guidini,Oliveira, Kathia Marcal,Kolski, Christophe.Identifying HCI approaches to support CMMI-DEV for interactive system development[J].Computer Standards and Interfaces…2018,58(1).53-86.
[38]褚洪江.IT软件项目风险管理策略探究[J].中国新通信.2020,(19).
[39]孟浩,邓惠文,黄永兢.基于软件生命周期的软件缺陷预防流程研究[J].电脑编程技巧与维护.2017,(12).D
[40]李川川,王俊江.软件生命周期模型探析[J].电子质量.2017,(10).
[41]胡国栋,王琪.平台型企业：互联网思维与组织流程再造[J].河北大学学报（哲学社会科学版）.2017,(2).
[42]朱小燕,曲俊燕.浅析软件缺陷的问题[J].无线互联科技.2023,(4).
[43]周春燕.中小型软件开发管理与控制分析[J].软件导刊.2022,(10).
[44]叶勇.业务流程再造理论的全景式展示[J].西安电子科技大学学报（社会科学版）.2020,(4).
[45]刘宗斌,徐京悦,张玉郁.关于流程再造理论的缺陷分析及改进思考[J].北京交通大学学报（社会科学版）.2018,(2).
[46]丁锐.浅析软件项目管理中的需求管理[J].经营管理者.2022,(3).90,86.
[47]李江兵.L公司软件开发项目管理改进研究[J].青岛大学.2018.
[48]韩万江,姜立新. 软件工程案例教程[M].机械工业出版社,2021.
[49]康一梅著. 软件项目管理[M].清华大学出版社,2020.
[50]ir. Rob J. B. Vanwersch,Dr. Khurram Shahzad,Dr. ir. Irene Vanderfeesten,等.A Critical Evaluation and Framework of Business Process Improvement Methods[J].Business & Information Systems Engineering.2016,(1).43-53.
[51]Yijun Yu,Xin Peng,Wenyun Zhao.Analyzing evolution of variability in a software product line: From contexts and requirements to features[J].Information & Software Technology.2021,53(7).
[52]Robert C. Mahaney.The role of monitoring and shirking in information systems project management[J].International journal of project management.2020,28(1).14-25.
[53]Xiaoqing (Frank) Liu,Yan Sun.Business-oriented software process improvement based on CMMI using QFD[J].Information & Software Technology.2030,52(1).
[54]Vijay Vaishnavi,Stacie Pettera.Facilitating experience reuse among software project managers[J].Information Sciences: An International Journal.2038,178(7).
[55]Mar?al Ana Sofia C.,de Freitas Bruno Celso C.,Soares Felipe S. Furtado.Blending Scrum practices and CMMI project management process areas[J].Innovations in Systems & Software Engineering.2018,4(1).17-29.
[56]王国平.敏捷开发方法在Z公司软件项目管理中的应用研究[J].西南交通大学.2016.
[57]温晶.基于CMMI模型的X公司软件研发过程改进案例研究[J].首都经济贸易大学.2013.