Altium 365 - エレクトロニクス設計エコシステム

多くのアジャイル「グル」がハードウェア開発について誤解していることアジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。神話＃1：柔軟で適応し続ける必要がありますアジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。神話＃2：毎スプリントで動作するプロトタイプを開発する必要がありますアジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。神話＃3：バックログにストーリーを追加して、ただ始めるアジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。神話＃4：すべての作業項目をユーザーストーリーとして定義する多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。

Commercial Altium 365 と Altium 365 GovCloud の比較カバー写真

Altium 365 と Altium 365 GovCloud の比較 Altium 365とAltium 365 GovCloudの商用版の違いを理解しようとしている場合、ここが正しい場所です。この記事では、それぞれのユニークな機能を理解できるように、具体的な違いを詳しく説明します。

40:03

Webinars 複数のECADファイル形式が市場投入までの時間を遅らせないようにしましょう！Altium 365 マルチCADサポートウェビナーを視聴して、ECADデータのサイロを取り除き、設計のコラボレーションを強化し、すべてのBOMを効率的に管理し、マルチCADファイルサポートでサプライチェーンのリスクを軽減する方法を学びましょう。 Altium 365はマルチCADサポートを導入し、世界で初めて真にECAD非依存の電子開発プラットフォームとなりました。設計、調達、製造の専門家が、電子開発プロセスについて協力して作業できる場所ができました。企業は、異なるシステムのレガシーデザイン、買収や好みによる混在ECADアプローチ、さまざまなソリューションを使用してクライアントに対応する請負業者などの理由で、複数のECADファイル形式を使用することがよくあります。歴史的に、設計レビュー、BOM、生産設計は異なるシステムに保存されており、統一されたビューを妨げていました。Altium 365マルチCADサポートにより、設計、BOM、サプライチェーンデータへの一元化されたアクセスが可能になりました。部品が寿命の終わりに近づいているか、供給が不足しているという警告を受けたことはありますか？これで、すべてのファイル形式にわたる影響を受ける設計をすばやく特定し、解決策を考えることができます。もう、無限に続くスプレッドシートを検索して部品番号を見つけ出し、見逃すことを願う必要はありません。これにより、会社に数百万ドルのコストがかかる可能性のある生産の停止リスクが軽減されます。学べること Altium 365がOrCAD®形式のファイルをサポートする方法（他の形式も対応予定）。異なるECAD形式間での設計協力を強化する方法。効率的なBOMおよびサプライチェーン管理の戦略。調達問題を減らし、設計プロセスを加速するためのヒント。トピック Altium 365とは複数のECAD形式を管理する際の課題 Altium 365マルチCADサポートの紹介 Altium

「シフトレフト」を実現し、調達とエンジニアリングをどのように連携させるか？Altium 365 BOM Portal ステップバイステップ BOM管理が調達マネージャーと電子エンジニアの両方にとってなぜ重要なのかを学びましょう。Altium 365 BOM Portalは、これらの世界の間のギャップを埋めるのに役立ちます。その方法を発見してください！

Altium 365で最後の瞬間の設計変更を加速製品の発売を妨げる生産の障害を、それが製品ラインを停止させる前に、どのように解決できるか気になりますか？Altium 365®が、最後の瞬間の設計変更、エンクロージャの適合、および要件を迅速に管理するのにどのように役立つかを探ります。エラー、時間の無駄、断片化したワークフローを排除しましょう。後期段階の変更：実際のシナリオツアーを体験する前回の記事で、生産ラインを停止させる一般的な障害について議論しました。今回は、これらの課題が実際に運用効率にどのように影響を与えるかを、後期段階の変更がエンジニアリング、調達、製造全体にドミノ効果の問題を引き起こし、生産スケジュールと製品の完全性を脅かす2つのシナリオを分析することで探ります。最初の状況を想像してください。電気エンジニアが新製品を導入しますが、時代遅れのコンポーネントに悩まされ、以前に検証された設計を活用する手段がありません。彼らはニーズを満たす最初のコンポーネントを使用しますが、それはリスクの増加につながります。第二のシナリオでは、調達が生産中に重要部品の誤ったリードタイムによって誤解を招きます。以前に代替部品が特定されていなかったため、製造不可能なボードと重大な品質上の懸念に対処するために迅速な行動が必要です。どちらの場合も、部品と設計の変更を緊急に対処するためのチームには大きな圧力がありますが、以下の障害に直面します：機械エンジニアは、基板がエンクロージャに収まることを確認するために、時間を要するファイル交換に直面しており、各手動のエクスポート/インポートサイクルでデータの損失や誤解が生じるリスクがあります。コンポーネントと更新の手動追跡には、エンジニアごとに最大40時間が費やされます。プロジェクトマネージャーはタイムラインを維持しようと努力しますが、効果的に行うための可視性がしばしば欠けています。効率を追求するエンジニアリングマネージャーは、遅い知識の移転と長いレビューサイクルによって足を引っ張られています。この段階で重要なステークホルダーはプロセスに接続されていません。プロダクトマネージャーとシステムアーキテクトは、最終製品を元の要件と市場の需要に合わせることに苦労しています。製造業者は情報を遅れて受け取り、その結果、生産ラインの停止や再作業によるコストがかかります。これらの問題をどのように軽減するか？リアルタイムのコラボレーション、文脈情報の流れ、および積極的な変更管理を可能にする統一されたデジタルインフラストラクチャを通じて、製品の成功を確実にし、勢いを維持します。使用するかもしれないソリューションの一つが、電子開発のすべての側面を一つにまとめ、組織がこれまで以上に迅速に優れた製品を提供するのを助けるアジャイルな電子開発プラットフォームである Altium 365です。

Customer Success Stories MKS Instruments Find out how MKS Instruments are using Altium 365 to support the search for a cure for COVID-19.