Come posso informare la mia squadra quando i componenti sono pronti per l'integrazione?

Se non vuoi aggiungere un nuovo strumento, usa quello che hai. Mi piace che le descrizioni delle attività siano modificabili nella maggior parte degli strumenti di ticketing.

Attività : 54328 - Rendi lo spinner "Numero di dipendenti" che consente i negativi.

Descrizione

Lo spinner non riesce a impedire l'input negativo. Non consentire prima che l'utente possa fare clic su OK.

[x] Find relevant source code: TaxGUI.asp
[x] Correct behavior: added guard code to onclick method
[x] Tested and Peer reviewed: by CO2
[x] Pull request: issued against v1.1 bugfix branch
[ ] Integration: pending

Una tavola piena di bigliettini (o di una tavola Jira) è il più semplice possibile. Un'occhiata alla lavagna dovrebbe fornire informazioni sufficienti sull'andamento della squadra e, in caso contrario, significa che la scacchiera è sbagliata e dovrebbe essere corretta.

Una vera scheda fisica di solito è migliore, perché:

• È più visivo di qualsiasi strumento di ticketing del software che ho visto finora. Non fraintendetemi: uso Jira quotidianamente e mi diverto a usarlo, ma continuo a vedere che in termini di visualizzazione del progresso, la scheda reale è più capace.

• Qualsiasi persona può vedere i tuoi progressi semplicemente passando fisicamente nello spazio dell'ufficio. Non è necessario avviare un PC, vai a trovare il link alla scheda di Jira (uno dei link che tutti i membri della tua squadra perdono sempre ), autentica, ecc. Inoltre, essendo fisicamente dove si trova la squadra, la persona può anche porre domande se la scheda fisica non è chiara. "Ehi, mi hai detto ieri che hai finito di cambiare le interfacce utilizzate dall'ETL; quindi, perché l'attività è in corso? "

Tuttavia, sarebbe un vero forum o virtuale, dovrebbe consentire a qualcuno al di fuori del team di capire:

• L'avanzamento corrente , ovvero:

  1. Cosa hai fatto durante questo sprint,

  2. A cosa stai lavorando adesso,

  3. Ciò che devi ancora fare per questo sprint,

• Le priorità ,

• I punti di blocco (punti bonus se il motivo del blocco è visibile sulla lavagna).

Non solo dovrebbe essere in grado di comunicare quei punti, ma dovrebbe anche essere in grado di mostrarlo con precisione . Quello che spesso accade, specialmente quando si usano le schede virtuali, è che i biglietti crescono, crescono e crescono, e qualcuno può facilmente trascorrere cinque giorni lavorando su un singolo biglietto. Questo, per definizione, rende impossibile visualizzare i progressi. Potresti, naturalmente, chiedere allo sviluppatore quali sono i suoi progressi su un dato compito, ma la risposta sarebbe irrilevante (vedi, ad esempio, la novantanovanta regole ).

Quindi mantieni tutte le attività abbastanza piccole. Se un'attività richiede due ore, è grandioso. Se ci vuole un giorno, è un compito molto, molto grande. Se occorrono diversi giorni, devi dividerlo in compiti più piccoli, in modo che la scheda possa riflettere i progressi della tua squadra.

Una volta che hai compiti che sono abbastanza granulari, "comunicare [ing] la prontezza all'integrazione" di un compito diventa facile: o l'attività è terminata, o non lo è. Non c'è 42% fatto o 85% fatto .

Alcuni consigli aggiuntivi:

1. Se l'integrazione è dolorosa, di solito significa che le interfacce non sono state progettate con sufficiente attenzione. Il lavoro sciatto a questo livello si traduce in ore, giorni o mesi di tempo sprecato per entrambe le squadre; dedica abbastanza tempo a progettare le interfacce tra il tuo team e il mondo esterno.

2. Quando è difficile progettare un'interfaccia o quando deve essere modificata mentre entrambi i team hanno già iniziato a lavorare sulle rispettive parti del codice, collaborare con altri team. Non limitarti a fare telefonate. Vai a vederli, o invitali a venire a lavorare con te, fianco a fianco. Ho smesso di contare il numero di ore, giorni e mesi sprecati da team in cui i membri sono semplicemente troppo pigri per raggiungere l'altro lato dell'edificio e decidono di comunicare via e-mail.

Penso che tu abbia tutti gli strumenti necessari per affrontare questo. Non c'è bisogno di aggiungere o rimuovere nulla. Se la tua squadra non ha percepito la tua proposta sulla comunicazione dei loro progressi, probabilmente l'approccio preso non potrebbe essere percepito correttamente da loro. Inoltre, la collocazione di entrambi gli strumenti nello stesso repository non aiuterà di più se il team ha già problemi di integrazione.

La tua squadra è composta da più esseri umani. Gli esseri umani non possono sopravvivere in un gruppo senza comunicazione. Lo stesso vale per una visione condivisa tra quel gruppo.

La visione qui è incarnata nelle storie degli utenti o, per motivi di completezza, uno sprint. Ogni piccolo pezzo di artefatto prodotto che fa parte di un sistema più grande, DEVE, fornisce un contratto (o interfacce) per comunicare con il sistema.

Taking the human being in a group example again, one MUST know the common language among the group in order to interact, negotiate or be aware of treats.

Da questo punto di vista, credo che concentrarsi sui contratti tra questi 2 sistemi possa aiutare la tua squadra a trovare pace nell'integrazione. Ecco i miei suggerimenti:

• Riformula la tua proposta in un modo diverso e poni loro la domanda
• Avere un server di integrazione in cui sia il sistema incorporato che i componenti di Windows vengono costantemente distribuiti dopo una modifica. Da questo sistema, dovrai monitorare / verificare con o senza la disponibilità della loro user story
• Fai test di integrazione parte del DoD (definizione di fatto) di una storia utente. O automatico o manuale, deve essere fornita una prova che ha funzionato da un altro membro del team. Con questo, potresti integrare un sistema di punti in cui vengono ricompensati pezzi ben integrati