🥇Organizzazione del flusso di lavoro in team su un progetto IT

Ciao amici. Molto spesso, soprattutto nell'outsourcing, vedo la stessa immagine. La mancanza di un flusso di lavoro chiaro nei team su vari progetti.

La cosa più importante è che i programmatori non capiscono come comunicare con il cliente e tra loro. Come costruire un processo continuo di sviluppo di un prodotto di qualità. Come pianificare la giornata lavorativa e gli sprint.

E tutto ciò alla fine si traduce in scadenze non rispettate, straordinari, continui scontri su chi è la colpa e insoddisfazione dei clienti: dove e come tutto si sta muovendo. Molto spesso, tutto ciò porta a un cambio di programmatori e persino a interi team. Perdita di un cliente, deterioramento della reputazione e così via.

Un tempo, ho appena iniziato un progetto del genere, dove c'erano tutte queste delizie.

Nessuno voleva assumersi la responsabilità del progetto (un grande mercato di servizi), il fatturato era terribile, il cliente era semplicemente combattuto e frustrato. L'amministratore delegato una volta è venuto da me e mi ha detto che hai l'esperienza necessaria, quindi ecco le carte nelle tue mani. Prendi il progetto per te. Se sbagli, chiuderemo il progetto e cacceremo tutti fuori. Funzionerà, sarà bello, quindi guidalo e sviluppalo come ritieni opportuno. Di conseguenza, sono diventato il team leader del progetto e tutto è ricaduto sulle mie spalle.

La prima cosa che ho fatto è stata progettare da zero un flusso di lavoro che corrispondesse alla mia visione in quel momento e scrivere una descrizione del lavoro per il team. Implementarlo non è stato facile. Ma da qualche parte nel giro di un mese tutto si è sistemato, gli sviluppatori e il cliente si sono abituati e tutto è andato in silenzio e comodamente. Per dimostrare alla squadra che questa non è solo una tempesta in un bicchiere, ma una vera via d'uscita dalla situazione, mi sono assunto il massimo delle responsabilità, eliminando la spiacevole routine dalla squadra.

È già passato un anno e mezzo e il progetto si sta sviluppando senza straordinari, senza "corse al successo" e ogni sorta di stress. Qualcuno nella vecchia squadra non voleva lavorare così e se n'è andato, anzi, qualcuno si è davvero appassionato che sono apparse regole trasparenti. Ma di conseguenza, tutti i membri del team sono molto motivati e conoscono a fondo l'enorme progetto, sia front-end che back-end. Includendo sia la base di codice che tutta la logica aziendale. Siamo persino arrivati \uXNUMXb\uXNUMXbal punto che non siamo solo "vogatori", ma noi stessi escogitiamo molti processi aziendali e nuove funzionalità che piacciono all'azienda.

Grazie a questo approccio da parte nostra, il cliente ha deciso di ordinare un altro marketplace dalla nostra azienda, il che è una buona notizia.

Dato che funziona sul mio progetto, forse aiuterà anche qualcuno. Quindi, il processo stesso, che ci ha aiutato a salvare il progetto:

Il processo di lavoro di squadra sul progetto "Il mio progetto preferito"

a) All'interno di un processo di gruppo (tra sviluppatori)

Tutti i problemi vengono creati nel sistema Jira
Ogni attività dovrebbe essere descritta il più possibile ed eseguire rigorosamente un'azione.
Qualsiasi caratteristica, se è abbastanza complessa, è suddivisa in tante piccole attività
Il team lavora sulle funzionalità come un'unica attività. Per prima cosa, realizziamo una caratteristica insieme, la diamo per il test, quindi prendiamo la successiva.
Ogni attività è contrassegnata, sia per il backend che per il frontend
Esistono tipi di attività e bug. Devi specificarli correttamente.
Dopo che l'attività è stata completata, viene trasferita allo stato di revisione del codice (viene creata una richiesta pull per il suo collega)
Colui che ha completato l'attività tiene immediatamente traccia del suo tempo per questa attività
Dopo aver controllato il codice, il PR lo approverà e, successivamente, colui che ha eseguito questa attività in modo indipendente lo unisce al ramo principale, dopodiché cambia il suo stato in pronto per la distribuzione sul server di sviluppo.
Tutte le attività pronte per essere distribuite al server di sviluppo vengono distribuite dal caposquadra (la sua area di responsabilità), a volte un membro del team, se qualcosa è urgente. Dopo la distribuzione, tutte le attività da pronto per la distribuzione a dev vengono trasferite allo stato - pronto per il test su dev
Tutte le attività sono testate dal cliente
Quando il cliente ha testato l'attività sullo sviluppatore, la trasferisce allo stato pronto per la distribuzione in produzione.
Per la distribuzione alla produzione, abbiamo un ramo separato in cui uniamo il master appena prima della distribuzione
Se durante il test il cliente trova dei bug, restituisce l'attività per la revisione, impostando il suo stato restituito per la revisione. Questo è il modo in cui separiamo le nuove attività da quelle che non sono state testate.
Di conseguenza, tutte le attività vanno dalla creazione al completamento: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
Ogni sviluppatore testa il proprio codice in modo indipendente, anche come utente del sito. Non è consentito unire un ramo con quello principale, a meno che non si sappia con certezza che il codice funziona.
Ogni compito ha delle priorità. Le priorità vengono stabilite dal cliente o dal team leader.
Gli sviluppatori svolgono prima le attività prioritarie.
Gli sviluppatori possono assegnarsi compiti l'un l'altro se nel sistema sono stati rilevati diversi bug o un'attività è costituita dal lavoro di diversi specialisti.
Tutte le attività create dal cliente vengono inviate al caposquadra, che le valuta e chiede al cliente di finalizzarle oppure le assegna a uno dei membri del team.
Tutte le attività che sono pronte per essere distribuite a dev o prod arrivano anche al team leader, che determina autonomamente quando e come distribuire. Dopo ogni implementazione, il team leader (o il membro del team) deve informare il cliente di ciò. E cambia anche gli stati per le attività in pronto per il test su dev / prod.
Ogni giorno alla stessa ora (ce l'abbiamo alle 12.00) teniamo un raduno tra tutti i membri del team
Tutti al rally raccontano, compreso il caposquadra, cosa ha fatto ieri, cosa ha intenzione di fare oggi. Cosa non funziona e perché. Pertanto, l'intero team è consapevole di chi sta facendo cosa e in quale fase si trova il progetto. Questo ci dà l'opportunità di prevedere e adeguare, se necessario, le nostre stime e scadenze.
Durante l'incontro, il team leader annuncia anche tutte le modifiche al progetto e il livello dei bug attuali che non sono stati trovati dal cliente. Tutti i bug vengono risolti e assegnati a ciascun membro del team per risolverli.
Alla manifestazione, il caposquadra assegna compiti a ciascuno, tenendo conto dell'attuale carico di lavoro degli sviluppatori, del loro livello di formazione professionale e tenendo conto anche della vicinanza di un determinato compito a ciò che lo sviluppatore sta attualmente svolgendo.
Durante l'incontro, il leader del team sviluppa una strategia generale per l'architettura e la logica aziendale. Dopodiché l'intero team ne discute e decide di apportare modifiche o adottare questa strategia.
Ogni sviluppatore scrive codice e crea algoritmi in modo indipendente all'interno di un'unica architettura e logica di business. Tutti possono esprimere la propria visione di implementazione, ma nessuno obbliga nessuno a farlo in questo modo e non altrimenti. Ogni decisione è giustificata. Se esiste una soluzione migliore, ma ora non c'è tempo per farlo, viene creata un'attività in fat, per il futuro refactoring di una certa parte del codice.
Quando uno sviluppatore assume un'attività, la sposta nello stato di sviluppo. Tutte le comunicazioni relative al chiarimento dell'attività con il cliente ricadono sulle spalle dello sviluppatore. Le domande tecniche possono essere poste al capogruppo o ai colleghi.
Se lo sviluppatore non comprende l'essenza dell'attività e il cliente non è stato in grado di spiegarla chiaramente, passa all'attività successiva. E il responsabile del team prende quello attuale e lo discute con il cliente.
Ogni giorno, lo sviluppatore dovrebbe scrivere nella chat del cliente su quali attività ha lavorato ieri e su quali attività lavorerà oggi
Il flusso di lavoro è basato su Scrum. Tutto è diviso in sprint. Ogni sprint dura due settimane.
Gli sprint vengono creati, compilati e chiusi dal caposquadra.
Se il progetto ha scadenze rigorose, proviamo a stimare approssimativamente tutte le attività. E raccogliamo da loro uno sprint. Se il cliente tenta di aggiungere più attività allo sprint, stabiliamo le priorità e trasferiamo alcune altre attività allo sprint successivo.

b) Il processo di collaborazione con il cliente

Ogni sviluppatore può e deve comunicare con il cliente
Non puoi permettere al cliente di imporre le proprie regole del gioco. È necessario in modo educato e amichevole far capire al cliente che siamo specialisti nel nostro campo, e solo noi dovremmo costruire processi di lavoro e coinvolgere il cliente in essi
È necessario, idealmente, prima di procedere con l'implementazione di qualsiasi funzionalità, creare un diagramma di flusso dell'intero processo logico per una funzionalità (flusso di lavoro). E invialo al cliente per la conferma. Questo vale solo per funzionalità complesse e non ovvie, ad esempio un sistema di pagamento, un sistema di notifica, ecc. Ciò ti consentirà di comprendere più accuratamente di cosa ha esattamente bisogno il cliente, salvare la documentazione per la funzione e anche assicurarti contro il fatto che il cliente possa dire in futuro che non abbiamo fatto ciò che ha chiesto.
Tutti i diagrammi/diagrammi di flusso/logica ecc. salviamo in Confluence/Fat, dove chiediamo al cliente nei commenti di confermare la correttezza della futura implementazione.
Cerchiamo di non appesantire il cliente con dettagli tecnici. Se abbiamo bisogno di capire come vuole il cliente, disegniamo algoritmi primitivi sotto forma di un diagramma di flusso che il cliente può comprendere e correggere / modificare tutto da solo.
Se il cliente trova un bug nel progetto, ti chiediamo di descriverlo dettagliatamente in Fat. In quali circostanze si è verificato, quando, quale sequenza di azioni è stata eseguita dal cliente durante il test. Si prega di allegare screenshot.
Proviamo ogni giorno, al massimo a giorni alterni, a distribuire sul server di sviluppo. Il cliente inizia quindi a testare la funzionalità e il progetto non è inattivo. Allo stesso tempo, questo è un segnale per il cliente che il progetto è in pieno sviluppo e nessuno gli racconta favole.
Accade spesso che il cliente non comprenda appieno ciò di cui ha bisogno. Dal momento che crea una nuova attività per se stesso, con processi che non sono ancora stati sottoposti a debug. Pertanto, un caso molto comune è quando gettiamo interi pezzi di codice nel cestino e rimodelliamo la logica dell'applicazione. Ne consegue che non è necessario coprire assolutamente tutto con i test. Ha senso coprire solo le funzionalità critiche con i test e quindi con le prenotazioni.
Ci sono situazioni in cui il team si rende conto che non rispettiamo le scadenze. Quindi conduciamo un rapido controllo delle attività e ne informiamo immediatamente il cliente. Per uscire dalla situazione, suggeriamo di lanciare funzionalità importanti e critiche in tempo e di lasciare il resto per il post-rilascio.
Se il cliente inizia a escogitare compiti diversi dalla sua testa, inizia a fantasticare e a spiegare con le dita, allora gli chiediamo di fornirci un layout di pagina e un flusso logico che dovrebbe descrivere completamente il comportamento dell'intero layout e il suo elementi.
Prima di intraprendere qualsiasi attività, dobbiamo assicurarci che questa funzione sia stata inclusa nei termini del nostro accordo/contratto. Se si tratta di una nuova funzionalità che va oltre i nostri accordi iniziali, allora dobbiamo assolutamente stimare questa funzionalità ((tempo di consegna approssimativo + 30%) x 2) e indicare al cliente che ci vorrà così tanto tempo per completarla, più la scadenza viene spostata per il tempo stimato moltiplicato per due. Rendiamo il compito più veloce: fantastico, tutti ne trarranno vantaggio. In caso contrario, siamo assicurati.

c) Cosa non accettiamo nel team:

Incoerenza, incoerenza, dimenticanza
"Alimentazione a colazione". Se non riesci a completare l'attività, non sai come, devi informare immediatamente il caposquadra e non aspettare fino all'ultimo.
Brovada e vanto di una persona che non ha ancora dimostrato le sue capacità e professionalità con i fatti. Se dimostrato, allora è possibile, nei limiti della decenza 🙂
La frode in tutte le sue manifestazioni. Se l'attività non è stata completata, non modificare il suo stato in completato e scrivere nella chat del cliente che è pronto. Il computer si è bloccato, il sistema si è bloccato, il cane ha masticato il laptop: tutto questo è inaccettabile. Se si verifica una vera forza maggiore, il capogruppo deve essere immediatamente informato.
Quando uno specialista è sempre offline ed è difficile raggiungerlo durante l'orario di lavoro.
La tossicità nella squadra non è consentita! Se qualcuno non è d'accordo con qualcosa, tutti si riuniscono per una manifestazione, discutono e decidono.

E una serie di domande/tesi che a volte pongo al mio cliente per togliere ogni malinteso:

Quali sono i tuoi criteri di qualità?
Come si determina se un progetto presenta problemi o meno?
Violando tutte le nostre raccomandazioni e consigli su come cambiare/migliorare il sistema, tutti i rischi sono a tuo carico
Eventuali modifiche importanti al progetto (ad esempio, tutti i tipi di flusso extra) porteranno alla possibile comparsa di bug (che, ovviamente, correggeremo)
È impossibile capire in un paio di minuti che tipo di problema si è verificato sul progetto, e ancor di più risolverlo proprio lì
Lavoriamo su un flusso di prodotto specifico (Attività in Zhira - Sviluppo - Test - Distribuzione). Ciò significa che non possiamo rispondere all'intero flusso di richieste e reclami nella chat.
I programmatori sono solo programmatori, non tester professionisti e non possono garantire la corretta qualità del test del progetto
La responsabilità per il collaudo finale e l'accettazione degli incarichi sulla vendita ricade interamente su di te
Se abbiamo già assunto un compito, non possiamo passare immediatamente ad altri fino a quando non completiamo quello attuale (altrimenti questo porta a ancora più bug e un aumento dei tempi di sviluppo)
Ci sono meno persone nel team (a causa di ferie o malattie), ma c'è più lavoro e fisicamente non avremo il tempo di rispondere a tutto ciò che desideri
Chiederti di distribuire in produzione senza attività testate su dev è solo un tuo rischio, non quello dello sviluppatore
Quando imposti attività fuzzy, senza un flusso corretto, senza layout di progettazione, ciò richiede molto più impegno e tempo di implementazione da parte nostra, poiché dobbiamo svolgere una quantità aggiuntiva di lavoro al tuo posto
Qualsiasi attività sui bug, senza una descrizione dettagliata della loro presenza e schermate, non ci dà l'opportunità di capire cosa è andato storto e come possiamo emettere questo bug
Il progetto richiede un costante perfezionamento e miglioramenti per migliorare le prestazioni e la sicurezza. Pertanto, il team dedica parte del suo tempo a questi miglioramenti.
A causa del fatto che abbiamo ore di straordinario (correzioni urgenti), dobbiamo compensarle negli altri giorni

Di norma, il cliente capisce immediatamente che non tutto è così semplice nello sviluppo del software e il desiderio da solo chiaramente non è sufficiente.

In generale, questo è tutto. Dietro le quinte, lascio molte trattative e il debug iniziale di tutti i processi, ma alla fine tutto ha funzionato. Posso dire che questo processo è diventato per noi una specie di "proiettile d'argento". Le nuove persone che sono venute al progetto potrebbero già mettersi subito al lavoro dal primo giorno, poiché tutti i processi sono descritti e la documentazione e l'architettura sotto forma di diagrammi hanno dato immediatamente un'idea di cosa stiamo facendo tutti Qui.

PS Ci tengo a precisare che dalla nostra parte non c'è nessun project manager. È dalla parte del cliente. Non è affatto un tecnico. progetto europeo. Tutte le comunicazioni sono solo in inglese.

Buona fortuna a tutti per i vostri progetti. Non esaurirti e cerca di migliorare i tuoi processi.

fonte nel mio blog.

Fonte: habr.com