組み込みシステムでスクラムを使用した非機能的な作業をどのように処理しますか？

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

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

• 取得RTOSを起動して実行
• ネットワークおよびシリアルドライバーを作成するタスクの作成
• ボタン、通信などの割り込みルーチンの作成
• プライマリデータベースのクラスとメソッドの作成
• シリアルデバッグメニューの作成

これらのタスクのほとんどは、ユーザーストーリーにはあまり適していません。実際、システム全体への唯一のインターフェースは、スプリント3に組み込まれたシリアルデバッグメニューであったため、スプリントの最後にデモンストレーションするものはありませんでした。シリアルメニューでさえ、エンドユーザーではなく内部使用を目的としていました。それにもかかわらず、私はまだスクラムを介してこれらの開発活動を追跡および管理したいと考えています。

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

次に、リリースとテストをどのように処理しますか？テスターに​​はハードウェアデバッガーがないため、非常に苦痛です。したがって、コードのフラッシュバージョンをビルドし、テストするために開発ボードに書き込む必要があります。テスターは技術的には開発者ほど鋭くなく、多くの場合、初期段階（ボードのリセット、シリアル通信の接続など）で作業を行ったり、出力を理解したりするのに多くのサポートを必要とします。

最後に、完了の定義に関して、スプリントはすべてのストーリーが完了するまで完了できません。すべてのストーリーは、テスターに​​よって検証されるまで完了しません。開発者がテスターに​​与える時間を「奪う」ことを避ける方法はありません。つまり、スプリント内の最後の3つのユーザーストーリーのテストに5日間かかる場合、スプリント終了の5日前にコーディングしてユニットテストを行う必要があります。開発者は何をすることになっていますか？仕事をやめる？

私は面白く思っていますが、ルールに準拠しようとするのは本当の問題です。今、私はルールを曲げることに問題はありませんが、私が抱えている問題は、テストされるまで物事をマークできない場合、すべてのバーンダウンメトリックを台無しにします。

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

私見と互換性のない製品で方法論を使用しています。

ほとんどの人がアジャイルを定義する方法では、すべての作業は優先順位の変更、再注文可能、または交換可能に基づいて交渉可能です。

ほとんどの人がウォーターフォールを定義する方法では、最初の重要なアーキテクチャの取り組みから、作業が事前に順番にレイアウトされます。

上記のタスクは、私にとって非常に重要なものです。それらは特定の順序である必要があり、交渉できません。

私はあなたがどんなプロセスの誰かの見方にも従わなければならないと言っているわけではありませんが、少なくともこれらのタスクについては、私にとって非アジャイルプロジェクトにいるようです。それをアジャイルプロセスにバッシングしようとすることは、せいぜいずさんなフィットになるでしょう。

プロジェクトの残りの部分がアジャイルに適している場合、初期設定が不適切であることをあまり心配しませんが、RTOSと開発ボードについて言及しているという事実は、全体がより良いものであると疑っていますウォーターフォール（不動の依存関係の長いシーケンス）のように。

さて、組み込みシステムの構築については何も知りませんが、スクラムをそのような開発に不適切にするものは何もありません。実際にユーザー向けの機能がないことを心配するのは簡単ですので、ユーザーを持つことで「ユーザーストーリー」を書くことは困難です。ユーザーストーリーは実際にはスクラムの一部ではなく、スクラムでよく使用されますが、実際には単なるツールとして使用されます。

スクラムの一部は、完全にテストされ、各スプリントのライブ環境で潜在的に実装可能な完全な機能を提供するという考えです。ある種のプロジェクトの1日目にゼロから始める場合、Sprint 1で提供できるあらゆる種類の機能の実際の価値はごくわずかです。それは、小さなものにはすべて、それを機能させるために大量のインフラストラクチャを構築する必要があるためです。しかし、ポイントは、各機能を機能させるのに十分なインフラストラクチャのみを構築することです。そして、さらに機能を追加するにつれてそれを構築します。

その考え方は、システムの外部から検出される方法のないインフラストラクチャを構築するために、特に何カ月も費やさないということです。どうして？実際に機能するものを構築するまで、インフラストラクチャの必要性が正確にわからないためです。これは、システムの実際の機能を構築する際に学ぶものです。最初にインフラストラクチャを構築する場合、システムについてほとんど知らないときに構築します。

ユーザーストーリーを書くことに夢中なら、ユーザーは人である必要はないことを忘れないでください。「CMOS割り込みハンドラーとして、fluxtronicコンプレッサーがパッシブバイパスアンダーチャージを通知するときに、bingle whozzitスタック変調フラグのステータスを検出できるようにする必要があります」などのように記述します。「開発者として...」ユーザーストーリーを絶対に書かないでください。

非常に特定の領域でスクラムを使用し、すべてのステップで想定されるプロセスに違反します。あなたの質問はおそらく次のとおりです：私の環境によりよく適合する別のアジャイルな方法論はありますか？単純に、環境で許可されていないスクラムの改善を支援するのは非常に困難です。あなたの説明にある問題：

• インフラストラクチャタスクと見なすことができる実証可能なタスクはありません。ビジネス上の価値と見なされない何かをするためにいくつかのスプリントが必要な場合、ユーザーストーリーはおそらく不適切に定義されています。ビジネスバリューを提供するためにツールなどを構築する必要がある場合、ツールを構築してビジネスバリューを構築するという2つの部分/リリースに製品を分けることができます。このような場合、開発者向けのツールが作成されるため、ユーザーストーリー「開発者として...」は完全に有効になります。

  ここでの問題は、最初のリリースへの関与がゼロであるため、これを顧客に伝える方法です。顧客にビジネス価値がない場合、どのように参加できますか？製品所有者はビジネスの優先順位をどのように定義できますか？

  ここでの主な問題は、これがスクラムに適合するものではないことだと思います。スクラムは最も重要なビジネス機能を最初に提供しようとしますが、最初の機能を提供するには2か月かかります。スクラムとアジャイル全体が変更を受け入れます-最初の機能を提供した後、顧客が最初のスプリントすべてに戻る変更を必要とする場合はどうなりますか？

• テスト。もう1つの失敗は、スクラムのチームが職域を超えたメンバーのグループと見なされるためです。これは、誰もが開発とテストを行うことを意味します。そのため、最終ポイントに記載されている状況はありません（少なくとも5日間はありません）。より複雑で高度なテストを行うために個別のQAが存在できないことを意味するものではありませんが、チームは既にテ​​スト/検証された機能を提供する必要があります。あなたの場合、スクラムは必要なものではないようです。開発とテストを個別に処理し、それらの間で機能を渡す必要があります。