In Scrum / Agile, come distribuire un motore di validazione / regole in modo incrementale?

How would you go about making a "potentially releasable product increment" by the end of the first iteration, when the rules engine would still be missing 90 of the core rules?

Rilasciate i primi dieci nel primo sprint. Solo perché è "potenzialmente rilasciabile" non significa che debba essere utilizzabile dal cliente. Significa solo che la funzionalità è stata testata e si comporta come progettato e non causa alcuna regressione nel prodotto.

Pensa a "potenzialmente rilasciabile" in quanto "non abbiamo altro lavoro da fare per questa funzionalità. Il codice è completo ed è stato testato e documentato correttamente".

Would you, for example, add a temporary failure / warning that always fires based on the fact that not all rules have been implemented?

Questo è sicuramente qualcosa che potresti voler considerare, se vuoi che il cliente verifichi effettivamente la funzione.

Dalla guida di Scrum, la definizione di un incremento dice :

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

Se non hai completato un numero sufficiente di regole, è probabile che il proprietario del prodotto scelga di non rilasciarlo. Tuttavia, l'incremento dovrebbe essere "Fatto". Qualsiasi regola che hai già implementato dovrebbe essere stata completata secondo la Definizione di Fatto della tua squadra.

Le decisioni che prendi dipendono da ciò che verrà fatto con l'Incremento. Nella tua domanda, menzioni le eccezioni di lancio per le regole non implementate. Questo potrebbe funzionare, ma se qualcuno dovesse integrarsi con il tuo motore di regole, potrebbe creare un sovraccarico per far fronte a questo caso di errore, specialmente se non esiste in un prodotto finito. O forse è ciò che renderebbe la vita più facile. Considera quale sia l'intento dell'incremento, chi può usarlo e vai da lì.

Hai definito una situazione senza via di fuga.

Sono sicuro che ci sono situazioni di vita reale in cui hai un blocco di complicate funzionalità che non possono essere suddivise. Ma il solito caso è che puoi suddividere un requisito in requisiti secondari che hanno alcuni vantaggi per se stessi.

Per esempio, il mio requisito è di convalidare gli indirizzi di fatturazione della carta di credito del Regno Unito. Questo è piuttosto complicato, vogliamo garantire nel miglior modo possibile che l'indirizzo sia l'indirizzo di residenza della persona nominata sulla carta in modo tale che, in caso di default su un pagamento, possiamo inseguirli.

Ci sono potenzialmente centinaia di convalide e verifiche che possiamo fare per migliorare l'affidabilità del controllo, ma ognuna individualmente è testabile e offre una reale diminuzione del rischio di frode.

L'indirizzo
• ha un numero civico e un codice postale
Il codice postale
• è un formato valido
• Ricerca codice postale con API esterna ha esito positivo
Il codice postale
• è un codice postale geografico
L'indirizzo
• è convalidato con il fornitore della carta di credito ecc. ecc.

Se la spinta arrivasse a spingere, il cliente sarebbe in grado di fare soldi con solo un sottoinsieme delle regole implementate. O il rischio extra potrebbe essere accettato o si potrebbe aggiungere al workflow del lavoro manuale per mitigare la situazione.

Le metodologie Scrum e Agile sono progettate tenendo presente questo. Cercano di evitare il fallimento dell'intero progetto garantendo che alcuni requisiti mancanti non causino l'inutilità dell'intera soluzione.

Ma non possono cambiare la realtà, se si dispone di un razzo spaziale che ha sicuramente bisogno di X, Y e Z per volare. Allora hai bisogno di tutti e tre!

Il trucco sta nel riconoscere che generalmente nelle applicazioni aziendali non è così, nonostante ciò che il cliente potrebbe dire.