Hallo vriende. Heel dikwels, veral in uitkontraktering, sien ek dieselfde prentjie. Gebrek aan 'n duidelike werkvloei in spanne oor verskeie projekte.
Die belangrikste ding is dat programmeerders nie verstaan hoe om met die kliënt en met mekaar te kommunikeer nie. Hoe om 'n deurlopende proses te bou om 'n kwaliteit produk te ontwikkel. Hoe om jou werksdag en naellope te beplan.
En dit alles lei uiteindelik tot vermiste spertye, oortyd, konstante kragmetings oor wie die skuld kry, en klante se ontevredenheid met waar en hoe alles beweeg. Dikwels lei dit alles tot 'n verandering van programmeerders, of selfs hele spanne. Verlies van 'n kliënt, verswakking van reputasie, ensovoorts.
Op 'n tyd het ek net op so 'n projek beland, waar daar al hierdie lekkertes was.
Niemand wou verantwoordelikheid vir die projek ('n groot diensmarkplek) aanvaar nie, die omset was verskriklik, die kliënt was eenvoudig verskeur en gefrustreerd. Die CEO het eenkeer na my toe gekom en gesê dat jy die nodige ondervinding het, so hier is die kaarte in jou hande. Neem die projek vir jouself. As jy mis, sal ons die projek sluit en almal uitskop. Dit sal uitwerk, dit sal cool wees, lei dit dan en ontwikkel dit soos jy goeddink. Gevolglik het ek die spanleier vir die projek geword en alles het op my skouers geval.
Die eerste ding wat ek gedoen het, was om 'n werkvloei van nuuts af te ontwikkel wat in lyn was met my destydse visie, en 'n posbeskrywing vir die span geskryf. Die implementering daarvan was nie maklik nie. Maar binne 'n maand of wat het alles afgereken, die ontwikkelaars en die kliënt het daaraan gewoond geraak, en alles het rustig en gemaklik verloop. Om die span te wys dat dit nie net 'n "storm in 'n teekoppie" was nie, maar 'n regte uitweg uit die situasie, het ek die maksimum hoeveelheid verantwoordelikhede op my geneem en die onaangename roetine van die span verwyder.
’n Jaar en ’n half is reeds verby, en die projek ontwikkel sonder oortyd, sonder “rat races” en allerhande stres. Sommige mense in die ou span wou nie so werk nie en het weggegaan; ander, inteendeel, was baie bly dat deursigtige reëls verskyn het. Maar op die ou end is almal in die span baie gemotiveerd en ken hulle die groot projek ten volle, insluitend beide voor- en agterkant. Insluitend beide die kodebasis en alle besigheidslogika. Dit het selfs tot die punt gekom waar ons nie net "roeiers" is nie, maar ons self kom met baie besigheidsprosesse en nuwe kenmerke waarvan die besigheid blyk te hou.
Danksy hierdie benadering van ons kant het die kliënt besluit om 'n ander mark by ons maatskappy te bestel, wat goeie nuus is.
Aangesien dit op my projek werk, sal dit dalk ook iemand help. Dus, die proses self wat ons gehelp het om die projek te red:
Die proses van spanwerk op die projek "My gunsteling projek"
a) Interne spanproses (tussen ontwikkelaars)
- Alle kwessies word in die Jira-stelsel geskep
- Elke taak moet soveel as moontlik beskryf word en streng een aksie uitvoer
- Enige kenmerk, as dit kompleks genoeg is, word in baie klein take opgedeel
- Die span werk aan kenmerke as 'n enkele taak. Eerstens werk ons almal saam aan een kenmerk, stuur dit vir toetsing en neem dan die volgende een.
- Elke taak is gemerk, vir die backend of frontend dit
- Daar is soorte take en foute. Jy moet hulle korrek aandui.
- Nadat 'n taak voltooi is, word dit na kode-hersieningstatus oorgedra (in hierdie geval word 'n trekversoek vir 'n kollega geskep)
- Die persoon wat die taak voltooi het, volg onmiddellik sy tyd vir hierdie taak.
- Nadat die kode nagegaan is, sal die PR dit goedkeur en daarna voeg die een wat hierdie taak uitgevoer het dit onafhanklik in die hooftak saam, waarna hy sy status verander na gereed vir ontplooiing na die dev-bediener.
- Alle take wat gereed is vir ontplooiing na die dev-bediener word ontplooi deur die spanleier (sy area van verantwoordelikheid), soms deur 'n spanlid, as iets dringend is. Na ontplooiing word alle take van gereed vir ontplooiing na dev oorgedra na die status - gereed vir toetsing op dev
- Alle take word deur die kliënt getoets
- Wanneer die kliënt die taak op die dev getoets het, dra hy dit oor na die status gereed vir ontplooiing na produksie
- Vir ontplooiing na produksie het ons 'n aparte tak, waar ons die meester eers voor ontplooiing saamsmelt
- As die kliënt tydens die toets foute vind, stuur hy die taak terug vir hersiening, en stel sy status as teruggestuur vir hersiening. Op hierdie manier skei ons nuwe take van dié wat nie die toets geslaag het nie.
- Gevolglik gaan alle take van skepping tot voltooiing: Om te doen → In ontwikkeling → Kode-hersiening → Gereed ontplooi na dev → QA on dev → (Keer terug na dev) → Gereed ontplooi na prod → QA op prod → Klaar
- Elke ontwikkelaar toets sy kode onafhanklik, insluitend as 'n werfgebruiker. Dit word nie toegelaat om 'n tak in die hoof een saam te voeg nie, tensy dit vir seker bekend is dat die kode werk.
- Elke taak het prioriteite. Prioriteite word óf deur die kliënt óf die spanleier bepaal.
- Ontwikkelaars voltooi eerste prioriteitstake.
- Ontwikkelaars kan take aan mekaar toewys as verskillende foute in die stelsel gevind is of een taak bestaan uit die werk van verskeie spesialiste.
- Alle take wat die kliënt skep, gaan na die spanleier, wat dit evalueer en óf die kliënt vra om dit te verander óf dit aan een van die spanlede toewys.
- Alle take wat gereed is vir ontplooiing om te ontwikkel of aan te voer, gaan ook na die spanleier, wat onafhanklik bepaal wanneer en hoe om die ontplooiing uit te voer. Na elke ontplooiing moet die spanleier (of spanlid) die kliënt hieroor in kennis stel. En verander ook die statusse vir take na gereed vir toetsing vir dev/cont.
- Elke dag op dieselfde tyd (vir ons is dit om 12.00) hou ons 'n vergadering tussen alle spanlede
- Almal by die vergadering doen verslag, insluitend die spanleier, oor wat hulle gister gedoen het en wat hulle beplan om vandag te doen. Wat werk nie en hoekom. Op hierdie manier is die hele span bewus van wie wat doen en in watter stadium die projek is. Dit gee ons die geleentheid om ons ramings en spertye te voorspel en aan te pas, indien nodig.
- By die vergadering praat die spanleier ook oor al die veranderinge in die projek en die vlak van huidige foute wat nie deur die kliënt gevind is nie. Alle foute word uitgesorteer en aan elke spanlid toegewys om dit op te los.
- By die vergadering ken die spanleier take aan elke persoon toe, met inagneming van die huidige werklading van die ontwikkelaars, hul vlak van professionele opleiding, en ook met inagneming van die nabyheid van 'n bepaalde taak tot wat die ontwikkelaar tans doen.
- By die vergadering ontwikkel die spanleier 'n algemene strategie vir argitektuur en besigheidslogika. Waarna die hele span dit bespreek en besluit om aanpassings te maak of hierdie strategie te aanvaar.
- Elke ontwikkelaar skryf kode en bou algoritmes onafhanklik binne die raamwerk van 'n enkele argitektuur en besigheidslogika. Almal kan hul visie van implementering uitdruk, maar niemand dwing enigiemand om dit op hierdie manier te doen en nie anders nie. Elke besluit is geregverdig. As daar 'n beter oplossing is, maar daar is nie nou tyd daarvoor nie, dan word 'n taak in vet geskep vir die toekomstige herfaktorering van 'n sekere deel van die kode.
- Wanneer 'n ontwikkelaar 'n taak opneem, dra hy dit oor na ontwikkelingstatus. Alle kommunikasie met betrekking tot die opheldering van die taak met die kliënt val op die skouers van die ontwikkelaar. Tegniese vrae kan aan die spanleier of kollegas gevra word.
- As die ontwikkelaar nie die essensie van die taak verstaan nie, en die kliënt kon dit nie duidelik verduidelik nie, gaan hy voort na die volgende taak. En die spanleier neem die huidige een en bespreek dit met die kliënt.
- Elke dag moet die ontwikkelaar in die kliënt se klets skryf oor watter take hy gister gewerk het en aan watter take hy vandag gaan werk
- Die werksproses vind volgens Scrum plaas. Alles word in naellope verdeel. Elke naelloop duur twee weke.
- Naellope word geskep, gevul en gesluit deur die spanleier.
- As die projek streng sperdatums het, probeer ons om al die take ongeveer te skat. En ons het hulle saamgevoeg in 'n naelloop. As die kliënt probeer om meer take by die naelloop te voeg, dan stel ons prioriteite en dra 'n paar ander take oor na die volgende naelloop.
b) Proses van werk met die kliënt
- Elke ontwikkelaar kan en moet met die kliënt kommunikeer
- Die kliënt kan nie toegelaat word om sy eie spelreëls af te dwing nie. Dit is nodig om dit op 'n beleefde en vriendelike wyse aan die kliënt duidelik te maak dat ons spesialiste in ons veld is, en net ons moet werksprosesse bou en die kliënt daarby betrek.
- Dit is ideaal gesproke nodig om 'n vloeidiagram van die hele logiese proses vir die kenmerk (werkvloei) te skep voordat enige funksionaliteit begin implementeer word. En stuur dit aan die kliënt vir bevestiging. Dit geld slegs vir komplekse en nie ooglopende funksionaliteit nie, byvoorbeeld 'n betalingstelsel, kennisgewingstelsel, ens. Dit sal ons in staat stel om meer akkuraat te verstaan wat presies die kliënt benodig, dokumentasie vir die kenmerk te stoor, en ons ook te verseker teen die feit dat die kliënt in die toekoms kan sê dat ons nie gedoen het wat hy gevra het nie.
- Alle diagramme/vloeidiagramme/logika ens. Ons stoor dit in Confluence/Fat, waar ons die kliënt vra om die korrektheid van die toekomstige implementering in die kommentaar te bevestig.
- Ons probeer om nie die kliënt te belas met tegniese besonderhede nie. As ons 'n begrip nodig het van hoe die kliënt dit wil hê, dan teken ons primitiewe algoritmes in die vorm van 'n vloeidiagram wat die kliënt kan verstaan en alles self kan regstel/wysig.
- As die kliënt 'n fout in die projek vind, vra ons u om dit in Zhira breedvoerig te beskryf. Onder watter omstandighede het dit plaasgevind, wanneer, watter volgorde van aksies is deur die kliënt tydens toetsing uitgevoer. Heg asseblief skermkiekies aan.
- Ons probeer elke dag, hoogstens elke ander dag, om na die dev-bediener te ontplooi. Die kliënt begin dan om die funksionaliteit te toets en die projek staan nie ledig nie. Terselfdertyd is dit 'n merker vir die kliënt dat die projek in volle ontwikkeling is en niemand vir hom sprokies vertel nie.
- Dit gebeur dikwels dat die kliënt nie ten volle verstaan wat hy nodig het nie. Want hy skep vir homself ’n nuwe besigheid, met prosesse wat nog nie gevestig is nie. Daarom is 'n baie algemene situasie wanneer ons hele stukke kode in die asblik gooi en die toepassingslogika herontwerp. Hieruit volg dat jy nie absoluut alles met toetse moet dek nie. Dit maak sin om slegs kritieke funksionaliteit met toetse te dek, en dan slegs met voorbehoude.
- Daar is situasies wanneer die span besef dat ons nie spertye haal nie. Dan doen ons 'n vinnige oudit van die take en lig die kliënt dadelik daaroor in. As 'n uitweg uit die situasie, stel ons voor dat u belangrike en kritieke funksionaliteit betyds begin, en die res los vir na-vrystelling.
- As die kliënt met verskillende take uit sy kop begin vorendag kom, begin fantaseer en met sy vingers verduidelik, dan vra ons hom om vir ons 'n bladsyuitleg en vloei met logika te voorsien wat die gedrag van die hele uitleg volledig moet beskryf en sy elemente.
- Voordat ons enige taak aanpak, moet ons seker maak dat hierdie kenmerk by die bepalings van ons ooreenkoms/kontrak ingesluit is. As dit 'n nuwe kenmerk is wat verder gaan as ons aanvanklike ooreenkomste, moet ons hierdie kenmerk prys ((geskatte voltooiingstyd + 30%) x 2) en aan die kliënt aandui dat dit ons soveel tyd sal neem om dit te voltooi, plus die sperdatum word verskuif met die skattingstyd vermenigvuldig met twee. Kom ons doen die taak vinniger – wonderlik, almal sal daarby baat. Indien nie, dan het ons jou gedek.
c) Wat ons nie in 'n span aanvaar nie:
- Ontoewyding, gebrek aan kalmte, vergeetagtigheid
- “Voed ontbyt.” As jy nie 'n taak kan voltooi nie en nie weet hoe nie, moet jy die spanhoof dadelik daaroor in kennis stel, en nie wag tot die laaste minuut nie.
- Blaai en spog met 'n persoon wat nog nie sy vermoëns en professionaliteit bewys het nie. As dit bewys is, dan is dit moontlik, binne die grense van ordentlikheid :)
- Misleiding in al sy vorme. As 'n taak nie voltooi is nie, moet jy nie sy status na voltooi verander en in die kliëntklets skryf dat dit gereed is nie. Die rekenaar het gebreek, die stelsel het neergestort, die hond het aan die skootrekenaar gekou – dit alles is onaanvaarbaar. Indien 'n werklike force majeure-gebeurtenis plaasvind, moet die spanleier onmiddellik in kennis gestel word.
- Wanneer 'n spesialis heeltyd vanlyn is en dit moeilik is om hom gedurende werksure te bereik.
- Toksisiteit in die span word nie toegelaat nie! As iemand nie saamstem met iets nie, dan kom almal bymekaar vir 'n saamtrek en bespreek en besluit daaroor.
En 'n aantal vrae/tesisse wat ek soms aan my kliënt vra om alle misverstande uit die weg te ruim:
- Wat is jou kwaliteitskriteria?
- Hoe bepaal jy of 'n projek probleme het of nie?
- Deur al ons aanbevelings en advies oor die verandering/verbetering van die stelsel te oortree, word alle risiko's slegs deur jou gedra
- Enige groot veranderinge aan die projek (byvoorbeeld, allerhande ekstra vloei) sal lei tot die moontlike voorkoms van foute (wat ons natuurlik sal regmaak)
- Dit is onmoontlik om binne 'n paar minute te verstaan watter soort probleem op die projek voorgekom het, nog minder om dit dadelik reg te stel
- Ons werk aan 'n spesifieke produkvloei (Take in Zhira - Ontwikkeling - Toets - Ontplooi). Dit beteken dat ons nie op die hele vloei van versoeke en klagtes in die klets kan reageer nie.
- Programmeerders is programmeerders, nie professionele toetsers nie, en kan nie die behoorlike gehalte van projektoetsing verseker nie
- Verantwoordelikheid vir finale toetsing en aanvaarding van produksietake lê geheel en al by jou
- As ons reeds 'n taak aangeneem het, kan ons nie onmiddellik na ander oorskakel totdat ons die huidige een voltooi het nie (anders lei dit tot nog meer foute en verhoogde ontwikkelingstyd)
- Daar is minder mense in die span (weens vakansies of siektes), maar daar is meer werk en ons sal fisies nie tyd hê om te reageer op alles wat jy wil hê nie
- Ons vra u om 'n ontplooiing na produksie te maak sonder getoetste take op die ontwikkelaar - dit is slegs u risiko, nie die ontwikkelaars nie
- Wanneer u onduidelike take stel, sonder 'n korrekte vloei, sonder ontwerpuitlegte, verg dit baie meer moeite en implementeringstyd van ons, aangesien ons 'n bykomende hoeveelheid werk in plaas van u moet doen
- Enige take op foute, sonder 'n gedetailleerde beskrywing van hul voorkoms en skermkiekies, gee ons nie die geleentheid om te verstaan wat verkeerd geloop het en hoe ons hierdie fout kan regmaak nie
- Die projek vereis konstante verfyning en verbeterings om prestasie en veiligheid te verbeter. Daarom bestee die span 'n deel van sy tyd aan hierdie verbeterings
- Weens die feit dat ons oortyd per uur het (dringende regstellings), moet ons op ander dae daarvoor vergoed
As 'n reël verstaan die kliënt dadelik dat alles nie so eenvoudig is in sagteware-ontwikkeling nie, en begeerte alleen is duidelik nie genoeg nie.
Oor die algemeen is dit al. Ek laat baie onderhandelinge en die aanvanklike ontfouting van alle prosesse agter die skerms, maar gevolglik het alles uitgewerk. Ek kan sê dat hierdie proses vir ons 'n soort "Silver Bullet" geword het. Nuwe mense wat na die projek gekom het, kon dadelik vanaf die eerste dag by die werk betrokke raak, aangesien al die prosesse beskryf is, en die dokumentasie en argitektuur in die vorm van diagramme het dadelik 'n idee gegee van wat ons almal hier doen.
NS Ek wil graag duidelik maak dat daar geen projekbestuurder aan ons kant is nie. Dit is aan die kliënt se kant. Glad nie 'n tegniek nie. Europese projek. Alle kommunikasie is slegs in Engels.
Sterkte aan almal met julle projekte. Moenie uitbrand nie en probeer om jou prosesse te verbeter.
Bron in myne .
Bron: will.com