組み込みシステムデバイス用のスクラム

当社では、一括通知に使用する新製品をお届けする予定ですので、組込みソフトウェアプロジェクトであり、SCRUMを製品のフレームワークとしてご利用いただきます。

製品のバックログの記録を開始しました。私が理解したことに基づいて、製品のバックログは各アイテムのビジネス価値を反映する必要があります。組み込みソフトウェアの性質は、SPI、UART、イーサネット、WIFIなどのマイクロコントローラー用のドライバーを作成するために大量の時間を消費する多くの技術的詳細があることです。

たとえば、システムは通知のためにメッセージを再生することで音を出しているので、メッセージを再生することがビジネス上の価値であることは明らかですが、この目標を達成するために、どのような方法でもない要件を書き留める必要があります。 SPI、MP3デコーダーチップドライバー、SDカードドライバー、そして最後にFATなので、以前のすべてのドライバーには、製品バックログに書き込む必要がある要件があります。サブ要件。

これらはクライアントのビジネス価値を反映していません。製品のバックログをどのように作成するのですか？

私が働いている場所では、組み込みシステムを作成し、開発にもスクラムを使用しています。機能の観点ではなく、技術的な観点から物事を見ています。

最初に尋ねる必要があるのは、「なぜこれを実装する必要があるのか​​」です。例： なぜ SPIが必要なのですか？シリアル番号を保存できるように、EEPROMに使用する予定ですか？または、ディスプレイコントローラーに接続して、ユーザーがディスプレイ上のアイテムを表示できるようにしますか？SPIドライバーを作成することには多くの正当な理由がありますが、SPIドライバーを作成するためだけに作成することは、それらの理由の1つではありません。

スクラムを使用すると、採用されなければならない「私たちがするまで、我々はそれを必要としない必要がある、それを」ポリシーを使用すると、SPIまたはWiFiまたはで時間を無駄にはならないと言うことである、何があるまで、他のビジネスニーズにこれらの技術を必要とし成し遂げる。次に、そのビジネスニーズがストーリーになります。

「Create SPI Code」の代わりに「Add on EEPROM for configuration storage」を試してください

そして、「リモート管理用サーバへの接続を作成する」の代わりに「WIFIのドキュメントを検索し、実装」

スクラムの教義にこだわらないでください。スクラムはあなたをより機敏にするために存在します。その邪魔になるものはすべて無視できます。

ビジネス価値をもたらさない仕事をすべきではないのは事実ですが、価値には多くの形があります。あなたはイーサネットドライバを持っていることから価値を得ていますか？そうしないと、特定の機能を提供できないためです。「開発者として、インターネット接続を必要とする機能を実装できるように、イーサネットドライバーが必要です」。

したがって、値をユーザーに表示される機能としてのみ見てはいけません。価値とは、たとえそれがエンドユーザーに見えなくても、製品をより良くするものです。

これは有効なストーリーではないと言う人もいますし、ストーリーにはユーザーに表示される機能のみを含める必要があります。このような問題が発生するところまでは、大丈夫だと思います。繰り返しますが、スクラムの目標はあなたを助け、集中力とコミュニケーションを向上させることです。あなたがやっていることになっていると思っていることを、物事を成し遂げることの邪魔にさせないでください。実用的で正直に。何かを開発する必要があると思われる場合は、「なぜ」、「誰のために」という質問に答えてください。答えは常に同じ人物である必要はありません。

私の経験では、組み込み開発でスクラムを使用する主要な課題の1つは、最高のスクラムチームが機能のフルスタックの機能スライスを提供することです。最も深い根性からユーザーへの露出まで。これにより、1つのチーム内および1つのスプリント内で統合の問題が維持されます。また、エンドユーザーが結果を確認して試すことができるため、ビジネス価値が証明されます。

純粋なソフトウェアであっても、ストーリー全体を1つまたは2つのスプリントで構築できるように、各レベルでストーリーを十分に薄くすることは困難な場合があります。しかし、組み込みの場合、これは不可能である可能性があります。最も深い根性は、物理的な世界に基づいているため、ソフトウェアほど速く適応しないハードウェアを必要とするためです。

理想的なソリューションは、ハードウェア機能を向上させて、より速く循環できるようにすることです...シミュレーター、短期間の高速ターンアラウンドラン、モデルなどを使用して。しかし、それは高価になる可能性があります。したがって、私があなたの状況に当てはまると私が考える、よく使用される妥協点は、ビジネス価値の概念を緩和し、エンドユーザーとアプリケーションに必要なより一般的な機能を含めることです。

したがって、たとえば、WiFiを構築する必要がある場合は、エンドユーザーの理由があるか、それを行う理由があるはずです。それを見つけて、自動車の例のように、ユーザーストーリーの定義に入れてください。

私はこのリンクを見つけました。とりわけ、組み込み開発のユーザーストーリーについて説明しています（下にスクロールして[ストーリー]セクションに移動してください）。

ストーリー

アジャイル開発の大きな課題の1つは、システムをストーリーに分割して、製品の段階的かつ目に見える進歩を可能にするためです。組み込みアジャイル開発では、ハードウェアとソフトウェアの相互作用がさらに複雑になるため、ストーリーの定義がさらに難しくなります。

ストーリーは通常、ユーザーストーリーと呼ばれます。私はそれらをProduct Storiesと呼びたいと思います。多くの場合、組み込み開発で行う作業はエンドユーザーには見えません。製品ストーリーという名前の方がふさわしいようです。

製品ストーリーは価値を提供し、進捗状況を示したり、リスクを軽減したりするため、1回の反復で完了することができます。