Článok bude o nazretí do zákulisia jednej z časti WebSupportu. Akým spôsobom pracuje náš development. Vo svojej práci najčastejšie využíva agilný spôsob vývoja s metodikou SCRUM. Konkrétne tomuto procesu sa budeme ďalej v článku venovať
Celý kalendárny rok je rozdelený na iterácie – 2 týždňovky. Zároveň sú developeri rozdelení do vývojových teamov. Každý projekt, update, bugfix je na tieto iterácie naplánovaný a priradený teamu. Jednotlivé teamy majú svoju kapacitu, kapacita vyplýva zo súčtu úväzkov jednotlivých developerov. Zloženie teamov sa pravidelne mení.
Každá iterácia má taktiež svoje etapy a rozdelenie. Najdôležitejšie sú: plánovací meeting, denné meetingy, demo meeting a freeday. Tu je znázornený priebeh vývoja jednej iterácie:
Klient dodá kompletnú špecifikáciu prípadne ju s ním vypracujeme. Následne rozdelíme celý projekt na backlogy.
Backlog je logický celok, ktorý vyplýva zo špecifikácie. Napr. pri vytváraní blogovacieho portálu, by bol jeden z backlogov pridávanie a manažovanie článkov, druhý by mohol byť pridávanie a manažovanie komentárov.
Jednotlivým backlogom sa určí odhadovaný čas vývoja, priorita a priradia sa do iterácií. Súčet odhadovaných časov pre backlogy nemôže presahovať kapacitu teamu. Na začiatku každej iterácie je plánovací meeting.
Plánovací meeting
Pozostáva z predstavenia a oboznámenia teamu, rozplánovania celej iterácie. Zúčastňujú sa ho všetci programátori, ktorí budú na danej iterácii pracovať.
Spoločnými silami sa každý backlog určený pre iteráciu rozdelí na menšie úlohy (tasky). Tieto tasky už interpretujú prácu developera. Čas strávený na splnení daného tasku by nemal presiahnuť 16 hodín. Pokiaľ je daný task náročnejší je potrebné ho rozdeliť na viac taskov. Tak isto je potrebné dohodnúť sa, kedy budú denné meetingy počas danej iterácie.
Pri rozdelovaní backlogu na menšie tasky má každý priestor vyjadriť sa a je to priam žiadúce. Každý task sa zapisuje spolu so všetkými pripomienkami a dodatočnými informáciami. Po spísaní všetkých taskov sa určí postupnosť, resp. priorita.
Po tom, ako sú spísané všetky úlohy nasleduje časové ohodnotenie daného tasku. Každý task zahrňuje aj dokumentáciu k danej funkcionalite a otestovanie. Členovia teamu májú kartičky, ktoré obsahujú číslo v hodinách. Tento postup sa nazýva plánovací poker.
Každý člen teamu si premyslí, koľko bude trvať vypracovanie daného tasku a vyberie príslušnú hodnotu na kartičke, avšak neukazuje ju ostatným kolegom. Po tom ako sú všetci rozhodnutí pre správnu hodnotu sú vyzvaní, aby ukázali svoje kartičky.
Každý musí následne vysvetliť prečo zvolil danú hodnotu. Všetky dôvody sa zapisujú do poznámky k danému tasku. Ohodnocovanie tasku prebieha dovtedy, pokiaľ sa všetci nezhodnú na jednej časovej hodnote. Výsledná časová hodnota sa zapíše k danému tasku. Postup ohodnocovania úlohy prebieha identicky pre každý task.
Denný meeting
Každý člen teamu je povinný zúčastniť sa ho. Prípadnú neprítomnosť musí riešiť dostatočne včas. Každý z členov teamu musí odpovedať na otázky:
- Čo spravil
- Čo bude robiť
- Aké prekážky mu stoja v ceste, aby mohol napredovať podľa plánu
Problémy sa však neriešia. Denný meeting nie je priestor pre riešenie problémov a zdržovanie celého tímu. Na daily meetingu sa môže dohodnúť prípadný termín, kedy bude meeting, na ktorom sa vyrieši problém.
Demo meeting
Stretnutie s klientom a predstavenie celej práce za 2 týždne. Klient sa pýta a upresňuje svoju špecifikáciu. Prípadné zmeny sa zapisujú.
Freeday
Slúži ako rezerva pre prípadné predĺženie iterácie. Team by sa počas tohto dňa mal vzdelávať, urobiť si poriadok v kódoch, dokumentácii, retrospektívne zhodnotiť iteráciu a urobiť prípadne vylepšenia do ďalšej. V ideálnom prípade sa neriešia tasky.
Matúš Kosa
http://twitter.com/fetket
17 odpovedí na “Ako pracujú vývojári vo WebSupporte”
pekny popis a vyzera to na zaujimavy serial, ale pouzivat anglicke slova tam, kde existuju plnohodnotne slovenske ekvivalenty posobi trosku absurdne.
task, meeting, update, bugfix (povedzme, ze dalsie uz mozu byt sporne)
s clovekom sa tie anglicke nazvy spoja. Staci ked denne pracuje v systemoch, ktore su v anglictine, cita odborne clanky a literaturu v anglictine, tak to uz berie ako samozrejmost a nepozastavi sa nad tym
Presne suhlasim s vami. Proste su to uz v IT bradzi udomacnene slovicka. Je to podla mna celkom uchylka, chciet to pouzivat v SVK :))
mne sa clanok velmi pacil, vcetne vyrazov, vidiet, ze sa profesionalne pohybujete v tejto oblasti. + ked vidim tento blog, hned by som mal chut pracovat pre takuto spolocnost 🙂
Naozaj to robite takto podla teorie? Presne toto dodrzujete?
SCRUM je podla mojho nazoru najmenej agilna metodika zo vsetkych, ked mas vsetko dane 🙂
My pouzivame na vyvoj GUI metodiku Getting Real a na programovanie XP (extreme programming s okamzitou spatnou vazbou). Ale je fakt, ze vacsinou nevyvijame pre klientov, ale pre seba.
Dodrzujeme tuto metodiku najpresnejsie ako sa da, je pravda, ze sa mame este v com zdokonalovat. Vznikaju nam iste komplikacie, kedze zamestnavame aj partime developerov.
Co sa tyka spatnej vazby od klientov moze nastat aj nastava problem, ze ich dodatocne pripomienky vyrazne zmenia podstatu povodnej specifikacie casto aj myslienky a je problem to zakomponovat do kodu a zaroven dodrzat terminy.
Stretnutie na konci iteracie sa nam zatial najviac osvedcilo, ale sme otvoreni aj inym metodikam. Casom chceme vyskusat aj pair programming co prakticky zahrnute v extreme programmingu.
Pri XP a Getting Real je specifikacia minimalna, a podoba programu sa tvori „za behu“. Iteracie su male, hned sa vysledok ukazuje klientovi na feedback, hned sa meni kod a robi sa refaktoring, stale dokola. Vyslovene sa ocakava, ze specifikacia sa bude menit podla toho, ako sa zlepsuje porozumenie pre projekt. Treba mat chapaveho klienta, ktory dokaze toto absolvovat spolu s teamom. Resp. je to idealne, ak klient je firma sama (napr. pre SaaS projekty).
getting real poznam… tiez pre nase projekty sa snazime zacat robit touto metodikou. pre mensie teamy a nase vlastne projekty je to super metodika, ktora sa da celkom fajn aplikovat aj na ostatne casti. nielen vyvoj sw.
pre klienta, kde sa clovek dohodne co mu nakodi, za kolko hodin a kolko to bude stat, kedy sa to odovzdava atd.. je potrebne prisnejsie riadenie.
Pekny clanok.
Osobne som zatial nemal moznost nastavit Agilne metodiky, ale velmi sa mi pacia. Disciplina vedie k pravidelnym vykonom, viem si predstavit, ze urcitym sposobom to moze potlacit tvorivost, alebo skor tvorivu iniciativu v ludoch.
Rad by som sa Vas spytal par otazok.
Aku mate skusenost s nedisciplinovanymi timovymi hracmi a vyvodzovovanim personalnych a financnych dosledkov/postihov?
Zavadzali ste SCRUM postupom casu a po vybranych praktikach, alebo ste sa rozohodli, postavit cely vyvoj od zaciatku na ludoch+metodike ktoru vsetci dobre poznali a boli s nou zoznameny?
Prajem Vam vela stastia na ceste.
Hm…
Dost vseobecnych kecov. Hlavne ten postup iteracii mi pride tak prirodzeny, ze informacna hodnota clanku je nulova.
Chcelo by to skor popis veci ako version control, peer review, unit a load testing, …
Mi vo firme taktiez vyuzivame Scrum, takze tieto veci su mi zname. Zaujimalo by ma ale, ci pouzivate neaky elektronicky nastroj na managovanie projektov ak ano aky? Alebo klasicku tabulu s papierikmi?
Agilny proces funguje len kym nie je projekt velky. Dalsim problemom je prave kolizia s TDD, pretoze manazery by vzdy najradsej mali vsetko.
Dámy a páni prečítajte si prosím prvú vetu … nič? Tak predposledné slovo.
Po prečítaní článku som mal pocit, že miestami mrháte časom … napr. kartičky (plánovací poker), inak sa stotožňujem s názorom utfg.
vdaka za podnet, chybicku sme opravili 🙂
4Bystro: čo je to za metodiku „GUI metodiku Getting Real“?
[…] Ako pracujú vývojári vo Websuporte? […]
[…] Ako pracujú vývojári vo Websuporte? […]