スクラムは、新しいコンパイラバックエンドを実装するときに意味がありますか？

新しいプラットフォームに移植する必要がある既存の言語があります。既存のコンパイラのバックエンドを変更することで、おそらくこれを試みます。

バックエンドを書き直すのはかなりの作業です。INVEST基準に違反することなく、これを理にかなったストーリーに分解する方法はありません。

各ストーリーがどのように交渉可能であるかはわかりません-それらはすべて、動作するコンパイラに必要です。ストーリーの優先度はすべて同じであり、配信する順番は関係ありません。それらすべてを行う必要があります。

私が実装しているソフトウェアには、他の部分より優先度が低い部分があり、それを段階的に提供できることがわかります。ただし、Must Haveという重要なコアがあります。

私はスクラムを追いかけようと計画していますが、私はただ動きをしているだけですか？

この種のプロジェクトに推奨されるプラクティスはありますか？

アジャイルプロセスが作成された主な理由は、変化する要件に対処することであったことに留意してください。要件が明確に設定されている場合（完全に固定された要件はまれですが、ここで説明します！）、要件の変更に対処するためのベストプラクティスのいくつか（交渉可能なストーリーなど）は、やや無関係になります。そうは言っても、スクラムワークフローに従うことは、成果物のスケジューリングと提供に関して、依然として多くの潜在的な価値があります。しばらくの間、成果物が完全に使用可能な製品にならない場合でも、顧客（およびチーム）に進捗を示すことができると言うことはまだあります。

これらの「必要な」ストーリーはすべて、「プラットフォームXでコンパイルできる」という単一の叙事詩で構成されていることを考慮してください。この場合、値をユーザーに配信する前にエピック全体を完了する必要がありますが、これは大規模プロジェクトの開始時によく見られます。ストーリーから始めて、可能な限り単純なプログラムをコンパイルし、さらにストーリーを作成して、より多くの言語機能をサポートします。

とりわけ、あらゆる状況を高度に一般化されたアプローチに適合させようとすることに夢中になりすぎないでください。アジャイルはあなたのために働くはずであり、その逆ではありません！

もちろんスクラムは便利です。これは、次の2つのことを行う方法論です。

1. プロジェクトを変更に適応させ、
2. 進行状況を追跡し、いつ終了するかを知ることができます

したがって、それを使用することにはいくつかの価値があります。

私はあなたの前提条件のいくつかが正しくないと思います、そしてそれはあなたが迷子になっているところです。

各ストーリーがどのように交渉可能であるかはわかりません-それらはすべて、動作するコンパイラに必要です

本当じゃない。言語のサブセットをサポートしながら、特定の条件下で動作するコンパイラーを使用できます。確かに完全なコンパイラーほど価値はありませんが、それでも価値はあります。

また、「交渉可能」の意味を誤解しています。必ずしも「オプション」を意味するわけではなく、ストーリーがINVESTでオプションであるという要件はありません。物語は価値のある目標であり、交渉はその目標を達成する方法についてです。確かに、各言語機能のバックエンドを実装する方法以上のものがあります。交渉が必要な場所があります。

ストーリーの優先度はすべて同じであり、配信する順番は関係ありません。

これは正しくありません。下で言うと、一部のストーリーは「必須」ではないので、確かにいくつかのストーリーはあまり価値がありません。しかし、「必須」カテゴリであっても、一部の言語機能は他の機能よりもはるかに基本的であり、測定可能なほど重要です。

これを測定する1つの方法は、「既存のコードベースでコンパイルできるコードの行数」または事前に定義されたテストスイートがある場合は「さらに多くのテストに合格する」です。

他のオプションもあります。あなたはCに似た言語をコンパイルした場合は、厳密に言えば、あなただけの必要ifとgoto（ほとんど）関数型言語を持っている、あなたが実装することができますループをwhile、forおよびrepeatマクロとして。プリコンパイラの使用を書くのが十分に簡単であると仮定すると、安価な一時的な解決策を得ることができます（ねえ、私たちは交渉していますか？:-)

適応性に関しては、言語のサポートはかなり静的な要件のセットですが、言語も変わり、ニーズに関する知識も変わります。すべてを実装する必要がありますか？あなたがあなたの目的のために特に必要としないものはありますか？アジャイルの基本的なテナントの1つは、不完全な知識を持つという知識です。それを活用できますか？

結論として、あなたの質問にもっと直接答えるために：あなたの要件が変更できないとき、あなたはアジャイルプロセスを必要としますか？絶対にありません！それらは使用可能ですか？おそらくそうだ！彼らはあなたの時間の価値がありますか？おそらくそうではありませんが、要件は変更できませんか？私の過去の経験では、「変更不可能な要件」=>「怠productな製品所有者」-ルールではなく、覚えておく価値があります。

TL; DR

すべてのプロジェクト管理コントロールはオーバーヘッドを追加します。必要のないオーバーヘッドを追加しないでください。

スクラムはここでは間違ったハンマーです（釘ではありません）

スクラムはプロジェクト管理フレームワークです、個々の開発者に適した一連の開発プラクティスではなくです。プロジェクト管理を行っていない限り、スクラムはおそらく間違った選択です。

さらに、あなたが言うとき：

ストーリーの優先度はすべて同じであり、配信する順番は関係ありません。それらすべてを行う必要があります。

あなたはいくつかのことを暗示しています：

1. すべてのストーリーが100％完了しない限り、プロジェクトの価値はゼロです。
2. ストーリーは互いに依存していません。

これらのステートメントが両方とも当てはまる場合、値または依存関係の順序で作業を優先するように設計されたフレームワークまたはプラクティスを使用しても意味がありません。

推奨代替案

どんな開発プロジェクトでも、いくつかのアジャイルプラクティスの恩恵を受ける可能性があります。特に、あなたの特定のケースでは、私はお勧めします：

1. すべてのストーリーに、ユニットテストと受け入れテストを含む「完了の定義」があることを確認します。
2. 頻繁に統合してリファクタリングします。プロジェクトの最後に巨大な統合タスクを残さないでください。

さらに、すべてのストーリーが完了しない限り、製品の価値が本当にゼロであっても、ストーリーを完成したマイルストーンとして扱うことができるテーマにグループ化するのに少し時間を費やします。「foo機能を完了しました」と言うことができると、「23/117のランダムなストーリーが完了しました」と言うよりも便利なことがよくあります。YMMV。

あなたの懸念を理解していますが、スクラムを使用することにはまだ価値があると思います。

確かに、ユーザーストーリーは、消費者向けアプリケーションよりもはるかに固定されています。そのため、スクラムの側面は価値が低くなります。

あなたが価値を得ると思うのは、反復的で頻繁なリリースからですです。すべてのスプリントの最後にリリース可能な製品があると、コードの品質を高く保ち、技術的な負債を低く抑えることができます。また、欠陥を早期に発見するのに最適な方法です。

速度を知ることで利益も得られると思います。数回のスプリントの後、チームが各スプリントを終了するまでの労力ポイントを確認できます。これにより、出荷日を決定するのに役立つ客観的な指標が得られます。

とりわけ、アジャイルは形容詞であることを忘れないでください。すべてのスプリントの終わりに、回顧会議を開催してから、ニーズに合わせてプロセスを調整する必要があります。コンパイラ開発に適用されないスクラムプロセスの一部がある場合、それを削除します。他に有益なプロセス要素がある場合は、それを追加します。私の意見では、アジャイルの最も重要な部分は、プロセスを認識し、特定の状況に合わせて絶えず改善することです。

（注意してください、私はコンパイラプロジェクトでスクラムをしたことがないので、一言一言アドバイスしてください。）

はい、スクラムは従うべき厳格なルールのセットではないことを覚えている限り、そうです。プロジェクトに合わせて調整できます。スプリント、スタンドアップ、ウィークリースクラムは、チームメンバー間のコミュニケーションを促進し、プロジェクトが意図した方向で継続することを確認するために引き続き有用です。

すべてのストーリーは同じ優先度を持っているように見えるかもしれませんが、それらを実装する相対的な難しさを考慮する必要があります。プロジェクトの終了まで、最も難しいアイテムを保持したくないでしょう。できるだけ早くそれらの作業を開始する必要があります。