ハードウェアチームに大きく依存しているソフトウェアチームに最適なソフトウェア開発モデルはどれですか。

ソフトウェア開発には、競合するベストプラクティスがいくつかあります。私が発見したことから、多くのチームがアジャイルプラクティスの恩恵を受けている場合があります。ただし、他のいくつかのケースでは、統一プロセスの使用はIBMなどの大企業によって支持されています。

私が見つけた共通のテーマは、主にソフトウェアを開発するチームにとってはうまく機能するように見えました。

私は、ソフトウェアが実行されているハードウェアを生産するチームが反対側にいるショップで働いている人々にとって何が最もうまくいったか知りたいです。たとえば、1つのチームが複数のカスタムハードウェアを搭載したクレートを組み立てます。一方、これらのクレートで動作するソフトウェアを開発する必要があります。この場合に最適に機能する開発モデル（アジャイル、スパイラルなど）が見つかりません。

どんな知恵もこの領域は高く評価されます。

それは、ハードウェアチームがソフトウェアチームが開発に使用できる有用なアーティファクトをどのように提供するか、およびチームが互いに通信するためにどのように設定されているかに大きく依存します。

通常、ハードウェアチームが製品を構築し、プロトタイプの段階に進んでテストを行い、その後ソフトウェアチームがハードウェアチームからあらゆる種類の要件ドキュメントを取得します。言うまでもなく、ソフトウェアは通常、プロセスの非常に遅い時期に開発されるため、これが常に最良の方法であるとは限りません。通常、ウォーターフォールベースの方法論を使用する以外に選択肢はほとんどありません。ハードウェアチームの観点から見て有利な点は、突然何かを変更する必要がある場合に、ソフトウェアチームがソフトウェアを変更する必要がないことです。もちろん、ここでの問題は、平均的なハードウェア担当者がこの方法で製品を開発する必要があり、ソフトウェアチームを支援することで彼に利益をもたらすことが期待されることです。

別の方法として、ハードウェアチームが製品を構築してソフトウェア要件を随時更新している場合、さらに良いことに、各ハードウェア機能が計画およびシミュレーションされているときにソフトウェアチームが早い段階で関与している場合は、はるかにアジャイルな方法で作業するソフトウェアチーム。当然、これはハードウェアチームがお客様であり、ソフトウェアチームがソフトウェアで解決する必要のある問題のリストを提供することを意味します。ソフトウェアチームは、各要件の相対的な優先順位について顧客と話し合うことができます。ハードウェアプロトタイプの準備が整い次第、ソフトウェアは早期リリースの形で提供され、ハードウェアのテストに使用できます。要件が変更された場合、ソフトウェアチームはソフトウェアを変更する際の機敏性を期待できます。また、ハードウェア設計がプロトタイプにコミットする前に、ハードウェアチームに早期フィードバックを提供できます。ソフトウェアチームは、プロジェクトの非常に早い段階で顧客に直接アクセスすることもできます。つまり、ハードウェアがテストするのを待っている間、モックアウトする必要があるものとその方法について、より良いアイデアを得ることができます。

現実的には、すぐに使える理想的な方法論を見つけることはできません。どの方法論を採用または開発するかに関係なく、多くの調整が必要になることを保証できます。本当の問題は、チーム間の同期を管理しやすくしたいということです。つまり、プロセスのできるだけ早い段階で、2つのチーム間の連絡と入力の量を増やす方法を見つける必要があります。 「無駄」または「直感に反する」と思われる場合でも これは私が現在取り組んでいる会社の大きな問題です。私たちのヨーロッパの「親」はこの正確な問題に苦しんでいますが、オズのチームは物事をもう少しスムーズに実行し続けることができるようです。

大規模なソフトウェアハードウェア製品開発チームのハードウェア側により多く取り組んできたので、私はおそらく偏見があります。ハードウェアの設計や設計が間違っていると、ハードウェアの修正に非常にコストがかかる可能性があります。多くの場合、ハードウェア設計のエラーは非常にコストがかかるため、プロジェクト全体をキャンセルすることになります。チップマスクエラーの修正には、何十人ものエンジニアの年収よりも多くの費用がかかる可能性があります。したがって、開発サイクルの最初の50％以上のソフトウェアチームの主な目的は、ハードウェアチームが失敗しないようにすることです。これは、最初は最終的なアプリケーションコードとその設計を忘れて、ハードウェアのアーキテクチャとパフォーマンスのシミュレーション、ハードウェアチームが設計を完了して検証するのに役立つツールに取り組むことを意味する場合があります。

顧客の仕様だけでなく、ハードウェアプラットフォームのさまざまな驚くべき癖/バグについても機敏であることが期待されます。ソフトウェアの回避策は、ハードウェアのスピンよりもスケジュールへの影響がはるかに少ない可能性があります。

アジャイルの主要なテナントの1つは「早期に失敗する」ことです。ハードウェアでは、これは真実ではありません。大量生産ハードウェアは非常に高価です。さらに、物理ハードウェアは、ソフトウェアのように単純に「パッチ」することはできません。これらの問題を悪化させるため、ハードウェアチームは実際にはソフトウェアチームよりも顧客に直面することが少なく、開発の「ビッグバン」モデルに慣れがちです。

これらの理由により、ハードウェアの問題をできるだけ早く検出しないことは、通常、ソフトウェアの問題を早期に検出できないことに比べて桁違いに高価です。お客様はソフトウェアの更新が必要であることを期待しており、ハードウェアのリコールに対処する必要がある場合は、お客様との連携が完全に停止する可能性があります。

要するに、 ハードウェアの問題を早期に予期して準備しないことが、ソフトウェアとハ​​ードウェアを並行して開発する際の開発モデルの最大の課題です。

絶対に失敗を予測する必要があります。早くプロトタイプを入手してください。プロトタイプを使用して開発します。失敗することを期待してください。失敗から学ぶ。リンス。繰り返す。関係者からのフィードバックに基づいて、ハードウェアのプロトタイプが改訂/批評/再設計されることを全員が期待していることを確認してください。