Redmine

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

Hodnocení
7¶

Doporučení¶

• odhady na schůzky se mají násobit počtem účastníků z týmu

Průběh a stav projektu¶

• + týdenní pro užší kontakt se zákazníkem v začátcích projektu a sběr nutných informací
• - do LCO ještě kus chybí, není projektový plán
• 2b

Iterace¶

• Retrospektiva
  • - co se dělalo je dobré téma, ale spíš pro standup
  • - chybělo porovnání záteže, odhadu, cílů, milníky
  • + ale vypadly z toho problémy i pozitiva
• plánování
  • - nebylo plánováno na tvorbu design dokumentu
  • - nepočítali se odhady a kontrola záteže
  • + dotklo se to executable architecture
• + burndown, scope ok na 3 lidi a 1 týden
• 1.5b

Technická kvalita¶

• - odhady na schůzky jsou na reálný čas, ne čas kumulativně strávený všemi účastníky z týmu
• 0 wiki stránku rizik slinkovat do Vize
• - schůzky zatím nejsou na wiki (mohou být jen ofocené + hlavní výstupy)
• + analýza bude nahraná
• - ani stručně nekomentované tickety
• 1.5b

Postupy a praktiky¶

• Demo
  • + poslané materiály predem
  • + upresnování požadavků
• 2b

Použitý proces¶

ASWI std

Datum schůzky¶

8.3.2024

Hodnocení
10¶

Doporucení¶

• o náslech mentora na dalším demu už se nemusíme snažit
• 5 minut na retrospektivu je možná trochu restriktivní, pokud bude treba zvýšit na 15-30 minut, není to problém

Prubeh a stav projektu¶

• + LCA (nebo velmi blízko)
• + projekt nejeví známky budoucích problému (krom možná zvyšující se záteže per iteraci v implementacní fázi)
• + komunikace a fugování týmu ok
• 2,5b

Iterace¶

• 0 neprobehlo std demo (díky chybe zákazníka) - bude dorešeno online
• + dobrý obsah retrospektivy
• + nápln a plán dál
• - scope menší - problém "najít, co víc delat"
• 2b

Technická kvalita¶

• + adr. struktura je více UX záležitost pro zákazníka / usability aspekt
• + UML architektury a domény pekný
• + zajištení prod serveru od CIVu
• + deployment plán formou diskuze v ticketu s popisem možností a vybraného postupu
• + executable architecture - spustitelné minimalistické verze obou cástí aplikace + rozhraní mezi nimi
• 3b

Postupy a praktiky¶

• + timebox retrospektivy na 5 minut + použití RetroTool
• + korekce zodpovednosti v týmu (za tvorbu ticketu)
• + úprava procesu používání ticketu
• + zmena architektury, nyní bez ORM - mrzí, ale je to tak lepší
• + poucení - ne príšte potvrzovat schuzku den predem
• + dobrá diskuze nad procesy a významem jednotlivých prvku obecne
• + oprava z minula - zápisy schuzek jsou suplovány na Discordu
• 2,5b

Použitý proces¶

ASWI std (+Jira)

Datum schuzky¶

28.3.2024

Hodnocení
11¶

Malus/Bonus¶

• potenciál za retrospektivní tabulku, analytické artefakty a zpracování rizik - TBD

Doporučení¶

• posílat/zpřístupňovat materiály pro demo zákazníkovi předem, pokud je vhodné
• příští iteraci pouze demo s náslechem mentora, review až po konci 3. iterace

Průběh a stav projektu¶

• + velmi dobrý start projektu
• + LCO
• + očividné skvělé interní fungování týmu i komunikace ven
• 3b

Iterace¶

• + náplň, burndown, scope, cíle a jejich splnění, plán na další, výstupy
• 3b

Technická kvalita¶

• + příprava na retrospektivu
  • + funkční vlastní tabulka (ač díky nedorozumnní ohledně bezplatnosti RetroTool)
• + plán nasazení
• + připravené filtry na issues
• + dev branch
• + podrobné analýzy, UI návrhy, konvence, plány iterací, plán/metodika testování
• + pěkná struktura wiki
• + Vize, analýza rizik, rizika v Redmine, specifikace požadavků, plán projektu
• 3b

Postupy a praktiky¶

• + celkově dobře zvládnuté demo
• 0 checklist z převzaté šablony pro retrospektivu nebrat jako předpis/formulář, jen jako osnovu/inspiraci pro témata - rozhodně není nutné vypisovat zvlášť paralelně s vlastní tabulkou
• + velmi důsledné psaní poznámek ze schůzek
• + posun hranice iterace - výstup vlastního přemýšlení nad praktičností
• - během plánování sklouzla diskuze možná do příliš technických detailů vhodných pro oddělenou část, ale vzhledem ke kontextu pochopitelné
• + diskuze o RTP se zákazníkem
• 2b (v podstatě jen kvůli vyhnutí se půlbodům je tímto vyjádřena kumulovaná ztráta napříč kategoriemi hodnocení - jinak by to bylo blízko 2.5)

Použitý proces¶

ASWI std

Datum schůzky¶

5.3.2024

Hodnocení
9¶

Doporučení¶

• není-li jasné, čím "vyplnit" iteraci (resp. co ještě se dá dělat), zeptat se mentora
• obdobně, pokud se zdá, že některé artefakty se dělají "jen aby byly", prodiskutovat s mentorem

Průběh a stav projektu¶

• + doladění LCO, kroky směrem k LCA
• + to co tým dělá, zdá se dělá dobře (otázka je jestli se toho nemá dít víc)
• + komunikace
• 0 projekt se zdá v dobrém stavu v danou chvíli, ale existují indikace budoucích problémů (např. strávený čas, monitoring vitálních indikátorů, nejasnosti v účelu artefaktů a pochopení procesu, atd.)
• 2,5b

Iterace¶

• + náplň a plán na další ok
• - zdá se malá
• 1,75b

Technická kvalita¶

• - potřebná data se z Jiry dostávají trochu přes ruku, pro hodnocení ok, ale znesnadňuje to monitoring
• + plán formou Jira sprintů
• + epicy jako high level požadavky se specifikací, postupně rozlámané na menší kusy
• + orientace v Jiře, přidání worklog reportů
• + CLI mockupy, ERA, UI návrhy, adr. struktura - poměrně kreativní způsob zachycení návrhu
• + specifikace požadavků (existuje, i když zatím jen v draftu)
  • - neodkazuje ID požadavků z Vize
• + první commity, odkazují issues (ač s Jirou nepůjde plná vazba), dodržují konvence
• + práce s tickety
• 3b

Postupy a praktiky¶

• Vize
  • + nová verze
  • + rozpis požadavků podle priorit, více požadavků, vyjasněné MVP
  • - pořád odkazuje na neexistující Plán artefakt
• - nezdá se, že by někde byly zápisy, což znemožňuje hlavně kontrolu standupů a výstupu retrospektivy
• 0 snaha vyhovět požadavkům procesu (artefkaty, atd.), ale trochu dogmaticky, bez pochopení jejich účelu a významu
• 1,75b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

14.3.2024

Hodnocení
8¶

Doporučení¶

• zrevidovat, co všechno má řešit retrospektiva
• do plánování faktorovat scope
• v Jiře najít jednoduchý způsob, jak monitorovat základní fakta "zdraví" projektu
  • plynulost a rozložení prací přes lidi, kvalitu odhadů a další
  • možná sestavit dashboard?

Průběh a stav projektu¶

• + dobrý start
• + PRI určitě, do LCO nechybí moc
• + komunikaca a spolupráce se zdá dobrá dovnitř i ven
• 2,5b

Iterace¶

• Retrospektiva
  • + diskuze deploy plánu jako mimofunkčního požadavku
  • - trochu přetéká do věcné diskuze mimo rozsah retro
  • - nepadlo explicitní vyjádření k dosažení cílů/milníků
  • + diskuze code review, maintenance repa -> konvence
• náplň a průběh ok
• 2b

Technická kvalita¶

• + přechod na Jiru a její zprovoznění
• + Vize pěkná formátově
• 0 repo zatím nepoužito, resp. v přípravě
• + gDrive pro artefakty
• 2b

Postupy a praktiky¶

• Demo
  • + vyjasňování požadavků, probírání deploymentu, potvrzení UI a obsah obecně
  • 0 vývoj na produkci není u green fieldu takov problém, ale hodilo by se uvažovat i o testovacím prostředí, hlavně do budoucna
  • + rekapitulace a next steps
  • 0 trochu neasertivní vystupování, ale to je o zkušenostech
• Vize
  • + obsahuje většinu zásadních informací
  • - není z ní jasné MVP (jsou to pažadvky nej vyšší priority?)
  • + rizika u jednotlivých požadavků
  • - chybí rizika projektu jako celku, nevázané na konkrétní požadavek
  • 0 identifikátory požadavků jsou dobrá věc, pokud se na ně bude dál odkazovat pro trasovatelnost, jinak jsou trochu zbytečné
• Plánovaní
  • - trochu chybí uvažování nad scopem (hodinově)
  • 0 pozor, přehled na CW je modelová situace, nikoli šablona
• - Vize zmiňuje vlastní artefkat pro plán, ten ale není k nalezení
• + plánované používání wiki na GitLabu k rozumným účelům (např. kódové/gitové konvence, instalační návod, apod.)
• 1,5b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

29.2.2024

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

• neuzavřená issues

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)¶

• odpovídají fázi projektu

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