工厂自动化设备的敏捷开发
最近公司在推广SAFe（规模化敏捷框架），所以我也开始思考敏捷开发对于自动化设备开发项目是否适用，能带来哪些价值。
首先我们来回顾一下非标自动化设备的开发流程，以及每个阶段我们会遇到哪些问题。
需求确认。需求可能来源于内部客户，也可能源于外部客户，本文不作区分。设备开发团队希望需求在项目开始前固化下来，但是现实是客户给出的这些需求很多时候也是拍脑袋决定的，他在开始时也不知道自己的确切需求是什么。结果就是伴随着设备开发的推进，客户的各种隐藏需求逐渐增加到项目中（就算之前签字确认了也没用）——已完成的设计要修改，项目费用可能要增加...对立情绪开始显现，甚至出现激烈的矛盾。
概念设计。这个阶段，方案设计工程师开始根据自己的理解进行方案构思和表达。往往方案需要反复修改好多版本，时间和精力花费很多。
详细设计。这个阶段的设计成果，现在除了机械设计有3D模型可以呈现给客户外，其余电控系统的设计对客户是几乎不可见的，也就没法反馈。而机械设计的成果，就算有3D模型，对客户而言也仍然不够直观。此时，自动化工程师们（包括机械、电气、软件开发人员）偏偏都很自信，而且还都具备埋头苦干的精神——根本不与客户沟通确认，各自完成设计后就开始物料采购、组装调试。
采购备料。这个阶段，采购工程师按照BOM要求开始询价、下订单。此时容易遇到的问题是，前期设计阶段用到的某个标准件价格太贵，或者交期太久...这时就要回到前一阶段进行设计修改。
组装调试。漫长等待之后，终于凑齐各种物料开始组装了。拆开零件的包装，突然发现标准件的型号不对，或者数量不对，或者机械加工件的图纸尺寸标注错误。这是机构工程师最无地自容的时刻，自己设计上的失误集中暴露了出来。
生产测试。设备组装完毕，各个功能单元也通电测试完毕，接下来就开始测试完整的生产流程了。各种设计问题开始显现，包括结构设计的缺陷、电气系统和控制逻辑的缺陷。而在此阶段，由于设备已经成型，而且基本动作流程已经实现，客户在现场看过之后，往往会对自己的需求有了新的理解和更准确的认知，因此也最容易提出需求更改和补充。
验收交付。终于熬到交付了，可以再跟客户收一笔钱了。但是设备刚运到客户现场，各种小毛病和问题又纷至沓来，不得不派出工程师到现场再调试和解决问题。
敏捷方法论的核心是，认可需求是会改变的。而为了适用需求的改变，开发团队要把一个长期开发任务分解成一系列的小任务，便于快速实施和交付。这一系列操作的目的，都是为了降低需求改变带来的不确定性，以最小的代价满足变幻不定的需求。
上述自动化设备开发流程及其中遇到的问题，能从敏捷开发的方法论中借鉴什么呢？
首先，与其抱怨客户不停地改变需求，不如接受它，也就是认可需求是会改变的。所以在上述开发流程的各个节点，都应当增加与客户沟通确认需求的动作，不断引导和发掘其潜在的、隐含的需求。如果不认可需求是可改变的，你可以一意孤行地完成设计、组装、调试，但无法完成验收交付。
第二，长期任务的分解，以及快速实施和交付。这里的分解，可以理解为在设计、调试等过程中增加与客户沟通的频率，经常向客户展现近期实现的一些进展。不要想着憋一个大招，给客户一个惊喜，也不要怕麻烦客户——每周给客户汇报一个小进展，确认一下你们是否还处在相同的方向。因为非标的东西，很多都是创新性的，双方都没有完成和清晰的认知，此时如果开发的方向偏离了客户需求，那么必然导致损失。
第三，专职的项目经理。敏捷开发框架对人员角色、沟通频次和形式等都有规定，这样有利于项目的实施不会偏离预定的轨道。对于自动化项目来说，专职的项目经理是必要的——除了熟悉项目管理的流程、工具，项目经理还要代表客户需求，保证技术开发人员的交付成果是符合客户期待的。而很多中小型的自动化集成商，要么项目经理太弱势，只是扮演助理角色；要么干脆没有专职项目经理。
第四，沟通频次和形式。对于沟通频次，在设计和调试阶段，也同样推荐每天15分钟的“站会”，让团队成员快速了解彼此的进展和问题。尤其在调试阶段，技术工程师很容易深陷在自己的技术领域内，只见一隅而忽视全局；又或者是麻痹大意，冀望于客户不发现问题。此时较好的做法，就是让开发团队每天抽一些时间站到设备旁边，现场回顾进展和问题，及时纠正偏离的方向，弥补错误，解决问题。
以上我对SAFe以及敏捷开发的理解可能并不全面和准确，毕竟接触时间不长。但是我对非标自动化设备项目开发流程及痛点还是有切身感受的，在对照敏捷开发的理论框架后，也就想到了上述一些可资借鉴的理论、方法。
希望我个人的这些总结，能对大家有所启发。欢迎交流讨论。