Zápis 08.10.2018 09:00 - 12:00

Miestnosť: 4.26

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

Zapisovateľ: Bc. Michal Fabiš

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á - remote
• Bc. Maroš Vašš

Agenda

Organizačné veci

• Appka Slack na mobile + preposielanie mailov z adresy tp@webable.solutions
• Maroš a Maťo ešte nemajú preposielanie na svoj mail

Testovanie prehliadača

• Všetci na tom robili

Web

• Pracuje sa na ňom (obsah stránky + dizajn sú rozrobené)
• Zajtra músí byť web nahodený

Azure hands-on

• Nepodarilo sa zatiaľ vybaviť
• Potrebujeme to kvôli prekladom
• Na drive je dokumentácia ako sa pripojiť na mastera
• Ak to vieme nasadiť na konci šprintu tak vpohode

Perry Talents

• Práca na biznis analýze v KOMERČNEJ OBLASTI
• 2 ďalšie kartičky do Perry Space budú dnes
• Podarilo sa nám zosúladiť naše šprinty v škole s ich 2 týždňovými

Diskusia

Stand-up

• Prvý za nami
• Treba spísať pokyn - každú dohodu treba niekde zapísať do dokumentácie ako sa riadime a ako fungujeme. Na wiki treba zapísať sekciu, kde bude: pravidlá komunikácie napr. Standup robíme vtedy a vtedy, každý tam napíše vtedy a vtedy…
• Informovanie na Slacku o tom, kto čo spravil + čo plánuje spraviť
• Čo si o tom myslíme? (príliš skoro hodnotiť ale ak sú nejaké pripomienky, von s nimi)

• Jira je TODO LIST nie Slack

• Počas standupu by sa mali riešiť hlavne problémy a odhalovať ich

Retrospektíva

Kolónky S čím by sme mali pokračovať - Aby sme si uvedomili veci ktoré nám idú dobre a aby sme ich náhodou nezrušili S čím by sme mali prestať * S čím by sme mali začať - Nápísať jednotnú štruktúru, Pokiaľ niekto chce ku niečomu z toho napísať tak by sa to malo riešiť v threadoch.

Github štruktúra

• Zatiaľ nie je upravená, dnes ju treba urobiť
• Informácie o zmenách sa môžu zapisovať, informovanosť je dôležitá. Feedback berieme. Nemôžeme čakať na odobrenie ani nič iné.
• K úlohám z backlogu sa môže vyjadrovať aj niekto kto na tom nerobí ale nemal by zasahovať
• Andy: bolo či by nebolo dobré urobiť Fork, aby sa zachovalo to ako sa veci riešili predtým a teraz. Jakub: na to treba napísať pravidlá tiež niekam.

• Spraviť nový repozitár by bolo úplne najlepšie asi s novou štruktúrou a neskôr sa vrátiť naspäť.

• Dávid: Prispievanie code-base. Keby chce nejako prebiehať, nesmie to interferovať s naším vývojom a to je problém, pretože: Jedná možnosť je že sa urobí vetva v ktorej sa bude robiť a z ktorej môžeme my prijímať pull requesty a musíme si byť istý že nám to nič nedokafre v tom našom šprinte. Nech dá vedieť že ide na niečom robiť a nech ten pull request nie je že raz za mesiac nejaká šupa.

• Do backlogu môže pridávať veci a musí to spĺňať štandardy: Musíme mať spísanú definition of ready, ktorú to musí spĺňať.
• Treba navrhnúť nový systém organizácie branchí a ten starý treba nechať tak ako je

Používateľské testovanie

• Máme vytvorený návrh

• Keď chceme feedback na takéto dokumenty alebo tak, tak určite čo najskôr poslať notifikáciu Jakubovi, aby sa na to vedel pripraviť.

• Prvá časť testovania môže byť celkom šupa, ktorá by mohla trvať aj pol hodinu

• Druhá časť - nemôže tam byť aj niečo so sociálnymi sieťami?
• S týmto návrhom by sa už dalo pracovať: Nie je tam napísané, že čo to znamená že tú úlohu urobil korektne - kde má skončiť. Na tento účel postačuje to čo máme
• Čo treba spraviť: odpilotovať si to teda, všetko by sa to tam malo dať spraviť aspoň teoreticky spraviť. Teda keď to zvládneme my tak potom môžeme ísť na reálnych userov
• Chýba sekcia: Inštalácia - ktorá by mohla byť na začiatku
• Po zmeraní zvážiť či nedať iba nejakú časť.

Jira

• Podarilo sa nám ju nasadiť, každý má používateľské konto, podarilo sa spraviť základný setup (notifikácie, čo všetko dokáže Jira, ….).
• Skontrolovať Jiru - či nám niečo nechýba

• Prebrať, akú štruktúru dávať opisom errorom a do akého epicu ich zaradiť Skontrolovať Backlog + poprípade niečo dopísať upraviť Naplánovať šprint

• Definition of ready? Aká je???

  • Treba mať
  • Nechceme zobrať do šprintu iba niečo čo vieme že v ňom vieme dokončiť
  • !INVEST! - Každá z týchto vecí musí byť odhadnuteľná a nezávislá od ostatnýc. Musia ku tomu existovať akceptačné kritéria.
  • Description tam nie je… Teda treba definovať aký to má mať výstup (zamyslieť sa nad niečim??)

• Definition of done - kritéria kedy je niečo dokončené - nie konkrétnej úlohy

  • definujeme si ju podľa seba a mala by byť jednotná pre všetky stories - je to nasadené, code review… Nič to neobsahuje o tom ako má vyzerať výsledok konkrétnej úlohy. To treba dopísať do každej jednej úlohy.
  • Pouvažovanie je analytická story. Mala by mať inú definition of done…
  • DOD môžeme mať viac podĺa toho o akom type story sa bavíme.
  • Napr tá analytická by mohla mať spísaný dokument ku čomu sa má autor vyjadriť alebo tak…

• V JIRE by bolo dobré nakonfigurovať storky

  • Klasická user story
  • Bug-fix
  • Analýza
  • Všetko ostatné

Praktická rovina

• Aby sa nám s tým dobre robilo, teda vieme nakonfigurovať pri úlohe, že description môže byť vyššie ako peoples
• Status by mal byť vysoko ale nemusel by byť pretože to uvidíme v tom kde sa nachádza na tabuľi - teda nepotrebujeme
• Components potrebujeme ak ich budeme používať
• Labels takmer určite začneme pouźívať
• Edectivne versions asi nebudeme používať
• Tým sa malo povedať, že treba odobrať nepotrebné veci, teda napr description by sme mali hneď vidieť.

• Šípočka je priorita, to by mohlo zmiznúť.

• Kritériá je dobré napísať a treba mať veci zoradené podľa priority

• Môžeme si urobiť ďalší Epic že bugy - teda dá sa zavieš že každá story je nejakého typu.

• Kde sa treba baviť o veciach ktoré nevieme čo s nimi? Určite dať ich do backlogu a začať používať tagy.

• O každej story by sme mali odhadnúť ako náročné je ju urobiť. Pokiaľ je niečo v takej pozící, že vôbec netuším čo s tým tak to nie je asi dobré.

• TODO, In progress, Ready to review, In review, Ready to deploy, Done

Plánovanie (Ako ho robiť?)

• Prioritu udelovať podľa toho používateľského testu
• Error okno sme dali iba chybu.. Ona je to nová funkcionalita, to nejdeme niečo opravovať ale pridať niečo úplne nové.
• Po šprinte ak nám nevyšiel nejaký odhad, už sa to hodnota tasku neupravuje, skôr sa robí že ako lepšie odhadnúť hodnotu

Odhadovanie (Ako ho robiť?)

• Bolo by dobré mať také veci ako odchytávanie eventov a odpalovanie podľa nejakého stavového stroja. Musíme zvážiť či takéto niečo nepotrebujeme. Teda to urobiť podľa nejakého návrhového vzoru.
• Máme tam observera?

TODO

• Azure hands-oň
• Jira šprinty - názvy podľa abecedy najlepšie a nech je to tematické
• Dokumentáciu buď do WIKI alebo Confluence - dohodneme sa
• Spísať metodiky (DOD, DOR, standups ....)
• Do dokumentácie zapísať - koľko story pointov je za aký typ úlohy
• Urobiť tasky ku stories!!! Čokoľvek treba urobiť tak na to urobiť subtask
• Do jiry In progress, Ready to review, In review, Ready to deploy, Done