Hej venner. Ganske ofte, især i outsourcing, ser jeg det samme billede. Manglen på en klar arbejdsgang i teams på forskellige projekter.
Det vigtigste er, at programmører ikke forstår, hvordan man kommunikerer med kunden og med hinanden. Hvordan man opbygger en kontinuerlig proces med at udvikle et kvalitetsprodukt. Sådan planlægger du din arbejdsdag og sprint.
Og alt dette resulterer i sidste ende i brudte deadlines, overarbejde, konstante opgør om, hvem der har skylden, og kundernes utilfredshed – hvor og hvordan alting bevæger sig. Ganske ofte fører alt dette til en ændring af programmører og endda hele teams. Tab af en kunde, forringelse af omdømme og så videre.
På et tidspunkt kom jeg lige på sådan et projekt, hvor der var alle disse herligheder.
Ingen ønskede at tage ansvaret for projektet (en stor servicemarkedsplads), omsætningen var forfærdelig, kunden rev og kastede bare. Den administrerende direktør henvendte sig på en eller anden måde til mig og sagde, at du har den nødvendige erfaring, så du har kortene mellem hænderne. Tag selv projektet. Hvis du skruer op, lukker vi projektet og sparker alle ud. Det vil vise sig, det vil være sejt, så led det og udvikle det, som det passer dig. Som et resultat blev jeg teamleder på projektet, og alt faldt på mine skuldre.
Det første, jeg gjorde, var at designe et workflow fra bunden, der matchede min vision på det tidspunkt og skrev en jobbeskrivelse til teamet. Det var ikke let at implementere det. Men et sted inden for en måned faldt alt af, udviklerne og klienten vænnede sig til det, og alt gik stille og roligt. For at vise holdet, at dette ikke bare er en storm i et glas, men en reel vej ud af situationen, påtog jeg mig det maksimale ansvar og fjernede den ubehagelige rutine fra holdet.
Der er allerede gået halvandet år, og projektet udvikler sig uden overarbejde, uden "rotteløb" og alverdens stress. Nogen i det gamle team ville ikke arbejde sådan og gik, tværtimod, nogen kom virkelig ind i det, at der dukkede gennemsigtige regler op. Men som følge heraf er alle i teamet meget motiverede og kender det kæmpe projekt til fulde, med både front-end og back-end. Inklusive både kodebasen og al forretningslogik. Det er endda kommet dertil, at vi ikke bare er “roere”, men vi selv kommer med mange forretningsprocesser og nye funktioner, som virksomheden godt kan lide.
Takket være denne tilgang fra vores side besluttede kunden at bestille en anden markedsplads fra vores virksomhed, hvilket er godt nyt.
Da dette virker på mit projekt, vil det måske også hjælpe nogen. Så selve processen, som hjalp os med at redde projektet:
Processen med teamarbejde på projektet "Mit yndlingsprojekt"
a) Inden for en teamproces (mellem udviklere)
- Alle opgaver oprettes i Jira systemet
- Hver opgave skal beskrives så meget som muligt og udføre strengt én handling.
- Enhver funktion, hvis den er kompleks nok, er opdelt i mange små opgaver
- Teamet arbejder på funktioner som en enkelt opgave. Først laver vi en funktion sammen, giver den til test, og derefter tager vi den næste.
- Hver opgave er mærket til backend eller frontend
- Der er typer af opgaver og fejl. Du skal angive dem korrekt.
- Når opgaven er fuldført, overføres den til kodegennemgangsstatus (en pull-anmodning oprettes til dens kollega)
- Den, der fuldførte opgaven, sporer straks sin tid til denne opgave
- Efter kontrol af koden godkendes PR'en, og derefter flettes den, der udførte denne opgave selvstændigt, ind i mastergrenen, hvorefter den ændrer sin status til klar til udrulning til udviklerserveren.
- Alle opgaver, der er klar til at blive implementeret til udviklerserveren, implementeres af teamlederen (hans ansvarsområde), nogle gange et teammedlem, hvis noget haster. Efter implementering overføres alle opgaver fra klar til udrulning til dev til status - klar til test på dev
- Alle opgaver testes af kunden
- Når kunden har testet opgaven på udvikleren, overfører han den til status klar til udrulning til produktion.
- Til udrulning til produktion har vi en separat filial, hvor vi slår masteren sammen lige før udrulningen
- Hvis kunden under testen finder fejl, returnerer han opgaven til revision og indstiller dens status tilbage til revision. Sådan adskiller vi nye opgaver fra dem, der ikke er testet.
- Som et resultat går alle opgaver fra oprettelse til færdiggørelse: At gøre → Under udvikling → Kodegennemgang → Klar til implementering til udvikler → QA på dev → (Tilbage til udvikler) → Klar til implementering til prod → QA på prod → Udført
- Hver udvikler tester sin kode uafhængigt, også som bruger af webstedet. Det er ikke tilladt at flette en filial med den primære, medmindre det med sikkerhed vides, at koden virker.
- Hver opgave har prioriteter. Prioriteringer fastsættes enten af kunden eller teamlederen.
- Udviklere udfører prioriterede opgaver først.
- Udviklere kan tildele opgaver til hinanden, hvis der blev fundet forskellige fejl i systemet, eller en opgave består af flere specialisters arbejde.
- Alle opgaver, som kunden opretter, sendes til teamlederen, som evaluerer dem og enten beder kunden om at færdiggøre dem eller tildele dem til et af teammedlemmerne.
- Alle opgaver, der er klar til at blive implementeret til dev eller prod, kommer også til teamlederen, som selvstændigt bestemmer, hvornår og hvordan de skal implementeres. Efter hver udrulning skal teamlederen (eller teammedlemmet) give kunden besked om dette. Og ændre også statuserne for opgaver til klar til test på dev/prod.
- Hver dag på samme tid (vi har det kl. 12.00) holder vi et stævne mellem alle teammedlemmer
- Alle ved stævnet rapporterer, inklusive holdlederen, hvad han lavede i går, hvad han planlægger at gøre i dag. Hvad virker ikke og hvorfor. Dermed er hele teamet klar over, hvem der gør hvad og på hvilket stadium projektet er. Dette giver os mulighed for at forudsige og om nødvendigt justere vores estimater og deadlines.
- På mødet annoncerer teamlederen også alle ændringer i projektet og niveauet af aktuelle fejl, som ikke blev fundet af kunden. Alle fejl sorteres fra og tildeles hvert teammedlem for at løse dem.
- Ved stævnet tildeler teamlederen opgaver til hver, idet der tages hensyn til udviklernes aktuelle arbejdsbyrde, deres niveau af faglig uddannelse og også under hensyntagen til, hvor tæt en bestemt opgave er i forhold til, hvad udvikleren gør i øjeblikket.
- På mødet udvikler teamlederen en generel strategi for arkitektur og forretningslogik. Derefter diskuterer hele teamet dette og beslutter, om de vil foretage justeringer eller vedtage denne strategi.
- Hver udvikler skriver kode og bygger algoritmer uafhængigt inden for en enkelt arkitektur og forretningslogik. Alle kan udtrykke deres vision om implementering, men ingen tvinger nogen til at gøre det på denne måde og ikke på anden måde. Enhver beslutning er berettiget. Hvis der er en bedre løsning, men nu er der ikke tid til det, så skabes der en opgave i fedt, til fremtidig refactoring af en bestemt del af koden.
- Når en udvikler påtager sig en opgave, flytter han den til udviklingsstatus. Al kommunikation vedrørende afklaring af opgaven med kunden falder på udviklerens skuldre. Tekniske spørgsmål kan stilles til teamlederen eller kollegaerne.
- Hvis udvikleren ikke forstår essensen af opgaven, og kunden ikke kunne forklare det fornuftigt, så går han videre til næste opgave. Og teamlederen tager den nuværende og diskuterer den med kunden.
- Hver dag skal udvikleren skrive i klientens chat om, hvilke opgaver han arbejdede med i går, og hvilke opgaver han vil arbejde med i dag
- Arbejdsgangen er baseret på Scrum. Alt er opdelt i spurter. Hver sprint varer to uger.
- Sprints oprettes, fyldes og lukkes af holdlederen.
- Hvis projektet har stramme deadlines, så forsøger vi at estimere alle opgaverne groft. Og vi henter fra dem en spurt. Hvis kunden forsøger at tilføje flere opgaver til spurten, så prioriterer vi, og overfører nogle andre opgaver til næste spurt.
b) Processen med at arbejde med kunden
- Hver udvikler kan og bør kommunikere med kunden
- Du kan ikke tillade kunden at pålægge deres egne spilleregler. Det er nødvendigt på en høflig og venlig måde at gøre det klart for kunden, at vi er specialister inden for vores felt, og kun vi skal bygge arbejdsprocesser og involvere kunden i dem
- Det er ideelt set nødvendigt, før du fortsætter med implementeringen af enhver funktionalitet, at oprette et flowchart over hele den logiske proces for en funktion (workflow). Og send den til kunden til bekræftelse. Dette gælder kun for kompleks og ikke indlysende funktionalitet, for eksempel et betalingssystem, et notifikationssystem mv. Dette vil give dig mulighed for mere præcist at forstå, hvad kunden har brug for, gemme dokumentationen til funktionen og også sikre dig mod, at kunden i fremtiden kan sige, at vi ikke gjorde, hvad han bad om.
- Alle diagrammer/flowdiagrammer/logik osv. vi sparer i Confluence/Fat, hvor vi beder kunden i kommentarerne bekræfte rigtigheden af den fremtidige implementering.
- Vi forsøger ikke at belaste kunden med tekniske detaljer. Hvis vi har brug for en forståelse for, hvordan kunden vil, så tegner vi primitive algoritmer i form af et flowchart, som kunden selv kan forstå og rette/modificere alt.
- Hvis kunden finder en fejl i projektet, så beder vi dig beskrive det meget detaljeret i Fat. Under hvilke omstændigheder skete det, hvornår, hvilken rækkefølge af handlinger blev udført af kunden under test. Vedhæft venligst skærmbilleder.
- Vi prøver hver dag, maksimalt hver anden dag, at implementere til udviklerserveren. Kunden begynder derefter at teste funktionaliteten, og projektet er ikke inaktivt. Dette er samtidig en markør for kunden på, at projektet er i fuld udvikling, og ingen fortæller ham eventyr.
- Det sker ofte, at kunden slet ikke helt forstår, hvad han har brug for. Da han opretter en ny forretning for sig selv med processer, der endnu ikke er blevet fejlrettet. Derfor er en meget almindelig situation, når vi smider hele stykker kode i skraldespanden og omformer applikationslogikken. Det følger heraf, at det ikke er nødvendigt at dække absolut alt med tests. Det giver mening kun at dække kritisk funktionalitet med test og derefter med forbehold.
- Der er situationer, hvor teamet indser, at vi ikke passer ind i deadlines. Derefter foretager vi en hurtig revision af opgaverne, og informerer straks kunden om det. Som en vej ud af situationen foreslår vi, at du lancerer vigtig og kritisk funktionalitet til tiden og overlader resten til post-release.
- Hvis kunden begynder at komme med forskellige opgaver fra sit hoved, begynder at fantasere og forklare på fingrene, så beder vi ham om at give os et sidelayout og flow med logik, der fuldt ud skal beskrive opførselen af hele layoutet og dets elementer.
- Før vi påtager os en opgave, skal vi sikre os, at denne funktion var inkluderet i vilkårene i vores aftale/kontrakt. Hvis dette er en ny funktion, der går ud over vores oprindelige aftaler, så skal vi bestemt estimere denne funktion ((ca. gennemløbstid + 30%) x 2) og indikere over for kunden, at det vil tage os så lang tid at færdiggøre den, plus fristen forskydes for estimattiden ganget med to. Lad os gøre opgaven hurtigere – fantastisk, alle vil kun få gavn af dette. Hvis ikke, så er vi forsikret.
c) Hvad vi ikke accepterer i teamet:
- Inkonsekvens, usammenhæng, glemsomhed
- "Morgenmadsmad". Hvis du ikke kan fuldføre opgaven, ved du ikke hvordan, så skal du straks underrette teamlederen om dette, og ikke vente til det sidste.
- Brovada og praler fra en person, der endnu ikke har bevist sine evner og professionalisme ved gerning. Hvis det bevises, så er det muligt, inden for anstændighedens grænser 🙂
- Svig i alle dets udslag. Hvis opgaven ikke er fuldført, så skal du ikke ændre dens status til afsluttet og skrive i klientens chat, at den er klar. Computeren styrtede ned, systemet styrtede ned, hunden tyggede på den bærbare computer - alt dette er uacceptabelt. Hvis der opstår en reel force majeure, skal teamlederen straks underrettes.
- Når en specialist er offline hele tiden, og det er svært at nå ham i arbejdstiden.
- Toksicitet i holdet er ikke tilladt! Hvis nogen er uenige i noget, så samles alle til et møde og diskuterer og beslutter.
Og en række spørgsmål/teser, som jeg nogle gange beder min kunde om at fjerne alle misforståelser:
- Hvad er dine kvalitetskriterier?
- Hvordan afgør du, om et projekt har problemer eller ej?
- Hvis du overtræder alle vores anbefalinger og råd om ændring/forbedring af systemet, bæres alle risici kun af dig
- Eventuelle større projektændringer (for eksempel alle former for ekstra flow) vil føre til mulige forekomster af fejl (som vi selvfølgelig vil rette)
- Det er umuligt at forstå inden for et par minutter, hvilken slags problem der opstod på projektet, og endnu mere at løse det lige der
- Vi arbejder på et specifikt produktflow (Opgaver i Zhira - Udvikling - Test - Deploy). Det betyder, at vi ikke kan besvare hele strømmen af anmodninger og klager i chatten.
- Programmører er bare programmører, ikke professionelle testere, og kan ikke sikre den korrekte kvalitet af projekttestning
- Ansvaret for sluttest og accept af opgaver på salget ligger helt hos dig
- Hvis vi allerede har påtaget os en opgave, så kan vi ikke umiddelbart skifte til andre, før vi fuldfører den nuværende (ellers fører det til endnu flere fejl og øget udviklingstid)
- Der er færre mennesker i teamet (pga. ferie eller sygdom), og der er mere arbejde, og vi vil ikke fysisk nå at svare på alt, hvad du ønsker
- At bede dig om at implementere til produktion uden testede opgaver på dev er kun din risiko, ikke udviklerens
- Når du sætter uklare opgaver, uden korrekt flow, uden designlayout, kræver det meget mere indsats og implementeringstid fra os, da vi skal udføre en ekstra mængde arbejde i stedet for dig
- Eventuelle opgaver på fejl, uden en detaljeret beskrivelse af deres forekomst og skærmbilleder, giver os ikke mulighed for at forstå, hvad der gik galt, og hvordan vi kan udsende denne fejl
- Projektet kræver konstant forfining og forbedringer for at forbedre ydeevne og sikkerhed. Derfor bruger teamet noget af sin tid på disse forbedringer.
- På grund af at vi har overarbejdstimer (hasterettelser), skal vi kompensere for dem på andre dage
Som regel forstår kunden med det samme, at alt ikke er så enkelt i softwareudvikling, og lyst alene er tydeligvis ikke nok.
Generelt er dette alt. Bag kulisserne efterlader jeg en masse forhandlinger og den indledende fejlsøgning af alle processer, men som et resultat lykkedes det. Jeg kan sige, at denne proces er blevet en slags "Silver Bullet" for os. Nye mennesker, der kom til projektet, kunne allerede fra første dag satse på arbejdet, da alle processer er beskrevet, og dokumentationen og arkitekturen i form af diagrammer gav straks en idé om, hvad vi alle laver her.
PS Jeg vil gerne præcisere, at der ikke er nogen projektleder på vores side. Det er på kundens side. Ikke en tekniker overhovedet. europæisk projekt. Al kommunikation er kun på engelsk.
Held og lykke til alle med jeres projekter. Brænd ikke ud og prøv at forbedre dine processer.
kilde i min .
Kilde: www.habr.com