Procesy
- kazdy web ma nadefinovany svuj jeden projekt v jire, k nemu je prirazen projektak/projektaci
- existuji dalsi projekty, ktere nejsou vazany primo na web, ale vazou s k funcnosti/pouzitelnosti, napr pro devare maintanance and operations
- existuje vzdy jeden sprint, vyjimkou je, pokud dojde k zalozeni specialniho projektu, pro ktery byl dedikovan cely tym, tento tym ma pak svuj vlastni sprint, board a …
- pokud projekt skonci, je potreba ho uzvarit, aby se jiz nedal pouzivat a „neprekazel“
- tasky
- produktak prirazuje tasky do svyho projektu
- nastavuje jim typ → bug, frontend feature, backend feature, config
- nastavuje jim prioritu → nizka, stredni, vysoka, kriticka(nejvyssi)
- jasne definuje zadani, doplni o odkazy pripadne screenshoty, grafiku apod., tasky bez popisku nebudou akceptovany, popisek != title
- tasky se podle typu a priority rozdeluji do backlogu(medium/low priority bug, f/b feature, medium/low priority config) a do helpdesk kanbanu(high/crit bugy, high/crit config)
- flow tasku
- tasky, ktere je potreba zpracovat nasledujici sprint, je potreba zadat do jiry nejpozdeji utery vecer
- pred poradou vyvoje(streda dopoledne, utery odpoledne) dojde frontend/backend oddelenim na ohodnoceni tasku storypointy
- pokud dojde k vytvoreni tasku ve stredu a je potreba ho zpracovat, ?mel by projit schvalenim? a nasledne je ohodnocen, to samy plati i pro tasky pridavane do aktualniho sprintu, task by mel byt vymenen 1:1 s jinym taskem/tasky(podle SP)
- na porade vyvoje dojde
- k alokaci lidi, tz. rozdeleni na vyvoj a helpdesk, vytvareni dedikovanych tymu pro specialni projekty
- k serazeni backlogu, muze dojit k prirazenim tasku na konkretni lidi(ale nemusi!)
- po porade vyvoje se zacne novy sprint, do sprintu se nahazi veci ze serazeneho backlogu, priradi se lidi(ale nemusi)
- meetings
- grooming party → 2h backend/frontend zvlast
- porada vyvoje → 1,5h produktaci + vedeni
- sprint meeting → 1h backend/frontend dohromady