5.+6. iterace (závěrečná) -- 10b, 9b
- schůzka k předání, dořešení nalezených chyb
- vytvořen dokument Testovací scénáře, ale tým si před předáním zjevně neudělal “instalační” resp “funkční” testy, při předvádění částečný generálský efekt
- řešení způsobu nasazení u zákazníka, potíže s neexistencí domény pro google workspace a jejím zřizováním (sporadická/nespolehlivá emailová komunikace zákazníka)
- instalační příručka s podrobným popisem
- zbývají otevřená issues (Feature), jen administrativní nedodělek
celkový proces a retrospektiva s týmem -- 10b
- proces s iteracemi a milníky (std ASWI) pro projekt tohoto rozsahu a velikosti týmu spíš nevhodný, iterace nešlo plánovat ani provést rovnoměrně co do rozsahů hodin, lepší by byl kanban-like proces
- artefakty nedávaly příliš smysl, a jejich vytváření bylo pro tým hodně nezáživné
- komunikace v týmu občas drhla, ale základní spolehnutí se navzájem bylo; retrospektivy trochu pomohly hlavně ve druhé třetině projektu (pak už rutina)
- kombinace 2-členného týmu a (jak se ukázalo v průběhu) zadání vyžadujícího ne-programovací řešení byla náročná, nedoporučovali by pro příště
- naučili se pár zajímavých věcí
- podstatné a hodné ocenění je, že tým našel vhodné technické řešení pro daný problém za daných omezujících okolností (zákazník, minimální nutné vlastnosti “produktu”, dostupný čas, velikost a složení týmu) a dotáhl toto řešení do funkční podoby
hodnocení: 9b
datum: 9.5.2023
stav projektu - dobré (3b)
- + vše běží
- + LCO a LCA reálně dosaženy
- 0 tým unavený, málo času, zákazník moc nekomunikuje, čeká se na domluvu zákazník - tech support (přístup na google workspace hospicu)
iterace - dobré (3b)
- + cíle dobré, výběr požadavků odpovídající
- 0 plán a odhady času, burndown, trace v ALM: 3.it celkem dobré, 4.it strávena polovina odhadnutého času kvůli jiným úkolům
- + customer demo ok
- 0 retrospektivy G/S/M fungují, zřejmě užitečné, byť se v nich opakují tatáž témata
technická kvalita - slabé (1b)
- 0 artefakty shromážděny na jedno místo, ale chybí jim formální stránka (“košilka”, indikace stavu)
- - doc Vize neobsahuje hlavní požadavky; Architektura není dokument a tedy nezahrnuje vysvětlení/zdůvodnění; komplikované rozdělení (duplicity) informací o požadavcích na 3 dokumenty, akceptační kriteria mohla být součástí “DSP” a v něm vysvětlen význam “IMPORTANT” příznaku
- - verzování – pouze automaticky vytvářené google doc verze
- + technické řešení předvedeno, funkční a použitelné, vhodně vybrané pro daný účel (byť softwaru to obsahuje velmi málo ;-)
postupy a praktiky - slušné (2b)
- + vhodné rozlišení task/enhancement/feature, časový rozsah issues
- 0 vazba requirements - issues jen přes shodu popisů, chybí priority
- - testy zatím neřešili
- + komunikační mechanismy (v týmu, tým-zákazník) vcelku odpovídající
doporučení
- plánovat tak, aby šlo projekt udržitelně dokončit
- prodiskutovány varianty postupu pro závěrečné iterace projektu
- se zákazníkem telefonovat, kromě emailování
hodnocení: 8b
datum: 17.4.2023
stav projektu - dobré (3)
- + tým funguje, zákazník je špatně k dosažení – řešeno kvalifikovaně
- + dosažen LCO, potvrzení “MVP” od zákazníka
iterace - slušné (2)
- + cíl dobrý a v souladu s fází, dosažen (nedokončená malá část, ok)
- + burndown vcelku ok, na začátku zapomněli zahrnout pár admin úkolů
- 0 odhad trochu nadhodnocený, částečně nestíhali, průzkum technologií rychlejší
- 0 retrospektiva G/S/M subjektivně přínosná, záznam na nevhodném místě (ticket comment)
technická kvalita - slabé (1)
- - artefakty teď primárně na google drive, ale stále trochu roztříštěné a chaoticky uspořádané (vize na redmine wiki vs MVP na drive, na drive vše na jedné hromadě, popis MVP nemá podobu artefaktu a přitom je odsouhlasený)
- - v redmine pouze “tasks” a prio “normal” (chybí analogie product->iteration backlog a DEEP)
- + připravovaný návrh architektury obsahově dobrý, formálně zatím syrové ale to v danou chvíli nevadí
- - vazba na požadavky – vytvořeny use case workflows, chybí vědomý výběr funkčností/vlastností charakteru architecturally significant
- - doc Vize bez zásadních změn oproti předchozí iteraci, nezahrnuje business critical funkčnosti
postupy a praktiky - slušné (2)
- + efektivní způsob řešení komunikace se zákazníkem, nastavení scope projektu
- 0 velmi jednoduché workflow issues, vhodné řešení multiple assignees, rozumné řešení přeplánování nedokončeného do další iterace (jen chybí vazba mezi danými issues #10043 a #10375)
- + průzkum technologií + technologické prototypy
doporučení: zapřemýšlet a řešit
- co udělat pro prevenci “final disaster” tj. situace, kdy by zákazník nebyl spokojen a neakceptoval řešení
- jak testovat, jak řešit úlohy konfiguračního řízení, při daných specifických technologiích
hodnocení: 9
datum: 29.3.2023
průběh a stav projektu - hodnocení slušné 2b
- + rychlý nástup prací projektu po úvodním čekání na rozjezd
- + dobře funguje komunikace, s hospicem v mezích možností
- 0 “LCO milník dosažen” ale ještě nejasnosti u stakeholderů (Daněk - podoba řešení, hospic - nekonzistence v požadavcích)
- 0 vytvořený plán projektu ale už neodpovídá předpokládané skutečnosti a nesedí dokument s Redmine roadmap
iterace - dobré 3b
- + cíl a obsah odpovídá fázi prj
- 0 burndown (camel hump) i neúplný seznam tasks odráží to, že se zapomnělo něco na začátku do plánu zadat protože potřebovali rovnou skočit na práci
- - výrazně nadhodnocené odhady, částečně způsobené rozhodnutím o změně technologie v průběhu iterace (probráno v retrospektivě)
- 0 retrospektiva provedena, na to že tým je 2-členný a že poprvé to vypadá na slušný pokus (mentor nebyl přítomen, z vlastního rozhodnutí), v záznamu chybí indikace typu glad/sad/mad a z retrospektivy nevyplynuly zřetelné “actionable points”
technická kvalita - slabé 1b
- - roztříštěné zaznamenávání informací (redmine wiki, tasks, google drive)
- - chybí zřetelně vymezené a řízeně upravované hlavní artefakty; obsah jim odpovídající ale +- existuje (vize v rámci “plán projektu” a záznamu schůzky se zákazníkem – cíl “stanovit si prioritu požadavků a minimální akceptační kritéria”, přehled požadavků tj. backlog v pracovním textovém souboru)
- 0 vývojové prostředí inicializováno ale zatím nepoužité resp. v řešení (součást cílové platformy)
- + tickety popsané kde potřeba, workflow ok; úložiště zatím n/a
postupy a praktiky - dobré 3b
- + dobře řízená komunikace se zákazníkem, přípravy a záznamy
- + (nakolik umím posoudit) vhodně změněná strategie co se týče technologie pro výsledné řešení a tedy cílové provozní platformy (z “desktop app + server backend” na “google suite se scriptováním”)
- 0 zápasí s vybalancováním programátorský přístup vs. sw projektový management, s pracností “administrativy”, a s řízením zákazníka
doporučení
- s aktuální znalostí zákazníka a kontextu: revidovat rizika a opatření, plánovat podle toho, věnovat víc péče definici požadavků+rozsahu a jejich doloženému odsouhlasení
- zamyslet se a odstranit duplicity ve vykazování a zaznamenávání informací (=> šetřit čas), vzít pragmaticky, co je opravdu třeba mít a v jaké formě
použitý proces
Zhodnocení 5.+6. iterace a celého projektu