Pozdravljeni prijatelji. Nemalokrat, zlasti pri zunanjem izvajanju, vidim isto sliko. Pomanjkanje jasnega poteka dela v timih na različnih projektih.
Najbolj pomembno je, da programerji ne razumejo, kako komunicirati s stranko in med seboj. Kako zgraditi neprekinjen proces razvoja kakovostnega izdelka. Kako načrtovati svoj delovnik in sprinte.
In vse to na koncu povzroči zamujene roke, nadure, nenehne obračune, kdo je kriv, in nezadovoljstvo strank, kje in kako se vse odvija. Nemalokrat vse to vodi v menjavo programerjev ali celo celih ekip. Izguba stranke, poslabšanje ugleda itd.
Nekoč sem pač končal na takem projektu, kjer so bili vsi ti užitki.
Nihče ni hotel prevzeti odgovornosti za projekt (velika tržnica storitev), promet je bil grozen, stranka preprosto raztrgana in razočarana. Nekoč je generalni direktor prišel do mene in rekel, da imate potrebne izkušnje, zato imate karte v rokah. Vzemite projekt zase. Če se zajebeš, bomo projekt zaprli in vse vrgli ven. Uspelo bo, kul bo, potem ga vodite in razvijajte, kot se vam zdi primerno. Posledično sem postal vodja ekipe za projekt in vse je padlo na moja ramena.
Prva stvar, ki sem jo naredil, je bila, da sem iz nič razvil potek dela, ki je bil usklajen z mojo takratno vizijo, in napisal opis delovnega mesta za ekipo. Izvajanje ni bilo enostavno. Toda v kakšnem mesecu se je vse uredilo, razvijalci in naročnik so se navadili in vse je potekalo tiho in udobno. Da bi ekipi pokazal, da to ni le »nevihta v skodelici«, ampak pravi izhod iz situacije, sem prevzel največjo mero odgovornosti in iz ekipe odstranil neprijetno rutino.
Minilo je že leto in pol in projekt se razvija brez nadur, brez "podganjih dirk" in vseh vrst stresa. Nekateri v stari ekipi niso želeli tako delati in so odšli, drugi so bili, nasprotno, zelo zadovoljni, da so se pojavila transparentna pravila. Toda na koncu so vsi v ekipi zelo motivirani in poznajo ogromen projekt v celoti, vključno s sprednjim in zadnjim delom. Vključuje tako osnovo kode kot celotno poslovno logiko. Prišlo je celo do te mere, da nismo samo »veslači«, ampak sami izdelamo številne poslovne procese in nove funkcije, ki so podjetju všeč.
Zaradi takšnega pristopa z naše strani se je stranka odločila, da pri našem podjetju naroči še eno tržnico, kar je dobra novica.
Ker to deluje na mojem projektu, bo morda komu tudi pomagalo. Torej, sam postopek, ki nam je pomagal rešiti projekt:
Proces timskega dela na projektu "Moj najljubši projekt"
a) Notranji timski proces (med razvijalci)
- Vse težave so ustvarjene v sistemu Jira
- Vsako nalogo je treba čim bolj opisati in izvesti samo eno dejanje
- Vsaka funkcija, če je dovolj zapletena, je razdeljena na številne majhne naloge
- Skupina dela na funkcijah kot eno nalogo. Najprej vsi skupaj delamo na eni funkciji, jo pošljemo v testiranje, nato vzamemo naslednjo.
- Vsako opravilo je označeno za zaledje ali čelni del
- Obstajajo vrste nalog in napak. Morate jih pravilno navesti.
- Po opravljeni nalogi se ta prenese v status pregleda kode (v tem primeru se za sodelavca ustvari zahteva za vlečenje)
- Oseba, ki je opravila nalogo, takoj spremlja svoj čas za to nalogo.
- Po preverjanju kodo PR potrdi in nato jo tisti, ki je to nalogo samostojno opravil, združi v glavno vejo, nakar ji spremeni status v pripravljen za uvedbo na dev strežnik.
- Vse naloge, ki so pripravljene za namestitev na razvijalski strežnik, razporedi vodja ekipe (njegovo področje odgovornosti), včasih tudi član ekipe, če je kaj nujnega. Po uvedbi se vse naloge iz pripravljenosti za uvedbo v razvijalce prenesejo v status - pripravljene za testiranje na razvijalcu
- Vse naloge testira stranka
- Ko stranka preizkusi nalogo na razvijalcu, jo prenese v stanje pripravljeno za uvedbo v produkcijo.
- Za uvedbo v produkcijo imamo ločeno podružnico, kjer master združimo šele pred uvedbo
- Če stranka med testiranjem odkrije hrošče, vrne nalogo v revizijo in nastavi status vrnjene v revizijo. Tako ločimo nove naloge od tistih, ki niso opravile testiranja.
- Posledično gredo vse naloge od ustvarjanja do dokončanja: Narediti → V razvoju → Pregled kode → Pripravljeno za uvedbo v razvijalce → QA na razvijalce → (Vrnitev na razvijalce) → Pripravljeno na uvedbo v prod → QA na prod → Končano
- Vsak razvijalec svojo kodo testira neodvisno, tudi kot uporabnik spletnega mesta. Veje ni dovoljeno združiti z glavno, razen če je zagotovo znano, da koda deluje.
- Vsaka naloga ima prioritete. Prioritete določi stranka ali vodja ekipe.
- Razvijalci najprej opravijo prednostne naloge.
- Razvijalci lahko drug drugemu dodelijo naloge, če so bile v sistemu odkrite različne napake ali če je ena naloga sestavljena iz dela več strokovnjakov.
- Vse naloge, ki jih stranka ustvari, gredo k vodji ekipe, ki jih oceni in prosi stranko, da jih spremeni, ali pa jih dodeli enemu od članov ekipe.
- Vse naloge, ki so pripravljene za uvedbo v dev ali prod, gredo tudi k vodji ekipe, ki samostojno določi, kdaj in kako izvesti uvedbo. Po vsaki uvedbi mora vodja ekipe (ali član ekipe) o tem obvestiti stranko. Prav tako spremenite stanja za opravila v pripravljeno za testiranje za razv./nad.
- Vsak dan ob isti uri (pri nas je to ob 12.00) organiziramo sestanek med vsemi člani ekipe
- Vsi na sestanku poročajo, vključno z vodjo ekipe, kaj so naredili včeraj in kaj nameravajo narediti danes. Kaj ne deluje in zakaj. Tako je celotna ekipa seznanjena s tem, kdo kaj dela in v kateri fazi je projekt. To nam daje možnost, da predvidimo in po potrebi prilagodimo svoje ocene in roke.
- Na sestanku vodja ekipe tudi spregovori o vseh spremembah v projektu in stopnji trenutnih napak, ki jih stranka ni odkrila. Vse napake so razvrščene in dodeljene vsakemu članu ekipe, da jih odpravi.
- Na sestanku vodja ekipe vsakemu posebej dodeli naloge, pri čemer upošteva trenutno obremenjenost razvijalcev, njihovo stopnjo strokovne usposobljenosti ter upošteva tudi bližino posamezne naloge tistemu, kar razvijalec trenutno počne.
- Na sestanku vodja ekipe razvije splošno strategijo za arhitekturo in poslovno logiko. Nato celotna ekipa razpravlja o tem in se odloči za prilagoditve ali sprejetje te strategije.
- Vsak razvijalec samostojno piše kodo in gradi algoritme v okviru enotne arhitekture in poslovne logike. Vsakdo lahko izrazi svoje videnje izvedbe, vendar nihče nikogar ne sili, da to počne tako in ne drugače. Vsaka odločitev je upravičena. Če obstaja boljša rešitev, vendar zanjo zdaj ni časa, se v maščobi ustvari naloga za prihodnje preoblikovanje določenega dela kode.
- Ko razvijalec prevzame nalogo, jo prenese v razvojni status. Vsa komunikacija v zvezi s pojasnitvijo naloge s stranko pade na ramena razvijalca. Tehnična vprašanja lahko zastavite vodji ekipe ali sodelavcem.
- Če razvijalec ne razume bistva naloge in ga stranka ni mogla jasno razložiti, nadaljuje z naslednjo nalogo. In vodja ekipe vzame trenutnega in se o njem pogovori s stranko.
- Vsak dan mora razvijalec v strankin klepet napisati, katere naloge je delal včeraj in katere naloge bo delal danes.
- Delovni proces poteka po Scrumu. Vse je razdeljeno na sprinte. Vsak sprint traja dva tedna.
- Sprinte ustvari, zapolni in zaključi vodja ekipe.
- Če ima projekt stroge roke, potem poskušamo približno oceniti vse naloge. In smo jih združili v sprint. Če stranka poskuša v sprint dodati več nalog, potem postavimo prioritete in nekatere druge naloge prenesemo na naslednji sprint.
b) Proces dela s stranko
- Vsak razvijalec lahko in mora komunicirati s stranko
- Stranka ne sme vsiljevati svojih pravil igre. Stranki je treba na vljuden in prijazen način pojasniti, da smo specialisti na svojem področju in samo mi moramo graditi delovne procese in vanje vključevati stranko.
- V idealnem primeru je treba, preden začnete izvajati katero koli funkcionalnost, ustvariti diagram poteka celotnega logičnega procesa za funkcijo (workflow). In ga pošljite stranki v potrditev. To velja samo za zapletene in neočitne funkcije, na primer plačilni sistem, sistem obveščanja itd. To nam bo omogočilo, da bomo natančneje razumeli, kaj točno stranka potrebuje, shranili dokumentacijo za funkcijo in se tudi zavarovali pred dejstvom, da bi stranka v prihodnosti rekla, da nismo storili, kar je zahtevala.
- Vsi diagrami/diagrami poteka/logika itd. Shranjujemo v Confluence/Fat, kjer naročnika prosimo, da v komentarju potrdi pravilnost bodoče izvedbe.
- Trudimo se, da stranke ne obremenjujemo s tehničnimi podrobnostmi. Če potrebujemo razumevanje, kako stranka to želi, potem narišemo primitivne algoritme v obliki diagrama poteka, ki ga stranka lahko razume in vse sama popravi/spremeni.
- Če stranka najde napako v projektu, vas prosimo, da jo zelo podrobno opišete v Zhira. V kakšnih okoliščinah se je to zgodilo, kdaj, kakšno zaporedje dejanj je stranka izvedla med testiranjem. Priložite posnetke zaslona.
- Poskušamo vsak dan, največ vsak drugi dan, uvesti na strežnik za razvijalce. Stranka nato začne testirati funkcionalnost in projekt ne miruje. Hkrati je to za naročnika znak, da je projekt v polnem razvoju in mu nihče ne pripoveduje pravljic.
- Pogosto se zgodi, da stranka ne razume popolnoma, kaj potrebuje. Ker si ustvarja nov posel, s procesi, ki še niso vzpostavljeni. Zato je zelo pogosta situacija, ko cele dele kode vržemo v smeti in preoblikujemo logiko aplikacije. Iz tega sledi, da s testi ne bi smeli zajeti čisto vsega. S testi je smiselno pokriti le kritično funkcionalnost in še to le s pridržki.
- Pridejo situacije, ko ekipa ugotovi, da se ne držimo rokov. Nato opravimo hitro revizijo nalog in o tem takoj obvestimo stranko. Kot izhod iz situacije predlagamo, da pravočasno zaženete pomembne in kritične funkcije, ostalo pa pustite za po izdaji.
- Če si stranka začne izmišljati različne naloge iz glave, začne fantazirati in razlagati s prsti, potem jo prosimo, da nam posreduje postavitev strani in teče z logiko, ki naj v celoti opisuje obnašanje celotne postavitve in njenih elementov.
- Preden prevzamemo katero koli nalogo, se moramo prepričati, da je bila ta funkcija vključena v pogoje naše pogodbe/pogodbe. Če je to nova funkcija, ki presega naše prvotne dogovore, moramo to funkcijo ceniti ((predvideni čas dokončanja + 30 %) x 2) in stranki navesti, da bomo potrebovali toliko časa, da jo dokončamo, plus rok se premakne za predvideni čas, pomnožen z dva. Nalogo opravimo hitreje – super, vsi bodo imeli koristi. Če ne, potem vas bomo pokrili.
c) Česa v ekipi ne sprejemamo:
- Nezavezanost, pomanjkanje zbranosti, pozabljivost
- “Hranjenje z zajtrkom.” Če naloge ne morete dokončati in ne veste kako, morate o tem takoj obvestiti vodjo ekipe in ne čakati do zadnje minute.
- Brskanje in hvalisanje od osebe, ki še ni dokazala svojih sposobnosti in profesionalnosti. Če je dokazano, potem je možno, v mejah spodobnosti :)
- Prevara v vseh oblikah. Če naloga ni dokončana, njenega statusa ne spremenite v dokončano in v klepet odjemalca napišite, da je pripravljena. Računalnik se je pokvaril, sistem se je sesul, pes je žvečil prenosnik – vse to je nesprejemljivo. Če nastopi realna višja sila, je treba takoj obvestiti vodjo ekipe.
- Ko je specialist ves čas offline in je med delovnim časom težko dosegljiv.
- Toksičnost v ekipi ni dovoljena! Če se kdo s čim ne strinja, potem se vsi skupaj zberemo na shodu in o tem razpravljamo in odločamo.
In nekaj vprašanj/tez, ki jih včasih zastavim svoji stranki, da razčistim vse nesporazume:
- Kakšna so vaša merila kakovosti?
- Kako ugotovite, ali ima projekt težave ali ne?
- S kršenjem vseh naših priporočil in nasvetov o spremembi/izboljšanju sistema vsa tveganja nosite samo vi
- Vsaka večja sprememba projekta (na primer vse vrste dodatnega toka) bo povzročila morebiten pojav napak (ki jih bomo seveda odpravili)
- Nemogoče je v nekaj minutah razumeti, kakšna težava se je pojavila na projektu, še manj pa jo takoj odpraviti
- Delamo na določenem toku izdelka (Naloge v Zhiri - Razvoj - Testiranje - Razmestitev). To pomeni, da ne moremo odgovoriti na celoten tok zahtev in pritožb v klepetu.
- Programerji so programerji, ne profesionalni preizkuševalci in ne morejo zagotoviti ustrezne kakovosti testiranja projekta
- Odgovornost za končno testiranje in prevzem proizvodnih nalog je v celoti vaša
- Če smo neko nalogo že prevzeli, ne moremo takoj preklopiti na druge, dokler ne dokončamo trenutne (sicer to povzroči še več hroščev in daljši razvojni čas)
- V ekipi je manj ljudi (zaradi dopustov ali bolezni), dela pa je več in fizično ne bomo imeli časa odgovoriti na vse, kar želite
- Prosimo vas, da izvedete uvedbo v produkcijo brez preizkušenih nalog na razvijalcu – to je samo vaše tveganje, ne razvijalci
- Ko postavljate nejasne naloge, brez pravilnega poteka, brez načrtov, to od nas zahteva veliko več truda in časa za izvedbo, saj moramo namesto vas opraviti dodatno količino dela.
- Kakršna koli opravila o hroščih brez podrobnega opisa njihovega pojava in posnetkov zaslona nam ne dajejo priložnosti, da bi razumeli, kaj je šlo narobe in kako lahko to napako odpravimo
- Projekt zahteva nenehno izpopolnjevanje in izboljšave za izboljšanje učinkovitosti in varnosti. Zato ekipa del svojega časa porabi za te izboljšave
- Ker imamo nadure po urah (nujni popravki), jih moramo nadomestiti druge dni.
Stranka praviloma takoj razume, da pri razvoju programske opreme ni vse tako preprosto in samo želja očitno ni dovolj.
Na splošno je to vse. Za prizori pustim veliko pogajanj in začetnega odpravljanja napak v vseh procesih, a kot rezultat se je vse izšlo. Lahko rečem, da je ta proces za nas postal nekakšna "srebrna krogla". Novi ljudje, ki so prišli v projekt, so se lahko takoj vključili v delo od prvega dne, saj so bili vsi procesi opisani, dokumentacija in arhitektura v obliki diagramov pa sta takoj dala predstavo o tem, kaj vse tu počnemo.
PS Rad bi pojasnil, da na naši strani ni vodje projekta. To je na strani stranke. Sploh nisem tehnik. evropski projekt. Vsa komunikacija je samo v angleščini.
Vso srečo vsem pri vaših projektih. Ne izgorevajte in poskušajte izboljšati svoje procese.
Vir v rudniku .
Vir: www.habr.com