Mentor schůzka 1 iterace (5-3-2024) » Historie » Revize 16
Revize 15 (Adam Šmucr, 2024-03-05 16:37) → Revize 16/18 (Adam Šmucr, 2024-03-05 16:41)
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 probereme 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 dokumenty ** 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