顾黄亮
作者顾黄亮2022-01-11 10:04
技术总监, 畅销书作者

《DevOps权威指南:IT效能“新基建”》-支撑管理(3.1)

字数 13504阅读 2465评论 0赞 0

作者:顾黄亮 (现任苏宁消费金融安全运维部总经理)

【声明】为了能让大家更好的学习Devops以及深入了解应用Devops的实践案例,《DevOps权威指南:IT效能“新基建”》作者顾黄亮先生授权twt社区进行该书部分内容连载。内容包括DevOps的基本概念,DevOps的工具集,支撑管理,敏捷开发,持续集成和测试,持续部署和持续交付,代码质量和安全,DevOps的度量体系,持续改进和反馈,DevOps最佳实践,以及DevOps的后续发展。

3.1 项目管理

在 DevOps 的实践过程中,项目管理是重要的能力子域。项目管理能不能在 DevOps 中体现,在作者看来,取决于项目管理的职能范畴,以及项目管理在企业文化、组织架构中的构成。本节的重点是 DevOps 和项目管理的集成,以及项目管理如何通过 DevOps 进行项目或产品交付中价值的锚定。

在作者看来,项目管理是一个很大的命题,也是一个全局概念。根据企业规模、业态的不同,项目管理呈现多种管理方式,具有鲜明的行业特征和领域属性,主要表现在项目章程和管理计划两个方面。项目管理的方法是一致的,也是可以客观的。从顶层来说,消除业务方的需求痛点和降低项目成本是根本,这也和 DevOps 的低成本、高效有很强的契合性。

3.1.1 传统项目管理、 IT 项目管理和 DevOps 项目管理的区别

1 .传统项目管理

传统项目管理把各种知识体系、运作手段和技术能力在项目活动中进行有机结合,旨在达到项目的预期。传统项目管理分为启动、规划、实施、监控和收尾 5 个阶段,管理的手段按照这 5 个阶段进行使用。值得注意的是,传统项目管理的手段较为成熟。

传统项目管理被广泛地理解为,在有限资源的制约下,运用成熟的项目管理手段和方法论,对项目过程中的标准节点进行有效管理。因此,传统项目管理包括不同行业、领域和业态的几个共同点,项目管理负责需求识别;项目管理负责可实现目标的明确;项目管理负责项目的质量、范围,以及时间和成本的平衡;项目管理通过项目资料和项目计划促使需求方和实施方很好地进行协作。由此可见,传统项目管理更多地呈现过程中的“主观为主、客观为辅”特性,更多地体现组织协作能力,重点在于领导力。上述特性造成了项目管理以项目组方式,垂直或矩阵式地进行项目的推进和管理。

2 . IT 项目管理

IT 项目管理是项目管理的一个分支,是项目管理在 IT 领域的应用,因此, IT 项目管理的基本特性继承于项目管理,其特性在乙方交付领域表现得格外突出。根据 IT 项目管理的描述, IT 项目管理是 IT 领域针对项目交付的一种管控手段,旨在达到项目的预期。和传统项目管理不一样的是, IT 项目管理中存在技术和管理交叉,且随着技术的演进,不断变化。因此,对于 IT 项目管理,有很多不同的理解,这也为后续的敏捷型、 DevOps 型打下了基础。

IT 项目管理往往集中在复杂的 IT 项目中。在 IT 项目的生命周期内,一般通过建立临时项目团队,由指定的项目经理对项目的计划、组织、控制和实施等阶段进行统筹管理,实现全局过程的内部优化、资源协调和最终的项目价值交付。

IT 项目管理和传统项目管理有本质的区别,传统项目管理突出领导力,将人、财和物集中进行安排,最终的项目后评价比较固定,如新建一栋大楼,进行某个产出物的交付时,一般可以通过行业规范和准则进行度量;而 IT 项目管理突出过程中的风险管理,将人、财和物进行统筹安排,最终的项目后评价存在极大的不确定性,且过程中的干扰源更多,因此, IT 项目管理更多地进行技术和管理的平衡,突出“技优则管”特征。

3 . DevOps 项目管理

DevOps 项目管理是 IT 项目管理的一个新的方向,是持续交付、价值交付的实践方式。在 DevOps 流水线中,项目管理是全流程的参与者,尤其在扁平化的 IT 组织架构中,项目管理已经不再局限于某个人或某个团队,往往通过数字化的方式对过程进行辅助跟踪。

DevOps 项目管理是高阶的 IT 项目管理,建立在实现研发敏捷和持续交付的基础上。在一些具备互联网基因的中小型项目中, DevOps 项目管理需要通过项目“敏捷”的方式,简化交付流程和提升交付价值,以“构架为中心、数据驱动、迭代交付”的方式达到价值交付的目的。 DevOps 项目管理有一个显著特征:相比传统的 IT 项目管理,对端到端的交付提供了可持续改进的属性,因此,度量和反馈需要数据赋能。

在此,我们将 DevOps 项目管理和传统的 IT 项目管理进行对比。 DevOps 项目管理和 IT 项目管理都需要前置的流程驱动进行项目文档的约束,如需求规范、代码设计文档。相比传统的 IT 项目管理, DevOps 项目管理对全流程进行一定比例的压缩,通过技术传递和自由流程的方式对文档进行二次处理和内容提炼,这种要求对团队的适应能力和自由度提出了较高的要求。

同时, DevOps 和研发敏捷的有效结合,对流程驱动的压缩提供了更好的方式,相关的项目风险集中在项目执行过程,通过燃尽图、看板监控和项目计划等方法来降低项目生命周期中的冲突发生的可能性。实际上,想要真正实现 DevOps 项目管理,需要流程驱动和数据驱动的融合,通过流程驱动的方式规范过程,减少风险,通过数据驱动的方式优化过程,提升价值。 DevOps 项目管理的迭代周期能力随着各能力子域的数据输出在项目管理统筹下得到大规模变现,实现了迭代周期变短、质量提升的效果,在实际的执行过程中,具备高效和低成本的特性。

DevOps 项目管理在很多企业的 IT 领域得到应用,但有些企业过于追求结果,导致了很多问题。究其原因, IT 组织的文化冲突和技术障碍导致了风险放大和质量下滑,对于项目管理者,数据思维和数据的使用需要上升至全局,项目管理的软技巧的使用更需要通过数据的方式体现在流程中。对于效率和成本,我们需要找到平衡点。效能和价值取决于项目管理全链路的风险控制和最终项目团队的输出变现能力,因此,作为 DevOps 项目管理的推动者,既需要具备传统的 IT 项目管理的知识体系,又需要具备交付全链路各能力子域的知识矩阵,最终形成 DevOps 项目管理的方法论。

3.1.2 DevOps 在项目管理中的定位

1 .控制项目需求的质量

目前,很多科技企业过度追求研发效能的提升,其实这种做法是不妥的。当需求的质量存在较大问题时,过高的研发效能会造成 IT 资源和人力的浪费,因此,控制项目需求的质量是项目管理中的一个难点。在传统的 IT 项目管理中,过往的数据存在指标单一和粗放等特点,借助 DevOps 可以帮助项目推动者提升项目需求的质量。

在软件项目的定义中,需求管理是项目管理前期的重点。软件项目的需求涵盖场景需求、用户需求和软件自身的架构需求。需求的生命周期涉及的能力子域呈现跨中心、跨体系分布的特点,因此,对于需求的收集、发掘和定义,需要 IT 组织提前介入,而对于需求的确认和实现,需要需求方的配合。在需求阶段,由于需求的复杂度导致需求的实现过程中的插队和变更会对需求的实现造成资源的浪费和影响最终的交付质量,因此需求的质量是软件项目中的风险点。对于项目管理,需求的稳定性保证了项目的整体计划的实施和最终的交付预见性,对于需求基线和质量的控制,需要通过 DevOps 进行辅助。

在 DevOps 的生态体系中,以项目参与度、项目类型和项目组织进行横向对比,分别对过往项目的需求进行回溯,针对回溯情况进行评级,以动态指标辅助项目推动者关注风险的级别。

在需求的质量评估方面,通过业务政策和数据对需求提供预评估,同样可以降低风险的级别,提升需求的质量。在需求控制点确认方面,对需求状态的跟踪需要打通端到端的追踪通道,打通从需求到确认,再到编码的过程,在这个过程中,很难对需求的质量进行控制。 DevOps 可以通过持续集成和持续部署,推动整个交付链路前移,为需求的质量的提升提供单维空间。

2 .完善项目的组织类型

组织是项目管理的核心要素。组织可分为项目型、职能型和矩阵型。企业往往根据项目的类型、大小和输出方式选择不同类型的组织,因此组织的类型在项目管理中呈现一种不确定性,这种不确定性往往需要项目推动者具备相应的组织能力和内外部协调能力。

对于项目管理,组织的协调工作最终以项目的驱动为根本,所有的组织成员都需要围绕软件交付的目标需求,最终完成项目的交付。在实际情况中,组织成员来自 IT 组织的各个能力子域,汇报机制伴随能力子域的划分存在多头的情况。因此,在项目管理中,需要明确组织成员的职责,进行资源的分配和协调。项目管理中的沟通和协作能力会成为阻碍项目交付的因素。在 DevOps 的生态体系中,打通 IT 组织内的“部门墙”是必需的。项目管理需要依托 DevOps 协作机制将能力子域作为链接锚点,有序地对信息的传递和反馈进行规范性约束。在实际情况中,以项目批次为流水线的方式已经取得了比较好的效果,其特点为弱化组织成员的特性,采取人力资源池的方式,对能力子域进行项目内职能映射,推动项目的有序进行和风险管控。

3 .突出项目的内部透明度

近些年,项目的内部透明度已成为项目管理的一个新的发展方向。对于项目参与者,项目进度和项目阶段性成果至关重要。传统的 IT 项目管理以看板的方式进行项目过程的跟踪,这往往导致在数据覆盖度问题上出现判断失真的情况。在组织成员分布方面,存在各属性的成员对数据的解读不够的情况,因此项目的内部透明度问题需要彻底解决。例如,测试案例一般基于项目需求和编码的实现方式进行编写,如果项目中出现加塞或变更的现象,往往导致测试案例样本中出现功能点遗漏的问题,同时,编码的进度也会影响测试用例的覆盖度,需要及时进行信息的同步。传统的同步方式往往是人和人的沟通,项目参与者的参与度决定了内部信息的透明度,而项目的推动者往往会忽略这一点。

DevOps 的生态具备了数字化属性,通过项目内部各能力子域的数据汇聚来纠偏最终的目标一致性,并通过一致的内部协同机制发挥项目团队在交付过程中的价值。对于项目管理,各阶段的管理需要以衔接的方式传递项目的情况。对于项目参与者,每个人都需要清楚在项目内部的定位和自身具备的能力,这样就可以通过数据反馈和数据参考提升自己,实现自我促进,同时为项目负责。

4 .提升项目风险管理水平

对于项目管理,可以通过项目风险管理来预测项目是否成功。对于传统的 IT 项目管理,接近一半的复盘往往是项目失败复盘,只有通过复盘,才能意识到相关的问题。

在项目管理的项目跟踪控制中,风险和问题是核心要素。在项目管理中,我们应该具备风险意识。风险意识包括项目危机感知能力、项目洞察力和项目风险处置能力。

在项目危机感知能力方面,对于项目管理,需要具备危机感知前置度,这取决于项目推动者的管理经验和从业经历,即通过过往的项目经历分析出可能造成项目危机的因素。在项目洞察力方面,项目推动者需要具备完善的数据思维,通过数据的关联和映射,尽快匹配项目的风险。在项目风险处置能力方面,需要项目推动者具备相应的经验和协作能力,通过资源的适时调配来完成对风险的处置。

对于项目管理,风险和收益是并存的,当需要承担风险的时候,最终的项目收益也是可观的,因此项目参与者需要以积极的心态对待项目风险。从上述风险意识和项目危机感 知能力的角度来看, DevOps 在流程管控和数据输出方面有助于项目推动者提升风险的识别 和处置能力,尤其在 DevOps 的度量环节,可以让风险无所遁形。

5 .提供项目监控

项目管理分为启动、规划、实施、监控和收尾 5 个阶段,对于每个阶段的风险控制和进度管理,需要具备相应的监控体系。相对传统的软件监控和系统监控,这种监控体系有很大的不同。项目的监控体系基于项目计划(也就是我们常说的项目运行情况和计划基准的进度偏差)和项目资源的衔接(通常理解为项目运行过程中对人、财和物的控制机制)。项目监控一般从识别开始,到确定控制标准,再到项目实施,一直到最后的过程管理。

在实际的执行过程中,传统的 IT 项目管理重点关注项目进度、成本管控和质量保障等,传统的 IT 项目监控可分为监管和控制两个方面,其中监管考查项目的执行是否遵循预定计划或者过程中的流程是否合规,控制的重点在于通过纠正的方式对偏离值较大的风险点进行规正,涉及风险识别、风险评估、风险计划、风险实施和风险沟通等一系列过程。常见的项目监控对象有需求范围的变更、人员的产出和沟通渠道的管理等。

DevOps 的生态体系赋予项目监控一定的灵活性和数据参考性,通过项目推动者的取舍来达到合规和不合规之间的平衡。尤其在快速交付和价值交付的边界方面, DevOps 的流水线和反馈度量提供了监控系统的适应性,其中包括项目自身和控制对象的适应,资源输出和产出的适应,以及流程驱动和数据驱动的适应。 DevOps 需要推动项目监控实现以下特性。

( 1 )相关性。由于项目内部各能力子域和需求方的复杂性,因此,对项目风险因素的控制应该具备较强的相关性,通过数据分析可以快速判断上下游因素的影响范围。

( 2 )适用性。在流程控制过程中,对于数据的使用,应该考虑全局,而不是局部。通过对数据的打标规范数据的使用范围,尽量确保数据的使用在项目监控的过程中具备较高的适用性。

( 3 )高效性。项目监控需要高效、及时地提供预警信息,提高预警信息的准确率和召回率,便于在项目监控过程中快速对项目风险执行纠偏。

3.1.3 DevOps 在 IT 项目管理中的特点和作用

1 . DevOps 在 IT 项目管理中的特点

IT 项目管理的过程具备以下 3 个特点。

( 1 ) IT 项目一般通过业务驱动, IT 组织负责实现和支撑。在不同业态和规模的企业中, IT 组织通过支撑、服务和引领的方式为业务赋能,因此,项目管理具有强耦合的业务属性。

( 2 ) IT 项目管理通过组织实现,组织不仅局限于 IT 组织,还包括业务组织和其他支撑部门,因此,资源调配是项目管理中重点关注的对象,项目管理者利用现有的资源在规定时间和场景内进行交付是项目管理的基本要求。

( 3 )项目管理的重点在于项目计划的制订。项目计划是否合理将影响项目交付过程中的技术指标的覆盖度,这一点在 IT 项目中尤为重要。价值交付在需求管理阶段能够帮助需求方达成业务需求,业务需求涵盖产品性能、交付质量和技术指标等核心要素。

在传统的 IT 项目管理相比, DevOps 具备一些显著特点,这和 DevOps 的生态体系相关,越健全的生态体系对项目管理的赋能越全面。

  • DevOps 通过对过往数据的预估,能够提前预估项目的目标达成情况,为项目目标的实现提供数据支撑。
  • DevOps 能够规范项目的生命周期,通过生命周期管理能够兼容项目过程中的变更,实现项目管理过程中的目标弹性。
  • DevOps 的无障碍沟通方式能够推动项目组织实现开放性和临时性,将资源进行池化,以总包的方式推动项目落地,打通 IT 组织和业务组织间的“部门墙”。
  • DevOps 的持续集成和持续交付的能力,在项目管理阶段,通过敏捷的方式实现 IT 组织在价值交付过程中的渐进,增加项目管理的透明度。
  • DevOps 的流水线能够帮助项目推动者对项目管理中的监控和预警进行管理,降低项目风险。
  • DevOps 的流程驱动和数据驱动的能力,在项目管理阶段,通过项目泳道和数据看板,能够控制项目活动的进度,对偏差度进行及时纠正,保证项目活动的整体性,消除短板,提升组织级的效能和质量。

广义的 DevOps 覆盖了价值交付链路中的所有环节,因此,需要多个组织参与,如决策方、业务方、用户、项目组织和 IT 组织,这种大范围的项目活动组织提升了对项目活动的参与度,这一点和项目管理的广度类似。在 IT 项目管理的利益关系图中, DevOps 流水线关联了绝大多数的干系方,分别从事前、事中和事后阶段提供项目活动的支持,这一点是传统的项目管理不具备的。项目活动组织的关联方如图 3-1 所示。

图 3-1

2 . DevOps 在 IT 项目管理中的流程驱动

从本质上来说,在 IT 项目管理中,没有单纯的流程驱动,因为单纯的流程驱动不利于在复杂场景下开展项目,尤其在需求变更和项目目标调整的环境下,存在滞后和失控风险。 DevOps 的流程驱动更多基于软件交付的流程,而不是项目交付的流程。这里需要强调的是,流程驱动更多基于业务价值的驱动,以服务的方式为业务赋能。

在传统的 IT 项目管理中, IT 组织作为业务的后端,承担支撑作用,而 DevOps 的流程驱动融合到项目管理中,对整体的交付流程进行横向扩展,从上游辅助业务进行价值导向的固化,在下游完善价值反馈机制,因此, DevOps 在 IT 项目管理中的流程驱动更多从成本和收益的角度进行。

在传统的项目管理中,具备阶段性特征的管理体系,该管理体系包含范围管理、时间管理、成本管理、质量管理、资源管理、采购管理、风险管理和沟通管理,介绍如下。

  • 范围管理。对于范围,涉及项目的范围计划、范围确认,以及范围的变更。从 DevOps 的角度出发,在项目立项阶段,需要对项目进行预估,设定项目的目标。
  • 时间管理,顾名思义,需要对项目的交付时间进行设定,这包括项目活动的编排、项目进度的设置和项目进度的控制。从 DevOps 的角度出发,对于时间管理,需要结合项目参与方进行时间节点的编排并设定流水线分段,也就是设置“里程碑”的时间节点。
  • 成本管理包括资源计划、资源成本、资源测算和资源控制。从 DevOps 的角度出发,成本管理映射了资源的管理,包括对硬件资源池和人力资源池的管理。
  • 质量管理。通过质量管理,可以确保项目能够满足既定的质量。质量管理包括质量计划和质量保障。对于 IT 项目,质量管理对应测试质量和业务验证质量。
  • 资源管理。与成本管理不同的是,资源管理的重点在于团队建设和资源分配矩阵,以及反馈度量过程中的考核机制。
  • 采购管理的重点是对 IT 项目中的第三方团队和交付物的管理,如采购计划的管理、采购过程的管理和第三方服务的管理。采购管理具备交叉和矩阵式的管理特征,一般由项目推动者进行统筹。
  • 风险管理包括项目活动的事前、事中和事后阶段的风险识别和风险评估,以及对风险的监控和处理。从 DevOps 的角度出发,风险管理集中在度量反馈阶段。
  • 沟通管理。沟通是流程驱动的基础。通过收集项目活动过程中的信息并进行横向和纵向传递,可以增加项目活动的透明度,降低项目风险。在沟通管理中,一般有端到端和段到段的沟通方式,这样可以确保项目参与者知晓以何事需要何时向何人进行反馈。

在 DevOps 的流水线中,一般以递进的方式进行流程驱动,并以交付后进行评价形成整个流程的闭环,如图 3-2 所示。

图 3-2

3 . DevOps 在 IT 项目管理中的数据驱动

数据驱动是流程驱动的高阶实现。在 DevOps 实践的过程中,驱动方式一般有两种,分别是流程驱动和数据驱动,这两种方式一般以递进的方式存在,先有流程驱动,后有数据驱动。在项目活动中,常见的一种方式是由流程驱动转变为数据驱动,使项目活动更加敏捷,另一种方式是采取数据赋能的方式优化流程驱动,使项目活动更加稳健。前一种方式适用于快速交付,后一种方式适用于价值交付。

数据驱动大大增加了项目活动的透明度,让每个项目参与者了解项目各阶段的情况,形成透明的流程模型和起到风险明确的作用。数据驱动方式会带来新问题,如各能力子域以各自的交付物进行上下游传递,并通过人机交互的方式构建流程模型,数据失真会对流水线形成较大的进度和质量方面的冲击。因此,数据驱动需要项目推动者随时介入。

数据驱动提高了项目活动中 IT 组织的支撑力度,更能将支撑转变为引领。数据驱动不仅驱动项目活动,还能驱动项目活动的多个关联方,如通过数据驱动需求的规范和项目的准入,通过项目后评价对业务方进行反向复盘。

通过流程驱动的最佳实践,促使各能力子域共同合作,以项目的价值交付为目标,通过交付物的形式进行横向和纵向传递,及时发现和解决问题,并通过全局复盘方式,实现项目活动的持续性和可回溯性,最终提升组织级的效能和质量,而不单单提升 IT 组织的效能和质量。

3.2 需求管理

在 DevOps 实践的过程中,对于需求管理,更多的是精益的需求管理。需求管理在价值交付流水线中处在重要的前置地位。精益的需求管理是敏捷流程的高阶实现,也是 DevOps 锚定价值的体现。

3.2.1 需求管理的概念和内容

需求管理是对需求分析过程的管理。需求分析是指通过分析需求来获取用户需求,有选择地针对某一类业务导向的线索,将收集的需求进行串联,进行业务分析和消除矛盾,并在业务分析的基础上结合系统现状进行系统分析,形成最终的需求方案和系统需求说明书。

传统的需求管理大致分为 8 个步骤,这 8 个步骤存在先后顺序和关联。这 8 个步骤分别为需求识别,业务流程分析,数据实体分析,角色和使用场景分析,系统功能分析,数据割接分析,用户体验分析,以及非功能需求分析。需求识别,业务流程分析,数据实体分析,角色和使用场景分析,以及系统功能分析是其中的重要步骤。

1 .需求识别

在需求识别阶段,需求人员需要对需求类别、需求复杂度和需求的价值进行分析,并根据结果来确定需求实施的优先级。

需求分为流程类需求、统计分析类需求和接口类需求。需求还可以分为单类型需求和多类型需求。在确认需求类别后,我们应该对需求的数量进行初步分析,如流程类需求应该包含多少个不同的流程、统计分析类需求应该包含多少个统计分析报表和接口类需求应该包含多少个接口。

需求复杂度分析通常作为工作量统计口径的一种方式,在需求复杂度分析过程中,通常将 5 人天以内的需求视为低复杂度,将 5 ~ 15 人天的需求视为中复杂度,将高于 15 人天的需求视为高复杂度。

价值分析是需求识别的重点。需求的价值和产品收益存在直接关系。在需求收集过程中,需求人员通过自身能力或需求评估模型对产品收益进行预估,最终判断并得出需求的价值。分析的维度包括需求的痛点和目标,需求的复杂度,以及业务的重要程度。

2 .业务流程分析

在需求管理过程中,针对流程类需求,需要进行业务流程分析。业务流程可以通过组织、部门和岗位 3 个维度进行分析。我们需要对涉及的具体岗位,执行活动,以及活动之间的关系进行梳理。业务流程分析是需求分析的主线,是流程分析的重要组成部分,其中组织级流程较为宏观,是对部门级流程的统一概括,而岗位级流程更多关注业务活动执行的细节。

一般来说,需求识别阶段确认的流程以部门级流程为主。在进行流程分析时,需求人员需要遵循以下步骤:确认业务流程,确认角色和业务活动,确认业务活动之间的关系和数据,以及分析流程的整体瓶颈。

3 .数据实体分析

流程类需求需要对业务活动中传递的数据实体进行分析,统计分析类需求需要分析的数据实体包括统计查询条件和查询逻辑,接口类需求需要分析接口对接或传输过程中的数据实体。

我们需要明确数据实体,涉及系统原有实体、新增实体和改造实体。我们需要明确数据实体之间的关系,如对应关系,还需要分析数据实体变更过程中的版本变化、造成的影响。我们需要明确数据权限和数据权限对应的角色,确保数据权限遵守最小化使用原则和权限适配原则,以及敏感数据隔离原则。

4 .角色和使用场景分析

一般来说,业务活动是对用户使用场景的抽象说明。业务活动和业务场景的关系可能是一对一,也可能是一对多。使用场景应该以业务活动为主线进行分析。每个业务活动需要包含下列内容。

( 1 )明确业务活动的执行角色。

( 2 )明确业务活动执行的前提条件和后置条件。

( 3 )明确业务场景的分层,如业务活动需要正确场景、备选场景和异常场景。

( 4 )明确每个业务场景的执行步骤的相关内容,如执行步骤的语法和语义,以及步骤之间的交互方式。

( 5 )明确业务活动需要遵循的业务规则和约束,这里的规则一般是指与业务流程相关的行为规则或与数据实体相关的数据规则。

5 .系统功能分析

系统功能分析是需求分析的核心,需要结合系统现状和上述分析明确用户场景的系统功能。系统功能分析也是需求说明书的重要组成部分,包括功能列表、功能分析、系统交互原型分析和算法分析等内容。

3.2.2 需求管理的难点

在软件交付过程中,随着企业规模的扩大和业态复杂的度的提高,对于需求管理,我们遇到了各种各样的问题。这些问题大致分为以下 3 类。

1 )需求来源呈现多样化趋势;需求差异过大,难以互相兼容

需求的多样性主要体现在非标准化产品中,这主要是由标准化需求和定制化需求之间的差异决定的,二者的主要区别在于用户群的功能覆盖面不同,标准化需求的用户群较为成熟,定制化需求面向的是一小部分同质化的用户,因此,标准化需求比定制化需求要丰富。针对同一类型功能的需求,需求之间存在重叠交叉或互斥的情况,因此会造成需求之间差异过大和难以兼容的情况,这在软件商业化输出的企业中表现得尤为明显。

2 )配置项过多和过于复杂,导致软件使用体验较差

在功能比较复杂或功能迭代频繁的软件产品中,需求的扩展是通过增加配置项来实现的。我们将配置项进行差异处理,以面向不同的用户群体。随着软件产品的版本迭代和功能扩展,配置项越来越多增加了软件产品使用复杂度,从而导致软件产品的用户体验较差。对于需求管理,需要提升配置项对应的需求识别和价值分析能力。

3 )不合理的需求管理导致开发阶段的版本和分支混乱,以及过多的技术债务

在敏捷研发过程中,由于过度追求研发效能,以及持续交付过程中的管理欠缺,导致相关的交付资料缺失。另外, IT 行业的人员流动频繁,最终导致在需求的开发过程中,需求配置、需求版本和需求分支不能得到有效管理,于是产生技术债务。产生上述问题的根本原因在于,在需求管理阶段,需求的管理和评估机制不健全。为了快速完成任务,快速上线产品,企业忽略了对交付过程前置部分的健康和有序管理。

除 上述比较有代表性的问题以外,还有一些常见问题。例如,在需求管理阶段,没有对需求进行有效分级,不同阶段的需求缺乏明确且合理的定义;在组织架构层面,缺少连接市场和 IT 组织的组织,该组织可用来实现市场到产品的需求衔接;在需求分析阶段,缺乏完善的收集、汇总和分析机制;在 IT 组织内部,交付流水线缺乏标准的端到端的业务流程传导机制;在工具层面,缺乏将需求管理纳入 DevOps 流水线的工具,数据不能完成流动。

3.2.3 需求管理的工程方法

在需求管理过程中,我们需要认清一个准则:每一个需求都是分层的,某些需求是针对某个用户群体的特定需求,某些需求是针对多个用户群体的通用需求,某些需求是针对某个用户群体的临时需求。需求的分层是需求管理中的一个重要方法,因此,需求人员需要将认知建立在全局层面,从业务角度,通过端到端的需求渐进方式对需求进行分层,如图 3-3 所示。


图 3-3

针对需求管理中遇到的问题,需要对需求管理采用工程化的方法来进行需求识别管理、需求过程管理和需求场景管理,促进需求管理过程中的各个阶段能够进行良好的衔接。需求管理的主要目标是对待开发或待完善的软件产品进行精准的、清晰的、完整的和无二义的描述,最终产出高质量的需求交付物。

需 求管理过程包括需求识别,业务流程分析,数据实体分析,角色和使用场景分析,系统功能分析,数据割接分析,用户体验分析,以及非功能需求分析,在工程化方法中,上述过程可以简化成需求的导出与确认和维护需求规格说明两个部分。在一个完整的需求管理过程描述中,应该明确几个要素,分别为需要执行的活动,活动组织的调度,活动的主体,活动的输入和输出,以及用于需求管理的工具。当需求管理过程出现问题时,还需要对过程进行改进。改进的方式包括过程中的改进和过程后的改进。这部分的改进主要由 DevOps 的度量反馈来实现,详见第 8 章和第 9 章。

在绝大多数情况下,需求管理过程可以划分为需求开发和过程管理两个阶段。因为需求复盘一般是较为滞后的阶段,所以此处不进行阐述。需求开发主要产出正式的需求交付物,过程管理主要根据过程中的变化对需求产出物进行内容和版本管理,如图 3-4 所示。

图 3-4

在需求工程化管理过程中,需求开发可以分为两个阶段,分别是用户或市场分析和需求规范。用户或市场分析也称为用户意图分析,主要收集、归纳和整理用户提出的需求,包括用户的诉求,用户需要什么,用户需要达到什么效果,业务需求和系统需求的衔接关系,以及系统应该如何做。需求规范是指由需求人员从需求的逻辑上对需求进行完整且严格的描述,确保需求交付物在传递过程保持不失真,能够准确且清晰地反映用户的需求。下面通过一张图展示需求的工程化管理流程,如图 3-5 所示。

图 3-5

需求获取集中在需求的确定和收集阶段,需求的对象来自需求源、需求承载的系统和需求的内容。

需求分析集中在需求识别阶段。对于获取的需求信息,通过相关的需求分析模型进行需求的提炼和分析。在这个过程中,对已知的需求进行完善和补充,找出其中的瑕疵或遗漏之处,锚定用户对业务和系统真正有价值的需求,建立系统需求的逻辑模型。

需求定义是需求管理的核心部分,通常是指需求人员使用自然语言对需求进行恰当描述,并按标准的格式进行需求产出物的输出。

在交付过程中或交付完成后,需求验证会分阶段地审查和验证需求交付物是否正确,是否完整地表达了用户对软件系统的需求。

需求改进是指在需求验证、交付完成或用户验收过程中发现实际交付物和需求定义不符合,需要对需求进行改正,以满足需求定义的要求,同时需要防止需求人员在未来的项目中犯同样的错误。

3.2.4 需求管理和 DevOps 的关系

DevOps 的价值体现在价值的交付。价值的覆盖范围是企业级或组织级。在 DevOps 的定义中,提升组织级的效能和质量是手段,而根本目的是实现企业的精益运营和 IT 的精益运行,因此,需求管理是 DevOps 价值中关键的一环。

通过 DevOps 对接舆情系统或知识获取系统获取业界或竞品的信息,然后通过需求管理流程和市场管理流程,最终将准确的需求传递至 IT 组织。需求管理流程、市场管理流程和交付管理流程之间的流程逻辑如图 3-6 所示。

图 3-6

和其他能力子域不同的是,需求管理主要承接业务的需求,并将业务的需求转化成 IT 组织的生产物料。在这个阶段,端到端的协作主要是从业务端到 IT 端的承载。 DevOps 需要帮助需求管理完成需求精益的提升,需要帮助需求管理者实现知识的传承,需要帮助需求人员提高需求创新的能力,更需要通过流程驱动和数据驱动实现需求管理的精准和过程感知。

在交付过程中, DevOps 具备快速进行信息传递和资源共享的特性,同时具备矩阵管理和复杂的交叉汇报关系的特点,因此,通过 DevOps 的特性进行需求渐进管理和实现双向的需求传递。精益需求理论中也阐述了这种方式。需求精益管理是敏捷的一个方面,我们可以将其理解成一个分支或一种配套方法。在实际的需求管理过程中,如果需求管理仅由某个能力子域或组织完成,那么会形成单向闭环,从而导致需求不断地从反馈阶段进行更改,最终导致整体计划崩溃。在双向传递过程中,对需求的每一次观察、判断、决策和行动,都需要建立不同等级的反馈机制,这主要是为了确定需求和论证需求,从而保证最终的需求质量。双向传递过程的反馈机制如图 3-7 所示。

基于 DevOps 的资源管理功能可以实现与需求管理中的价值预估的结合,这样有利于需求的驱动。驱动方式包括计划驱动(主要由价值交付的流程驱动进行适配)和价值驱动(主要由价值交付的数据驱动进行适配),二者的区别如下。

图 3-7

( 1 )计划驱动一般关注任务的全局和关键节点。在以项目批次为基准的流水线中,需要确定任务的时间域和范围,然后由范围来控制每个能力子域的参与成本和参与时间。最终,通过流程方式进行计划驱动。这是项目管理中常用的一种方式。

( 2 ) 价值驱动是指在需求管理中根据业务价值在既定的成本和时间内进行资源的适配。 通过双向沟通和快速迭代的方式与业务方进行需求的锚定,最终保证需求的达成和最终业务价值的变现。同时,根据资源情况来推动需求的敏捷。在敏捷交付和持续交付中,价值驱动使用的场景较多。

## 全部连载
《DevOps权威指南:IT效能“新基建”》-前言
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.1)
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.2)
《DevOps权威指南:IT效能“新基建”》-认识DevOps(1.3)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.1)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.2)
《DevOps权威指南:IT效能“新基建”》-支撑管理(3.3)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.1)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.2)
《DevOps权威指南:IT效能“新基建”》-DevOps的度量体系(8.3)

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广