Agile DevelOPMent for Mechatronics Products? 机电产品的敏捷开发？ 原文 by Chad Jackson; 翻译 by 咋不乐
“We don’t have enough engineers.” That’s was the takeaway headline, according to a Computerworld article, from Obama’s speech back in the middle of June. For anyone that’s been tracking the STEM shortfall issue, that might not come as a terrible surprise. Yet there was one other issue I came across in this summary that did surprise me. Here it is. “我们没有足够的工程师” 这是奥巴马在六月中旬演讲中（发表在Computerworld article）的一句话。对关注STEM短缺（Science, Technology, Engineering and Mathematics Network.）问题的人来说并不是个令人吃惊的消息。但是我的确碰到了另外一个让我吃惊的东东，看一下吧： “The U.S. had just over 1.9 million engineers in 2010, according to Labor Department data. Software engineers make up nearly half of that total.” Of course, today’s products not only include embedded software, most of the innovation and investment of any product development venture is in the embedded software. In the end, however, the ultimate task is to get systems of mechanical items, electrical components and embedded software to work together. While the mechanical and electrical design processes may not have changed all that much in the past few deCADes, software development has. And the question on my mind is this: could those advances be applied to mechanical, electrical or system design processes? “根据劳工部的数据，美国在2010年已经拥有190个万工程师。而软件工程师将近一半。” 当然，今天的产品不仅仅包括嵌入式软件，但大部分的资金投入和创新都在嵌入式软件上。最终的任务是将机械部分，电子部分和嵌入式软件部分搭配在一起运作。实际上机械和电子在过去的十来年里没有很大的发展，这与软件的发展相反。我脑子的问题是：软件业的发展经验是否可以用于机械，电子和系统的设计。 What is Agile Development and SCRUM? （敏捷开发和SCRUM是啥东东？） I don’t think the concepts of Agile Development need too much introduction, but just to set a proper baseline, here’s some short excerpts from wikipedia that summarize some of the main points. I’ve clipped these together for brevity. To get the full scoop, head on over to the entire wikipedia entry on Agile Development. Agile Software Development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The Agile Manifesto introduced the term in 2001. 我相信我要花费过多的时间来解释敏捷开发，但还是得设定一个“基线”，下面来自wikipedia的节选总结了几个要点。我将这些要点罗列在一起。希望得到详细的信息的话，请点击entire wikipedia entry on Agile Development. Agile软件研发是一些列基于迭代和增长的研发方式的整合。客户要求和解决方案贯穿跨部门和自我管理的团队。Agile Manifesto在2001年引入这个概念。 The main emphasis of the Agile Software Development method are the following. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 敏捷软件研发强调的观点如下： 个人的交互而不是流程和工具 可运做的软件（working software）而不是具体的文档 与客户协同而不是合同的讨价还价 及时回应变更而不是遵循计划 Here are some of the major characteristics I think are most important. Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders… 下面是我认为最重要的一些特征。 敏捷方法会将任务分解成比较小的计划，而不是长期的规划。迭代往往会花费比较少的时间（通常是一到四周）。每次迭代都包含软件生命周期的流程：规划，需求分析，设计，编码，单元测试，接受度测试（为相关人员中做演示时）。 Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members… Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication… 敏捷项目团队的构成是跨部门的，自我管理的。而不会去考虑企业的管理架构和每个成员的职位Title. 敏捷方法强调在同一个办公地点，采用面对面交流而不是利用各种文档。大部分的敏捷团队在一个公共的空间办公（称为牛栏），这样有利于沟通。 No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions… Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are… 不管研发的流程是咋样，每个敏捷的团队都会包含一个“客户代表”。这个人由相关人员任命，代表他们并致力于提出中途的问题以便于任务的迭代。。。 大部分敏捷开发都会采用每天面对面的交流，包括用户代表和外围感兴趣的观察员。在日常的晨会中，团队成员相互报告头一天的工作进展，接下的一天的计划和遇到的困难。 Compared to the traditional processes and procedures associated with mechanical, electrical or system design, these characteristics sound dramatically different. But it’s hard to argue with the popularity of these processes. Agile development and it’s offshoots like SCRUM, paired programming and the like are widespread in the software application industry. Furthermore, they’re increasingly widespread in traditional product industries like high tech, automotive, aerospace and defense and others. I guess the last and most important point here is that this process is effective. It enables organizations to stay on schedule, control scope creeping, control costs and solve problems at an incredible rate. 传统的机械，电子和系统研发都有比较传统的流程，这些流程和敏捷的理念看似有很大的不同。对这些流程提出异议是件很难的事情，但是敏捷研发（和其分支，比如说SCRUM），协同编程等方法已经普遍被软件行业接受。甚至它也渗透到到传统行业的研发，比如高科技电子，汽车，航空航天和国防等。我想最重要的一点是敏捷的流程是很有效的。它使得整个组织都与计划，任务范围，花费时刻保持一致并有效地解决问题。 Analogies to Mechanical, Electrical and System Engineering? ( 机械，电气和系统工程从中的借鉴？ ) So what would it look like if we applied these concepts to mechatronic products or systems? Let’s take a look. 那么假如我们将上述的理念用到机电产品（或系统工程）中的话，会怎样呢？让我们来看看吧。 Going Old School? (回到从前) When thinking about Agile in the context of broader mechatronic products, the concept of working software as the end game is equivalent to working sub-systems or systems. This would almost necessitate integrated teams of mechanical, electrical, software and system engineers. But this isn’t just about getting those individuals together, but getting a working prototype of the subsystem or system actually functioning. Lots of companies have processes and procedures for NPDI and the like but that equivalent doesn’t necessarily have to be brought down to the lower levels of product development. In fact, from my impression of Agile Software Development, the attitude should be more like let the chaos ensue and solve problems as they arise. Ultimately, this actually reminds me of old school design. Back in the day, engineers and designers weren’t locked to their desk. They were most likely to be found on the shop floor or test lab, tinkering and experimenting with physical parts in their hands. 当我们讨论机电产品的敏捷开发时，作为最终产品的working software就像是是机电产品中的working 系统或子系统。 这需要将机械，电气，软件和系统设计的工程师联合在一起。但并不仅仅是将这些人聚集在一起，而是将产品系统或子系统的原型及时运作起来。很多公司都有自己的“新产品导入（NPDI）”流程，但这类流程没有太大的必要深入到具体的底层开发。实际上，以我实践的敏捷开发经验来看：允许问题不断出现；出现后去解决它。这些都让我想起了以前时代的设计。那时候，工程师和设计师并不是固定在办公桌前，他们更多时候是待在车间和实验室里，亲自抓起零件来调修。 But does that mean less actual design time? Does that mean less time in front of CAD and CAE? Ultimately I’m not sure how it would play out in terms of exact amounts of time, but I do think the activities would change. The urgency would be on getting the subsystem or system in the test lab as soon as possible to enable fast failures, fast changes and fast experimentation. 是不是说这就意味着较少的设计时间呢？是不是意味着花在CAD和CAE的时间会比较少呢？实际上，我并不了解时间上改变的度量，但是研发的流程及安排改变了。最重要的一点就是尽快将系统或子系统放在实验室做“失败分析”以便尽快地做修改及进一步的实验。 There’s No ‘I’ in Team （在团队中没有“我”） Another major emphasis with Agile Software Development is on face-to-face interaction and a de-emphasis on documentation. The whole idea of capturing and documenting everything that was said or how decisions were made aren’t at the forefront. What I find most interesting about that is how it cuts across the traditional accountability culture of engineering. In the old days, when an engineer signed off on a drawing, their reputation was on the line. If something went wrong, managers and executives would come to that individual. Of course this led to a lot of conservative decisions over the years, but that was engineering for you. The Agile way ignores that individual accountability approach for the sake of a more team-based and consensus building approach. I guess the team could be held accountable but I think that’s besides the point. The idea here is adaptability and speed. 另外一个关于敏捷制造的重点是面对面的交流和弱化文档交流。扑捉并归档所有的信息，并基于此作出决策变得不是很重要了。我看到这里面一个有趣的现象，就是把以前传统的“信用文化”给肢解了。以前，假如一个工程师签署了一份工程图的话，他是堵上了其名誉/可靠性。后续出现问题的话，经理和高层会找到那个负责的人。这样的“信誉文化“会导致保守的决策，但是要记住这是工程问题（而不是政治问题）。敏捷方法会摒弃个人的“可靠性”，而更倾向于团队的共识。我想整个团队应该对其负责，但这并不是问题的重点。更重要的是对问题的适应性和执行速度。 We Don’t Need No Stinking Schedule! (我们不需要,拒绝又臭又长的计划) That title is a little bit in jest. But again, it’s all about where the emphasis is placed. Tasks are broken into minimal tasks with little emphasis on long term planning. I think I can hear many an executive’s blood pressure rising right now. And I have to admit, I am unsure how this might apply to broader product development myself. 这个标题有开玩笑的成分。还是要强调一下重点：放弃长远的规划，将大任务分成成个个小的任务。针对这句话，我已经可以想想到很多高层的血压上升了。我也怀疑这个观点是否可以运用到更广泛的产品研发中。 In the software application world, conceptually there is an infinite list of enhancements and bugs to be addressed over an infinite number of releases. Software applications are almost like living things that grow over time. That strikes quite a juxtaposed image compared to traditional products like cars, planes and industrial machines. Sure, you can enable all of those things with internet connectivity and update them wirelessly. But for you to ship those products you have to have at least one formally working configuration. And while the same applies to the first release of a software application, with traditional products the hardware in the first shipping product might never change. So there is at least some part of that configuration that as an engineer you assume it is locked. 在软件行业，针对无尽的小版本总有数不清的bugs要修补，数不清的功能要加强。软件运用就像是个活着的生命体在不断成长。而与传统的产品如汽车，飞机和工业机器形成了鲜明的对比。当然，你可以将这些产品用互联网连接起来，并用无线网络进行升级。但交付的这些产品至少得有一个正式的配置（硬件及软件的匹配）。当然这些是适用于运用软件的，不一样的地方在于传统产品的硬件是不太可能改变的。所以作为工程师，你必须要了解到这个配置中，有一些是被锁死的。 Summary and Conclusions （总结） Embedded software is a major piece of traditional products. A lot of resources and budget are now being dumped into the hiring and support of software engineers. There are a lot of intriguing characteristics of Agile Software Development. It seems like some of them apply to mechanical, electrical and system engineering. But there are others that may not translate very well. Time for you to weigh in. Has your company tried to adapt Agile methodologies to other engineering areas? What worked? What didn’t? Weigh in and let us know what you think. Take care. Talk soon. And thanks for reading. 嵌入式软件已经变成了传统产品中重要的一部分。厂商会投入很多资源和金钱来雇佣和支持软件工程师。软件的敏捷开发有很多发人深思的特征。似乎有一些观点是适用于机械，电子和系统工程的。但另外一些似乎不是那么回事。 是时候权衡了，你的公司是否尝试在工程领域采用敏捷方法？哪些有效？哪些无效呢？思考一下，让我们了解你的想法。 谢谢阅读！！ |
