🥇Organisatie van de workflow in een team aan een IT-project

Hallo vrienden. Heel vaak, vooral bij outsourcing, zie ik hetzelfde beeld. Het ontbreken van een duidelijke workflow in teams op verschillende projecten.

Het belangrijkste is dat programmeurs niet begrijpen hoe ze met de klant en met elkaar moeten communiceren. Hoe een continu proces van het ontwikkelen van een kwaliteitsproduct te bouwen. Hoe je je werkdag en sprints plant.

En dit alles resulteert uiteindelijk in gebroken deadlines, overuren, constante confrontaties over wie de schuldige is en ontevredenheid van de klant - waar en hoe alles beweegt. Dit alles leidt vaak tot een wisseling van programmeurs en zelfs van hele teams. Verlies van een klant, verslechtering van de reputatie en ga zo maar door.

Ooit kwam ik net aan zo'n project, waar al deze geneugten waren.

Niemand wilde de verantwoordelijkheid nemen voor het project (een grote servicemarktplaats), de omzet was verschrikkelijk, de klant scheurde en gooide gewoon. De CEO benaderde me op de een of andere manier en zei dat je de nodige ervaring hebt, dus je hebt de kaarten in handen. Neem het project voor jezelf. Als je het verprutst, sluiten we het project en schoppen we iedereen eruit. Het zal blijken, het zal cool zijn, leid het dan en ontwikkel het naar eigen inzicht. Hierdoor werd ik teamleider op het project en viel alles op mijn schouders.

Het eerste dat ik deed, was een volledig nieuwe workflow ontwerpen die overeenkwam met mijn toenmalige visie en een taakomschrijving voor het team schrijven. De uitvoering ervan was niet eenvoudig. Maar ergens binnen een maand kwam alles tot rust, de ontwikkelaars en de klant raakten eraan gewend en alles verliep rustig en comfortabel. Om het team te laten zien dat dit niet zomaar een storm in een glas is, maar een echte uitweg uit de situatie, nam ik het maximale aantal verantwoordelijkheden op me en verwijderde ik de onaangename routine uit het team.

Er is al anderhalf jaar verstreken en het project ontwikkelt zich zonder overuren, zonder "ratraces" en allerlei soorten stress. Iemand in het oude team wilde zo niet werken en vertrok, integendeel, iemand ging er echt op in dat er transparante regels verschenen. Maar daardoor is iedereen in het team erg gemotiveerd en kent het enorme project door en door, zowel front-end als back-end. Inclusief zowel de codebase als alle bedrijfslogica. Het is zelfs zo ver gekomen dat we niet zomaar “roeiers” zijn, maar zelf veel bedrijfsprocessen en nieuwe features bedenken die de business leuk vindt.

Dankzij deze aanpak van onze kant heeft de klant besloten om een andere marktplaats bij ons bedrijf te bestellen, wat goed nieuws is.

Aangezien dit werkt op mijn project, zal het misschien ook iemand helpen. Dus het proces zelf, dat ons heeft geholpen het project te redden:

Het proces van teamwerk aan het project "Mijn favoriete project"

a) Binnen een teamproces (tussen ontwikkelaars)

Alle taken worden aangemaakt in het Jira systeem
Elke taak moet zoveel mogelijk worden beschreven en strikt één actie uitvoeren.
Elke functie, als deze complex genoeg is, wordt opgedeeld in vele kleine taken
Het team werkt aan functies als een enkele taak. Eerst doen we samen één functie, geven deze om te testen en nemen dan de volgende.
Elke taak is gelabeld voor backend of frontend
Er zijn soorten taken en bugs. U moet ze correct specificeren.
Nadat de taak is voltooid, wordt deze overgedragen naar de status van codebeoordeling (er wordt een pull-verzoek gemaakt voor zijn collega)
Degene die de taak heeft voltooid, houdt onmiddellijk zijn tijd voor deze taak bij
Na het controleren van de code wordt de PR goedgekeurd en daarna voegt degene die deze taak zelfstandig heeft uitgevoerd het samen in de master branch, waarna het de status verandert naar klaar voor implementatie naar de dev server.
Alle taken die klaar zijn om op de dev-server te worden geïmplementeerd, worden uitgevoerd door de teamleider (zijn verantwoordelijkheidsgebied), soms een teamlid, als er iets dringend is. Na de implementatie worden alle taken van klaar voor implementatie tot dev overgedragen naar de status - klaar voor testen op dev
Alle taken worden getest door de klant
Wanneer de klant de taak op de dev heeft getest, brengt hij deze over naar de status klaar voor implementatie naar productie.
Voor implementatie naar productie hebben we een aparte branch waar we de master net voor de implementatie samenvoegen
Als de klant tijdens het testen bugs vindt, retourneert hij de taak voor revisie en stelt hij de status terug voor revisie in. Zo scheiden we nieuwe taken van niet geteste taken.
Als gevolg hiervan gaan alle taken van creatie naar voltooiing: To Do → In ontwikkeling → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
Elke ontwikkelaar test zijn code onafhankelijk, ook als gebruiker van de site. Het is niet toegestaan een branch samen te voegen met de hoofdtak, tenzij zeker is dat de code werkt.
Elke taak heeft prioriteiten. Prioriteiten worden bepaald door de klant of de teamleider.
Ontwikkelaars doen eerst prioriteitstaken.
Ontwikkelaars kunnen taken aan elkaar toewijzen als er verschillende bugs in het systeem zijn gevonden of als één taak bestaat uit het werk van meerdere specialisten.
Alle taken die de klant maakt, worden naar de teamleider gestuurd, die ze evalueert en de klant vraagt om ze af te ronden of toewijst aan een van de teamleden.
Alle taken die klaar zijn om te worden ingezet om te ontwikkelen of te proderen, komen ook bij de teamleider, die zelfstandig bepaalt wanneer en hoe te implementeren. Na elke inzet dient de teamleider (of teamlid) de klant hierover te informeren. En verander ook de statussen voor taken in klaar voor testen op dev / prod.
Elke dag op hetzelfde tijdstip (we hebben het om 12.00 uur) houden we een rally tussen alle teamleden
Iedereen bij de rally rapporteert, ook de teamleider, wat hij gisteren heeft gedaan, wat hij van plan is vandaag te doen. Wat werkt er niet en waarom. Zo weet het hele team wie wat doet en in welk stadium het project zich bevindt. Dit geeft ons de mogelijkheid om onze schattingen en deadlines te voorspellen en indien nodig aan te passen.
Tijdens de vergadering kondigt de teamleider ook alle wijzigingen in het project aan en het niveau van de huidige bugs die niet door de klant zijn gevonden. Alle bugs worden uitgezocht en toegewezen aan elk teamlid om ze op te lossen.
Tijdens de rally wijst de teamleider taken toe aan elk, rekening houdend met de huidige werklast van ontwikkelaars, hun niveau van professionele training en ook rekening houdend met de nabijheid van een bepaalde taak tot wat de ontwikkelaar momenteel aan het doen is.
Tijdens de bijeenkomst ontwikkelt de teamleider een algemene strategie voor architectuur en bedrijfslogica. Daarna bespreekt het hele team dit en besluit om bij te sturen of deze strategie over te nemen.
Elke ontwikkelaar schrijft onafhankelijk code en bouwt algoritmen binnen een enkele architectuur en bedrijfslogica. Iedereen kan zijn visie op implementatie uiten, maar niemand dwingt iemand om het op deze manier te doen en niet anders. Elke beslissing is gerechtvaardigd. Als er een betere oplossing is, maar er is nu geen tijd voor, dan wordt er in fat een taak aangemaakt voor toekomstige refactoring van een bepaald deel van de code.
Wanneer een ontwikkelaar een taak op zich neemt, verplaatst hij deze naar de ontwikkelingsstatus. Alle communicatie over de verduidelijking van de opdracht met de klant valt op de schouders van de ontwikkelaar. Technische vragen kunnen gesteld worden aan de teamleider of collega's.
Als de ontwikkelaar de essentie van de taak niet begrijpt en de klant het niet verstandig kan uitleggen, gaat hij verder met de volgende taak. En de teamleider pakt de huidige en bespreekt deze met de klant.
Elke dag moet de ontwikkelaar in de chat van de klant schrijven aan welke taken hij gisteren heeft gewerkt en aan welke taken hij vandaag zal werken
De workflow is gebaseerd op Scrum. Alles is opgedeeld in sprints. Elke sprint duurt twee weken.
Sprints worden gemaakt, gevuld en afgesloten door de teamleider.
Als het project strikte deadlines heeft, proberen we alle taken ruwweg in te schatten. En we verzamelen van hen een sprint. Als de klant meer taken aan de sprint probeert toe te voegen, dan stellen we prioriteiten, en verplaatsen we enkele andere taken naar de volgende sprint.

b) Het proces van werken met de klant

Elke ontwikkelaar kan en moet communiceren met de klant
Je kunt niet toestaan dat de klant zijn eigen spelregels oplegt. Het is noodzakelijk om op beleefde en vriendelijke wijze de klant duidelijk te maken dat wij specialisten zijn in ons vakgebied, en alleen wij dienen werkprocessen op te bouwen en de klant daarbij te betrekken
Idealiter is het noodzakelijk om, alvorens door te gaan met de implementatie van een functionaliteit, een stroomschema te maken van het gehele logische proces voor een functie (workflow). En stuur het ter bevestiging naar de klant. Dit geldt alleen voor complexe en niet voor de hand liggende functionaliteit, bijvoorbeeld een betalingssysteem, een notificatiesysteem, etc. Hierdoor kunt u nauwkeuriger begrijpen wat de klant precies nodig heeft, de documentatie voor de functie opslaan en uzelf verzekeren tegen het feit dat de klant in de toekomst zou kunnen zeggen dat we niet hebben gedaan wat hij vroeg.
Alle diagrammen/stroomschema's/logica enz. we slaan op in Confluence/Fat, waar we de klant in de commentaren vragen om de juistheid van de toekomstige implementatie te bevestigen.
We proberen de klant niet te belasten met technische details. Als we inzicht nodig hebben in hoe de klant wil, dan tekenen we primitieve algoritmen in de vorm van een stroomschema dat de klant kan begrijpen en alles zelf kan repareren/aanpassen.
Als de klant een bug vindt in het project, dan vragen we je om deze tot in detail te beschrijven in Fat. Onder welke omstandigheden gebeurde het, wanneer, welke volgorde van acties werd uitgevoerd door de klant tijdens het testen. Voeg screenshots toe.
We proberen elke dag, maximaal om de andere dag, te implementeren op de dev-server. De klant gaat dan aan de slag met het testen van de functionaliteit en het project staat niet stil. Tegelijkertijd is dit voor de klant een teken dat het project volop in ontwikkeling is en dat niemand hem sprookjes vertelt.
Het komt vaak voor dat de klant helemaal niet begrijpt wat hij nodig heeft. Omdat hij een nieuw bedrijf voor zichzelf creëert, met processen die nog niet zijn opgespoord. Daarom is het een veel voorkomende situatie dat we hele stukjes code in de prullenbak gooien en de applicatielogica opnieuw vormgeven. Hieruit volgt dat het niet nodig is om absoluut alles met tests te dekken. Het is logisch om alleen kritieke functionaliteit te dekken met tests en vervolgens met reserveringen.
Er zijn situaties waarin het team zich realiseert dat we niet binnen deadlines passen. Vervolgens doen we een snelle audit van de taken en informeren we de klant daar meteen over. Als uitweg uit de situatie raden we aan om belangrijke en kritieke functionaliteit op tijd te lanceren en de rest over te laten voor post-release.
Als de klant verschillende taken uit zijn hoofd begint te bedenken, begint te fantaseren en op zijn vingers uit te leggen, dan vragen we hem om ons een paginalay-out en stroom met logica te geven die het gedrag van de hele lay-out en zijn elementen.
Voordat we een taak aannemen, moeten we ervoor zorgen dat deze functie is opgenomen in de voorwaarden van onze overeenkomst/contract. Als dit een nieuwe functie is die verder gaat dan onze initiële afspraken, dan moeten we deze functie zeker inschatten ((doorlooptijd bij benadering + 30%) x 2) en aan de klant aangeven dat het ons zoveel tijd zal kosten om het te voltooien, plus de deadline wordt verschoven voor de geschatte tijd vermenigvuldigd met twee. Laten we de taak sneller maken - geweldig, iedereen zal hier alleen maar van profiteren. Zo niet, dan zijn wij verzekerd.

c) Wat we niet accepteren in het team:

Inconsistentie, incoherentie, vergeetachtigheid
"Ontbijtvoeding". Als je de taak niet kunt voltooien, je weet niet hoe, dan moet je de teamleider hiervan onmiddellijk op de hoogte stellen en niet wachten tot het laatste.
Brovada en opscheppen van een persoon die zijn capaciteiten en professionaliteit nog niet met daden heeft bewezen. Indien bewezen, dan is het mogelijk, binnen de grenzen van het fatsoen 🙂
Fraude in al zijn verschijningsvormen. Als de taak niet is voltooid, moet u de status ervan niet wijzigen in voltooid en in de chat van de klant schrijven dat deze gereed is. De computer crashte, het systeem crashte, de hond kauwde op de laptop - dit alles is onaanvaardbaar. Als er zich een echte overmacht voordoet, moet de teamleider onmiddellijk op de hoogte worden gebracht.
Wanneer een specialist de hele tijd offline is en hem tijdens werkuren moeilijk te bereiken is.
Toxiciteit in het team is niet toegestaan! Als iemand het ergens niet mee eens is, komt iedereen bij elkaar voor een bijeenkomst en bespreekt en beslist.

En een aantal vragen/stellingen die ik soms aan mijn klant stel om alle misverstanden uit de weg te ruimen:

Wat zijn uw kwaliteitscriteria?
Hoe bepaal je of een project problemen heeft of niet?
Als u al onze aanbevelingen en adviezen over het veranderen/verbeteren van het systeem overtreedt, draagt u alleen alle risico's
Elke grote projectwijziging (bijvoorbeeld allerlei extra flow) zal leiden tot het verschijnen van bugs (die we natuurlijk zullen oplossen)
Het is onmogelijk om binnen een paar minuten te begrijpen wat voor soort probleem zich voordeed in het project, en nog meer om het daar op te lossen
We werken aan een specifieke productstroom (Tasks in Zhira - Development - Testing - Deploy). Dit betekent dat we niet op de hele stroom verzoeken en klachten in de chat kunnen reageren.
Programmeurs zijn slechts programmeurs, geen professionele testers, en kunnen de juiste kwaliteit van projecttesten niet garanderen
De verantwoordelijkheid voor de definitieve tests en acceptatie van taken op de verkoop ligt volledig bij u
Als we al een taak op ons hebben genomen, kunnen we niet meteen overschakelen naar een andere totdat we de huidige hebben voltooid (anders leidt dit tot nog meer bugs en een toename van de ontwikkeltijd)
Er zijn minder mensen in het team (vanwege vakantie of ziekte), en er is meer werk en we zullen fysiek geen tijd hebben om op alles te reageren wat je wilt
U vragen om te implementeren naar productie zonder geteste taken op de ontwikkelomgeving is alleen uw risico, niet dat van de ontwikkelaar
Wanneer u fuzzy taken instelt, zonder correcte flow, zonder ontwerplay-outs, vraagt dit veel meer inspanning en implementatietijd van ons, aangezien wij een extra hoeveelheid werk moeten doen in plaats van u
Alle taken op bugs, zonder een gedetailleerde beschrijving van hun optreden en screenshots, geven ons niet de mogelijkheid om te begrijpen wat er mis is gegaan en hoe we deze bug kunnen veroorzaken
Het project vereist voortdurende verfijning en verbeteringen om de prestaties en veiligheid te verbeteren. Daarom besteedt het team een deel van zijn tijd aan deze verbeteringen.
Vanwege het feit dat we overuren hebben (spoedeisende reparaties), moeten we deze op andere dagen compenseren

In de regel begrijpt de klant meteen dat alles niet zo eenvoudig is bij softwareontwikkeling, en verlangen alleen is duidelijk niet genoeg.

Over het algemeen is dit alles. Achter de schermen laat ik veel onderhandelingen en het eerste debuggen van alle processen achter, maar als resultaat is alles gelukt. Ik kan zeggen dat dit proces voor ons een soort “Silver Bullet” is geworden. Nieuwe mensen die naar het project kwamen, konden zich vanaf de eerste dag al direct aan het werk zetten, aangezien alle processen beschreven zijn, en de documentatie en architectuur in de vorm van diagrammen meteen een idee gaven van waar we allemaal mee bezig zijn hier.

PS Ik wil verduidelijken dat er geen projectmanager aan onze kant is. Het is aan de kant van de klant. Helemaal geen techneut. Europees project. Alle communicatie is alleen in het Engels.

Veel succes aan iedereen met jullie projecten. Burn-out niet en probeer uw processen te verbeteren.

bron in mijn blog.

Bron: www.habr.com

Organisatie van de workflow in een team op een IT-project