Devops运营体系管理平台应答方案建议书.docx

1. 项目背景
目前信息化工作的日常开展主要依托OA系统、ITSM系统、JIRA系统等进行，虽能在一定程度上满足日常办公及条线工作管理的需要，但是普遍存在管理流程割裂、数据信息不一致的情况，同时仍有大量工作的开展依托手工台账方式进行，信息技术相关管理制度、规范指引也无法得到系统的有效支持，对IT条线进一步释放生产力、提高工作效率造成了严重制约!为了填补信息化日常管理场景在信息系统支持方面的空白，打通IT条线相关管理场景和作业流程，迫切需要建设一个流程化、标准化、智能化的IT作业管理平台，以充分满足IT条线的工作需要。
由于项目开发产品的复杂、技术架构的多样、人力资源的储备等问题，在工作中往往不能达到合理协同。环节衔接依靠手工、任务资源分配不合理、关联任务依赖关系无法清晰展示、风险区不能及早识别、问题不能溯源定位、自动化程度低等，这些都严重阻碍了研发项目在开发产品过程中的工作效率和软件质量，同时引发了一系列过程控制风险问题。
因此需要一款简单易用、功能强大、项目组成员愿意使用的研发项目控制管理平台软件来满足研发项目产品开发的项目管理、产品开发需求。

2. 项目主要建设内容
l 实现项目启动-需求-设计-编码-测试-发布与变更的全生命周期项目管理。
l 支持层次化的组织结构管理
l 组织结构、角色和人员配置
l 提供灵活的参数化设置 。
l 通过工作流引擎，可以方便灵活的自定义工作流程。
l 系统支持开放式设计，能够提供方便灵活的与外系统集成的能力，可以实现与第三方系统的对接。
l 具备安全的资源信息保护体系 。
l 灵活全面的项目配置管理 、缺陷管理、需求管理功能。
l 方便灵活的二次开发能力。
l 实现项目的透明化管理，定制各类统计报表为项目管理者提供多维度的数据展现，实时掌控项目进展与绩效。
l 实现项目全面信息的整合和闭环控制，包括项目进度、工时、工作量、质量、资源、偏差分析、项目变更控制等。
l 对IT工作流程所涉及的各方面数据标准，包括IT预算、项目、需求、运维等进行统一，建立IT工作信息的标准化数据基础；
l 将信息化相关的管理制度、规范通过系统管控的方式进行固化落实, 确保IT工作实务流程和规章制度的一致性；
l 将IT工作流程及配套制度规范相关的风险管控点、信息安全管控点通过系统方式进行固化落实，确保全方位、无死角的覆盖；
l 对IT工作的质量效能监督检查进行系统化支持，提高检查的效率、准确性和针对性；
l 通过工作流程的打通、信息数据的共享，实现对信息化建设工作的多维度、透视化管理，满足各层级管理需要。

3. 项目建设原则及目标
3.1. 项目建设原则
l 实现项目启动-需求-设计-编码-测试-发布与变更的全生命周期项目管理。
l 支持层次化的组织结构管理
l 组织结构、角色和人员配置
l 提供灵活的参数化设置 。
l 通过工作流引擎，可以方便灵活的自定义工作流程。
l 系统支持开放式设计，能够提供方便灵活的与外系统集成的能力，可以实现与第三方系统的对接。
l 具备安全的资源信息保护体系 。
l 灵活全面的项目配置管理 、缺陷管理、需求管理功能。
l 方便灵活的二次开发能力。
l 实现项目的透明化管理，定制各类统计报表为项目管理者提供多维度的数据展现，实时掌控项目进展与绩效。
l 实现项目全面信息的整合和闭环控制，包括项目进度、工时、工作量、质量、资源、偏差分析、项目变更控制等。

3.2. 建设目标
为提高IT项目管理水平，实现IT管理及相关日常管理工作的数据化、流程化、标准化和自动化管理，减少技术、管理人员工作负担，提高工作效率，特启动本系统采购与定制化工作，该系统将作为公司IT部工作平台，能够作为一个企业级多项目管控平台与信息共享平台，实现项目过程规范化、精细化管理，满足企业中长期发展要求。
该系统需要具备IT全过程管理能力，能够将部门管理、项目管理、质量管理、研发管理和个人工作融入到一个集成的工作平台，将知识和成果沉淀下来，将制度和管理体系固化下来，将技术管理人员的工作明确和展示出来，将各个业务、产品管理条线串接起来。系统要能减少多头管理负担，形成领导、产品条线、部门、项目和个人的综合管控视图，减少开发、测试等一线人员、质量人员、项目经理的事务性工作。系统还需要为部门、项目和个人的量化考核提供全方位数据和能力支持。
系统要支持项目在线管理，支持按阶段管理项目任务，实现对项目全生命周期管理。对工作任务、计划节点、工作总结、存在问题等内容的在线管理、图表展现和统计分析，支持公司领导、部门领导、PMO、质量负责人、项目负责人和项目组成员间的多层次信息沟通和资源共享，支撑项目过程管理节点、周工作、月总结、大事记等工作信息共享。能够跟踪全部项目关键节点进展情况，查看项目阶段成果、评审/审批意见和问题及处理情况，可减少各类报表，为各类项目IT流程提供引导，减少各类事务性工作，项目组能够随时查看和处置项目组内部交流情况和上级审批情况，可自动生成各类质量记录报表，支持人员在岗、加班、休假和请销假情况的登记、审批、查看、统计、分析和输出功能。
系统最终要集项目管理、开发管理、沟通协作、质量管理、部门管理、知识平台、绩效管理于一身，做到理念先进、功能完备、易学易用、稳定可靠、安全保密，成为公司IT管理工作的基础软设施。
本期DevOps运营体系建设项目是以数据和质量为核心，以电子化为手段。解决传统瀑布开发模式中各个环节相对割裂，从需求、研发、测试到生产运营整个周期相对较长，跨部门间的沟通效率低下，难以满足当前的业务需求。为突破瓶颈并改善现状，现以敏捷开发为出发点，按照DevOps的理念，进行合作外包管理系统落地、敏捷开发管理（含电子看板）建设、DevOps工具链建设。
建立合作外包管理平台，统一承载业务支撑网业务外包领域涉及到的各项能力，实现合作伙伴信息、合同信息、需求工单、工作量信息、考核结果等各个纬度信息的可追溯、可关联、可共享，并通过统一视图可从全视角纵览外包管理的整个生命周期。
建立需求敏捷开发流程管理系统（含电子看板），实现高效严谨的需求敏捷开发流程管理，解决研发过程中的责任不清、进度不明、信息不畅等诸多弊病。电子看板能满足开发团队进行细化需求管理、敏捷开发管理、Bug 追踪管理、代码共享与连接、版本发布管理、部署与运维管理、研发日报/周报、工作效率评估和追踪。从而实现研发流程管理到工作效率评估全流程管理。
建立DevOps敏捷工具链平台，在构建、部署、测试、交付等开发过程中，自动化一切值得自动化的过程。在建设开发、测试和发布自动化流水线过程中，通过流水线整合、改造一系列工具链，实现端到端整体能力的打通，实现交付能力的全面提升，保证软件产品的交付的质量和效率。最终保证快速实现业务需求，通过自动化流水线快速实现发布上线，保证业务可靠、高效运行。

4. 需求分析
(1) 工作流引擎
系统应提供可灵活定制、可视化编辑、可靠性高、可监控的强大的工作流引擎，能够对上述各管理域提供必要的、充分的流程支持。
具体应支持但不限于如下特性：
• 支持单一审核、多人顺序、多人并行、多人抢占四种办理方式；
• 支持条件流；
• 支持子流程；
• 支持多路并发与归并；
• 支持异步提交；
• 支持协办功能；
• 支持知会功能；
• 支持驳回、撤回、转办、催办、交办、撤转、加签、减签、会签、传阅等各种常用操作；
• 支持催办功能、并可根据办理时限等条件设定自动催办；
• 支持待办人员按照预设规则、条件进行自动计算；
• 可以对表单、表单字段的访问权限进行精确设置；
• 支持进入、离开节点事件；
• 支持自动办理节点；
• 支持动态流程；
• 支持流程合并；
• 支持暂停、恢复功能；
• 支持手工强制结束流程；
• 支持替换节点办理人员；
• 支持办理节点跳转；
• 支持办理节点驳回；
• 支持流程实例与流程修改的更新同步。
(2) 表单引擎
系统应提供可灵活定制、可视化编辑、所见即所得、可靠性高的表单引擎。具体应支持但不限于如下特性：
• 支持各种常见表单控件，并可维护自定义控件，实现表单的即时配置、生成；
• 能够将生成的表单数据与工作流引擎生成的工作流实例有机集成，并可根据表单要素设置各类条件、策略、规则、表达式等驱动工作流运转，实现流程各个环节业务的应用；
• 能支持与用户和组织管理、权限管理等的有机整合，实现统一的配置维护管理能力。
(3) 智能搜索引擎
系统应提供基于权限的、支持全文检索方式的、高效率的智能搜索引擎，让用户可以在IT作业管理平台直接查询到有权限查看的所有数据，包括结构化数据以及各种非结构化文档数据。
注：如能引入大数据相关技术更佳。
(4) 数据交换引擎
l 系统内数据交换
主要指通过设定数据报送任务及模板，可组织进行批量格式数据的报送及汇总整理。
l 系统间数据交换
主要指支持IT作业管理平台通过数据平台和各周边系统进行批量数据交换。
(5) 作业调度引擎
l 对于IT作业管理平台需要进行的作业(如定时任务、跑批处理等)进行统一调度管理，对于作业执行异常的情况，可以通过短信、邮件等方式及时提供告警。
(6) 接口管理引擎
l 对于IT作业管理平台提供的接口的状态进行管理及运行情况的记录(包括但不限于被调用次数、调用成功情况、响应时长等)，支持进行在线重启；
l 对于IT作业管理平台调用的其他系统的接口的状态进行管理，并可记录调用次数、响应时长等；
l 对于接口状态异常的情况，可以通过短信、邮件等方式及时提供告警。
(7) 工作台
l 工作台为提供用户使用的工作界面，支持工作台面板的个性化配置，根据权限可设置相关功能模块。
1、 系统管理功能
IT作业管理平台应能提供丰富强大的系统管理功能，包括但不限于：
l 用户管理
l 角色管理
l 基于组织的、角色的、岗位的、业务关系等多种方式的权限管理（含菜单、数据、功能、流程等）
l 工作流程管理
l 业务单据管理
l 基础数据管理
l 日志管理、审计
l 系统运行监控
l 查询、统计功能

2、 IT作业管理平台移动版本
在IT作业管理平台运转成熟后，着手搭建该平台的移动版本，可支持手机、PAD等智能终端设备使用方式。用户可通过移动版随时登录查看和处理各项任务。
移动终端门户应基于当前主流成熟技术建设（如 HTML5等），主要针对主流智能手机和PAD等终端设备（支持IOS和Android系统），视觉效果和使用效果要充分保证。

3、 系统间对接需求

对接系统名称
说明
内网门户
统一用户及组织机构
单点登录及待办信息推送
和移动门户对接，在移动门户上提供IT作业管理平台相关功能的操作界面
OA系统

IT立项审批单（项目信息）
IT服务单-开发需求类（需求信息）
IT服务单-运维服务类（运维请求信息）
合同审批单及合同台账库（合同信息）
ITSM系统
事件信息
上线发布请求
服务请求
变更请求
邮件系统
发送提醒邮件
短信平台
发送提醒短信、密码找回等

5. 系统现状
目前信息化工作的日常开展主要依托OA系统、ITSM系统、JIRA系统等进行，虽能在一定程度上满足日常办公及条线工作管理的需要，但是普遍存在管理流程割裂、数据信息不一致的情况，同时仍有大量工作的开展依托手工台账方式进行，信息技术相关管理制度、规范指引也无法得到系统的有效支持，对IT条线进一步释放生产力、提高工作效率造成了严重制约!为了填补信息化日常管理场景在信息系统支持方面的空白，打通IT条线相关管理场景和作业流程，迫切需要建设一个流程化、标准化、智能化的IT作业管理平台，以充分满足IT条线的工作需要。

6. 项目系统建设方案
6.1. 系统定位与结构
作为一个流程化、标准化、智能化的IT作业管理平台，它的建设定位于“作业流程全贯通”、“数据标准全统一”、“制度规范全落地”、“风险管控全方位”、“质量效能监督全过程”等五个方面，通过IT作业管理平台的建设，希望达到如下目标：
l 对现有IT工作流程进行全面打通和整合，并结合财险公司发展新常态下对信息化建设工作的新要求，对相关工作流程进行优化和再造；
l 对IT工作流程所涉及的各方面数据标准，包括IT预算、项目、需求、运维等进行统一，建立IT工作信息的标准化数据基础；
l 将信息化相关的管理制度、规范通过系统管控的方式进行固化落实, 确保IT工作实务流程和规章制度的一致性；
l 将IT工作流程及配套制度规范相关的风险管控点、信息安全管控点通过系统方式进行固化落实，确保全方位、无死角的覆盖；
l 对IT工作的质量效能监督检查进行系统化支持，提高检查的效率、准确性和针对性；
l 通过工作流程的打通、信息数据的共享，实现对信息化建设工作的多维度、透视化管理，满足各层级管理需要。

6.2. 业务模型
IT作业管理平台主要包括IT作业管理平台整体框架实施、基础性功能（工作流引擎、表单引擎、数据交换引擎、作业调度引擎、接口管理引擎、工作台等）以及主要管理功能（规划计划管理、IT预算管理、项目管理、需求管理、架构管理、基础资源管理、组织机构管理、合作商管理、质量效能管理、开发管理、发布管理、运维管理、信息安全管理、风险管理），以及IT作业管理平台的移动版本。
6.3. 技术架构
核心功能是以项目管理为核心和主线，集成了项目计划、项目监控、需求管理、测试管理、交付物管理、资源管理、评审管理、外包商管理、合同管理、度量分析等完整的功能模块。并提供各种项目管理过程的统计报表。
完整的覆盖了CMMI二级和三级中的大部分的核心过程域。可以有效的协助CMMI的质量体系认证过程。提高CMMI的质量体系建设效率，是过程体系落地有效工具。
6.4. 数据架构
系统内数据交换
主要指通过设定数据报送任务及模板，可组织进行批量格式数据的报送及汇总理。
系统间数据交换
主要指支持IT作业管理平台通过数据平台和各周边系统进行批量数据交换。

6.5. 权限机制
维护单位（部门）的人员信息。功能包括增、删、改人员，人员顺序调整以及搜索，人员的角色授权和权限列表授权等功能
维护系统角色机及其权限设置。功能包括增、删、改角色及其角色授权和查看角色人员列表等功能
管理用户、角色的页面元素授权。功能包括页面元素人员授权、页面元素角色授权
6.6. 部署模式

6.7. 详细建设方案
6.7.1. 合作外包管理子系统
6.7.1.1. 合作伙伴管理
6.7.1.1.1. 台账统一管理
以资产设备管理为核心、集资产设备日常管理维护、辅助决策、报表自动统计等功能为一体采用先进的管理平台。满足企业审计、资产清查、国务院机关事务管理局、财政、国资委（或其他政府部门）提出的资产设备上报、统计要求。建立统一的台帐管理制度，台帐的内容至少包括所有不同类别合作伙伴的合同清单，清单中应包括合同金额、服务质量标准、服务条款、付款约定等关键信息，这些信息可通过与公司级合同管理系统进行功能整合或建立接口的方式获取，以实现在合作外包管理系统中的统一展示、统一管理、统一统计报表。

6.7.1.1.2. 台账定期审核
台帐信息要以年度为单位发送到部门领导进行审核，提供线上审核能力，部门各级领导和技术人员应经常查阅资料、记录、台帐的登录情况，对记录中反映的问题应及时 进行分析，并有明确答复。IT部门专工应每日审阅本专业的日志、报表和台帐，安培专工定期审阅班组安全活动及技术培训台帐 并签名，部门领导每月不定期检查各专工台帐。合同中是否包含了合作伙伴所提供的产品或服务内容、工作量需求、质量考核标准、结算付款约定、安全保密协议、知识产权约定等重点条款。可通过与公司级OA系统进行功能整合或建立接口的方式，将对上述条款的审核过程及审核结果记录并统一展示在合作外包管理系统中。
6.7.1.1.3. 人员管理
管理人员的扩展信息，包括查看和审核。人员扩展信息可以包括各类奖励、论文、著作等。设置个人信息。包括个人基本信息、密码、头像、补充信息、消息来源、其他设置等
6.7.1.1.4. 工时管理
系统支持领导或者项目经理对工时进行审核。公司审核的功能特点有：
l 可以支持一级审核，也可以支持二级审核机制。
l 可以单个工时审核，也可以批量进行审核。
l 审核不通过的工时，可以重新修正。
l 可以通过配置决定，是否审核不通过的工时纳入统计
工时审核界面如下图：

6.7.1.1.5. 考核管理
查看本项目相关的请销假和加班情况。可以按人、时间、类型查询过滤，输出汇总报表。展示项目人员日报中填写的项目进展情况。可以按人员、时间过滤，并输出报表。从项目成员和参与部门维度查看挣值和报工数据。
6.7.1.1.6. 合作伙伴结算付款
考核评分结果体现在合作伙伴结算与付款中，可从合作伙伴台帐、合同台帐中直接调用查看财务报账单等相关结算付款依据，财务报账单中应体现考核结果。

6.7.1.2. 合同管理
6.7.1.2.1. 合同统一管理
管理合同、客户/供应商、合同标的物及合同付款信息，并对合同进展和财务进行监控。包括合同付款、标的物、检查点、款项、发票要求等信息，可以设置提醒时间。支持单个合同授权。监控合同进展以及合同财务。
6.7.1.2.2. 合同条款审核
l 合同的实体条款和程序条款
l 合同审核与一万小时定律
l 合同审核时，应树立以合同履行为中心的理念
l 区分通用条款和商业条款，有助于提高合同审核的效率和突出重点
6.7.1.2.3. 合同监控回顾
用于监控合同审核情况。可以查看合同、在某时间段内审批流程。能够查看部门人员在各个项目中的合同签订量。
6.7.1.2.4. 合同结束付款
核评分结果体现在合作伙伴结算与付款中，可从合作伙伴台帐、合同台帐中直接调用查看财务报账单等相关结算付款依据，财务报账单中应体现考核结果。

6.7.1.3. 需求管理
需求管理作为软件工程管理的业务基础，所以整个系统需要对需求有全面的支撑能力，能对需求做全生命周期的管理，能在组织范围内协作并管理需求和功能点，能够管理和需求相关的功能或技术设计文档。
需求管理过程中，应当支持工作流管理、审批管理功能，并支持自定义工作流及相应的模版。

6.7.1.3.1. 需求入口
项目或者产品的需求来源有很多：
l 来自于市场客户的需求
l 来自行业规范的需求
l 来自于公司内部业务部门提出的需求
l 项目优化或者问题解决带来的需求
对于上述几个需求来源，北京奥博思PowerProject可以通过创建新需求，批量导入Word或者Excel需求，进入到北京奥博思PowerProject的需求列表中。
这个列表列出需求的标题，每个需求的详细描述，优先级，期望完成时间等属性。业务负责人员可以根据实际需要进行编辑与管理。
需求列表如下图：

当需求的方案成型以后，需求负责人可以提交需求，进入受理阶段。

6.7.1.3.2. 工作量跟踪和考核
人员报工，包括工时填报、工时审核、工时统计。项目成员可以每天填写工作中的时间投入及工作内容。
6.7.1.3.3. 工作量评估
可以关联计划中的任务，可以关联需求，关联缺陷等。实现领导或者项目经理对工时进行多级审核。实现多维度的工时统计报表，包括从项目的维度也包括从部门和人的维度统计工时。
6.7.1.3.4. 开发需求管理
（1）、开发任务管理
l 支持对开发任务的全生命周期管理，暨从开发任务的启动至开发任
l 支持对开发任务的灵活分配、指派，可具体到处室、板块、人员、乙方团队等；
l 支持对开发任务的拆分，以及开发任务间关联关系的建立；
l 对于每个开发任务，提供概览页面，包括任务详细信息、关联任务、详细进展、最新活动、人力资源使用情况、风险等；
l 支持在开发任务流转过程中，对流程的灵活配置、修改、调度，且在流程变更后，原有的流程可顺利完成；
l 支持对开发任务相关过程性文档的归集、整理；
l 对于开发任务的查找，支持灵活、自定义的查找方式；
l 提供对于开发任务的多维度统计功能。
（2）、开发资源管理
l 支持对开发团队及开发资源的管理；
l 对于每个开发团队，提供概览页面，包括团队人员组成、承担的任务信息、工作量情况等；

6.7.1.3.5. 需求后评估
l 支持定期开展IT需求征集工作，在征集工作中可以创建IT需求；
l 系统支持IT需求拆分为子需求，子需求可以在信息部各处室流转，支持对于子需求的评估（涉及系统、预计金额、预算类型等）；
l 系统支持汇总评估结果，并按照需求提出方、涉及信息技术部处室、涉及系统、预算金额、预算类型等维度生成统计表。

6.7.2. 敏捷开发管理子系统
以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
6.7.2.1. 电子看板
Backlog和敏捷任务直观展现，目视化管理(VM,Visual Management)的一种表现形式，即对数据、情报等的状况一目了然地表现，主要是对于管理项目、特别是情报进行的透明化管理活动。它通过利用形象直观而又色彩适宜的各种视觉感知信息来组织现场生产活动，目视管理依据人类的生理特征，在生产现场充分利用信号灯、标识牌、符号颜色等方式来发出视觉信号，鲜明准确地刺激人的神经末梢，快速地传递信息，形象直观地将潜在的问题和浪费现象都显现出来。以便任何人都可以及时掌握管理现状和必要的情报，从而能够快速制定并实施应对措施
6.7.2.1.1. 新建需求工单
l 需求分析阶段，按照评估阶段拆分的子需求，分配给需求负责人进行需求分析，分析完成后汇总分析结果由需求部门确认；支持上传需求成果物以及相关轨迹和要素，形成需求成果物的基线管理；
l 需求实施阶段，支持按照子需求创建开发任务，并按照开发管理功能对开发任务进行管理，在需求、子需求层面体现开发任务数量及进度；
l 需求验收阶段，开发负责人填写验收环境，由需求负责人进行第一次验收，并填写验收结果，需求负责人验收通过后，提交需求部门验收，需求部门验收通过后进入上线阶段；
l 需求上线阶段，支持按照开发任务安排上线工作，通过发布管理完成系统上线，在需求、子需求层面体现上线进度；

6.7.2.1.2. 用户故事管理
用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。
6.7.2.1.3. 计划任务分配
敏捷开发也非常强调计划的重要性，但制定的过程却非常灵活。在敏捷开发迭代初期，开发人员会和客户一起按照需求的优先级和依赖关系制定一个2-6周的开发计划。这个计划的灵活性在于计划的构成不是按照任务数量来规定时间，而是根据时间来制定任务量，这就解决了需求变更导致的计划改变等问题。
l 确认工时
l 确定用户素材
l 估算用户素材所需时间
6.7.2.1.4. 需求池
需求管理模块包括统一需求入口、工作量评估、工作量跟踪和考核、工作量结算和付款、需求后评估构成。

6.7.2.1.5. 每日站会
在Scrum方法中，Scrum 会议非常重要，整个会议可能会比较混乱粗略，但推进度的目标却非常清晰明确，并促使团队齐心协力朝共同目标迈进。团队应召开每日 Scrum会议，以便确定下一天所需执行的工作，以最大可能地履行其承诺。 团队的每个成员都应该描述自上次会议以来所做的工作。他们计划在当天完成的工作，以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或障碍。Scrum主管严格控制会议结构，确保会议准时开始并在15分钟或更短时间内结束。 
SCRUM组严格遵守 timebox原则，每天的日站会准时开始，每次都严格的控制在十五分钟之内，会议的进展也严格围绕daily SCRUM的三个主题进行。

6.7.2.1.6. 故事验收
l 可获得反馈
l 能运行
l 可提交Alpha测试的
6.7.2.1.7. 迭代看板
在敏捷开发的实践当中，通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。通过可视化的任务看板我们可以达到如下几个目的：
1. 可视化管理团队的目标;
2. 明确目标的优先级;
3. 明确目标分解后的任务项;
4. 可视化管理任务的进展状况。

6.7.2.1.8. 迭代评审会看板
敏捷的任务看板通常每个迭代一个，看板的结构通常包括如下几个列：
l Story — 这一列代表的是用户故事，用户故事是敏捷开发中的需求表达方式，每个用户故事代表了从产品的用户视角表达的一条用户需求。用户故事这一列放的是这个迭代需要完成的所有用户故事，这些故事加在一起就是这个迭代的目标。这些故事通常按照优先级从上到下排列。
l Todo — 这一列代表的是待办任务项，用户故事会被分解为对应的技术任务，这些待办的技术任务放到Todo列。
l Doing — 进行中的任务，放正在进行的任务。
l Done — 完成的任务，放已经完成的任务和用户故事。
l 在任务看板上除了有4个列之外，还要为每个用户故事建立一个泳道，通过泳道来管理故事和任务的对应关系。

6.7.2.1.9. 质量分析看板
通过使用看板系统，我们可以将团队的在做任务限制在一个设定的能力阈值内，根据已完成任务的交付速率来平衡交给团队的工作需求。
看板提供了视觉化的直观管理感受，它能迅速暴露那些影响团队效能的问题，因此，在使用看板管理的团队所面临的挑战是：如何专注于解决问题以维持稳定的工作流。
看板很好的展示下游环节的当前状态，根据已完成工作确定前一环节可以投入多少资源，而不是前面环节使劲投入，不管后面环节是否能应对。
看板也为质量和过程中出现的问题供了可见性，使得缺陷、瓶颈、变异性以及经济成本等因素对工作流与交付速率的影响变得更明显。仅就使用看板来限制在做任务这一做法，就能促成更高的质量和更高的效能。
通过看板建立团队稳定的任务节奏，实现始终如一的可靠交付，这能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。而信任关系对每一方都是非常重要的。

6.7.2.1.10. 迭代燃尽图
系统可自动根据敏捷任务构建燃尽图，用来观察项目过程中完成的实际工作量与剩余时间的关系。在项目完成之前，可视化显示需要完成的工作并预测当前进度能否按时完成。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
6.7.2.2. 需求成果管理
l 支持成果物的基线管理和版本管理：
1）每个成果物支持独立的版本管理；
2）同一个文档支持版本间的差异比较；
3）同一类型的文档可以进行合并；
4）支持每个文档的编辑权限独立控制；
l 成果物的条目化、层次化管理：
1）支持成果物的导入导出，支持WORD文档导入后直接按照文档结构进行章节分层，支持在线编辑完成后直接导出为WORD格式；
2）支持成果物的图、文、表等形式的编辑；
3）支持条目的移动、复制、拖拽等操作；
4）支持查看条目的变动历史；
l 支持需求跟踪矩阵，建立需求、项目、系统、开发任务、测试用例、缺陷等之间的跟踪关系；
l 支持需求变更管理，支持记录需求变更依据、将变更与条目进行关联、支持查看变更记录、通过变更依据分析产生的影响及被变更影响的条目；
l 支持成果物的管理，如移动文档归属、对文档进行授权、跨项目的文档复制等功能；
l 支持所有成果物的全文检索，支持自定义搜索模板；
l 需求变化自动通知；
l 支持需求条目设置内部流程，可以在各环节之间相互流转状态，支持记录流转记录、支持查看流程图；
l 支持需求属性扩充，可自定义表单；
l 支持ECXEL模板下载及导入检查；
l 支持需求条目详细关联问题的跟踪及管理。

6.7.2.2.1. 创建列表
创建需求条目列表，并且根据需求改变可配置列表表头。
6.7.2.2.2. 创建迭代计划
在项目初期先挑选系统核心架构的需求来实现，待系统核心架构完成后，再在系统核心架构的基础上不断的添加其他功能模块，通过累加开发的方式，来不断的完善系统，并在完善系统时，对系统的瑕疵或不足，不断的进行重构和改进设计工作。通过多个迭代的敏捷开发，并且每个迭代都会产生一个可使用的产品。
每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。
6.7.2.3. 敏捷团队角色配置管理
管理必须在其所涉及的整个实践领域内不断地促进内容和环境的转换。由于内容和环境经常会变化，所以转换必须纳入例行的迭代中。为此，管理人员必须保证信息的共享和理解。
l 项目过程和结果的完全可预见性
l 总是有且只有一个客户
l 专注于指挥与控制
l 很少或者不涉及内容管理
l 只管理输入-输出

6.7.2.4. 质量分析流程管理
1）、检查计划管理
l 支持质量效能检查计划、检查任务的建立和维护，并对相应计划、任务的执行情况进行跟踪监督；
l 支持对检查结果的整理及导出。
（2）、检查流程及检查点管理
l 支持检查流程及检查点的建立和维护，并设置相应的质量效能目标及告警阈值。
（3）、检查问题记录及后续处理情况跟踪管理
l 支持从各工作环节中按照设定的规则，自动收集质量效能问题；
l 支持各工作环节主动报送质量效能事件；
l 支持对于质量效能问题的解决进展进行跟踪，并可根据需要触发告警、提示或其他工作流程。

6.7.2.4.1. 下发质量分析待办

6.7.2.4.2. 记录生成

6.7.2.5. 测试流程管理
l 支持对测试用例的管理；
l 支持对测试计划的管理；
l 支持对测试资源的管理；
l 支持系统缺陷的跟踪管理，包括集成测试BUG和UAT阶段BUG的跟踪管理。

6.7.2.5.1. 流程模板
测试计划管理的具体功能流程如下：
l 支持测试计划和测试轮次的测试生命周期管理
l 每个计划的每个轮次都可以创建或者导入测试用例
l 一个项目可以有多个测试计划
测试流程界面如下图：

6.7.2.5.2. 扫描结果反馈
支持集成已建开源性能测试工具，并且可以从集成的第三方或开源工具中获取测试报告，实时反馈，并支持测试用例测试结果汇总和各版本测试问题对比等分析功能。输出报告支持定制化输出检查报告展示。

6.7.2.5.3. 回退方案及测试通知
测试管理要实现对项目测试过程中相关文档、测试活动和阶段、缺陷以及测试结果的统一管理，能够形成并且建立完善的测试用例库，以此来指导测试过程。
1) 测试说明文档管理。系统支持创建和管理测试说明文档，其中，测试说明文档由测试用例构成；支持测试说明文档的复制、合并、导入和导出功能，支持将测试说明导出到Word。测试用例可以关联需求和产品，方便进行需求覆盖分析。
2) 测试活动和阶段管理。支持测试活动和阶段的统一管理，测试活动由不同的测试阶段构成，每一个测试阶段都可以关联一个测试说明文档。测试活动和阶段可以在不同的系统之间导入和导出。导入操作将更新关联文档的测试结果，使得测试结果能够及时更新。
3) 测试结果记录。可以对测试用例中的每一个步骤的测试结果进行记录，对整个用例的测试结果进行总结，支持缺陷的记录，同时能够追踪缺陷对应的测试操作步骤和方法。记录的测试结果为进行测试统计分析提供真实有效的数据。
4) 测试任务分配与处理。测试阶段用例可以直接指派到个人，或者以任务的方式指派到个人，个人登录后能够看到自己负责的测试用例，并能执行和记录测试结果。
5) 建立一个名为“测试用例库”的项目，将所有的测试用例汇集在该项目中。其他项目可直接引用该项目中的用例（具体到某条用例的直接引用）。修改后的用例可以再次入用例库，并有版本管理和历史记录。
6) 测试用例的维护（添加、更新、删除等）仅在该项目中进行，可统一管理测试用例。
7) 测试用例（包括测试用例中的所有信息）可以详细导入导出，采用Excel格式或CSV格式。
8) 统计分析和报表输出。支持按阶段对测试活动进行统计，能够统计测试用例通过比例和测试覆盖比率，统计测试过程中发现的缺陷数量，统计报表内容可以直接输出到Word。
9) 测试步骤带上所有步骤信息功

6.7.2.5.4. 缺陷汇总
缺陷管理是对测试过程中发现的缺陷进行管理，包括缺陷的建立，处理，转发，修复，验证，关闭等完整的缺陷处理流程。
缺陷管理的功能有：
l 支持对缺陷处理流程的自定义，完全由用户决定缺陷的处理过程
l 支持对缺陷提交表单的自定义，由用户提出表单需求进行定制实施
l 提供灵活的缺陷查询功能，可以保持查询条件
l 支持多维度的缺陷统计功能，提供统计图表（柱状图，饼状图等）
下图是缺陷列表界面：

下图是缺陷处理流程图：

下图是缺陷统计图：

6.7.3. 工具链管理子系统
支持流水线自定义，如新增开发提交流水线，定制化开发需要的流水线工具，提供定制化能力。
提供流水线模板，可快速根据实际环境进行对接接入。至少内置开发流水线、测试流水线和发布流水线。支持流水线执行过程的可视化，并可查看日志及扫描报告等，具备历史日志记录及审计报告能力和执行过程的可视化管理能力。
流水线执行过程可视化，包含各环节执行时间、执行错误日志输出等，操作结果直观呈现。

6.8. 系统割接方案

7. 下一期规划建设建议
1、需求方的高层质量目标
这个是最重要的，多数情况下就是客户和直接发起领导的高层意图，比如速度快、界面美观、高质量等定性的指标，能够指示质量关注重点。
2、公司运营管理的总体要求
比如配合项目/产品需要多长时间完成、成本多少等等，这个通常是限制，要在这个大的限制下做好质控，不能说为了达到90%的测试覆盖率，而让项目成本超标，那就不是测试的本来目的了。
3、设计、开发的要求
要了解开发人员的工作习惯、使用的工具/平台/构架，有些事情是开发工具解决不了的问题，不要硬生生通过“文字”反馈给开发人员，应该先有个沟通，在形成一定共识的基础上设计测试计划，对于设计或构架等难于解决的问题，也要有渠道反馈给管理层，以做风险应对，而不要针锋相对非逼着研发人员修改，最后可能会出现拖延、误修复等更严重的问题。
4、测试的要求
了解公司的质量管理要求、策略、制度、流程，更重要的是了解执行测试的人员的实际能力和经验。如果这份测试计划包括了定义的测试操作（也即是测试用例），那这部分是不能因人而异的，如果说测试计划是为了指导测试人员开发测试用例并指明测试工作安排的，则可以考虑根据执行人员的经验水平进行繁简处理调整，如果都是初级人员，则测试计划就要写得细一些；如果都是高级人员，则可以把测试计划的执行主体部分写的宽泛一些。
5、实施的要求
这里包括项目/产品的实施人员、运维人员、销售人员的意见，比如项目后期的运维方式、系统的版本控制、自动更新、授权许可机制等