スクラム/アジャイルで、検証/ルールエンジンを段階的に提供する方法は？

有効にするために100のルールをカバーする必要がある検証エンジンがあるとします。

また、チームは反復ごとに約10のルールしか配信できないと仮定します。

ルールエンジンにコアルールの90がまだ不足している場合、最初の反復の終わりまでに「リリース可能な製品の増分」を行うにはどうすればよいでしょうか。

たとえば、すべてのルールが実装されていないという事実に基づいて常に起動する一時的な失敗/警告を追加しますか？

コンテキストの編集：私は、大規模なモノリスを複製して置き換えることを目的とした、多くのレガシーユースケースを持つ複雑なビジネスプロセス用のミドルウェアを開発しています。100％カバレッジなしでライブ配信するのは困難です。サービスを要求する運用で表示されるトリッキーなユースケースを決定または制限する機能が限られているためです。

ルールエンジンにコアルールの90がまだ不足している場合、最初の反復の終わりまでに「リリース可能な製品の増分」を行うにはどうすればよいでしょうか。

最初のスプリントで最初の10をリリースします。「リリースされる可能性がある」からといって、お客様が使用できる必要があるわけではありません。これは、どの機能がテストされ、設計どおりに動作することを意味し、製品にリグレッションを引き起こしません。

「リリースされる可能性がある」とは、「この機能に対して行う必要のある作業はもうありません。コードは完成し、適切にテストおよび文書化されている」と考えてください。

たとえば、すべてのルールが実装されていないという事実に基づいて常に起動する一時的な失敗/警告を追加しますか？

これは、顧客に実際に機能をテストしてもらいたい場合、間違いなく検討したいことです。

スクラムガイドによると、増分の定義は次のように述べています。

スプリントの最後に、新しいインクリメントは「完了」でなければなりません。つまり、使用可能な状態であり、スクラムチームの「完了」の定義を満たしている必要があります。製品所有者が実際にリリースすることを決定したかどうかに関係なく、使用可能な状態でなければなりません。

十分なルールが完了していない場合、プロダクトオーナーが実際にリリースしないことを選択する可能性があります。ただし、増分は「完了」でなければなりません。すでに実装しているルールはすべて、チームの定義の完了ごとに完了する必要があります。

決定は、インクリメントで何が行われるかによって異なります。あなたの質問では、実装されていないルールに対して例外をスローすることについて言及しています。これは機能しますが、誰かがルールエンジンと統合しようとしている場合、特に完成品に存在しない場合は、このエラーケースに対処するためのオーバーヘッドが生じる可能性があります。あるいは、それが彼らの生活をより簡単にするものなのかもしれません。Incrementの意図、それを使用している可能性のあるユーザーを検討し、そこから進んでください。

エスケープなしの状況を定義しました。

分割できない複雑な機能のブロックがある実際の状況があると思います。しかし、通常のケースでは、要件をサブ要件に分割することができ、それ自体にいくつかの利点があります。

たとえば、私の要件は、英国のクレジットカードの請求先住所を検証することです。これはかなり複雑です。住所がカードに記載された人の居住地であることをできる限り確実にしたいので、彼らが支払いを怠った場合に追跡することができます。

チェックの信頼性を向上させるために私たちが実行できる数百の検証とチェックがある可能性がありますが、それぞれが個別にテスト可能であり、詐欺のリスクを実際に減少させます。

• 住所には家番号と郵便番号があります
• 郵便番号は有効な形式です
• 外部APIを使用した郵便番号検索が成功する
• 郵便番号は地理的な郵便番号です
• 住所はクレジットカード業者などで検証されます

プッシュが発生した場合、顧客は実装されたルールのサブセットのみで収益を上げることができます。余分なリスクを受け入れるか、手動の回避策をワークフローに追加して状況を緩和することができます。

スクラムとアジャイルの方法論は、これを念頭に置いて設計されています。彼らは、不足している要件によってソリューション全体の価値が失われないようにすることで、プロジェクト全体の失敗を回避しようとします。

しかし、飛ぶためにX、Y、Zが確実に必要な宇宙ロケットがある場合、現実を変えることはできません。次に、3つすべてが必要です。

秘訣は、顧客の意見にかかわらず、一般にビジネスアプリケーションではこれは当てはまらないことを認識することです。