Problemi del team SCRUM distribuito: l'ambiente di lavoro

Penso che ci siano 3 parti del problema:

1. Vuoi risparmiare il debito tecnico / mal di testa lungo la strada, applicando buone regole ora.
2. Non vuoi uccidere la velocità della squadra facendo impantanare tutti con regole non necessarie.
3. Non conosci esattamente le migliori regole da implementare, perché il progetto è in una fase esplorativa.

Ho provato entrambi gli estremi (da nessuna regola, basta usare lo stesso controllo del codice sorgente, ad una linea guida di stile di codifica di 20 pagine + molti altri processi)

L'unica cosa che ha funzionato in modo coerente è abbracciare il minimo assoluto so di aver bisogno e posso dimostrare di aver bisogno adesso, e di rivedere il processo regolarmente . (Ogni sprint nella retrospettiva è un buon momento per farlo) Questo include anche la rimozione di qualsiasi regola rudimentale.

Immagino che questo dipenda davvero dalle squadre e quanto ti preoccupi del checkstyle. Sono d'accordo che dovremmo avere una sorta di regole per prevenire alcuni bug inutili. Ma alcune regole sono piuttosto fastidiose che produttive. Immagino tu debba concordare all'interno del team quali regole sono necessarie e non necessarie.

Anche impostare job Jenkins per checkstyle o firebug è buono, ma di nuovo devi essere d'accordo sul modo in cui vuoi che sia rigoroso. Sono stato in una situazione in cui qualcuno ha infranto una regola di checkstyle e impediamo a chiunque di commettere. A lungo termine, infastidirà solo le persone. Ancora una volta, se hai detto che le persone non devono prestare molta attenzione, inizieranno a ignorarle. Quindi, nel mio team, siamo d'accordo sul fatto che finché il lavoro di qualità non è gravemente rotto. Deve essere blu prima della fine dello sprint.

Quindi il mio suggerimento sarebbe, timebox della riunione in modo da non passare molto tempo a creare regole e discutere sulle regole.

Alcuni pensieri, gli IDE moderni hanno un plugin checkstyle per avvisare le persone quando alcune regole sono state violate, il team può essere d'accordo solo per controllare durante la revisione del codice prima di impegnarsi. Ciò aiuta anche la mia squadra.

• Qualunque IDE che non ti faccia sviluppare più velocemente non è uno strumento, è un ancora per barche Buttalo fuori bordo e non guardare mai indietro.
• Se hai già un'infrastruttura di CI, usala dal giorno 1. Ti ringrazierai più tardi, anche se riuscirai davvero a buttare fuori il tuo codice prototipo.
• Al contrario, non perdere tempo a configurare un sistema di CI se non ne hai uno. Il costo è troppo alto e speri davvero di ricominciare da capo.
• Inizia con un VCS il giorno 1. Periodo.

Suggerirei di iniziare ad implementare il concetto di un ambiente di lavoro unitario una volta che la velocità della squadra inizia a stabilizzarsi. Ciò potrebbe causare alcuni problemi tecnici all'inizio del progetto, ma c'è sempre un ufficio tecnico all'inizio di qualsiasi progetto. :)

Di solito ho successo nel permettere all'aspetto auto-organizzativo di una squadra di trovare qualcosa che sia appropriato per loro e le loro esigenze. Fondamentalmente presenta al team una descrizione di un problema, come il fallimento di Jenkin Builds e fornisce loro l'opportunità di "risolverlo".

Questo di solito comporta un'implementazione minima di una soluzione, proprio come Zachary Yates menzionato nella sua risposta.

Vorrei notare che conterebbe a tuo favore se hai qualcuno di un alto livello di abilità tecnica / posizione che fornisce una guida sottile, solo per aiutare la squadra a non diventare strana con quello che decide di andare con. :)