Dobrý deň, priatelia. Pomerne často, najmä pri outsourcingu, vidím rovnaký obraz. Chýba jasný pracovný postup v tímoch na rôznych projektoch.
Najdôležitejšie je, že programátori nerozumejú tomu, ako komunikovať so zákazníkom a medzi sebou navzájom. Ako vybudovať nepretržitý proces vývoja kvalitného produktu. Ako si naplánovať pracovný deň a šprinty.
A to všetko má v konečnom dôsledku za následok zmeškané termíny, nadčasy, neustále zisťovanie, kto za to môže, a nespokojnosť zákazníkov s tým, kde a ako sa všetko hýbe. Dosť často to všetko vedie k výmene programátorov, či dokonca celých tímov. Strata zákazníka, zhoršenie dobrého mena a pod.
Raz som práve skončil na takom projekte, kde boli všetky tieto slasti.
Nikto nechcel prevziať zodpovednosť za projekt (veľké trhovisko služieb), obrat bol hrozný, zákazník bol jednoducho roztrhaný a frustrovaný. Raz za mnou prišiel generálny riaditeľ a povedal, že máte potrebné skúsenosti, takže tu máte karty vo vašich rukách. Vezmite si projekt pre seba. Ak to pokazíte, projekt uzavrieme a všetkých vyhodíme. Vyjde to, bude to cool, potom to veďte a rozvíjajte, ako uznáte za vhodné. V dôsledku toho som sa stal vedúcim tímu projektu a všetko padlo na moje plecia.
Prvá vec, ktorú som urobil, bolo vytvoriť pracovný postup od začiatku, ktorý bol v súlade s mojou víziou v tom čase, a napísal som popis práce pre tím. Realizácia nebola jednoduchá. Zhruba do mesiaca sa ale všetko ustálilo, vývojári aj klient si zvykli a všetko prebehlo v tichosti a v pohode. Aby som tímu ukázal, že nejde len o „búrku v šálke“, ale o skutočné východisko zo situácie, zobral som na seba maximum zodpovednosti a odstránil z tímu nepríjemnú rutinu.
Už uplynul rok a pol a projekt sa rozvíja bez nadčasov, bez „potkaních pretekov“ a všetkých druhov stresu. Niektorým ľuďom v starom tíme sa takto pracovať nechcelo a odišli, iní sa naopak veľmi potešili, že sa objavili transparentné pravidlá. Ale v konečnom dôsledku sú všetci v tíme veľmi motivovaní a poznajú obrovský projekt naplno, vrátane front-endu aj back-endu. Vrátane základne kódu a celej obchodnej logiky. Dospelo to dokonca do bodu, keď už nie sme len „veslári“, ale sami prichádzame s mnohými obchodnými procesmi a novými funkciami, ktoré sa podniku páčia.
Vďaka tomuto prístupu z našej strany sa zákazník rozhodol objednať si ďalšie trhovisko od našej spoločnosti, čo je dobrá správa.
Keďže toto funguje na mojom projekte, možno to tiež niekomu pomôže. Takže samotný proces, ktorý nám pomohol zachrániť projekt:
Proces tímovej práce na projekte „Môj obľúbený projekt“
a) Interný tímový proces (medzi vývojármi)
- Všetky problémy sú vytvorené v systéme Jira
- Každá úloha by mala byť čo najviac opísaná a mala by sa vykonávať iba jedna akcia
- Akákoľvek funkcia, ak je dostatočne zložitá, je rozdelená do mnohých malých úloh
- Tím pracuje na funkciách ako na jednej úlohe. Najprv všetci spoločne pracujeme na jednej funkcii, pošleme ju na testovanie a potom vezmeme ďalšiu.
- Každá úloha je označená pre backend alebo frontend
- Existujú typy úloh a chýb. Musíte ich správne uviesť.
- Po dokončení úlohy sa úloha prenesie do stavu kontroly kódu (v tomto prípade sa vytvorí požiadavka na stiahnutie pre kolegu)
- Osoba, ktorá splnila úlohu, okamžite sleduje svoj čas na túto úlohu.
- Po skontrolovaní kódu PR schváli a potom ten, kto túto úlohu vykonal nezávisle, ju zlúči do hlavnej vetvy, po ktorej zmení jej stav na pripravený na nasadenie na dev server.
- Všetky úlohy pripravené na nasadenie na dev server vykonáva vedúci tímu (jeho oblasť zodpovednosti), niekedy člen tímu, ak je niečo naliehavé. Po nasadení sa všetky úlohy od pripravenosti na nasadenie po dev prenesú do stavu – pripravené na testovanie na dev
- Všetky úlohy sú testované zákazníkom
- Keď zákazník otestuje úlohu na vývojárovi, prenesie ju do stavu pripraveného na nasadenie do produkcie
- Pre nasadenie do produkcie máme samostatnú pobočku, kde master zlúčime až pred nasadením
- Ak počas testovania zákazník nájde chyby, vráti úlohu na revíziu, pričom jej stav nastaví ako vrátená na revíziu. Takto oddelíme nové úlohy od tých, ktoré neprešli testovaním.
- Výsledkom je, že všetky úlohy idú od vytvorenia až po dokončenie: Úloha → Vo vývoji → Kontrola kódu → Pripravené nasadenie do vývojára → Kontrola kvality vo vývoji → (Návrat k vývoju) → Pripravené nasadenie do výroby → Kontrola kvality vo verzii → Hotovo
- Každý vývojár testuje svoj kód nezávisle, a to aj ako používateľ stránky. Nie je dovolené zlúčiť vetvu do hlavnej, pokiaľ nie je isté, že kód funguje.
- Každá úloha má priority. Priority určuje zákazník alebo vedúci tímu.
- Vývojári najskôr dokončia prioritné úlohy.
- Vývojári si môžu navzájom prideľovať úlohy, ak sa v systéme našli rôzne chyby alebo jedna úloha pozostáva z práce viacerých špecialistov.
- Všetky úlohy, ktoré zákazník vytvorí, idú vedúcemu tímu, ktorý ich vyhodnotí a buď požiada zákazníka, aby ich upravil, alebo ich pridelí jednému z členov tímu.
- Všetky úlohy, ktoré sú pripravené na nasadenie do vývoja alebo výroby, prechádzajú aj na vedúceho tímu, ktorý nezávisle určuje, kedy a ako nasadenie vykonať. Po každom nasadení o tom musí vedúci tímu (alebo člen tímu) informovať zákazníka. A tiež zmeniť stavy úloh na pripravené na testovanie pre dev/cont.
- Každý deň v rovnakom čase (u nás je to o 12.00) organizujeme stretnutie všetkých členov tímu
- Všetci na stretnutí, vrátane vedúceho tímu, referujú o tom, čo robili včera a čo plánujú robiť dnes. Čo nefunguje a prečo. Týmto spôsobom si celý tím uvedomuje, kto čo robí a v akom štádiu sa projekt nachádza. To nám dáva možnosť predvídať a v prípade potreby upraviť naše odhady a termíny.
- Vedúci tímu na stretnutí hovorí aj o všetkých zmenách v projekte a miere aktuálnych chýb, ktoré zákazník nenašiel. Všetky chyby sú vyriešené a priradené každému členovi tímu, aby ich vyriešil.
- Na stretnutí vedúci tímu prideľuje úlohy každému človeku, pričom zohľadňuje aktuálne pracovné vyťaženie vývojárov, úroveň ich odbornej prípravy a tiež berie do úvahy blízkosť konkrétnej úlohy k tomu, čo vývojár momentálne robí.
- Na stretnutí vedúci tímu vypracuje všeobecnú stratégiu pre architektúru a obchodnú logiku. Potom o tom celý tím diskutuje a rozhodne sa vykonať úpravy alebo prijať túto stratégiu.
- Každý vývojár píše kód a vytvára algoritmy nezávisle v rámci jedinej architektúry a obchodnej logiky. Každý môže vyjadriť svoju predstavu o realizácii, ale nikto nikoho nenúti robiť to takto a nie inak. Každé rozhodnutie je opodstatnené. Ak existuje lepšie riešenie, ale teraz naň nie je čas, tak v tuku vzniká úloha na budúce refaktorovanie určitej časti kódu.
- Keď vývojár prevezme úlohu, prenesie ju do stavu vývoja. Všetka komunikácia ohľadom vyjasnenia úlohy so zákazníkom padá na plecia developera. Technické otázky možno položiť vedúcemu tímu alebo kolegom.
- Ak vývojár nerozumie podstate úlohy a zákazník ju nedokázal jasne vysvetliť, pokračuje k ďalšej úlohe. Vedúci tímu vezme ten aktuálny a prediskutuje ho so zákazníkom.
- Každý deň by mal vývojár písať do chatu klienta o tom, na akých úlohách pracoval včera a na ktorých úlohách bude pracovať dnes
- Pracovný proces prebieha podľa Scrumu. Všetko je rozdelené do šprintov. Každý šprint trvá dva týždne.
- Šprinty vytvára, vypĺňa a uzatvára vedúci tímu.
- Ak má projekt prísne termíny, tak sa snažíme približne odhadnúť všetky úlohy. A dali sme ich dokopy do šprintu. Ak sa zákazník pokúsi pridať ďalšie úlohy do sprintu, potom určíme priority a presunieme niektoré ďalšie úlohy do ďalšieho sprintu.
b) Proces práce so zákazníkom
- Každý developer môže a mal by komunikovať so zákazníkom
- Zákazník nemôže mať možnosť vnucovať si vlastné pravidlá hry. Zákazníkovi je potrebné slušne a priateľsky dať najavo, že sme špecialisti vo svojom odbore a len my musíme budovať pracovné procesy a zapájať do nich zákazníka
- V ideálnom prípade je potrebné pred začatím implementácie akejkoľvek funkcionality vytvoriť vývojový diagram celého logického procesu funkcie (workflow). A odošlite ho zákazníkovi na potvrdenie. Týka sa to iba zložitých a nie zrejmých funkcií, napríklad platobného systému, systému upozornení atď. Umožní nám to presnejšie pochopiť, čo presne zákazník potrebuje, uložiť dokumentáciu k funkcii a tiež sa poistiť proti tomu, že zákazník môže v budúcnosti povedať, že sme neurobili, čo žiadal.
- Všetky diagramy/vývojové diagramy/logika atď. Ukladáme do Confluence/Fat, kde prosíme zákazníka o potvrdenie správnosti budúcej implementácie v komentároch.
- Snažíme sa zákazníka nezaťažovať technickými detailmi. Ak potrebujeme porozumieť tomu, ako to zákazník chce, potom nakreslíme primitívne algoritmy vo forme vývojového diagramu, ktorý zákazník pochopí a všetko sám opraví/upraví.
- Ak zákazník nájde chybu v projekte, potom vás žiadame, aby ste ju veľmi podrobne popísali v Zhire. Za akých okolností k nemu došlo, kedy, akú postupnosť úkonov vykonal zákazník počas testovania. Pripojte snímky obrazovky.
- Snažíme sa každý deň, maximálne každý druhý deň, nasadiť na dev server. Zákazník potom začne testovať funkčnosť a projekt nezostane nečinný. To je zároveň pre zákazníka značka, že projekt je v plnom rozpracovaní a nikto mu nehovorí rozprávky.
- Často sa stáva, že zákazník úplne nerozumie tomu, čo potrebuje. Pretože pre seba vytvára nový biznis s procesmi, ktoré ešte nie sú zavedené. Veľmi častou situáciou preto je, že celé kusy kódu vyhodíme do koša a prerobíme logiku aplikácie. Z toho vyplýva, že testami by ste nemali pokrývať úplne všetko. Má zmysel pokryť testami iba kritickú funkčnosť a potom iba s výhradami.
- Sú situácie, keď si tím uvedomí, že neplníme termíny. Následne vykonáme rýchly audit úloh a okamžite o tom informujeme zákazníka. Ako východisko zo situácie odporúčame spustiť dôležité a kritické funkcie včas a zvyšok ponechať na po vydaní.
- Ak zákazník začne vymýšľať rôzne úlohy z hlavy, začne fantazírovať a vysvetľovať prstami, potom ho požiadame, aby nám poskytol rozloženie stránky a tok s logikou, ktorá by mala plne vystihovať správanie celého rozloženia a jeho prvky.
- Pred prijatím akejkoľvek úlohy sa musíme uistiť, že táto funkcia bola zahrnutá v podmienkach našej dohody/zmluvy. Ak ide o novú funkciu, ktorá presahuje rámec našich pôvodných zmlúv, musíme túto funkciu oceniť ((odhadovaný čas dokončenia + 30 %) x 2) a oznámiť zákazníkovi, že jej dokončenie nám zaberie toľko času, plus termín sa posúva o odhadovaný čas vynásobený dvomi. Urobme úlohu rýchlejšie – skvelé, každý z toho bude mať úžitok. Ak nie, potom sme pre vás pripravení.
c) Čo v tíme neakceptujeme:
- Nezáväznosť, nedostatok vyrovnanosti, zábudlivosť
- "Kŕmenie raňajok." Ak nemôžete dokončiť úlohu a neviete ako, musíte o tom okamžite informovať vedúceho tímu a nečakať na poslednú chvíľu.
- Obočie a chvály od osoby, ktorá ešte nepreukázala svoje schopnosti a profesionalitu. Ak je to dokázané, tak je to možné, v rámci slušnosti :)
- Klamanie vo všetkých jeho podobách. Ak úloha nie je dokončená, nemali by ste meniť jej stav na dokončený a do chatu klienta napísať, že je pripravená. Počítač sa pokazil, systém havaroval, pes žuval notebook - to všetko je neprijateľné. Ak dôjde k skutočnej udalosti vyššej moci, musí byť o tom okamžite informovaný vedúci tímu.
- Keď je špecialista neustále offline a počas pracovnej doby je ťažké ho zastihnúť.
- Toxicita v tíme nie je povolená! Ak niekto s niečím nesúhlasí, tak sa všetci zídu na mítingu a diskutujú a rozhodujú o tom.
A množstvo otázok/téz, ktoré občas požiadam svojho zákazníka, aby objasnil všetky nedorozumenia:
- Aké sú vaše kritériá kvality?
- Ako zistíte, či má projekt problémy alebo nie?
- Porušením všetkých našich odporúčaní a rád na zmenu/vylepšenie systému nesiete všetky riziká len vy
- Akékoľvek veľké zmeny v projekte (napríklad všetky druhy extra toku) povedú k možnému výskytu chýb (ktoré samozrejme opravíme)
- Nie je možné v priebehu niekoľkých minút pochopiť, aký problém sa na projekte vyskytol, tým menej ho okamžite opraviť
- Pracujeme na špecifickom toku produktov (Úlohy v Zhire - Vývoj - Testovanie - Nasadenie). To znamená, že nemôžeme reagovať na celý tok žiadostí a sťažností v chate.
- Programátori sú programátori, nie profesionálni testeri a nemôžu zabezpečiť správnu kvalitu testovania projektov
- Zodpovednosť za záverečné testovanie a akceptovanie výrobných úloh leží výlučne na vás
- Ak sme už prevzali úlohu, nemôžeme okamžite prejsť na iné, kým nedokončíme aktuálnu (inak to vedie k ešte väčšiemu počtu chýb a predĺženiu času vývoja)
- V tíme je menej ľudí (kvôli dovolenkám alebo chorobám), ale práce je viac a fyzicky nestihneme odpovedať na všetko, čo chcete
- Žiadame vás, aby ste vykonali nasadenie do produkcie bez testovaných úloh na vývojárovi - je to len vaše riziko, nie vývojári
- Keď zadávate nejasné úlohy, bez správneho postupu, bez návrhových rozložení, vyžaduje si to od nás oveľa viac úsilia a času na implementáciu, pretože musíme za vás urobiť ďalšie množstvo práce
- Akékoľvek úlohy týkajúce sa chýb bez podrobného popisu ich výskytu a snímok obrazovky nám nedávajú príležitosť pochopiť, čo sa pokazilo a ako môžeme túto chybu opraviť
- Projekt si vyžaduje neustále zdokonaľovanie a zlepšovanie na zlepšenie výkonu a bezpečnosti. Preto tím trávi časť svojho času týmito vylepšeniami
- Vzhľadom na to, že máme hodinové nadčasy (urgentné opravy), musíme ich kompenzovať v iné dni
Zákazník spravidla okamžite pochopí, že pri vývoji softvéru nie je všetko také jednoduché a samotná túžba zjavne nestačí.
Vo všeobecnosti je to všetko. Nechávam v zákulisí veľa rokovaní a prvotného odladenia všetkých procesov, no vo výsledku všetko klaplo. Môžem povedať, že tento proces sa pre nás stal akousi „striebornou guľkou“. Noví ľudia, ktorí prišli do projektu, sa mohli okamžite zapojiť do práce od prvého dňa, pretože všetky procesy boli popísané a dokumentácia a architektúra vo forme diagramov okamžite poskytla predstavu o tom, čo sme tu všetci robili.
PS Chcel by som objasniť, že na našej strane nie je žiadny projektový manažér. Je to na strane zákazníka. Vôbec nie technik. európsky projekt. Všetka komunikácia prebieha len v angličtine.
Veľa šťastia všetkým vo vašich projektoch. Nevyhorieť a snažiť sa zlepšiť svoje procesy.
Zdroj v mojom .
Zdroj: hab.com