Zápis 24.09.2018 09:00 - 12:00
Miestnosť: 4.26
Vedúci: Ing. Jakub Šimko, PhD.
Zapisovateľ: Bc. Michal Fabiš
Prítomní:
- Ing. Jakub Šimko, PhD.
- Bc. Martin Žák
- Bc. Andrej Slaninka
- Bc. Andrej Zaťko
- Bc. Michal Fabiš
- Bc. Katarína Rafčíková
- Bc. Maroš Vašš
Neprítomní:
- Bc. Daniel Sitárová
Priebeh stretnutia
- Manažér úloh bude JIRA
- Slack sa pod ňou zintegruje
- Andy: Treba Prehodnotiť čo ako budeme pokračovať ďalej - či budeme pokračovať v technológiach aké máme, niečo prehodnotíme alebo čo.
- Treba určiť SCRUM mastera
- Určiť Backlog
- Product ownery budeme všetci
- Katka: Dávid písal kto bude riešiť DevOps (Azure, Docker …)
- Jakub: Je to jedna z tém podpory vývoja(support, continuous integration, využívanie repozitára). Vlastníctvo kódu by mali mať minimálne dvaja ale najlepšie takmer všetci
- Andy: Čo s dennými stretnutiami (stand upmi)??
- Jakub: Malo by ich byť dostatok aby sme vedeli medzi sebou komunikovať - Nám sa bude hodiť ak ich budeme robiť na stretnutiach S J. ale aj niekedy počas tých spoločných sedení - najlepšie na začiatku. Máme tam dva bloky, najlepšie keď si dáme standup na začiatku každého z nich. Tým že chceme mať standup v pondelky tak to bude možno lepšie na začiatku a na konci. Mal by trvať tak 5 minút
- Jakub: Spoločnou prácou minimálne 4h (plánujeme aj viacej) - hlavne kvôli bezbarierovej komunikácií
Support
- Vyriešiť Git repozitár
- Ako bude repo organizované?:
- master - do masteru iba cez pull requesty a bude funkčnú
- development - stále je to priced vec, stále stabilná
- každá fičúra - vlastná vetva
- Ak chceme aj integračný testing tak nám chýba nejaká šprint vetva, vyrobí sa z devu a z nej máme branche a fičúry, na nej testujeme či je dobre zintegrované a na konci dáme do devu. Toto je iba jeden príklad, dá sa stanoviť aj inak.
- Čo je to (naša) aká je definícia že je niečo hotové (Definition of done?)
- Ak je niečo hotové, malo by to byť aj otestované
- kód musí byť testable, metóda robí jednu vec a pomocou mock…upov by sme ich mohli testovať
- Napr. Metóda, v ktorej sa vnútri vyrába databázová konekcia nie je dobrá. Konekciu pošleme ako parameter funkcie a nevytvoríme ju vnútri napr. Mohli by sme si vypočuť aj podcasty.
- Mal by niekto urobiť code review
- Zintegruje sa, nasadí sa
- Jira
- Úlohy budú testovať kanban table: Todo, In progress, ready to review, ready to deploy, Done.
- Continuous Integration
- Automatické nasadenie softvéru - po nejakom čase po komite sa to prejaví na produkcií, často sa musí ísť do databázy, niečo sa tam prepíše, jedná sa o zložitú procedúru ale všetko sa to dá naskriptovať.
- Monitoring - hovorí že server je vpohode a keď nie, príde napr. niečo do slacku.
- Automatické spúšťanie testov - ak spadnú testy, zakráka to. Môžu to byť aj iné ako jednotkové testy, napríklad integračné. Pivo za zlý push, najlepšie dve.
- Načo je využívaný Cloud v našom produkte? - Site mapa, tam sa pridávali synonymá, odoslala sa mapa z textami a to sa priložilo do databázy na prehliadači. Potrebujeme to ďalej? Nebudeme potrebovať nejaké ďalšie? Ak chceme vyvýjať serverovú časť, musí byť v cloude?
- Náš prípad CI: Serverová časť a desktop prostredie. Môžeme chcieť odbremeniť klienta a pôjde to na server.
- Ak máme spojené komity s branchami tak sa oplatí mať zintegrované github s Jirou
- Čo má táto CI zabezpečiť? -
- Byť čo najskôr informovaný o tom čo sa deje
- Na druhej strane to musí byť dobre nastavené, aby nás to neotravovalo o všetkom. Aby to informovalo tak akurát a to čo má
Povinnosti ku predmetu
- Mať vytvorený web - ku tímu a ku projektu
- Treba tam dať odkaz na download link, na dokumentáciu, na prezentáciu ďalej
- Môže byť to čo už mali, ale pribudne záložka tím
- Na konci je potrebné ho odovzdať
- Odovzdávať v nejakých etapách funkčný softvér a dokumentáciu
V deviatom týždni odovzdať dokumentáciu - čo bude lajstro obsahovať?
- väčšina vecí vzniká automaticky - po ceste
- Prvá časť sa volá Dokumentácia k inžinierskemu dielu + špecifikácia so všetkými story. Keď dokončíme prácu v nejakej fičúre, tak je dobré napísať že tu som napísal takúto metodku, api call atď, tak je to dobré napísať. Storky, bude to mať description, a počas plánovania sa vytvorí táto časť dokumentácie. Pri backlog groomingu sa zistí čo ešte ako urobíme atď. Všetko čo zaznie pri tomto sa zapíśe do tej Jiry a z pôvodného opisu vznikne väčší a zrazu z toho bude dokumentácia.
- Druhá časť sa volá Dokumentácia k riadeniu - všetky pravidlá, coding standards, ako vyzerá scenár nášho riadenia, naše procesy + ďalšie veci ako napríklad zápisy zo stretnutí, zápisy z retrospektívy.
Backlog
- Prvý krok: Zistiť to čomu sa doteraz venovali, či je to fajn pre nevidiacich a zistiť čo by sa im zišlo.
- Jednou z tém je: Používateľské testovanie, ktoré je zdrojom podnetov. Mali by sme to urobiť čo najskôr.
- Potrebujeme mať v rozbehanej JIRE rozbehaný Backlog!!!
- Backlog bude mať epicy a nad ním budú témy (themes). Téma je napríklad performance improvement alebo nové cool fičúry, používateľské testovanie atď. V každej téme bude viacero epicov ako napr. Odhadovanie používateľského intentu(úmyslu). V rámci story by potom bolo, že necháme pouźívateľa tam niečo zadať.
- “mali by sme story teda zaobalovať do väčších celkov, akonáhle ich bude viac ako desať, môžeme začať robiť”
Používateľské testovanie
- napíše sa scenár
- Rozbehať používateľské testy, treba nahrubo určiť ich závažnosť a riešiť to
- Ku testu je potrebné stanoviť očakávania a ako ho používatelia naplnili
- Je vhodné vytvoriť persóny - používatelia môžu byť
- Persony by mohli byť vytlačené, kludne aj v tom perryspace
- V Slacku si vytvoriť tých userov a zapisovať tam, aký user mal s čím problém
- U nás do prvého ročníka nastúpil nevidiaci, treba ho získať na našu stranu
- Cez érazmus tu máme študenta z univerzitu v Kunštajne či kde, robil na nejakej appke pre nevidiacich. Niečo že pre vlastníkov stránok sa injectne javascript a vylepší stránku aby bola viac accessible. Možno je zneužiteľný. Julian Nicolas Kannopka, treba mu dať pivo.
- Skúsenosť: s tým testovaním to ide pomaly
- Jakub Nielsen - vstupná brána do testingu, nejakú veľkú teóriu nepotrebujeme, treba urobiť scenár, ukázať Jakubovi. Aj zle urobený experiment je experiment. Maroš: odsledovať hlbšie ako čo používajú.
- Štúdie treba nahrávať, aby bolo vidieť priebeh
Prvý šprint
- Zhruba o dva týźdne ďalší šprint
- Treba čo najskôr rozbehať aktuálny stav a working pipeline
- Rola je iba scrum master a product owner
- Keď sme my programátori tak je PO Jakub, inak sme my
Začlenenie tímu
Scrum master
- Je katalyzátor
- Zabezpečuje aby všetko išlo plynule, odbremeňuje programátorov
- Stráži, aby bola diskusia produktívna
- V školskom SCRUM je to ten študent ktorý kontroluje či sa dobre komunikuje, riadi stretnutia, o tri/štyri týždne bude riadiť stretnutia.
- Vyberieme si ho my, môže sa striedať ale nesmie sa to striedať veľmi často, max tak 4ia ľudia aspoň po 2-3 sprinty
Možno sa nájdu aj iní
- Možno sa nájdu ľudia ktorí majú skúseností viac technológiami ako niekto iný
- Najviac skúsený človek by nemusel kódiť ale robiť codereview
- Niekto viac bude stáť nad kvalitou kódu, lebo má takú povahu
Q/A
- Riešime v TP biznis?
- Nie neriešime, nie je to GRO. Jakub nám ale môže pomôcť
TODO
- !!!V rozbehanej JIRE mať rozbehaný backlog!!!
- Používateľské testovanie na zhrnutie podnetov
- WEB čím skôr a plagát
Nice to have - Čo by bolo dobré?
- Oplatí sa mať wiki, kvôli nejakým metodikám, know-how.
- Technická dokumentácia
- Coding standards
- Wiki je najlepšie mať na githube
Ďalšie stretnutie - predikcia
- Budeme sedieť nad BackLogom
- Kontrola JIRI
- Chystať sa na ďalší týždeň spustiť šprint