ASWI - Pokročilé softwarové inženýrství » ASWI 2024 » Zachycení scénáře průchodu webovou aplikací - VUŠ

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