Mentor schůzka 1. iterace (5-3-2024)¶

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
  • Platí 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

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

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

Další schůzka¶

Společné DEMO s mentorem na další schůzce.
Další Review bychom nejspíš udělali až po třetí iteraci. Definitivně bude určeno pro DEMO.