Redmine

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)
  • námět na retrospektivu?

Doporučení¶

• diskutováno lack of traceability ("my to máme v hlavě" nestačí)

Hodnocení¶

Doporučení¶

*

Průběh a stav projektu¶

• + přechod na gitlab.com po táhlých problémech s KIV instancí
• + spent time skoro 80% spodní hranice
• - zádrhele s testováním, deploymentem, dokumentací
• 0 na IOC to nevypadá a REL se zdá z dostupných materiálů dost daleko na to, aby se stihl v další iteraci, ale v plánu je rezerva na potenciální další iteraci (7.)
• b

Iterace¶

• 0 v it 5 zákazník nemohl na schůzku
• + retrospektivy, náplň se zdá rozumná
• b

Technická kvalita¶

• + změna VCS, udržení trasování a dalších konvencí
• + CI pipeline
• + release v gitlabu včetně notes
• b

Postupy a praktiky¶

• + změna konvencí (subtasky)
• + starost o tickety a vykazování
• - nulová snaha o přeplánování schůzek, nebo jejich dopředné potvrzení
• b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

25.4.2024 (offline)

Hodnocení
8¶

Průběh a stav projektu¶

• + zákazník spokojen
• + příští iterace beta release (MVP)
• + rozložení zátěže
• 0 dokumentace a testování necháno na poslední iteraci, protože zákazník chci field test aplikace už tento semestr
• 2.5b

Iterace¶

• - nepodařilo se propojení s Moodlem ale se zákazníkem dohodnut workaround a vyřazení z TSP1
• + odhady, cíle, splění (krom výše), scope, náplň, burndown
• + plán na 5. iteraci
• 2b

Technická kvalita¶

• + hierarchie tasků, description, priority, category
• + tag iterace, 15 branchí, trasovatelnost
• - artefakty obecně dost rudimentary a působí, že "jsou jen, aby byly"
• 0 tickety lepší proti startu, ale pořád je prostor na zlepšení
• - zápisy z retrospektiv nejsou dosažitelné
• 1.5b

Postupy a praktiky¶

• 0 minimalistické, fungující
• 2b

Použitý proces¶

ASWI std

Datum schůzky¶

19.4.2024

Hodnocení
10¶

Doporučení¶

• příští review jen letmo + info k uzávěrce

Průběh a stav projektu¶

• + cca 50% funkčnosti
• + komunikace se zadavatelem a fungování týmu
• + rozložení zátěže konverguje správně
• + řešení bugfixů jako výstupu testování
• 3b

Iterace¶

• + retro, +- burndown, cíle, splněny (až na jeden task)
• 0 přeplánovaní tasku ne ideální mechanicky, ale zásadně to nevadí
• 2.25b

Technická kvalita¶

• + priority, tracker, kategory
• 0 prefixy tasků se zdají redundantní
• + 40+ branchí, trasovatelnost, spent time přes commit message
• + release tag
• + testování + report
• 2.5b

Postupy a praktiky¶

• + přeplánování tasku + úprava prj plánu
• + standupy a zápisy schůzek
• 2.25b

Použitý proces¶

ASWI std

Datum schůzky¶

19.4.2024

Hodnocení
11+11¶

Malus/bonus¶

• TBD

Doporučení¶

• další schůzka až na konci 5. iterace

Průběh a stav projektu¶

• + protažení iterace o týden kvůli velikonocům (v plánu předem)
• + LCA začátkem 3. iterace
• + vše podle plánu - ne-li před
• + vše pečlivě hlídáno a upravováno
• + spent time má tendenci se zarovnávat
• + 60% funkcionality
• + zákazník spokojený
• 3b

Iterace¶

• + burndowny skvělé
• + odhady, plány iterací, scope, cíle, splnění, náplň
• 3b

Technická kvalita¶

• + provázání rizik na tasky (totéž s EFR)
• + vlastní šablona pro plány iterací a retrospektivy
• + plán nasazení a testování a jejich úpravy v čase
• - u samostatně nevypovídajících změn ticketů chybí komentáře
• + hierarchie a rozpad ticketů
• + trasovatelnost od commitu až do Vize
• + iterační tag, feature branches
• + arch. modely + 5-6 prototypů
• - design dokument by mohl být pojat více holisticky než jen dvojice diagramů
• + descriptions, priority, typy, category
• 2.5b

Postupy a praktiky¶

• + doidentifikovaná další 2 rizika a reflektování ve vizi
• + doladění specifikace na základě inputu od zákazníka
• 0 když už jsou rizika v Redmine, bylo by dobré je "oživit" (tj. upravovat podle stavu projektu) - totéž s MF a Features
• + řízení se koncenvemi
• + Demo 2 ok
• 2.5b

Použitý proces¶

ASWI std

Datum schůzky¶

9.4.2024

Hodnocení
10¶

Doporučení¶

• nepovedené odkazy z commitů na tickety se dají ručně "dohnat" v Redmine

Průběh a stav projektu¶

• + zákazník spokojen
• + tým funguje dobře
• + LCO a LCA
• + spent time zhruba odpovídá
• 2.75b

Iterace¶

• + prodloužení iterace na 3 týdny kvůli velikonocům
• + retrospektiva vysvětluje důležité aspekty
• + scope, náplň, odhady
• 0 burndown nekritický a vysvětlený
• + rozdělení a vysvětlení spent time
• 2.5b

Technická kvalita¶

• + analýza CLI
• + design dokument
  • + poměrně podrobný pro relativně jednoduchou aplikaci
  • + specifikace zpracování jednotlivých příkazů
  • - mohl by obsahovat i GUI aplikaci, ale mezi MVP požadavky je jen jednoduchá verze, takže možno doplnit později
• + feature branches (20+)
• + tag se plánuje po mergi do main
• + trasovatelnost (ač obcas ujede)
• tickety - popisy, kategorie, priority, typy
  • - u nejasných změn by byl vhodný komentář
• 2.5b

Postupy a praktiky¶

• Demo2
  • + predvedení funkce
  • + plán nechat vyzkoušet zákazníka (po implementaci cyklů)
  • - je dobré na konci schůzky si explicitně potvrdit príští setkání
• + úprava plánu
• + zápisy schůzek
• 2.25b

Použitý proces¶

ASWI std

Datum schůzky¶

5.4.2024

Hodnocení
8¶

Doporučení¶

• při plánování využívat možnosti Redmine k ulehčení (přesun více ticketů najednou, uložené filtry, atd.)
• ulehčit si retrospektivu RetroToolem nebo něčím jiným

Průběh a stav projektu¶

• 0 MVP před LCO (zjevně pomíchání termínů s prototypem)
• - není LCO (Vize nedotažená, specifikace nenačatá, konvence strohé)
• - není ani náznak práce na návrhu, rovnou se kódí
• + komunikačně s kolaboračně tým funguje zdá se dobře
• 0 problémy se zdá se neobjevují, ale působí to spíše jako shoda náhod než aktivní snaha jim předcházet
• 2b

Iterace¶

• + burdown nekritický, náplň odpovídá cíly
• + dobrý scope, odhady mimo o 12.5% což není krizové
• Retro
  • + není přístup je validní omluva
  • 0 co se dělo je dobré ale není to úplně cíl
  • - chyběl celkový pohled s využitím metrik
  • + individuální pohledy ok
  • + dobrá separace témat
• 2.5b

Technická kvalita¶

• - Vize
  • - postrádá MVP, míchají se F a EF požadavky
  • - chybí rizika a stakeholders
  • + komunikční plán
• - není specifikace
• + plán projektu (mohli by jen přibýt milníky)
• + branche, zacházení s commity, CICD, trasovatelnost
• - bludný commit bez propojení s ticketem, nekonzistence jazya commit message, není iterační tag
• 0 velmi strohé konvence
• + výrazné zlepšení na ticketech (komentování, jednotnost, kategorizace)
• - zápisy ze schůzek jsou jen z mentorských, ne z dema a ne z retrospektivy
• 1.75b

Postupy a praktiky¶

• 0 standupy nejsou nutné, je stálý kontakt na Discordu
• Plánování
  • + v podstatě ok
  • + dobré je, že se reflektuje feedback od zákazníka a input všech
  • 0 nezapomenout vzít v úvahu zátěž
• Demo
  • 0 schůzku rozhodně moderujte vy
  • - nastínit a držet strukturu schůzky
  • 0 posílat výstupy předem, pokud je to možné a přínosné
  • + test přes zákazníka
  • - vyjasňování požadavků na docela velké úrovni, tohle mělo být předmětem minulé itarece, kde se dělo velmi málo
  • + spokojenost zákazníka
  • - explicitně říct kdy příště a co čekat
• 1.75b

Použitý proces¶

ASWI std

Datum schůzky¶

2.4.2024

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

Hodnocení
4¶

Doporučení¶

• artefakty vám slouží k zachycení nasbíraných intformací, neděláte je jen pro vyučující, tudíž odklad jejich tvorby, zvlášť v iteraci, kdy se strávilo minumum času dost nechápu
• trojitá kategorizace ticketů je zbytečná -> vybrat jednu a té se držet konzistentně
• rekapitulace zásadních artefaktů

Průběh a stav projektu¶

• - nezvládnul se náslech dema, retra ani plánování
• - do LCO daleko (není plán, vize, konvence,
• - pozdnější začátek - samo o sobě by nebyl problém, ale v kombinaci s výstupy iterace to nevypadá dobře
• + rozdělení domén v týmu (AI vs. admin+web)
• 1b

Iterace¶

• - malá scopem (20h na 5 lidí na 2 týdny)
• - burndown a další hlediska tím ztrácí smysl
• - výstupy nejsou dohledatelné
• 0.5b

Technická kvalita¶

• - pro artefakty jsou údajně fakta, ale tvoit se budou až v další iteraci
• + seznámení s moodlem
• - nekomentované změny issues
• - kategorizace prefixem+category+tag - duplicitní, nekonzistentní, chaotické
• - souhrn informací na OneDrvie (to je v pohodě), ale není na to odkaz z Redmine (tj. jak o tom má člověk vědět?)
• + trasovatelnost commitů na tickety (dokonce s kategrizací v commit message)
  • - ve formátu jsou lehké nekonzistence
• - různé drobné nekonzistence ve vedení informcí (dvojjazyčnost cílů iterací) - v izolaci jen kosmetický problém, ale dohromady přispívají k chaosu v projektu a datech
• 1b

Postupy a praktiky¶

• + seznamování s moodlem
• + nástrely rešení (ač se zdá, že ještě není základ, tj. předchozí artefakty)
• 1.5b

Použitý proces¶

ASWI std

Datum schůzky¶

26.3.2024

Hodnocení
8¶

Doporučení¶

Průběh a stav projektu¶

• 0 LCO dosažení zacátkem príštího týdne vlivem vyjasnení vecí se zadavatelem
• + plánované LCA na príští iteraci
• 2b

Iterace¶

• 0 burndown ne kritický
• + rozložení casu ok, odhady
• + další iterace budou 2týdenní což vysvetluje disproporci stráveného casu
• 2b

Technická kvalita¶

• - Gitlab testy - místo v cvicném projektu
• + integrace gitu s discordem
• + konvence gitu
• + v rizikách pribyly svátky
• + plán projektu
• - není zápis z retrospektivy
• 0 design dokument bude po víkendu na Redmine
• + git konvence - fix branch
• 2b

Postupy a praktiky¶

• + prubežná práce na designu
• + NTH požadavky a jejich plánování po IOC (na 5.iteraci)
• 2b

Použitý proces¶

ASWI std

Datum schůzky¶

15.3.2024