ファームウェア/組み込みシステムソフトウェアの開発にアジャイル手法を採用する方法は？

アジャイル手法をどのように適用するかは、大規模で複雑な組み込みシステムソフトウェア（100人以上のエンジニア）に本当にあるのかといつも思っていました。ファームウェア開発には、アジャイルを実行するのを難しくするいくつかの独自の特性があります（つまり、ハードウェアは開発サイクルの後半まで利用できません。製品がリリースされると、ファームウェアを簡単に更新できませんなど）。

この種の開発の標準は、厚手のドキュメントと厳しいピアレビューです。2〜3個の署名なしで変数の名前を変更するなどの簡単なコード修正を取得することはできません。（少し誇張しますが、これは典型的なことです。さらに、多くの人がショートカットを採用しており、特に厳しい市場の締め切りに直面して、プロジェクトマネージャーはそれらを承認します。）

ファームウェア開発プロジェクトにアジャイル手法を採用する方法に関するヒントやガイドラインを聞きたいです。

2つのテクニックが重要だと思います。

• ハードウェア用の完全なシミュレーターまたはテスト環境を開発し、実際のハードウェアがあるかのようにソフトウェアを開発できるようにします。ここでskiしたり、近道をしたりしないでください。優れたシミュレーターを開発することで成果が得られます。

• シミュレーターに対して多数の単体テストを作成します。

これらを実行し、シミュレーターとユニットテストがハードウェアでどのように機能するかを正確に把握できると人々が確信したら、他のアジャイルテクニック（短い反復、容赦ないリファクタリングなど）を採用するのが簡単になります。 。

複数のサプライヤが関与する開発プロセスに対するアジャイルの影響は、企業がJITに移行したときに何が起こるかと比較できます。

JITを配信するには、会社の各サプライヤーがJITを配信する必要があります。

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

同様に、アジャイル手法に従って複雑な製品を開発する場合、チェーン内のすべてのサブグループがそのように機能する必要があります。

「インクリメンタル」開発（15年前のトレーサーブレットとも呼ばれます）の観点からは、これは「コア」がすぐにドライバーにリリースされ、基本的なドライバーがインテグレーターに利用可能になり、GUIが単一のボタンと編集ボックスを同時に使用して開発します。

ハードな部分は、ハードウェアデザイナーに、前向きな確固たるエンジニアリングの分野から来て、私たちのティンカラー社会に参加するよう説得することです。

2番目に難しいのは、ハードウェアプリントを3週間前に注文する世界でインクリメンタル開発を可能にする方法を見つけることです。私はエミュレータを考えています、fpgaはここにあります。私はハードウェアではありませんが。

漸進的なハードウェア開発をやめたい場合は、JITチェーンの境界のように、アジャイルチームが前進できるようにするバッファリングメカニズムを予測できます。

盲目にならないようにしましょう。アジャイルは、重いプロセスにも対処する必要があります！次のスプリントで、JavaコードベースをPythonに「リファクタリング」するようにアジャイルチームに依頼しないでください。いくつかのパーツが本当に安定しているからこそ、アジャイルの動きをそれらの上で踊ることができます。

アジャイル宣言：http : //agilemanifesto.org/

「プロセスとツールを介した個人と相互作用」

• もっと会いましょう。紙を押してください。

「包括的なドキュメントよりも機能するソフトウェア」

• プロトタイプおよび構築技術は、早期に頻繁に急増します。

• 仕様へのこだわりを作り続けるのではなく、ユーザーの本当の問題を解決してください。これは進化的解決策を意味します。二度と構築できないので、正しく構築しなければならないという考えは間違っています。繰り返しを計画します。マーケティングおよびロールアウト戦略の一部にします。

「契約交渉よりも顧客とのコラボレーション」

• ハイパーコンプレックスの変更管理プロセスは、顧客に「いいえ」と言うだけの方法です。

• すべての要件を事前にロックダウンしてから変更管理を課すことも、「いいえ」と言う別の方法です。

• すでに複数のリリースを計画している場合は、要件を後のリリースに簡単に延期できます。顧客が組み込みソフトウェアを備えたデバイスを入手すると、次のリリースの優先順位が変更されます。

「計画に従った変更への対応」

• 複雑な統合には複雑な計画が必要ですが、全体的な「プログラム」（またはプロジェクトのシーケンス）を具体的にキャストするのは早すぎません。

完全にアジャイルな方法論（つまり、スクラム）は、組み込みシステムには意味がない場合があります。

しかし、アジャイルマニフェストは、単純な混乱を許さずに変更を可能にする方法を提供します。

組み込みシステムでのスクラムに関する私の問題は、特に初期段階で行うべき多くのタスクがあり、それは実証できないことです。開発ボード、OSなし、ディスプレイなし、シリアル通信なしなどから始めました。6スプリントのディスプレイはありませんでした。

最初の4つのスプリントは、次のとおりです。

これらのタスクのほとんどは、ユーザーストーリーにはあまり適していません。実際、システム全体への唯一のインターフェイスは、スプリント3に組み込まれているシリアルデバッグメニューでした。シリアルメニューでさえ、エンドユーザーではなく内部使用を目的としていました。

もちろん、記述する各クラスにはユニットテストが関連付けられており、ユニットテストフレームワークを使用してすべてのテストの実行を自動化します。

「開発者として...」のような「ユーザーストーリー」というフレーズを書くことになりました。これは満足できませんが、ターゲットプロセス（www.targetprocess.com）を使用する場合、バックログアイテムの概念はありません。タスクまたは雑用。

他の人がこれらの状況をどのように処理したか聞いてみたいです。