InfoQ技术大会双节活动折上折,满10000-1000>> 了解详情
写点什么

程序原本(三):开发视角下的工程问题

2020 年 2 月 12 日

程序原本(三):开发视角下的工程问题

编者按:本文节选自周爱民著《程序原本》一书中的部分章节。


集成化工具需要有配套的生产过程和管理

应用开发的“集成环境”(IDE,例如 Eclipse IDE)不是给一个人用的,开发工具公司的“套件”(Suite,例如 VSTS,Visual Studio Team Suite)是为多种角色提供的。但这两点事实,大多数时候为工程人员所忽视。集成环境或套件都是基于工业生产的理念来提供的,这一理念认为:工业生产整体依赖于分工明确的产品过程。因此,开发人员需要代码文本的编辑环境,测试人员需要自动化测试与脚本驱动的工具,构建人员需要包、构件以及面向资源的管理界面,如此等等。


将这一切组织在一起的 Suite 或 IDE,就如同工业生产线上的硬件环境。正如这个比喻所暗示的:在购买这个生产线的同时,也就意味着你需要这个生产线的过程模型与管理体系。大多数时候,我们的应用软件产品开发并不是工具用得不好,而是生产组织与管理得不好。而这其中,“模型”的指导意义尤其被忽略。


MSF(Microsoft Solution Framework)描述了“VSTS 生产线”背后的工程模型,其核心并非来自于技术实施,而是来自对管理 “项目/产品过程”所需要进行的权衡(图 1)1,这与“项目平衡三角(项目管理三要素)”所阐述的问题是一致的(图 2):


1 引自“MSF Process Model v. 3.1”, Microsoft Solutions Framework White Paper。



图 1 项目要素之间的平衡三角



图 2 管理平衡三角


于是进一步地,MSF 提出了三种模型来解决对应的问题,如图 3 所示。



图 3 MSF 的三种模型与项目要素之间的关系


其中组队模型讨论项目创建时的团队、资源、沟通模式,过程模型讨论开发过程的控制与管理方法,应用模型则讨论产品定义、产品实现以及产品特性的管理。当这些模型映射到 Suite 或 IDE 中时,相关的要素就变成了类似如表 9 所示的关系2


2 这种对应关系并非是边界分明的,事实上 IDE 中的同一个功能可能应对的是不同模型中的问题或问题集。



表 1 模型要素在理论框架与集成环境中的关系


这一类工具在“一致性”上的要求与“统一建模”、“统一过程”等思想同出一源。更确切地说,它们是“方法 + 过程 + 工具”这一传统工程模型的具体实践,即方法论决定了过程模型,工具是对方法论与过程模型的实现及其具体实施手段。


但问题在于:是要懂得使用工具,还是要懂得方法与过程?


敏捷工程实践者其实代表了工具精良派的产业工人的声音

集成环境或套件试图通过统一模型来建立整个团队对话、沟通、工作的一致化的界面,但这一过程其实并非依赖或只依赖特定的工具。


敏捷工程敌视那些强行植入开发工具的决策需求、管理需求以及产品需求3,进而否定“管理者、决策者以及产品相关角色”等在这一环境中的价值,并从“形式上”将这些角色推出团队,同时把产品定义与产品品质这些职责直接交给开发人员与用户。但是从根本上来说,它未能否定“过程模型”的价值。因此,大多数敏捷团队在弱化了管理与产品相关职责之后,仍无法摆脱软件工程过程(例如瀑布模型,以及基于瀑布模型的迭代)的约束4,只是他们有空间、有能力去选择更轻量、适用的工具来应付那些决策、管理与产品的需求。


3 导致这一局面的部分的、且并非关键的原因在于:一方面,开发工具中使用 Project、ProjectGroup 等关键字来应对项目规模的扩大,而这一问题延伸到工程模型后所得到的抽象概念却是 Product、Version 以及 ProductLine 等;另一方面,工程工具与开发工具的提供商试图将这些合而为一,但形式上的统一未能弥补概念与领域上差异。


4 这进一步导致了团队无法摆脱既有的公司组织与管理结构,于是实施敏捷变得在组织层面上既说不通也行不通。


除开这些因素,“敏捷”事实上是在探索用户与工程师进行有效沟通的最简方式。这种方式并不是说不要“模型”,敏捷工程师(也包括“不敏捷”的工程师)其实也试图为用户所描述的业务数据与业务过程进行建模5。一部分建模工作是这些工程师“乐于”去做的,通常它们是面向业务的“数据与过程”的。因为这跟编程世界中的“数据结构与算法”有着近乎天然的映射关系6,只是他们将这些工作换了一门“手艺”来做罢了。例如在 UML 中,逻辑视图与实现视图构建的就是这两类模型。而他们“不喜欢”做另一些建模工作(例如完整的业务建模与产品建模),只是因为这些内容与开发工作没法关联起来,因而在他们的工作中是不需要的。


5 例如,正如此前所讨论的,敏捷中的原型事实上也是敏捷工程师与用户之间沟通的模型。


6 你可以想象成开发过程中的“定义数据结构和写函数声明”,以及形式化的流程图与部分逻辑代码。


将 VSTS 等单纯视为“开发工具”是一个根本性的错误。既然这是生产线,那么正确的做法应是明确工程师在生产线上的角色,并将适当的工作交付给他们。但现实是,源于那些错误的认识,一些团队过度地要求工程师在生产线中的职责,反而激化了他们对相应职责的抵制。而敏捷工程与敏捷开发方法,不过是在这样的抵制运动中所诞生的“看起来有点革命性的”产物。


图书简介https://www.ituring.com.cn/book/2429



相关阅读


程序原本(一):应用开发基础


程序原本(二):应用开发技术


2020 年 2 月 12 日 14:001079

评论

发布
暂无评论
发现更多内容

产品经理岗位需求总结

Geek_a32093

产品训练营作业1-李沂秾

克比

如果公司要招⼀个⾼级版你

向日葵

产品经理训练营

产品经理训练营_Chapter1

芃芃

产品经理训练营

第一章学习总结

Kasn

产品经理 产品经理训练营

Dubbo源码解析-开始篇

冰三郎

Java 分布式 dubbo RPC

第一节课总结

Jove

Job Model

·大蕾同学

产品训练营-作业1

简小一

产品经理第一周第二课总结(第一课手贱删除了,回头再补)

克比

HDFS杂谈:数据读写原理

罗小龙

hadoop hdfs 28天写作

极客大学产品训练营作业(第1周)

朱航

ACC是如何实现的(28天写作 Day12/28)

mtfelix

自动驾驶 28天写作

Week1:按图索骥—从JD入手做能力建设

Y.

产品 产品经理训练营 极客大学产品经理训练营 求职岗位要求

应聘&招聘

skylar

三个有意思的产品作业(第一次)

李钊悌

极客时间产品训练营-第一周学习总结(上)

Trigger

极客大学产品经理训练营

第一章作业:认识产品经理

隋泽

产品经理训练营

用户增长产品经理招聘帖

梁媛

产品经理

行业产品经理岗位分析

Shine

产品

产品经理调研备忘录(何先生的梦呓)

小蜜蜂

产品经理 能力模型 产品经理训练营 何先生的梦呓 数据能力

对产品岗位的研究和一些看法

Dylan Zhu

产品经理岗位对比分析

DwToretto

甲方日常 87

句子

工作 随笔杂谈 日常

如何给产品团队更好地提出设计反馈

Justin

心理学 产品设计 团队协作 28天写作

产品经理岗位对比

思亭

在线教育产品经理 & 物流行业的产品经理

哈撒啦岛

产品经理 产品经理训练营

HTML(三)——在网页中使用图像img

程序员的时光

程序员 28天写作

0互联网工作经验的我,面对字节跳动产品岗1723个招聘岗位慌了起来….

Geek_fe4aa7

产品经理训练营 极客大学产品经理训练营

把我自己做成产品交付给目标岗位

havaguday

assignment 01

Jove

程序原本(三):开发视角下的工程问题-InfoQ