Ako pracujú vývojári vo WebSupporte


  • Zdieľať na Google+

Č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

Komentáre

  • hnidopich
    Odpovedať
    Autor
    hnidopich

    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)

    • WebSupport
      Odpovedať
      Autor
      WebSupport WebSupport

      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

      • Peter
        Odpovedať
        Autor
        Peter

        Presne suhlasim s vami. Proste su to uz v IT bradzi udomacnene slovicka. Je to podla mna celkom uchylka, chciet to pouzivat v SVK :))

  • Michael Pekarek
    Odpovedať
    Autor
    Michael Pekarek

    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 🙂

  • Bystro
    Odpovedať
    Autor
    Bystro

    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.

    • WebSupport.sk team
      Odpovedať
      Autor
      WebSupport.sk team WebSupport.sk team

      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.

      • Bystro
        Odpovedať
        Autor
        Bystro

        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).

        • MichalTruban
          Odpovedať
          Autor
          MichalTruban

          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.

  • Janko Panko
    Odpovedať
    Autor
    Janko Panko

    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.

  • utfg
    Odpovedať
    Autor
    utfg

    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, …

  • Dominik Slavkovsky
    Odpovedať
    Autor
    Dominik Slavkovsky

    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?

  • jano
    Odpovedať
    Autor
    jano

    Agilny proces funguje len kym nie je projekt velky. Dalsim problemom je prave kolizia s TDD, pretoze manazery by vzdy najradsej mali vsetko.

  • Megatron :D
    Odpovedať
    Autor
    Megatron :D

    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.

    • WebSupport.sk team
      Odpovedať
      Autor
      WebSupport.sk team WebSupport.sk team

      vdaka za podnet, chybicku sme opravili 🙂

  • Peter
    Odpovedať
    Autor
    Peter

    4Bystro: čo je to za metodiku „GUI metodiku Getting Real“?

  • Dostali sme scrámy | SIEŤ DOBRA
    Odpovedať
    Autor
    Dostali sme scrámy | SIEŤ DOBRA

    […] Ako pra­cujú vývo­jári vo Websuporte? […]

  • Dostali sme scrámy | web.sietdobra.sk
    Odpovedať
    Autor
    Dostali sme scrámy | web.sietdobra.sk

    […] Ako pracujú vývojári vo Websuporte? […]