Ciao amici. Spesso, soprattutto nell'outsourcing, vedo sempre la stessa situazione. La mancanza di un processo di lavoro chiaro nei team su vari progetti.
La cosa più importante è che i programmatori non comprendono come comunicare con il cliente e tra loro. Come costruire un processo continuo di sviluppo di un prodotto di qualità. Come pianificare la propria giornata lavorativa e gli sprint.
E tutto questo porta a scadenze saltate, straordinari, continui colloqui su chi è colpevole e insoddisfazione dei clienti — dove e come si sta andando. Molto spesso, tutto ciò porta al cambio di programmatori e a volte di interi team. Alla perdita di clienti, al deterioramento della reputazione e così via.
Una volta mi sono trovato proprio su un progetto con tutte queste problematiche.
Nessuno voleva prendersi responsabilità per il progetto (un grande marketplace di servizi), c'era un'incredibile rotazione del personale e il cliente era davvero difficile. Un giorno, il CEO si è avvicinato a me e mi ha detto che avevo l'esperienza necessaria, quindi mi ha passato la palla. Prendi il progetto. Se fallisci, chiudiamo il tutto e tutti saranno licenziati. Se ce la fai, sarà fantastico, quindi gestiscilo e sviluppalo come ritieni opportuno. Alla fine, sono diventato il team leader del progetto e tutto è ricaduto sulle mie spalle.
La prima cosa che ho fatto è stata sviluppare un workflow da zero, che corrispondeva alla mia visione di quel momento, e ho redatto una descrizione del lavoro per il team. Implementarlo non è stato facile. Ma dopo circa un mese, tutto si è sistemato; gli sviluppatori e il cliente si erano abituati, e tutto è iniziato a procedere in modo tranquillo e confortevole. Per mostrare al team che non si trattava solo di una «tempesta in un bicchiere d'acqua», ma di una vera soluzione, ho assunto il massimo carico di responsabilità, liberando il team dalla routine sgradevole.
Sono già passati un anno e mezzo e il progetto sta proseguendo senza straordinari, senza "corsa dei topi" e senza stress di vario genere. Alcuni membri del team originale non volevano lavorare in questo modo e se ne sono andati, mentre altri hanno apprezzato molto le regole trasparenti. Alla fine, tutti coloro che sono nel team sono molto motivati e conoscono a menadito il progetto, sia per quanto riguarda il frontend che il backend, inclusa la base di codice e tutta la logica di business. Siamo arrivati al punto in cui non siamo solo "rematori", ma siamo noi stessi a ideare molti processi aziendali e nuove funzionalità che sono piaciute all'azienda.
Grazie a questo approccio da parte nostra, il cliente ha deciso di commissionare alla nostra azienda un altro marketplace, il che non può che farci piacere.
Dato che sul mio progetto ciò funziona, potrebbe anche essere utile a qualcun altro. Quindi, ecco il processo che ci ha aiutato a salvare il progetto:
Processo di lavoro del team nel progetto "Il mio progetto preferito"
a) Processo interno del team (tra sviluppatori)
- Tutti i compiti vengono creati nel sistema Jira
- Ogni compito deve essere descritto in modo massimo e deve eseguire un'azione specifica
- Qualsiasi funzionalità, se sufficientemente complessa, viene suddivisa in molte piccole attività
- Il team lavora sulle funzionalità come un'unica attività. Iniziamo a creare insieme una funzionalità, la mettiamo in test e poi passiamo alla successiva.
- Ogni attività è contrassegnata come backend o frontend.
- Esistono tipi di attività e bug. È necessario specificarli correttamente.
- Dopo aver completato un'attività, viene cambiato lo status in revisione del codice (viene creato un pull request verso il proprio collega).
- Colui che ha eseguito il compito tiene traccia subito del suo tempo per questa attività.
- Dopo il controllo del codice, il PR viene approvato e, dopo ciò, chi ha svolto il compito lo unisce autonomamente nel ramo master, cambiando successivamente il suo status in pronto per il deployment su dev. un server.
- Tutte le attività pronte per il deployment su dev vengono gestite dal team leader (è di sua responsabilità), a volte da un membro del team, se c'è qualcosa di urgente. Dopo il deployment, tutte le attività pronte per il deployment su dev vengono cambiate in stato — pronte per il testing su dev.
- Tutte le attività vengono testate dal cliente.
- Quando il cliente ha testato l'attività su dev, la cambia in stato pronto per il deployment su prod.
- Per il deployment su prod abbiamo un ramo separato, in cui uniamo il master solo prima del deployment.
- Se durante i test il committente trova dei bug, restituisce il compito per le modifiche, assegnandogli lo stato 'ritorno per modifica'. In questo modo separiamo i nuovi compiti da quelli che non hanno superato il test.
- Alla fine, tutti i compiti seguono un percorso 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 autonomamente, incluso come utente del sito. Non è consentito unire il branch principale se non si è certi che il codice funzioni.
- Ogni compito ha delle priorità. Le priorità sono impostate dal committente o dal team leader.
- Gli sviluppatori si concentrano prima sui compiti prioritari.
- Gli sviluppatori possono assegnare compiti tra loro se sono stati trovati diversi bug nel sistema o se un compito è composto dal lavoro di più specialisti.
- Tutti i compiti creati dal committente vanno al team leader, il quale li valuta e chiede al committente di modificarli o li assegna a un membro del team.
- Tutte le attività pronte per il deployment su dev o prod vengono inviate anche al team leader, il quale decide autonomamente quando e come effettuare il deployment. Dopo ogni deployment, il team leader (o un membro del team) deve informare il cliente. Inoltre, deve aggiornare lo stato delle attività a 'pronto per testing' su dev/prod.
- Ogni giorno alla stessa ora (nel nostro caso alle 12:00) teniamo una riunione tra tutti i membri del team.
- Durante la riunione, ciascun membro relaziona, inclusi il team leader, su cosa ha fatto ieri, cosa prevede di fare oggi e quali problemi sta incontrando e perché. In questo modo, l'intero team è a conoscenza di chi sta facendo cosa e a che punto si trova il progetto. Questo ci consente di prevedere e correggere, se necessario, le nostre stime e scadenze.
- Durante la riunione, il team leader comunica anche tutte le modifiche al progetto e il livello attuale dei bug trovati che non sono stati segnalati dal cliente. Tutti i bug vengono discussi e assegnati a ciascun membro del team per la loro risoluzione.
- Durante la riunione, il team leader assegna a ciascun membro del team dei compiti, tenendo conto del carico attuale dei programmatori, del loro livello di preparazione professionale e della prossimità di ciascun compito a quello che il programmatori stanno realizzando al momento.
- In riunione, il team leader sviluppa una strategia comune per l'architettura e la logica di business. Successivamente, l'intero team discute e decide se apportare modifiche o adottare questa strategia.
- Ogni sviluppatore scrive il codice e costruisce gli algoritmi autonomamente nell'ambito di un'architettura e logica di business comuni. Ognuno può esprimere la propria visione di implementazione, ma nessuno viene costretto a farlo in un determinato modo. Ogni decisione è giustificata. Se esiste una soluzione migliore, ma al momento non c'è tempo per implementarla, viene creata un'attività in JIRA per il futuro refactoring di una determinata parte del codice.
- Quando uno sviluppatore prende in carico un compito, lo passa allo stato di sviluppo. Tutta la comunicazione riguardante il chiarimento del compito con il cliente ricade sulle spalle dello sviluppatore. Questioni di natura tecnica possono essere poste al team leader o ai colleghi.
- Se lo sviluppatore non comprende il compito, e il cliente non è riuscito a spiegarlo chiaramente, allora passerà al compito successivo. Il team leader assume il compito corrente e ne discute personalmente con il cliente.
- Ogni giorno, lo sviluppatore deve scrivere nel chat del cliente riguardo a quali compiti ha lavorato ieri e quali compiti lavorerà oggi.
- Il processo di lavoro avviene secondo la metodologia Scrum. Tutto è suddiviso in sprint. Ogni sprint dura due settimane.
- Gli sprint sono creati, riempiti e chiusi dal team leader.
- Se il progetto ha scadenze rigorose, cerchiamo di stimare tutti i compiti. E li raccogliamo in uno sprint. Se il cliente cerca di aggiungere ulteriori compiti allo sprint, allora stabiliamo le priorità e rimandiamo alcuni altri compiti al prossimo sprint.
b) Processo di lavoro con il cliente
- Ogni sviluppatore può e deve comunicare con il cliente.
- Non si può permettere al cliente di imporre le proprie regole. È necessario far capire al cliente, in modo cortese e amichevole, che siamo esperti nel nostro campo e che solo noi dobbiamo definire i processi di lavoro e coinvolgerlo in essi.
- È fondamentale, preferibilmente prima di procedere all'implementazione di qualsiasi funzionalità, creare un diagramma di flusso dell'intero processo logico per la caratteristica (workflow). E inviarlo per conferma al cliente. Questo riguarda solo le funzionalità complesse e non evidenti, come il sistema di pagamento, il sistema di notifiche, ecc. Questo permetterà di comprendere meglio ciò che desidera il cliente, mantenere la documentazione della funzionalità e proteggersi dall'eventualità che il cliente possa dire in futuro che abbiamo realizzato qualcosa di diverso da quanto richiesto.
- Tutti i diagrammi/diagrammi di flusso/logiche, ecc. vengono salvati in Confluence/Jira, dove chiediamo al cliente di confermare nei commenti la correttezza della futura implementazione.
- Cerchiamo di non sovraccaricare il cliente con dettagli tecnici. Se abbiamo bisogno di comprendere come desidera il cliente, disegniamo algoritmi primitivi sotto forma di diagrammi di flusso, che il cliente può capire e modificare/correggere da solo.
- Se il cliente trova un bug nel progetto, chiediamo di descriverlo in dettaglio su Jira. Quali circostanze lo hanno causato, quando è successo e quale sequenza di azioni ha eseguito il cliente durante i test. Chiediamo di allegare screenshot.
- Cerchiamo di fare il deploy sul server di sviluppo ogni giorno, al massimo ogni due giorni. In questo modo il cliente inizia a testare le funzionalità e il progetto non subisce pause. Questo serve anche come segnale per il cliente che il progetto è in pieno sviluppo e nessuno gli racconta storie.
- Spesso accade che il cliente non comprenda completamente ciò di cui ha realmente bisogno. Poiché sta creando un nuovo business con processi ancora da affinare. Di conseguenza, è frequente che nel processo buttiamo nel cestino interi pezzi di codice e riadattiamo la logica dell'applicazione. Questo porta alla conclusione che non è necessario coprire tutto con i test. Ha senso testare solo le funzionalità critiche, e anche in questo caso con delle riserve.
- Ci sono situazioni in cui il team si accorge di non rispettare le scadenze. In tal caso, conduciamo un'audit rapida delle attività e informiamo immediatamente il cliente. Come soluzione, proponiamo di lanciare in tempo le funzionalità importanti e critiche, mentre il resto può essere lasciato per il post-release.
- Se il cliente inizia a inventare vari compiti e a spiegare a gesti, allora gli chiediamo di fornirci un mockup della pagina e un flusso con la logica, che deve descrivere completamente il comportamento dell'intero layout e dei suoi elementi.
- Prima di prendere in carico qualsiasi compito, dobbiamo assicurarci che questa funzionalità fosse inclusa nei termini del nostro contratto. Se si tratta di una nuova funzionalità che va oltre i nostri accordi iniziali, dobbiamo necessariamente stimare il tempo di realizzazione di questa funzionalità ((tempo di esecuzione stimato + 30%) x 2) e informare il cliente che ci vorranno così tanto tempo, e che la scadenza sarà posticipata di un periodo pari alla stima moltiplicata per due. Se completiamo il compito prima del previsto, sarà fantastico, ne trarranno vantaggio tutti. Se no, ci siamo tutelati.
v) Cosa non accettiamo nella squadra:
- Non obbligatorietà, disorganizzazione, dimenticanza
- “Nutrire di promesse”. Se non puoi completare un compito o non sai come farlo, devi comunicarlo immediatamente al team leader, non aspettare fino all'ultimo.
- Sbrodolamenti e vanterie da parte di chi non ha ancora dimostrato con i fatti le proprie capacità e professionalità. Se l'ha dimostrato, allora può farlo, sempre nei limiti del buonsenso 🙂
- Inganno in tutte le sue forme. Se un compito non è completato, non si deve cambiare il suo stato in completato né comunicare al cliente che è pronto. Il computer si è rotto, il sistema è andato in crash, il cane ha rosicchiato il portatile — tutto ciò è inaccettabile. Se c'è un reale caso di forza maggiore, il team leader deve essere immediatamente avvisato.
- Quando uno specialista è sempre offline e difficile da contattare durante l'orario lavorativo.
- La tossicità nel team non è tollerata! Se qualcuno non è d'accordo, tutti insieme si riuniscono per discutere e risolvere la questione.
E un altro paio di domande/tesi che a volte pongo al mio cliente per chiarire ogni malinteso:
- Quali sono i vostri criteri di qualità?
- Come definite se ci sono problemi nel progetto o meno?
- Sconvolgendo tutte le nostre raccomandazioni e consigli per modificare/migliorare il sistema, tutti i rischi sono a tuo carico.
- Qualsiasi modifica sostanziale al progetto (ad esempio, flussi extra) potrebbe portare all'insorgere di bug (che noi naturalmente correggeremo).
- È impossibile capire in pochi minuti quale sia il problema del progetto, e tanto meno risolverlo immediatamente.
- Lavoriamo secondo un flusso di prodotto specifico (Task in Jira — Sviluppo — Test — Deployment). Questo significa che non possiamo reagire a tutte le richieste e lamentele nel chat.
- I programmatori sono programmatori e non professionisti del testing, e non possono garantire un’adeguata qualità nel testing del progetto.
- La responsabilità per il collaudo finale e l'accettazione delle attività in produzione ricade interamente su di te.
- Se abbiamo già avviato un'attività, non possiamo subito passare ad altre finché non completiamo quella attuale (altrimenti si verificheranno ulteriori bug e ci vorrà più tempo per lo sviluppo).
- Il numero di persone nel team è diminuito (a causa di ferie o malattie), mentre il carico di lavoro è aumentato e fisicamente non riusciremo a soddisfare tutte le vostre richieste.
- Richiesta da parte vostra di effettuare il deploy in produzione senza compiti testati in sviluppo: sono solo i vostri rischi, non quelli degli sviluppatori.
- Quando formulate compiti poco chiari, senza un flusso corretto e senza layout di design, questo richiede da noi sforzi e tempi di realizzazione molto maggiori, poiché tocca a noi svolgere un volume di lavoro aggiuntivo al posto vostro.
- Qualsiasi task sui bug, senza una descrizione dettagliata della loro origine e screenshot, non ci consente di capire cosa sia andato storto e come simulare quel bug.
- Il progetto richiede costante aggiornamento e miglioramenti per aumentare le prestazioni e la sicurezza. Pertanto, il team dedica parte del proprio tempo a questi miglioramenti.
- Poiché a volte abbiamo ore extra da compensare (fix urgenti), dobbiamo recuperarle in altri giorni.
Di solito, il cliente comprende subito che non è tutto così semplice nello sviluppo software e che un semplice desiderio non è affatto sufficiente.
In generale questo è tutto. Dietro le quinte lascio molte trattative e la messa a punto iniziale di tutti i processi, ma alla fine tutto è andato a posto. Posso dire che questo processo è diventato per noi una sorta di «Proiettile d'Argento». Le nuove persone che si univano al progetto potevano già iniziare a lavorare dal primo giorno, poiché tutti i processi sono descritti e la documentazione e l'architettura, sotto forma di diagrammi, forniscono immediatamente un'idea di cosa facciamo qui.
P. S. Voglio precisare che non abbiamo un project manager dalla nostra parte. È presente dalla parte del cliente. Non è affatto un tecnico. Il progetto è europeo. Tutta la comunicazione avviene solo in inglese.
Buona fortuna a tutti nei progetti. Non bruciatevi e cercate di migliorare i vostri processi.
Il sorgente nel mio .
Fonte: habr.com
