Come gestire le dipendenze "esterne" nella mischia?

Se hai pianificato una serie di storie utente per uno sprint e una storia candidato dipende dal fatto che un fornitore esterno fornisca qualcosa al tuo team. Ad esempio un fornitore di servizi online che aggiunge una nuova chiamata API al proprio sistema o abilita l'account di prova sul proprio sistema o simili.

Sai che arriverà 'presto'.

Vai avanti e aggiungi la storia allo sprint sperando che consegnino ciò che è necessario in tempo per completare la tua storia o aspetti fino allo sprint successivo, quando sai che sarà pronto e puoi iniziare immediatamente anche se significa non iniziare la storia il prima possibile.

Se il primo come gestisci i punti della storia "non acquisiti" persi a causa della dipendenza? credito parziale (eek!) o prenderlo sul mento.

In definitiva, dipende dal fatto che tu sia sicuro al 100% che il fornitore esterno fornirà qualcosa che puoi usare quando ti serve.

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

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

Tra i lati positivi, potrebbero esserci degli aspetti della storia che puoi fornire, ad esempio scomporli ulteriormente fino a quando non hai isolato le dipendenze il più possibile. Ciò potrebbe consentire di fare un po 'di storia prima che il fornitore consegni il proprio lavoro.

Una cosa che potresti fare è creare un'interfaccia tra il tuo codice e l'API di terze parti. Codifichi sulla tua interfaccia in modo che il resto del progetto possa procedere e fino a quando non hai l'API reale usa una simulazione per restituire i dati di esempio. Quindi quando arriva la vera API devi solo cambiare il codice dietro l'interfaccia che non influirà sul resto dell'applicazione. Fallo solo se puoi concordare con il fornitore dell'API che la loro interfaccia non cambierà (almeno non drasticamente).

La squadra è quella che prende l'impegno. Nel nostro team, se riteniamo che stiamo aspettando (ad esempio) uno sviluppatore esterno, abbiamo imparato a dire che non siamo disposti a raccogliere la storia. La storia non è in buone condizioni per essere ripresa.

C'è un'ottima possibilità che la consegna tardiva, inattesa o diversa dalla risorsa esterna comporti un cambiamento delle stime e delle priorità.

Fino a quando non avrai tutte le informazioni, il team non dovrebbe essere così ingenuo da pensare di poter completare la storia. Se dicono di poterlo fare, arrivano in ritardo, nel formato previsto, o per niente, hanno deluso tutti.

Sembra duro ma voglio chiarire il mio punto di vista.

In Scrum c'è una definizione di done e c'è una definizione di storie utente pronte per l'uso. In una situazione come la tua è importante avere una definizione pronta che tutti gli stakeholder comprendano e siano d'accordo. Ad esempio, sembra molto ragionevole avere una linea nella tua definizione di ready like:

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

Se hai bisogno di questa API per aggiungere valore al tuo prodotto, la cosa logica da fare è aspettare fino a quando non avremo davvero questa API per iniziare il nostro lavoro. Nel frattempo possiamo fare altri Stati Uniti che aggiungono valore al prodotto, davvero non mi piacciono questi Stati Uniti con implementazioni simulate e simili, se non c'è un valore reale per il cliente non ci sono Stati Uniti, la sua perdita di tempo e risorse .

Se stai aspettando qualcosa che non conosci ancora, non puoi pianificarlo anche se sei sicuro al 100% che verrà consegnato domani. Perché? Perché se non lo conosci non puoi nemmeno stimarne la complessità e se non riesci a stimarlo non puoi pianificarlo.

Se hai definito "interfaccia" / "contratto" in anticipo che devono essere seguiti da una società esterna puoi pianificarlo e creare un servizio simulato dalla tua parte. Il tuo sviluppo utilizzerà il servizio deriso in modo che non dipendano dalla consegna esterna. Tuttavia, lo sviluppo con simulazione deve essere pianificato per lo sprint in cui verrà erogato un servizio reale perché le funzionalità sviluppate e testate contro la simulazione non sono state completate - 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 metodologia stessa. Se una società ha deciso di integrare un sistema esterno, ci sarà un contratto tra (minimo) 2 entità. Il contratto deve garantire l'integrazione . 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 (sostanzialmente il contratto) .

Detto questo, deve essere considerato un rischio durante la pianificazione di quei casi e considerando che non si conosce la velocità della squadra, sarà necessario essere generosi con quei margini.

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

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Se non dipende dal tuo team e puoi svolgere altre attività, ti consiglio di assumerlo solo quando è pronto. Anche se hai un servizio web di simulazione, schema, interfaccia e / o contratto potrebbe ancora rompersi (ricordi la Legge di Murphy?).