Salut prieteni. Frecvent, în special în outsourcing, observ aceeași situație. Lipsa unui proces de lucru clar în echipe la diverse proiecte.
Cel mai important este că programatorii nu înțeleg cum trebuie să comunice cu clienții și între ei. Cum să construiască un proces continuu de dezvoltare a unui produs de calitate. Cum să își planifice ziua de lucru și sprinturile.
Și totul se transformă până la urmă în termene limita depășite, ore suplimentare, certuri constante despre cine este de vină și nemulțumirea clienților — încotro și cum se îndreaptă totul. Destul de des, toate acestea duc la schimbarea programatorilor, iar uneori chiar și a întregilor echipe. Pierderea clientului, deteriorarea reputației și așa mai departe.
Într-o perioadă anume, am nimerit pe un astfel de proiect, unde existau toate aceste neajunsuri.
Nimeni nu voia să își asume responsabilitatea pentru proiect (o mare platformă de servicii), fluctuația de personal era uriașă, clientul pur și simplu era furios. CEO-ul a venit la mine într-o zi și mi-a spus că am experiența necesară, așa că îți încredințez acest proiect. Dacă eșuezi, vom închide proiectul și vom da afară pe toată lumea. Dacă reușești, va fi grozav, așa că dezvoltă-l cum crezi de cuviință. Așa am devenit lider de echipă pe proiect și totul a căzut pe umerii mei.
Primul lucru pe care l-am făcut a fost să dezvolt un proces de lucru de la zero, care corespundea viziunii mele de atunci, și am scris o fișă a postului pentru echipă. Implementarea lui nu a fost simplă. Dar într-o lună totul s-a reglat, dezvoltatorii și clientul s-au obișnuit, iar lucrurile au început să decurgă deja liniștit și confortabil. Pentru a le arăta colegilor că nu este doar o „furtună într-un pahar de apă”, ci o soluție reală, am preluat un volum maxim de responsabilități, eliberând echipa de rutina neplăcută.
Au trecut deja un an și jumătate, iar proiectul evoluează fără ore suplimentare, fără „curse de șobolani” și fără stresuri de tot felul. Unii din vechea echipă nu au vrut să lucreze în acest mod și au plecat, în timp ce altora le-a plăcut că au apărut reguli transparente. Dar rezultatul este că toți cei din echipă sunt foarte motivați și cunosc în întregime un proiect uriaș, atât front-end, cât și back-end. Inclusiv baza de cod și întreaga logică de afaceri. Am ajuns chiar la punctul în care nu suntem doar „padloni”, ci venim cu multe procese de afaceri și caracteristici noi, care s-au dovedit a fi pe placul afacerii.
Prin această abordare din partea noastră, clientul a decis să comande încă o piață de la compania noastră, ceea ce nu poate decât să ne bucure.
Deoarece funcționează la proiectul meu, poate că va ajuta și pe altcineva. Așadar, procesul care ne-a ajutat să salvăm proiectul:
Procesul de lucru al echipei pe proiectul „Proiectul meu preferat”
a) Procesul intern al echipei (între dezvoltatori)
- Toate sarcinile sunt create în sistemul Jira
- Fiecare sarcină trebuie să fie descrisă cât mai detaliat și să efectueze strict o singură acțiune
- Orice funcționalitate, dacă este suficient de complexă, este împărțită în multe sarcini mici
- Echipa lucrează asupra funcționalităților ca asupra unei singure sarcini. La început, facem împreună o funcționalitate, o trimitem pentru testare, apoi luăm următoarea.
- Fiecare sarcină este marcată, fie pentru backend, fie pentru frontend
- Există tipuri de sarcini și bug-uri. Este necesar să le indicăm corect.
- După finalizarea sarcinii, aceasta este trecută în statusul revizuirii codului (în acest timp, se creează un pull request pentru colegul său)
- Cel care a îndeplinit sarcina își urmărește imediat timpul pentru această sarcină
- După verificarea codului, PR-ul este aprobat și, după aceea, cel care a îndeplinit această sarcină, o îmbină singur în ramura principală, după care își schimbă statusul în „gata pentru deployment pe dev” serverul.
- Toate sarcinile gata de deployment pe serverul dev sunt deployate de team lead (zona sa de responsabilitate), uneori de un membru al echipei, dacă este ceva urgent. După deployment, toate sarcinile cu statusul „gata pentru deployment pe dev” sunt trecute în statusul — „gata pentru testare pe dev”
- Toate sarcinile sunt testate de client
- Când clientul testează sarcina pe dev, o trece în statusul „gata pentru deployment pe prod”
- Pentru deployment pe prod avem o ramură separată, în care îmbinăm master-ul doar înainte de deployment
- Dacă în timpul testării clientul găsește bug-uri, acesta returnează sarcina pentru refacere, stabilind statusul „returnată pentru refacere”. Astfel, separăm sarcinile noi de cele care nu au trecut testarea
- În concluzie, toate sarcinile trec prin parcursul de la creare la finalizare: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Fiecare dezvoltator testează propriul cod în mod independent, inclusiv ca utilizator al site-ului. Nu este permisă îmbinarea ramurii cu cea principală dacă nu se știe cu certitudine că codul funcționează.
- Fiecare sarcină are priorități. Prioritățile sunt stabilite fie de client, fie de liderul echipei.
- Dezvoltatorii îndeplinesc mai întâi sarcinile prioritare.
- Dezvoltatorii pot delega sarcini între ei, dacă au fost identificate bug-uri diferite în sistem sau dacă o sarcină constă din munca mai multor specialiști.
- Toate sarcinile create de client ajung la liderul echipei, care le evaluează și fie cere clientului să le revizuiască, fie le alocă unuia dintre membrii echipei.
- Toate sarcinile care sunt gata de deploy pe dev sau prod ajung de asemenea la liderul echipei, care determină când și cum să efectueze deploy-ul. După fiecare deploy, liderul echipei (sau un membru al echipei) trebuie să informeze clientul despre acest lucru. De asemenea, trebuie să schimbe statutul sarcinilor la "gata de testare" pe dev/prod.
- În fiecare zi la aceeași oră (pentru noi, aceasta este la 12:00) organizăm o întâlnire între toți membrii echipei.
- Fiecare persoană la întâlnire își raportează activitatea, inclusiv liderul echipei, ce a realizat ieri, ce planifică să facă astăzi, ce nu reușește și de ce. Astfel, întreaga echipă este la curent cu cine se ocupă de ce și în ce stadiu este proiectul. Acest lucru ne oferă posibilitatea de a prezice și de a corecta, dacă este necesar, estimările și termenele limită.
- La întâlnire, liderul echipei anunță de asemenea toate modificările din proiect și nivelul bug-urilor actuale, care nu au fost identificate de client. Toate bug-urile sunt discutate și atribuite fiecărui membru al echipei pentru rezolvare.
- La întâlnire, liderul echipei alocă sarcini fiecărei persoane, având în vedere încărcătura actuală a dezvoltatorilor, nivelul lor de pregătire profesională, precum și apropierea acelei sarcini de ceea ce face dezvoltatorul în acel moment.
- La întâlnire, liderul echipei elaborează o strategie generală pentru arhitectură și logica de afaceri. După aceea, întreaga echipă discută acest lucru și ia o decizie cu privire la modificările necesare sau acceptarea acestei strategii.
- Fiecare dezvoltator scrie cod și construiește algoritmi de sine stătător în cadrul unei arhitecturi unice și a unei logici de afaceri. Fiecare poate să-și exprime viziunea pentru implementare, dar nimeni nu este constrâns să facă asta într-un singur mod. Fiecare decizie este argumentată. Dacă există o soluție mai bună, dar nu este timp pentru ea acum, se creează o sarcină în JIRA pentru o viitoare refactorizare a unei anumite părți din cod.
- Când dezvoltatorul preia o sarcină, o transformă în statutul de dezvoltare. Toată comunicarea referitoare la clarificarea sarcinii cu clientul revine dezvoltatorului. Întrebările tehnice pot fi adresate team lead-ului sau colegilor.
- Dacă dezvoltatorului nu-i este clară esența sarcinii, iar clientul nu a reușit să o explice clar, el trece la următoarea sarcină. Team lead-ul preia sarcina curentă și o discută cu clientul.
- În fiecare zi, dezvoltatorul trebuie să scrie în chatul clientului despre sarcinile la care a lucrat ieri și la care va lucra astăzi.
- Procesul de muncă se desfășoară pe baza metodologiei Scrum. Totul este împărțit în sprinturi. Fiecare sprint durează două săptămâni.
- Sprinturile sunt create, populate și închise de către team lead.
- Dacă proiectul are termen limită stricte, ne străduim să estimăm toate sarcinile. Și formăm un sprint din acestea. Dacă clientul încearcă să adauge sarcini suplimentare în sprint, atunci stabilim priorități și amânăm unele sarcini pentru sprintul următor.
b) Procesul de lucru cu clientul
- Fiecare dezvoltator poate și trebuie să comunice cu clientul.
- Nu trebuie să permitem clientului să impună propriile reguli de joc. Trebuie să-i dăm, într-un mod politicos și prietenos, să înțeleagă că suntem specialiști în domeniul nostru și doar noi ar trebui să structurăm procesele de lucru și să-l implicăm pe client în acestea.
- Ideal, înainte de a începe implementarea oricărei funcționalități, ar trebui să creăm un diagramă de flux pentru întregul proces logic al caracteristicii (workflow). Și să o trimitem pentru aprobat clientului. Aceasta se referă doar la funcționalități complexe și non-occhioase, de exemplu, sistemul de plată, sistemul de notificări etc. Aceasta va permite o înțelegere mai precisă a ceea ce are nevoie clientul, să păstrăm documentația pentru caracteristică și să ne asigurăm că clientul nu poate spune în viitor că nu am făcut ceea ce a cerut.
- Toate diagramele / schemele / logica etc. le păstrăm în Confluence / Jira, unde cerem clientului să confirme în comentarii corectitudinea implementării viitoare.
- Încercăm să nu supraaglomerăm clientul cu detalii tehnice. Dacă avem nevoie de înțelegerea dorințelor clientului, desenăm algoritmi foarte simplificați sub formă de scheme, pe care clientul le poate înțelege și corecta / îmbunătăți singur.
- Dacă clientul descoperă un bug în proiect, cerem să-l descrie foarte detaliat în Jira. În ce circumstanțe a apărut, când, ce succesiune de acțiuni a efectuat clientul în timpul testării. Cerem să atașeze capturi de ecran.
- Încercăm să facem deploy în fiecare zi, maximum o dată la două zile pe serverul de dezvoltare. Clientul începe astfel să testeze funcționalitatea și proiectul nu stă degeaba. Acest lucru este un semn pentru client că proiectul este în dezvoltare completă și nimeni nu-i spune povești.
- Foarte des se întâmplă ca clientul să nu înțeleagă pe deplin ce are nevoie. Deoarece își creează o afacere nouă, cu procese încă neîncadrate. De aceea, un caz frecvent este situația în care aruncăm la gunoi întregi bucăți de cod și refacem logica aplicației. Din aceasta rezultă că nu este necesar să acoperim absolut totul cu teste. Are sens să acoperim cu teste doar funcționalitatea critică și asta cu anumite condiții.
- Sunt situații în care echipa realizează că nu ne încadrăm în termenele limită. Atunci facem un audit rapid al sarcinilor și vom informa imediat clientul. Ca soluție, propunem să lansăm la timp funcționalitatea importantă și critică, lăsând restul pentru post-releases.
- Dacă clientul începe să inventeze diferite sarcini din cap, să-și folosească imaginația și să explice pe degete, atunci îi cerem să ne ofere un mockup al paginii și un flux cu logica, care să descrie complet comportamentul întregului mockup și al elementelor sale.
- Înainte de a prelua orice sarcină, trebuie să ne asigurăm că această caracteristică era inclusă în condițiile contractului nostru. Dacă este o caracteristică nouă, care depășește acordurile noastre inițiale, trebuie să o estimăm ((timpul aproximativ de execuție + 30%) x 2) și să informăm clientul că ne va lua atât de mult timp, plus că termenul limită se va muta cu timpul estimat înmulțit cu doi. Dacă reușim să finalizăm sarcina mai repede — minunat, toată lumea va avea de câștigat. Dacă nu, ne-am luat măsuri de precauție.
b) Ce nu acceptăm în echipă:
- Lipsa de responsabilitate, dezorganizarea, uitarea
- Întârzierile nejustificate. Dacă nu poți finaliza o sarcină, nu știi cum, trebuie să anunți imediat team lead-ul, nu să aștepți până în ultima clipă.
- Lăudăroșenia și vanitatea din partea unei persoane care nu și-a demonstrat încă abilitățile și profesionalismul prin fapte. Dacă a demonstrat, atunci acceptabil, în limitele bunului simț 🙂
- Înșelătoria în orice formă. Dacă sarcina nu este finalizată, nu trebuie să schimbi statutul ei în finalizată și să scrii în chatul clientului că este gata. S-a defectat computerul, a căzut sistemul, câinele a mestecat laptopul — toate acestea sunt inacceptabile. Dacă se întâmplă un real forț major, team lead-ul trebuie să fie anunțat imediat.
- Când specialistul este tot timpul offline și este greu de contactat în timpul orelor de lucru.
- Toxicitatea în echipă nu este acceptată! Dacă cineva nu este de acord cu ceva, atunci toți se adună la o întâlnire și discută și soluționează.
Și o serie de întrebări/teze pe care le pun uneori clientului meu pentru a elimina orice neclaritate:
- Care sunt criteriile dumneavoastră de calitate?
- Cum determinați dacă există probleme în proiect sau nu?
- Încălcând toate recomandările și sfaturile noastre de modificare/îmbunătățire a sistemului, toate riscurile le asumați doar dumneavoastră
- Orice modificări majore ale proiectului (de exemplu, tot felul de fluxuri suplimentare) vor duce la o posibilă apariție a bug-urilor (pe care le vom corecta, desigur)
- Nu este posibil să înțelegi într-un minut ce problemă a apărut în proiect, cu atât mai puțin să o repari imediat
- Noi lucrăm pe un flux de produse concret (Sarcinile în Jira — Dezvoltare — Testare — Deploiere). Asta înseamnă că nu putem reacționa la toate cererile și plângerile din chat
- Programatorii sunt programatori, nu testeri profesioniști și nu pot asigura calitatea corespunzătoare a testării proiectului.
- Responsabilitatea pentru testarea finală și acceptarea sarcinilor în producție vă revine în totalitate.
- Dacă am început deja o sarcină, nu putem trece imediat la altele până nu finalizăm curenta (altfel, asta duce la mai multe bug-uri și la creșterea timpului de dezvoltare).
- Numărul persoanelor din echipă s-a redus (din cauza concediilor sau bolilor), iar volumul de muncă a crescut, astfel că nu putem reacționa fizic la tot ceea ce doriți.
- Cererea dumneavoastră de a face deploy în producție fără sarcini testate pe dev este un risc care vă aparține, nu al dezvoltatorilor.
- Când formulați sarcini neclare, fără un flux corespunzător, fără designuri, acest lucru necesită din partea noastră mult mai mult efort și timp de execuție, deoarece trebuie să facem muncă suplimentară în locul dumneavoastră.
- Orice sarcini legate de bug-uri, fără o descriere detaliată a apariției lor și capturi de ecran, nu ne oferă posibilitatea de a înțelege ce a mers prost și cum să recreăm acest bug.
- Proiectul necesită îmbunătățiri constante pentru a crește performanța și securitatea. De aceea, echipa își rezervă o parte din timp pentru aceste îmbunătățiri.
- Datorită faptului că avem uneori ore suplimentare (fixări urgente), trebuie să le compensăm în alte zile.
De obicei, clientul înțelege imediat că lucrurile nu sunt atât de simple în dezvoltarea software-ului și că doar dorința nu este suficientă.
Asta e tot. Las în afara scenei numeroase negocieri și începutul tuturor proceselor, dar în cele din urmă totul s-a reglat. Pot spune că acest proces a devenit pentru noi un fel de 'glonț de argint'. Noii oameni care au venit în proiect au putut să se apuce de lucru din prima zi, deoarece toate procesele sunt documentate, iar documentația și arhitectura în formă de diagrame ofereau imediat o imagine de ansamblu despre activitățile noastre.
P. S. Vreau să subliniez că nu avem un manager de proiect de partea noastră. El este de partea clientului. Nu este tehnic. Proiectul este european. Toată comunicarea se face doar în engleză.
Mult succes în proiecte. Nu vă epuizați și încercați să vă îmbunătățiți procesele.
Sursa este în mâinile mele. .
Sursa: habr.com
