Ahojte priatelia. Často, najmä v outsourcingu, vidím tú istú situáciu. Nedostatok jasného pracovného procesu v tímoch na rôznych projektoch.
Najdôležitejšie je, že programátori nerozumejú, ako komunikovať so zákazníkom a medzi sebou. Ako vybudovať nepretržitý proces vývoja kvalitného produktu. Ako si naplánovať svoj pracovný deň a sprinty.
A to všetko vyústi do zmeškaných termínov, nadčasov, neustálych sporov, kto je vinník, a nespokojnosti zákazníkov — kam a ako všetko smeruje. Pomerne často to vedie k zmene programátorov, alebo celých tímov. Ztráte zákazníka, zhoršeniu reputácie a tak ďalej.
V istom čase som sa dostal na taký projekt, kde sa všetky tieto nepríjemnosti vyskytovali.
Nikto nechcel prevziať zodpovednosť za projekt (veľký servisný trhovisko), fluktuácia bola dramatická, zákazník jednoducho ničil a hneval sa. CEO sa k mne nejako priblížil a povedal, že máš potrebné skúsenosti, tak ti dávam voľnú ruku. Zober si projekt a ak sa ti to nepodarí, projekt zavrieme a všetkých vyhodíme. Ak to vyjde, bude to skvelé, potom ho vedz a rozvíjaj tak, ako považuješ za potrebné. Nakoniec som sa stal tímovým lídrom na projekte a všetko sa uložilo na moje plecia.
Prvé, čo som urobil, bolo vyvinúť pracovný proces od nuly, ktorý v tom čase zodpovedal môjmu pohľadu, a napísal som popis práce pre tím. Zavádzať ho nebolo jednoduché. Ale niekde v priebehu mesiaca sa všetko usadilo, vývojári a klient si zvykli a všetko už prebiehalo pokojne a pohodlne. Aby som tímu ukázal, že to nie je len "búrka v pohári", ale skutočné riešenie situácie, vzal som na seba maximálny objem povinností, aby som odstránil nepríjemnú rutinu z tímu.
Už uplynulo päťnásť mesiacov a projekt sa vyvíja bez nadčasov, bez „potkaních pretekov“ a rôznych stresov. Niekto zo starej tímu nechcel takto pracovať a odišiel, niekomu inému sa naopak veľmi zapáčilo, že sa objavili transparentné pravidlá. Ale nakoniec všetci, kto sú v tíme, sú veľmi motivovaní a úplne poznajú obrovský projekt, vrátane front-endu a back-endu, vrátane kódovej bázy a celej podnikovej logiky. Už to dospelo do toho, že nie sme len „veslári“, ale sami vymýšľame mnohé obchodné procesy a nové funkcie, ktoré sa podniku páčia.
Vďaka takémuto prístupu z našej strany sa zákazník rozhodol objednať od našej spoločnosti ďalší marketplace, čo nás nemôže ako tešiť.
Keďže na mojom projekte to funguje, možno to pomôže aj niekomu inému. Takže samotný proces, ktorý nám pomohol zachrániť projekt:
Proces práce tímu na projekte "Môj obľúbený projekt"
a) Interný tímový proces (medzi vývojármi)
- Všetky úlohy sú vytvorené v systéme Jira
- Každá úloha by mala byť maximálne popísaná a vykonávať striktne jeden úkon
- Akákoľvek funkcia, ak je dostatočne zložitá, sa rozdelí na množstvo drobných úloh
- Tím pracuje na funkciách ako na jednej úlohe. Najprv robíme všetci spolu jednu funkciu, odovzdávame ju na testovanie a potom prechádzame na ďalšiu.
- Každá úloha je označená, či patrí do back-endu alebo front-endu
- Existujú typy úloh a bugov. Je potrebné ich správne označiť.
- Po splnení úlohy sa prekladá do stavu revízie kódu (zároveň sa vytvára pull request na kolegu)
- Ten, kto úlohu vykonával, hneď sleduje svoj čas pre túto úlohu
- Po kontrole kódu je PR schválený a potom ten, kto úlohu vykonával, ju samostatne zlúči do hlavnej vetvy, po čom zmení jej stav na pripravenú na nasadenie na dev server.
- Všetky úlohy pripravené na nasadenie na dev server nasadzuje tímový lead (jeho zodpovednosť), niekedy aj člen tímu, ak je niečo urgentné. Po nasadení sa všetky úlohy s prípravou na nasadenie na dev prekladajú do stavu — pripravené na testovanie na dev
- Všetky úlohy testuje zákazník
- Keď zákazník otestoval úlohu na dev, prevedie ju do stavu pripraveného na nasadenie na produkciu
- Pre nasadenie na produkciu máme samostatnú vetvu, do ktorej zlúčime hlavnú vetvu iba pred nasadením
- Ak počas testovania zákazník nájde chyby, vráti úlohu na úpravy a nastaví jej stav na vrátená na úpravu. Týmto spôsobom oddelíme nové úlohy od tých, ktoré neprešli testovaním.
- Nakoniec všetky úlohy prechádzajú cestou od vytvorenia po dokončenie: 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ár testuje svoj kód samostatne, vrátane toho, ako používateľ webu. Nie je povolené zlúčiť vetvu s hlavnou, pokiaľ nie je presne známe, že kód funguje.
- Každá úloha má priority. Priority určuje buď zákazník, alebo tímový líder.
- Vývojári sa najprv zaoberajú prioritnými úlohami.
- Vývojári môžu priraďovať úlohy navzájom, ak boli nájdené rôzne chyby v systéme alebo ak sa jedna úloha skladá z práce viacerých odborníkov.
- Všetky úlohy, ktoré vytvorí zákazník, putujú k tímovému lídrovi, ktorý ich vyhodnocuje, a buď žiada zákazníka o úpravy alebo ich priraďuje niektorému z členov tímu.
- Všetky úlohy, ktoré sú pripravené na nasadenie na dev alebo prod, putujú tiež k tímovému lídrovi, ktorý sám rozhoduje, kedy a ako vykonať nasadenie. Po každom nasadení musí tímový líder (alebo člen tímu) informovať zákazníka o tom. A tiež zmeniť stavy pre úlohy na pripravené na testovanie na dev/prod.
- Každý deň o tej istej hodine (u nás je to o 12.00) konáme míting medzi všetkými členmi tímu.
- Každý na mítingu podáva správy, vrátane tímového lídra, o tom, čo robil včera, čo plánuje robiť dnes. Čo nefunguje a prečo. Takto je celá tím informovaný o tom, kto čo robí a v akom štádiu je projekt. Toto nám umožňuje predpovedať a prispôsobovať, ak je to potrebné, naše odhady a termíny.
- Na mítingu tímový líder tiež oznamuje všetky zmeny v projekte a úroveň aktuálnych chýb, ktoré neboli nájdené zákazníkom. Všetky chyby sa preberajú a priraďujú každému členovi tímu na ich vyriešenie.
- Na mítingu tímový líder priraďuje každému úlohy, pričom zohľadňuje aktuálne zaťaženie vývojárov, úroveň ich profesionálneho vzdelania, a taktiež blízkosť danej úlohy k tomu, čomu sa vývojár práve venuje.
- Na stretnutí tímový líder formuluje celkovú stratégiu architektúry a obchodnej logiky. Potom to celá tím diskutuje a rozhodne o potrebných úpravách alebo prijatí tejto stratégie.
- Každý vývojár píše kód a vytvára algoritmy samostatne v rámci jednotnej architektúry a obchodnej logiky. Každý môže vyjadriť svoju predstavu o implementácii, ale nikto nie je nútený robiť to len tak alebo inak. Každé rozhodnutie je zdôvodnené. Ak existuje lepšie riešenie, ale teraz naň nie je čas, vytvorí sa úloha v Jire na budúce prepracovanie určitej časti kódu.
- Keď vývojár prevezme úlohu, prepošle ju do stavu vývoja. Celá komunikácia ohľadom objasnenia úlohy leží na pleciach vývojára. Technické otázky môže klásť tímovému lídrovi alebo kolegom.
- Ak vývojárovi nie je jasná podstata úlohy a zákazník ju nedokáže zrozumiteľne vysvetliť, prejde k ďalšej úlohe. Aktuálnu úlohu preberá tímový líder a sám ju diskutuje so zákazníkom.
- Každý deň by mal vývojár v chate zákazníka písať o tom, na akých úlohách pracoval včera a na akých úlohách bude pracovať dnes.
- Pracovný proces prebieha podľa Scrum metodológie. Všetko je rozdelené do sprintov. Každý sprinť trvá dva týždne.
- Sprinty vytvára, napĺňa a uzatvára tímový líder.
- Ak má projekt prísne termíny, snažíme sa odhadnúť všetky úlohy. A zozbierame ich do sprintu. Ak sa zákazník pokúsi pridať ďalšie úlohy do sprintu, stanovíme priority a niektoré iné úlohy presunieme na ďalší sprinť.
b) Proces práce so zákazníkom
- Každý vývojár môže a mal by komunikovať so zákazníkom.
- Nemôžeme umožniť zákazníkovi vnucovať svoje pravidlá. Je potrebné v zdvorilej a priateľskej forme dať zákazníkovi jasne najavo, že sme odborníci vo svojom obore, a len my by sme mali organizovať pracovné procesy a zapájať do nich zákazníka.
- Ideálne je pred začatím implementácie akéhokoľvek funkčného prvku vytvoriť blokovú schému celého logického procesu pre funkciu (workflow). A poslať ju na schválenie zákazníkovi. To sa týka iba zložitých a ťažko zrozumiteľných funkcií, ako napríklad platobný systém, systém upozornení atď. To umožní presnejšie pochopenie, čo zákazník skutočne potrebuje, uchovať dokumentáciu k funkcii a tiež ochrániť seba pred tým, že zákazník v budúcnosti povie, že sme urobili niečo iné, ako si prial.
- Všetky diagramy/blokové schémy/logiky atď. uchovávame v Confluence/Jira, kde žiadame zákazníka, aby v komentároch potvrdil správnosť budúcej implementácie.
- Snažíme sa nezaťažovať zákazníka technickými podrobnosťami. Ak potrebujeme pochopiť, ako si zákazník želá, nakreslíme primitívne algoritmy vo forme blokovej schémy, ktoré zákazník môže pochopiť a sám všetko opraviť/doplniť.
- Ak zákazník nájde v projekte chybu, veľmi podrobne ho žiadame, aby ju opísal v Jira. Aké okolnosti sa udiali, kedy, akú postupnosť akcií vykonával zákazník pri testovaní. Žiadame ho, aby pripojil screenshoty.
- Snažíme sa každý deň, maximálne každý druhý deň, robiť nasadenie na dev server. Zákazník potom začne testovať funkčnosť a projekt nestoja. To tiež slúži ako ukazovateľ pre zákazníka, že projekt je v plnej vývoji a nikto mu nepredkladá rozprávky.
- Veľakrát sa stáva, že zákazník úplne nerozumie, čo vlastne potrebuje. Pretože zakladá nový podnik s ešte nepreverenými procesmi. Preto sa veľmi často stáva situácia, že vyhadzujeme celé kusy kódu a prerábame logiku aplikácie. Z toho vyplýva, že nie je nutné pokrývať všetko testami. Je zmysluplné pokryť testami iba kriticky dôležitú funkčnosť a to s výhradami.
- Sú situácie, keď tím zistí, že sa nezmestíme do termínov. Vtedy vykonáme rýchly audit úloh a ihneď informujeme zákazníka. Ako riešenie situácie navrhujeme uvádzaní do prevádzky dôležitej a kritickej funkčnosti v termíne, a ostatné nechať na post-release.
- Ak objednávateľ začne vymýšľať rôzne úlohy z hlavy, začne fantazírovať a vysvetľovať prstami, tak ho žiadame, aby nám poskytol návrh stránky a tok so logikou, ktorá by mala úplne popísať správanie celého návrhu a jeho prvkov.
- Predtým ako preberieme akúkoľvek úlohu, musíme sa uistiť, že táto funkcia bola zahrnutá v podmienkach našej zmluvy. Ak je to nová funkcia, ktorá presahuje naše pôvodné dohody, musíme ju nevyhnutne odhadnúť ((priemerný čas vykonania + 30%) x 2) a uviesť objednávateľovi, že na ňu potrebujeme toľko času, plus termín sa posunie o čas odhadu vynásobený dvoma. Ak úlohu urobíme rýchlejšie – skvele, všetci z toho len získajú. Ak nie, sme krytí.
b) Čo neprijímame v tíme:
- Nezodpovednosť, nesústredenie, zabúdanie
- „Krmienie raňajkami“. Ak nemôžeš splniť úlohu, nevieš ako, o tom je potrebné okamžite informovať tímového lídra, a nie čakať do poslednej chvíle.
- Chvástanie a chválenie od človeka, ktorý ešte nepreukázal svoje schopnosti a profesionalitu. Ak to preukázal, bere sa to v rámci slušnosti 🙂
- Podvod v akýchkoľvek jeho prejavoch. Ak úloha nie je splnená, nie je potrebné meniť jej stav na splnený a písať v chate klientovi, že je pripravená. Pokazil sa počítač, systém spadol, pes roztrhal notebook – toto je neprijateľné. Ak sa stane skutočná neočakávaná udalosť, tímový líder by mal byť okamžite informovaný.
- Keď je špecialista stále offline a je ťažké sa k nemu dostať v pracovnom čase.
- Toxickosť v tíme nie je prijateľná! Ak sa niekto s niečím nesúhlasí, všetci sa spoločne zhromaždia na meetingu a to prediskutujú a rozhodnú.
A ešte niekoľko otázok/tezí, ktoré občas kladiem svojmu objednávateľovi, aby odstránil všetky nedorozumenia:
- Aké sú vaše kritériá kvality?
- Ako určujete, či sú v projekte problémy, alebo nie?
- Porušovaním všetkých našich odporúčaní a rád na zmenu/zlepšenie systému nesiete všetky riziká iba vy.
- Akékoľvek majoritné zmeny projektu (napríklad akékoľvek extra toky) môžu viesť k možnému vzniku chýb (ktoré budeme, samozrejme, opravovať).
- Nemožno v priebehu pár minút pochopiť, aký problém sa na projekte vyskytol, a už vôbec ho hneď opraviť.
- Pracujeme podľa konkrétneho produktového toku (Úlohy v Jira — Vývoj — Testovanie — Nasadenie). To znamená, že nemôžeme reagovať na celý prúd žiadostí a sťažností v chate.
- Programátori sú programátori a nie profesionálni testeri, a nemôžu zabezpečiť primeranú kvalitu testovania projektu.
- Zodpovednosť za konečné testovanie a prijatie úloh na produkcii leží plne na vás.
- Ak sme už vzali úlohu do práce, nemôžeme sa ihneď prepnúť na iné, kým nedokončíme aktuálnu (inak to vedie k ešte väčším chybám a predlžuje čas vývoja).
- Ľudí v tíme je menej (z dôvodu dovoleniek alebo chorôb), a práce je viac, a fyzicky nestíhame reagovať na všetko, čo si prajete.
- Žiadosť z vašej strany o nasadenie na produkciu bez otestovaných úloh na dev sa týka iba vašich rizík a nie vývojárov.
- Keď stanovíte nejasné úlohy bez správneho toku, bez dizajnových makiet, vyžaduje to od nás oveľa väčšie úsilie a dlhšie lehoty realizácie, pretože namiesto vás musíme vykonávať dodatočnú prácu.
- Akékoľvek úlohy týkajúce sa chýb bez podrobného popisu ich vzniku a snímok obrazovky nám nedávajú možnosť pochopiť, čo sa pokazilo a ako simulovať túto chybu.
- Projekt si vyžaduje neustálu prácu a zlepšovanie na zvýšenie výkonnosti a bezpečnosti. Preto tím venuje čas týmto vylepšeniam.
- Z dôvodu toho, že máme prepracované hodiny (urgentné opravy), musíme ich kompenzovať v iné dni.
Zvyčajne klient okamžite chápe, že vývoj softvéru nie je tak jednoduchý, a jedného priania rozhodne nestačí.
Celkovo je to všetko. Za scénou zostáva množstvo rokovaní a počiatočné ladenie všetkých procesov, ale nakoniec sa všetko zlepšilo. Môžem povedať, že tento proces sa pre nás stal akousi „striebornou guľou“. Noví ľudia, ktorí prišli do projektu, sa mohli už od prvého dňa zapojiť do práce, pretože všetky procesy sú popísané a dokumentácia a architektúra vo forme diagramov okamžite poskytovali predstavu o tom, čím sa tu všetci zaoberáme.
P. S. Chcem objasniť, že na našej strane nie je projektový manažér. Ten je na strane zákazníka. Nie je technický. Projekt je európsky. Všetka komunikácia je len v angličtine.
Všetkým prajem veľa šťastia na projektoch. Nenechajte sa vyhorieť a snažte sa zlepšovať svoje procesy.
Zdrojový kód je v mojom .
Zdroj: habr.com
