Mentor schůzka 1 iterace (5-3-2024) » Historie » Revize 17
Revize 16 (Adam Šmucr, 2024-03-05 16:41) → Revize 17/18 (Adam Šmucr, 2024-03-05 16:44)
h1. Mentor schůzka 1. iterace (5-3-2024)
h2. Retro a plánování
** Dobrá příprava, Retrotool není zadarmo????? asi ne nebo jo? Tabulka je dostatečná
** Rozložení hodin přes lidi je vhodné, lze použít rovnou přes filtry
** Neduplikovat přes dva soubory - použít "Důsledky", Word šablona slouží spíš pro připomenutí nad čím se zamýšlet
** Nahnat čas je v pořádku, iterace nemusejí být hodinově stejné, plánovat na současnou iteraci
** Posun na úterý dává smysl - iterace se můžou na úterku překrývat (někdy budou schůzky jindy), důležitá je schůzka se zákazníkem
*** Hodiny se počítají tam kde byly stráveny - ne tam kam nutně logicky patří
** Pondělní schůzka - mohla by sloužit jako příprava na demo, na zvážení jestli přidává hodnotu (ušetření času na retrospektivě)
** Možná by bylo vhodné potvrdit si pevný termín schůzek se zadavatelem - dávat si vědět jen když jsou výjimky
** Plán nasazení v Readme je dobrý postup - stačí v pár bodech kroky, které se mají udělat
** Zabíhání při plánování do moc technických/konkrétních věcí - možná si stanovit časový limit po kterém musí být plán vytvořen
** Během probíhající iterace už identifikovat úkoly pro iteraci další (sbírání background informací) a až poté zaplánovat do konkrétní iterace
*** Planí i pro další akce v rámci iteraci
** Architektura - některé modely a diagramy mohou být platné bez ohledu na technologii
*** Dát si dřívější deadline na prototypy a v druhé půlce můžeme mít vybráno a udělat architekturu
*** Architektura nemusí být úplně kompletní
** Není úplně nutné naplánovat iteraci přesně na 90 hodin - dobré je mít nějaký čas do zálohy
*** Když si myslíme, že je hotovo 80% tak nás čeká ještě 80% času
h2. Demo se zákazníkem
** Na začátku rychlý plán co se bude dělat a to dodrženo
** Materiály, které chceme se zákazníkem probírat by bylo dobré mu předem dodat (urychlení schůzky)
*** V releasech by mohl být nějaký tag indikující release - zefektivnění schůzek, rychlejší feedback
** Se zákazníkem by bylo dobré probrat rizika v rámci Vize (především v praxi - zákazník tuto diskuzi spíše nevyvolá sám)
** Tematicky schůzka byla v pořádku - vyjasnili se i některé věci
** Pokud toho stihneme více, můžeme toho udělat více - hlavně zjistit, jestli to dokážeme spustit přes všechny překážky
h3. Projekt
** Ticketů je dost, drobení je dobré, průběžná práce, zavedené kategorie
** Burndown chart je v pořádku
** Název úkoly by měl obsahovat nějaké sloveso - upravit, vytvořit, atd. (infinitiv)
** Chybí alokace na plánovací schůzku - může být součásti retrospektivy (pokud jsou ve stejný den)
** Chybí alokace na schůzku s mentorem
** Pěkné filtry, zápisky ze schůzek taky super :)
** Strávený čas -> Report -> Vybrat rok a uživatele - lze i přes iterace
** V každé iteraci nemusíme mít všichni stejně, ale na konci semestru by to tak mělo být
** Wiki obsahuje základní fakta + rozcestník, Google Drive dává smysl pro dokumenty, které se budou často měnit
** Kam dávat úkoly ohledně testování a zda-li sem patří i dokumenty ohledně testování
** Konvence - definovat strukturu commit message (má být na začátku odkaz na úkol?)
** LCO nejspíš máme hotové - probráno podrobněji níže
** Na Wiki stačí odkaz na složku s dokumenty, není nutné mít odkazy na všechny plány a retrospektivy
** Vize - obsahuje klíčové požadavky, bylo by dobré odkazovat ve specifikaci na klíčové požadavky ve vizi
*** Rozdrobit na tasky - odkazovat úkoly na hlavní požadavky
** Specifikace požadavků - v pořádku, podrobněji bude přečteno později
** Plán projektu - existuje, obecné cíle iterací, konzervovat a v průběhu času se podívat jak jsme se od něj odchýlili
*** 5. iterace spíš jako IOC
*** Možná zbytečně rozsekáno, ceremonie na konci je příliš natažená (možná je lepší poslední iteraci prohlásit za rezervu)
** Rizika - podívat se na to z hlediska toho kdo nebyl u jejich definování
*** Odkaz na Redmine, definovat ve Vizi, že je to výchozí verze a jejich životní cyklus je v Redmine
*** Většina rizik jsou pouze organizační, přidat technologická rizika (např. nezkušenost s technologií, špatný výběr technologie)
*** Úkoly navázat na rizika - jako jejich ošetření
** Architektura
*** Není jasné, jestli dosáhneme LCA milníku, pokud nevíme jakou technologii použijeme
** Plán testování - v pořádku, detailně bude pročteno později
** Do PSTSP není nutné dávat poznámky ze schůzek