1.VSTS软件开发指南目录
2.软件配置项软件配置项的源码管理
3.什么是软件配置管理
4.常见的7种软件规模估算方法 优劣势比较
5.常见的缺陷管理工具——禅道，从安装到使用手把手教会你
6.计算机软件配置项是集成什么
VSTS软件开发指南目录
引子第一篇 VSTS介绍 第1章 VSTS概述 1.1 VSTS简介 1.2 VSTS快速演示 1.3 实战演习 1.4 河曲数码的项目经理 1.5 本章讨论 第2章 白话MSF方法论 2.1 果冻的预习 2.2 MSF基本原则 2.3 MSF团队模型 2.4 MSF过程模型 2.5 MSF敏捷开发模式 2.6 MSFCMMI开发模式 2.7 本章讨论 第3章 MSF敏捷模式的工作流程 3.1 开门件事 3.2 项目管理流程 3.3 回顾 3.4 本章讨论 第4章 工作项 4.1 什么是工作项 4.2 工作项的字段 4.3 MSF敏捷方法论中的工作项 4.4 本章讨论 第5章 源代码控制 5.1 TF源码控制系统基本场景 5.2 分支，合并 5.3 标签 5.4 上架，源码下架 5.5 实战指南 5.6 TFS和VSS 5.7 本章讨论 第6章 构建工具 6.1 TF构建的集成基本概念 6.2 TBF架构 6.3 拓扑结构和安全性 6.4 构建基本流程 6.5 每日构建 6.6 本章讨论 第7章 软件测试和VSTS测试工具 7.1 基本名词解释及分类 7.2 单元测试 7.3 代码覆盖率测试 7.4 构建验证测试 7.5 验收测试 7.6 “探索式”的测试 7.7 回归测试 7.8 场景/集成/系统测试 7.9 伙伴测试 7. 效能测试 7. 压力测试 7. 内部/外部公开测试 7. 易用性测试 7. “小强”大扫荡 7. 讨论 第8章 Office集成功能、报表、源码门户网站，集成delphi 反编译源码以及其他 8.1 与Excel的源码集成 8.2 与Project的集成 8.3 报表分析 8.4 项目门户网站 8.5 从网页访问VSTS 8.6 使用TFSOM 8.7 本章讨论 第二篇 基本技术 第9章 提高个人技术 9.1 从HelloWorld开始 9.2 移山开发方法——比敏捷更精简 9.3 建立最简单的项目，WC 9.4 VSTS效能分析工具 9.5 本章讨论 第章 代码规范与代码复审 .1 代码风格规范 .2 代码设计规范 .3 代码复审 .4 本章讨论 第章 两人合作 .1 团队合作从两个人开始 .2 对工作的集成估计 .3 WBS和时间的分配 .4 单元测试 .5 好的单元测试的标准 .6 结对编程 .7 两人合作的不同阶段(舞蹈版) .8 两人的合作——如何影响对方 .9 黄金点——两人合作的项目 . 思考 . 进一步的作业 . 本章讨论 第三篇 实例分析 第章 构想阶段 .1 项目的起因 .2 收集意见 .3 团队构成 .4 领导小组——阿超的软件开发观点和管理理念 .5 团队讨论 .6 不对称的主楼 .7 用户需求分析 .8 决定项目的远景 .9 团队合作要经历的阶段 . 本章讨论 第章 计划阶段 .1 委群材，会群工 .2 项目计划 .3 创建TFS项目及设置 .4 软件项目的源码估计 .5 项目计划 .6 项目管理到底管啥 .7 移山故事：功能本天成，妙手偶得之 .8 测试计划 .9 本章讨论 第章 开发阶段 .1 典型用户 .2 从典型用户到场景 .3 场景到任务 .4 从任务到代码 .5 别人在干啥 .6 开发阶段的集成日常管理 .7 代码完成 .8 讨论 第章 稳定阶段 .1 似是而非的测试观念 .2 测试的文档 .3 测试设计说明书(TDS) .4 测试用例 .5 错误报告 .6 测试修复，关闭缺陷报告 .7 测试报告 .8 运用测试工具 .9 萝卜白菜，源码各有所爱 . 会诊 . 向ZBB进军 . 本章讨论 第章 发布阶段和之后 .1 Alpha和Beta发布 .2 执行发布计划 .3 设计变更(DCR) .4 重写或者是集成重构 .5 砍掉功能 .6 螺旋式的上升 第章 结束语 .1 事后诸葛亮会议(Postmortem) .2 大家的个人总结 附录A 参考资源 附录B 代码规范 附录C 测试计划 附录D 软件工程相关站点 附录E 事后诸葛亮会议模板 附录F VSTS新功能介绍 英文索引 中文索引扩展资料
这是一本介绍软件开发方法(MSF)和工具(VSTS)的书。《移山之道：VSTS软件开发指南》的源码内容包括：程序设计的基本原则；如何在工具的帮助下进行软件开发：如何与人合作：如何管理软件工程及微软的解决方案和方法论。软件配置项软件配置项的集成管理
软件配置项在软件开发过程中至关重要，是源码配置项识别活动的成果。CMMI（能力成熟度模型集成）对此提出要求，即需要文档化的配置项识别准则。按照准则进行配置项识别，形成配置项列表，并为每个配置项赋予唯一的编号、名称等标识信息。此外，还需标明配置项的一些关键属性，如存储位置、负责人、对应源码语言以及受控级别等。这一系列操作旨在确保配置项的清晰、准确和可追溯性，从而有效管理软件开发过程中的配置项，提升软件质量与效率。
配置项管理是软件开发流程中不可或缺的一环。通过遵循CMMI提出的准则，识别并记录软件开发过程中的关键组件与资源，如代码、设计文档、测试脚本等，确保所有配置项都能得到适当的关注与处理。配置项的编号、名称等标识信息为后续的跟踪与检索提供了便利，使团队成员能够在需要时迅速定位并访问相关资源。
此外，配置项的重要属性如存储位置、负责人、源码语言及受控级别等信息的明确标示，对于软件开发过程的组织与协调具有重要意义。存储位置信息有助于优化资源存储与访问效率，确保团队成员可以轻松访问所需资源。负责人信息则有助于明确责任归属，促进问题的及时解决与协作。源码语言的标注则便于后续开发、维护与迭代，确保代码的可读性与可维护性。受控级别的设定则有助于管理变更流程，确保软件开发活动遵循预定的规范与标准。
综上所述，软件配置项管理通过文档化准则、明确标识与属性标注等手段，有效提升软件开发过程中的组织效率与质量控制。遵循CMMI提出的准则，合理管理配置项，将为软件项目带来更高效、更高质量的开发成果。
什么是软件配置管理
软件配置管理(SCM)是指在开发过程中各阶段，管理计算机程序演变的学科，它作为软件工程的关键元素。已经成为软件开发和维护的重要组成部分。SCM提供了结构化的、有序化的、产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。
配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。
配置管理的任务
配置管理的任务如下图所示：
(1)定义配置项：软件配置项(SCI)即软件配置管理的对象。软件开发过程中产生的所有信息构成软件配置，它们是：代码(源代码、目标代码)以及数据结构(内部数据、外部数据)、文档(技术文档、管理文档、需方文档)、报告，其中每一项称为配置项，软件配置项是配置管理的基本单位。同时，开发过程中使用的环境，如操作系统、各种支撑软件、配置管理工具，也可纳入软件配置管理范围。
(2)标识配置项：正确标识软件配置项对整个管理活动非常重要，对软件开发过程中的所有软件项目赋予唯一的标识符，便于对其进行状态控制和管理。
配置标识包括：文档标识、代码标识、运行文件标识。
典型的命名规则是RUP法。
(3)定义基线：基线标志着软件开发过程一个阶段的结束，任一软件配置项，一旦形成文档并审议通过，即成为基线。基本的作用在于把各阶段的工作划分得更明确，使本来连续的工作在这些点上断开，以便检验和肯定阶段成果。
(4)定义软件配置库：软件配置库内容因涵盖开发的全过程，应包括如表所示的软件项：
表 软件开发过程与软件配置库
模型、文档库代码库运行库软件分析设计软件实现软件运行软件分析设计模型源代码可执行代码软件分析设计文档目标代码使用数据测试数据软件开发环境软件运行环境
基线技术将项目实施配置管理的存储库分为3类：开发库、受控库、产品库。
①开发库：存放在开发过程中按照要求生成的各种技术文档、源代码、可执行代码和使用的会说话指标源码数据，为开发人员的活动提供支持。
② 受控库：存放基线产品即项目转阶段经评审通过的和已经批准的软件工作产品和软件产品。
③产品库：存放项目正式交付用户的最终产品和最终运行环境。
(5)控制配置：配置控制的定义是为了明确配置管理在具体实现时所执行的配置规程，主要包括入库控制和变更控制。
(6)配置审计：包含了物理和功能上的审计。包括以下活动：① 验证每个软件配置项的正确性、一致性、完备性、有效性、可追踪性；② 在软件生存期内应定期配置审计工作；③定期进行软件备份，应保证备份介质的安全性和可用性。
(7)配置状态报告：提供软件开发过程的历史记录，内容包括配置管理项的现行状态及何时因何故发生了何事(入库、更动)。配置管理人员应定期或在需要时提交配置状态报告。配置状态报告包含了整个软件生命周期中对基线所有变更的可追踪性。
实施软件配置管理的优点
节约费用：缩短开发周期、减少施工费用
利于知识库的建立：代码对象库、业务及经验库
规范管理：量化工作量考核、规范测试、加强协调与沟通。
配置软件管理实施的流程
1.规划、调整网络开发环境
一个规划良好的开发环境，是实施配置管理系统的前提。此阶段要对配置管理系统做出规划，主要考虑以下问题：
网络的带宽、拓扑结构
服务器的选择、命名规范
存储区的定位
开发人员及组的命名规约等。
2.设计配置管理库
根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置管理库的访问性能，同时便于控制访问权限，保护软件资产。
3.定义配置管理系统的角色
需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。
一般配置管理中的角色主要包括：
项目经理
配置管理员
软件开发人员
集成人员
QA人员
4.制定配置管理流程
配置管理实施的一个重要阶段，主要目的是根据项目开发的需要，制定相应的配置管理流程，以更好地支持开发，主要活动包括：
定制并行开发策略。合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化：
发布版本管理。软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以至始至终管理、跟踪部件版本间的关联。
5.相关人员的培训
实施配置管理系统，相关人员需要接受培训：
管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容：
开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作
管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合。
软件配置管理与CMMI
能力成熟度集成模型(Capability Maturity Model Integration)是由美国卡耐基·梅隆大学的软件工程研究所(SEI)组织开发，并于年发布的一种规范、实用的途径来管理软件过程的模型．CMMI通过指导软件开发人员的活动来改进软件过程，以达到软件过程可复用性、可定量管理、可有效控制的目的．软件配置管理是CMMI可重复级的一个关键过程域(Key Process Area，KPA)，其目的是在整个项目的软件生命周期中，保持软件产品的完整性和可追踪性，这包含了对改变的控制和所有能影响到改变的软件因素的管理．作为过程实现、过程优化的一部分，配置管理是实现软件过程的基本保证，它还是基于重用的软件开发的管理手段，所以成为软件过程管理的核心．CMMI模型清晰地描述了SCM，并说明了SCM 的目的和所要达到的目标，具体描述了某级成熟度下软件过程在该方面所应达到的一组目标和实现这些目标的一组关键实践(Key Pradice)．这些关键实践被划分为5类，分别为完成该组目标所需的承诺、执行能力、执行的活动、度量分析以及验证．使企业在实施软件配置管理时能知道到底要做什么，团队的配置管理现状如何评估，在哪些方面还可以进行改进等问题能得到具体的答案。
软件配置管理案例分析
案例一：配置管理在软件企业中的应用
软件配置管理，对从事软件的人来说， 并不陌生。要想真正做到实施好配置管理，对于软件配置管理的意义及其重要性有必要进行认识和理解。软件配置管理是软件项目管理的重要内容，也是保证软件质量的重要手段。它能够对软件开发过程进行有效管理和控制， 目的是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合 它能够控制、记录、追踪对软件的修改并形成规范文档，方便日后维护和升级， 更重要的是能够保护代码资源，积累软件财富，提高软件重用率。
一、软件配置管理存在的问题
很多软件企业在日常的开发工作中遇到的问题都是因缺少规范的管理造成的。
而发生这些问题需要我们花费很大的精力与时间来处理，而且有很多是重复的问题，有的是不必要的麻烦。
1.文档和代码管理不善。
我们知道开发一项软件产品， 其代码的药理反应指标源码可重用性相当高，但如果没有良好的配置管理流程，软件复用的效率将大幅降低， 比如对于复用的代码进行了必要的修改或改进，却只能通过手工将变更传递给所有复用该软件的项目，效率之低可想而知。另外开发过程形成的文档和代码等缺乏统一管理， 随意的保存往往会因为硬件故障或人员的离职而消失， 而各个开发人员编写的代码的风格迥异， 编码和设计脱节，也往往会导致重复开发、难以维护。
2.项目的进度状况不明确
软件工程思想指出越早发现缺陷和风险，采取相应措施的代价越小。然而由于缺乏配置管理的支持，部门主管及项目经理无法确切得知各个开发人员的具体工作，项目进展随意性很大，不能适时适度管理。问题往往会集中到项目里程碑时出现，开发人员为在期限内完成任务，只能敷衍了事，容忍部分缺陷存在，给后期施工留下隐患，造成无休止的维护。
3.并行开发的手段缺乏
在开发工作中，经常会出现并行开发的情况，并行开发能够有效提高开发效率。例如：一个项目可能在开发新版本的同时维护前一版本，或者需要针对不同客户进行定制修改。但并行开发在分支及合并时往往会衍生出很多麻烦，如果没有配置管理工具的支持，进行并行开发将十分困难，往往会造成修改过的bug 重复出现或者若干人进行相同的工作， 产生不必要的浪费，这样也会对开发的管理及代码的质量带来影响。
4.测试工作开展的不规范
国内很多企业已经认识到配置管理和软件测试的重要性，缺乏合理管理的软件测试只是形式主义。传统开发模式的弊端使得测试工作无法起到测试应有的作用，测试结果无法量化更无法考核。开发人员将精力耗费在如何应付测试，而测试人员单凳主观意愿进行测试， 走走过场，使得这一环节形同虚设， 当然就无法对以后的开发工作起指导作用。
二、软件配置管理在企业中的应用
我国目前的软件行业主要还是由中小型团队组成，相对应国家水平存在着严重的开发过程混乱，缺乏有效的过程管理手段，而软件配置管理是一套规范、高效的软件开发管理方法，同时也是提高软件质量的重要手段。配置管理由于其本身实施的便利性、工具的支持性以及与其他过程域良好的连接性，正符合企业的管理需求。软件配置管理可以帮助开发团队对软件开发过程进行有效的变更控制，高效地开发高质量的软件，从而达到提高软件生产质量这一根本任务，它有机地把其他支持活动结合起来， 形成一个整体， 相互促进，相互影响，配置管理为了实现控制变更， 高效、有序的存放、查找和利用软件开发信息， 为达到这一目的， 首先我们需要完成以下几个主要功能域：配置标识、版本控制、变更管理、配置审核和状态报告。下面本文就其中3个功能域进行阐述：
1.配置标识
软件配置标识就是对每个软件配置项的标识。 对一个软件项目而言，它的配置项有以下内容：需求分析文档、概要设计文档、详细设计文档、源代码、测试文档、客户文档等。
而对这么多需要存储的重要的文档和代码，软件配置管理工作的第一步就是建立一个安全、可靠的知识库，用于保存开发过程中产生的软件资产。在建好知识库后，首先要明确项目生命周期内所产生的各类文档和代码，然后确定其名称和标识规则。根据实际需要，将正式文档、模型文件、源代码等文件按照各自标识规则分门别类放入库中， 而对于临时文档、编译时产生的中间文件等，则不需将它们放入库中。原则是保证配置管理工具检索便利，让项目组成员容易记住标识规则， 同时要确保组织一级的标识规则的一致性。
2.变更管理
在软件配置管理中， 由于软件的可变性，变更管理成为一个难点，并且变更涉及的范围很广，各种因素都会引起变更，如市场的变化、技术的进步、客户对于项目认识的深入等等，都可能导致软件开发过程中变更的提出。如果缺乏对于变更的有效的管理能力，纷至沓来的变更就会成为开发团队的困扰。
实施高效的变更管理至少应该包括两个部分：“定义合理的变更管理流程”、“采用自动化工具作为支持”。在具体的实践中，变更管理的复杂程度与变更的具体类型有关。应该对变更进行分类和分层，既保证项目组成员有一定的自主权，又不会耽误高层经理对关键问题的卖点主图源码把握。通常变更管理的流程会涉及到变更提交、变更复审、变更任务分配、变更结果验证等一系列活动。
3.配置审核
配置审核包括配置管理活动审核和基线审核。配置管理活动审核用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，实施基线审核，要保证基线化软件工作产品的完整性和一致性， 并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项?基线库中配置项自身的内容是否完整? 此外， 对于代码，要根据代码清单检查是否所有源文件都已存在于基线库。同时，还要编译所有的源文件， 检查是否可产生最终产品 一致性主要考察需求与设计以及设计与代码的一致关系， 尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。在实际操作过程中，一般认为审核是一种事后活动， 很容易被忽视。但是“事后”也是有相对性的，在项目初期审核发现的问题，对项目后期工作总是有指导和参考价值的。
软件配置管理活动在整个开发活动中是一项支持性、保障性的工作，实施之前还应该对所有开发人员进行软件配置管理方面的培训。通过软件配置管理的实施，除了可以给企业带来效益， 还会对使用配置管理的每个人有所收益： 学习先进的软件过程管理思想，培养良好的团队合作精神，提高个人专业水平，增强自身的竞争力等。
常见的7种软件规模估算方法 优劣势比较
业内主要软件规模估算方法包括LOC、故事点估算法、FPA、COSMIC、快速功能点估算法、IFPUG和自动化功能点估算法。
LOC方法通过统计源代码总行数估算规模。其优点是简单，缺点在于无法跨语言统一估算，不同语言的相同行数代码代表的工作量不同。
故事点估算法是敏捷开发中常用方法，用于衡量用户故事大小、复杂度和数量。其优势在于速度较快，但在跨项目估算时准确性存在一定波动。
FPA方法通过评估输入、输出、查询、接口和数据存储来计算功能点，其优势在于估算较为完整和准确，但过程较为复杂，耗时较长。
COSMIC方法侧重数据移动评估，适用于多层次软件系统，其优势在于专为现代软件系统设计，但需要额外关注特定方面。
快速功能点估算法（QFPA）由国家标准定义，准确度较高，但复杂性较高，需要经过培训，学习成本较大。
IFPUG方法是国际功能点用户组织定义的通用计算方法，应用范围广泛。
自动化功能点估算法基于AI和自然语言处理，旨在解决专业人员短缺、效率低下和准确性不足问题，随着AI发展，将成为主流估算方法。
CoCode需求分析工具是国内首款自动化软件规模估算工具，基于AI的NLP算法，能自动识别功能点、实现内部和外部逻辑文件，自动估算项目规模、工作量和产品报价。使用数据显示，工具实现了倍的生产率提升，原本两周的工作现在仅需两小时完成。工具现已升级为软件成本造价工具，提供免费试用版本。
CoCode还发布包括智能项目管理、需求分析、评审分析和故事点估算在内的四大开发工具，提供从项目管理到成本估算的全面支持。项目管理平台提供4个版本，支持天免费试用。CMMI落地工具已上线，全面支持CMMI3-5级高效落地。
常见的缺陷管理工具——禅道，从安装到使用手把手教会你
在众多开源项目管理工具中，禅道以其独特的功能与便利性，逐渐成为了众多团队首选的缺陷管理工具之一。禅道，其前身是Bugfree，后因团队发展方向不同，分道扬镳，禅道应运而生。作为一款国产开源项目管理软件，禅道专注于项目管理，集需求管理、任务管理、Bug管理、缺陷管理、用例管理、计划发布等功能于一体，实现了软件完整生命周期的管理。
禅道完整支持敏捷、瀑布、鲨鱼上岸指标源码看板项目模型，以及CMMI标准的落地实施，能够帮助团队细致划分需求、任务、缺陷与用例，全面覆盖研发项目的核心流程，实现软件生命周期的高效管理。其基于ZPL协议发布，源代码开放，且拥有丰富的插件生态，为用户提供高度自定义的使用体验。
安装禅道的过程简洁明了。首先，访问禅道官网下载开源版本，这里以.4版本为例。根据自身需求选择合适的安装包，本文以Windows一键安装包为例，便于操作。解压安装包至根目录，确保xampp集成环境（包含MySQL、php、Apache）可以正常运行。启动xampp集成环境，系统会自动加载禅道集成环境，显示php、Apache、MySQL、禅道版本信息。启用Apache用户访问验证，增加访问安全性，若选择不启用，则所有用户可直接访问登录页面。
配置访问验证账号，自由设定用户名与密码。若需复制密码，可点击“复制密码”按钮，方便后续使用。登录禅道项目管理系统，通过“访问禅道”功能，输入禅道地址，即http://.0.0.1/index.php，跳转至登录界面。默认用户名与密码为“admin/”，完成登录后，可自行修改密码。在系统右上角导航栏中找到A图标，点击打开修改密码页面，便于安全设置。
登录系统后，可通过左侧菜单找到“后台”选项，进一步调整安全设置。访问禅道数据库页面，输入数据库用户名与密码。根据my.php配置文件获取数据库配置信息，包括数据库名与密码。将这些信息填入禅道数据库访问页面，即可登录数据库，查看数据表信息。禅道以其丰富的功能与简易的操作流程，为团队提供了一站式项目管理解决方案，帮助提高团队协作效率，确保项目顺利进行。
计算机软件配置项是什么
1、软件配置项（SCI）：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。
2、软件配置项包括：
（1）与合同、过程、计划和产品有关的文档和资料；
（2）源代码、目标代码和可执行代码；
（3）相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。
3、软件配置项是作为配置项识别活动的产出物，CMMI中要求有文档化的配置项识别准则，根据准则来进行配置项识别，列出配置项列表，给与配置项的编号、名称等，并标明配置项的一些重要属，如：它的存储位置、它的负责人、对应源码语言、受控级别等。
浅谈软件研发管理体系建设
最近一段时间，我一直在反复思考一个问题：我们的软件研发管理体系应该是怎样的？在不断思考的过程中，逐步有一些粗浅的认识，在此将这些认识记录成文字，并期待能够与更多的伙伴碰撞，进一步完善这种认识，并逐步上升到理论高度，从而有利于指导具体实践。1. 对软件研发管理体系的一些概念认知
1.1. 研发管理是什么
关于研发管理，百度百科中这样定义：研发管理就是在研发体系结构设计和各种管理理论基础之上，借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。
也就是说，研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构，之后按照这种研发体系结构组件一支高水平的研发团队，设计高效合理的研发流程，借助合适的研发信息平台支持研发团队高效工作，以绩效管理调动研发团队的积极性，以风险管理控制研发风险，以成本管理使研发在成本预算范围内完成研发工作，以项目管理确保研发项目的顺利进行，而知识管理使得研发团队的智慧联网和知识沉淀。
纵观各类软件企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分，最终追求的目标都是能否适合企业的发展，给企业带来市场和财务上的成功。
1.2. 基于CMMI的研发管理
CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则，实际上，大部分企业尤其是国内企业并不会严格按照这个模型去做，因为如果每一个过程域都不打折扣地执行地话，需要非常标准化的流程和强大的资源支撑，在这个讲究快速响应变化的时代其实是很难做到的，通常这个时候都会进行相应的裁剪，甚至会结合敏捷迭代等方面的模式，从而逐步形成自己公司的研发管理体系。
1.3. 基于敏捷模式的研发管理
在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外，还有相应的成熟工具做支撑。例如，腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分，实现对需求的有效管控和分解，从而确保持续迭代上线。
敏捷研发管理在当前我们以业务为导向、项目为主的情况下，要全面实施尚有较大困难，当然并非是完全不能做，主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。
1.4. 基于IPD的研发管理
之前有简单了解过IPD产品研发管理体系，我认为其中的核心就是“四四四”模型，四四四代表了四大团队、四个流程、四个支撑体系。
四大团队建设包括建立集成产品管理团队（IPMT）、建立产品市场团队（PMT）、建立产品开发团队（PDT）、建立技术开发团队（TDT）。
四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。
四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。
个人感觉，基于IPD的产品研发管理从整体上来看是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动。
IPD的理念和敏捷开发理念在本质上是基本一致的，比如以市场需求（用户价值）为核心，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。
从理论上来讲，IPD研发管理体系是一个较全面的体系，在当前我们的现状下也可能容易出现水土不服的情形，当然其中有一些好的做法是值得借鉴的。
2. 什么样的软件研发管理体系适合我们的发展
从项目及产品的研发角度来看，发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式，由于项目的特点及人员的组织结构等因素，项目开发及产品研发的周期往往较长，较难适应市场快速变化的需要，也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂，推行了敏捷研发模式，或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。
那么，针对当前我们所面临的一系列问题，究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展？我们需要重构我们的软件研发管理体系吗？我们有必要重构我们的软件研发管理体系吗？带着这些问题，我想主要思考几个方面的问题。
2.1. 能否快速适应未来业务的发展变化
技术是为业务发展而服务的，因此在考虑软件研发管理体系构建时，第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下，信息化能力是越来越多客户的第一选择，因此在业务的快速发展方面需要更加强有力的技术支撑，而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系，特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。
2.2. 在业务出现较大波动时能否弹性伸缩
另外一个问题就是，业务在发展过程中，受大环境等诸多因素的影响，定然很难一直都是呈现直线上升的发展趋势，这当中必然会有波峰波谷，只不过这个波峰波谷是大是小的问题。而我们面临的问题则是，当出现较大的波峰波谷的时候，我们的研发管理体系应该如何适应？特别是在软件业务处于相对低谷时，既能够继续保持对技术研发的持续投入，又能够在应用开发等方面有一定的可伸缩性，从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下，不同业务单元的发展会有不同的发展路径，对软件研发能力的诉求也有所不同，那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。
对于基础研发能力，个人认为应该是一个软件公司最内在的核心技术能力，往往很多时候基础研发工作很难像做行业应用开发那样立竿见影，但这项工作干得不好往往又容易成为行业研发能力的掣肘，这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。
对于行业研发能力，个人认为应该要从两个方面去考虑，一个是产品化的能力，其二才是应用开发能力。应用开发能力很好理解，就是目前我们这么多年以来一直在做的各种类型的项目开发，而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容，不过这条路上我们尚开始起步，还有很长的路要走，也还有不少坑要踩。个人认为，产品化的能力能否真正发展起来，其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发，应用开发更多是定制化的开发，是客户导向的软件开发，通常面向的是一个或少数几个的客户；而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发，是市场导向的软件开发，面向的是一个或多个的客户群体，甚至面向的是一个市场或跨界市场。
2.3. 新技术研发及成果转化能否跟上业务变化
最近几年，新技术层出不穷，在软件架构的发展方面也非常迅猛，历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看，我们有少量的项目/系统采用了SOA架构，然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看，我们在技术领域的持续跟进及成果转化方面已然有落后趋势，这方面需要我们奋起直追才行。当然，出现如今这种局面固然由众多因素催生而成。比如，已有开发框架前端兼容性的问题最近一两年以来常常被诟病，诚然有它内在的好处，然则最近一两年以来，用户对系统的用户体验要求更高了，不再是单纯地满足于功能实现层面，而是开始追求良好的人机交互和界面展现。因此，这方面势必对新技术的要求更加迫切。最近几年，当不少团队都在往前后端分离走的时候，我们至今的绝大部分软件项目开发仍然停留在前后端分离之前，对不少用户界面展现要求高的软件项目而言，难以快速有效响应变化，同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。
因此，能否在新技术的研发上抓住正确的方向并加快研发成果转化，为业务的快速变化提供强有力的技术支撑，是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看，研发架构方面，我们虽说不能完全抛弃传统的单体/垂直架构，但我们必须要往微服务架构方向迈进，除了与最新技术接轨之外，更重要的是如何进行业务解耦，沉淀行业积累，并反向推动人员组织层次的变革，提升软件生产效率，提高软件质量。
除此之外，对于人工智能、区块链等新领域，也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。
2.4. 在标准化和敏捷迭代之间如何平衡
标准化的软件研发道路固然有不少好处，有严谨的流程、规范的体系、固定的套路，当然更多的则是瀑布开发模式，虽然最近几年也陆续有迭代开发的模式，但更多的是被动式响应，而且这种迭代开发模式基本上是大阶段的划分，在每一个大阶段里面依旧是一个典型的瀑布开发模式，即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤，横跨周期往往较长，一旦发生需求变更，变动的代价过高。
敏捷开发强调以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
那么，问题来了，既然标准化项目管理模式下存在太多流水线作业及效率低下等问题，那么我们能够直接转向敏捷迭代模式呢？世界上万事万物都是对立统一的，个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面，在现有的以项目为主导的软件开发体系中，标准化模式是我们一直以来的主要做法，也积累了不少经验做法；另一方面，采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪，既能提高软件质量和软件开发效率，也能够保留一定的规范性和软件过程文档。例如，针对项目管理，通常是五个过程组：启动、规划、执行、监控、收尾，那么我们其实可以结合实际将规划提前，将监控贯穿于执行过程，这样就势必要求在启动时也要做好项目计划相关工作，在执行过程中抓住关注点并定期监控其执行情况，在收尾阶段做好项目回顾总结。
不论采用何种模式，我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
因此，我们的软件研发管理体系中是否应该引入DevOps，进而改善公司组织文化、提高员工的参与感、提高交付效率，我想这也是需要重点关注和考虑的。
2.5. 组织过程资产能否持续积累并盘活
组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标，项目组织在实践中形成自己独特的过程资产，构成组织的核心竞争力。
组织过程资产主要包括但不限于以下内容：项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训，其中既包括已经形成文字的档案，也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档，包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。
经过多年的软件开发，我们做了大大小小形形色色的软件项目和产品，也逐渐积累了一些行业化的软件项目，但总的来看，能够形成规模化效应的软件产品尚较为匮乏，更多的是以定制化开发为主的软件系统，当然也积累了不少项目经验。在这过程中，也积累了不少标准、规范、流程、模板等各类软件过程资源。然而，从目前掌握的情况来看，这些资源是分散的，不够体系化的，还谈不上真正意义上的资产，至少在价值的发挥上还不充分。况且，软件行业这几年的人才流动率明显加快，人员更替的速度以及未能体系化的过程资产积累，加剧了组织过程资产的盘活难度。
那么，构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分，也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中，其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产，这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”，是一项涉及知识库、过程资产、环境和交流等元素的整合过程，所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言，我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。
3. 构建我们的软件研发管理体系应包含哪些内容
软件研发管理体系的建设离不开几个关键要素：人员、技术、过程、资源，并在此基础上配以相应的管理手段。进一步来看，要构建适合我们自身发展的软件研发管理体系，需要着重考虑几个能力体系的建设，即：人员组织能力、技术研发能力、过程管理能力和资源建设能力。
前面也有针对“什么样的软件研发管理体系适合我们的发展”进行了一些相对粗浅的探讨，那么在考虑如何构建适合我们发展的软件研发管理体系之前，我想这里首先要明确一下我们期待构建的软件研发管理体系。我们公司的业务涉及众多行业客户，一直以来主要以定制化项目开发为主，同时也涉及运维服务，而在产品研发等方面则处于起步阶段，且在一段时期内项目、产品、服务将会长期并存，因此，个人认为适合我们的软件研发管理体系应该至少经历三个阶段，包括初期的标准化软件研发管理体系、中期的标准化与敏捷相结合的软件研发管理体系和后期的敏捷化软件研发管理体系。
基于上述这样的考虑，正常来讲我们当前应该在标准化的软件研发管理体系中要做进一步强化，而考虑到市场的快速变化、技术的日益进步，个人认为我们当前就需要开始考虑标准化的与敏捷相结合的软件研发管理体系。为什么还需要考虑标准化的软件研发管理体系呢？主要是传统的定制化的软件项目开发依旧占据主体，且目前在这方面仍然有非常大的改进提升空间，然而标准化的模式常常是过于强调标准、规范、流程，开发模式过于线性化，因此需要引入敏捷开发模式。所以，我们又需要考虑敏捷的软件研发管理体系，这主要是为了更好地适应市场变化、更快速地响应客户需求，更好地提升软件开发生产效率。
3.1. 人员组织能力
关于人员组织能力，个人认为有两个关注点：一是团队的发展，二是个体的发展。这两者是相辅相成、互相融合促进的。综合来看，人员组织能力的建设主要包括设立与公司战略、业务、技术发展相适应的组织架构，并配以构建相对完整可行的岗位体系和对应的人员考核体系，同时在团队建设等方面持续改进与提升。
关于组织架构，当前的组织架构虽然解决了一些曾经的主要矛盾，但依然存在不少问题，突出的一点就是核心薄弱，即核心技术能力不强，仍旧需要投入大量的人力到各行业的应用开发中，当然这与我们一直以来承接定制化的软件项目开发不无关系。这是当前乃至未来一定时期需要解决的。
同时，最近几年来的组织架构主要是以职能型组织架构为主，产品线为主导的研发模式尚不成熟，针对项目及产品的团队构建主要是以项目经理来驱动，在项目团队的组成方面固然与互联网的项目团队截然不同。在团队建设方面，需要进一步打通团队之间的壁垒，强化团队的整体协同作战能力。
在岗位体系方面，特别是对人员的绩效评价方面，需要在已有的岗位体系基础上进一步考虑如何更好地执行落地，确保个人绩效目标与团队绩效目标的一致性和顺利达成。
3.2. 技术研发能力
结合我们的实际，我认为在技术研发能力方面要考虑四个方面：一是技术预研，二是技术开发，三是产品开发，四是定制开发。
关于技术预研，通俗来讲就是：预研=预先+研究。这种预先研究通常来源于几个方面，例如来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等。为什么要做技术预研呢？这是扫清前行障碍的过程，这为后续展开总体设计、详细设计指明了方向，也是持续积累公司技术能力、保持与新技术同步而不至于脱离轨道的方式之一。
关于技术开发，其实这里主要指与基础平台、公共组件、关键技术等方面的技术研发。另外一个方面来理解，技术开发是技术预研的延续，是在技术预研成果经论证的基础上开展的一系列能促进公司发展、业务发展、技术发展而开展的技术研发工作。
软件产品是指向用户提供的计算机软件、信息系统、套装软件或在提供计算机信息系统集成、应用服务等技术服务时提供的软件，是通用的产品应用于某一行业领域而不是像软件项目一样为某一需求或者单位定制开发。
软件项目主要为特定企业开发或者部署实施一套专用的系统，在进入项目开发之前需要与用户进行具体的交流和讨论，了解用户心中对于软件预期的样子，后经过招投标，签订合同，实施交付。
关于产品开发，这方面我们尚处于起步阶段，尚缺乏一套完整可行的产品研发流程及最佳实践，需要摸着石头过河，也需要长期坚持不懈地努力。
关于定制开发，当前主要是基于客户需求的软件项目定制开发，后续还会包括基于产品衍生出来的定制化开发。前面的这种方式是我们当前最熟悉的模式，主要面临的困境是两个：一是如何实现快速交付，二是如何实现成本可控，从而提升软件项目的利润。
做项目侧重于在最短的时间内，按照客户的需求开发出操作敏捷，用户体验良好的软件。而做产品则侧重于市场驱动，时间相对充足，但要开发出有竞争力，有自身特色，且受客户欢迎的产品，要求功能响应速度快，操作简单，界面美观。
技术预研+技术开发是强化内核的内在需要，定制开发是现阶段的生存根本，产品开发则是为未来发展铺路。
3.3. 过程管理能力
过程管理能力主要包括项目管理、开发管理、质量管理和配置管理等几个方面，需要一套完整合理的流程贯穿整个过程。
在项目管理方面，我们需要梳理当前项目管理体系的标准、规范、流程及相关实践，建立以过程为核心、以度量为基础、以人为本的可裁剪、受认可、能执行的信息集成项目管理体系，进一步规范公司的项目管理，提升项目群管理能力。结合项目管理的五大过程组（启动、计划、执行、监控、收尾），并结合敏捷迭代的思想，形成标准化项目管理与敏捷迭代相结合的具有实际指导意义的方法体系，同时将这套方法体系以指南性文件、规范性文件等形式传导到相关人员，确保可落地执行。此外，为加强过程管控、资源共享、工作协同，组建PMO团队，实现对项目群及重大项目的统一管控与决策支持。
在开发管理方面，一是要落实统一的软件开发规范，包括架构规范、设计规范、UI规范、编码规范、测试规范等。强化设计及开发关键环节的评审，包括对需求、概要设计、详细设计、UI设计等的设计方面的评审，对测试用例等方面的评审，对代码的评审检查（例如利用SonarQube进行代码的自动检查等）及发布评审等。同时通过试点+逐步铺开的方式着力推进CI/CD的落地。
在质量管理方面，进一步强化项目质量审计，逐步改进软件过程生产效能。而在配置方面，则加强对配置项的识别、配置空间的管理、变更控制等，规范软件开发过程，确保构建正确的系统。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。
综合来讲，在过程管理方面就是要形成一套适用的软件研发管理流程，并配以相应的节点管控，让不同开发角色之间即各司其职又相互融合促进，从而促进软件开发自组织能力的逐步提升，充分调动软件开发人员的主动性和积极性。
3.4. 资源建设能力
简单来讲，资源建设是软件研发管理体系中的支撑体系。资源建设主要包括了一系列的制度规范、工具、模板、过程资料及交付物（例如项目文档、源代码等），以及相应的经验、知识沉淀等。一是要适时梳理相应的制度、规程、标准、规范、文档模板等，形成标准化资源库；二是要对不同行业历年来的项目资料及源代码分门别类做好规划和归档管理，形成静态库（归档库）和活跃库，同时做好数据安全管理；三是要对软件研发人员及工作中的一些隐性知识转化为显性知识，并逐步构建软件研发的知识图谱，促进知识经验的持续积累与转化，并通过链条式、网状式等方式实现知识分享与传播，形成经验知识库。
