Bună prieteni. Destul de des, mai ales în outsourcing, văd aceeași imagine. Lipsa unui flux de lucru clar în echipe pe diverse proiecte.
Cel mai important lucru este că programatorii nu înțeleg cum să comunice cu clientul și între ei. Cum să construiți un proces continuu de dezvoltare a unui produs de calitate. Cum să vă planificați ziua de lucru și sprinturile.
Și toate acestea au ca rezultat în cele din urmă termene limită ratate, ore suplimentare, confruntări constante cu privire la cine este de vină și nemulțumirea clienților cu privire la unde și cum se mișcă totul. Destul de des, toate acestea duc la o schimbare de programatori, sau chiar de echipe întregi. Pierderea unui client, deteriorarea reputației și așa mai departe.
La un moment dat, tocmai am ajuns la un astfel de proiect, unde erau toate aceste delicii.
Nimeni nu a vrut să-și asume responsabilitatea pentru proiect (o piață mare de servicii), cifra de afaceri a fost teribilă, clientul a fost pur și simplu sfâșiat și frustrat. CEO-ul a venit odată la mine și a spus că aveți experiența necesară, așa că iată cărțile în mâinile voastre. Ia proiectul pentru tine. Dacă dai peste cap, vom închide proiectul și vom da afară pe toți. Va funcționa, va fi cool, apoi conduceți-l și dezvoltați-l după cum credeți de cuviință. Drept urmare, am devenit liderul echipei pentru proiect și totul a căzut pe umerii mei.
Primul lucru pe care l-am făcut a fost să dezvolt un flux de lucru de la zero, care sa aliniat cu viziunea mea la acea vreme și să scriu o descriere a postului pentru echipă. Punerea în aplicare nu a fost ușoară. Dar în decurs de aproximativ o lună totul s-a așezat, dezvoltatorii și clientul s-au obișnuit și totul a decurs în liniște și confortabil. Pentru a arăta echipei că aceasta nu a fost doar o „furtună într-o ceașcă de ceai”, ci o adevărată ieșire din situație, mi-am asumat maximum de responsabilități, eliminând rutina neplăcută din echipă.
A trecut deja un an și jumătate, iar proiectul se dezvoltă fără ore suplimentare, fără „curse de șobolani” și tot felul de stres. Unii oameni din vechea echipă nu au vrut să lucreze așa și au plecat; alții, dimpotrivă, au fost foarte încântați că au apărut reguli transparente. Dar, până la urmă, toată lumea din echipă este foarte motivată și cunoaște pe deplin proiectul uriaș, incluzând atât front-end, cât și back-end. Include atât baza de cod, cât și toată logica de afaceri. S-a ajuns chiar la punctul în care nu suntem doar „vâslători”, ci noi înșine venim cu multe procese de afaceri și funcții noi care se dovedește a fi pe placul afacerii.
Datorită acestei abordări din partea noastră, clientul a decis să comande o altă piață de la compania noastră, ceea ce este o veste bună.
Deoarece acest lucru funcționează pe proiectul meu, poate că va ajuta pe cineva. Deci, procesul în sine care ne-a ajutat să salvăm proiectul:
Procesul de lucru în echipă la proiectul „Proiectul meu preferat”
a) Procesul intern al echipei (între dezvoltatori)
- Toate problemele sunt create în sistemul Jira
- Fiecare sarcină ar trebui să fie descrisă cât mai mult posibil și să efectueze strict o singură acțiune
- Orice caracteristică, dacă este suficient de complexă, este împărțită în multe sarcini mici
- Echipa lucrează la funcții ca o singură sarcină. Mai întâi, lucrăm cu toții împreună la o funcție, o trimitem pentru testare, apoi o luăm pe următoarea.
- Fiecare sarcină este marcată, pentru backend sau frontend
- Există tipuri de sarcini și erori. Trebuie să le indicați corect.
- După finalizarea unei sarcini, aceasta este transferată în starea de revizuire a codului (în acest caz, este creată o cerere de extragere pentru un coleg)
- Persoana care a finalizat sarcina își urmărește imediat timpul pentru această sarcină.
- După verificarea codului, PR-ul va aproba și, după aceea, cel care a îndeplinit această sarcină independent îl îmbină în ramura principală, după care își schimbă starea în gata pentru implementare pe serverul de dezvoltare.
- Toate sarcinile gata de implementare pe serverul de dezvoltare sunt implementate de liderul echipei (zona sa de responsabilitate), uneori de un membru al echipei, dacă ceva este urgent. După implementare, toate sarcinile de la gata pentru implementare la dev sunt transferate la starea - gata pentru testare pe dev
- Toate sarcinile sunt testate de client
- Când clientul a testat sarcina pe dezvoltator, o transferă în starea gata pentru implementare în producție
- Pentru implementarea în producție, avem o ramură separată, unde îmbinăm masterul numai înainte de implementare
- Dacă în timpul testării clientul găsește erori, el returnează sarcina pentru revizuire, setând starea acesteia ca fiind returnată pentru revizuire. În acest fel, separăm sarcinile noi de cele care nu au trecut testele.
- Ca rezultat, toate sarcinile merg de la creare până la finalizare: De făcut → În dezvoltare → Revizuire cod → Implementare gata pentru dezvoltare → AQ pe dezvoltare → (Revenire la dev) → Implementare gata pentru produs → QA pe produs → Terminat
- Fiecare dezvoltator își testează codul în mod independent, inclusiv ca utilizator al site-ului. Nu este permisă îmbinarea unei ramuri în cea principală decât dacă se știe cu siguranță că codul funcționează.
- Fiecare sarcină are priorități. Prioritățile sunt stabilite fie de client, fie de liderul echipei.
- Dezvoltatorii finalizează mai întâi sarcinile prioritare.
- Dezvoltatorii își pot atribui sarcini unul altuia dacă au fost găsite erori diferite în sistem sau o sarcină constă în munca mai multor specialiști.
- Toate sarcinile pe care clientul le creează merg către liderul echipei, care le evaluează și fie îi cere clientului să le modifice, fie le atribuie unuia dintre membrii echipei.
- Toate sarcinile care sunt gata pentru implementare pentru dezvoltare sau producție sunt, de asemenea, către liderul echipei, care determină în mod independent când și cum să efectueze implementarea. După fiecare implementare, liderul echipei (sau membrul echipei) trebuie să notifice clientul despre acest lucru. Și, de asemenea, modificați stările pentru sarcini la gata pentru testare pentru dev/cont.
- În fiecare zi la aceeași oră (pentru noi este ora 12.00) ținem o întâlnire între toți membrii echipei
- Toți cei de la întâlnire raportează, inclusiv liderul echipei, despre ceea ce au făcut ieri și ce intenționează să facă astăzi. Ce nu funcționează și de ce. În acest fel, întreaga echipă este conștientă de cine ce face și în ce stadiu se află proiectul. Acest lucru ne oferă posibilitatea de a anticipa și ajusta, dacă este necesar, estimările și termenele noastre.
- La întâlnire, șeful echipei vorbește și despre toate modificările din proiect și despre nivelul bug-urilor actuale care nu au fost găsite de client. Toate erorile sunt rezolvate și atribuite fiecărui membru al echipei pentru a le rezolva.
- La întâlnire, șeful de echipă atribuie sarcini fiecărei persoane, ținând cont de volumul de muncă actual al dezvoltatorilor, de nivelul lor de pregătire profesională și, de asemenea, ținând cont de apropierea unei anumite sarcini de ceea ce face în prezent dezvoltatorul.
- La întâlnire, liderul echipei dezvoltă o strategie generală pentru arhitectură și logica de afaceri. După care toată echipa discută acest lucru și decide să facă ajustări sau să adopte această strategie.
- Fiecare dezvoltator scrie cod și construiește algoritmi independent în cadrul unei singure arhitecturi și logici de afaceri. Toată lumea își poate exprima viziunea asupra implementării, dar nimeni nu obligă pe nimeni să o facă așa și nu altfel. Fiecare decizie este justificată. Dacă există o soluție mai bună, dar nu există timp pentru aceasta acum, atunci este creată o sarcină în grăsime pentru refactorizarea viitoare a unei anumite părți a codului.
- Când un dezvoltator preia o sarcină, o transferă în starea de dezvoltare. Toată comunicarea cu privire la clarificarea sarcinii cu clientul cade pe umerii dezvoltatorului. Întrebările tehnice pot fi adresate șefului echipei sau colegilor.
- Dacă dezvoltatorul nu înțelege esența sarcinii și clientul nu a putut să o explice clar, atunci trece la următoarea sarcină. Iar șeful echipei îl ia pe cel actual și îl discută cu clientul.
- În fiecare zi, dezvoltatorul ar trebui să scrie în chat-ul clientului despre ce sarcini a lucrat ieri și la ce sarcini va lucra astăzi
- Procesul de lucru se desfășoară conform Scrum. Totul este împărțit în sprinturi. Fiecare sprint durează două săptămâni.
- Sprinturile sunt create, completate și închise de liderul echipei.
- Dacă proiectul are termene stricte, atunci încercăm să estimăm aproximativ toate sarcinile. Și le-am pus împreună într-un sprint. Dacă clientul încearcă să adauge mai multe sarcini la sprint, atunci stabilim priorități și transferăm alte sarcini la următorul sprint.
b) Procesul de lucru cu clientul
- Fiecare dezvoltator poate și ar trebui să comunice cu clientul
- Clientului nu i se poate permite să-și impună propriile reguli de joc. Este necesar să clarificăm clientului într-o manieră politicoasă și prietenoasă că suntem specialiști în domeniul nostru și doar noi trebuie să construim procese de lucru și să implicăm clientul în ele.
- Este necesar, în mod ideal, înainte de a începe implementarea oricărei funcționalități, să creați o diagramă flux a întregului proces logic pentru caracteristică (flux de lucru). Și trimiteți-l clientului pentru confirmare. Acest lucru se aplică numai funcționalităților complexe și nu evidente, de exemplu, un sistem de plată, un sistem de notificare etc. Acest lucru ne va permite să înțelegem mai exact de ce are nevoie clientul, să salvăm documentația pentru caracteristică și, de asemenea, să ne asigurăm împotriva faptului că clientul poate spune în viitor că nu am făcut ceea ce a cerut.
- Toate diagramele/organigramele/logica etc. Îl salvăm în Confluence/Fat, unde solicităm clientului să confirme corectitudinea implementării viitoare în comentarii.
- Încercăm să nu împovărăm clientul cu detalii tehnice. Dacă avem nevoie de o înțelegere a modului în care își dorește clientul, atunci desenăm algoritmi primitivi sub forma unei organigrame pe care clientul o poate înțelege și corecta/modifica totul el însuși.
- Dacă clientul găsește o eroare în proiect, atunci vă rugăm să o descrieți în detaliu în Zhira. În ce circumstanțe a avut loc, când, ce secvență de acțiuni a fost efectuată de client în timpul testării. Vă rugăm să atașați capturi de ecran.
- Încercăm în fiecare zi, cel mult în două zile, să implementăm pe serverul de dezvoltare. Clientul începe apoi să testeze funcționalitatea și proiectul nu rămâne inactiv. În același timp, acesta este un marker pentru client că proiectul este în plină dezvoltare și nimeni nu îi spune basme.
- Se întâmplă adesea ca clientul să nu înțeleagă pe deplin de ce are nevoie. Pentru că își creează o nouă afacere, cu procese care nu au fost încă stabilite. Prin urmare, o situație foarte comună este atunci când aruncăm bucăți întregi de cod la coșul de gunoi și reproiectăm logica aplicației. De aici rezultă că nu ar trebui să acoperiți absolut totul cu teste. Este logic să acoperiți doar funcționalitățile critice cu teste și apoi numai cu rezerve.
- Sunt situații în care echipa realizează că nu respectăm termenele limită. Apoi efectuăm un audit rapid al sarcinilor și informăm imediat clientul despre acesta. Pentru a ieși din situație, vă sugerăm să lansați funcționalitățile importante și critice la timp și să lăsați restul pentru post-lansare.
- Dacă clientul începe să vină cu diferite sarcini din cap, începe să fantezeze și să explice cu degetele, atunci îi cerem să ne ofere un aspect al paginii și să curgă cu o logică care ar trebui să descrie pe deplin comportamentul întregului aspect și elementele sale.
- Înainte de a prelua orice sarcină, trebuie să ne asigurăm că această caracteristică a fost inclusă în termenii acordului/contractului nostru. Dacă aceasta este o caracteristică nouă care depășește acordurile noastre inițiale, atunci trebuie să stabilim prețul acestei caracteristici ((timpul estimat de finalizare + 30%) x 2) și să indicăm clientului că ne va dura atât de mult timp pentru ao finaliza, plus termenul limită este deplasat cu timpul estimat înmulțit cu doi. Să facem sarcina mai repede - grozav, toată lumea va beneficia de ea. Dacă nu, atunci vă avem acoperit.
c) Ce nu acceptăm într-o echipă:
- Neangajament, lipsă de calm, uitare
- „Hrănind micul dejun.” Dacă nu puteți finaliza o sarcină și nu știți cum, atunci trebuie să anunțați imediat liderul echipei despre aceasta și să nu așteptați până în ultimul minut.
- Sprâncenele și se laudă de la o persoană care nu și-a dovedit încă capacitățile și profesionalismul. Dacă se dovedește, atunci este posibil, în limitele decenței :)
- Înșelăciunea în toate formele ei. Dacă o sarcină nu este finalizată, atunci nu trebuie să-i schimbați starea în finalizată și să scrieți în chat-ul clientului că este gata. Calculatorul s-a stricat, sistemul s-a prăbușit, câinele a mestecat laptopul - toate acestea sunt inacceptabile. În cazul în care apare un eveniment de forță majoră, șeful echipei trebuie anunțat imediat.
- Când un specialist este offline tot timpul și este dificil să-l contactați în timpul programului de lucru.
- Toxicitatea în echipă nu este permisă! Dacă cineva nu este de acord cu ceva, atunci toată lumea se adună pentru un miting și discută și decide în privința asta.
Și o serie de întrebări/teze pe care uneori le pun clientului meu pentru a lămuri toate neînțelegerile:
- Care sunt criteriile tale de calitate?
- Cum afli dacă un proiect are probleme sau nu?
- Încălcând toate recomandările și sfaturile noastre privind schimbarea/îmbunătățirea sistemului, toate riscurile sunt suportate numai de dvs.
- Orice modificare majoră a proiectului (de exemplu, tot felul de flux suplimentar) va duce la posibila apariție a erorilor (pe care, desigur, le vom remedia)
- Este imposibil să înțelegeți în câteva minute ce fel de problemă a apărut pe proiect, cu atât mai puțin să o remediați imediat
- Lucrăm pe un flux de produs specific (Sarcini în Zhira - Dezvoltare - Testare - Implementare). Aceasta înseamnă că nu putem răspunde întregului flux de solicitări și reclamații din chat.
- Programatorii sunt programatori, nu testeri profesioniști și nu pot asigura calitatea corespunzătoare a testării proiectelor
- Responsabilitatea pentru testarea finală și acceptarea sarcinilor de producție vă revine în întregime
- Dacă ne-am asumat deja o sarcină, nu putem trece imediat la altele până când nu o finalizăm pe cea actuală (altfel, aceasta duce la și mai multe erori și la creșterea timpului de dezvoltare)
- Sunt mai puțini oameni în echipă (din cauza vacanțelor sau a bolilor), dar este mai multă muncă și fizic nu vom avea timp să răspundem la tot ce îți dorești
- Vă cerem să faceți o implementare în producție fără sarcini testate pe dev - acesta este doar riscul dvs., nu dezvoltatorii
- Când stabiliți sarcini neclare, fără un flux corect, fără layout-uri de proiectare, acest lucru necesită mult mai mult efort și timp de implementare din partea noastră, deoarece trebuie să facem o cantitate suplimentară de muncă în locul dvs.
- Orice sarcină privind erorile, fără o descriere detaliată a apariției lor și a capturilor de ecran, nu ne oferă posibilitatea de a înțelege ce a mers prost și cum putem remedia această eroare
- Proiectul necesită o rafinare constantă și îmbunătățiri pentru a îmbunătăți performanța și siguranța. Prin urmare, echipa își petrece o parte din timp pe aceste îmbunătățiri
- Din cauza faptului că avem ore suplimentare la oră (remedieri urgente), trebuie să le compensăm în alte zile
De regulă, clientul înțelege imediat că totul nu este atât de simplu în dezvoltarea de software, iar dorința singură nu este în mod clar suficientă.
În general, asta e tot. Las în culise o mulțime de negocieri și depanarea inițială a tuturor proceselor, dar ca rezultat, totul a funcționat. Pot spune că acest proces a devenit un fel de „Glonț de argint” pentru noi. Oamenii noi care au venit la proiect s-au putut implica imediat în lucru din prima zi, deoarece toate procesele au fost descrise, iar documentația și arhitectura sub formă de diagrame au dat imediat o idee despre ceea ce făceam cu toții aici.
PS Aș dori să clarific că nu există un manager de proiect de partea noastră. Este de partea clientului. Nu este deloc un tehnist. proiect european. Toată comunicarea este doar în limba engleză.
Mult succes tuturor în proiectele tale. Nu vă epuizați și încercați să vă îmbunătățiți procesele.
Sursa in a mea .
Sursa: www.habr.com