Hej venner. Hyppigt, isÊr i outsourcing, ser jeg det samme billede. Manglen pÄ en klar arbejdsproces i teams pÄ forskellige projekter.
Det vigtigste er, at programmÞrer ikke forstÄr, hvordan man skal kommunikere med kunden og hinanden. Hvordan man opbygger en kontinuerlig proces til udvikling af et kvalitetsprodukt. Hvordan man planlÊgger sin arbejdsdag og sine sprints.
Og alt dette fÞrer i sidste ende til forsinkede deadlines, overarbejde, konstante diskussioner om, hvem der er skyld i det, og utilfredshed blandt kunderne - hvor og hvordan alt bevÊger sig. Ofte fÞrer dette til udskiftning af programmÞrer, eller endda hele teams. Tab af kunder, dÄrligere omdÞmme osv.
Engang kom jeg netop ind i et sÄdant projekt, hvor alle disse problemer var til stede.
Ingen Þnskede at tage ansvar for projektet (en stor service-markedsplads), fluktuationen var frygtelig, og kunden var bare frustreret. CEO'en kom hen til mig og sagde, at du har den nÞdvendige erfaring, sÄ her er kortene i hÄnden. Tag projektet til dig. Hvis du fejler, lukker vi projektet, og alle bliver fyret. Hvis du fÄr det til at lykkes, vil det vÊre fantastisk, sÄ fÞr det og udvikl det, som du mener er nÞdvendigt. I sidste ende blev jeg teamleder for projektet, og alt kom til at ligge pÄ mine skuldre.
Det fÞrste, jeg gjorde, var at udvikle en arbejdsproces fra bunden, som dengang svarede til min vision, og jeg skrev en stillingsbeskrivelse til teamet. Det var ikke let at implementere. Men efter cirka en mÄned var alt faldet pÄ plads, udviklerne og kunden var blevet vant til det, og alt gik nu stille og behageligt. For at vise teamet, at dette ikke blot var 'stormen i et glas vand', men en reel lÞsning pÄ situationen, tog jeg sÄ mange opgaver pÄ mine skuldre som muligt og befriede teamet fra den ubehagelige rutine.
Der er allerede gÄet halvandet Är, og projektet udvikler sig uden overarbejde, uden 'rotterace' og diverse stress. Nogle i det gamle team Þnskede ikke at arbejde pÄ den mÄde og forlod, mens andre derimod meget satte pris pÄ de klare regler. Men i sidste ende er alle i teamet meget motiverede og kender det store projekt fuldstÊndigt, bÄde frontend og backend. Inklusive kodebasen og hele forretningslogikken. Det er endda kommet til det punkt, at vi ikke bare er 'roere', men selv finder pÄ mange forretningsprocesser og nye funktioner, som virksomheden satte stor pris pÄ.
Med denne tilgang fra vores side har kunden besluttet at bestille endnu en marketplace fra vores virksomhed, hvilket vi naturligvis er glade for.
Da det virker pÄ mit projekt, kan det mÄske ogsÄ hjÊlpe andre. SÄ her er processen, der hjalp os med at redde projektet:
Teamets arbejdsgang pĂ„ projektet âMit yndlingsprojektâ
a) Intern teamproces (mellem udviklerne)
- Alle opgaver oprettes i Jira-systemet
- Hver opgave skal vÊre sÄ detaljeret som muligt og udfÞre en specifik handling.
- Enhver funktion, hvis den er tilstrÊkkeligt kompleks, opdeles i mange smÄ opgaver.
- Teamet arbejder pÄ funktionerne som en enkelt opgave. FÞrst laver vi sammen én funktion, sender den til test, og derefter tager vi den nÊste.
- Hver opgave mĂŠrkes som backend eller frontend.
- Der er typer af opgaver og bugs. Det er vigtigt at angive dem korrekt.
- Efter opgaven er udfĂžrt, ĂŠndres dens status til kodeanmeldelse (og der oprettes en pull-request til en kollega).
- Den, der udfÞrte opgaven, holder straks styr pÄ sin tid for denne opgave.
- Efter kodegennemgang godkendes PR, og derefter fusionerer den, der udfÞrte opgaven, den selv til master-grenen, hvorefter de Êndrer dens status til klar til deployment pÄ dev. server.
- Alle opgaver, der er klar til deployment pÄ dev-serveren, deployes af teamlederen (hans ansvar). Nogle gange af et teammedlem, hvis der er noget presserende. Efter deployment Êndres alle opgaver fra klar til deployment pÄ dev til status - klar til test pÄ dev.
- Alle opgaver testes af kunden.
- NÄr kunden har testet opgaven pÄ dev, Êndrer han dens status til klar til deployment pÄ prod.
- Til deployment pÄ prod har vi en separat gren, hvor vi kun fusionerer master fÞr deployment.
- Hvis kunden finder bugs under testen, returnerer han opgaven til revision og sÊtter dens status til returneret til revidering. PÄ den mÄde adskiller vi nye opgaver fra dem, der ikke bestod testen.
- I sidste ende gennemgĂ„r alle opgaver rejsen fra oprettelse til afslutning: To Do â In Development â Code Review â Ready deploy to dev â QA on dev â (Return to dev) â Ready deploy to prod â QA on prod â Done.
- Hver udvikler tester selv sin kode, ogsÄ som en bruger af hjemmesiden. Fusion af grenen til hovedgrenen er ikke tilladt, medmindre det er helt sikkert, at koden virker.
- Hver opgave har sine prioriteter. Prioriteterne fastsĂŠttes enten af kunden eller teamlederen.
- Udviklerne prioriterer fĂžrst de opgaver, der er mest presserende.
- Udviklerne kan tildele opgaver til hinanden, hvis der er fundet forskellige fejl i systemet, eller hvis en opgave krĂŠver arbejdet fra flere specialister.
- Alle opgaver, som kunden opretter, gÄr til teamlederen, der vurderer dem og enten beder kunden om at revidere eller tildeler dem til et af teammedlemmerne.
- Alle opgaver, der er klar til deployment pÄ dev eller prod, gÄr ogsÄ til teamlederen, som selv bestemmer, hvornÄr og hvordan deployment skal udfÞres. Efter hver deployment skal teamlederen (eller et teammedlem) informere kunden om dette. Og Êndre statussen for opgaverne til klar til test pÄ dev/prod.
- Hver dag pÄ samme tidspunkt (hos os er det kl. 12.00) afholder vi et mÞde mellem alle teammedlemmer.
- Hver person pÄ mÞdet rapporterer, inklusiv teamlederen, hvad de har lavet i gÄr, hvad de planlÊgger at gÞre i dag, hvad der ikke fungerer, og hvorfor. PÄ den mÄde er hele teamet klar over, hvem der laver hvad, og pÄ hvilket trin projektet befinder sig. Dette giver os mulighed for at prognosere og justere vores estimater og deadlines, hvis det er nÞdvendigt.
- PÄ mÞdet informerer teamlederen ogsÄ om alle Êndringer i projektet og om niveauet af aktuelle fejl, der ikke er blevet fundet af kunden. Alle fejl bliver gennemgÄet og tildelt hvert teammedlem til lÞsning.
- PĂ„ mĂždet tildeler teamlederen opgaver til hver enkelt, under hensyntagen til den nuvĂŠrende arbejdsbelastning for udviklerne, deres fĂŠrdigheder og i hvilken grad en bestemt opgave relaterer til det, udvikleren arbejder med i Ăžjeblikket.
- PĂ„ mĂždet udvikler teamlederen en samlet strategi for arkitektur og forretningslogik. Derefter diskuterer hele teamet det og trĂŠffer beslutning om eventuelle justeringer eller godkendelse af strategien.
- Hver udvikler skriver kode og bygger algoritmer selvstÊndigt inden for en fÊlles arkitektur og forretningslogik. Hver enkelt kan udtrykke sin vision for implementeringen, men ingen tvinges til kun at gÞre det pÄ en bestemt mÄde. Hver beslutning er argumenteret. Hvis der findes en bedre lÞsning, men der ikke er tid til det lige nu, oprettes der en opgave i JIRA til fremtidig refaktorering af en bestemt del af koden.
- NÄr udvikleren har taget en opgave til behandling, Êndrer han dens status til udvikling. Al kommunikation om afklaring af opgaven hos kunden ligger pÄ udviklerens skuldre. Tekniske spÞrgsmÄl kan stilles til teamlederen eller kollegerne.
- Hvis udvikleren ikke forstÄr opgavens essens, og kunden ikke har vÊret i stand til at forklare den tilstrÊkkeligt, sÄ gÄr han videre til den nÊste opgave. Den nuvÊrende opgave overtager teamlederen og diskuterer den selv med kunden.
- Hver dag skal udvikleren i kundens chat skrive om, hvilke opgaver han arbejdede pÄ i gÄr, og hvilke opgaver han vil arbejde pÄ i dag.
- Arbejdsgangen foregÄr efter Scrum. Alt er opdelt i sprints. Hver sprint varer to uger.
- Sprints opretter, fylder og afslutter teamlederen.
- Hvis projektet har stramme deadlines, forsÞger vi at estimere alle opgaver. Og vi samler dem til en sprint. Hvis kunden forsÞger at tilfÞje yderligere opgaver til sprinten, sÄ prioriterer vi og flytter nogle andre opgaver til den nÊste sprint.
b) Arbejdsprocessen med kunden
- Hver udvikler kan og bĂžr kommunikere med kunden.
- Man mÄ ikke lade kunden pÄtvinge sine egne spilleregler. Det er nÞdvendigt at pÄ en hÞflig og venlig mÄde gÞre kunden klart, at vi er specialister i vores felt, og det er kun os, der skal opbygge arbejdsprocesserne og involvere kunden i dem.
- Ideelt set, inden man pÄbegynder implementeringen af en funktionalitet, bÞr man lave et flowdiagram for hele den logiske proces for funktionen (workflow). Og sende det til kunden for godkendelse. Dette gÊlder kun for kompleks og ikke-indlysende funktionalitet, f.eks. betalingssystemer, notifkationssystemer osv. Dette vil gÞre det muligt at forstÄ mere prÊcist, hvad kunden har brug for, bevare dokumentationen for funktionen samt beskytte sig selv mod, at kunden i fremtiden siger, at vi har gjort noget andet end det, han bad om.
- Vi gemmer alle diagrammer/flowcharts/logik osv. i Confluence/Jira, hvor vi beder kunden bekrĂŠfte korrektheden af den fremtidige implementering i kommentarerne.
- Vi forsÞger ikke at overbelaste kunden med tekniske detaljer. Hvis vi har brug for at forstÄ, hvordan kunden Þnsker det, tegner vi primÊre algoritmer i form af flowcharts, som kunden kan forstÄ og selv rette/tilpasse.
- Hvis kunden finder en fejl i projektet, beder vi dem om at beskrive den meget detaljeret i Jira. Under hvilke omstÊndigheder skete det, hvornÄr, og hvilken rÊkkefÞlge af handlinger havde kunden under testen. Vi beder dem om at vedhÊfte skÊrmbilleder.
- Vi forsÞger at lave deployment pÄ udviklingsserveren hver dag, maksimum hver anden dag. Kunden begynder da at teste funktionaliteten, og projektet stÄr ikke stille. Dette er ogsÄ et tegn for kunden pÄ, at projektet er i fuld udvikling, og at ingen fortÊller dem eventyr.
- Det sker ofte, at kunden ikke helt forstÄr, hvad de overhovedet har brug for. Da de starter en ny virksomhed, hvor processerne endnu ikke er fastlagt, er det derfor en almindelig situation, at vi smider hele kodeafsnit i skraldespanden og ombygger applikationens logik. Deraf fÞlger, at man ikke bÞr dÊkke alle aspekter med test. Det giver mening kun at dÊkke kritisk vigtig funktionalitet og det med forbehold.
- Der er situationer, hvor teamet indser, at vi ikke overholder deadlines. SÄ gennemfÞrer vi en hurtig gennemgang af opgaverne og informerer straks kunden om dette. Som en lÞsning foreslÄr vi at implementere vigtig og kritisk funktionalitet til tiden og lade resten vÊre til post-release.
- Hvis kunden begynder at finde pÄ forskellige opgaver uden at tÊnke dem igennem, begynder at fantasere og forklare med hÊnderne, beder vi dem om at give os et layout af siden og flowet med logikken, som helt skal beskrive adfÊrden for hele layoutet og dets elementer.
- FÞr vi pÄtager os en opgave, skal vi sikre, at denne funktion var en del af vores aftale / kontrakt. Hvis det er en ny funktion, som gÄr ud over vores oprindelige aftaler, skal vi nÞdvendigvis estimere denne funktion ((estimeret tid + 30%) x 2) og informere kunden om, at det vil tage sÄ lang tid, plus at deadline flyttes med tiden for estimatet ganget med to. Hvis vi kan fÄ opgaven gjort hurtigere - fantastisk, det vil kun vÊre til gavn for alle. Ellers har vi taget forholdsregler.
b) Hvad vi ikke accepterer i teamet:
- Uforpligtethed, uorganiserethed, glemsomhed
- At âfodre med lĂžfterâ. Hvis du ikke kan fuldfĂžre en opgave eller ikke ved hvordan, skal du straks informere teamlederen i stedet for at vente til sidste Ăžjeblik.
- SelvhĂŠvdelse og praleri fra en person, der endnu ikke har bevist deres evner og professionalisme. Hvis de har bevist det, er det i orden, inden for rimelighedens grĂŠnser đ
- Bedrag i enhver form. Hvis opgaven ikke er udfÞrt, bÞr du ikke Êndre dens status til fuldfÞrt og skrive i kundens chat, at den er klar. Computeren er gÄet i stykker, systemet har fejlet, hunden har bidt i bÊrbar - alt dette er uacceptabelt. Hvis der opstÄr en reel force majeure, skal teamlederen straks informeres.
- NÄr en specialist hele tiden er offline, og det er svÊrt at fÄ fat i dem i arbejdstiden.
- Toxicitet i teamet accepteres ikke! Hvis nogen er uenige, sÄ mÞdes alle sammen og diskuterer og lÞser det.
Og en rÊkke spÞrgsmÄl / teser, som jeg nogle gange stiller min kunde for at afklare eventuelle misforstÄelser:
- Hvad er jeres kvalitetskriterier?
- Hvordan vurderer I, om der er problemer i projektet eller ej?
- Hvis I ignorerer alle vores anbefalinger og rÄd om Êndringer / forbedringer af systemet, bÊrer I alene alle risici.
- Enhver stĂžrre ĂŠndring i projektet (f.eks. forskellige ekstra flows) kan fĂžre til muligheden for fejl (som vi naturligvis vil lĂžse).
- Det er umuligt at forstÄ, hvilken problematik der er opstÄet i projektet pÄ et par minutter, og isÊr at fikse det med det samme.
- Vi arbejder med et specifikt produkt flow (Opgaver i Jira - Udvikling - Testning - Deploy). Det betyder, at vi ikke kan reagere pÄ hele strÞmmen af anmodninger og klager i chatten.
- ProgrammĂžrer er programmĂžrer, ikke professionelle testere, og kan ikke sikre passende kvalitet i projektets testning.
- Ansvar for den endelige testning og godkendelse af opgaver pÄ produktion ligger helt pÄ dig.
- Hvis vi allerede har taget en opgave i arbejde, kan vi ikke straks skifte til andre, fĂžr vi er fĂŠrdige med den nuvĂŠrende (ellers fĂžrer det til endnu flere fejl og lĂŠngere udviklingstid).
- Antallet af folk i teamet er blevet fÊrre (pÄ grund af ferie eller sygdom), mens arbejdet er steget, og vi fysisk ikke kan nÄ at reagere pÄ alt, hvad du Þnsker.
- At anmode os om at deployere pÄ produktion uden testede opgaver pÄ udvikling er kun dine risici, ikke udviklernes.
- NÄr du stiller uklare opgaver, uden korrekt flow, uden designmockups, krÊver det langt stÞrre indsats og tid fra os, da vi i stedet for dig mÄ udfÞre ekstra arbejdsopgaver.
- Enhver opgave vedrÞrende bugs, uden detaljeret beskrivelse af deres opstÄen og screenshots, giver os ikke mulighed for at forstÄ, hvad der er gÄet galt, og hvordan vi kan genskabe denne bug.
- Projektet krÊver konstant forfining og forbedringer for at Þge ydeevnen og sikkerheden. Derfor bruger teamet en del af sin tid pÄ disse forbedringer.
- Da vi undertiden har overarbejde (hastefix), skal vi kompensere dem pÄ andre dage.
Som regel forstÄr kunden straks, at det ikke er sÄ simpelt at udvikle software, og blot et Þnske er tydeligvis utilstrÊkkeligt.
Det var alt. Bag kulisserne efterlader jeg mange forhandlinger og den indledende justering af alle processer, men som resultat er alt blevet ordnet. Jeg kan sige, at denne proces er blevet vores 'sĂžlvkugle'. Nye mennesker, der kom ind i projektet, kunne straks deltage i arbejdet fra den fĂžrste dag, da alle processer er beskrevet, og dokumentation og arkitektur i form af diagrammer straks gav indsigt i, hvad vi alle arbejder med.
P. S. Jeg vil prÊcisere, at vi ikke har en projektleder pÄ vores side. Det er der pÄ kundens side. Helt ikke teknisk. Projektet er europÊisk. Al kommunikation foregÄr kun pÄ engelsk.
Alle held og lykke med projekterne. Bliv ikke udbrĂŠndt, og forsĂžg at forbedre jeres processer.
Kilden i min .
Kilde: habr.com
