Hodnocení po 3. iteraci

Přidáno uživatelem Premek Brada před asi 4 roky(ů)

Datum schůzky¶

30.4.2020

Hodnoceny 2. a 3. iterace.

ASWI std

negativa
- plán prj stále není (vidět), skrývá potenciální rizika => viz první dvě doporučení; nicméně týmem vyjasněno, že výchozí podoba plánu je ve Vize
pozitiva
- reakce na průběh projektu na základě retrospektiv 2.it, 3.it -- úpravy délky iterací a interních postupů pro sledování průběhu
- artefakty odpovídají fázi projektu
další komentáře
- tým vyjasnil: na konci 3.it zhruba konec Elaboration tj dosažen LCA
- komunikace s FDU funguje, s UPM také ale příliš mnoho prostředníků
- stále chybí data od UPM a neví se, kdy budou => viz doporučení
- časová kapacita: neplánovaně velmi mnoho hodin spáleno na komunikaci se zákazníkem, zbývající vlastní vývoj by neměl být už časově tolik náročný => viz doporučení
hodnocení: 2.it slušné 2b, 3.it slušné 2b

negativa
- nejsou definovány cíle iterací
- průběh => burndown obou špatný
- 2.it uděláno vše ale doděláno na poslední chvíli
- 3.it trvání ne podle domluvy/plánu, prodloužena o týden kvůli nedokončeným taskům (nesplnění interního definition of done)
pozitiva
- nakonec vše přehledně reportováno v Redmine
další komentáře
- na konci 3.it chtěli schůzku s p.Fišárkem ale časově nevyšlo, bude v průběhu 4.it
- z burndown 3.it není přímočaře vidět vícepráce a hodiny strávené v prodloužení, ale u ticketů jsou reportovány
hodnocení: 2.it slušné 2b, 3.it slabé 1b

negativa
- doc arch: zbytečný diagram MVC, ve struktuře aplikace chybí kontroler (zato je tam 2x Views); pořád zůstavají výpočty v textu, bez jasného závěru (výkon, disk)
- chybí produktový backlog nebo jiná forma trasovatelnosti mezi DSP a vývojovými úkoly a implementací; diskutováno s týmem
pozitiva
- DSP velmi kvalitní (struktura, obsah)
- doc arch věcný obsah správně
- otagované fuknčí verze, existují executable architecture prototypes
další komentáře
- pedagogická otázka: do jakého arch view patří gesign guidelines?
- všechny gitlab pipeline jsou failed? -- vyjasněno, nejde nahrát docker img do Container registry ale vývoj to nebrzdí; PBr zjistí řešení
- potíže s neznalostí front-end vývoje (technologie, guidelines), zčásti vyřešeno (správně) zjednodušením grafického návrhu (komunikace s FDU) ale i tak spáleno hodně času na slepých uličkách a získávání zkušeností
hodnocení: 2.it ("LCO") skvělé 3b, 3.it ("LCA") slušné 2b

negativa
- disciplína týmu a monitorování průběhu projektu slabé hlavně ve 3.it, důsledky výše, důvody sebe-reflektovány team leaderem
pozitiva
- snaha o build pipeline
- férové a užitečné retrospektivy, přebrána praktika interních kontrolních dnů v iteraci
- včasná a udržovaná komunikace s UPM (prevence rizik pozdějších komplikací)
- správné řešení konfliktu "vymazlenosti" grafického návrhu a technické proveditelnosti (vzhledem ke znalostem a kapacitě týmu)
další komentáře
- tým dobře reflektuje užitečnost retrospektiv, ty jsou celo-týmové
hodnocení: 2.it skvělé 3b, 3.it slušné 2b

contingency plan pro případ, že data přijdou příliš pozdě
společně (celý tým) probrat odhad pracnosti zbylé na vývoj a dokončení prj
neřídit se dogmaticky doporučeními z coureware (počet a délka iterací), snažit se pochopit podstatu (customer demo, potentially shippable product increment) -- 3.it věcně obsahuje materiál na dvě samostatné iterace

2.it 10b
3.it 7b