🥇 Lan-prozesua taldean antolatzea IT proiektu batean

Kaixo lagunak. Askotan, batez ere azpikontratazioan, argazki bera ikusten dut. Hainbat proiektutan taldeetan lan-fluxu argirik ez izatea.

Garrantzitsuena da programatzaileek ez dutela ulertzen bezeroarekin eta elkarren artean nola komunikatu. Nola eraiki kalitatezko produktu bat garatzeko prozesu etengabea. Nola planifikatu zure lanaldia eta esprintak.

Eta horrek guztiak, azken finean, epeak galdu, aparteko orduak, errudun noren inguruan etengabeko borrokak eragiten ditu eta dena nora eta nola mugitzen denarekin bezeroaren atsekabea eragiten du. Askotan, horrek guztiak programatzaileen aldaketa dakar, edota talde osoak. Bezero bat galtzea, ospearen hondatzea, etab.

Garai batean, halako proiektu batean amaitu nuen, non gozamen horiek guztiak zeuden.

Inork ez zuen proiektuaren ardura hartu nahi (zerbitzuen merkatu handi bat), fakturazioa izugarria zen, bezeroa urratuta eta zapuztuta zegoen. CEOa behin etorri zitzaidan eta esan zidan behar den esperientzia duzula, beraz, hemen dituzu esku artean dituzun txartelak. Hartu proiektua zeuretzat. Izorratzen baduzu, proiektua itxi eta denak kanporatuko ditugu. Funtzionatuko du, polita izango da, gero eraman eta garatu behar duzun moduan. Ondorioz, proiektuaren talde buru bihurtu nintzen eta dena sorbaldetan erori zitzaidan.

Egin nuen lehenengo gauza, momentuko nire ikuspegiarekin bat datorren lan-fluxu bat garatzea izan zen hutsetik, eta lan-deskribapena idatzi zuen taldearentzat. Ezartzea ez zen erraza izan. Baina hilabete baten buruan dena konpondu zen, garatzaileak eta bezeroa ohitu ziren, eta dena lasai eta eroso joan zen. Taldeari erakusteko, hori ez zela “te-katilu batean ekaitza” bat besterik ez, egoeratik ateratzeko benetako bidea baizik, gehieneko ardurak hartu nituen, taldetik errutina desatsegina kenduz.

Urte eta erdi igaro da jada, eta proiektua luzapenik gabe garatzen ari da, “arratoi lasterketarik” eta mota guztietako estresik gabe. Talde zaharreko batzuek ez zuten horrela lan egin nahi eta alde egin zuten; beste batzuk, aitzitik, oso pozik zeuden arau gardenak agertu zirelako. Baina, azkenean, taldeko guztiak oso motibatuta daude eta oso-osorik ezagutzen dute proiektu erraldoia, front-end zein backend barne. Kode-oinarria eta negozio-logika guztia barne. Are gehiago, "arraunlariak" ez garen puntura iritsi da, baina guk geuk negozio-prozesu asko eta negozioak gustuko dituen ezaugarri berriekin gatoz.

Gure ikuspegi horri esker, bezeroak gure enpresari beste marketplace bat eskatzea erabaki zuen, eta hori albiste ona da.

Honek nire proiektuan funtzionatzen duenez, agian norbaiti ere lagunduko dio. Beraz, proiektua salbatzen lagundu zigun prozesua bera:

"My Favorite Project" proiektuan talde-lanaren prozesua

a) Talde barruko prozesua (garatzaileen artekoa)

Arazo guztiak Jira sisteman sortzen dira
Zeregin bakoitza ahalik eta gehien deskribatu behar da eta ekintza bakarra egin behar da
Edozein ezaugarri, nahikoa konplexua bada, zeregin txiki askotan banatzen da
Taldeak eginbideetan lan egiten du zeregin bakar gisa. Lehenik eta behin, denok batera funtzionatzen dugu funtzio batean, bidali probak egiteko, eta gero hartu hurrengoa.
Zeregin bakoitza markatuta dago, backend edo frontend-erako
Zereginak eta akats motak daude. Zuzen adierazi behar dituzu.
Zeregin bat amaitu ondoren, kodea berrikusteko egoerara transferitzen da (kasu honetan, tira-eskaera bat sortzen da lankide bati)
Zeregin hori bete duen pertsonak berehala egiten du jarraipena zeregin honetarako duen denbora.
Kodea egiaztatu ondoren, PR-k onartuko du eta, horren ostean, zeregin hori modu independentean egin duenak adar nagusiarekin batzen du, eta ondoren, bere egoera aldatzen du garapen zerbitzarian inplementatzeko prest.
Dev zerbitzarian inplementatzeko prest dauden zeregin guztiak taldeko buruak (bere ardura-eremua) zabaltzen ditu, batzuetan taldekide batek, zerbait premiazkoa bada. Inplementatu ondoren, inplementatzeko prest hasi eta garatzailera arteko zeregin guztiak egoerara transferitzen dira - garatzailean probatzeko prest.
Zeregin guztiak bezeroak probatzen ditu
Bezeroak zeregina garatzailean probatu duenean, ekoizpenera inplementatzeko prest dagoen egoerara transferitzen du
Ekoizpenera hedatzeko, adar bereizi bat dugu, non maisua inplementatu baino lehen batzen dugun
Probetan bezeroak akatsak aurkitzen baditu, zeregina berrikusteko itzultzen du, bere egoera berrikusteko itzuli den moduan ezarriz. Horrela, zeregin berriak probak gainditu ez dituztenetatik bereizten ditugu.
Ondorioz, zeregin guztiak sorreratik amaitzen dira: Egiteko → Garapenean → Kodearen berrikuspena → Garatzailean inplementatu prest → Garatzailean QA → (Itzuli garapenera) → Inplementatu prest → Produkzioan QA → Egina
Garatzaile bakoitzak bere kodea probatzen du modu independentean, gunearen erabiltzaile gisa barne. Ezin da adar bat nagusiarekin batu kodeak funtzionatzen duela ziur jakin ezean.
Zeregin bakoitzak lehentasunak ditu. Lehentasunak bezeroak edo taldeko buruak ezartzen ditu.
Garatzaileek lehentasunezko zereginak betetzen dituzte lehenik.
Garatzaileek elkarri zereginak esleitu diezazkiokete sisteman akats desberdinak aurkitu badira edo zeregin bat hainbat espezialistaren lana bada.
Bezeroak sortzen dituen zeregin guztiak taldeko buruari doaz, honek ebaluatzen ditu eta bezeroari aldatzeko eskatzen dio edo taldekideetako bati esleitzen dizkio.
Garapenerako edo produkziorako inplementatzeko prest dauden zeregin guztiak taldeko buruari ere ematen dizkiote, eta honek independenteki zehazten du hedapena noiz eta nola egin. Inplementazio bakoitzaren ondoren, taldeko buruak (edo taldeko kideak) bezeroari horren berri eman behar dio. Eta aldatu eginkizunen egoerak dev/cont probatzeko prest egoteko.
Egunero ordu berean (guretzat 12.00etan da) taldekide guztien arteko bilera bat egiten dugu
Bileran parte hartzen duten guztiek, taldeburuak barne, atzo egin zutenaren eta gaur egiteko asmoaren berri ematen dute. Zerk ez du funtzionatzen eta zergatik. Horrela talde osoa jakitun da nork zer egiten duen eta zein fasetan dagoen proiektua. Horrek aukera ematen digu aurreikusteko eta doitzeko, behar izanez gero, gure estimazioak eta epeak.
Bileran, taldeko buruak proiektuan izandako aldaketa guztiei eta bezeroak aurkitu ez dituen egungo akatsen mailari buruz ere hitz egiten du. Akats guztiak konpondu eta taldekide bakoitzari esleitzen zaizkio horiek konpontzeko.
Bileran, taldeburuak pertsona bakoitzari zereginak esleitzen dizkio, garatzaileen unean uneko lan-karga, bere lanbide-prestakuntza-maila kontuan hartuta, eta, era berean, zeregin jakin bat garatzailea une honetan egiten ari denarekiko hurbiltasuna kontuan hartuta.
Bileran, taldeko buruak arkitektura eta negozio logikarako estrategia orokor bat garatzen du. Horren ostean, talde osoak eztabaidatzen du eta egokitzapenak egitea edo estrategia hau hartzea erabakitzen du.
Garatzaile bakoitzak kodea idazten du eta algoritmoak modu independentean eraikitzen ditu arkitektura eta negozio logika bakar baten esparruan. Bakoitzak bere ezarpenaren ikuspegia adieraz dezake, baina inork ez du inor behartzen horrela eta ez bestela egitera. Erabaki bakoitza justifikatuta dago. Irtenbide hoberik badago, baina oraingoz ez dago horretarako denborarik, orduan kodigoaren zati jakin baten etorkizuneko birfactorizaziorako zeregin bat sortzen da koipeetan.
Garatzaile batek zeregin bat hartzen duenean, garapen egoerara pasatzen du. Bezeroarekin zeregina argitzeko komunikazio guztiak garatzailearen sorbaldetan daude. Galdera teknikoak taldeburuari edo lankideei egin diezazkiekete.
Garatzaileak zereginaren funtsa ulertzen ez badu eta bezeroak ezin izan badu argi eta garbi azaldu, hurrengo zereginera igarotzen da. Eta taldeko arduradunak egungoa hartzen du eta bezeroarekin eztabaidatzen du.
Egunero, garatzaileak bezeroaren txatean idatzi beharko luke atzo zer zereginetan lan egin zuen eta zer lan egingo duen gaur.
Lan-prozesua Scrum-en arabera egiten da. Dena esprintetan banatuta dago. Sprint bakoitzak bi aste irauten du.
Sprintak sortu, bete eta ixten ditu taldeko buruak.
Proiektuak epe zorrotzak baditu, lan guztiak gutxi gorabehera estimatzen saiatzen gara. Eta esprint batean elkartu ditugu. Bezeroa esprintean zeregin gehiago gehitzen saiatzen bada, orduan lehentasunak ezartzen ditugu eta beste zeregin batzuk hurrengo esprintera transferituko ditugu.

b) Bezeroarekin lan egiteko prozesua

Garatzaile bakoitzak bezeroarekin komunikatu dezake eta behar du
Bezeroari ezin zaio onartu bere joko-arauak inposatzen. Beharrezkoa da bezeroari modu adeitsu eta atseginean argitzea gure alorreko espezialistak garela, eta guk bakarrik lan-prozesuak eraiki behar ditugu eta bezeroa horietan inplikatu behar dugu.
Beharrezkoa da, hoberena, edozein funtzionalitate inplementatzen hasi aurretik, funtziorako prozesu logiko osoaren fluxu-diagrama bat sortzea (lan-fluxua). Eta bidali bezeroari berresteko. Hau funtzionaltasun konplexu eta agerikoetan soilik aplikatzen da, adibidez, ordainketa-sistema, jakinarazpen-sistema, etab. Horri esker, zehatzago ulertuko dugu bezeroak zer behar duen zehazki, eginbiderako dokumentazioa gordetzeko eta, gainera, bezeroak etorkizunean eskatutakoa ez dugula egin esan dezakeenaren kontra ziurtatuko dugu.
Diagrama/fluxu-diagrama/logika eta abar guztiak. Confluence/Fat-en gordetzen dugu, non bezeroari iruzkinetan etorkizuneko ezarpenaren zuzentasuna berresteko eskatzen diogu.
Bezeroa xehetasun teknikoekin ez zamatzen saiatzen gara. Bezeroak nola nahi duen ulertu behar badugu, orduan algoritmo primitiboak marrazten ditugu, bezeroak berak ulertu eta dena zuzendu/alda dezakeen fluxu-diagrama moduan.
Bezeroak proiektuan akatsen bat aurkitzen badu, Fat-en xehetasun handiz deskribatzeko eskatzen dizugu. Zein egoeratan gertatu zen, noiz, zein ekintza-sekuentzia egin zituen bezeroak probak zehar. Mesedez, erantsi pantaila-argazkiak.
Egunero saiatzen gara, beste egun guztietan gehienez, garatzaileen zerbitzarian zabaltzen. Orduan, bezeroa funtzionaltasuna probatzen hasten da eta proiektua ez da geldirik geratzen. Aldi berean, bezeroarentzat proiektua garatzen ari dela eta inork ez diola maitagarrien ipuinak kontatzen duen marka da.
Sarritan gertatzen da bezeroak ez duela guztiz ulertzen zer behar duen. Beretzat negozio berri bat sortzen ari delako, oraindik finkatu gabeko prozesuekin. Horregatik, oso ohikoa da kode zati osoak zaborrontzira bota eta aplikazioaren logika birdiseinatzen dugunean. Hortik ondorioztatzen da ez duzula erabat estali behar probekin. Zentzuzkoa da funtzionaltasun kritikoa soilik probekin estaltzea, eta gero erreserbekin soilik.
Badago egoerak taldea konturatzen ez garela epeak betetzen ari ez garela. Ondoren, zereginen auditoria azkar bat egiten dugu eta berehala bezeroari horren berri ematen diogu. Egoeratik ateratzeko, funtzionalitate garrantzitsuak eta kritikoak garaiz abiarazi eta gainerakoak kaleratu osteko uztea proposatzen dugu.
Bezeroa bere burutik zeregin desberdinak burutzen hasten bada, hatzekin fantasiatzen eta azaltzen hasten bada, orduan eskatzen diogu orri-diseinua eskain diezagula eta diseinu osoaren jokabidea guztiz deskribatu beharko lukeen logika batekin. bere elementuak.
Edozein zeregin hartu aurretik, eginbide hori gure hitzarmen/kontratuaren baldintzetan sartuta zegoela ziurtatu behar dugu. Hau gure hasierako akordioetatik haratago doan ezaugarri berri bat bada, orduan eginbide hau tasatu beharko dugu ((aurreikusitako betetze-denbora + % 30 x 2) eta bezeroari adierazi beharko diogu denbora hori betetzeko, gehi epea zenbatespen-denborarekin bi bider desplazatzen da. Egin dezagun zeregina azkarrago - bikaina, denek izango dute onura. Hala ez bada, estalita daukagu.

c) Talde batean onartzen ez duguna:

Konpromisorik eza, lasaitasun falta, ahanztura
"Gosaltzen". Zeregin bat bete ezin baduzu eta nola ez dakizu, orduan taldearen buruari berehala jakinarazi behar diozu, eta ez azken unera arte itxaron.
Oraindik bere gaitasunak eta profesionaltasuna frogatu ez duen pertsona baten bekainak eta harroak. Frogatuta badago, posible da, dezentziaren mugen barruan :)
Iruzurra bere forma guztietan. Zeregin bat betetzen ez bada, ez zenuke bere egoera aldatu behar amaituta eta idatzi bezeroaren txatean prest dagoela. Ordenagailua matxuratu zen, sistema huts egin zuen, txakurrak ordenagailu eramangarria murtxikatu zuen - hori guztia onartezina da. Benetako ezinbesteko gertaera bat gertatzen bada, berehala jakinarazi beharko zaio taldeko buruari.
Espezialista bat denbora guztian lineaz kanpo dagoenean eta lanorduetan berarekin harremanetan jartzea zaila denean.
Taldean toxikotasuna ez da onartzen! Norbait zerbaitekin ados ez badago, denak elkarretaratzera biltzen dira eta eztabaidatu eta erabakitzen dute.

Eta batzuetan nire bezeroari gaizki-ulertu guztiak argitzeko egiten dizkiodan galdera/tesi batzuk:

Zeintzuk dira zure kalitate irizpideak?
Nola zehaztu proiektu batek arazoak dituen ala ez?
Sistema aldatzeko/hobetzeko gure gomendio eta aholku guztiak urratuz, arrisku guztiak zuk bakarrik hartzen dituzu.
Proiektuan egindako edozein aldaketa handiek (adibidez, era guztietako fluxu gehigarriak) akatsen agerpen posiblea ekarriko du (noski konponduko ditugu).
Ezinezkoa da minutu pare batean ulertzea zer-nolako arazoa gertatu den proiektuan, are gutxiago berehala konpontzea
Produktu-fluxu zehatz batean lan egiten dugu (Zhira-n Zereginak - Garapena - Probak - Zabaltzea). Horrek esan nahi du ezin diogula erantzun txatean eskaeren eta kexen fluxu osoari.
Programatzaileak programatzaileak dira, ez probatzaile profesionalak, eta ezin dute ziurtatu proiektuen proben kalitate egokia
Azken probaren eta produkzio-zereginen onarpenaren ardura zurea da erabat
Dagoeneko zeregin bat hartu badugu, ezin dugu berehala beste batzuetara aldatu oraingoa amaitu arte (bestela horrek are akats gehiago eta garapen-denbora handitzea dakar).
Jende gutxiago dago taldean (oporrak edo gaixotasunak direla eta), baina lan gehiago dago eta fisikoki ez dugu nahi duzun guztiari erantzuteko astirik izango
Garatzailean probatutako zereginik gabe ekoizpenean inplementatzea eskatzen dizugu - hau zure arriskua da soilik, ez garatzaileak.
Zeregin argigabeak ezartzen dituzunean, fluxu zuzenik gabe, diseinu-diseinurik gabe, horrek askoz esfortzu eta ezarpen-denbora handiagoa eskatzen digu, zure ordez lan gehiago egin behar baitugu.
Akatsei buruzko edozein zereginek, haien agerraldiaren eta pantaila-argazkien deskribapen zehatzik gabe, ez digu aukerarik ematen zer gertatu den eta akats hau nola konpondu dezakegun ulertzeko aukera.
Proiektuak etengabeko hobekuntza eta hobekuntza eskatzen ditu errendimendua eta segurtasuna hobetzeko. Hori dela eta, taldeak bere denboraren zati bat hobekuntza hauetan ematen du
Aparteko orduak orduka (premiazko konponketak) ditugunez, beste egun batzuetan konpentsatu behar ditugu

Oro har, bezeroak berehala ulertzen du softwarearen garapenean dena ez dela hain erraza, eta nahia bakarrik ez dela nahikoa.

Oro har, hori da dena. Negoziazio asko eta prozesu guztien hasierako arazketa atzean uzten ditut, baina, ondorioz, dena atera zen. Esan dezaket prozesu hau “Silver Bullet” moduko bat bihurtu zela guretzat. Proiektura etorritako jende berria lehen egunetik berehala parte har zitekeen lanean, prozesu guztiak deskribatu baitziren, eta eskema moduko dokumentazioa eta arkitekturak berehala eman zuten hemen denok egiten ari ginenaren ideia.

PS Argitu nahiko nuke ez dagoela gure alde proiektu-zuzendaririk. Bezeroaren alde dago. Ez da batere teknikaria. Europako proiektua. Komunikazio guztiak ingelesez soilik dira.

Zorte on guztioi zure proiektuetan. Ez erre eta saiatu zure prozesuak hobetzen.

Iturria nirean blog post.

Iturria: www.habr.com

Lan-fluxua taldean antolatzea IT proiektu batean