ファームウェア/組み込みシステムソフトウェアを開発するためのアジャイル方法論をどのように採用しますか？
アジャイルメソッドを適用する方法は、実際には大規模で複雑な組み込みシステムソフトウェア（100人以上のエンジニア）にどのように適用されるのか、常に疑問に思っていました。ファームウェア開発には、アジャイルを実行するのを困難にするいくつかの固有の特性があります（つまり、ハードウェアは開発サイクルの後半まで利用できません。製品がリリースされると、ファームウェアを簡単に更新できないなど）。
この種の開発の標準は、分厚いドキュメントと厳しいピアレビューです。 2〜3個のシグネチャなしで変数の名前を変更するような簡単なコード修正を取得することはできません。 （私は少し誇張していますが、これは典型的です。さらに、多くの人々はショートカットを取るし、プロジェクトマネージャーは特に厳しい市場の期限に直面してもそれらを承認します。）
ファームウェア開発プロジェクトにアジャイル手法を採用する方法についてのヒントやガイドラインを教えてください。
2つのテクニックが重要だと思います。
ハードウェアの完全なシミュレーターまたはテスト環境を開発して、実際のハードウェアがあるかのようにソフトウェアを開発できるようにします。ここでは、見逃したり近道をしたりしないでください。優れたシミュレーターの開発will見返りがあります。
lotsシミュレーターに対する単体テストの書き込み。
これらの作業が完了したら、シミュレーターと単体テストがハードウェアでの動作を正確に理解できると人々が確信すると、他のアジャイル手法（短い反復、容赦ないリファクタリングなど）を採用するのが容易になります。 。
複数のサプライヤーが関与する開発プロセスに対するアジャイルの影響は、企業がJITに移行したときに何が起こるかと比較できます。
JITを提供するには、会社の各サプライヤーがJITを提供する必要があります。
function deliversJIT( company ) {
return company.isJIT() && map( deliversJIT, company.suppliers() );
}
同様に、アジャイル手法に従って複雑な製品を開発したい場合は、チェーン内のすべてのサブグループがそのように機能する必要があります。
「インクリメンタル」開発（別名 Tracer Bullets 15年前）の観点から、これは「コア」がドライバーの人にすぐにリリースされ、基本的なドライバーがインテグレータ、およびGUIが開発されることを考えると、1つのボタンと編集ボックスを同時に使用します。
難しいのは、堅実な思考の前向きなエンジニアリング分野に由来するハードウェアデザイナーが、いじくり回し社会に参加するよう説得することです。
2番目に難しい部分は、ハードウェアプリントが3週間前に注文される世界で段階的な開発を可能にする方法を見つけることです。私はエミュレータを考えています、fpgaはここにあります。私はハードウェアの男ではありません。
ハードウェア開発を段階的に進めたい場合は、JITチェーンの境界線と同様に、アジャイルチームが前進できるようにするバッファリングメカニズムを予測できます。
盲目にならないようにしましょう。アジャイルは重いプロセスにも対処する必要があります。 JavaコードベースをPythonに次のスプリントでリファクタリングする）ようにアジャイルチームに要求しないでください。これは、一部のパーツがその上でアジャイルの動きを踊ることができるので、本当にとても安定しています。
アジャイルマニフェスト： http://agilemanifesto.org/
「個人とプロセスとツールの相互作用」
- もっと会いましょう。紙を減らします。
「包括的なドキュメント上で動作するソフトウェア」
プロトタイピングとビルドテクノロジーの急増は頻繁に発生します。
仕様へのこだわりを構築し続けるのではなく、ユーザーのreal問題を解決します。これは、進化的ソリューションを意味します。二度と構築できないため、正しく構築しなければならないという考えは間違っています。反復を計画します。それをマーケティングおよびロールアウト戦略の一部にします。
「契約交渉をめぐる顧客コラボレーション」
非常に複雑な変更管理プロセスは、お客様に「ノー」と言うだけの方法です。
すべての要件を前もってロックダウンしてから変更制御を課すことは、「いいえ」と言う別の方法です。
すでに複数のリリースを計画している場合は、要件を後のリリースに簡単に据え置くことができます。お客様がソフトウェアを組み込んだデバイスを入手すると、次のリリースでは優先順位が変更されます。
「計画変更後の対応」
- 複雑な統合には複雑な計画が必要ですが、全体的な「プログラム」（または一連のプロジェクト）を具体的に早期にキャストすることはできません。
完全にアジャイルな方法論（つまり、スクラム）は、組み込みシステムには意味がないかもしれません。
ただし、アジャイルマニフェストは、単純な混乱を許さずに変更を可能にする方法を提供します。
組み込みシステムでのスクラムに関する私の問題は、特に初期段階で実行する必要がある多くのタスクがあることです。開発ボード、OSなし、ディスプレイなし、シリアル通信なしなどで始めました。6つのスプリント用のディスプレイがありませんでした。
最初の4つのスプリントは次のとおりです。RTOS稼働中のタスクの作成ネットワークとシリアルドライバーの作成ボタン、通信などの割り込みルーチンの作成プライマリデータベースクラスとメソッドの作成シリアルデバッグメニューの作成
これらのタスクのほとんどは、ユーザーストーリーにはあまり適していません。実際、システム全体への唯一のインターフェースは、スプリント3に組み込まれたシリアルデバッグメニューでした。そのため、スプリントの最後にデモするものはありませんでした。シリアルメニューでさえ、エンドユーザーではなく内部で使用するためのものでした。
もちろん、作成する各クラスにはユニットテストが関連付けられており、ユニットテストフレームワークを使用してすべてのテストの実行を自動化します。
「開発者として...」のような「ユーザーストーリー」のフレーズを書いてしまいましたが、私は満足していませんが、ターゲットプロセス（www.targetprocess.com）の使用には、バックログアイテムという概念がありません。タスクまたは雑用。
他の人がこれらの状況をどのように処理したか聞いてみたいです。