Mobile menu
Altium Agile Teams
大規模でも高速に。構造化された再現性。安全で柔軟。

 高度なマルチディシプリナリ連携を実現する統合プラットフォーム

詳細はこちら
ホーム Altium Agile Teams

Altium Agile Teams

Altium Agile Teams は、Altium Designer、Altium 365、Octopart を接続されたクラウドプラットフォーム上で統合し、スピード、構造、柔軟性のバランスを実現します。これにより、ハードウェアチームは迅速に作業を進め、プロセスを標準化し、変化するビジネスや業界のニーズに適応できるようになります。

アジャイルチームを探る Altium Agile の使用開始方法
Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
アジャイル・ハードウェア開発に関する一般的な誤解のカバーフォト 多くのアジャイル「グル」がハードウェア開発について誤解していること 1 min Blog シミュレーションエンジニア 機構設計者（メカエンジニア） プロジェクトリーダー（マネージャー） +7 シミュレーションエンジニア シミュレーションエンジニア 機構設計者（メカエンジニア） 機構設計者（メカエンジニア） プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） テスト技術者 テスト技術者 技術マネージャー 技術マネージャー アジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、 ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。 電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。 神話＃1：柔軟で適応し続ける必要があります アジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。 これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、 プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。 神話＃2：毎スプリントで動作するプロトタイプを開発する必要があります アジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する 「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。 アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。 神話＃3：バックログにストーリーを追加して、ただ始める アジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。 ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される 要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。 和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。 神話＃4：すべての作業項目をユーザーストーリーとして定義する 多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。 ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！ ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。 記事を読む
アジャイル・ハードウェア開発ブログシリーズのカバー ハードウェア開発がただ…異なる5つの方法 1 min Blog 機構設計者（メカエンジニア） プロジェクトリーダー（マネージャー） シミュレーションエンジニア +7 機構設計者（メカエンジニア） 機構設計者（メカエンジニア） プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） シミュレーションエンジニア シミュレーションエンジニア テスト技術者 テスト技術者 技術マネージャー 技術マネージャー 電子ハードウェア開発におけるアジャイル手法の実装に伴う独自の課題と戦略を探求します。アジャイルフレームワーク内でのハードウェアとソフトウェア開発の主な違いを理解します。 記事を読む
Jira ハードウェア開発用 ハードウェア開発のためのJira：ツールとプロセス 1 min Blog PCB設計者 エンジニアリングチーム PCB設計者 PCB設計者 エンジニアリングチーム エンジニアリングチーム 新しいコラボレーションツールは、PCBデザイナーや電気エンジニア向けのハードウェア開発タイプのプロセスに対してJiraを作成することができます。 記事を読む
Altium 365 簡単コラボレーション ハードウェアバージョン管理システムのベストプラクティス 1 min Blog 電子設計におけるハードウェアバージョン管理システムの使用に関するベストプラクティスについてもっと読む。 記事を読む
PCB設計のレビューとコラボレーション Altium 365におけるPCB設計のレビューとコラボレーション 1 min Blog 最近ではリモート協力ツールが至る所にあり、設計者は電子設計のための便利な協力システムにアクセスできるようになりました。設計チームの一員であるか、製造業者から推奨された設計変更を迅速に実行する必要があるかどうかにかかわらず、PCB設計アプリケーション内ですぐにアクセスできるクラウド協力ツールが必要です。 今ではAltium 365を使用することで、Altium Designer内でアクセス可能なクラウド駆動の設計インターフェースを利用できます。このプロセスは難しそうに聞こえるかもしれませんが、Altium 365のワークスペースにアクセスするだけで全てが可能になります。新しいPCB設計プロジェクトにおいて、どのように迅速に協力を開始できるか、そしてチームが手動でファイルを各チームメンバーに送信することなく設計に変更を容易に加えることができる方法についてここで説明します。 PCB設計協力プロセスの開始 このチュートリアルでは、Altium 365のウェブインターフェースを通じて設計を見ているデザイナーと、Altium Designerで設計に取り組んでいる別のデザイナーの2つの役割を想定します。Altium 365のワークスペース内から、私の設計のための新しいプロジェクトを作成し、共同作業者にアクセス可能にすることができます。また、Altium Designer内で新しいプロジェクトを作成し、すぐにワークスペースに保存して、共同作業者がアクセスできるようにすることもできます。 Altium 365のウェブインスタンスにログインしていることを確認してください。その際、Altium Designerのユーザー認証情報を使用します。 クラウドを通じてこれを行う利点は、共同作業者がプロジェクトファイルを送り合うことなく、Altium Designer内でプロジェクトに即座にアクセスできることです。彼らはAltium Designer内のOpen Project機能を使用するだけで、あなたのワークスペース内のプロジェクトにアクセスできます。 共同作業者が見ることができるプロジェクトとファイルを制御できます、そして手動で変更を追跡することについて心配する必要はありません。もしプロジェクトの以前のバージョンに戻す必要がある場合や、現在の状態でプロジェクトのクローンをすぐに作成する必要がある場合でも、すべてのプロジェクトデータはAltium 365に組み込まれた安全なバージョン管理システムにあります。 記事を読む
Altium 365における電子部品管理 Altium 365における電子部品の管理 1 min Blog エレクトロニックコンポーネントの管理は、チームがAltium 365で部品データを迅速に共有し、注釈を付けることができる場合、はるかに簡単です。 記事を読む
PCBデータ管理とは PCBデータ管理とは？ 1 min Blog どんなPCBでも、優れた設計と製造にはデータ管理がつきものです。各PCBプロジェクトには、コンポーネントやフロントエンド回路図、物理レイアウト、製造ファイルに関する大量のデータが含まれています。お使いのPCB設計ソフトウェアには含まれていない他のドキュメントが必要となるかもしれません。不完全なデータや古いデータを使うと想定通りの設計ができなくなるため、設計者はこれらのデータをすべて追跡、管理する必要があります。 PCBデータ管理では、複数の領域にまたがる要件と設計情報を扱います。まず、最終製品がどのように動作するか、またその仕様と許容差、動作環境についての機能要件があります。さまざまな形式（データシートや、設計ツールライブラリにデジタル保存されたものなど）で各コンポーネントに関連付けられたデータもあります。さらに、PCB自体、その材料特性、物理的レイアウト、生産要件に関するデータもあります。設計は必ずしもゼロから始まるとは限りません。以前成功した設計の一部を再利用しなければならない場合もあります。 設計者は、以下の重要事項を考慮しなくてはなりません。 必要なデータはすべて揃っているか 設計データは正確で最新のものか 自分の知らないところで、誰かが変更を加えたか この記事では、こうした事項を確認するために役立つ情報と、最新のツールがプロの設計会社やOEMのデータ管理プロセスをどのように変えているかについてご紹介します。 PCBデータ管理とは？ PCBデータ管理は、プリント回路基板の設計、製造、実装に使われるデータの取得、保存、検証、使用法、分配、維持など、幅広い範囲にわたる作業を指します。PCB設計プロジェクトにおいてデータが作成、取得されるのは、以下のような場合です。 SOWやプロジェクト要件、デバイス要件を作成するとき フロントエンドエンジニアリングにおいて、予備設計が作成され、コンポーネントデータが収集されるとき 機械設計および電気設計をCADソフトウェアで作成する、物理設計の作業中 設計が製造に転送され、最終的な設計データが製造用に準備されるとき 設計プロセスの一部における、設計に関する決定は、筐体の形の変更などといったその他の要素にも影響を及ぼします。それによって、 PCBコンポーネントが中に収まらなくなることもあります。操作環境を変更すると、異なる周囲温度やより高い振動レベルに対応できるような設計を行う必要が出てきます。論理回路セクションの設計は、異なる許容差を持つ電力供給に適したものでなければならなくなるかもしれません。想定される変更点は莫大な量となります。いかなる変更も突き止めるられるデータ管理プロセスは必須です。 これらの問題は、PCBレベルであろうと機械設計であろうと、新製品に関する共同作業を行う場合に拡大します。たとえば、仕様が変更されたことや、物理的または電気的特性が異なる別のコンポーネントが設計に入れ込まれたことなどを、設計チームの全員がプロセス内で確実に把握する必要があります。すべてのデータで、変更や新しい情報が追跡され、それが設計チームの全員が見られる共有システムにコンパイルされると、すべてのプロジェクト関係者が表示およびアクセスできるようになります。 この概念についてもう少し詳しくご説明します。データ自体の管理について取り上げる前に、どんな情報を取得すべきか、またこの情報をどこでどのように取得するのかについて見ていきたいと思います。 PCB業界にしばらくいた方なら、PCB設計の一般的なプロセスについてはほとんどご存じでしょう。ほとんどのPCB設計では始めに同じか非常によく似た情報を使い、ソースは多くの場合同じものです。栄養豊かな地面に植えられたどんぐりが大きな木に成長するようなものです。また、最初の情報こそプロジェクト全体の成功に大きくかかわってきます。PCB設計の最初に使う情報が正確でなければ、その設計も正確なものにならない可能性が高くなります。この段階で注力すべきは、情報の量よりも質であるということをしっかりと覚えておきましょう。 データの作成と取得 データは、PCB設計チーム、製品メーカー、外部請負業者、最終顧客を含むすべてのプロジェクト関係者によって作成、編集されます。このようなデータには以下が含まれますが、必ずしもこれだけに限定されるわけではありません。 記事を読む