Zápis 22.10.2018 08:30 - 11:30

Miestnosť: 4.26

Vedúci: Ing. Jakub Šimko, PhD.

Zapisovateľ: Bc. Daniela Sitárová

Scrum master: Bc. Martin Žák

Prítomní:

• Ing. Jakub Šimko, PhD.
• Bc. Martin Žák
• Bc. Andrej Slaninka
• Bc. Daniela Sitárová
• Bc. Andrej Zaťko
• Bc. Michal Fabiš
• Bc. Katarína Rafčíková
• Bc. Maroš Vašš

Sprint review

• WEB-34 - nie sú testy
• WEB-33 - nevieme, či budeme robiť, keďže sa nebudeme zaoberať sitemapou (Azure a kredity)
• WEB-30 - chýbajú testy
• WEB-35 - problém s dependencies, nepodarilo sa rozbehať vetvu reviewerom
• WEB-43 - hotové, len nie je zmergované a nemohli sme ukázať
• WEB-36 - nepodarilo sa
• Šprint za 0 User points

Retrospektíva

• hlavným problémom bolo testovanie

S čím prestať, začať?

S čím pokračovať?

• standups na Slacku sú fajn
• ak mal niekto nejaký problém, ostatní mu pomohli (riešili to spolu, buď na jednom mieste alebo remote), práca išla rýchlejšie
• párové programovanie
• byť fyzicky spolu pri práci, lebo komunikácia ide rýchlo
• Slack ako jediný komunikačný kanál
• veci ku konkrétnej otázke na Slacku sa riešia v threadoch
• V šprinte máme určený deadline na programovanie, kedy by mali byť úlohy Ready to review

S čím prestať?

• priveľa notifikácií z jiry, začali sa považovať za spam
• prestať písať heslá a prístupy do Slacku
• prestať sa baviť odveci

S čím začať?

• posielať notifikácie z jiry len na tie udalosti, ktoré sú naozaj dôležité (Ready to review, Ready to deploy)
• zaviesť nejaký repozitár prístupov a hesiel, prípadne používať SSH, ak je to možné
• založiť nový kanál na úlohy súvisiace s PerrySpace
• oddeliť prácu na tímovom projekte a prácu v PerrySpace
• zefektívniť komunikáciu, rozprávať sa o téme, ktorú máme v pláne riešiť, nezamotávať sa
• pridať na Slack notifikácie na Github, ktoré sú dôležité (pull requests - vytvorený a schválený, komentáre, wiki)
  • notifikácie priamo človeku, čo má robiť review, označiť ich
• začať dodržiavať pravidlá, ktoré sme si spísali
  • loading message na Slacku nakonfigurovať tak, že tam budú naše pravidlá
• na biznis analýze by mohli robiť min. 2 ľudia
• pri Code review aj spustiť novú funkcionalitu
• absolvovať párové programovanie s každým aspoň raz
• písať dokumentáciu produktu po anglicky na wiki
• zlepšiť odozvu na Slacku, keď sa položí nejaká otázka, ktorá očakáva odpoveď, napísať tú odpovaď, aj keď je negatívna
• ak je niekto označený na Slacku v otázke, mal by odpovedať
• jednoznačne zadefinovať, aké testy treba robiť pri testovaní jednotlivých úloh
  • mať testovací framework
  • unit testy by mali pokrývať každú metódu
  • unit testy by mali pokrývať okrajové prípady
  • unit testy by mali testovať základný scenár
  • pri integračných testoch otestovať tiež základný scenár
  • ak používame funkcionalitu, ktorá nie je otestovaná, môžeme napísať testy
• určiť v šprinte deadline na testovanie

Plánovanie šprintu

• vytváranie taskov v US - môžeme vytvoriť aj počas šprintu

TODO

• spýtať sa nevidiacich, či si ukladajú heslá
• nahodiť dokumenty na wiki, urobiť checklist na Githube
• aktualizovať metodiku Code review
• oboznámiť tím s tým, ako sa testuje

Diskusia

• Dependencies - Andrejkov task, ako to budeme riešiť, tiež to, čo písal Dávid, ake packages používať
• Kredity na Azure
• Kto merguje, ake pravidlá nastaviť - merguje posledný reviewer
• Nastaviť notifikácie z jiry, aby ich toľko nechodilo
• Github - notifikácie nastaviť do Slacku
• stretnutia v PerrySpace, ako fungovať aj v tejto oblasti tak, aby to bolo pre nás užitočné
  • musíme rozmýšľať aj v oblasti biznisu, nie len o technologickej stránke nášho projektu
• ako efektívne programovať, urobiť optimalizáciu - vyrieši Dávid s Maťom
• pri code review je lepšie si nanovo naklonovať repo a prepnúť sa na danú vetvu