新しいコンパイラバックエンドを実装する場合、スクラムは意味がありますか？
新しいプラットフォームに移植する必要がある既存の言語があります。私はおそらく、既存のコンパイラのバックエンドを変更することによってこれを試みます。
バックエンドを書き直すのはかなりの作業です。 INVESTの基準に違反しない限り、これを賢明なストーリーに分解する方法はわかりません。
各ストーリーが交渉可能かどうかはわかりません。それらはすべて、動作するコンパイラに必要です。ストーリーはすべて同じ優先順位であり、どの順序で配信するかは問題ではありません。私はそれらすべてを行う必要があります。
私が実装しているソフトウェアの一部は他よりも優先度が低く、それを段階的に提供できることがわかります。ただし、 必須 という重要なコアがあります。
スクラムをフォローするつもりですが、モーションを実行するだけですか？
この種のプロジェクトに推奨される方法はありますか？
アジャイルプロセスが作成された主な理由は、変化する要件に対処するためであることを覚えておいてください。要件が厳しく設定されている場合（真に固定された要件はめったにありませんが、ここで説明します！）要件の変更に対処するためのいくつかのベストプラクティス（例：交渉可能なストーリー-やや無関係になります。とはいえ、スクラムワークフローに従うことは、成果物のスケジュールと提供に関して、依然として多くの潜在的な価値があります。成果物がしばらくの間完全に使用可能な製品を構成しない場合でも、顧客（およびチーム！）に進捗状況を示すことができることについてはまだ言いたいことがあります。
これらの「必須」のストーリーはすべて、「プラットフォームXでコンパイルできる」という1つの叙事詩で構成されていると考えてください。この場合、値がユーザーに配信される前にエピック全体を完了する必要がありますが、これは大規模なプロジェクトの開始時によく起こります。ストーリーから始めて、可能な限り単純なプログラムをコンパイルし、さらにストーリーを作成して、より多くの言語機能をサポートします。
何よりも、非常に一般化されたアプローチにすべての状況を合わせるように強制しようとすることにあまり夢中にならないでください。アジャイルはあなたのために働くはずであり、逆ではありません！
もちろんスクラムは役に立ちます。これは、次の2つのことを行う方法です。
- プロジェクトを変化に適応させ、
- それはあなたが進捗状況を追跡し、それがいつ終了するかについてのアイデアを得ることができます
したがって、それを使用することにはいくつかの価値があります。
私はあなたの前提条件のいくつかが正しくないと思います、そしてそれはあなたが失われているところです。
各ストーリーが交渉可能になる方法がわかりません-それらはすべて動作するコンパイラに必要です
本当じゃない。言語のサブセットをサポートしながら、特定の条件下で機能するコンパイラを使用できます。確かに完全なコンパイラよりも価値は低いですが、それでも価値があります。
また、「交渉可能」の意味を誤解しています。これは必ずしも「オプション」を意味するものではなく、INVESTでストーリーがオプションである必要はありません。ストーリーは貴重な目的であり、交渉はその目的を達成する方法についてです。確かに、各言語機能のバックエンドを実装する方法以上のものがあります。交渉が必要なところがあります。
ストーリーはすべて同じ優先順位であり、どの順序で配信するかは問題ではありません。
これは正しくありません。以下に説明するように、一部のストーリーは「必須」ではないため、一部のストーリーはそれほど価値がありません。ただし、「必須」のカテゴリでも、一部の言語機能は他の言語機能よりもはるかに基本的であり、かなりそうです。
これを測定する1つの方法は、「既存のコードベースでコンパイルできるコードの行数」または事前定義されたテストスイートがある場合は「テストの合格数」です。
他のオプションもあります。 Cのような言語をコンパイルしていた場合、厳密に言えば、ifとgotoループだけで（かろうじて）関数型言語を使用でき、while、for、repeatをマクロとして実装できます。プリコンパイラの使用を書くのは十分簡単であると仮定すると、安価な一時的解決策を用意できます（交渉中ですか？:-)
適応性に関しては、言語のサポートはかなり静的な要件のセットですが、言語も変化しますあなたのニーズに関する知識変化。すべてを実装する必要がありますか？特に目的に必要のないものはありますか？アジャイルの基本的なテナントの1つは、不完全な知識を持つ知識です。それを活用できますか？
結論として、より直接的に質問に答えるには、要件を変更できない場合にアジャイルプロセスが必要ですか。絶対にありません！使えますか？多分そう！彼らはあなたの時間の価値がありますか？おそらくそうではありませんが、要件は変更できませんか？私の過去の経験では、「変更不可能な要件」=>「怠惰な製品所有者」-ルールではありませんが、覚えておく価値はあります。
TL; DR
すべてのプロジェクト管理コントロールはオーバーヘッドを追加します。不要なオーバーヘッドを追加しないでください。
ここでスクラムは間違ったハンマーです（釘にならないでください）
スクラムは、個々の開発者に適した一連の開発プラクティスではなく、プロジェクト管理フレームワークです。プロジェクト管理を行わない限り、スクラムはおそらく間違った選択です。
さらに、あなたが言うとき：
ストーリーはすべて同じ優先順位であり、どの順序で配信するかは問題ではありません。私はそれらすべてを行う必要があります。
あなたはいくつかのことを示唆しています：
- すべてのストーリーが100％完成しない限り、プロジェクトの価値はゼロです。
- 物語は互いに依存していません。
これらのステートメントの両方が真である場合、値または依存関係の順序で作業を優先するように設計されたフレームワークまたはプラクティスを使用しても意味がありません。
代替案
すべての開発プロジェクトは、いくつかのアジャイルプラクティスから利益を得る可能性があります。特に、あなたの特定のケースで私はお勧めします：
- すべてのストーリーに、単体テストと受け入れテストを含む「完了の定義」があることを確認してください。
- 頻繁に統合およびリファクタリングします。プロジェクトの最後に巨大な統合タスクを任せないでください。
さらに、すべてのストーリーが完了していない限り、製品の価値が本当にゼロであっても、ストーリーをテーマにグループ化して、完了したマイルストーンとして扱うことができます。 「私はfoo機能を完了しました」と言える方が、「23/117のランダムなストーリーを完了しました」と言うよりも、多くの場合便利です。 YMMV。
あなたの懸念を理解しましたが、スクラムを使用することにはまだ価値があると思います。
確かに、ユーザーストーリーは、消費者向けのアプリケーションよりもはるかに固定されています。したがって、スクラムのその側面は、より少ない価値を提供します。
あなたが価値を得ると私が思うところは、反復と頻繁なリリースからです。すべてのスプリントの最後にリリース可能な製品があると、コードの品質を高く維持し、技術的負債を低く抑えることができます。また、欠陥を早期に発見する優れた方法でもあります。
velocityを知っておくとよいでしょう。数回のスプリントの後、チームが各スプリントを完了しているエフォートポイントの数を確認できます。これにより、出荷日を決定するのに役立つ客観的な指標が得られます。
何よりも、アジャイルは形容詞であることを覚えておいてください。すべてのスプリントの最後に、回顧会議を開き、ニーズに合わせてプロセスを調整する必要があります。スクラムプロセスにコンパイラの開発に適用されない部分がある場合は、削除してください。他にメリットのあるプロセス要素がある場合は、それを追加します。私の意見では、アジャイルの最も重要な部分は、プロセスを認識し、特定の状況に合わせて常に改善することです。
（注意してください、私はコンパイラー・プロジェクトでスクラムを行ったことはありません。細かいアドバイスをしてください。）
そうです、スクラムが従うべき厳格なルールのセットではないことを覚えている限りは。プロジェクトに合わせて調整できます。スプリント、スタンドアップ、毎週のスクラムは、チームメンバー間のコミュニケーションを促進し、プロジェクトが意図した方向に確実に継続するために引き続き役立ちます。
すべてのストーリーの優先度は同じように見えるかもしれませんが、それらを実装することの相対的な難しさを考慮する必要があります。プロジェクトの最後まで、最も難しいアイテムを保持したくないでしょう。あなたはできるだけ早くそれらに取り組み始めたいと思うでしょう。