Hallo freonen. Hiel faak, benammen by útbesteging, sjoch ik itselde byld. Gebrek oan in dúdlike workflow yn teams op ferskate projekten.
It wichtichste is dat programmeurs net begripe hoe't se kinne kommunisearje mei de klant en mei elkoar. Hoe kinne jo in trochgeand proses bouwe foar it ûntwikkeljen fan in kwaliteitsprodukt. Hoe kinne jo jo wurkdei en sprints planne.
En dit alles resultearret úteinlik yn miste deadlines, oerwurk, konstante showdowns oer wa't de skuld hat, en ûntefredenens fan klanten oer wêr't en hoe't alles beweecht. Hiel faak, dit alles liedt ta in feroaring fan programmeurs, of sels hiele teams. Ferlies fan in klant, efterútgong fan reputaasje, ensfh.
Op in kear kaam ik krekt op sa'n projekt telâne, wêr't al dy lekkernijen wiene.
Nimmen woe ferantwurdlikens nimme foar it projekt (in grutte tsjinstmerkplak), de omset wie ferskriklik, de klant wie gewoan skuord en frustrearre. De CEO kaam ris nei my ta en sei dat jo de nedige ûnderfining hawwe, dus hjir binne de kaarten yn jo hannen. Nim it projekt foar josels. As jo skroefje, sille wy it projekt slute en elkenien útsmite. It sil wurkje, it sil cool wêze, dan liede it en ûntwikkelje it as jo goed fine. Dêrtroch waard ik de teamlieder foar it projekt en foel alles op myn skouders.
It earste wat ik die wie in workflow fanôf it begjin te ûntwikkeljen dy't ôfstimd wie mei myn fyzje op dat stuit, en skreau in taakbeskriuwing foar it team. It útfieren wie net maklik. Mar binnen in moanne as wat kaam alles fêst, de ûntwikkelders en de klant wiene der oan wend, en alles gie rêstich en noflik. Om it team sjen te litten dat dit net allinich in "stoarm yn in teacup" wie, mar in echte útwei út 'e situaasje, naam ik it maksimale bedrach fan ferantwurdlikheden op, ferwiderje de onaangename routine fan it team.
In jier en in heal is al foarby, en it projekt ûntwikkelet sûnder oerwurk, sûnder "rat races" en alle soarten fan stress. Guon minsken yn it âlde team woene net sa wurkje en gongen fuort, oaren wiene krekt tefreden dat der transparante regels ferskynden. Mar op it lêst is elkenien yn it team tige motivearre en ken it enoarme projekt folslein, ynklusyf sawol front-end as back-end. Ynklusyf sawol de koadebasis as alle saaklike logika. It hat sels krigen op it punt dêr't wy binne net allinnich "roeiers", mar wy sels komme mei in protte saaklike prosessen en nije funksjes dy't it bedriuw blykt te leuk.
Mei tank oan dizze oanpak fan ús kant besleat de klant in oare merk te bestellen fan ús bedriuw, wat goed nijs is.
Sûnt dit wurket op myn projekt, miskien sil it ek helpe immen. Dat, it proses sels dat ús holp it projekt te rêden:
It proses fan teamwurk oan it projekt "Myn favorite projekt"
a) Ynterne teamproses (tusken ûntwikkelders)
- Alle problemen wurde makke yn it Jira-systeem
- Elke taak moat safolle mooglik beskreaun wurde en strikt ien aksje útfiere
- Elke funksje, as it kompleks genôch is, wurdt opdield yn in protte lytse taken
- It team wurket oan funksjes as ien taak. Earst wurkje wy allegear gear oan ien funksje, stjoer it foar testen, nim dan de folgjende.
- Elke taak is markearre, foar de backend of frontend it
- D'r binne soarten taken en bugs. Jo moatte se goed oanjaan.
- Nei it foltôgjen fan in taak wurdt it oerdroegen oan koadebeoardielingsstatus (yn dit gefal wurdt in pull-fersyk makke foar in kollega)
- De persoan dy't de taak foltôge, folget fuortendaliks syn tiid foar dizze taak.
- Nei it kontrolearjen fan 'e koade sil de PR goedkarre en dêrnei, dejinge dy't dizze taak selsstannich útfierde fuseart it yn 'e mastertûke, wêrnei't hy syn status feroaret nei klear foar ynset nei de dev-tsjinner.
- Alle taken klear foar ynset nei de dev-tsjinner wurde ynset troch de teamleader (syn ferantwurdlikensgebiet), soms troch in teamlid, as wat driuwend is. Nei ynset wurde alle taken fan klear foar ynset oant dev oerbrocht nei de status - klear foar testen op dev
- Alle taken wurde hifke troch de klant
- As de klant de taak op 'e dev hat hifke, draacht hy it oer nei de status klear foar ynset nei produksje
- Foar ynset nei produksje hawwe wy in aparte tûke, wêr't wy de master allinich foar ynset fusearje
- As de klant by it testen bugs fynt, jout hy de taak werom foar revyzje, en stelt de status yn as weromjûn foar revyzje. Op dizze manier skiede wy nije taken fan dyjingen dy't de test net hawwe trochjûn.
- As resultaat geane alle taken fan skepping oant foltôging: Te dwaan → Yn ûntwikkeling → Koadebeoardieling → Klear ynset nei dev → QA op dev → (Werom nei dev) → Klear ynset nei prod → QA op prod → Klaar
- Elke ûntwikkelder testet syn koade selsstannich, ynklusyf as side-brûker. It is net tastien om in tûke te fusearjen yn 'e wichtichste, útsein as it wis is dat de koade wurket.
- Elke taak hat prioriteiten. Prioriteiten wurde ynsteld troch de klant of de teamlieder.
- Ûntwikkelers foltôgje prioriteit taken earst.
- Untwikkelders kinne taken oan elkoar tawize as ferskate bugs yn it systeem fûn binne of ien taak bestiet út it wurk fan ferskate spesjalisten.
- Alle taken dy't de klant oanmakket geane nei de teamleader, dy't se evaluearret en of de klant freget om se te feroarjen of tawize se oan ien fan 'e teamleden.
- Alle taken dy't klear binne foar ynset foar dev of prod, geane ek nei de teamlieding, dy't selsstannich bepaalt wannear en hoe't de ynset útfierd wurdt. Nei elke ynset moat de teamlieder (of teamlid) de klant hjiroer ynformearje. En feroarje ek de statusen foar taken om klear te wêzen foar testen foar dev / kont.
- Alle dagen tagelyk (foar ús is it om 12.00 oere) hâlde wy in gearkomste tusken alle teamleden
- Elkenien op de gearkomste docht ferslach, ek de teamlieder, oer wat se juster dien hawwe en wat se hjoed fan plan binne te dwaan. Wat wurket net en wêrom. Op dizze manier is it heule team bewust fan wa't wat docht en yn hokker stadium it projekt is. Dit jout ús de kâns om ús skattings en deadlines, as it nedich is, te foarsizzen en oan te passen.
- Op 'e gearkomste sprekt de teamlieder ek oer alle wizigingen yn it projekt en it nivo fan aktuele bugs dy't net waarden fûn troch de klant. Alle bugs wurde sorteare en tawiisd oan elk teamlid om se op te lossen.
- Op 'e gearkomste jout de teamlieder taken oan elke persoan, rekken hâldend mei de hjoeddeistige wurkdruk fan' e ûntwikkelders, har nivo fan profesjonele training, en ek rekken hâldend mei de buert fan in bepaalde taak oan wat de ûntwikkelder op it stuit docht.
- By de gearkomste ûntwikkelet de teamlieder in algemiene strategy foar arsjitektuer en saaklike logika. Dêrnei besprekt it hiele team dit en beslút om oanpassingen te meitsjen of dizze strategy oan te nimmen.
- Elke ûntwikkelder skriuwt koade en bout selsstannich algoritmen binnen it ramt fan ien arsjitektuer en saaklike logika. Elkenien kin har fisy op ymplemintaasje uterje, mar gjinien twingt immen dit te dwaan en net oars. Elk beslút is terjochte. As der in bettere oplossing is, mar der is no gjin tiid foar, dan wurdt in taak yn fet makke foar de takomstige refactoring fan in bepaald diel fan 'e koade.
- As in ûntwikkelder in taak opnimt, draacht hy it oer nei ûntwikkelingsstatus. Alle kommunikaasje oangeande opheldering fan 'e taak mei de klant falt op' e skouders fan 'e ûntwikkelder. Technyske fragen kinne steld wurde oan de teamlieder of kollega's.
- As de ûntwikkelder de essinsje fan 'e taak net begrypt, en de klant koe it net dúdlik ferklearje, dan giet hy troch nei de folgjende taak. En de teamlieder nimt de hjoeddeiske en besprekt it mei de klant.
- Elke dei moat de ûntwikkelder yn it petear fan 'e klant skriuwe oer hokker taken hy juster wurke en hokker taken hy hjoed sil wurkje
- It wurkproses fynt plak neffens Scrum. Alles is ferdield yn sprints. Elke sprint duorret twa wiken.
- Sprints wurde makke, ynfold en ôfsletten troch de teamlieder.
- As it projekt strikte deadlines hat, besykje wy alle taken sawat te skatten. En wy sette se byinoar yn in sprint. As de klant besiket mear taken ta te foegjen oan de sprint, dan stelle wy prioriteiten en ferpleatse guon oare taken nei de folgjende sprint.
b) Proses fan wurkjen mei de klant
- Elke ûntwikkelder kin en moat kommunisearje mei de klant
- De klant kin net tastien te oplizze syn eigen regels fan it spul. It is needsaaklik om de klant op in beleefde en freonlike manier dúdlik te meitsjen dat wy spesjalisten binne op ús fjild, en allinich moatte wy wurkprosessen bouwe en de klant dêrby belûke
- It is needsaaklik, ideaal, foardat jo begjinne mei it útfieren fan elke funksjonaliteit, om in streamdiagram te meitsjen fan it heule logyske proses foar de funksje (workflow). En stjoer it nei de klant foar befêstiging. Dat jildt allinnich foar komplekse en net foar de hân lizzende funksjonaliteit, Bygelyks, in betelling systeem, notifikaasje systeem, etc. Hjirmei kinne wy krekter begripe wat krekt de klant nedich is, dokumintaasje foar de funksje bewarje, en ús ek fersekerje tsjin it feit dat de klant yn 'e takomst kin sizze dat wy net dien hawwe wat hy frege.
- Alle diagrammen/flowcharts/logika ensfh. Wy bewarje it yn Confluence / Fat, wêr't wy de klant freegje om de korrektheid fan 'e takomstige ymplemintaasje te befêstigjen yn' e kommentaren.
- Wy besykje de klant net te belêsten mei technyske details. As wy in begryp nedich hawwe fan hoe't de klant it wol, dan tekenje wy primitive algoritmen yn 'e foarm fan in flowchart dat de klant alles sels ferstean en korrizjearje / wizigje kin.
- As de klant in brek fynt yn it projekt, dan freegje wy jo om it yn Zhira yn detail te beskriuwen. Under hokker omstannichheden barde it, wannear, hokker folchoarder fan aksjes waard útfierd troch de klant by testen. Heakje asjebleaft skermôfbyldings ta.
- Wy besykje elke dei, op syn heechst elke oare dei, yn te setten nei de dev-tsjinner. De klant begjint dan de funksjonaliteit te testen en it projekt stiet net stil. Tagelyk is dit in marker foar de klant dat it projekt yn folsleine ûntwikkeling is en gjinien fertelt him mearkes.
- It komt faak foar dat de klant net folslein begrypt wat er nedich is. Want hy makket foar himsels in nij bedriuw, mei prosessen dy't noch net fêstlein binne. Dêrom is in heul foarkommende situaasje as wy hiele stikken koade yn it jiskefet smite en de applikaasjelogika opnij ûntwerpe. Dêrút folget dat jo net hielendal alles mei tests moatte dekke. It makket sin om allinich krityske funksjonaliteit te dekken mei testen, en dan allinich mei reservearrings.
- D'r binne situaasjes as it team beseft dat wy de deadlines net foldwaan. Dan fiere wy in flugge kontrôle fan de taken en ynformearje de klant der daliks oer. As útwei út 'e situaasje stelle wy foar om wichtige en krityske funksjonaliteit op 'e tiid te lansearjen en de rest oer te litten foar post-release.
- As de klant begjint te kommen mei ferskate taken út syn holle, begjint te fantasearjen en ferklearje mei syn fingers, dan freegje wy him te foarsjen ús mei in side opmaak en stream mei logika dy't moat folslein beskriuwe it gedrach fan de hiele opmaak en syn eleminten.
- Foardat wy in taak nimme, moatte wy derfoar soargje dat dizze funksje opnommen is yn 'e betingsten fan ús oerienkomst / kontrakt. As dit in nije funksje is dy't boppe ús earste ôfspraken giet, dan moatte wy dizze funksje priisje ((skatte foltôgingstiid + 30%) x 2) en oanjaan oan de klant dat it ús sa folle tiid sil nimme om it te foltôgjen, plus de deadline wurdt ferskood troch de skatting tiid fermannichfâldige mei twa. Litte wy de taak rapper dwaan - geweldich, elkenien sil der fan profitearje. Sa net, dan hawwe wy jo behannele.
c) Wat wy net akseptearje yn in team:
- Uncommitment, gebrek oan kalmens, ferjitten
- “Brochje iten.” As jo in taak net kinne foltôgje en net witte hoe, dan moatte jo de teamlieder der fuortendaliks oer ynformearje, en net wachtsje oant de lêste minút.
- Brows and boasts fan in persoan dy't syn kapasiteiten en profesjonaliteit noch net hat bewiisd. As it bewiisd is, dan is it mooglik, binnen de grinzen fan fatsoen :)
- Bedrog yn al syn foarmen. As in taak net foltôge is, dan moatte jo de status net feroarje nei foltôge en skriuwe yn 'e klantpetear dat it klear is. De kompjûter brutsen, it systeem crashte, de hûn kauwde op 'e laptop - dit alles is net akseptabel. As der in echte oermacht barren foarkomt, moat de teamlieder fuortendaliks op 'e hichte brocht wurde.
- As in spesjalist de hiele tiid offline is en it dreech is om him te berikken tidens wurktiden.
- Toxiciteit yn it team is net tastien! As immen it ergens net mei iens is, dan komt elkenien byinoar foar in rally en besprekt en beslút dêroer.
En in oantal fragen/proefskriften dy't ik myn klant soms freegje om alle misferstannen op te heljen:
- Wat binne jo kwaliteitskritearia?
- Hoe kinne jo bepale oft in projekt problemen hat of net?
- Troch al ús oanbefellings en advys oer it feroarjen / ferbetterjen fan it systeem te brekken, wurde alle risiko's allinich troch jo droegen
- Alle grutte wizigingen oan it projekt (bygelyks alle soarten ekstra stream) sille liede ta it mooglike ferskinen fan bugs (dy't wy fansels sille reparearje)
- It is ûnmooglik om binnen in pear minuten te begripen wat foar probleem barde op it projekt, folle minder reparearje it fuortendaliks
- Wy wurkje oan in spesifike produktstream (Taken yn Zhira - Untwikkeling - Testen - Deploy). Dit betsjut dat wy net kinne reagearje op de hiele stream fan oanfragen en klachten yn it petear.
- Programmeurs binne programmeurs, gjin profesjonele testers, en kinne net soargje foar de goede kwaliteit fan projekttesten
- Ferantwurdlikens foar definitive testen en akseptearjen fan produksjetaken leit folslein by jo
- As wy al in taak oannommen hawwe, kinne wy net daliks oerskeakelje nei oaren oant wy de hjoeddeistige foltôgje (oars liedt dit ta noch mear bugs en ferhege ûntwikkelingstiid)
- D'r binne minder minsken yn it team (troch fakânsjes of sykten), mar der is mear wurk en wy hawwe fysyk gjin tiid om te reagearjen op alles wat jo wolle
- Wy freegje jo om in ynset te meitsjen foar produksje sûnder teste taken op 'e dev - dit is allinich jo risiko, net de ûntwikkelders
- As jo ûndúdlike taken ynstelle, sûnder in juste trochstreaming, sûnder ûntwerpopmaak, freget dit folle mear ynspanning en ymplemintaasjetiid fan ús, om't wy in ekstra hoemannichte wurk moatte dwaan yn plak fan jo
- Elke taken op bugs, sûnder in detaillearre beskriuwing fan har foarkommen en skermôfbyldings, jouwe ús net de kâns om te begripen wat mis gie en hoe't wy dizze brek kinne reparearje
- It projekt fereasket konstante ferfining en ferbetteringen om prestaasjes en feiligens te ferbetterjen. Dêrom besteget it team in diel fan syn tiid oan dizze ferbetteringen
- Fanwege it feit dat wy oeren per oere hawwe (driuwende reparaasjes), moatte wy dizze op oare dagen kompensearje
As regel begrypt de klant fuortendaliks dat alles net sa ienfâldich is yn softwareûntwikkeling, en winsk allinich is dúdlik net genôch.
Yn it algemien, dat is alles. Ik lit efter de skermen in protte ûnderhannelings en de earste debuggen fan alle prosessen, mar as gefolch, alles slagge. Ik kin sizze dat dit proses foar ús in soarte fan "Silver Bullet" waard. Nije minsken dy't nei it projekt kamen, koenen fuortendaliks belutsen wurde by it wurk fan 'e earste dei, om't alle prosessen waarden beskreaun, en de dokumintaasje en arsjitektuer yn' e foarm fan diagrammen joegen fuortendaliks in idee fan wat wy hjir allegear diene.
PS Ik soe graach dúdlik meitsje dat der gjin projektmanager oan ús kant is. It is oan 'e kant fan' e klant. Gjin technyk hielendal. Europeesk projekt. Alle kommunikaasje is allinich yn it Ingelsk.
Sterkte foar elkenien op jo projekten. Brand net út en besykje jo prosessen te ferbetterjen.
Boarne yn myn .
Boarne: www.habr.com