Speed at Scale. Structured Repeatability. Secure Flexibility.

A unified platform for advanced multidisciplinary collaboration

Agile Teams

Agile Teams gives users cutting edge connected design capabilities through a unified, cloud-based platform where speed, structure, and flexibility reinforce each other, instead of competing for priority. Altium Agile Teams brings together the proven design power of Altium Designer, the secure cloud connectivity of Altium 365, and the up-to-date component intelligence of Octopart, then adds an enterprise layer of structure for repeatable processes so that structure doesn’t stifle innovation. Agile Teams also features platform flexibility to adapt to industry change or localize the solution to a team’s unique circumstances. With Agile Teams, hardware organizations can move as fast as a startup while operating with the discipline of a large enterprise.

Filter
found
Sort by
Role
Software
Content Type
Region
Clear Filters
多CAD工程顶级挑战封面照片 多CAD工程:前6大挑战 1 min Blog Users of Competitor Tools 工程经理 Project Leads Users of Competitor Tools Users of Competitor Tools 工程经理 工程经理 Project Leads Project Leads 在理想情况下,每个工程师、制造商、承包商和客户都会使用相同的CAD系统,这样可以大大简化协作努力。然而,产品设计的现实远非如此理想。不同的公司选择不同的ECAD系统,需要在电子产品开发中适应这一点。 即使在同一个组织内,也常见不同部门或分支使用不同的设计软件,不论它们的物理位置如何。这种多样性导致许多挑战,包括错误、混乱、效率低下、努力重复和财务损失。但为什么会这样呢? 多CAD环境的原因 遗留设计 首先,许多组织操作一个主要的CAD工具,但也保留了在多个CAD系统中创建的一系列遗留设计。这些较早的设计仍然相关,通常需要更新或修改以符合现实世界的应用或正在进行的项目。在我们最近的 网络研讨会调查中,超过51%的受访者声明保持多个ECAD工具的原因是遗留项目。 超过51%的受访者声明遗留项目是保持多个ECAD工具的原因。 分散的ECAD工具选择 其次,你可能会遇到有分散团队的组织,每个团队都被授予自主选择CAD工具的自由。这种多样性往往源于过去的收购,新整合的公司希望保持它们已建立的工作流程和实践。 此外,特定团队可能更喜欢使用特定的CAD工具而不是组织的主要选项,因为熟悉度、效率,或者因为他们已经与其他软件和系统开发了自定义集成。切换到不同的CAD工具可能意味着失去这些定制解决方案或面临在重新配置工作流程时的重大障碍。 事实上, 超过40%的受访者承认至少每个月使用一次次要ECAD工具,只有略超过16%的人报告仅依赖单一ECAD工具。 超过40%的受访者至少每月使用一次次要ECAD工具,只有大约16%的人报告仅依赖单一ECAD工具。 设计承包商和制造商 最后,设计承包商和合同制造商的作用不容忽视。这些外部合作伙伴服务于各种客户,需要熟练掌握多种CAD系统,以满足客户的规范、建议和偏好。 多CAD工程的挑战 但是,理解多CAD环境背后的原因仅仅是开始。这些不同的系统显著增加了跨平台ECAD管理和协作的复杂性,原因如下。 #1 文件不兼容 不同的CAD系统通常使用它们自己独特的数据格式,当跨平台共享文件时会导致兼容性问题。虽然许多CAD工具提供文件转换器以适应另一个系统的文件格式,但这些转换器并不完美,尤其是对于复杂设计。转换过程本身可能导致数据丢失、损坏或错误等问题,这可能严重影响设计的完整性。 阅读文章
敏捷硬件开发封面照片 为什么原则是正确的,但策略需要重新思考 1 min Blog Simulation Engineers 机械设计工程师 Project Leads +7 Simulation Engineers Simulation Engineers 机械设计工程师 机械设计工程师 Project Leads Project Leads Test Engineers Test Engineers 工程经理 工程经理 在我们揭秘敏捷系列的最后一部分中,我们将探索硬件开发与敏捷方法论交汇的复杂领域。虽然敏捷的核心原则提供了坚实的基础,但当应用于 电子硬件的独特挑战时,重新评估策略变得至关重要。在我们的探索旅程中,我们将揭示敏捷的共同元素和仪式,以及我们如何在有形产品开发的背景下转变它们。 从采纳并持续培养敏捷思维开始 在深入探讨可以将日常软件敏捷实践提升为硬件开发的强大优势的战术调整之前,首先接受敏捷心态的基本原则是至关重要的。一个好的起点可能是考虑 敏捷宣言的初衷,并修改语言以满足硬件开发的需求。下表提供了一个可能的硬件开发宣言。 每个宣言意图的简单总结可能是, "让我们一起合作,采用迭代开发和学习方法,来发现并交付客户真正价值的东西。" 当然,这几乎适用于任何项目,而且在团队深陷日常开发策略时,记住这些基本原则是至关重要的。 方向规划的关键作用 敏捷的迭代特性有时可能给人一种印象,即早期规划不如直接开始重要。然而,在硬件开发中,为了导航复杂的物理和电子产品设计与开发过程,一定程度的前期规划是必不可少的。不要想象它是一个详尽的前期计划,而应该将其视为一张路线图,指导团队通过迭代学习和执行进行开发旅程。 在敏捷硬件开发的早期规划中,涉及到设定明确的目标、定义里程碑以及通过深思熟虑的原型制作和 反馈策略来进行风险评估和缓解。通过这样做,团队可以在敏捷的适应性和成功硬件开发所需的结构化规划之间找到平衡。 将用户故事与工作项分开 正如我们在本系列的前一篇文章中讨论的, 敏捷“大师们”经常敦促硬件团队填充他们的待办列表,用用户故事来定义任务。让我们考虑一个关于硬件的用户故事,并假设你计划开发一台新的叉车。你写下了以下用户故事: "作为用户,我希望能够快速领取我的物料,以便节省移动库存的时间。" 硬件开发者知道该怎么做吗?可能不知道。要解决的问题方面太多了。实施可能涉及叉车的速度、叉装附件的准确性、智能库存感应、库存的方向以及许多其他因素。这些硬件的用户故事应该成为客户目标,而不是 产品要求和工作项,而不是具体的功能或任务。 用户故事在敏捷硬件设计流程中有其位置,用于关注客户的需求并澄清客户试图实现的结果。然而,由于物理产品的用户故事不能直接转化为功能、属性或任务,它们成为开发任务积压工作的起点,而不是积压工作项本身。 原型设计策略:展示进展和成功 阅读文章
关于敏捷硬件开发的常见误区封面照片 大多数敏捷“大师”对硬件开发的误解 1 min Blog Simulation Engineers 机械设计工程师 Project Leads +7 Simulation Engineers Simulation Engineers 机械设计工程师 机械设计工程师 Project Leads Project Leads Test Engineers Test Engineers 工程经理 工程经理 敏捷方法论,源于软件开发领域,被誉为技术行业的变革力量。然而,当我们进入硬件和电子开发领域时,敏捷原则的看似顺畅适应遇到了一系列挑战和误解。在这三部分探索的第一部分中,我们分析了 硬件与软件开发之间差异引起的敏捷挑战。在本文中,我们将检验由敏捷“大师们”传播的神话。 在深入探讨电子硬件开发中的敏捷细节之前,重要的是要澄清,我们的目的不是贬低敏捷教练和顾问。我们认识并感激他们帮助客户获得敏捷方法论好处的良好意图和热情。虽然一些批评可能源于对硬件细节的有限理解,但目的不是批评,而是有效地适应敏捷原则,以满足硬件开发的特定需求。我们的重点是调整敏捷策略,以在这一独特背景下发挥其好处,修改方法但保留原则。 谬论 #1: 你必须保持灵活并适应 敏捷大师正确地颂扬了迭代执行、 反馈循环以及在软件的数字领域中蓬勃发展的快速适应能力的优点。然而,这些原则转移到硬件和电子的有形领域时,引入了一层在纯数字领域中未发现的复杂性。与软件相比,物理解决方案需要“完成”,以便订购零件、制造模具和满足严格的制造需求。敏捷对持续变化的呼吁与硬件的无情本质发生冲突,即使是在游戏后期需要进行的轻微 更改也会产生连锁反应。 作为回应,修改敏捷开发以适应硬件开发需要一种范式转变。这不是关于无休止的修改,而是基于快速学习和执行周期的明智、战略性调整和 原型设计。这些旨在在时间、预算和资源的限制条件下最大化价值。敏捷灵活性与物理产品最终需求之间的平衡需要更加谨慎的迭代计划和对整个项目风险降低的深刻承诺。 谣言 #2: 每个冲刺都必须开发一个可工作的原型 虽然敏捷纯粹主义者经常宣扬每两到三周开发一个完全功能的原型 “冲刺”是实现敏捷的普遍“必须”,但这种方法在面对硬件和电子开发(以及预算)的现实时,其实际可行性就会崩溃。构建某物,展示进度,并使用这个成果来获得宝贵的技术和商业反馈以指导你的下一次迭代的想法是正确的。然而,每个硬件项目都是一个具有自己的目标、依赖关系、领先时间约束、需要创新的领域和风险的独特实体。每个项目都应该有其自己独特的原型制作和学习方法。 要真正拥抱敏捷硬件产品开发,团队必须摒弃一刀切的思维模式。相反,他们必须仔细审视项目需求,然后合作制定一个创造性的、学习性的和原型设计策略。重要的是要认识到,“原型”可以是任何可展示的输出,从初步的宣传册到泡沫模型(就像史蒂夫·乔布斯著名的iPod模型,它能“让你口袋里放1000首歌”),甚至包括部分或完全功能的原型。 神话#3:向待办事项列表添加故事,然后就开始 敏捷方法的一个内在优势在于它们启动项目的速度比传统瀑布式方法要快得多。实际上,对于敏捷硬件电子项目,我们已经看到从概念识别到开发启动的周期显著缩短。这个周期,在传统的分阶段方法下通常需要数月甚至数年的时间,现在通过敏捷方法被压缩到了几周甚至几天。当然,这一戏剧性的结果部分原因是我们如何定义“开发启动”。 在软件领域,这是直截了当的。敏捷大师倡导编写用户故事来定义软件功能,将它们优先排序到待办列表中,并启动一个冲刺。然而,在硬件领域,至少需要一些最初的规划来指导项目朝着正确的方向发展,这需要对架构、关键期望属性、约束以及其他因素有所了解。这种最初的努力似乎与敏捷原则“工作中的软件是进度的主要衡量标准”和“欢迎变更需求,即使是在开发后期”相冲突。 阅读文章
团队协作与PCB设计 团队合作与PCB设计 1 min Whitepapers 曾经有一段时间,一旦电路设计完成,就会交给“PCB设计师”,然后由他们来完成电路板布局。但现在,随着平板电脑、智能手机甚至电子游戏等产品的复杂性增加,PCB的设计不再是单一人员的工作。产品的设计需要专家团队的合作,如果不能有效协作,就会浪费时间并引入错误。 曾经有一段时间,一旦概念设计完成,就会交给“PCB设计师”,然后由他们来完成最终的PCB布局。但现在,随着平板电脑、智能手机甚至电子游戏等产品的复杂性增加,团队协作和PCB设计变得至关重要。产品的设计需要专家团队的合作,如果不能有效协作,就会浪费时间并引入错误。 这个过程因为团队成员经常不在同一地点而变得更加复杂,因此,协调、记录和团队共享的软件工具对于顺畅的工作流程至关重要。本文探讨了在评估具有强大协作功能的PCB工具时经常被问到的几个问题: - 在没有强大的协作性PCB设计工具的情况下,在团队PCB设计环境中工作有什么缺点吗? - 具有强大协作工具的PCB设计工具如何使您的团队受益? - 在考虑PCB设计工具的选项时,您应该寻找哪些协作特性? 在协作PCB设计环境中工作的陷阱 在没有适当工具的协作氛围中,沟通是第一大挑战。无效的沟通会在设计过程中造成障碍、延误和失败——耗费时间和金钱。以下是四个严重问题,它们显著影响协作设计环境。 产品生命周期管理和设计数据不同步:没有协作工具,设计师可能会不经意间更改设计的相同部分,导致致命的数据冲突。团队成员可能不得不面临使用过时版本、重做不必要的工作或尝试解决不一致性的选择。 设计团队在使用MCAD和ECAD(电子设计师)之间的交换文件进行印刷电路板PCB设计工作时,采用的是静态文件传输数据库。虽然使用交换文件总比没有好,但极难确定哪些数据发生了变化,变化在哪里以及是谁做的更改。没有这些信息,真正的同步就无法发生,相同的问题就会再次出现。 在同一个设计上的团队协作效率低下:能够查看设计中正在进行的所有工作对于高效的工作流程至关重要。所有参与的工程师都需要理解彼此的意图和愿景,这需要全面的沟通。 然而,电子邮件线索、笔记和其他笨拙的沟通方法会破坏工作流程中的效率和生产力。这个过程是笨重的,如果有人没有被抄送到消息上——甚至当他们收到电子邮件时,他们可能不会及时阅读——信息就可能丢失。 间歇性或罕见的PCB布局交换通常会在最终产品中导致问题,这意味着设计师必须追溯他们的步骤,确定违规的来源并重新设计。团队成员实际上是在做两次工作,以确保整体设计能够达到最终的PCB布局和原理图捕获签名。 跨不同设计领域的沟通:虽然PCB设计师的工作重点是作为最终产品的一个元素的电路板,但实际上涉及许多人。电气和机械工程师以及CAD技术人员正在处理印刷电路板的形状,而在制造商方面——有制造专家,以及物流和供应链专家。 接触PCB设计软件的每个团队使用不同的设计领域,几乎不可能用相同的“语言”进行沟通,同时在他们自己的原生应用程序中解释数据。多个领域没有集成到单一的、流畅的工作流程中,因此可以访问同一块板的多个设计师可能会影响其他有权访问项目的人的工作——创建冲突,导致成本高昂、耗时的错误。 缺乏问责制:在PCB设计过程中,一个团队如果没有在协作氛围中工作,当他们到达项目末尾时会感到沮丧,只因发现了重大冲突。由于缺乏沟通和未能同步设计数据,出现了错误。但因为没有办法跟踪设计的变化并找到错误的来源,在非协作工作环境中,就没有问责制或透明度。更糟糕的是,团队成员可能会犯错误而不自知。因此,错误会继续发生——造成额外的成本和更多的时间,影响生产力。 PCB协作的好处:效率和一致性 阅读文章