🥇Organisering av arbeidsflyten i et team på et IT-prosjekt

Hei venner. Ganske ofte, spesielt i outsourcing, ser jeg det samme bildet. Mangelen på en tydelig arbeidsflyt i team på ulike prosjekter.

Det viktigste er at programmerere ikke forstår hvordan de skal kommunisere med kunden og med hverandre. Hvordan bygge en kontinuerlig prosess for å utvikle et kvalitetsprodukt. Hvordan planlegge arbeidsdagen og spurtene.

Og alt dette resulterer til slutt i brutte tidsfrister, overtid, stadige oppgjør om hvem som har skylden, og kundemisnøye – hvor og hvordan alt beveger seg. Ganske ofte fører alt dette til en endring av programmerere, og til og med hele team. Tap av en kunde, forringelse av omdømme og så videre.

På et tidspunkt begynte jeg nettopp på et slikt prosjekt, hvor det var alle disse herlighetene.

Ingen ønsket å ta ansvar for prosjektet (en stor tjenestemarkedsplass), omsetningen var forferdelig, kunden bare rev og kastet. Konsernsjefen kom på en eller annen måte til meg og sa at du har den nødvendige erfaringen, så du har kortene i hendene. Ta prosjektet for deg selv. Skruer du til slutt stenger vi prosjektet og sparker alle ut. Det vil vise seg, det blir kult, så led det og utvikler det slik du vil. Som et resultat ble jeg teamleder på prosjektet og alt falt på mine skuldre.

Det første jeg gjorde var å utforme en arbeidsflyt fra bunnen av som passet med min visjon på den tiden og skrev en jobbbeskrivelse for teamet. Det var ikke lett å implementere det. Men et sted i løpet av en måned ordnet alt seg, utviklerne og klienten ble vant til det, og alt gikk stille og behagelig. For å vise teamet at dette ikke bare er en storm i et glass, men en reell vei ut av situasjonen, tok jeg på meg det maksimale ansvaret, og fjernet den ubehagelige rutinen fra teamet.

Et og et halvt år har allerede gått, og prosjektet utvikler seg uten overtid, uten "rotterace" og all slags stress. Noen i det gamle laget ville ikke jobbe slik og dro, tvert imot, noen kom virkelig inn i det at det dukket opp transparente regler. Men som et resultat er alle i teamet veldig motiverte og kjenner det enorme prosjektet til fulle, med både front-end og back-end. Inkludert både kodebasen og all forretningslogikk. Det har til og med kommet til det punktet at vi ikke bare er «roere», men vi selv kommer opp med mange forretningsprosesser og nye funksjoner som bedriften liker.

Takket være denne tilnærmingen fra vår side, bestemte kunden seg for å bestille en annen markedsplass fra selskapet vårt, noe som er gode nyheter.

Siden dette fungerer på prosjektet mitt, kan det kanskje også hjelpe noen. Så selve prosessen, som hjalp oss med å redde prosjektet:

Prosessen med teamarbeid på prosjektet "Mitt favorittprosjekt"

a) Innenfor en teamprosess (mellom utviklere)

Alle oppgaver lages i Jira-systemet
Hver oppgave skal beskrives så mye som mulig, og utføre strengt tatt én handling.
Enhver funksjon, hvis den er kompleks nok, er delt inn i mange små oppgaver
Teamet jobber med funksjoner som en enkelt oppgave. Først gjør vi en funksjon sammen, gir den til testing, og så tar vi den neste.
Hver oppgave er merket for backend eller frontend
Det finnes typer oppgaver og feil. Du må spesifisere dem riktig.
Etter at oppgaven er fullført, overføres den til kodegjennomgangsstatusen (en pull-forespørsel opprettes for kollegaen)
Den som fullførte oppgaven sporer umiddelbart tiden sin for denne oppgaven
Etter å ha sjekket koden, godkjennes PR-en, og etter det slår den som utførte denne oppgaven den sammen med hovedgrenen, hvoretter den endrer status til klar for distribusjon til utviklerserveren.
Alle oppgaver som er klare til å distribueres til utviklerserveren, distribueres av teamlederen (hans ansvarsområde), noen ganger et teammedlem, hvis noe haster. Etter utrulling overføres alle oppgaver fra klar for utplassering til dev til status - klar for testing på dev
Alle oppgaver testes av kunden
Når kunden har testet oppgaven på utvikleren, overfører han den til statusen klar for distribusjon til produksjon.
For utplassering til produksjon har vi en egen gren hvor vi slår sammen masteren rett før utplasseringen
Hvis kunden under testing finner feil, returnerer han oppgaven for revisjon, og setter statusen tilbake for revisjon. Slik skiller vi nye oppgaver fra de som ikke er testet.
Som et resultat går alle oppgaver fra opprettelse til fullføring: Å gjøre → Under utvikling → Kodegjennomgang → Klar distribusjon til utvikler → QA på utvikler → (Tilbake til utvikler) → Klar distribusjon til produkt → QA på produkt → Ferdig
Hver utvikler tester koden sin uavhengig, inkludert som bruker av nettstedet. Det er ikke tillatt å slå sammen en gren med den viktigste, med mindre det er sikkert kjent at koden fungerer.
Hver oppgave har prioriteringer. Prioriteringer settes enten av kunden eller teamlederen.
Utviklere gjør prioriterte oppgaver først.
Utviklere kan tildele oppgaver til hverandre hvis det ble funnet forskjellige feil i systemet eller en oppgave består av arbeidet til flere spesialister.
Alle oppgaver som kunden oppretter sendes til teamlederen, som evaluerer dem og enten ber kunden om å fullføre dem eller tildeler dem til en av teammedlemmene.
Alle oppgaver som er klare til å bli distribuert til utvikling eller prod, kommer også til teamlederen, som selvstendig bestemmer når og hvordan de skal distribueres. Etter hver utplassering skal teamleder (eller teammedlem) varsle kunden om dette. Og endre også statusene for oppgaver til klare for testing på dev/prod.
Hver dag til samme tid (vi har det kl. 12.00) holder vi et rally mellom alle teammedlemmene
Alle på rallyet rapporterer, inkludert laglederen, hva han gjorde i går, hva han planlegger å gjøre i dag. Hva fungerer ikke og hvorfor. Dermed er hele teamet klar over hvem som gjør hva og på hvilket stadium prosjektet er. Dette gir oss muligheten til å forutsi og justere, om nødvendig, våre estimater og tidsfrister.
På møtet kunngjør teamlederen også alle endringene i prosjektet og nivået på aktuelle feil som ikke ble funnet av kunden. Alle feil blir sortert ut og tildelt hvert teammedlem for å løse dem.
På rallyet tildeler teamlederen oppgaver for hver, tar hensyn til den nåværende arbeidsmengden til utviklerne, deres nivå av profesjonell opplæring, og tar også hensyn til nærheten til en bestemt oppgave til det utvikleren gjør for øyeblikket.
På møtet utvikler teamlederen en generell strategi for arkitektur og forretningslogikk. Etter det diskuterer hele teamet dette og bestemmer om de skal gjøre justeringer eller ta i bruk denne strategien.
Hver utvikler skriver kode og bygger algoritmer uavhengig innenfor en enkelt arkitektur og forretningslogikk. Alle kan uttrykke sin visjon om implementering, men ingen tvinger noen til å gjøre det på denne måten og ikke på annen måte. Hver avgjørelse er berettiget. Hvis det finnes en bedre løsning, men nå er det ikke tid til det, så lages det en oppgave i fett, for fremtidig refaktorering av en viss del av koden.
Når en utvikler tar på seg en oppgave, flytter han den til utviklingsstatus. All kommunikasjon angående avklaring av oppgaven med kunden faller på utviklerens skuldre. Tekniske spørsmål kan stilles til teamleder eller kollegaer.
Hvis utvikleren ikke forstår essensen av oppgaven, og kunden ikke kunne forklare det på en fornuftig måte, går han videre til neste oppgave. Og teamlederen tar den nåværende og diskuterer den med kunden.
Hver dag skal utvikleren skrive i klientens chat om hvilke oppgaver han jobbet med i går og hvilke oppgaver han skal jobbe med i dag
Arbeidsflyten er basert på Scrum. Alt er delt inn i spurter. Hver sprint varer i to uker.
Sprints opprettes, fylles og lukkes av laglederen.
Hvis prosjektet har strenge tidsfrister, så prøver vi å grovt anslå alle oppgavene. Og vi samler fra dem en sprint. Hvis kunden prøver å legge til flere oppgaver på sprinten, så setter vi prioriteringer, og overfører noen andre oppgaver til neste sprint.

b) Prosessen med å jobbe med kunden

Hver utvikler kan og bør kommunisere med kunden
Du kan ikke tillate kunden å pålegge sine egne spilleregler. Det er nødvendig på en høflig og vennlig måte å gjøre det klart for kunden at vi er spesialister på vårt felt, og det er kun vi som skal bygge arbeidsprosesser og involvere kunden i dem
Ideelt sett er det nødvendig, før du fortsetter med implementeringen av funksjonalitet, å lage et flytskjema over hele den logiske prosessen for en funksjon (arbeidsflyt). Og send den til kunden for bekreftelse. Dette gjelder kun kompleks og ikke åpenbar funksjonalitet, for eksempel et betalingssystem, et varslingssystem osv. Dette vil tillate deg å mer nøyaktig forstå hva kunden trenger, lagre dokumentasjonen for funksjonen, og også sikre deg mot det faktum at kunden kan si i fremtiden at vi ikke gjorde det han ba om.
Alle diagrammer/flytskjemaer/logikk osv. vi sparer i Confluence/Fat, hvor vi ber kunden i kommentarfeltet bekrefte riktigheten av fremtidig implementering.
Vi prøver å ikke belaste kunden med tekniske detaljer. Trenger vi forståelse for hvordan kunden ønsker, så tegner vi primitive algoritmer i form av et flytskjema som kunden kan forstå og fikse/modifisere alt selv.
Hvis kunden finner en feil i prosjektet, ber vi deg om å beskrive den i detalj i Fat. Under hvilke omstendigheter skjedde det, når, hvilken rekkefølge av handlinger ble utført av kunden under testing. Legg ved skjermbilder.
Vi prøver hver dag, maksimalt annenhver dag, å distribuere til utviklerserveren. Kunden begynner deretter å teste funksjonaliteten og prosjektet er ikke inaktivt. Samtidig er dette en markør for kunden på at prosjektet er i full utvikling og ingen forteller ham eventyr.
Det hender ofte at kunden ikke helt forstår hva han trenger i det hele tatt. Siden han oppretter en ny virksomhet for seg selv, med prosesser som ennå ikke er feilsøkt. Derfor er en veldig vanlig situasjon når vi kaster hele kodebiter i søpla og omformer applikasjonslogikken. Det følger av dette at det ikke er nødvendig å dekke absolutt alt med tester. Det er fornuftig å kun dekke kritisk funksjonalitet med tester, og deretter med forbehold.
Det er situasjoner hvor teamet innser at vi ikke passer inn i tidsfrister. Deretter gjennomfører vi en rask revisjon av oppgavene, og informerer umiddelbart kunden om det. Som en vei ut av situasjonen foreslår vi at du lanserer viktig og kritisk funksjonalitet i tide, og lar resten ligge etter utgivelsen.
Hvis kunden begynner å komme på forskjellige oppgaver fra hodet, begynner å fantasere og forklare på fingrene, så ber vi ham om å gi oss et sideoppsett og flyt med logikk som fullt ut skal beskrive oppførselen til hele layouten og dens elementer.
Før vi tar på oss en oppgave, må vi sørge for at denne funksjonen var inkludert i vilkårene i vår avtale/kontrakt. Hvis dette er en ny funksjon som går utover våre opprinnelige avtaler, må vi definitivt estimere denne funksjonen ((omtrentlig ledetid + 30%) x 2) og indikere til kunden at det vil ta oss så mye tid for det, pluss fristen forskyves for estimattiden multiplisert med to. La oss gjøre oppgaven raskere - flott, alle vil bare tjene på dette. Hvis ikke, så er vi forsikret.

c) Hva vi ikke godtar i laget:

Inkonsekvens, usammenheng, glemsel
"Frokostmating". Hvis du ikke kan fullføre oppgaven, vet du ikke hvordan, må du umiddelbart varsle teamlederen om dette, og ikke vente til det siste.
Brovada og skryt fra en person som ennå ikke har bevist sine evner og profesjonalitet ved handling. Hvis bevist, så er det mulig, innenfor grensene for anstendighet 🙂
Svindel i alle dens manifestasjoner. Hvis oppgaven ikke er fullført, bør du ikke endre statusen til fullført og skrive i klientchatten at den er klar. En datamaskin krasjet, et system krasjet, en hund tygget på en bærbar PC - alt dette er uakseptabelt. Hvis det oppstår en reell force majeure, bør teamlederen umiddelbart varsles.
Når en spesialist er offline hele tiden og det er vanskelig å nå ham i arbeidstiden.
Giftighet i laget er ikke tillatt! Hvis noen er uenige i noe, så samles alle til et møte og diskuterer og bestemmer.

Og en rekke spørsmål / teser som jeg noen ganger ber kunden min om å fjerne alle misforståelser:

Hva er kvalitetskriteriene dine?
Hvordan avgjør du om et prosjekt har problemer eller ikke?
Brudd på alle våre anbefalinger og råd om å endre/forbedre systemet, alle risikoer bæres kun av deg
Eventuelle større prosjektendringer (for eksempel all slags ekstra flyt) vil føre til mulig opptreden av feil (som vi selvfølgelig vil fikse)
Det er umulig å forstå i løpet av et par minutter hva slags problem som oppstod på prosjektet, og enda mer å fikse det akkurat der
Vi jobber med en spesifikk produktflyt (Oppgaver i Zhira - Utvikling - Testing - Deploy). Dette betyr at vi ikke kan svare på hele strømmen av forespørsler og klager i chatten.
Programmerere er bare programmerere, ikke profesjonelle testere, og kan ikke sikre riktig kvalitet på prosjekttestingen
Ansvaret for slutttesting og aksept av oppgaver på salget ligger helt hos deg
Hvis vi allerede har tatt på oss en oppgave, kan vi ikke umiddelbart bytte til andre før vi fullfører den nåværende (ellers fører dette til enda flere feil og økt utviklingstid)
Det er færre personer i teamet (pga ferier eller sykdommer), og det er mer arbeid og vi vil ikke fysisk ha tid til å svare på alt du ønsker
Å be deg distribuere til produksjon uten testede oppgaver på dev er bare din risiko, ikke utviklerens
Når du setter uklare oppgaver, uten riktig flyt, uten designoppsett, krever dette mye mer innsats og implementeringstid fra oss, siden vi må gjøre en ekstra mengde arbeid i stedet for deg
Eventuelle oppgaver på feil, uten en detaljert beskrivelse av deres forekomst og skjermbilder, gir oss ikke muligheten til å forstå hva som gikk galt og hvordan vi kan sende ut denne feilen
Prosjektet krever konstant foredling og forbedringer for å forbedre ytelsen og sikkerheten. Derfor bruker teamet noe av tiden sin på disse forbedringene.
På grunn av at vi har overtidstimer (hastefikser), må vi kompensere for disse på andre dager

Som regel forstår kunden umiddelbart at alt ikke er så enkelt i programvareutvikling, og lyst alene er tydeligvis ikke nok.

Generelt er dette alt. Bak kulissene legger jeg igjen mange forhandlinger og den første feilsøkingen av alle prosesser, men som et resultat fungerte alt. Jeg kan si at denne prosessen har blitt en slags "Silver Bullet" for oss. Nye personer som kom til prosjektet kunne allerede umiddelbart trene seg i arbeid fra første dag, siden alle prosessene er beskrevet, og dokumentasjonen og arkitekturen i form av diagrammer ga umiddelbart en idé om hva vi alle gjør her.

PS Jeg vil presisere at det ikke er noen prosjektleder på vår side. Det er på kundens side. Ikke en tekno i det hele tatt. Europeisk prosjekt. All kommunikasjon er kun på engelsk.

Lykke til alle med prosjektene dine. Ikke brenn ut og prøv å forbedre prosessene dine.

kilde i min blogginnlegg.

Kilde: www.habr.com