Salutami amichi. Piuttostu spessu, soprattuttu in l'outsourcing, vecu a stessa stampa. Mancanza di un flussu di travagliu chjaru in squadre nantu à diversi prughjetti.
A più impurtante hè chì i programatori ùn capiscenu micca cumu cumunicà cù u cliente è cù l'altri. Cumu custruisce un prucessu cuntinuu di sviluppà un pruduttu di qualità. Cumu pianificà a vostra ghjurnata di travagliu è sprints.
È tuttu questu in ultimamente risultati in scadenze mancate, ore supplementari, cunfronti constanti nantu à quale hè a culpa, è insatisfazione di i clienti induve è cumu si move tuttu. Piuttostu spessu, tuttu questu porta à un cambiamentu di programatori, o ancu squadre intere. Perdita di un cliente, deterioramentu di a reputazione, etc.
À un tempu, aghju ghjustu finitu nantu à un tali prughjettu, induve ci eranu tutti issi piacè.
Nimu ùn vulia piglià a rispunsabilità di u prughjettu (un grande mercatu di serviziu), u fatturatu era terribili, u cliente era simplicemente strappatu è frustratu. U CEO una volta hè ghjuntu à mè è hà dettu chì avete l'esperienza necessaria, dunque quì sò e carte in e vostre mani. Pigliate u prugettu per voi stessu. S'ellu vi sguassate, chjuderemu u prugettu è cacciate tutti. Funcionarà, sarà cool, poi guidà è sviluppallu cum'è vo vulete. In u risultatu, sò diventatu u capu di squadra per u prugettu è tuttu hè cascatu nantu à e mo spalle.
A prima cosa ch'e aghju fattu hè di sviluppà un flussu di travagliu da zero chì si allineava cù a mo visione à u mumentu, è hà scrittu una descrizzione di u travagliu per a squadra. Implementà ùn era micca faciule. Ma in un mesi o più tuttu si stalla, i sviluppatori è u cliente si sò abituati, è tuttu andò tranquillamente è cunfortu. Per dimustrà a squadra chì questu ùn era micca solu una "tempesta in una tazza di tè", ma una vera manera di esce da a situazione, aghju pigliatu u massimu di rispunsabilità, sguassendu a rutina dispiacevule da a squadra.
Un annu è mezu hè digià passatu, è u prughjettu si sviluppa senza overtime, senza "razze di rat" è ogni tipu di stress. Certi persone in u vechju squadra ùn vulianu micca travaglià cusì è si n'andò; altri, à u cuntrariu, eranu assai cuntenti chì e regule trasparenti eranu apparsu. Ma à a fine, tutti in a squadra sò assai motivati è cunnoscenu u prughjettu enormu in tuttu, cumpresu u front-end è u back-end. Includendu sia a basa di codice è tutta a logica cummerciale. Hè ancu ghjuntu à u puntu chì ùn simu micca solu "remi", ma noi stessi venenu cù assai prucessi di cummerciale è funzioni novi chì l'affari diventanu piace.
Grazie à questu approcciu da a nostra parte, u cliente hà decisu di urdinà un altru mercatu da a nostra cumpagnia, chì hè una bona nutizia.
Siccomu questu travaglia nantu à u mo prughjettu, forse ancu aiutà à qualchissia. Allora, u prucessu stessu chì ci hà aiutatu à salvà u prugettu:
U prucessu di travagliu in squadra nantu à u prughjettu "U mo prughjettu preferitu"
a) Prucessu internu di a squadra (trà i sviluppatori)
- Tutti i prublemi sò creati in u sistema Jira
- Ogni compitu deve esse descrittu quantu pussibule è eseguisce strettamente una azione
- Ogni funziunalità, s'ellu hè abbastanza cumplessu, hè spartutu in parechji picculi compiti
- A squadra travaglia nantu à e funzioni cum'è un compitu unicu. Prima, tutti travagliammu inseme nantu à una funzione, mandate per a prova, poi pigliate a prossima.
- Ogni compitu hè marcatu, per u backend o frontend
- Ci sò tipi di compiti è bugs. Avete bisognu à indicà bè.
- Dopu avè finitu un compitu, hè trasferitu à u statutu di rivisione di codice (in questu casu, una dumanda di pull hè creata per un cullega)
- A persona chì hà finitu u compitu seguita immediatamente u so tempu per questu compitu.
- Dopu avè verificatu u codice, u PR appruvarà è dopu, quellu chì hà realizatu stu compitu indipindentamente si fusiona in u ramu maestru, dopu chì cambia u so statutu in pronta per a implementazione à u servore dev.
- Tutti i travaglii pronti per l'implementazione à u servitore dev sò implementati da u capu di a squadra (a so zona di responsabilità), à volte da un membru di a squadra, se qualcosa hè urgente. Dopu a implementazione, tutti i travaglii da pronti per implementazione à dev sò trasferiti à u statu - pronti per a prova nantu à dev
- Tutti i travaglii sò pruvati da u cliente
- Quandu u cliente hà pruvatu u compitu nantu à u dev, u trasferisce à u statutu prontu per a implementazione à a produzzione
- Per l'implementazione à a produzzione, avemu un ramu separatu, induve unisce u maestru solu prima di implementazione
- Se durante a prova, u cliente trova bugs, torna u compitu per a revisione, stabilisce u so statutu cum'è restituitu per a revisione. In questu modu, separemu novi travaglii da quelli chì ùn anu micca passatu a prova.
- In u risultatu, tutti i travaglii passanu da a creazione à a fine: Da fà → In Sviluppu → Revisione di codice → Implementazione pronta à dev → QA in dev → (Returnà à dev) → Implementazione pronta per prod → QA on prod → Fatto
- Ogni sviluppatore prova u so codice indipindente, cumpresu cum'è utilizatore di u situ. Ùn hè micca permessu di unisce un ramu in u principale, salvu chì ùn hè micca cunnisciutu per certu chì u codice funziona.
- Ogni compitu hà priorità. E priorità sò stabilite da u cliente o da u capu di a squadra.
- I sviluppatori cumplenu prima i travaglii di priorità.
- I sviluppatori ponu assignà i travaglii à l'altri si sò stati truvati diversi bug in u sistema o un compitu hè custituitu da u travagliu di parechji specialisti.
- Tutti i travaglii chì u cliente creanu vanu à u capu di a squadra, chì l'evalueghja è dumanda à u cliente di mudificà o l'assigna à unu di i membri di a squadra.
- Tutti i travaglii chì sò pronti per l'implementazione à dev o prod passanu ancu à u capu di a squadra, chì determina indipindentamente quandu è cumu eseguisce a implementazione. Dopu ogni implementazione, u capu di a squadra (o membru di a squadra) deve avvisà u cliente nantu à questu. È cambia ancu i stati per i travaglii per pronti per a prova per dev/cont.
- Ogni ghjornu à a listessa ora (per noi hè à 12.00) facemu una riunione trà tutti i membri di a squadra
- Tutti in a riunione raportanu, cumpresu u capu di a squadra, nantu à ciò chì anu fattu eri è ciò chì pensanu di fà oghje. Chì ùn viaghja micca è perchè. In questu modu, tutta a squadra hè cuscente di quale face ciò chì è in quale stadiu hè u prughjettu. Questu ci dà l'uppurtunità di predichendu è aghjustà, se ne necessariu, i nostri stimi è e scadenze.
- À a riunione, u capu di a squadra parla ancu di tutti i cambiamenti in u prugettu è u livellu di bugs attuali chì ùn anu micca truvatu da u cliente. Tutti i bug sò risolti è assignati à ogni membru di a squadra per risolve.
- À a riunione, u capu di a squadra assigna compiti à ogni persona, tenendu in contu a carica di travagliu attuale di i sviluppatori, u so livellu di furmazione prufessiunale, è ancu tenendu in contu a vicinanza di un compitu particulari à ciò chì u sviluppatore face attualmente.
- À a riunione, u capu di a squadra sviluppa una strategia generale per l'architettura è a logica cummerciale. Dopu chì tutta a squadra discute questu è decide di fà aghjustamenti o aduttà sta strategia.
- Ogni sviluppatore scrive codice è custruisce algoritmi indipindentamente in u quadru di una sola architettura è logica cummerciale. Ognunu pò sprime a so visione di l'implementazione, ma nimu ùn obbliga à nimu à fà cusì è micca altrimenti. Ogni decisione hè ghjustificata. Se ci hè una suluzione megliu, ma ùn ci hè micca tempu per questu ora, allora un compitu hè creatu in grassu per u futuru refactoring di una certa parte di u codice.
- Quandu un sviluppatore assume un compitu, u trasferisce à u statu di sviluppu. Tutte e cumunicazioni riguardanti a clarificazione di u compitu cù u cliente cascanu nantu à e spalle di u sviluppatore. E dumande tecniche ponu esse dumandate à u capu di a squadra o à i culleghi.
- Se u sviluppatore ùn capisce micca l'essenza di u compitu, è u cliente ùn era micca capaci di spiegà chjaramente, allora procede à u prossimu compitu. È u capu di a squadra piglia l'attuale è discute cù u cliente.
- Ogni ghjornu, u sviluppatore deve scrive in u chat di u cliente nantu à quali travaglii hà travagliatu ieri è quali compiti hà da travaglià oghje.
- U prucessu di travagliu si svolge secondu Scrum. Tuttu hè divisu in sprints. Ogni sprint dura duie settimane.
- Sprints sò creati, pieni è chjusi da u capu di a squadra.
- Se u prughjettu hà scadenze strette, allora pruvemu di stima apprussimatamente tutti i travaglii. E li mettemu inseme in un sprint. Se u cliente prova di aghjunghje più attività à u sprint, allora avemu stabilitu priorità è trasfirìu qualchì altra attività à u prossimu sprint.
b) Prucessu di travaglià cù u cliente
- Ogni sviluppatore pò è deve cumunicà cù u cliente
- U cliente ùn pò micca esse permessu di impone e so regule di u ghjocu. Hè necessariu di fà chjaru à u cliente in una manera educata è amichevule chì simu spezialisti in u nostru campu, è solu avemu da custruisce prucessi di travagliu è implicanu u cliente in elli.
- Hè necessariu, idealmente, prima di cumincià à implementà qualsiasi funziunalità, per creà un diagramma di flussu di tuttu u prucessu logicu per a funzione (flussu di travagliu). È mandate à u cliente per a cunferma. Questu hè solu applicà à e funziunalità cumplessu è micca evidenti, per esempiu, un sistema di pagamentu, un sistema di notificazione, etc. Questu ci permetterà di capiscenu più precisamente ciò chì esattamente u cliente hà bisognu, salvà a documentazione per a funzione, è ancu assicurassi contru à u fattu chì u cliente pò dì in u futuru chì ùn avemu micca fattu ciò chì hà dumandatu.
- Tutti i diagrammi / diagrammi di flussu / logica etc. Salvemu in Confluence / Fat, induve dumandemu à u cliente per cunfirmà a correttezza di l'implementazione futura in i cumenti.
- Pruvemu micca di carica u cliente cù dettagli tecnichi. Se avemu bisognu di capiscenu cumu u cliente vole, allora avemu tracciatu algoritmi primitivi in forma di un diagramma di flussu chì u cliente pò capisce è curreghja / mudificà tuttu ellu stessu.
- Se u cliente trova un bug in u prughjettu, allora vi dumandemu di discrive in grande dettagliu in Zhira. In quale circustanze hè accadutu, quandu, chì sequenza di azioni hè stata realizata da u cliente durante a prova. Per piacè aghjunghje screenshots.
- Pruvemu ogni ghjornu, ogni altru ghjornu à u più, per implementà à u servitore dev. Allora u cliente principia à pruvà a funziunalità è u prugettu ùn si ferma micca. À u listessu tempu, questu hè un marcatu per u cliente chì u prugettu hè in u sviluppu sanu è nimu ùn li dice di fiaba.
- Spessu succede chì u cliente ùn capisce micca bè ciò chì hà bisognu. Perchè ellu crea una nova attività per ellu stessu, cù prucessi chì ùn sò micca stati stabiliti. Per quessa, una situazione assai cumuna hè quandu gettemu pezzi interi di codice in a basura è riprogettate a logica di l'applicazione. Hè da questu chì ùn deve micca copre assolutamente tuttu cù testi. Hè sensu per copre solu funziunalità critica cù testi, è dopu solu cù riservazioni.
- Ci sò situazioni quandu a squadra capisce chì ùn avemu micca scuntrà i termini. Allora facemu un auditu rapidu di i travaglii è informemu immediatamente à u cliente. Cum'è una manera di esce da a situazione, suggerimu di lancià funziunalità impurtante è critica à u tempu, è di lascià u restu per a post-liberazione.
- Se u cliente principia à vene cù diverse attività fora di a so testa, cumencia à fantasià è spiegà cù i so dite, allora li dumandemu di furnisce un layout di pagina è flussu cù logica chì deve descriverà cumplettamente u cumpurtamentu di tuttu u layout è i so elementi.
- Prima di piglià ogni compitu, avemu da assicurà chì sta funzione hè stata inclusa in i termini di u nostru accordu / cuntrattu. S'ellu hè una nova funzione chì va oltre i nostri accordi iniziali, allora avemu da u prezzu di sta funzione ((tempu stimatu di cumpletamentu + 30%) x 2) è indicà à u cliente chì ci volerà tantu tempu per compie, più u a scadenza hè spostata da u tempu di stima multiplicatu per dui. Facemu u compitu più veloce - grande, tutti ne prufittàranu. Se no, allora avemu cupertu.
c) Ciò chì ùn accettemu micca in una squadra:
- Uncommitment, mancanza di cumpusizioni, oblicu
- "A colazione" Se ùn pudete micca compie un compitu è ùn sapete micca cumu, allora avete bisognu di avvisà immediatamente u capu di a squadra, è ùn aspittà micca finu à l'ultimu minutu.
- Brows è si vanta di una persona chì ùn hà ancu pruvucatu e so capacità è prufessionalità. S'ellu hè pruvatu, allora hè pussibule, in i limiti di a decenza :)
- L'ingannimentu in tutte e so forme. Se un compitu ùn hè micca cumpletu, allora ùn deve micca cambià u so status à cumpletu è scrivite in u chat di u cliente chì hè pronta. L'urdinatore s'hè rottu, u sistema hà sbulicatu, u cane hà masticatu u laptop - tuttu questu hè inacceptable. Se si verifica un veru avvenimentu di forza maiò, u capu di a squadra deve esse avvisatu immediatamente.
- Quandu un specialista hè offline tuttu u tempu è hè difficiule di ghjunghje à ellu durante l'ora di travagliu.
- A toxicità in a squadra ùn hè micca permessa! Se qualchissia ùn hè d'accordu cù qualcosa, allora tutti si riuniscenu per una manifestazione è discute è decide nantu à questu.
È una quantità di dumande/tesi chì qualchì volta dumandu à u mo cliente per smachjà tutti i malintesi:
- Chì sò i vostri criteri di qualità?
- Cumu stabilisce se un prughjettu hà prublemi o micca?
- Viulendu tutte e nostre raccomandazioni è cunsiglii per cambià / migliurà u sistema, tutti i risichi sò sopr'à voi solu
- Ogni cambiamenti maiò à u prugettu (per esempiu, ogni tipu di flussu extra) portanu à l'apparizione pussibuli di bug (chì, sicuru, correggeremu)
- Hè impussibile di capiscenu in un paru di minuti chì tipu di prublema hè accadutu nantu à u prugettu, assai menu di risolve immediatamente
- Travagliemu nantu à un flussu di produttu specificu (Tasks in Zhira - Sviluppu - Testing - Deploy). Questu significa chì ùn pudemu micca risponde à tuttu u flussu di richieste è lagnanze in u chat.
- I programatori sò programatori, micca teste prufessiunali, è ùn ponu micca assicurà a qualità propria di teste di prughjettu
- A rispunsabilità per a prova finale è l'accettazione di i travaglii di produzzione hè interamente cun voi
- Se avemu digià pigliatu un compitu, ùn pudemu micca passà immediatamente à l'altri finu à chì avemu finitu l'attuale (altrimenti questu porta à ancu più bug è un tempu di sviluppu aumentatu)
- Ci hè menu persone in a squadra (per via di vacanze o di malatie), ma ci hè più travagliu è fisicamenti ùn avemu micca tempu per risponde à tuttu ciò chì vulete.
- Vi dumandemu di fà una implementazione à a produzzione senza compiti testati nantu à u dev - questu hè solu u vostru risicu, micca i sviluppatori.
- Quandu avete stabilitu compiti pocu chjaru, senza un flussu currettu, senza layout di cuncepimentu, questu richiede assai più sforzu è tempu di implementazione da noi, postu chì avemu da fà una quantità di travagliu supplementu invece di voi.
- Ogni attività nantu à i bug, senza una descrizzione dettagliata di a so occurrence è screenshots, ùn ci dà l'uppurtunità di capisce ciò chì hè andatu male è cumu pudemu risolve stu bug.
- U prugettu richiede un raffinamentu constantu è migliurà per migliurà u rendiment è a sicurità. Dunque, a squadra passa una parte di u so tempu nantu à sti migliuramentu
- A causa di u fattu chì avemu l'ora extra per l'ora (soluzioni urgenti), avemu da cumpensà per elli in altri ghjorni
Comu regula, u cliente capisce immediatamente chì tuttu ùn hè micca cusì simplice in u sviluppu di software, è u desideriu solu ùn hè chjaramente micca abbastanza.
In generale, hè tuttu. Lascià daretu à i sceni assai negoziazioni è a debugging iniziale di tutti i prucessi, ma in u risultatu, tuttu hà travagliatu. Puderaghju dì chì stu prucessu hè diventatu un tipu di "Silver Bullet" per noi. I novi persone chì sò ghjunti à u prughjettu puderanu subitu in u travagliu da u primu ghjornu, postu chì tutti i prucessi sò stati descritti, è a ducumentazione è l'architettura in forma di diagrammi hà datu immediatamente una idea di ciò chì tutti faciamu quì.
PS Vogliu chjarificà chì ùn ci hè micca un capu di prughjettu da a nostra parte. Hè da u latu di u cliente. Ùn hè micca un tecnicu in tuttu. prughjettu europeu. Tutta a cumunicazione hè solu in inglese.
Bona furtuna à tutti nantu à i vostri prughjetti. Ùn brusgiate micca è pruvate à migliurà i vostri prucessi.
Fonte in u mio .
Source: www.habr.com