Ahoj přátelé. Často, zejména v outsourcingu, vidím stejný obraz. Chybějící jasný pracovní proces v týmech na různých projektech.
Nejdůležitější je, že programátoři nerozumí, jak komunikovat se zákazníkem a mezi sebou. Jak vybudovat nepřetržitý proces vývoje kvalitního produktu. Jak si naplánovat svůj pracovní den a sprinty.
A to všechno nakonec vyústit ve zpožděné deadliny, přesčasy, neustálé hádky o to, kdo je za co zodpovědný, a nespokojenost zákazníků — jakým směrem se vše ubírá. Poměrně často to vede ke střídání programátorů, nebo i celých týmů. Ztrátě zákazníka, zhoršení pověsti a tak dále.
Kdysi jsem se dostal na takový projekt, kde byly všechny tyto problémy.
Nikdo nechtěl převzít odpovědnost za projekt (velký servisní marketplace), fluktuace byla strašná, zákazník neustále zuřil. Ředitel mi jednou přišel a řekl, že máš potřebné zkušenosti, tak tady máš projekt. Když to pokazíš, projekt zavřeme a všechny vyhodíme. Pokud to vyjde, bude to skvělé, pak ho řídíš a rozvíjíš, jak uznáš za vhodné. Nakonec jsem se stal vedoucím týmu na projektu a všechno leželo na mých bedrech.
První, co jsem udělal, bylo, že jsem vyvinul pracovní proces od nuly, který v té době odpovídal mému vidění, a napsal jsem popis práce pro tým. Implementace nebyla snadná. Ale během asi měsíce se všechno usadilo, vývojáři a klient si zvykli a všechno začalo plynout klidně a pohodlně. Abych ukázal týmu, že to není jen "bouře ve sklenici vody", ale skutečné východisko ze situace, vzal jsem na sebe maximální objem povinností a uvolnil tým od nepříjemné rutiny.
Už uběhlo jeden a půl roku a projekt se vyvíjí bez přesčasů, bez "krysích závodů" a různých stresů. Někdo ve starém týmu nechtěl takto pracovat a odešel, někdo naopak byl rád, že se objevila jasná pravidla. Ale nakonec všichni, kdo jsou v týmu, jsou velmi motivováni a znají obrovský projekt dokonale, zahrnující jak frontend, tak backend. Včetně kódové základny a celé obchodní logiky. Už jsme dospěli až k tomu, že nejsme jen "veslaři", ale sami vymýšlíme mnohé obchodní procesy a nové funkce, které se byznysu líbí.
Díky našemu přístupu se zákazník rozhodl objednat u naší společnosti další tržiště, což nás velmi potěšilo.
Protože to u mého projektu funguje, může to být užitečné i někomu jinému. Takže tady je proces, který nám pomohl zachránit projekt:
Pracovní proces týmu na projektu „Můj oblíbený projekt“
a) Interní týmový proces (mezi vývojáři)
- Všechny úkoly jsou vytvářeny v systému Jira
- Každý úkol by měl být co nejlépe popsán a měl by vykonávat striktně jednu činnost
- Každá funkce, pokud je dostatečně složitá, se rozděluje na mnoho malých úkolů
- Tým pracuje na funkcích jako na jednom úkolu. Nejprve společně vytvoříme jednu funkci, předáme ji k testování, a pak se zaměříme na další.
- Každý úkol je označen, zda patří k backendu nebo frontendu
- Existují typy úkolů a chyb. Je nutné je správně uvádět.
- Po dokončení úkolu je převeden do stavu recenze kódu (přitom se vytváří pull request pro kolegu)
- Osoba, která úkol vykonávala, hned sleduje svůj čas pro tento úkol
- Po kontrole kódu je PR schválen a pak ten, kdo úkol vykonával, sám provede jeho sloučení do hlavní větve, a poté změní jeho stav na připraveno k nasazení na dev server.
- Všechny úkoly připravené k nasazení na dev server jsou nasazovány týmovým lídrem (jeho odpovědnost), občas členem týmu, pokud je něco naléhavého. Po nasazení jsou všechny úkoly s připraveno k nasazení na dev převedeny do stavu – připraveno k testování na devu
- Všechny úkoly testuje zákazník
- Když zákazník otestuje úkol na devu, převede jej do stavu připraveno k nasazení na produkci
- Pro nasazení na produkci máme oddělenou větev, do které slučujeme hlavní větev pouze před nasazením
- Pokud zákazník během testování najde chyby, vrátí úkol k dopracování, přičemž mu nastaví stav vráceno k dopracování. Tím oddělujeme nové úkoly od těch, které neprošly testováním
- Nakonec všechny úkoly projdou cestu od vytvoření po dokončení: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Každý vývojář testuje svůj kód samostatně, včetně testování jako uživatel webu. Sloučení větve s hlavní je zakázáno, dokud není známo, že kód funguje.
- Každému úkolu jsou přiřazeny priority. Tyto priority stanovuje buď zadavatel, nebo týmový vedoucí.
- Vývojáři nejprve plní úkoly s nejvyššími prioritami.
- Vývojáři si mohou přiřazovat úkoly navzájem, pokud byly nalezeny různé chyby v systému, nebo pokud je jeden úkol rozdělen mezi několik specialistů.
- Všechny úkoly, které vytvoří zadavatel, se dostávají k týmovému vedoucímu, který je posoudí a buď požádá zadavatele o úpravy, nebo je přidělí jednomu z členů týmu.
- Všechny úkoly, které jsou připraveny k nasazení na dev nebo prod, se také dostávají k týmovému vedoucímu, který samostatně určuje, kdy a jak provést nasazení. Po každém nasazení musí týmový vedoucí (nebo člen týmu) informovat zadavatele o tom, a také změnit statusy úkolů na připravené k testování na dev/prod.
- Každý den ve stejnou dobu (u nás v 12:00) konáme schůzku všech členů týmu.
- Na schůzce se k reportování zapojují všichni, včetně týmového vedoucího, a oznamují, co dělali včera, co plánují na dnes, co se nedaří a proč. Tímto způsobem má celý tým přehled o tom, čím se kdo zabývá a v jaké fázi se projekt nachází. To nám umožňuje prognózovat a, pokud je to potřeba, upravit naše odhady a termíny.
- Na schůzce týmový vedoucí také oznamuje všechny změny v projektu a úroveň aktuálních chyb, které nebyly nalezeny zadavatelem. Všechny chyby se probírají a přiřazují každému členu týmu k vyřešení.
- Na schůzce týmový vedoucí přiřazuje každému úkoly, berouc v úvahu aktuální vytíženost vývojářů, úroveň jejich odborné připravenosti a také přihlíží k blízkosti daného úkolu k tomu, čemu se vývojář aktuálně věnuje.
- Na schůzce týmový vedoucí vypracovává celkovou strategii architektury a obchodní logiky. Poté to celý tým diskutuje a přijímá rozhodnutí o provedení úprav nebo přijetí této strategie.
- Každý vývojář píše kód a vytváří algoritmy sám v rámci jedné architektury a obchodní logiky. Každý může vyjádřit svou vizi realizace, ale nikdo není nucen to dělat jen tak, nebo jinak. Každé rozhodnutí má své zdůvodnění. Pokud existuje lepší řešení, ale nyní na něj není čas, vytvoří se úkol v JIRA na budoucí refaktoring určité části kódu.
- Když vývojář převezme úkol, převede ho do stavu vývoje. Veškerá komunikace ohledně upřesnění úkolu s klientem leží na bedrech vývojáře. Technické dotazy lze směřovat k týmovému vedoucímu nebo kolegům.
- Pokud vývojář nerozumí podstatě úkolu a klient jej nedokázal srozumitelně vysvětlit, přechází k další úloze. Současný úkol převezme týmový vedoucí a s klientem jej sám projednává.
- Každý den by měl vývojář v chatu s klientem psát o úkolech, na nichž pracoval včera, a na kterých bude pracovat dnes.
- Pracovní proces probíhá podle scrumu. Všechno je rozděleno do sprintů. Každý sprint trvá dva týdny.
- Sprinty vytváří, naplňuje a uzavírá týmový vedoucí.
- Pokud projekt má přísné termíny, snažíme se odhadnout všechny úkoly a sestavit z nich sprint. Pokud se klient snaží do sprintu přidat další úkoly, stanovujeme priority a některé úkoly přesouváme na další sprint.
b) Proces práce s klientem
- Každý vývojář může a měl by komunikovat s klientem.
- Není možné klientovi dovolovat vnucovat svá pravidla hry. Je nutné v zdvořilé a přátelské formě dát klientovi najevo, že jsme odborníci ve svém oboru, a jen my bychom měli řídit pracovní procesy a zapojovat do nich klienta.
- Je nutné, ideálně před zahájením realizace jakéhokoliv funkčního prvku, vytvořit blokové schéma celého logického procesu pro funkci (workflow). A poslat ho ke schválení klientovi. To se týká pouze složitého a ne zřejmého funkčního prvku, například platebního systému, systému notifikací atd. To umožní lépe pochopit, co přesně klient potřebuje, zachovat dokumentaci k funkci, a také se chránit před tím, že klient může v budoucnu říct, že jsme udělali něco jiného, než co žádal.
- Všechny diagramy/flowcharty/logiku atd. ukládáme do Confluence/Jira, kde žádáme zákazníka, aby v komentářích potvrdil správnost budoucí implementace.
- Snažíme se nezatěžovat zákazníka technickými detaily. Pokud potřebujeme pochopit, co přesně zákazník chce, nakreslíme primitivní algoritmy ve formě flowchartu, které může zákazník pochopit a případně opravit/doklepat sám.
- Pokud zákazník najde chybu v projektu, žádáme ho, aby ji co nejpodrobněji popsal v Jira. Za jakých okolností k ní došlo, kdy, jaký sled akcí zákazník prováděl při testování. Žádáme o připojení screenshotů.
- Snažíme se každý den, maximálně každé dva dny provádět nasazení na vývojový server. Zákazník pak začíná testovat funkčnost a projekt nezůstává nečinný. To je zároveň značkou pro zákazníka, že projekt je v plném vývoji a nikdo mu nevypráví pohádky.
- Velmi často se stává, že zákazník úplně nerozumí, co vlastně potřebuje. Vytváří nový byznys s ještě nefungujícími procesy. Proto se často stává, že vyhazujeme celé kusy kódu do koše a přepracováváme logiku aplikace. Z toho vyplývá, že není nutné pokrývat testy vše. Smysl má pokrývat testy pouze kriticky důležitou funkčnost a to s výhradami.
- Někdy se stává, že tým chápe, že se nevejdeme do termínů. Poté provedeme rychlý audit úkolů a ihned o tom informujeme zákazníka. Jako východisko z situace nabízíme spuštění důležité a kritické funkčnosti v termínu a zbytek nechat na post-release.
- Pokud zákazník začne vymýšlet různé úkoly z hlavy, začne fantazírovat a vysvětlovat to na prstech, žádáme ho, aby nám poskytl maketu stránky a flow s logikou, která by měla úplně popsat chování celé makety a jejích prvků.
- Než se pustíme do jakéhokoli úkolu, musíme se ujistit, že tato funkce byla součástí podmínek naší smlouvy. Pokud jde o novou funkci, která překračuje naše původní dohody, musíme ji určitě odhadnout ((přibližná doba provedení + 30%) x 2) a informovat zákazníka, že na ni budeme potřebovat tolik a tolik času, navíc se termín posune o dobu odhadu vynásobenou dvěma. Pokud úkol dokončíme rychleji — skvělé, všichni z toho budou mít prospěch. Pokud ne, máme rezervu.
v) Co v týmu nepřijímáme:
- Nezodpovědnost, nepořádnost, zapomnětlivost
- Odmítání odpovědnosti. Pokud nemůžete úkol splnit, nebo nevíte jak, musíte okamžitě informovat týmového lídra, a ne čekat na poslední chvíli.
- Chlubením se od osoby, která ještě nedokázala své schopnosti a profesionalitu skutky. Pokud to prokázala, je to v rámci slušnosti přijatelné 🙂
- Podvod v jakékoli podobě. Pokud úkol není splněn, není vhodné měnit jeho stav na splněný a psát v chatu zákazníka, že je hotový. Počítač se rozbil, systém selhal, pes rozcupoval notebook — to všechno je nepřijatelné. Pokud dojde k reálné mimořádné situaci, musí být týmový lídr okamžitě informován.
- Když je specialista neustále offline a těžko ho kontaktovat během pracovní doby.
- Toxičnost v týmu není povolena! Pokud s něčím někdo nesouhlasí, všichni se sejdou na schůzce a toto téma prodiskutují a vyřeší.
A také několik otázek/thesí, které občas pokládám svému zákazníkovi, abych odstranil všechna nedorozumění:
- Jaké máte kritéria kvality?
- Jak určujete, zda projekt má nebo nemá problémy?
- Pokud nedodržujete všechna naše doporučení a rady ohledně změn/vylepšení systému, veškeré riziko nese jen vy.
- Jakékoli majoritní změny v projektu (například různé extra toky) mohou vést k možnému vzniku chyb (které samozřejmě budeme opravovat).
- Není možné během několika minut pochopit, jaký problém se na projektu objevil, a už vůbec ne hned jej opravit.
- Pracujeme podle konkrétního produktu flow (Úkoly v JIRA — Vývoj — Testování — Nasazení). To znamená, že nemůžeme reagovat na celý proud žádostí a stížností v chatu.
- Programátoři jsou programátoři, nikoli profesionální testovací inženýři, a nemohou zajistit odpovídající kvalitu testování projektu.
- Odpovědnost za konečné testování a převzetí úkolů do produkce leží plně na vás.
- Pokud jsme již vzali úkol do práce, nemůžeme se hned přepnout na jiné, dokud nedokončíme aktuální (jinak to vede k ještě větším chybám a prodloužení doby vývoje).
- Lidé v týmu se zmenšili (kvůli dovoleným nebo nemocem), ale práce je více, a fyzicky nemůžeme reagovat na vše, co potřebujete.
- Vaše žádost o nasazení do produkce bez otestovaných úkolů na develu je pouze vaše riziko, nikoli riziko vývojářů.
- Když zadáte nejasné úkoly, bez správného workflow a návrhů, vyžaduje to od nás mnohem více úsilí a času na realizaci, protože namísto vás musíme vykonat další objem práce.
- Jakékoli úkoly týkající se chyb, bez podrobného popisu jejich vzniku a screenshotů, nám nedávají možnost pochopit, co se pokazilo, a jak tuto chybu simulovat.
- Projekt vyžaduje neustálé úpravy a zlepšení pro zvýšení výkonu a bezpečnosti. Proto tým tráví část svého času na těchto vylepšeních.
- Vzhledem k tomu, že máme občas přesčasy (naléhavé opravy), musíme je kompenzovat v jiné dny.
Obvykle zákazník okamžitě chápe, že vývoj softwaru není tak jednoduchý a jedno přání zde zcela jistě nestačí.
To je vše. Za scénou zůstává řada jednání a počáteční ladění všech procesů, ale nakonec se všechno zlepšilo. Mohu říci, že tento proces se stal pro nás jakousi 'stříbrnou kulkou'. Noví lidé, kteří se přišli do projektu zapojit, mohli začít pracovat hned od prvního dne, protože všechny procesy byly popsány a dokumentace a architektura ve formě diagramů dávaly okamžitý přehled o tom, co všechno děláme.
P. S. Chci upřesnit, že na naší straně není projektový manažer. Je na straně zákazníka. Není to technik. Projekt je evropský. Celá komunikace probíhá pouze v angličtině.
Všem přeji hodně štěstí v projektech. Nevyhořívejte a snažte se zlepšovat své procesy.
Zdrojový kód mám v sobě. .
Zdroj: habr.com
