Zdravo prijatelji. Vrlo često, posebno u outsourcingu, vidim istu sliku. Nedostatak jasnog toka rada u timovima na različitim projektima.
Najvažnije je da programeri ne razumiju kako da komuniciraju sa kupcem i jedni s drugima. Kako izgraditi kontinuirani proces razvoja kvalitetnog proizvoda. Kako planirati svoj radni dan i sprintove.
A sve to na kraju rezultira promašenim rokovima, prekovremenom, stalnim obračunima ko je kriv i nezadovoljstvom kupaca gdje i kako se sve odvija. Često sve to dovodi do promjene programera, pa čak i cijelih timova. Gubitak kupca, pogoršanje reputacije i tako dalje.
Jedno vrijeme sam upravo završio na jednom takvom projektu, gdje je bilo svih tih užitaka.
Niko nije želio da preuzme odgovornost za projekat (veliko tržište usluga), promet je bio užasan, kupac je bio jednostavno rastrgan i frustriran. Generalni direktor mi je jednom prišao i rekao da imate potrebno iskustvo, pa evo karte u vašim rukama. Uzmite projekat za sebe. Ako zeznete, zatvorit ćemo projekat i izbaciti sve. Uspjet će, bit će cool, onda ga vodite i razvijajte kako vam odgovara. Kao rezultat toga, postao sam vođa tima za projekat i sve je palo na moja ramena.
Prvo što sam uradio je da sam razvio tok posla od nule koji je bio u skladu sa mojom vizijom u to vreme i napisao opis posla za tim. Implementacija nije bila laka. Ali u roku od mjesec dana sve se smirilo, programeri i klijent su se navikli na to i sve je prošlo tiho i udobno. Kako bih pokazao timu da ovo nije bila samo „oluja u šoljici“, već pravi izlaz iz situacije, preuzeo sam maksimalan iznos odgovornosti, maknuvši iz ekipe neprijatnu rutinu.
Prošlo je već godinu i po dana, a projekat se razvija bez prekovremenog rada, bez “pacovskih trka” i svih vrsta stresa. Neki ljudi u starom timu nisu hteli tako da rade i otišli su, drugi su, naprotiv, bili veoma zadovoljni što su se pojavila transparentna pravila. Ali na kraju, svi u timu su veoma motivisani i znaju veliki projekat u potpunosti, uključujući front-end i back-end. Uključujući i bazu koda i svu poslovnu logiku. Došlo je čak do toga da nismo samo „veslači“, već i sami dolazimo do mnogih poslovnih procesa i novih funkcija koje se posluju dopadaju.
Zahvaljujući ovakvom pristupu s naše strane, kupac je odlučio naručiti još jedno tržište od naše kompanije, što je dobra vijest.
Pošto ovo radi na mom projektu, možda će nekome i pomoći. Dakle, sam proces koji nam je pomogao da spasimo projekat:
Proces timskog rada na projektu “Moj omiljeni projekat”
a) Interni timski proces (između programera)
- Sva izdanja se kreiraju u Jira sistemu
- Svaki zadatak treba opisati što je više moguće i izvršiti striktno jednu radnju
- Svaka karakteristika, ako je dovoljno složena, raščlanjena je na mnogo malih zadataka
- Tim radi na funkcijama kao jedan zadatak. Prvo, svi zajedno radimo na jednoj osobini, šaljemo je na testiranje, a zatim uzimamo sljedeću.
- Svaki zadatak je označen, za backend ili frontend
- Postoje vrste zadataka i grešaka. Morate ih ispravno navesti.
- Nakon dovršetka zadatka, on se prenosi u status pregleda koda (u ovom slučaju se kreira pull request za kolegu)
- Osoba koja je završila zadatak odmah prati svoje vrijeme za ovaj zadatak.
- Nakon provjere koda, PR će ga odobriti i nakon toga onaj koji je izvršio ovaj zadatak samostalno ga spaja u master granu, nakon čega mijenja njegov status u spreman za implementaciju na dev server.
- Sve zadatke spremne za implementaciju na dev server postavlja vođa tima (njegova oblast odgovornosti), ponekad i član tima, ako je nešto hitno. Nakon implementacije, svi zadaci od spremnosti za implementaciju do dev-a se prenose u status - spreman za testiranje na dev-u
- Sve zadatke testira kupac
- Kada korisnik testira zadatak na dev-u, on ga prenosi u status spreman za implementaciju u proizvodnju
- Za implementaciju u proizvodnju, imamo zasebnu granu, gdje spajamo master samo prije implementacije
- Ako tokom testiranja korisnik pronađe greške, vraća zadatak na reviziju, postavljajući njegov status kao vraćen na reviziju. Na taj način odvajamo nove zadatke od onih koji nisu prošli testiranje.
- Kao rezultat toga, svi zadaci idu od kreiranja do završetka: Obaveze → U razvoju → Pregled koda → Spremno postavljanje na dev → QA na dev → (Povratak na dev) → Spremno postavljanje na prod → QA na prod → Gotovo
- Svaki programer testira svoj kod nezavisno, uključujući i kao korisnik sajta. Nije dozvoljeno spajanje grane u glavnu osim ako se pouzdano zna da kod radi.
- Svaki zadatak ima prioritete. Prioritete postavlja ili kupac ili vođa tima.
- Programeri prvo izvršavaju prioritetne zadatke.
- Programeri mogu jedni drugima dodijeliti zadatke ako su u sistemu pronađene različite greške ili se jedan zadatak sastoji od rada nekoliko stručnjaka.
- Svi zadaci koje klijent kreira idu voditelju tima, koji ih ocjenjuje i ili traži od kupca da ih izmijeni ili ih dodjeljuje nekom od članova tima.
- Svi zadaci koji su spremni za implementaciju dev-u ili prod-u također idu voditelju tima, koji samostalno određuje kada i kako će implementirati. Nakon svake implementacije, vođa tima (ili član tima) mora obavijestiti kupca o tome. I također promijenite statuse zadataka u spremni za testiranje za dev/cont.
- Svaki dan u isto vrijeme (kod nas je u 12.00) održavamo sastanak svih članova tima
- Svi na sastanku, uključujući i vođu tima, izvještavaju o tome šta su radili jučer i šta planiraju učiniti danas. Šta ne radi i zašto. Na taj način je cijeli tim svjestan ko šta radi i u kojoj je fazi projekat. To nam daje priliku da predvidimo i prilagodimo, ako je potrebno, naše procjene i rokove.
- Na sastanku, vođa tima govori i o svim promjenama u projektu i nivou trenutnih grešaka koje nije pronašao kupac. Sve greške su razvrstane i dodijeljene svakom članu tima da ih riješi.
- Na sastanku, vođa tima dodjeljuje zadatke svakoj osobi, uzimajući u obzir trenutno opterećenje programera, njihov nivo profesionalne obuke, a također uzimajući u obzir blizinu određenog zadatka onome što programer trenutno radi.
- Na sastanku, vođa tima razvija opštu strategiju za arhitekturu i poslovnu logiku. Nakon toga cijeli tim raspravlja o tome i odlučuje da izvrši prilagodbe ili usvoji ovu strategiju.
- Svaki programer samostalno piše kod i gradi algoritme u okviru jedinstvene arhitekture i poslovne logike. Svako može izraziti svoju viziju implementacije, ali niko nikoga ne tjera da to radi na ovaj način, a ne drugačije. Svaka odluka je opravdana. Ako postoji bolje rješenje, ali za to sada nema vremena, onda se u masti kreira zadatak za buduće refaktoriranje određenog dijela koda.
- Kada programer preuzme zadatak, on ga prenosi u razvojni status. Sva komunikacija u vezi pojašnjenja zadatka s kupcem pada na ramena programera. Tehnička pitanja se mogu postaviti vođi tima ili kolegama.
- Ako programer ne razumije suštinu zadatka, a kupac nije mogao to jasno objasniti, onda prelazi na sljedeći zadatak. A vođa tima uzima trenutni i razgovara o njemu s kupcem.
- Programer bi svaki dan trebao pisati u klijentov chat o tome na kojim zadacima je radio jučer i na kojim će zadacima raditi danas
- Proces rada se odvija po Scrum-u. Sve je podijeljeno na sprinteve. Svaki sprint traje dvije sedmice.
- Sprinteve kreira, popunjava i zatvara vođa tima.
- Ako projekt ima stroge rokove, onda pokušavamo približno procijeniti sve zadatke. I spojili smo ih u sprint. Ako kupac pokuša dodati još zadataka u sprint, tada postavljamo prioritete i prenosimo neke druge zadatke na sljedeći sprint.
b) Proces rada sa kupcem
- Svaki programer može i treba da komunicira sa kupcem
- Kupcu se ne može dozvoliti da nameće svoja pravila igre. Potrebno je kupcu na ljubazan i prijateljski način jasno staviti do znanja da smo specijalisti u svojoj oblasti, a samo mi moramo izgraditi radne procese i uključiti kupca u njih
- U idealnom slučaju, prije početka implementacije bilo koje funkcionalnosti, potrebno je napraviti dijagram toka cjelokupnog logičkog procesa za funkciju (workflow). I pošaljite je kupcu na potvrdu. Ovo se odnosi samo na složenu i ne očiglednu funkcionalnost, na primjer, sistem plaćanja, sistem obavještavanja itd. Ovo će nam omogućiti da preciznije shvatimo šta je tačno korisniku potrebno, sačuvamo dokumentaciju za funkciju, a takođe i da se osiguramo od činjenice da bi kupac u budućnosti mogao reći da nismo uradili ono što je tražio.
- Svi dijagrami/dijagrami toka/logika itd. Spremamo ga u Confluence/Fat, gdje molimo kupca da u komentarima potvrdi ispravnost buduće implementacije.
- Trudimo se da kupca ne opterećujemo tehničkim detaljima. Ako nam je potrebno razumijevanje kako kupac to želi, onda crtamo primitivne algoritme u obliku dijagrama toka koji kupac može razumjeti i sam sve ispraviti/modifikovati.
- Ako kupac pronađe grešku u projektu, molimo vas da je detaljno opišete u Zhira. Pod kojim okolnostima se to dogodilo, kada, koji je redoslijed radnji izvršio kupac tokom testiranja. Molimo priložite snimke ekrana.
- Pokušavamo svaki dan, najviše svaki drugi dan, da se implementiramo na dev server. Kupac tada počinje testirati funkcionalnost i projekt ne miruje. Istovremeno, ovo je znak za kupca da je projekat u punom razvoju i da mu niko ne priča bajke.
- Često se dešava da kupac ne razume u potpunosti šta mu treba. Zato što stvara novi posao za sebe, sa procesima koji još nisu uspostavljeni. Stoga je vrlo česta situacija kada cijele dijelove koda bacamo u smeće i redizajniramo logiku aplikacije. Iz ovoga slijedi da testovima ne treba pokrivati apsolutno sve. Ima smisla pokriti samo kritičnu funkcionalnost testovima, a onda samo uz rezerve.
- Postoje situacije kada tim shvati da ne poštujemo rokove. Zatim vršimo brzu reviziju zadataka i odmah o tome obavještavamo kupca. Kao izlaz iz situacije, predlažemo pokretanje važnih i kritičnih funkcionalnosti na vrijeme, a ostalo ostaviti za naknadno objavljivanje.
- Ako kupac počne smišljati različite zadatke iz glave, počne maštati i objašnjavati prstima, onda ga tražimo da nam da izgled stranice i da teče logikom koja u potpunosti treba opisati ponašanje cijelog izgleda i njegovih elemenata.
- Prije preuzimanja bilo kojeg zadatka, moramo se uvjeriti da je ova funkcija uključena u uslove našeg ugovora/ugovora. Ako je ovo nova karakteristika koja prevazilazi naše početne ugovore, onda moramo dati cijenu za ovu funkciju ((procijenjeno vrijeme završetka + 30%) x 2) i naznačiti kupcu da će nam trebati toliko vremena da je završimo, plus rok se pomjera za vrijeme procjene pomnoženo sa dva. Uradimo zadatak brže - odlično, svi će imati koristi od toga. Ako ne, onda smo vas pokrili.
c) Šta ne prihvatamo u timu:
- Neposvećenost, nedostatak pribranosti, zaborav
- “Hranjenje doručka.” Ako ne možete završiti zadatak i ne znate kako, onda morate odmah o tome obavijestiti vodstvo tima, a ne čekati do posljednjeg trenutka.
- Obrve i hvale od osobe koja još nije dokazala svoje sposobnosti i profesionalnost. Ako je dokazano, onda je moguće, u granicama pristojnosti :)
- Prevara u svim njenim oblicima. Ako zadatak nije dovršen, onda ne biste trebali mijenjati njegov status u dovršen i pisati u chatu klijenta da je spreman. Računar se pokvario, sistem se srušio, pas je žvakao laptop - sve je to neprihvatljivo. Ako dođe do stvarne više sile, vođa tima mora biti odmah obaviješten.
- Kada je specijalista stalno van mreže i teško je doći do njega tokom radnog vremena.
- Toksičnost u timu nije dozvoljena! Ako se neko sa nečim ne slaže, onda se svi skupe na skup i raspravljaju i odlučuju o tome.
I niz pitanja/teza koje ponekad postavim svom kupcu da razjasnim sve nesporazume:
- Koji su vaši kriterijumi kvaliteta?
- Kako odrediti da li projekat ima problema ili ne?
- Kršenjem svih naših preporuka i savjeta o promjeni/poboljšanju sistema, sve rizike snosite samo Vi
- Sve veće promjene u projektu (na primjer, sve vrste dodatnog toka) dovest će do moguće pojave grešaka (koje ćemo, naravno, popraviti)
- Nemoguće je u roku od nekoliko minuta shvatiti kakav se problem pojavio na projektu, a još manje odmah ga riješiti
- Radimo na specifičnom toku proizvoda (zadaci u Zhira - Razvoj - Testiranje - Deploy). To znači da ne možemo odgovoriti na cijeli tok zahtjeva i pritužbi u chatu.
- Programeri su programeri, a ne profesionalni testeri, i ne mogu osigurati odgovarajući kvalitet testiranja projekta
- Odgovornost za finalno testiranje i prihvatanje proizvodnih zadataka u potpunosti je na vama
- Ako smo već preuzeli zadatak, ne možemo se odmah prebaciti na drugi dok ne završimo trenutni (inače to dovodi do još više grešaka i povećanog vremena razvoja)
- Manje je ljudi u timu (zbog odmora ili bolesti), ali posla ima više i fizički nećemo imati vremena odgovoriti na sve što želite
- Molimo vas da izvršite implementaciju u produkciju bez testiranih zadataka na dev-u - ovo je samo vaš rizik, a ne programeri
- Kada postavljate nejasne zadatke, bez pravilnog toka, bez dizajna, to od nas zahtijeva mnogo više truda i vremena za implementaciju, jer mi moramo obaviti dodatni posao umjesto vas
- Bilo koji zadaci na greškama, bez detaljnog opisa njihove pojave i screenshotova, ne daju nam priliku da shvatimo šta je pošlo po zlu i kako možemo popraviti ovu grešku
- Projekat zahtijeva stalna usavršavanja i poboljšanja radi poboljšanja performansi i sigurnosti. Stoga tim troši dio svog vremena na ova poboljšanja
- Zbog činjenice da imamo prekovremeni rad po satu (hitna popravka), moramo ih nadoknaditi ostalim danima
U pravilu, kupac odmah shvati da u razvoju softvera nije sve tako jednostavno, a sama želja očito nije dovoljna.
Generalno, to je sve. Ostavljam iza kulisa dosta pregovora i početno otklanjanje grešaka svih procesa, ali kao rezultat, sve je ispalo. Mogu reći da je ovaj proces za nas postao svojevrsni “Srebrni metak”. Novi ljudi koji su došli u projekat mogli su se odmah uključiti u posao od prvog dana, jer su svi procesi bili opisani, a dokumentacija i arhitektura u obliku dijagrama su odmah davali predstavu o tome šta sve radimo ovdje.
PS Želio bih pojasniti da na našoj strani nema projekt menadžera. To je na strani kupca. Uopšte nisam tehničar. evropski projekat. Sva komunikacija je samo na engleskom jeziku.
Sretno svima na vašim projektima. Nemojte izgorjeti i pokušajte poboljšati svoje procese.
Izvor u mom .
izvor: www.habr.com