Pozdrav prijatelji. Često, posebno u outsourcingu, vidim istu sliku. Nedostatak jasnog radnog procesa u timovima na različitim projektima.
Najvažnije je to što programeri ne razumiju kako komunicirati s klijentom i jedni s drugima. Kako izgraditi neprekidan proces razvoja kvalitetnog proizvoda. Kako planirati svoj radni dan i sprintove.
I sve to na kraju dovodi do promašenih rokova, prekovremenog rada, neprekidnih rasprava tko je kriv i nezadovoljstva klijenata — kamo i kako sve to ide. Prilično često sve to dovodi do smjene programera, pa čak i cijelih timova. Gubitka klijenata, pogoršanja reputacije i tako dalje.
U jednom trenutku sam se našao na takvom projektu gdje su bile sve te čari.
Nitko nije htio preuzeti odgovornost za projekt (velika uslužna tržišna platforma), fluktuacija je bila strašna, klijent je jednostavno bio bijesan. CEO mi je prišao i rekao da imam potrebno iskustvo, pa su ti karte u ruke. Preuzmi projekt. Ako ispadne loše, zatvorit ćemo projekt i sve ćemo otpustiti. Ako uspe, bit će sjajno, tada ga vodi i razvijaj kako smatraš potrebnim. Na kraju sam postao tim lider na projektu i sve je bilo na mojim leđima.
Prvo što sam učinio je da sam razvio radni proces od nule, koji je u to vrijeme odgovarao mom viđenju, i napisao sam opis posla za tim. Implementirati ga nije bilo lako. No, negdje u roku od mjesec dana sve se stabiliziralo, developeri i klijent su se prilagodili, a sve je počelo teći tiho i udobno. Da bih timu pokazao da ovo nije samo 'oluja u čaši', već stvarno rješenje, preuzeo sam maksimalan opseg odgovornosti, sklonivši neugodne rutinske zadatke s tima.
Već je prošlo godinu i pol, i projekt se razvija bez prekovremenog rada, bez 'mišjih utrka' i raznih stresova. Neki u starom timu nisu željeli raditi na taj način i otišli su, nekima je, s druge strane, bilo drago što postoje transparentna pravila. No, na kraju, svi u timu su jako motivirani i poznaju ogroman projekt u potpunosti, uključujući i frontend i backend. Uključujući i kodnu bazu i svu poslovnu logiku. Već smo došli do toga da nismo samo 'veslači', već sami smišljamo mnoge poslovne procese i nove značajke koje su se svidjele biznisu.
Zahvaljujući našim postupcima, klijent je odlučio naručiti još jednu platformu od naše tvrtke, što nas ne može ne veseliti.
Budući da to na mom projektu radi, možda će to nekome drugome također pomoći. Dakle, proces koji nam je pomogao da spasimo projekt:
Proces rada tima na projektu 'Moj omiljeni projekt'
a) Unutarnji timski proces (među programerima)
- Sve zadaće se kreiraju u sustavu Jira
- Svaka zadaća mora biti maksimalno opisna i izvršavati strogo jednu radnju
- Svaka značajka, ako je dovoljno složena, razdvaja se na mnogo malih zadataka
- Tim radi na značajkama kao na jedinstvenoj zadaći. Najprije zajedno radimo na jednoj značajci, predajemo je na testiranje, a zatim preuzimamo sljedeću.
- Svaka zadaća se označava, za backend ili frontend
- Postoje tipovi zadataka i grešaka. Potrebno ih je ispravno označiti.
- Nakon izvršenja zadaće, ona se premješta u status pregled koda (pri čemu se stvara pull request za kolegu)
- Onaj tko je izvršio zadaću odmah prati svoje vrijeme za tu zadaću
- Nakon provjere koda, PR se odobrava i nakon toga, onaj tko je izvršio tu zadaću, samostalno je spaja u master granu, nakon čega mijenja njen status u spremno za implementaciju na dev server.
- Sve zadaće spremne za implementaciju na dev server, implementira tim lider (njegova zona odgovornosti), ponekad član tima, ako je nešto hitno. Nakon implementacije, sve zadaće sa statusom spremno za implementaciju na dev premještaju se u status - spremno za testiranje na devu
- Sve zadaće testira klijent
- Kada klijent testira zadaću na devu, premješta je u status spremno za implementaciju na produkciju
- Za implementaciju na produkciju imamo posebnu granu, u koju spajamo master samo prije implementacije
- Ako klijent tijekom testiranja pronađe greške, vraća zadaću na doradu, postavljajući joj status vraćena na doradu. Na taj način odvajamo nove zadaće od onih koje nisu prošle testiranje
- Na kraju, sve zadaće prolaze put od stvaranja do završetka: To Do → In Development → Code Review → Ready deploy to dev → QA na dev → (Return to dev) → Ready deploy to prod → QA na prod → Done
- Svaki programer samostalno testira svoj kod, uključujući i kao korisnik web stranice. Spojiti granu s glavnom nije dopušteno, osim ako se pouzdano ne zna da kod radi.
- Svaka zadaća ima svoje prioritete. Prioritete postavlja ili naručitelj ili tim lider.
- Programeri prvo izvršavaju prioritetne zadaće.
- Programeri mogu dodjeljivati zadaće jedni drugima ako su pronađeni različiti bugovi u sustavu ili ako jedna zadaća uključuje rad nekoliko stručnjaka.
- Sve zadaće koje naručitelj stvara prelaze kod tim lidera, koji ih ocjenjuje i ili traži od naručitelja da ih doradi ili ih dodjeljuje jednom od članova tima.
- Sve zadaće koje su spremne za deployment na dev ili prod također prelaze kod tim lidera, koji samostalno određuje kada i kako provesti deployment. Nakon svakog deploymenta, tim lider (ili član tima) mora obavijestiti naručitelja o tome. Također se moraju promijeniti statusi zadaća na spremno za testiranje na dev/prod.
- Svaki dan u isto vrijeme (kod nas je to u 12:00) održavamo sastanak između svih članova tima.
- Svaka osoba na sastanku izvještava, uključujući tim lidera, što je radila jučer, što planira raditi danas. Što im ne uspijeva i zašto. Na taj način cijeli tim je u tijeku oko onoga što tko radi i u kojoj je fazi projekt. To nam omogućava da prognoziramo i ispravimo, ako je potrebno, naše procjene i rokove.
- Na sastanku tim lider također izvještava o svim promjenama u projektu i o razini trenutnih bugova koji nisu pronađeni od strane naručitelja. Svi bugovi se razmatraju i dodjeljuju svakom članu tima za njihovo rješavanje.
- Na sastanku tim lider dodjeljuje zadaće svakom članu, uzimajući u obzir trenutnu opterećenost programera, razinu njihove profesionalne pripreme, kao i bliskost određene zadaće onome čime se programer trenutno bavi.
- Na sastanku tim lider razvija zajedničku strategiju za arhitekturu i poslovnu logiku. Nakon toga cijeli tim to raspravlja i donosi odluku o izmjenama ili prihvaćanju te strategije.
- Svaki programer individualno piše kod i gradi algoritme unutar jedne arhitekture i poslovne logike. Svi mogu izraziti svoju viziju provedbe, ali niko nije prisiljen raditi isključivo na jedan način. Svako rješenje ima svoje obrazloženje. Ako postoji bolje rješenje, ali trenutno nema vremena, kreira se zadatak u Jiri za budući refaktor određene dijela koda.
- Kada programer preuzme zadatak, on ga prebacuje u status razvoja. Cijela komunikacija vezana uz pojašnjenje zadatka s klijentom pada na leđa programera. Tehnička pitanja mogu se postavljati tim lideru ili kolegama.
- Ako programer ne razumije suštinu zadatka, a klijent nije mogao jasno objasniti, on prelazi na sljedeći zadatak. A trenutni zadatak preuzima tim lider i sam ga razmatra s klijentom.
- Svaki dan programer treba u klijentov chat napisati o zadacima na kojima je radio jučer i zadacima na kojima će raditi danas.
- Radni proces se odvija prema Scrum metodi. Sve je podijeljeno na sprintove. Svaki sprint traje dva tjedna.
- Sprintove kreira, popunjava i zatvara tim lider.
- Ako projekt ima stroge rokove, trudimo se procijeniti sve zadatke. I od njih stvaramo sprint. Ako klijent pokušava dodati još zadataka u sprint, tada postavljamo prioritete, a neke druge zadatke premještamo u sljedeći sprint.
b) Proces rada s klijentom
- Svaki programer može i treba komunicirati s klijentom.
- Klijentu ne smijemo dopustiti da nameće svoja pravila igre. Potrebno je na uljudan i prijateljski način dati do znanja klijentu da smo stručnjaci u svom poslu i da mi trebamo usmjeravati procese rada, uključujući klijenta u njih.
- Idealan scenarij bi bio, prije nego što se pristupi realizaciji bilo koje funkcionalnosti, stvoriti dijagram toka cijelog logičkog procesa za funkciju (workflow). I poslati ga na potvrdu klijentu. Ovo se odnosi samo na složene i nejasne funkcionalnosti, kao što su sistem plaćanja, sistem obavijesti itd. To će omogućiti bolje razumijevanje potrebâ klijenta, očuvanje dokumentacije za funkcionalnost, kao i osiguranje od toga da klijent kasnije ne može reći da smo napravili nešto što nije tražio.
- Sve dijagrame/flowchartove/logiku itd. spremamo u Confluence/Jira, gdje tražimo od naručitelja da u komentarima potvrdi točnost buduće realizacije.
- Trudimo se ne opterećivati naručitelja tehničkim detaljima. Ako nam je potrebno razumijevanje onoga što naručitelj želi, crtamo primitivne algoritme u obliku dijagrama koji naručitelj može razumjeti i sam ispraviti/doraditi.
- Ako naručitelj pronađe grešku u projektu, tražimo da je vrlo detaljno opisuje u Jiri. Pod kojim se okolnostima dogodila, kada, koju je sekvencu radnji naručitelj izvršavao prilikom testiranja. Tražimo da priloži snimke ekrana.
- Trudimo se svaki dan, najviše svaka dva dana, obaviti deployment na dev server. Tada naručitelj počinje testirati funkcionalnosti, a projekt ne stoji. To je također pokazatelj za naručitelja da je projekt u punoj izradi i da mu nitko ne pričinja bajke.
- Vrlo često se događa da naručitelj ne razumije do kraja što mu uopće treba. Budući da pokreće novi biznis s procesima koji još nisu ustaljeni. Stoga se vrlo često dogodi situacija da bacamo cijele dijelove koda u smeće i prepravljamo logiku aplikacije. Iz toga proizlazi da ne treba sve pokrivati testovima. Ima smisla pokriti testovima samo kritične funkcionalnosti, i to uz rezervacije.
- Dogode se situacije kada tim shvati da ne stignemo s rokovima. Tada provodimo brzu reviziju zadataka i odmah obavještavamo naručitelja o tome. Kao izlaz iz situacije nudimo da puštamo važne i kritične funkcionalnosti na vrijeme, a ostalo ostavljamo za post-release.
- Ako naručitelj počne smišljati razne zadatke iz glave, počne fantazirati i objašnjavati rukama, tražimo da nam dostavi maketu stranice i flow s logikom koja bi trebala u potpunosti opisati ponašanje cijele makete i njenih elemenata.
- Prije nego što preuzmemo bilo koji zadatak, moramo se uvjeriti da je ta značajka bila uključena u uvjete našeg ugovora. Ako je to nova značajka koja nadilazi naše prvotne dogovore, moramo obavezno procijeniti tu značajku ((približno vrijeme izvršenja + 30%) x 2) i obavijestiti naručitelja da će nam trebati toliko vremena, plus što se rok odgađa za vrijeme procjene pomnoženo s dva. Ako uspijemo brže obaviti zadatak - izvrsno, svi će od toga imati koristi. Ako ne, onda smo se pokrili.
b) Što ne prihvaćamo u timu:
- Neozbiljnost, neorganiziranost, zaboravljivost
- „Davanje iluzije“. Ako ne možeš izvršiti zadatak, ne znaš kako, treba odmah obavijestiti tim lidera, a ne čekati do zadnjeg trenutka.
- Hvalisanje od osobe koja još nije dokazala svoje sposobnosti i profesionalnost. Ako je dokazao, može, u okviru pristojnosti 🙂
- Prevara u svim njenim oblicima. Ako zadatak nije izvršen, ne treba mijenjati njegov status na izvršen i pisati u chatu klijentu da je gotov. Pokvario se računar, sistem je pao, pas je pojeo laptop — to je sve nedopustivo. Ako se dogodi stvarna viša sila, tim lider mora odmah biti obaviješten.
- Kada je stručnjak stalno izvan mreže i teško ga je kontaktirati u radno vrijeme.
- Toksičnost unutar tima nije dopuštena! Ako se netko s nečim ne slaže, svi se zajedno okupe na sastanku i to rasprave i riješe.
I još niz pitanja/teza koje ponekad postavljam svom klijentu, kako bih razjasnio svu nesporazumu:
- Koji su vaši kriteriji kvalitete?
- Kako određujete postoje li problemi u projektu ili ne?
- Kršeći sve naše preporuke i savjete za promjene/unapređenje sustava, sve rizike snosite samo vi.
- Sve veće promjene u projektu (na primjer, različiti ekstenzivni tijekovi) mogu dovesti do pojave grešaka (koje ćemo, naravno, ispraviti).
- Nemoguće je unutar nekoliko minuta shvatiti koja je problem u projektu, a kamoli odmah to ispraviti.
- Radimo prema konkretnoj proceduri proizvoda (Zadaci u Jira — Razvoj — Testiranje — Implementacija). Stoga ne možemo reagirati na cijeli niz zahtjeva i pritužbi u chatu.
- Programeri su programeri, a ne profesionalni testeri, i ne mogu osigurati odgovarajuću kvalitetu testiranja projekta.
- Odgovornost za završno testiranje i prihvaćanje zadataka na produkciji potpuno leži na vama.
- Ako smo već preuzeli zadatak, ne možemo se odmah prebaciti na druge dok ne završimo trenutni (inače to dovodi do još većih bugova i produženja vremena razvoja).
- Broj ljudi u timu se smanjio (zbog odmora ili bolesti), a posla je više, i fizički ne možemo reagirati na sve što želite.
- Vaša molba da se izvrši deploy na produkciju bez testiranih zadataka na razvoju - to su isključivo vaši rizici, a ne risci programera.
- Kada postavljate nejasne zadatke, bez ispravnog toka, bez dizajnerskih maketa, to zahtijeva od nas mnogo veće napore i produženje rokova realizacije, jer umjesto vas moramo obaviti dodatni obim posla.
- Svaki zadatak vezan za bugove, bez detaljnog opisa njihovog nastanka i ekranizacija, ne daje nam mogućnost da razumijemo što nije u redu i kako da simuliramo taj bug.
- Projekt zahtijeva stalne dorade i poboljšanja za povećanje performansi i sigurnosti. Zato tim troši dio svog vremena na te poboljšanja.
- Zbog toga što imamo prekovremene sate (hitne ispravke), moramo ih nadoknaditi u drugim danima.
Općenito, klijent brzo shvata da razvoj softvera nije tako jednostavan i da je samo jedna želja očito nedovoljna.
To je to. Ostavio sam mnogo pregovora i inicijalnu debagiranje svih procesa iza scene, ali u rezultatima sve se uspostavilo. Mogu reći da je taj proces postao neka 'Srebrna metak' za nas. Novi ljudi koji su dolazili na projekt mogli su odmah početi raditi od prvog dana jer su svi procesi opisani, a dokumentacija i arhitektura u obliku dijagrama odmah su pružali predstavu o tome čime se ovdje bavimo.
P. S. Želim naglasiti da s naše strane nema projekt menadžera. On je sa strane klijenta. Potpuno nije tehnički. Projekt je europski. Cijela komunikacija je samo na engleskom.
Svima sreću na projektima. Nemojte izgarati i pokušajte poboljšati svoje procese.
Izvor u mom .
Izvor: habr.com
