Redmine

Hodnocení
11¶

Malus/Bonus¶

n/a

Doporučení¶

• projekt by se měl při 3 lidech dostat na minimálně 180h - možnost vyplnit šperkováním, experimenty, atd.
• nicméne nebude-li nic prinášejícího cenu týmu/zákazníkovi, co dál dělat, a scope projektu bude aspoň na minimu --> poslední iterace se dá zkrátit

Průběh a stav projektu¶

• pozitiva
  • povedlo se zapujčení HW - nyní přijde testování na něm/v labce
  • spokojenost zákazníka
  • nová aplikace nyní na úrovni původní implementace (podle plánu)
  • rozdělení záteže
• další komentáre
  • současný stav nepředán zákazníkovi, ale po domluve s ním (není důvod, nemá jak vyzkoušet)
    • nicméně viděl demo video
• hodnocení: skvělé 2,5

Iterace¶

• negativa
  • burndown - dotahování věcí na poslední chvíli (už z minula) - obecně ale proces funguje/nezpůsobilo problémy
• pozitiva
  • scope, odhady, náplň ok, cíle splněny
  • retrospektiva a plán další iterace ok
  • v plánu na príšte přibyde refactoring a uživatelská dokumentace
• hodnocení: skvělé 2,5

Technická kvalita¶

• pozitiva
  • update komunikačního protokolu
  • propojení Unity s C++
  • trasování, feature branche, iteracní tagy
  • již zavedené a neměné zacházení s tickety
  • videoukázka funkční aplikace na Youtube (link na wiki)
• hodnocení: skvělé 3

Postupy a praktiky¶

• pozitiva
  • bez zásadní změny, vše už je usazené, dobře nasazené pro kontext projektu
• hodnocení: skvělé 3

Použitý proces¶

ASWI lightweight (díky skladbě týmu a nátuře projektu)

Datum schuzky¶

11.5.2021

Hodnocení
12¶

Malus/Bonus¶

n/a (budou snad vyřešeny do příště)

Doporučení¶

• příště uzávěrka
  • kromě review poslední iterace, projití dotazníku s retrospektivou projektu (vyplnit předem, odkaz bude na Teams)
  • zákazníkovi předat odkaz na dotazník pro jeho hodnocení (odkaz bude na Teams)
  • zákazníkovi předat produkt (ve formě s ním domluvené) a předávací protokol k podepsání (mít ho na review)
  • vytvořit archiv projektu se všemi výstupy (obsah repository, všechny mezivýstupy, dokument, atd. i ty co se nepředávaly zákazníkovi) - může/nemusí obsahovat exporty wiki stránek

Průběh a stav projektu¶

• pozitiva
  • IOC, zákazník velmi spokojen
  • doběhne kosmetická úprava a refactoring + docs a admin
  • všechny UC, hotové testy
  • shoda s projektovým plánem
• hodnocení: skvělé 3

Iterace¶

• pozitiva
  • odhady, burndown, náplň, scope ok
  • cíle splněny
  • retrospektiva validní
  • plán na poslední iteraci
• hodnocení: skvělé 3

Technická kvalita¶

• pozitiva
  • testy přes Robot Framework podle požadavku zadavatele
  • tag iterace i milníku, trasování, feature branches
  • priority, description, due date, komentáře změn, kategorizace
  • robustní CI/CD
• hodnocení: skvělé 3

Postupy a praktiky¶

• pozitiva
  • práce s risk listem
  • update Vize a Reqs o CR
  • ostatní viz minulá hodnocení
• hodnocení: skvělé 3

Použitý proces¶

ASWI std

Datum schůzky¶

10.5.2021

Hodnocení
9,5¶

Malus/Bonus¶

n/a

Doporučení¶

• testování je nutné ale jde o to promyslet do jaké míry je v kontextu projektu možné
• paralelní, na sobě závislé týmy je cenná zkušenost, + v projektu se dobře projevil význam oboustraně otevřené a jasné komunikace
  • na začátku dojem od zákazníka, že je vše ready, ve skutečnosti se spousta dodělávala za běhu/měnila pod rukama

Průběh a stav projektu¶

• pozitiva
  • vykrystalizovaná akceptační kritéria
  • posun ve funkčnosti na základě minulého dema
  • pokryta většina UC
  • v příští iterace IOC + finální 1týdenní iterace na uzávěrku
  • po nějaké delší době (projekt je malý) vypořádání se se současnou prací týmu na FE a zákazníka na FE
  • výrazné dohnání skluzu až na několik nízkých priorit - téměř zpět na původním plánu
  • zapracování feedbacku z minula
• hodnocení: slušné 2

Iterace¶

• pozitiva
  • retrospektiva ok
  • cíle hrubě splněny (pár nižší priorit přeplánováno)
  • odhad je v relaci
  • 60h, náplň odpovídá
  • validní plán 5. iterace - už teď 1/3 hotová
• další komentáře
  • burndown +- rock-edge, ale dáno okolnostmi/retro/diskuze
• hodnocení: skvělé 2,5

Technická kvalita¶

• pozitiva
  • iterační tag (duplikát možná kvůli procesu natahování repo dat do Redmine)
  • branche, commit messages, trasování commitů
  • testovat se chce, jen jsou poměrně úzké možnosti jak -> možná jediná schůdná jsou manuální FE testy podle test casů
  • vyřešení problému s přenositelností mezi prohlížeči - různé formáty datumu
  • produkt doznal viditelného vylepšení
• další komentáře
  • kategorizace ticketů stále není jasná, ale v tuhle chvíli už je nepodstatná, správně se zaměřuje hlavně na produkt
  • skokové vykazování času má v tomto případě svoje důvody
• hodnocení: skvělé 2,5

Postupy a praktiky¶

• pozitiva
  • v retro zlepšení práce s VCS
  • zájem o bezpečnost, ač se řeší jen FE a je to na straně zákazníka - naivita zákazníka stylem "nikdo nezadá souřadnice ve špatném formátu"
  • odstranění PNJ :)
    • dotazy na to co je třeba, nespoléhá se na backend
    • každý endpoint jiný formát data
    • informace o doimplementovaných BE endpointech roztříštěné mezi kanály - momentálně už se povedlo dokonvergovat ke snesitelnému stavu
    • zákazník upravil wiki a nedal o tom nikomu vědět - odhalilo se náhodou
    • studium dokumentace se ukázalo jako zbytečné - neodpovídala realitě
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std

Datum schůzky¶

7.5.2021

Hodnocení
9¶

Malus/Bonus¶

n/a

Doporučení¶

• vzhledem k dostatku času (kalendářně i hodinově) hledat místa kde přidat větší hodnotu 1) zákazníkovi (funkčně i mimofunkčně), 2) sobě (zkušenosti s nástroji a praktikami, útok na vyšší hodnocení) - š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¶

• pozitiva
  • LCA (ač poměrně pozdě)
  • zapracování většiny feedbacku z minula
  • nastavená další (6.) iterace - prostor je, "musí" se najít výplň
  • rozdělení zátěže a komunikace
  • produkt se úměrně blíží finalizaci proti původnímu cíly, otázka je, jestli něco nepřidat
• další komentáře
  • zatím "jen" 160h (částečně náturou projektu)
• hodnocení: skvělé 2,5

Iterace¶

• negativa
  • lehké problémy kvůli souběhu předmětů/konci semestru (mohlo být zaneseno v retrospektivě)
• pozitiva
  • cíle splněny
  • odhady přesné
  • navzdory burndownu práce probíhali průběžně
  • 5. iterace naplánována
• další komentáře
  • málo ticketů dáno z podstaty věci
  • burndown špatný ale vysvětlený okolnostmi (Redmine, retro 2 dny po due date, málo úkolů, které skáčou z 0 na 100)
• hodnocení: slušné 2

Technická kvalita¶

• negativa
  • pár commitů opomenuté trasování
  • pokulhává komentování významových změn
• pozitiva
  • iterační tagy
  • reakce na feedback
    • Vize - cílový uživatelé a přidaná rizika
    • konvence - detaily klasifikace ticketů
  • použití priority, description, kategorií
• další komentáře
  • jen jeden committer - následek git squash
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • na demu se hůř komunikovalo, jak se zamýšlí změna UI (squash grafů vs. skrolování) - i když to funkční demo zatím nedává, pomohly by náčrty/statické prototypy toho, jak je to zamýšleno
• pozitiva
  • standupy
  • demo
    • obecně správná struktura, dobrá komunikace
    • demo s dummy daty + BE ukládání do souborů
• další komentáře
  • žádná výrazná změna
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std

Datum schůzky¶

7.5.2021

Hodnocení
8¶

Malus/Bonus¶

n/a

Doporučení¶

• je-li nutno, připravit realistický odhad, co se stihne a vyvolat vyjednávání o scopu a MVP se zákazníkem (mimo demo, ASAP) + řešit priority dalších věcí pro případ optimistického scénáře
• zjistit, co z procesní stránky se dá ořezat bez dopadu na schopnost věst projekt a ušetřený čas věnovat na produkt/sražení skluzu (viz doporučení už z minula)
• zjistit, pokud existují ješte další implementační nejistoty (jako certifikát, WebGL) kritické pro MVP a adresovat co nejdříve

Průběh a stav projektu¶

• negativa
  • zatím ne LCOA - chybí funkční kostra aplikace
    • propojení s daty a modely na příšte
    • blokováno specifickými problémy (viz níže v praktikách)
  • skluz, možná nutnost převyjednání požadavků/MVP
• pozitiva
  • plán projektu alespoň formou Roadmap
  • GUI demo/prototyp, nad kterým se dá bavit
  • zapracován feedback z minula
• hodnocení: slušné 1,5

Iterace¶

• negativa
  • nutnost přeplánování několika úkolů/cílů
  • velký scope (65h) - dohánění restů + problémy + nové požadavky
• pozitiva
  • relevantní retropsektiva
  • burndown relativne ok
  • odhady v relaci, náplň ok
  • plán na 4. iteraci relevantní
• hodnocení: slušné 2

Technická kvalita¶

• negativa
  • nerozepsání požadavků znemožňuje jejich (hrubý) odhad a posouzení, jestli se vejdou do scopu a např. následné vyjednávání se zákazníkem
  • plus není vizuální přehled o tom, kolik toho ještě zbývá (v rozumné míře detailu) - individální požadavky mohou být malé (přepínání Tabem ve formuláři), ale jejich nahromaděním vzniká zátěž
• pozitiva
  • vylepšený popis MVP a (nerozepsaných) požadavků
  • Architektura - package/class diagramy serveru, parseru, komunikace server-client, GUI design, info o klientských aplikacích, konfigurace
  • zápisy ze schůzek
  • komentáře změn ticketů (vč. aktivity), detilní descriptions, používání priorit a due date
  • tagy v repo (jen značit je datem je trochu nešikovné - človek musí párovat s due daty iterací)
  • topic branche
  • úprava konvencí pro workflow a activity u spent time
  • RetroTool -> export do wiki
  • plánování přes sdílený spreadsheet - zachycuje vetší rozbor, priority, součty
  • postup při přeplánování ticketu + odpovídá konvencím
• skvělé 2,5

Postupy a praktiky¶

• negativa
  • demo - zákazník potřebuje přehled na kdy je co domluveno
    • např. v zápisech schůzek nebo plánu projektu
    • v menším detailu existuje v Roadmap, ale o tom zadavatel nevěděl, dokud se explicitně nezeptal
  • některé problémy by byly ideální príklady na správu rizik a adresování v začátcích Elaboration fázi
    • komunikace přes WebGL, problém s certifikátem
• pozitiva
  • demo - struktura a náplň schůzky
  • standupy - podle retrospektivy prospěšné a častější
• hodnocení: slušné 2

Použitý proces¶

ASWI std + vlastní business case

Datum schuzky¶

4.5.2021

Hodnocení¶

9 bodů

30.4.2021

Doporučení¶

• ověřit si, zda je naplněna vize, zejména z ophledu pokrytí požadavků všech cílových skupin

Průběh a stav projektu¶

• práce postupují, dojem týmu: zbývají implementační drobnosti + začištění kódu
• začali řešit cílovou provozní platformu, potíže s (ne)komunikací od provozovatele technické infrastruktury ale zavětřili že si mají udělat "plán B"

pozitiva

• práce zjevně pod kontrolou

negativa

• -

další komentáře

• dosud strávený čas: 215 hodin

Hodnocení: dobré (3)

Iterace¶

• provedena, ukončena, zhodnocena

pozitiva

• cíl dobře definován, odpovídá fázi, dosažen
• celkem sedí odhad vs skutečná pracnost
• slušný průběh dle hours burndown (lepšímu průběhu burndown pomohlo, že se víc snažili na projektu dělat průběžně + měli hotové průběžné termíny sam.prací z jiných předmetů)

negativa

• -

Hodnocení: dobré (3)

Technická kvalita¶

• programátorsky dobré, projektově/inženýrsky slabší

pozitiva

• kód je celkem přehledný, i když při malé složitosti aplikace by byl překvapením opak ;-)
• wiki udržovaná

negativa

• pořád není doc arch a není ani "na radaru", je v plánu vyrobit instalační návod (readme v git src) -- "co předáte následníkům?" ...
• v zápisu retrospektivy je pořád hodně prostoru věnováno detailnímu zhodnocení dosažení plánu, což by mělo být vidět jinde a děláno jindy -- planning meeting, customer demo
• žádné artefakty související s ověřováním kvality

Hodnocení: slabé (1)

Postupy a praktiky¶

pozitiva

• retrospektiva byla, mad/sad/glad celkem zafungovalo -- detekována issues (stálé změny požadavků od zákazníka, nejednotné verze sw), opatření stanovena (i když není jisté, jestli budou vlastně ještě potřeba)
• odhady vcelku fungují, spíš jsou malinko nadhodnocené
• používány git feature branches + task branches, dobré, merge prováděn na <nějakou větev> která nahradila dev branch; dodržují pravidla na udržení "master" vždy fungujícího dle konvencí (pouze chybí deklarace "invariantu" pro master branch)
• víceméně systematicky "feature" jako user reqts + používané priority, takže se dá říci, že projekt používá +-DEEP backlog

negativa

• nedotažené propojení commit-ticket (důsledné používání ticket id ale nesprávná syntaxe => chybí vazba z ticketu, nechtělo se jim měnit konvence ...)
• testování uděláno ručně, je na to ticket (#8640), ale žádná opakovatelnost natož automatizace a neřešeno UX testing

Hodnocení: slušné (2)

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
• 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
• 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í
• 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

Hodnocení
7¶

Malus/Bonus¶

n/a

Doporučení¶

• zjistit řádný a mezní termín odevzdání, domluvit s p. Bradou možnost zkoušky bez zápočtu (kvůli Bc studentům) a následně přemýšlet o přidání iterace (třeba i zkrácené)
• nespoléhat na vyčtení věcí z kontextu, pocit, předpoklady a radši se na všechno vždy explicitně zeptat
• nejasnosti, i když momentálně nepředstavují blockery, hlásit/řešit se zadavateli okamžitě místo čekání na demo
• zákazníkovi tickety vyhodit mimo iterace (pokud to nepotřebuje on), aby nezkreslovali statistiky - pokud nejde, počítat s jejich přítomností při monitoringu pokroku

Průběh a stav projektu¶

• negativa
  • komunikace ven místy pokulhává - příliš se předpokládá a usuzuje s kontextu místo explicitní dotazu/vyjasnění
• pozitiva
  • LCA
  • komunikace uvnitř týmu ok
  • přes dolazování požadavků za pochodu (viz níže) projekt overall on-track
  • dělba práce
• hodnocení: slušné 2

Iterace¶

• negativa
  • nejasnost v prioritách
    • tým čekal na endpointy
    • podle zákazníka mohl v mezičase dělat na GUI
    • díky specializaci členů týmu a propojenosti řešení to ale brzdilo i je (nevědělo ani jaké budou vstupní/výstupní typy dat, takže GUI nešlo stavět)
    • řešení mělo být 1) jasná komunikace zákazníkovi o návaznosti prací a např. ujasnění dat pro endpointy ještě před jejich implementací, 2) prototypování - kreslení GUI, příprava toho, co na datech nestojí, 3) přeplánování podle okolností
  • burndown špatný (sráz na konci) kvůli čekání na vstupy zákazníka a plánu, který na to nereagoval (viz předchozí bod)
  • plán další iterace se zdá neúplný (myšleno v ticketech - 27h, i když ve wiki spíš jen cíle) - navíc už teď je ve skluzu
  • mírné podhodnocení odhadů
• pozitiva
  • retrospektiva validní
  • náplň, cíle, splněny ok
• další komentáře
  • čekání na vstupy zákazníka iteraci poznamenalo, ale nemuselo tolik
  • demo a review týden po konci iterace (časová situace zákazníka)
• hodnocení: slušné 1,75

Technická kvalita¶

• negativa
  • neni CI/CD - byl záměr, ale pro ostatní věci se nestihlo a teď už nemá cenu
    • výsledkem je ale závislost na "nezapomenutí" na ruční deploy na staging server
  • návrh GUI vznikl vnitřní diskuzí týmu na základě "dojmu" z komunikace se zákazníkem
    • obzvlášť u takto GUI-heavy projektu jsou GUI prototypy/vizualizace (byť i kreslené) velmi žádoucí --> vede na méně rozporů v představách obou stran a menší nutnosti předělávání - zpětně nemá cenu dodělávat/dodávat, když už existuje live demo
  • problém s přenositelností mezi prohlížeči - mělo být 1) riziko, 2) předmět srovnávání knihoven, 3) součást executable architecture a odstraňování technických rizik
  • iterační tag formou commit message merge commitu - obtížně by se dohledával (navíc je týden po konci iterace)
  • zápisy schůzek končí 18.4.
• pozitiva
  • staging server s přístupem pro zadavatele
  • iterační tag alespoň existuje
  • různé významové odrážky v commit message (+,-,*)
  • zpřesnění technické specifikace
  • používání description a komentářů ticketů
  • trasovatelnost commitů
• hodnocení: slušné 1,75

Postupy a praktiky¶

• negativa
  • demo
  • křížení jazyků v commit messages (podle konvencí) občas ujede, stejně jako užívání branchí
  • některé věci se zdají, že se daly řešit dříve konkrétním dotazem na zákazníka (lze i mimo demo; např. 2 uživatelé zdánlivě se stejnými právy, return code u mazání unit, endpointy pro mazání)
  • "jak to deláme každý zvlášt" - proto je třeba se jednotit na návrzích, postupech, rozhraních atd.
  • nejasné používání typu ticketů - konvence to neřeší, většina se dá usoudit, ale ne rozdíl Enhancement vs. Feature
• pozitiva
  • příprava schůzek na wiki
  • standupy
  • pokračování v tom, co fungovalo z minula
• další komentáře
  • krystalizace požadavků na demu - (+) dobře že probíhá a řeší se konkrétní dotazy, (-) možné podcenění analýzy, díky které to mohlo být dříve
• hodnocení: slušné 1,5

Použitý proces¶

ASWI std

Datum schůzky¶

27.4.2021

Hodnocení
10,5 (3. iterace) + 9,5 (4.iterace)¶

Malus/Bonus¶

• potenciální bonusy (o přidělení se bude rozhodovat na konci projektů)
  • vyzkoumání spent timu přes commit message (zanést do Redmine manuálu)
  • pokročilá práce s CI/CD (včetně test coverage, ovládání přes commity, atd.)

Doporučení¶

• zvážit přidání iteraci (i třeba kratší) - prostor na to je

Průběh a stav projektu¶

• negativa
  • lehký skluz kvůli 4týdenní nemoci vedoucího týmu a souběhu s ostatními předměty
• pozitiva
  • cca 40-50% implementace - core hotový, BE správy cílů z části (datová + část aplikační)
  • průběžné testování
  • komunikace dovnitř i ven
  • zapracování relevantního feedbacku z minula
  • obecně dobré zvládnutí obtížné situace s táhlou nemocí vedoucího týmu
• další komentáře
  • problémy s časovými průniky
• hodnocení: skvělé 2,5

Iterace¶

• negativa
  • ve 4. iteraci se pár věcí nestihlo a objevili bugy - díky většině práce o víkendech (před koncem iterace) se na ně nestihlo reagovat
• pozitiva
  • retrospektivy validní - vyřešní problémů se dá určit tím, že se neopakují v další iteraci
  • plán na 5. iteraci validní
  • solidní odhady (u 4. iterace větší rozdíl díky nerealizovanému meetingu)
  • náplň, scope ok
• další komentáře
  • burndowny řešeny v diskuzi na minulé review --> z většiny irelevantní
  • ve 3. iteraci nebylo demo (vytíženost zadavatele)
• hodnocení: 3. iterace - skvělé 3, 4. iterace - slušné 2

Technická kvalita¶

• pozitiva
  • přihlašování před active directory (MS) + správa lokálních uživatelů jako NTH feature "zdarma"
  • specifikace testů pro core i modul
  • trasovatlenost commit-ticket
  • kategorie ticketů
  • řešení přesunu tasků mezi iteracemi
  • obsáhlé popisy ticketů (kde vhodno)
  • vykazování času přes commit message
  • pokročilé CI/CD (kterým se na midterm inspiroval i další tým) pro interní potřeby
  • přeplánování nestihlých ticketů (přes kopie s upravenou výchozí pozicí)
• hodnocení: skvělé 2,5

Postupy a praktiky¶

• pozitiva
  • demo
    • zvládlo se efektinvě za obě iterace nejednou
    • komunikace skluzu --> příprava zákazníka na možné vynéchání NTH funkčnosti (druhého modulu)
    • plánované testování na straně uživatele
    • posílání výsedků zipem z interního CI/CD je snažší než se snažit probít na interní server zákazníka
    • obecně komunikace a věcná domluva
    • myšlení "co když?" kolem produktu
    • domluvení schůzek předem
  • tagy ne iterační, ale featurové (dá se považovat za úpravu procesu)
  • uvažování scopu při plánování (oprava od minule)
• další komentáře
  • zbytek viz minulé iterace (dodržování toho, co má smysl)
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std

Datum schůzky¶

28.4.2021, 3. + 4. iterace

Hodnocení
10¶

Malus/Bonus¶

n/a

Doporučení¶

• klást důraz na získání přístupu/zapůjčení HW (viz demo) a překlopení do Unity za účelem odstranění hlavních rizik
• zjistit přesné termíny řádného a mezního data odevzdání od p. Brady přes veřejný kanál na Teams

Průběh a stav projektu¶

• pozitiva
  • LCOA
  • plán formou roadmap
    • další iterace se dostane na paritu s původním řešením (MVP)
    • 5. iterace na funkční vylepšení
    • 6. na předání (zkrácená, závisí na deadline viz výše)
    • IOC se bude špatně definovat, ale průběhu projektu to nevadí (nejspíš IOC= stabilní MVP)
  • komunikace ok
  • dělba práce
  • projekt on track
  • prototyp hotový, ale bez HW a Unity nemá cenu ukazovat/posílat (leda by to zákazník chtěl)
• hodnocení: skvělé 2,5

Iterace¶

• negativa
  • burndown schod na konci - řešeno v retro
• pozitiva
  • cíle splněny
  • odhady ok, náplň ok, rozsah ok
  • retrospektiva validní - řešení problémů z minula, identifikace problému, řešení na příště
  • plán na další iteraci validní (scope, náplň)
• další komentáře
  • většina práce na konci iterace kvůli kolizi s ostatními předměty
• hodnocení: skvělé 2

Technická kvalita¶

• pozitiva
  • updaty komunikačního protokolu
  • funkční prototyp - C++ + C# (zatím bez Unity)
  • iterační tagy i zpětně
  • trasování commit-ticket, commit messages
  • používání mezilehlých due date, description v rámci potřeby, návaznosti ticketů
  • Architektura jen lehká (1 diagram + protokol), ale potvrzená prototypem, pro další pohledy není důvod
• hodnocení: skvělé 2,75

Postupy a praktiky¶

• pozitiva
  • vedení na ASWI straně, věcná stránka na ZSWI
  • některé "oficiality" z procesu ignorovány, ale ne bez rozmyslu (zdůvodněno kontextem) a projektu to prospívá
• hodnocení: skvělé 2,75

Použitý proces¶

ASWI std - lightweight verze (některé vedlejší praktiky/artefakty bez přínosu vypuštěny, nižší úroveň ceremonie)

Datum schůzky¶

27.4.2021