第11课:架构设计中的系统工程

第11课:架构设计中的系统工程

从工程学角度讲,软件开发的相关工作可以分成两个维度,即项目管理和过程改进。项目管理从范围、时间、成本等角度出发讨论如何在一定的约束条件下实现系统,包括需求工程、计划和估算管理、质量与配置管理、风险与团队管理等内容;而过程改进则围绕软件开发的过程,提出持续优化的方法和实践确保得到令人满意的结果。架构设计过程中的系统工程实际上指的就是这两个维度,而每个维度都与架构师有关。本篇从系统工程的两个维度出发,一方面给出各个维度的工作内容,另一方面也会介绍架构师与这些维度之间的的关联关系,从而更好的指导架构师的日常工作。

项目管理

项目管理包含一整套知识体系,如业界具有代表性的 PMBOK(Project Management Body Of Knowledge,项目管理知识体系)就是对项目管理所需的知识、技能和工具进行了概括性描述。PMBOK 中包含项目整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和干系人管理等十大知识领域。以上这十大知识领域之间的关系可以见下图。

PMBOK 面向通用的、全行业的项目管理过程,对于软件开发而言,由于一般不涉及到材料的消耗,不需要对成本和采购做专门的管理;人力资源、沟通管理和干系人管理涉及到技术管理者的组织管理和软能力,我们会在下一篇中做这方面的阐述;整合管理的思想贯穿项目管理所有内容,产品和技术之间的融合、系统的集成等都是其具体体现。所以本篇中的项目管理主要针对的是与软件开发和技术管理者日常工作密切相关的知识领域,包括需求管理、计划管理、质量管理和风险管理。

需求管理

如同软件架构,我们对需求进行分析之后会发现其同样具备一定的层次性,层次性的产生原因一方面在于需求抽象的过程,另一方面也取决于需求传递过程中所流转的角色和媒介。从下图中可以看出,业务需求位于整个需求层次的最上层,代表的是客观存在的业务实体本身,反映了组织机构或客户对系统、产品高层次的业务利益和目标要求。但业务实体只有被抽象成用户需求才能被识别,也才能从用户角度被验证,用户需求描述了用户使用产品必须要完成的任务,它们在用例(Use Case)和情景描述(Scenario)中予以说明。系统需求描述了系统中各个方面的需求,包含硬件、软件和其它关联系统,更多站在技术人员的角度看问题,把用户需求转变为可供编码实现的系统模型。

需求的不同层次分别会有不同的需求表现形式,从最初的项目视图和功能范围,到功能用例,再到详细的软件需求规格,需求的粒度逐步细化,而对功能的描述也从纯粹的功能性需求转变到功能性需求和非功能性需求的结合体。所谓功能性需求,指的是项目中具体需要或不需要提供的功能和内容,而非功能需求则代表项目中为满足客户业务需要必须达到的一些特性,典型的包括系统性能、可靠性、可维护性,可扩展性以及对技术与业务方面的适应性。这些非功能性需求的提炼依赖于对功能性需求的充分理解和分析,也是架构师的一项关键职责,我们已经在前面的文章中对这些非功能性需求做了分析和探讨。

计划管理

计划管理可以说是范围、时间、成本管理的整合体,对于软件开发而言,作为技术管理者的架构师最重要的工作之一就是主导制定产品或项目的开发计划。研发计划的制定一方面存在通用的管理框架,另一方面,软件开发活动的固有特性又需要我们对开发范围的分析和开发工作量的估算采用特定的方法和模型。计划管理最重要的工作就是开发范围分解以及开发工作量估算。

开发范围分解技术

考虑到软件开发的固有特性和不同场景,我们认为以下分解方法有助于更好的明确开发范围,并确保开发人员能够在范围管理中起到一定的推动作用:

  • 根据系统集成

很多软件系统都涉及到系统集成需求,包括与外部第三方系统的对接,也包括组织内部各个团队之间的功能或数据集成。在对范围分解过程中,识别并分解这部分开发范围至关重要,因为但凡依靠其他团队才能完成的功能其风险性都会比普通的开发任务大很多。如果系统集成的双方是合作关系,即分别处于上游和下游的两个团队共同进退,那还是比较理想的关系。而如果两者之间是遵奉者(Conformist)关系,即其他团队由于利益关系等因素并不想或没有能力推动系统集成,那么范围分解所得出的系统集成需求就是开发过程中需要重点管理的对象。

  • 根据技术改造

现实中有很多系统属于遗留系统(Legacy System),这些系统中普遍存在很多技术债务(Technical Debt),需要通过不断的重构来改善系统架构。但通常,范围的分解面向业务功能,而不是技术改造,如果处于技术债务较多的遗留系统中,技术管理者就应具备从功能开发范围中提炼技术改造需求的能力,并把它们作为开发范围的一部分展示给所有相关人员以争取开发资源。

  • 根据技术试验

有时候,开发人员无法正确的把控开发所需的技术需求。在这种情况下,可以创建技术预演和试验相关的需求,我们把这种需求称为试验性需求。这种需求通常具备较大的灵活性,因此在范围分解以及后续的计划安排中需要专门考虑。

  • 根据管理成本

软件开发范围分解过程中一个比较明显的特点就是几乎不大考虑管理软件开发过程的成本。实际上,按照 WBS(Work Breakdown Structure,工作分解结构) 规范,管理成本也是一种范围,也需要进行分解。在合适的条件下,技术管理者可以把这部分管理成本作为开发范围的一部分进行分解并补充到范围分解结果中。

虽然本小节讨论的话题是开发范围分解,但反过来,随着开发过程的演进,对一些过度细分的范围也有可能需要进行合并。合并是分解的逆过程,可以按照前面介绍的各种分解思路进行逆推即可。

开发工作量估算技术

开发工作量估算在软件开发领域是一个老大难问题,因为软件开发是一项需要创新的工作,并不能像传统制造业一样容易对工作进行量化管理。一方面软件开发过程中新技术的不断出现和应用,软件本质是复杂和不可见的。另一方面,传统项目进程可以用相近的项目做参考,但软件项目在绝大多数情况下都是独一无二的,缺少可以参考的经验数据。但软估算仍然存在一些典型的估算策略,包括常见的基于分解的自顶向下和自底而上策略、类比策略、代理策略等。基于这些策略,业界诞生了很多估算技术,我们把这些估算技术分成具有普遍适用性的通用估算技术和针对软件开发的专用估算技术。通用估算技术包括类比估算法(Analogous Estimating)、参数估算法(Parametric Estimating)和专家判断法等,而专用估算技术则包括功能点估算法(Function Point,FP)和全功能点分析法(Full Function Point,FFP)等。

质量管理

项目中的质量管理由三部分组成,分别是质量规划、质量保证和质量控制。质量规划(Quality Planning,QP)用于识别哪些质量标准适用于本项目,并确定如何满足这些标准的要求;质量保证(Quality Assurance,QA)开展经过计划的、具有系统性的质量活动,确保项目实施满足所需要的所有过程;质量控制(Quality Control,QC)监测项目的具体结果,判断它们是否符合相关质量标准,并找出如何消除不合理场景的方法。

对于质量管理,架构师需要主导的工作一般是各种技术评审(Technical Review,TR),其主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查,以找出和消除其中的缺陷。技术评审中存在一些典型问题点需要引起注意。

  • 缺少必要的评审

在不同的产品开发阶段需要不同的技术评审,每个技术评审主要关注产品的一个方面。尽管我们可以通过过程裁剪弱化乃至取消部分技术评审,但缺少必要的技术评审是质量问题产生的一个源头。评审过于仓促,或者可有可无,保证质量就需要过分依赖测试。确保该有的评审在执行过程中都应该要有。

  • 产品需求没有二次评审

建议在产品需求中实施二次评审。为了快速适应市场需求,软件开发周期越来越短,产品经理在没有完全梳理清楚产品需求的情况下就召开需求评审会议,导致后期开发过程中出现很多问题,返工的现象比较严重。这种情况在互联网行业尤为常见。二次评审意味着在面向所有开发人员的正式需求评审之前,先可以找部分技术代表作第一次评审,通过第一次评审对需求存在的问题先修订之后再召集所有人开第二次评审。

  • 评审缺乏数据

评审同样需要数据,缺乏评审的历史数据就无法确保评审本身的质量,也就无法对评审过程进行评估和管理,也就无法改进评审。评审数据也是一种过程资产,需要进行维护和管理。

  • 评审节奏无法合理控制

评审会议也是会议,会议就需要聚焦议题。很多评审效率不高就在于会议本身有问题,典型的包括输入输出不明确、缺少主持人或主持人不善于引导、会议不是结果导向也就无法形成有效决策、会议议程空泛而不能收敛、会议虽然能达成一致但没有具体工作安排和责任人制度、即使有工作安排但缺乏跟踪和监控机制、会议相关的资料没有充分准备也没有提前交付到参会人员等。具有上述特点的评审会议很大程度上不会有实质性的成果,开完一次之后还需要开第二次,如果把握不好浪费的不但是时间还是团队的气氛,需要进行分析和识别。

  • 不合适的参与者

这里不合适的参与者往往指的是具有决策权的上层管理人员。这些上层管理人员的个人意见可以主导其他人员的意见,评审会也就可能变成“一言堂”。技术评审会议中应尽量避免这些人员的参与。

风险管理

软件开发的核心风险

软件开发的风险普遍存在,作为技术管理者,可能你能根据你周围团队的现状列举几十种风险。这些风险有些比较容易发现,有些也比较容易解决,我们这里要列举的是软件开发的核心风险,即绝大多数开发工作的失败都与这些风险有或多或少的关联。

  • 不合理的开发计划

软件开发过程中处于首位的风险是不合理的开发计划,这一点几乎无可争议。回想我们前面讨论的开发计划管理,在通用计划管理活动框架中的每一个活动都可能存在不合理的结果,更加不要说由于开发范围分解和开发工作量估算所导致的的误差和错误。

开发技术中存在的误差和错误是致命的,因为这是整个开发过程开展的基础。不合理的开发计划的制定,要不是技术团队、尤其是技术管理者自身对开发任务存在理解不充分或判断识别的原因,要不就是上层管理者对技术的制定起到了决策作用。无论是哪个原因,对开发最终能否按时完成都是一个极大的风险。

  • 不可控的需求管理

从项目管理角度讲,需求总是在不断变化,如果不加管理就会变成不可控。对于需求的变化,技术人员的立场应该是坚定的:如果你需要添加什么功能,可以,但我们的开发过程也需要进行相应的调整,并根据工作量重新制定开发计划并允许一定程度上的变化。显然,技术人员的这种立场能够减低开发过程的风险,但不一定会降低产品交付的风险,所以在现实世界里不大可能出现给开发者足够时间弹性的需求变化。最可能的一种结局是开发范围变了,但时间不可能有相应的变化,然后自然而然就产生了风险。

  • 不稳定的开发团队

在当下的互联网行业,开发人员频繁跳槽已经不是什么新鲜事。在团队研发过程体系和过程资产建设不是很健全的团队下,人员流失是一种高风险,而且这种风险一般很难在计划评估的时候被纳入要考虑的风险范围之内,也不大会有团队会为一个可能但又不确定是否会离职的人安排备份人员。如果离职的是一名核心人员,那么他带走的可能是整个系统的架构设计、这个团队的管理思维以及整个产品的发展愿景,很难在短时间内找到合适的人填补空缺。

  • 不可靠的开发效率

开发人员之间的工作效率存在较大差异(来自人月神话),但是作为技术管理者而言,应该把团队作为一个整体来考虑,尽量减低团队成员个体之间的差异。一个团队的开发效率在很大程度上也受前面所列几种风险的影响。更为重要的是,一个团队中势必需要存在一到两名核心开发人员,如果大家的技术水平没有层次,除非所有人水平都很高,不然也不利于提升团队的整体水平。

缓解风险的方法

缓解风险的方法有很多,最基本也最重要的一点就是要做到“提前”,除此之外,迭代式开发和增量式交付都有助于发现和降低开发过程中的风险。

  • 提前

缓解风险的最好办法就是将各种能做的事情都提前来做。风险本质上是一种带来不良影响的可能性,“提前”能够缓解风险的原理就在于把这种风险尽早变成现实,那么风险也就无所谓风险。当然,“提前”需要环境和各种资源的支持,一般也无法做到提前很多。技术管理者之所以能成为管理者,就在于他的思想和行动永远都要比下面的开发人员快半拍,在别人还没有意识到要去做风险分析的时候已经明白可能会发生什么,从而防止某些风险的发生或者说降低风险发生时的影响。

  • 迭代式开发

风险来自于计划、需求、团队和开发效率,所有这些相关的风险都是不可避免的,那是否有办法在开发过程上对风险进行缓解乃至扼杀呢?答案就是把过程进行缩小化管理,即把一个大而全的产品开发过程划分成一个个小的子过程,每个子过程的产出是上一个子过程的累加。每个子过程因为涉及到的范围、时间、资源都比较少,那么由于计划、需求和团队上存在的风险所带来的影响也就越小。这就是迭代式开发的核心思想。

项目管理与架构师

一般意义上的架构师主要职责在于跟客户或需求分析人员进行沟通后获取客户需求,将面向客户的需求文档变成面向开发人员的开发文档,同时要从功能实现的角度出发来实现系统的总体规划。然而,现实中的架构师可能担当着需求分析和系统建模工作,成为一名业务架构师。同时,架构师作为研发团队的负责人,也需要把控团队的资源、成本、进度、质量等项目管理因素,成为半个项目经理。

对于研发团队而言,理想情况下项目经理负责对外接口,而技术团队负责项目开发工作量的估算,双方协作共同完成开发计划这一项目管理中最重要的中间产物。项目的计划管理其核心原则是“信息不对称”,即在客户和研发团队之间形成信息传递的过滤和筛选机制,确保两者之间的信息不对称从而为项目经理和研发团队把握项目进程提供缓冲并降低风险。

研发团队根据项目实施计划中的研发阶段进行细化分解,按照研发团队中的采用的如瀑布、敏捷等研发过程模型进行时间和人力资源分配。通常按照功能模块和功能点进行研发任务组织,结合系统开发、集成、测试等步骤进行进度安排并形成项目研发计划。项目研发计划的一个重点是系统集成,需要对第三方供应商的研发任务安排有细粒度的计划以确保项目实施的顺利执行。架构师在上述项目管理工作中往往起到主导作用。

过程改进

在项目管理和软件开发过程中,软件过程的各个方面都可以且需要进行持续改进,经典的 PDCA(Plan、Do、Check、Adjust) 环就是一种过程改进闭环管理的方法。从更通用的角度讲,过程改进闭环包括度量(Measurement)、分析(Analysis)和变更(Change)三个主要环节。过程的度量就是收集过程数据,如完成某一特定过程的时间、某个特定过程所需要的资源、某个特定事件发生的次数等都是有效的过程数据。过程分析的目标在于理解过程中活动以及这些活动之间的关系、理解活动属性与度量之间的关系,常见的过程分析技术包括调查问卷与会谈、异常活动触发和深入过程体系内部的实地调查研究。过程变更的过程参考下图,在整个变更过程中涉及到对过程模型的裁剪和修正、人员的培训以及工具技术手段的潜在应用。

CMMI 与过程改进

业界对如何进行过程改进也存在一些方法论和框架,最具代表性的就是 CMMI(Capability Maturity Model Integration,软件能力成熟度模型集成)。CMMI 由一组过程域(Process Area)、一些目标(Goal)和一些工程实践(Practice)组成。通过这些要素的组合形成了五个级别,由低到高分别称为初始级(Initial)、可重复级(Repeatable)、已定义级(Defined)、量化管理级(Managed)和持续优化级(Optimizing)。

初始级中过程没有制度化,过程是无序的甚至是混乱的,几乎没有什么过程经过妥善定义,过程执行情况难以预测。处于初始级的组织一般不具备稳定的开发环境,项目成功取决于个人或小组的努力,取决于精英和个人的经验(见下图 a)。在项目中建立基本的项目管理过程来跟踪成本、进度和功能特性,制定必要的过程纪律,能重复早先类似项目取得的成功,具备这些特征的就是可重复级(见下图 b)。已定义级中,已将管理和工程两方面的过程文档化和标准化,并形成了组织级的过程资产。所有项目都使用经批准和剪裁的标准过程来开发和维护,需要收集数据,也要使用数据(见下图 c)。而量化管理级则使用统计和其他量化技术对项目过程进行控制,建立了质量和过程性能的定量目标,作为过程管理的准则,质量和过程性能度量数据能用于支持决策(见下图 d)。最终的持续优化级基于对过程中性能偏差的原因的定量分析,通过渐进的和革新的技术改进,持续地进行过程性能改进。组织过程改进得到识别、评估和实施,并且全体员工参与过程优化(见下图 e)。

CMMI 关注人、工具和方法,从无序的初始级开始,建立项目记录、建立稳定一致的过程、以事实为依据达到能够不断创新和改进的持续优化级,将企业过程成熟能力分为五个等级。我们在实施 CMMI 过程改进的关键在于将标准开发过程制度化。

敏捷方法与过程改进

敏捷思想中有一条原则指导我们进行过程改进:每隔一定时间,团队会对如何才能更有效地工作进行反省,然后相应地对自己的行为进行调整。由于很多不确定性因素会导致计划失效,比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。敏捷不是基于预定义的工作方式,而是基于经验性(Empirical)的方式,对以上这些变化,敏捷团队通过不断的反省调整来保持团队的敏捷性。与 CMMI 所提供的重量级解决方案不同,敏捷方法为我们提供了针对过程改进的很多简单但又实用的工程实践,这里列举两个作为参考。

  • 五个为什么

5个为什么是敏捷领域比较推崇的一个过程改进实践,原理很简单但确实很有效。所谓为什么,也就是对一个问题点连续以5个“为什么”来自问,以追究其根本原因。当然,这里的数字5知识一种虚数,使用时不限定只做5次为什么的探讨,主要是必须找到根本原因为止。5个为什么的关键在于鼓励解决问题的人从结果着手,沿着因果关系链条,直至找出原有问题的根本原因(如下图)。

  • 亲和图法

亲和图(KJ 法/Affinity Diagram),把大量收集到的事实、意见或构思等语言资料,按其相互亲和性(相近性)归纳整理这些资料,使问题明确起来,求得统一认识和协调工作,以利于问题解决的一种方法。下图就是亲和图的一种表现形式,通过对团队成员提出的想法从“继续保持”、“停止”’和“尝试”者三个类型进行归类。

过程改进与架构师

过程改进主要围绕研发团队展开工作,但可能也包括一些配合型的、非研发团队角色。正规且规模较大的团队中一般会成立专门的过程改进小组,根据团队的现状分析、计划和裁剪过程改进模型,并负责在团队中推广、实施具体的过程改进措施。过程改进小组类似 CMMI 中的 SEPG(Software Engineering Process Group,软件工程过程小组),架构师可以作为过程改进小组的重要一员参与组织级别的过程改进体系的建立。

中小型团队中普遍缺少专业的过程改进团队,项目经理通常是项目管理过程改进域的主要负责人,但正如本篇所述,软件系统工程不仅仅包括项目管理,架构师可以从软件实现角度上为研发团队引入变化从而推进过程改进。

过程改进的目标是改进研发团队的整体绩效,过程改进是一项重要和长远的工作,应该根据组织的发展战略、研发实力等实际情况来梳理过程域和改进方案,并要充分考虑过程改进的成本和效益。对于快速发展的研发团队而言,过程改进的宗旨是提供轻量级的实施方法,针对没有专设过程改进部门的团队现状,可以通过比较低的代价建立合理的开发流程体系,目标是能达到适合当前团队发展的过程能力。架构师如果希望成为过程改进的推行者,应当具备本篇中介绍的软件工程和项目管理知识,再掌握主流的软件开发管理模型和过程改进模型,并进行裁剪和扩充。

下篇导读

系统工程主要关注于架构设计的过程,而系统还是需要人来实现。现实中,架构师通常也是一名技术管理者,也需要掌握沟通、激励、领导等软能力,下一篇我们将讨论架构师所应具备的几项主要的软能力。

上一篇
下一篇
目录