Datum: 6.6.2024
Hodnocení: 8b
Předané artefakty¶
- předávací protokol - ano
- archiv projektu - ještě TODO
Tým a komunikace¶
slušné (3b)
individuální penalizace 1 člen
- + se zákazníkem dobře řízená komunikace, časté schůzky, týmem zapojeni i koncoví uživatelé
- + rozdělení rolí dobré
- + (ne)komunikace jednoho člena v průběhu projektu, tým byl schopen (s jednou konzultací s mentorem) vyřešit samostatně, byť to vedlo ke zdržení a zvýšení celkově odpracovaného času
Projekt¶
slušné (2b)
- 0 snaha o podrobné řízení, ale zpočátku ne vždy vycházelo + monitorovatelnost zvenku (mentor) spíše slabá
- - výrazně přesahnutý rozsah (přes 820 hodin)
- + proces postupně mírně upraven/doladěn (ticket workflow)
Technická kvalita¶
slušné (2b)
- 0 dokumentové artefakty zpočátku slabé, postupně dopracovány
- 0 produkt ve výsledné implementaci funkční ale s architektonickými i impl. slabinami
- 0 web projektu zpočátku velmi nepřehledný, nakonec OK-ish
Postupy a praktiky¶
slabé (1b)
- 0 práce s úložištěm nakonec OK, ale vůbec nepoužity tagy
- - burndown nefunkční kvůli použitému workflow ticketů
- - potíže s trasovatelností požadavků, zejm. vazbou tasků na výchozí potřeby / požadavky
- + plánování a výsledná přesnost odhadů vcelku dobré
- - nezřídka používány rozsáhlé tasky (na nich přesnost odhadů malá)
- + retrospektivy (části "co zlepšit" a "čemu se vyhnout" ) pomohly najít a upravit postupy (komunikace, SCM)
- - retrospektivy nepoužily zavedené schema, obsahují pravidelně velkou část "udělali jsme, co jsme naplánovali" což ale patří do uzávěrky iterace se zákazníkem (toto zhodnotí product owner)
Post-mortem review¶
Provedeno jen velmi krátce.
- tým a komunikace
- rozdělení rolí: v předchozím studiu už měli ve stejném složení jinak rozdělené, tj. teď si zkusili "zamíchat", užitečné
- k diskusi po skončení ASWI je složení týmu pro pokračování v TSP2
- technická kvalita produktu
- k diskusi zda refactorovat nebo použít jen jako prototyp a (v pokračování projektu) reimplementovat
- příčinou zčásti to, že architektonický prototyp byl pouze Proof of Technology nikoli Proof of Concept (neimplementovány business / architecturally critical requirements)
Použitý proces¶
ASWI std
Datum: 5.6.2024
Hodnocení: 6.it 9 bodů, 7.it 11 bodů
Průběh a stav projektu¶
dobré (3b)
- + IOC
- + tým do značné míry konsolidován
- 0 postup prací setrvalý
- dosud strávený čas: (nezaznamenáno)
Iterace¶
6.it slušné (1b)
7.it dobré (3b)
- + cíle v souladu s fází, splněny bez nutnosti změn
- + 7.it burndown i objem prací realističtější
- - 6.it backlog not DEEP
- - velké úkoly (odhad 15-30h), na nich výrazné rozdíly odhad vs skutečnost
- + slušná přesnost odhadu pracnosti na menších úkolech
- + užitečné body v retrospektivě (6.it "co zlepšit" a "čemu se vyhnout")
Technická kvalita¶
slušné (2b)
- + trasovatelnost commit-ticket systematicky používána
- 0 použity unit testy a základní perf testy (tým se sám naučil, neměli ve výuce)
- - v polovině 6.it se objevil nesoulad očekávání zadavatele s implementací webové části (funkčnost, technologie, architektura, kvalita src kódu)
- zčásti příčina v dřívějších komunikačních potížích v týmu (první impl. nešlo dříve demonstrovat/konzultovat), zčásti neuchopením "executable architecture"
- - src slušná struktura, ale ve zdrojáku občas magická čísla a hesla v plaintextu (v repository) :(
- + základní uživatelská dokumentace
Postupy a praktiky¶
dobré (3b)
- + v 7. iteraci uzavírání issues při dokončení => burndown umožňuje sledovat postup
- + testy pro ověření výkonu aplikace vůči specifikaci požadavků
- 0 jinak standardní
Průběh a stav projektu (3b)¶
- běží vývojové práce
- spíše "programování" než "fáze konstrukce", viz postupy níže
- tým řešil (vč. konzultace s mentorem) nedostatečnou spolupráci J.Hrušovského
- použité řešení = komunikace + samostatný přesně definovaný úkol, dobré
- std ASWI proces
Iterace (dobré 3b)¶
- iterace prodloužena (3 týdny) -- zadání jasné, cílem bylo zvládnout dostatečný objem práce
pozitiva
- řízený průběh
- pravidelná komunikace se zadavatelem
- řešení kolizních situací v týmu (vč. záznamu v retrospektivě)
- výsledná pracnost úkolů dobře odpovídá odhadům
Technická kvalita (slušné 2b)¶
pozitiva
- dopracován popis architektury, základní informace k design decisions
- použité technologie zřejmě vhodné
negativa
- popis architektury (logický a impl) nekoresponduje s implementací v repository
- chybí testy, viz níže
Postupy a praktiky (slušné 1b)¶
pozitiva
- feature branches mají (de facto), jenom nevhodně pojmenované ("v4", "v5"); při merge smazány
- trasovatelnost commit-ticket začala být používána
negativa
- absence testování - neměli nikdo z nich na to předmět, proto https://students.kiv.zcu.cz:3443/issues/11492, čili nedostatek znalostí řešen proaktivně
- teprve vyjasní, zda a co nasadit na konci současného (ASWI) projektu; řešeno hodně pozdě v projektu
Průběh a stav projektu (slušné 2b)¶
- zhruba LCA
- zhruba standardní ASWI proces
pozitiva
- dobrá organizace práce a komunikace
- tým postupuje sice částečně intuitivně, ale správně
negativa
- lehce nevyrovnaný objem příspěvků (zejm. jeden z členů, 115/150/130 vs 70 hodin a 18/10/10 vs 1 commit), diskutováno
další komentáře
- dosud strávený čas: 478 hodin
Iterace (slušné 2b)¶
- delší (3 týdny) vzhledem k cíli (dosahnout LCA) a již vyjasněným potřebám uživatelů
pozitiva
- cíl v souladu s fází
- aktivně řeší situace v týmu a komunikaci se zadavatelem
negativa
- "verfied -> closed" až na konci iterace hromadně => burndown spíše "rock edge" => neslouží účelu v průběhu iterace
- dost nadhodnocené effort estimates (Estimated time 237.00 hours, Spent time 178.00 hours), diskutováno
Technická kvalita (slabé 1b)¶
- základní sada artefaktů je pohromadě
pozitiva
- SRS a SAD dobře strukturované, čitelně a srozumitelně napsané
- SAD: využití pohledů vč. vhodně zdůrazněného procesního pohledu, stručně ale informačně hutně psáno
- množství (pro ASWI doplňkových) ekonomicko-manažerských dokumentů/artefaktů (OBS, matice odpovědnosti, ...)
negativa
- stále není vůbec trasovatelnost potřeby <-> požadavky <-> issues <-> commits <-> tests, diskutováno
- SRS: struktura ok, ale specifikace požadavků ne - nejde o use cases, ani něco jiného; technologie jsou takto požadovány uživateli??? ; není specifikován rozsah "první verze aplikace" a "finální aplikace"
- žádné informace ohledně cílového prostředí a nasazení
- SAD: chyby ve workflow v procesním pohledu; design decisions jsou jen u technologií a nejsou navázány na požadavky; impl pohled neozřejmuje strukturu implementačního projektu (komplet flask-driven? nebo nějaké odchylky? kde je "schovaný" React?) + charakter "krabiček" (třídy? moduly? flask controllery? importované hotové knihovny/komponenty?) a škoda, že tyto "krabičky" nejsou provázaně odkazované v Datové toky; chybí informace o datovém modelu (použité podmnožiny?) MRS a interních datových/funkčních API (např. schemata pro JSON)
- např. SRS "Odezva systému maximálně do 3 sekund." -- odpovídá tomu architektura s dat. pumpou a získáváním dat vždy on-demand z MRE?
- např. impl pohled "Predikce mRS" vs tok dat "Model pro predikci mRS" -- jde o tentýž subsystém?
- LCA prototyp není explicitně mapován na uživatelsky a/nebo architektonicky kritické use cases z SRS
- PoT implementace je triviální tj. příliš jednoduchá a nad rámec propojení prohlížeč<->MRS v podstatě nic neověřuje
- repo: kompletní RDF connection info vč hesla commitnuté do git repo (!) uff
- klíčové dokumenty nemají "košilku"
Postupy a praktiky (slušné 2b)¶
- jednotlivé praktiky vcelku ok, chybí vědomé použití těch navázaných na risk / priority / value management
pozitiva
- code review pro vybrané merge requests (dle významu změn) dělají, není vidět ve workflow issues ale je vidět v gitlab
- zapsat do interních pravidel týmu, kde není vůbec
- effort estimates: priorita autorovi issue, celkem to funguje (až na případy průzkumných úkolů typu "naučit se technologii")
negativa
- workflow na ticketech často neodpovídá interním pravidlům týmu (výskyty new -> closed, accepted -> closed)
Doporučení¶
- diskutováno lack of traceability ("my to máme v hlavě" nestačí)
Průběh a stav projektu (dobré 3b)¶
- vyjasněny cíle, účel (s koncovými uživateli) a dlouhodobý plán vč. podzimu
- LCO uzavřeno
pozitiva
- projekt "nakolejen" díky vyjasnění cílů a plánu
- vyčištěna informační struktura projektu
- zaměření a obsah prací dobře odpovídá fázi
negativa
- neřešena trasovatelnost mezi požadavky (vize, SRS) a prováděnými/plánovanými činnostmi (issues)
další komentáře
- dosud strávený čas: 282 hodin
Iterace (slušné 2b)¶
- cíl a obsah odpovídá fázi (PoT prototypy)
- retrospektiva: drobné ale užitečné ladění postupů
pozitiva
- schůzka s lékaři, výrazně pomohla vyjasnit vision and scope + synchronizaci s KIV zadavateli
- dokončení artefaktů k LCO
negativa
- sprint backlog nemá mapování na SRS / product backlog
- výsledné dokumenty: nejasný status
další komentáře
- nadhodnocené odhady pracnosti (159 estim, 127 spent): hlavně kvůli PoT úkolům (šlo to rychleji) a kumulativní úspoře času při schůzkách
Technická kvalita (slušné 2b)¶
- vyčištěna informační struktura projektu
- dokončeny klíčové dokumenty Vize a DSP, začištěn Plán projektu
pozitiva
- rozdělení infomrací "k procesu v Redmine Documents, k produktu v git repo Dokumenty"
- začátek použití git branches a policies dle GitFlow
- Vision and scope: struktura, stručnost
- Specifikace požadavků: struktura tj. oblasti zachycených informací
negativa
- dokumenty nemají metadata (košilku)
- neví se (nebo minimálně nejsou specifikovány) detaily business critical nebo risk-relevant požadavků
- občas chyby v issues (špatný Tracker, např. Support pro #11090 nebo Bug pro #11188) + popisy issues používány spíše sporadicky
- Vision and scope
- účel systému nespecifikuje, o jaké lékaře, jaká medicínská data a jaké analýzy se konkrétně jedná => scope nejasná
- chybí stakeholder concerns / profiles
- u některých funkcí systému nejasný účel a/nebo výstup (např. segmentace obrazových dat, kontrola možnosti provést analýzu)
- závislosti neuvádí napojení (a jiné vazby) na existující systémy
- nedefinovaná zkratka MRE
- Specifikace požadavků
- celkový pohled: popisuje "projekt" nikoli "produkt", chybí detaily o "impaktovaném článku" (tj. citace zdroje)
- ASWI, TSP1 a TSP2 jsou pojmy nerelevantní vzhledem k specifikaci požadavků (hint: relevantní by byly verze / vydání produktu)
- minimální akceptační kritéria: téměř nulový rozdíl mezi celkovými a "pro ASWI"
- produkční prostředí není specifikováno, pouze identifikováno
- technologie, formáty dat: které z nich jsou opravdu požadavky, a které něco jiného? tj. patří (všechny) tyto informace do daného dokumentu?
- use cases jen názvy, bez identifikace, podrobností a vazby na funkce uvedené ve Vision and scope
- forma dodávek neřeší skutečnou dodávku produktu
Postupy a praktiky (dobré 3b)¶
- celkově postupy odpovídají fázi a potřebám projektu
pozitiva
- rozumné rozhodnutí udělat 4.it delší (dotažení LCA)
- použití GitFlow
- komunikace s koncovými uživateli a zadavateli
- weekly standups
negativa
Doporučení¶
- diskutováno, jak se dívat na "fyzický pohled" pro SAD
- validace architektury, vazba na SRS: viz teor. poznatky
- retrospektiva - "kaizen" přístup
Průběh a stav projektu (slušné - 2b)¶
- ještě "inception" s vyjasňováním potřeb uživatelů, LCO zatím nedosaženo
pozitiva
- komunikace se stakeholders a v rámci týmu
- založené potřebné artefakty
- průběžné technologické průzkumy (příprava pro architekturu)
negativa
- nevyjasněný cíl ("produkt" nebo "ověření metod")
- údaje k plánu projektu a průběhu roztříštěné (vize vs logický rámec, plán prj vs Redmine roadmap vs wiki iterací, spec pož vs vize, ...), není Redmine Roadmap pro ASWI projekt
další komentáře
- dosud strávený čas: 134 hodin
Iterace (dobré - 2b)¶
- cíle v souladu s fází projektu, provedení OK, formality slabé
pozitiva
- řešeny podstatné věci pro celkový projekt
- podrobné zachycení průběhu (wiki stránka)
- retrospektiva vedla na drobné úpravy procesu/praktik
negativa
Technická kvalita (slabé - 1b)¶
- artefakty odpovídají fázi projektu, vč. stavu rozpracovanosti, ale trpí roztříštěností a chybí některé podstatné informace
pozitiva
- struktura Vize a Spec pož dobrá, "logický rámec" dobře udělaný
negativa
- vize nezachycuje / nevyjasňuje hlavní cíl(e) projektu, typy vyšetření a dat (mrtvice), potřeby stakeholders; nepřebírá relevantní info z "logický rámec projektu"
- spec požadavků postrádá detaily (produkční prostředí, požadavky fční a mimofční) a/nebo odůvodnění tj. trasovatelnost (technologie)
- špatně strukturované úložiště (větve tj. "version space" pro části systému a projektu tj. "product space")
- wiki špatně formátovaná, zanechané "historické relikty" již nepotřebné, URL namísto hyperlinků
Postupy a praktiky (slušné - 2b)¶
pozitiva
- rozdělení rolí a aktivit
- technologické sondy, komunikace s různými stakeholders
negativa
- workflow na issues vymyšlené dobře (velmi robustní) ale ne(do)realizované v praxi
- nejasná / slabá prioritizace + specifikace uživatelských potřeb a požadavků
Doporučení¶
- v plánu projektu zahrnout i cíl pro "TSP2" poločas
Průběh a stav projektu (2b)¶
- projekt a tým inicializovány
pozitiva
- kontakt se zákazníkem
- rozběhnutá komunikace a infrastruktura pro vedení projektu
- představa o celkových výsledcích projektu a jejich fázování (z pohledu ročního prj, ASWI+TSP)
- stav odpovídá fázi projektu
negativa
- chybí plán projektu (probráno)
další komentáře
- analýza rizik plánována, viz logický rámec projektu
- dosud strávený čas: 37.5 hodin
Iterace (3b)¶
- obsah a cíle v souladu s fází projektu
- dokončena bez komplikací
pozitiva
- vyjasněn rámcový cíl
- tým řešil správné úvodní potřeby: komunikace, synchronizace, infrastruktura, úvodní schůzky se zákazníkem
negativa
Technická kvalita (2b)¶
- odpovídá fázi projektu (artefakty i provozní záznamy)
pozitiva
- využití wiki
- prvotní podoba specifikace požadavků
negativa
- (ne)formátování wiki
- vize jen slovně
- interní pravidla a konvence jen slovně
Postupy a praktiky (3b)¶
- tým řešil témata odpovídající fázi projektu, dobře použité schema retrospektivy
pozitiva
- zápisy ze schůzek
- retrospektiva s využitím schematu povedlo/nepovedlo/zlepšit/vyhnout_se
- vhodná reakce na detekovaný problém s plánováním schůzek
negativa
Doporučení¶
- informace s trvalou platností nenechávat v komentářích k Issues, dávat do wiki/dokumentů
- zkontrolovat informace zadávané pro TSP, jinak ale průběh z pohledu TSP budeme řešit automaticky v rámci ASWI schůzek
Zhodnocení projektu