上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之。不笑不足以为道。–《道德经》

软件工程从原始的作坊式工作方式，经过了哪些思考、哪些方案的试探，才在不断地尝试与改善后，走到现代化的工程过程？在升级的道路上，经历了哪些挑战，以及针对这些挑战做了哪些方案，这些对于真正践行敏捷工作方式具有重大的指导意义。本文将对比作坊式开发过程与敏捷开发过程的区别，以实例的方式来总结这两个过程管理中的提升点。

作坊过程方式（无组织式）

在这里插入图片描述

对于大多数公司来说都有一套完整的研发流程，以支撑公司的研发体系。这样做最大的优势是可以保证各个团队的行为规范的一致性，继而保障质量、速度、规范性的一致性。而作坊式的过程管理一个很大的特点就是各个团队之间没有统一的研发流程，导致更多细节性问题暴露。

阐述过程分先后，但作坊式的过程管理的问题并不是先后出现的。而是并发发生的，所以这里的陈述顺序不影响问题的优先级和问题发生事件。下面讨论一下作坊式的过程管理中会遇到的问题。下文中以抽象总结出的结论作为章节标题，再以实例来说明标题。

｜边界模糊

边界模糊说明两件事：业务边界模糊，时间边界模糊。这两个模糊边界会导致投入的人力未知、质量问题收敛速度未知。所以，项目管理铁三角缺一项就会影响质量，作坊式过程中会缺三项可以说是没有做过程管理。

1. 业务边界模糊

业务边界模糊可以从几个方向说明：

业务需求过大导致的边界模糊在做过一个从零到一的 OAM（Open Application Model）的迭代过程中，需要对 OAM 建立 GUI，YAML 配置，版本过程，发布过程等等。每个过程都有无数的细节，例如：在控制应用下的副本数的时候不填代表什么？填0代表什么？填数有代表什么？再比如：在 OAM 中逻辑概念有十几个，每个逻辑概念可以作为一个逻辑实体。逻辑实体之间的关系会形成三联实体（三个实体之间的特定关系），有甚者会有四联实体。在这样复杂的场景下总会漏一些在前期需求澄清时总有未想到的细节点，最终都遗留到线上才发现也是有的。

业务澄清模糊导致边界模糊在做业务澄清时，因为是BA/产品给研发/测试进行讲解总会遇到澄清过程中基于现有的需求理解为某个特性确定为一个方向。但在开发过程中或业务上线后会意识到这个问题不应该在这个方向上，而应该在另外一个方向。例如：K8s 的资源管理器Helm界面上支持环境管理不需要支持依赖中的 values 文件作为指定文件，但后来需要支持。

版本发布导致的业务边界模糊私有化部署要做版本化，然后在发布 Saas 产品的时候又要归到版本中。在这个过程中 Saas 线上用户报的工单，Saas 线上用户的简单需求。到底应该在哪个版本来同步到私有化部署的版本中。因为 Saas 线上客户的需求，工单是需要放在当前线上的版本中的。这样就导致线上需求会上多个版本，如果版本会有一点不同那么就会造成版本差异问题。

2. 时间边界模糊

时间边界模糊可以从几个方向说明：

不做工作量评估，或以人员能力来做工期评估作坊式过程管理是将工作交给某个人或者交给两个人去做即可，具体什么时间做完做成什么样就没人去管了。

因为业务边界模糊导致，交付时间不确定。任何时候都可以插入新的工作，导致每个人手中的工作越堆积越多。然后再推导出插入进来的工作先做，前面接手的工作又被延后了。从而导致手中重要的工作一直向后延期，而又无法推动上线。

过大的开发量，导致评估不准确过长的开发周期直接上线，导致很多点未测试完全，问题遗留到线上解决。问题定位都有可能忘了细节在哪里。

团队协作私有化部署与 Saas 服务不同，私有化部署必须在某个时间点对齐功能之后再打版本。这样就会形成团队间协作。一般作坊式工作坊中不会在团队间形成时间对齐理念，因为没有 PMO 来对齐与跟踪这部分。

｜独立个体大于团队协作

在作坊式过程的团队形式比较恰当的比喻是团队是一个职能型组织。职能型组织最大的特点是相互独立，专业化团队。在作坊式过程中这样做其实会发生更多的问题，例如：某部分工作再一直堆积而又没有办法加快进度、信息不足导致开发过程的验证不足从而导致质量飘忽不定、同时开启的工作事项越来越多失去重点。

1. 协作过程不通畅

团队关系以单个成员独立完成为主，不评审，不检查，不回顾。在这个过程中就会发生信息同步不通畅，无法说明的工作内容与进度，单个成员负责特定业务的问题。

信息同步不通畅一个很简单的例子：OKR 的拆解过程需要从团队的 KR 拆解为团队成员的 O，在用团队成员的 O 进行具体的KR的拆解，这样会形成KR 又下层的 O 来支撑这个过程。但是在作坊式的团队中虽然使用了比KPI更加现代化的 OKR 来完成团队目标的制定，但是没有做拆解过程，没有目标来源的讲解过程。那么团队的目标就没有办法落地到每个团队成员中，这样就造成信息不通畅问题。另外，信息是一种非常重要的资源。当之后某几个成员掌握特定的信息后，他们就可以把信息作为利益交换资本。这样特定成员手里就多了筹码可以跟他人做利益交换。这样的事情多了是不是就很像传统的国企做事风格，要给某些不舔上级的团队成员穿小鞋的时候这个信息差就可以做到一些不利的事情。这是一种在作坊式工坊中的生存方式。

无法说明的工作内容与进度只在业务上说明一个大概要做的事情，再加上业务模糊问题。在不进行评审与设计，工作拆分的情况下就无法说明具体工作内容，无法跟踪工作事项中的进度。可以在开发过程中来整理是否做过设计，设计评审，工作拆分，工作量评估，工作跟踪等事项既可知道是否已发生这个问题。

单个成员负责特定业务职能型组织一个特点就是特定的团队完成特定的业务。而在作坊式团队中一个成员负责一块业务，然后如果这块业务最近不需要开发或维护则负责这块的团队成员就闲下来了。了解最多的业务模块的成员永远最忙。无业务备份团队成员概念。

2. 同时开启的工作事项越来越多

在开发过程中不设置阶段（里程碑）、不设置目标，从而把团队工作作为一个任何内容都可以插入的，都有必要插入的。在这样的情况下一个团队不管是 two pizza 团队还是更大的团队，只要是根据这样的规则就会一直开启新的工作项。作者在工作过程中见过一个团队同时开启十几项事务。例如：线上问题修正，KA 客户支撑，代码安全扫描问题修正，性能优化，客户小需求几个等等都同时开启。

在这样的情况下，主要特征是规划与执行有问题。规划过程与执行过程无法对齐导致了只做了紧急不重要的事，而做不了规划中的事项。

3. 丢失焦点

丢失焦点便是为什么叫冲刺的根因。前面说到时间边界模糊，再加上上一节说到同时开启多想工作项。再加一个无周期的环境中又开启多个事项，而不是团队专注于一件事在固定周期内解决这一件事来保持阶段的专注性。这样导致团队成员都很忙，但是又没有完成更多的事情。从而降低成员成就感，并对职位晋升有较大的阻碍。因为职位晋升需要阐明在一个周期内为团队、为公司做了哪些贡献，在作坊式过程中做事既琐碎有误目标总结为贡献就会很难。

4. 任性的成员越来越多

团队目标缺失导致团队成员没有行为规范。没有行为规范各个成员就会按照个人理解对代码，开发规范进行实施。在开发过程中就会发现A想这样，B想那样最终就看谁更强硬。而不是看团队整体的目标输出价值，还是稳固质量就开始做自己的事情。导致各做各的，由此任性的成员就从这里出来。

5. 独立个体大于团队协作

事情堆积如山，再来新的事情必须排队进行。因为事项同时开启过多，导致每个成员要做的事情都是不一样的。每个人头上都是一堆事要做，而每个事情都有不同的头需要去牵扯出来再做，所以，没有办法去做。

｜无过程CheckPoint

因为没有里程碑的制定，就没有办法 check 计划执行情况。无法跟进进度的情况下很容易造成相互职责，相互不信任的过程。进入负反馈循环之后就会造成团队在泥沼中越陷越深，再加上作坊式过程无法完成自我改善。

无视风险技术风险、进度风险，在前期识别过程中没有过程与方法来提出。在中期没有 CheckPoint 进行识别。后期进行无回顾与总结更无法在后期回顾风险。从而在整个研发过程中无法进度测量和结果评估需要不同的方法。

无视质量在作坊式工作过程中，工作事项会堆积如山。而在这个时候质量的劣势就更加凸显，在质量的效果不可显示展示出来。所以，就会极力的压榨质量的投入。例如：开发完成测试用例编写，开发完成测试工作，开发完成验收上线工作。这样很容易造成陷入固有思维陷阱，导致问题在线上暴露。

运动式管理作坊式管理就是没有规矩，想一出是一出。例如：前两天发现线上问题比较多，然后就开始问质量人员为啥没测出来。过两天线上问题少了就又忘了这一出。再跟上没有过程改进，复盘又无法做到根因分析。所有的过程管理都流域表面无法解决根本性的问题。

｜结论

初步总结一下作坊式过程，其实还有很多事情无法深入讨论。例如：这样的团队中的成员对于过程管理的认知是什么样的？这样的团队中文化是什么样的？

1. 难以响应外部变化

永远在响应变化，那就是没有响应变化。因为永远响应变化那就没有时间去做自己应该做的事情，例如 OKR，KPI 事项。而在根据 OKR 引申到要支撑的业务方向的变化就更难进行支撑。

2. 质量信心缺失

因为无视质量，所以新开发的内容上线，线上什么时间出问题都保持迷惘状态。从而需要时时刻刻都要保持警惕，然后以人力的方式老保证系统上线故障的解决。

3. 进度对齐工作无处可做

进度对齐包括团队内部对齐，团队间对齐。一方面因为信息沟通不畅，另一方面因为不进行规划，再加上每项事都是单个成员独立完成。几乎各个点都有可能影响进度，而这些点又没有对齐所以风险更高。

4. 导出结论：不要合作，想怎么干就怎么干

从上面的现象描述过程中可以看到，软件开发的团队合作几乎没有。为了不守规矩想怎么干就怎么干。

敏捷方式

在这样的团队中既无输出有无成果还每时每刻都要提心吊胆的盯着线上是不是有问题。而且不会有张弛有度，只会一直的在做紧急的事情。看完上面的内容是不是感觉很无力，很不理解怎么做成这样。从软件开发领域的基本规则作者推导出一个更一般性的规则：理清事物之间的关系，描述清楚事物的边界，剔除不必要的内容，添加必要内容；遵循这个规则才能更好的做成事。

｜自组织团队

代码使用团队所有制而不是独立个人对业务这种形式，应该是以团队所有制的形式来管理代码所有制。

最好的架构、需求和设计出自自组织团队更多的团队自主权，团队群体决策。这样的方式可以提升团队整体凝聚力与责任心。

｜小步快跑

将大的无法评估的工作，拆分成小的工作。并以明确小工作的目标，以小工作来组成项目。这样即设置了里程碑，又可以进行 check 。这就是完成冲刺的第一个概念周期。

｜目标明确

由 Sprint Backlog 来明确迭代目标，以 Product Backlog 来明确产品目标。这样就有了冲刺的另一个概念目标。

｜敏捷实践

敏捷过程中可以用各种各样的形式的工具去管理整个流程。而在过程管理中以统一，完善的方式去做一个敏捷过程。CODING 提供了一整完整可用的方式对敏捷过程管理。

1. 有效的管理需求

在 CODING 中可以使用史诗级任务看板来管理需求。可以有效的管理需求的优先级，并可以根据优先级在迭代中选择 Sprint 任务。这样迭代的边界可以在选择 Sprint 任务的过程中变的清晰，并在迭代启动会中澄清时间边界。

在这里插入图片描述

2. 有效的工作量的评估

在敏捷迭代过程中，可以对 Sprint 任务进行拆分，并对拆分的工作进行工作量评估。这样可以很好的控制进度风险。保证迭代工作可以低延时的交付。并评估工作量的过程是开发团队公认的，在团队内形成共识的。相当于团队中每一个成员对外的承诺。提升团队成员的参与感。

在这里插入图片描述

3. 有效的度量

团队过程改进在作坊式的过程中都是运动式的。没有固定的时间点，没有固定的会议在 CODING 度量中可以看到有效的了解团队中的开发速度，交付速度。对于影响开发速度，交付速度的内容一眼就可以看到，以过程数据量化展示的方式给团队提供过程改进的依据。

在这里插入图片描述

｜结论

最简单的事才是最难做的。就像以敏捷方式来解决作坊式的问题看似简单，但只有在真正理解和实践敏捷开发的核心价值观和实践方法的基础上，才能够在解决作坊式问题时发挥出敏捷的真正价值。

总结

软件工程是以工程化方法规范软件开发，按步骤和流程进行软件开发，保证软件项目成功交付。上世纪 60 年代，IBM 开发 OS/360 操作系统，这是第一个超大型软件项目，非常复杂。当时，共有 1000 名左右的程序员参与其中，该项目总投入工作量高达 5000 个人年，但最终却无法运行，以失败告终。而项目负责人 Brooks 博士总结经验撰写了《人月神话》一书，使得该书成为软件工程领域的经典之作。

尽管发展多年，软件工程仍然是一个充满挑战和机遇的领域。相信随着技术的革新和应用场景的拓展，软件工程将迎来更为广阔的发展空间。