PulseMeetings/DailyMeetings/DailyMeeting-20260810-0930.md

7.2 KiB
Raw Blame History

Zapisnik sestanka

Prisotni

Tomaž, Matija, Mihael, Rafa, Janko, Ana Marija

Namen sestanka

Pregled pripravljene sheme sestankov

Vsebina sestanka

Implementira se nova shema sestankov. Dnevni sestanki se odstranijo.

Odgovori se pojavijo, danes se preda znanje od Matije na Rafa. Potreben bo feedback od Tomaža.

Zjutraj smo dobili seznam sestankov potrebnih, da bo vse delovalo.

Pulse, branding sestanki grejo ven iz koledarja. Od sedaj naprej se bo potrebno držat nove sheme.

Delivery coordination nadomešča dnevne sestanke. Sestanek ni za to, da je sestanek. Če kdo nima nič za potevedat, mu ni treba prit. Držat se moramo minut in ostat učinkoviti. Na teh sestankih Tomaž ne bo prisoten, ker imam druge.

Skupna točka je Roadmap, ki je na podlagi prioretizacij. To so UserStory-ji. Izvedba pa dostavi izdelke v dogovorjenih ciklih.

Shema novih sestankov je predlog, ki ga po enem mesecu evalviramo.

Sprotni pregled delujočega stanja. Izvede se samo takrat, ko obstaja delujoč prikaz. Ko bo večji feature skoraj zaključen je smiselno pogledat in evalvirat. Brainstorming. Izkaže se, da on-the-fly debate niso najbolj optimalne, ker ni zaključkov kdo naredi kaj, do kdaj itd. Želim, da se sproti komunicira. Vodla delivery-ja in release-a sproži te sestanke.

Tedenski ekipni zaključek. Matija pravi, da se bo čas morda moral biti daljši.

Strokovni fokusni sestanek. Tu se gre za specialno obravnavo. Pogosto se bomo srečali s funkcijami, ki jih bo težko vmestiti. Nekatere odločitve bodo lahko imele dramatične poslaedice. Nadzorovano vnašanje funkcij, ki bodo konsistentni in transparentni. Če nekaj sprememnimo, kar na uporabnika ne vpliva ni problem. Če pa ima vpliv, je to treba obravnavati širše. Matijo zanima, če so ti sestanki lahko AdHock. Tomaž pravi, da raje ne, ker želi, da pridemo na sestanek pripravljeni. Eva je lahko koordinator teh sestankov in ji pobudnik posreduje informacije, da jih posreduje ekipi. AdHock je lahko, ampak naj bodo stvri urejene.

Shema sestankov se bo evalvirala v določenem roku.

Izvedbeno planiranje. Tipično bomo imeli prvi sprint v prvi polovici meseca, drugega pa v drugi. PPotrebno je pripravit plan, ki ga je potrebno uredit na enem sestanku. Sprint mora biti prirpavljen, tu se samo uredi plan. Iz Backloga se sestavi sprint. Backlog mora bit pripravljen za pol leta vnaprej. Sprinti bodo določeni preko Roadmap-a, ki bazirajo na prioretizaciji. Predlaga se, da je pripravljenih taskov za pet printov vnaprej. Taski se lahko razporejajo znotraj sprintov po potrebi. Vedno je treba sledit prioriteti. Prioretizacija se generira iz vrednosti za uporabnika in posel.

Vsako predlagano spremembo je potrebno ovrednostit kakšno uporabniško vrednost ima in katere nevarnsoti prinaša. Delivery se odloči kateri featurji se vnesejo. Če se vnese se vmesti in se za tem stoji.

UX/UI review. Po eni strani želimo hud UX, po drugi strani pa temu namenjano 30min na mesec. To se lahko še prilagodi. Namen sestanka je intuitiven. Namen je izboljševat izkušnjo. Tu se evalvira tudi Pulse Visual Language. Ni pa nujno zadnja verzija, smo odprti za komentarje. Mora pa biti konsistentno. Tu se izpostavi opaženo in se uskladi kaj je potrebno uredit.

Technical Review. Namen je presoditi tehnično rešitev, ki pomembno vpliva na druge dele. Odločitev mora biti pretehtana in dogovorjena skupaj. Delivery Review 2x mesečno se obravnava pregled stanja sprinta. Na koncu sprinta preverimo, če je rezultat pripravljen na Release. Pogleda se kaj smo naredili. QA mora biti izveden že tekom sprinta. Ko je sprint zaključen je izdelek delujoč. V Jiro je potrebno dodati status za QA. Delo mora biti tako splanirat, da so zadnji trije dnevi samo za stabilizacijo, ne da se do zadnjega razvija. Če planiramo, da se zadnji petek še razvija, se ne bo zrihtalo in se v naslednjem sprintu še popravlja za nazaj. Kapacitete za aktiven sprint so 7 dni za razvoj. Če kdo tiste tri dni nima kaj za delat, lahko začne delat naprej za naslednji sprint, kar je pripravljeno.

Če želimo dosešt cilje, je potrebno rpav čas identificirat negativne vplive.

Mesečna retrospektiva. Kaj smo se naučili iz dela, ki smo ga opravili tekom tega meseca. Namenjen je optimizaciji procesov. Na teh sestankih se lahko implementirajo spemembe procesov.

Želja je, da se vodi statistika bug-ov in regresij. To mora izvozit Jira.

Mesečni ekipni blok Kaj smo zares izboljšali za uporabnika. Namen je, da vrednostimo, kaj smo izboljšali za uporabnika v enem mesecu. Od tega je lahko rezultat, da je potrebno prioretzacije spremenit. Tu smo odprti za predloge in izboljšave. Trg in izvedba mora biti usklajeno. Če ugotovimo, da lahko pride do odstopanj je treba na to opozorit.

Mogoče bi se sprinti delali v prvi polovici meseca in v drugi polovici meseca.

Product Discovery Workshop. Sestanek namenjen razščiščevanju zadev. Po navadi bo prišlo od prodaje in bo namen da se problem pojasni. Dokler problem ni razjasnjen, ga je potrebno dovolj definirat.

Eva je lahko koordinator, ki pošlje naokoli materiale. Lastnik sestanka prirpavi materiale in jih posreduje Evi za distribucijo.

Sprint BETA:

Danes se mora začeti s polno paro. Mogoče bi se sprint raztegnil do konca meseca, da lahko implementiramo delujočo rešitev do konca meseca. Matija pravi, da to reši problem kapacitet za prvi sprint.

Tomaž zapiše prioritete na katerih bo lahko baziral Roadmap. Tako bomo vedeli, kaj se načrtuje za naprej. Na tak način bomo vedeli kako vmestiti katero funkcijo.

Release kako predlagate samo zato, ker bo sprint zaključen konec meseca, še ne pomeni, da bomo upgrade naredili prvega naslednjega meseca. Release mora iti najprej v samdbox. Karantensko obdobje bo trajalo 14 dni ali en mesec. Release mroa biti nadzorovan. Mogoče bodo release-i vsake 3 mesece. Vključeni so sprinti, ki bo stari vsaj en mesec. Ta proces je potrebno definirat in dokumentirat.

HotFix-i bodo morali obstajat. Matija pravi, da Canary release pomeni, da se release naredi manjšim strankam, nadzoruje in se kasneje večjim strankam da. Ta procecs bo potrebno evidentirat, dokumentirat, dogovorit. Želimo doseči, da nismo odvisni od posameznikov.

Lastnik tega, kar smo danes obravnavali je Škrjanec. Ekipa, ki je bila danes naslovljena, je odgovorna za izvedbo. Potrebno je narediti take sestanke, da se bo lahko konec meseca pogledalo retrospektivno in povedalo kako in kaj je kvaliteta boljša ali slabša.

Pulse in Branding sestanki letijo ven. Ameli se skomunicira kako se naredi naprej.

Matija pravi, da je definicija sprinta vzela 9h. Predlaga, da se zdefinira user storyje in se jih dodeli. Sami si odprejo taske pod story-jem. Napiše kaj je treba narest in koliko časa bo to vzelo. Tomaž se v osnovi strinja. Tomaž prosi, da se finomehaniko dogovori med ekipo. Predlog se implementira za naslednji sprint.

Zaključki

Ana Marija javi Evi, da razpiše vse sestanke iz Office accounta. Določimo kdo je obvezen in se jih doda. Pri opcijskih sestankih naj to piše v nazivu. Če sestanka ne potrebujemo, ga min dva dni prej skenslamo. V nazivu sestanka naj bo tudi lastnik sestanka. En dan prej se pošlje amteriale, če obstajajo. Jutri imamo Pogoji fokusni termin, da se razčisti tehnične zadeve.

Ostalo

06-08-2026 9:30 - 10:34 Avtor zapisnika: Ana Marija Pritržnik