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
Hodnocení 4. iterace