Hodnocení 3. iterace
Hodnocení
7¶
Malus/Bonus¶
n/a
Doporučení¶
- po naplánování cílu iterace je už nemenit, využít kontrast s finálním stavem
- Vizi už upravovat netřeba, spíš se poučit pro příště
- vzhledem k plánovanému konci (5. iterace) a vykázanému času je prostor na přidání další iterace - šperkovat (dokumenty, tickety, kvalitu kódu, robustní testování), zkoušet si pokročilé praktiky, zkusit navrhnout další rozšíření a komunikovat je se zákazníkem
Průběh a stav projektu¶
- negativa
- ještě nedosáhnuto LCA
- bude ve 4. iteraci z plánovaných 5 (ale možná se přidá další)
- zdržení kvůli problému s instalací na Windows - varoval o ní zákazník už po 1. iterace --> měla být v rizikách a řešená co nejdříve
- ještě nedosáhnuto LCA
- pozitiva
- zákazník zatím nemá s postupem problém
- komunikace ok
- teoretická část LCA
- reakce na většinu feedbacku, ač občas se zdá trochu "na oko"
- další komentáře
- celkově poměrně málo vykázaného času --> pokud není nic dalšího v požadavcích, zkusit přijít s vlastními vylepšeními
- hodnocení: slušné 1,5
Iterace¶
- negativa
- v retrospektivě se splnění cílů musí vyčítat s kontextu, navíc nemluví o důvodech zdržení a jejich řešení
- navíc LCA cíl byl smazán z cílů nedorozuměním, ale mění to historii projektu a srovnání původních cílů vs. dosažených, což je nutné pro retrospektivu a řízení obecně
- menší rozsah
- plán na další iteraci malý (30h)
- burndown špatný - většina vykázána až týden po a v jednom rázu
- podle týmu jde jen správu Redmine, práce jako takové proběhli včas
- pozitiva
- cíle splněny (až na LCOA)
- náplň ok
- skoro přesný odhad
- další komentáře
- review + retro a plánování 10 dní po konci iterace - nenašel se dobrý průnik časů
- v takovém případě zkusit zapojit offline metody retrospektivy a plánování (např. pře sdílený soudor, online tool) - není ideálně ale asi lepší než mít takovýto odstup
- review + retro a plánování 10 dní po konci iterace - nenašel se dobrý průnik časů
- hodnocení: slušné 1,5
Technická kvalita¶
- negativa
- opravy Vize
- nedorozumění v termínu "koncový uživatelé" (místo toho specifikovány role/postavení/zkušenosti týmu, mentora a zákazníka)
- riziko na nezkušenost s plánováním a řízením je platné, ale generické
- působí víc dojmem "aby tam něco bylo", než pochoponím významu (zvláště kvůli riziku na Windows, viz výše)
- komentování změn ticketů - obzvláště těch, které posouvají stav prací na méně než 100% (neví se pak, v jakém stavu daný úkol je)
- repo tag existuje, ale není z něj jasné, na kterou iteraci se váže (podle data na žádnou) a nikde není vysvětlen jeho význam, pokud to není tag iterační
- opravy Vize
- pozitiva
- používání description u úkolů
- přidaná a dodržovaná kategorizace ticketů v konvencích (i když není jasné, kam spadají analytické/designové a infrastrukturní úkoly)
- feature branche
- trasování commitů
- další komentáře
- poměrně málo ticketů (nejsou moc obecné?)
- hodnocení: slušné 1,5
Postupy a praktiky¶
- pozitiva
- standupy
- změna plánu projektu podle situace
- z konvencí vypuštěné Code Review jako nutnost, ale v opodstatnělýc případech se pořád používá buď to, nebo dokonce párové programování
- hodnocení: slušné 2,5
Použitý proces¶
ASWI std
Datum schůzky¶
28.5.2021
Komentáře