Come gestire le dipendenze "esterne" in scrum?

In definitiva dipende se sei sicuro al 100% che il fornitore esterno fornirà qualcosa che puoi usare nel momento in cui dovrai utilizzarlo.

Se non puoi essere sicuro che consegneranno in tempo, non aggiungere la storia allo sprint. Tuttavia, solo perché hanno sempre consegnato in passato non c'è alcuna garanzia che verranno consegnati questa volta.

Dovresti far sapere al cliente che questa dipendenza esiste e che dovrai aspettare che l'API (o qualsiasi altra cosa) sia disponibile prima di poter pianificare il lavoro.

Tra i lati positivi, ci possono essere aspetti della storia che puoi fornire - ovvero scomposizione più avanti finché non hai isolato il più possibile le dipendenze. Questo potrebbe consentire di fare una parte della storia prima che il fornitore faccia il suo lavoro.

Una cosa che potresti fare è creare un'interfaccia tra il tuo codice e l'API di terze parti. Si esegue il codice nell'interfaccia in modo che il resto del progetto possa continuare e finché la vera API non utilizza una simulazione per restituire dati di esempio. Poi, quando arriva la vera API, devi solo cambiare il codice dietro l'interfaccia che non influenzerà il resto dell'applicazione. Fai questo solo se sei d'accordo con il fornitore dell'API che la loro interfaccia non cambierà (almeno non drasticamente).

Il team è quello che rende l'impegno. Nel nostro team, se pensiamo che stiamo aspettando (per esempio) uno sviluppatore esterno, abbiamo imparato a dire che non siamo disposti a raccogliere la storia. La storia non è in uno stato adatto da raccogliere.

C'è una buona probabilità che la consegna tardiva, inaspettata o diversa dalla risorsa esterna significhi che le tue stime e priorità potrebbero cambiare.

Finché non avrai tutte le informazioni, la squadra non dovrebbe essere così ingenua da pensare di poter completare la storia. Se dicono che possono, allora arrivano in ritardo, in un formato previsto, o per niente, hanno deluso tutti.

Suona duro ma voglio ottenere il mio punto di vista.

In Scrum c'è una definizione di fatto e c'è una definizione di ready for user stories. In una situazione come la tua è importante avere una definizione di pronto che tutti gli stakeholder comprendano e siano d'accordo. Ad esempio, sembra molto ragionevole avere una riga nella tua definizione di pronto come:

• Tutte le API esterne necessarie per la storia devono essere fornite e testate

Se hai bisogno di questa API per aggiungere valore al tuo prodotto, è logico fare la sua attesa finché non avremo davvero questa API per iniziare il nostro lavoro. Nel frattempo possiamo fare altri Stati Uniti che aggiungono valore al prodotto, in realtà non mi piacciono gli Stati Uniti con implementazioni simulate e simili, se non c'è un valore reale per il cliente non ci sono Stati Uniti, è tempo sprecato e risorse .

Se stai aspettando qualcosa che non sai ancora di quanto tu non possa pianificare, anche se sei sicuro al 100% che sarà consegnato domani. Perché? Perché se non lo sai non puoi nemmeno stimarne la complessità e se non puoi stimarlo non puoi pianificarlo.

Se hai definito alcune "interfacce" / "contratti" in anticipo che devono essere seguite da società esterne, puoi pianificarle e creare servizi di simulazione dalla tua parte. Il tuo sviluppo utilizzerà il servizio deriso in modo che non dipendano dalla consegna esterna. È necessario pianificare lo sviluppo con simulazioni per lo sprint dove verrà consegnato il servizio reale perché la funzionalità sviluppata e testata contro la simulazione non è stata completata - deve essere testato con il servizio reale per essere considerato completato alla fine dello sprint.

Comunicazione e accordi

Due sistemi sono integrati dai programmatori, non dalla stessa metodologia. Se una società ha deciso di integrare un sistema esterno, ci sarà un contratto tra (minimo) 2 entità. Il contratto deve garantire che l'integrazione abbia luogo . Di conseguenza, se l'accordo tra le società, non richiede una collaborazione tecnica tra i due dipartimenti, il problema non è la metodologia di sviluppo. Il problema è la metodologia aziendale (in pratica il contratto) .

Detto questo, deve essere considerato un rischio durante la pianificazione di quei casi e considerando che non conosci la velocità della squadra, dovrai sii generoso con quei margini.

Come può un Project Manager gestire una dipendenza da un team esterno?

link

Se non dipende dal tuo team e puoi svolgere altre attività, ti consiglio di prenderlo solo quando è pronto. Anche se hai un webservice, uno schema, un'interfaccia e / o un contratto di mockup, potrebbe ancora rompersi (ricorda la legge di Murphy?).