Pozdrav prijatelji. Vrlo često, posebno u outsourcingu, vidim istu sliku. Nedostatak jasnog tijeka rada u timovima na raznim projektima.
Najvažnije je da programeri ne razumiju kako komunicirati s kupcem i međusobno. Kako izgraditi kontinuirani proces razvoja kvalitetnog proizvoda. Kako planirati svoj radni dan i sprinteve.
A sve to u konačnici rezultira probijanjem rokova, prekovremenim radom, stalnim obračunima tko je kriv i nezadovoljstvom kupaca gdje i kako se sve kreće. Nerijetko sve to dovodi do promjene programera, pa čak i cijelih timova. Gubitak kupca, pogoršanje ugleda i tako dalje.
Jedno vrijeme sam baš završio na jednom takvom projektu, gdje je bilo svih tih užitaka.
Nitko nije htio preuzeti odgovornost za projekt (veliko tržište usluga), promet je bio užasan, kupac jednostavno rastrgan i frustriran. Jednom mi je prišao direktor i rekao da imate potrebno iskustvo, pa evo karte u ruke. Uzmite projekt za sebe. Ako zajebeš, zatvorit ćemo projekt i sve izbaciti. Ići će, bit će cool, pa vodite i razvijajte kako vama odgovara. Kao rezultat toga, postao sam voditelj tima za projekt i sve je palo na moja pleća.
Prvo što sam napravio bilo je da sam ispočetka razvio tijek rada koji je bio usklađen s mojom tadašnjom vizijom i napisao opis posla za tim. Provođenje nije bilo lako. Ali u roku od mjesec dana sve se posložilo, programeri i klijent su se navikli i sve je prošlo tiho i udobno. Kako bih pokazao momčadi da ovo nije samo "oluja u šalici", već pravi izlaz iz situacije, preuzeo sam maksimalnu količinu odgovornosti, maknuvši neugodnu rutinu iz momčadi.
Već je prošla godina i pol, a projekt se razvija bez prekovremenog rada, bez “štakorskih utrka” i svih vrsta stresa. Neki ljudi iz starog tima nisu htjeli tako raditi i otišli su, drugi su, naprotiv, bili jako zadovoljni što su se pojavila transparentna pravila. Ali na kraju, svi u timu su vrlo motivirani i poznaju ogroman projekt u cijelosti, uključujući front-end i back-end. Uključujući i bazu koda i svu poslovnu logiku. Došlo je čak do točke da nismo samo "veslači", već sami smišljamo mnoge poslovne procese i nove značajke koje se poslu sviđaju.
Zahvaljujući ovakvom našem pristupu, kupac je odlučio naručiti još jednu tržnicu od naše tvrtke, što je dobra vijest.
Budući da ovo radi na mom projektu, možda će i pomoći nekome. Dakle, sam proces koji nam je pomogao spasiti projekt:
Proces timskog rada na projektu “My Favorite Project”
a) Interni timski proces (između programera)
- Sva izdanja kreirana su u Jira sustavu
- Svaki zadatak treba opisati što je više moguće i izvršiti samo jednu radnju
- Bilo koja značajka, ako je dovoljno složena, podijeljena je na mnogo malih zadataka
- Tim radi na značajkama kao jednom zadatku. Prvo, svi zajedno radimo na jednoj značajki, šaljemo je na testiranje, a zatim preuzimamo sljedeću.
- Svaki zadatak je označen, za backend ili frontend
- Postoje vrste zadataka i grešaka. Morate ih ispravno naznačiti.
- Nakon završetka zadatka, on se prebacuje u status pregleda koda (u ovom slučaju se kreira zahtjev za povlačenjem za kolegu)
- Osoba koja je izvršila zadatak odmah prati svoje vrijeme za ovaj zadatak.
- Nakon provjere koda, PR će odobriti i nakon toga, onaj koji je izvršio ovaj zadatak samostalno ga spaja u master granu, nakon čega mu mijenja status u ready for deployment to dev server.
- Sve zadatke spremne za implementaciju na dev server postavlja voditelj tima (njegovo područje odgovornosti), ponekad i član tima, ako je nešto hitno. Nakon implementacije, svi zadaci iz spremni za implementaciju u dev prenose se u status - spremni za testiranje na dev
- Sve zadatke testira kupac
- Kada je kupac testirao zadatak na dev-u, on ga prebacuje u status spreman za implementaciju u proizvodnju
- Za implementaciju u proizvodnju, imamo zasebnu granu, gdje spajamo master samo prije implementacije
- Ako tijekom 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 stvaranja do završetka: Obaveze → U razvoju → Pregled koda → Spremno za implementaciju na dev → QA na dev → (Povratak na dev) → Spremno za implementaciju na prod → QA na prod → Gotovo
- Svaki programer samostalno testira svoj kod, uključujući i kao korisnik stranice. Nije dopušteno spojiti granu u glavnu osim ako se pouzdano zna da kod radi.
- Svaki zadatak ima prioritete. Prioritete postavlja kupac ili voditelj tima.
- Programeri prvi dovršavaju prioritetne zadatke.
- Programeri mogu međusobno dodjeljivati zadatke ako su u sustavu pronađene različite pogreške ili se jedan zadatak sastoji od rada nekoliko stručnjaka.
- Svi zadaci koje korisnik kreira idu voditelju tima, koji ih procjenjuje i ili traži od korisnika da ih modificira ili ih dodjeljuje jednom od članova tima.
- Svi zadaci koji su spremni za implementaciju u dev ili prod također idu voditelju tima, koji samostalno određuje kada i kako izvršiti implementaciju. Nakon svake implementacije, voditelj tima (ili član tima) mora o tome obavijestiti kupca. I također promijenite statuse zadataka u spremni za testiranje za razvoj/nastavak.
- Svaki dan u isto vrijeme (kod nas je to u 12.00) održavamo sastanak svih članova tima
- Svi na sastanku izvještavaju, uključujući i vođu tima, o tome što su radili jučer i što planiraju učiniti danas. Što ne radi i zašto. Na taj način cijeli tim je svjestan tko što radi i u kojoj je fazi projekt. To nam daje priliku predvidjeti i prilagoditi, ako je potrebno, naše procjene i rokove.
- Na sastanku voditelj tima također govori o svim promjenama u projektu i razini trenutnih grešaka koje klijent nije pronašao. Sve pogreške su razvrstane i dodijeljene svakom članu tima da ih riješi.
- Na sastanku voditelj tima dodjeljuje zadatke svakoj osobi, uzimajući u obzir trenutno opterećenje programera, njihovu razinu stručne osposobljenosti, a također uzimajući u obzir blizinu određenog zadatka onome što programer trenutno radi.
- Na sastanku voditelj tima razvija opću strategiju za arhitekturu i poslovnu logiku. Nakon toga cijeli tim raspravlja o tome i odlučuje napraviti prilagodbe ili usvojiti ovu strategiju.
- Svaki programer samostalno piše kod i gradi algoritme unutar okvira jedinstvene arhitekture i poslovne logike. Svatko može izraziti svoje viđenje provedbe, ali nitko nikoga ne tjera da to čini ovako, a ne drugačije. Svaka odluka je opravdana. Ako postoji bolje rješenje, ali za to sada nema vremena, tada 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 s pojašnjavanjem zadatka s kupcem pada na ramena programera. Tehnička pitanja mogu se postaviti voditelju tima ili kolegama.
- Ako programer ne razumije bit zadatka, a kupac to nije mogao jasno objasniti, tada prelazi na sljedeći zadatak. A voditelj tima uzima trenutni i raspravlja s kupcem.
- Programer bi svaki dan trebao pisati u chatu klijenta na kojim je zadacima radio jučer i na kojim će zadacima raditi danas
- Proces rada odvija se prema Scrumu. Sve je podijeljeno na sprinteve. Svaki sprint traje dva tjedna.
- Sprintove kreira, popunjava i zatvara vođa tima.
- Ako projekt ima stroge rokove, pokušavamo približno procijeniti sve zadatke. I spojili smo ih u sprint. Ako korisnik pokuša dodati više zadataka u sprint, postavljamo prioritete i prenosimo neke druge zadatke na sljedeći sprint.
b) Proces rada s kupcem
- Svaki programer može i treba komunicirati s kupcem
- Ne može se dopustiti da kupac nameće svoja pravila igre. Kupcu je potrebno na ljubazan i prijateljski način jasno dati do znanja da smo mi specijalisti u svom području i samo mi moramo graditi procese rada i uključiti kupca u njih
- Potrebno je, idealno, prije početka implementacije bilo koje funkcionalnosti, izraditi dijagram toka cijelog logičkog procesa za značajku (workflow). I pošaljite ga kupcu na potvrdu. Ovo se odnosi samo na složene i neočigledne funkcije, na primjer, sustav plaćanja, sustav obavijesti itd. To će nam omogućiti da točnije razumijemo što točno korisnik treba, spremimo dokumentaciju za značajku, a također ćemo se osigurati od činjenice da bi korisnik u budućnosti mogao reći da nismo učinili 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.
- Nastojimo kupca ne opterećivati tehničkim detaljima. Ako trebamo razumjeti kako kupac to želi, tada crtamo primitivne algoritme u obliku dijagrama toka koji kupac može razumjeti i sve sam ispraviti/modificirati.
- Ako kupac pronađe grešku u projektu, molimo vas da je detaljno opišete u Fatu. U kojim okolnostima se to dogodilo, kada, koji je redoslijed radnji proveo kupac tijekom testiranja. Priložite snimke zaslona.
- Svaki dan, najviše svaki drugi dan, pokušavamo implementirati na razvojni poslužitelj. Kupac tada počinje testirati funkcionalnost i projekt ne miruje. Ujedno, to je i oznaka kupcu da je projekt u punom razvoju i da mu nitko ne priča bajke.
- Često se događa da kupac ne razumije u potpunosti što mu je potrebno. Jer on sebi stvara novi posao, s procesima koji još nisu uspostavljeni. Stoga je vrlo česta situacija kada cijele dijelove koda bacamo u smeće i redizajniramo logiku aplikacije. Iz ovoga proizlazi da ne treba apsolutno sve pokriti testovima. Testovima ima smisla pokriti samo kritičnu funkcionalnost, i to samo uz rezerve.
- Postoje situacije kada ekipa shvati da ne poštujemo rokove. Zatim provodimo brzu reviziju zadataka i odmah o tome obavještavamo kupca. Kao izlaz iz situacije predlažemo pokretanje važnih i kritičnih funkcija na vrijeme, a ostalo ostaviti za post-izdanje.
- Ako kupac počne smišljati različite zadatke iz glave, počne maštati i objašnjavati prstima, tada ga tražimo da nam dostavi izgled stranice i teče logikom koja bi trebala u potpunosti opisati ponašanje cijelog izgleda i njegovih elemenata.
- Prije nego što preuzmemo bilo koji zadatak, moramo provjeriti je li ova značajka uključena u uvjete našeg sporazuma/ugovora. Ako je ovo nova značajka koja nadilazi naše početne dogovore, tada moramo odrediti cijenu ove značajke ((procijenjeno vrijeme dovršetka + 30%) x 2) i navesti kupcu da će nam trebati toliko vremena da je dovršimo, plus rok se pomiče za predviđeno vrijeme pomnoženo s dva. Obavimo zadatak brže - super, svi će imati koristi od toga. Ako niste, mi vas pokrivamo.
c) Što ne prihvaćamo u timu:
- Neposvećenost, nedostatak pribranosti, zaboravnost
- “Doručak za hranjenje.” Ako ne možete izvršiti zadatak i ne znate kako, morate o tome odmah obavijestiti voditelja tima, a ne čekati zadnji trenutak.
- Obrve i hvalisanje od osobe koja još nije dokazala svoje sposobnosti i profesionalnost. Ako je dokazano, onda je moguće, u granicama pristojnosti :)
- Prijevara u svim oblicima. Ako zadatak nije dovršen, ne biste trebali mijenjati njegov status u dovršen i napisati u chatu klijenta da je spreman. Računalo se pokvarilo, sustav se srušio, pas je žvakao laptop - sve je to nedopustivo. Ako se dogodi stvarna viša sila, potrebno je odmah obavijestiti voditelja tima.
- Kada je stručnjak cijelo vrijeme offline i teško ga je dobiti tijekom radnog vremena.
- Toksičnost u timu nije dopuštena! Ako se netko s nečim ne slaže, onda se svi okupe na skupu i o tome raspravljaju i odlučuju.
I nekoliko pitanja/teza koje ponekad postavim svojim klijentima kako bih razjasnio sve nesporazume:
- Koji su vaši kriteriji kvalitete?
- Kako odrediti ima li projekt problema ili ne?
- Kršenjem svih naših preporuka i savjeta o promjeni/poboljšanju sustava sve rizike snosite samo vi
- Sve veće promjene u projektu (primjerice, sve vrste dodatnog protoka) dovest će do moguće pojave grešaka (koje ćemo, naravno, popraviti)
- Nemoguće je u roku od nekoliko minuta razumjeti kakav se problem pojavio na projektu, a još manje ga odmah riješiti
- Radimo na određenom tijeku proizvoda (zadaci u Zhiri - Razvoj - Testiranje - Postavljanje). 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ću kvalitetu testiranja projekta
- Odgovornost za završno testiranje i prihvaćanje proizvodnih zadataka u potpunosti leži na vama
- Ako smo već preuzeli zadatak, ne možemo se odmah prebaciti na druge dok ne dovršimo trenutni (u suprotnom to dovodi do još više grešaka i produljenog vremena razvoja)
- Manje je ljudi u timu (zbog godišnjih odmora ili bolesti), ali ima više posla i fizički nećemo imati vremena odgovoriti na sve što želite
- Molimo vas da izvršite implementaciju u produkciju bez testiranih zadataka na programeru - to je samo vaš rizik, a ne programeri
- Kada postavljate nejasne zadatke, bez pravilnog tijeka, bez dizajna, to od nas zahtijeva puno više truda i vremena implementacije, jer mi moramo obaviti dodatnu količinu posla umjesto vas
- Bilo koji zadaci o greškama, bez detaljnog opisa njihove pojave i snimaka zaslona, ne daju nam priliku da shvatimo što je pošlo po zlu i kako možemo popraviti tu grešku
- Projekt zahtijeva stalnu doradu i poboljšanja za poboljšanje performansi i sigurnosti. Stoga tim troši dio svog vremena na ova poboljšanja
- S obzirom na to da imamo prekovremene sate (hitni popravci), moramo ih nadoknaditi drugim danima
U pravilu, kupac odmah razumije da sve nije tako jednostavno u razvoju softvera, a sama želja očito nije dovoljna.
Općenito, to je sve. Ostavljam iza scene puno pregovora i početno otklanjanje pogrešaka svih procesa, ali kao rezultat, sve je uspjelo. Mogu reći da je ovaj proces za nas postao svojevrsni “Silver Bullet”. Novi ljudi koji su došli na projekt mogli su se odmah od prvog dana uključiti u rad, jer su svi procesi bili opisani, a dokumentacija i arhitektura u obliku dijagrama odmah su dali predodžbu o tome što sve mi ovdje radimo.
PS Želio bih pojasniti da s naše strane nema voditelja projekta. To je na strani kupca. Uopće nisam tehničar. europski projekt. Sva komunikacija je samo na engleskom jeziku.
Sretno svima na projektima. Nemojte izgorjeti i pokušajte poboljšati svoje procese.
Izvor u rudniku .
Izvor: www.habr.com