Redmine

Hodnocení
9¶

Malus/Bonus¶

n/a

Doporučení¶

• zkusit se zákazníkem domluvit konkrétní den a čas schůzky každých 14 dní (mohlo by být účinější pro hledání průniku než ad hoc domluva při každé iteraci)
• protože LCA se dosáhlo neočekávaně brzo, demo s účastí mentorů se udělá na konci příští iterace
• uložit si často používané filtry v Redmine pro omezení nutnosti neustálého nastavování

Průběh a stav projektu¶

• pozitiva
  • komunikace a kolaborace
  • LCO a LCA dosaženy
  • výrazné zlepšní na úrovni postupů a Redmine
  • projekt dál, než se předpokládalo
• další komentáře
  • těžké najít průnik v rozvrhu se zákazníkem
• hodnocení: skvělé 2,5

Iterace¶

• pozitiva
  • cíle, splnění, rozsah, odhad jen lehce nadstřelený
  • relevantní plán na další iteraci
  • výstup retrospektivy
• další komentáře
  • burndown (- schodovitý, + vysvětleno proč a nemusí mít vliv na kvalitu)
• hodnocení: skvělé 2,5

Technická kvalita¶

• negativa
  • chybí trasovatelnost commit-ticket
  • struktura One Note se zdá místy neintuitivní a formát výstupů nejednotný (v pořádku, pokud se v tom vyzná tým, může být problém pro člověka z vnějšku)
• pozitiva
  • používání description a komentářů ticketů - usnadňuje přehled o stavu
  • Architektura (resp. ERA model, celkový návrh a workflow diagram)
  • přemýšlení nad alternatviami a budoucností řešení (migrace mezi DBMS)
  • zápisy schůzek
  • částečná implementace coru jako baseline architecture (ostatní části nepředstavují arch. rizika, protože s nimi má tým zkušenost)
  • používání branches, initial project tag
  • popisy Tvorba moduů, Tvorba testů, Spuštění, atd.
• další komentáře
  • arch. diagramy bez standardizované notace, ale není nutně problém
  • pro oddělení implementace, bugfixu, testování a zbytku se použijí kategorie
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • retrospektivě chybí "big picture" (prověření přesnosti odhadů na škale iterace, rozložení prací, burndown, atd.) a explicitní vyjádření k dosažení cílů iterace
  • při plánování chybí uvažování mezisoučtu hodin (scopu)
• pozitiva
  • hezká interní diskuze o průběžném a hromadném review důležitých výstupů
  • retrospektiva - efektivní použití RetroTool, procházení na úrovni individálních členů a tasků, společné řešení problémů
  • řízení schůzek
  • plánování - zpřesňování plánu, příprava dopředu, příprava úkolů na "když to dobře půjde"
  • konvence zachceny a další přirozeně dodržovány
  • včasný důraz na testy
• další komentáře
  • diskuze o přeplánování úkolu - jak nejlépe provést v Redmine
• hodnocení: slušné 2

Použitý proces¶

ASWI std

Datum schůzky¶

31.3.2021

Hodnocení
11¶

Malus/Bonus¶

• možné bonusy: Architektura, verzování a forma dokumentů, trasování požadavků (čeká na probrání s p. Bradou)

Doporučení¶

• další schůzka až po 4. iteraci

Průběh a stav projektu¶

• pozitiva
  • LCOA deklarováno a dosaženo, on-track podle plánu
  • důsledné a efektivní řízení
  • komunikace v týmu i ven
  • všechny připomínky z minulé iterace zapracovány
  • projekt obecně postupuje řízeně a po všech stránkách výborně
• hodnocení: skvělé 3

Iterace¶

• negativa
  • odhad lehce podstřelený (zmíněná zpožděná reakce zákazníka + některé schůzky delší než se počítalo)
• pozitiva
  • cíle, splnění, náplň ok, vše zavřeno
  • burndown slušný
  • retrospektiva relevantní a odpovídá realitě
  • plán na další iteraci relevantní
• hodnocení: skvělé 2,75

Technická kvalita¶

• negativa
  • kategorizace issues nepočítá s filtrováním testovacích ticketů
  • PoC jen z CLI, nepokrývá půřez architekturou, tak jak by executable architecture měla (ne velký problém, protože na této hranici rizika malá a PoC řeší ty hlavní)
• pozitiva
  • trasování požadavků Vize - DSP - user stories - tickety - commity
  • dotažení oboustrané trasovatlenosti commit-ticket + zanešení do konvenců
  • konvence nově pokrývají tracker ticketů (kategorizaci)
  • používání priorit, due date, description a komentářů ticketů
  • GUI návrhy
  • PoC - spustitelná minimální funkčnost z CLI
  • Architektura - moc pěkná, detailní popisy i diagramy
  • historie dokumentů efektivně trasuje změny
  • Git - feature branches, iterační a milníkové tagy, commit message formát, trasování
• další komentáře
  • diskuze nad tickety pokrývajícími více FREQs
• hodnocení: skvělé 2,5

Postupy a praktiky¶

• negativa
  • demo
    • ukazování kódu je na demo už moc
    • místy jít pomaleji, po částech a nechat protistranu vyjádřit postupně
• pozitiva
  • úprava Vize a DSP na základě feedbacku, prioritizace rizik
  • zápisy ze schůzek, glosář, od další iterace detailní popis dopředu, konvence
  • demo
    • řízení, rozdělení kompetencí - aktivní účast všech, pokrytí dokumentů, PoC a GUI návrhu, sběr feedbacku, posílání podkladů předem
    • identifikovaná potřeba úpravy návrhu -> speciální týmová schůzka
• hodnocení: skvělé 2,75

Použitý proces¶

ASWI std

Datum schůzky¶

29.3.2021

Hodnocení
8¶

Malus/Bonus¶

n/a

Doporučení¶

• dávat prostor po vyjádření po projití menších celků (jak zákazníkovi, tak při týmových schůzkách)
• milníky v interní komunikaci týmu jsou zbytečné, pokud je všichni nechápou stejně
• šablonu pro retrospektivu nebrat jako předpis, jen námět témat
• oddělit promítání a psaní poznámek na schůzkách
• dodělat obousměrnou vazbu commit-issue

Průběh a stav projektu¶

• negativa
  • nejasná akceptační kritéria - rozlišit nutné vs. nice-to-have věci (ty druhé třeba i navrhnout sami)
• pozitiva
  • komunikace se zadavatelem skvělá ze strany týmu
  • LCO
  • řešení staging serveru
• další komentáře
  • zákazník pozdě reagoval, což mělo negativní dopady, viz níže
• hodnocení: slušné 2

Iterace¶

• negativa
  • v plánu na další iteraci chybí zachycení návrhu
• pozitiva
  • relevantní cíle, splněny, náplň ok, scope ok, odhady dobré
• další komentáře
  • burndown špatný vinou pozdní reakce zákazníka
  • baseline architektura zřejmě pokryta plánovanými implementačními úkoly na 2. iteraci - momentálně není možné zcela posoudit
• hodnocení: slušné 2

Technická kvalita¶

• negativa
  • pozdní vykazování
  • Vize obsahuje i věci více technické (diagram, rozhraní -> architektura), ale částečně dáno jednodušší prezentací
  • trasovatlenost commit-ticket jen jednostraná
  • plán projektu specifikuje jen počet iterací a data bez jejich high-level cílů
• pozitiva
  • plán využít parent tasků, které si každý sám rozdrobí
  • Vize pokrývá všechno co má (i když možná lehce)
  • řešení staging serveru přes Open Nebula (CIV)
  • formát commit message, větve
  • používání description a komentářů
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • na demo neposlané podklady předem, neřešeno, co čekat příště
  • plánování nezohledňuje scope iterace
  • konvence neobsahují kategorizaci úkolů, Git konvence (, konvence kódu)
• pozitiva
  • promítání a rekapitulace v retrospektivě
  • zapojení zákazníků do Teams a Redmine
  • průběh dema, řešené věci (problémová data, specifikace uživatelů, priority)
  • aktivní snahy o řešení problému responsivity zákazníka -> pro jistotu domluva na pravidelné schůzky na řešení problémů kažý týden + stanovení pravidelného termínu
  • aktivní účast všech členů na demu každý ve své "doméně"
  • plánování zohledňuje priority
  • posun hranice iterací z neděle na úterý adekvátní okolnostem
  • konvence obsahují filtrování meetingů, zakládání a zpracovávání issues, workflow, časosběrné úkoly, komunikaci
  • zápisy ze schůzek, knowledge base o rozhraních a knihovnách
• další komentáře
  • plánování 3. den iterace díky neresponzivitě zákazníka
• hodnocení: slušné 2

Použitý proces¶

ASWI std

Datum schůzky¶

24.3.2021

Hodnocení
5¶

Malus/Bonus¶

n/a

Doporučení¶

• retrospektivu a plánování dělat nad promítanou Redmine (pro retro rekapitulace a statistiky, pro plánování vidět úkoly, přiřqzení, odhady + celkový odhad iterace)
• nebát se ozvat při schůzkách (i když jen vyjádření souhlasu)
• šablony retrospektivy brát jen jako náměty diskuze, ne nutně strukturu hovoru
• v průběhu iterace sbírat informace pro řádné plánování další (připravovat si půdu)
• (formální) DSP není "nutné", ale musí existovat nějaká forma specifikace požadavků

Průběh a stav projektu¶

• negativa
  • zatím nesměřuje k designu/návrhu/architektuře řešení (LCA)
  • deklarace PRI, ale Vize tomu neodpovídá (viz níže)
  • rychlá soustředěnost na vývoj a jeho přípravu na úkor nutných předchozích kroků
• pozitiva
  • rozchození Raspberry Pi a infrastuktury obecně
  • spokojenost zákazníka
• hodnocení: slabé 1

Iterace¶

• negativa
  • hodně nejistoty na další iteraci - "nepřipravená půda" -> nutnost shánět informace, analyzovat a upravovat plán za běhu
  • nevyužitý čas (jen cca 20h), burndown špatný
• pozitiva
  • cíle splněny častečně (není PRI, konvence nepochopené)
• hodnocení: slabé 1

Technická kvalita¶

• negativa
  • neuzavřené úkoly, některé na 0%
  • nepoužité description, kategorizace issues
  • odhady schůzek nenásobené počtem členů
  • záměna konvencí a kompetencí (což je jen podmnožina) - žádné sepsané konvence a přitom používání více stavů workflow
  • Vize - chybí rizika, mimofunkční požadavky, stakeholders, na druhé straně věci více do specifikace požadavků nebo architektury
• pozitiva
  • UI design
  • plán projektu, struktura wiki
  • komentování změn issues
• hodnocení: slušné 1,5

Postupy a praktiky¶

• negativa
  • Vize a plán neprobírané se zákazníky
  • posílat podklady pro schůzku předem
  • plánování nezohledňuje scope
  • pozdní vykazování času
• pozitiva
  • obecná tématika dema (prezentace pokroku + očekávání na příště)
  • zápisy schůzek, popis iterací, náplň retrospektivy
  • přišli na nutnost oddělit technické diskuze od plánování -> speciální schůzka týmu kolem návrhu
• hodnocení: slušné 1,5

Použitý proces¶

ASWI std

Datum schůzky¶

24.3.2021

Hodnocení
5¶

Malus/Bonus¶

n/a

Doporučení¶

• na demu procházet se zákazníkem výstupy po menších částech a dát prostor na feedback radši než až na konci po projetí celého (viz jednotlivé stránky UI návrhu)
• přítomnost mentorů na retrospektivě a plánování doženeme příště (retro 2., plánování 3.)
• 40h na 2týdenní iteraci je spíše minimum (ale pozor, aby projekt nepřesáhl výrazně 320h - kdyžtak řešit včas)
• velký úkol typu návrh GUI (10h) rozložit alespoň do kroků/jednotlivých stránek v popisu - lépe se pak odhaduje
• cloudové dokumenty klidně, ale na Redmine alespoň link - chovat se k ní jako k hubu, odkud se kdkoli dostane na všechny potřebné informace

Pruběh a stav projektu¶

• negativa
  • částečný Cart Before the Horse - řeč o implementaci na příště, neprobraná/neodsouhlasená Vize a návrh
  • sžívání se s procesy a Redmine
• pozitiva
  • iniciace projektu ok, vyjasnění detailů se zákazníkem
• další komentáre
  • v tento moment se vše zdá na svém místě, ale nejistota v mgmt věští budoucí problémy (viz absence Vize, důraz na implementační detaily moc brzy, neuchycení procesů, atd.)
• hodnocení: slušné 1,5

Iterace¶

• negativa
  • vykazování a zavírání 4 dny po konci iterace - tím trpí burndown
  • z retrospektivy nenalezen záznam
• pozitiva
  • náplň ok, cíle splněny, odhady ok
  • plán na 2. iteraci ok, ale chybí meetingy
  • retrospektiva proběhla (odsvěčeno na review) a odhalila 2 zásadní problémy (posun přelomu iterací a ???), ty adresovány
• další komentáre
  • LCO ještě nedosaženo
    • podle týmu na základě absence datového modelu
    • reálně spíš neucelený základ/přehled (Vize) o projektu vyjasněný na obou stranách
• hodnocení: slušné 1,5

Technická kvalita¶

• negativa
  • všechny úkoly zavírány přímo z New stavu a těsně před review - dá se pohodlně dělat na retrospektivě
  • kategorizace přes název ticketu není ideální a když už, tak musí být úplná a konzistentní
  • na Redmine není krom ticketů nic (v době schůzky) -> nový člověk v projektu, nebo mentor, si neudělá obrázek o všem podstatném
  • u ticketů nepoužité priority, due date
  • změna ticketu z 0 na 70% bez komentáře, který by to vysvětlil
• pozitiva
  • UI návrh
  • analýzy technických aspektů
  • kolaborace nad výstupy na One Note
  • rozpis požadavků (konkrétně Reqs) pěkný, ale hodilo by se sjednotit (mezi Zadání, Reqs a Use cases není jasné, co je kde), popř. přidat unikátní identifikáty požadavků, aby se na ně dalo odkazovat
  • podrobné rozpisy analýz
• další komentáre
  • některé úkoly velké, ale částečně opodstatnělé
• hodnocení: slušné 1

Postupy a praktiky¶

• negativa
  • podklady pro demo zákazníkovi neposlány předem
  • opomenutá přítomnost mentora na retro a plánování
  • Vize neprobírána na demu - projevilo se diskuzí nad rolemi a data modelem
  • konvence ALM (i obecně) existují jen některé a nejsou nikde vidět (v době schůzky)
  • v době review nebyly výstupy (UI, Vize, retro a cokoli dalšího) dostupné z Redmine
  • chybí Vize nebo alespoň podstatná část jejího obsahu (rizika, stakeholders, business case, akceptační kritéria, ...)
• pozitiva
  • zápisy ze schůzek jsou, ač nekonzistení formátem a obsahem
  • konvence na issues workflow, tracker (stačí tahle míra kategorizace?), log time, vytváření a odhadování
  • konvence GitLabu - necommitovat do master, verzování
• hodnocení: slabé 1

Použitý proces¶

ASWI std

Datum schůzky¶

18.3.2021

ZAZNAMENAT-DO-TABULKY https://zcu365.sharepoint.com/:x:/s/StudiumKIV-navazujc-TSP-Mentoi/EVhm8RB_jINKn2nV_Zy2DMIBTm6ORYF5cRFlEU9OIBxTVA?e=2NgsfJ&nav=MTVfezAwNjJFREQ5LTMyNjktNERFQi04MDg2LUE5MTVEM0ZCN0MzNH0

Datum: 
Hodnocení: slabé (0-4b) slušné (5-7b) dobré (8-10b) výborné (11+b)

h2. Průběh a stav projektu 

slabé (0-1b) slušné (1-2b) dobré (2-3b) výborné (3+b)

* + pozitiva
* - negativa
* 0 neutrální

Dosud strávený čas: X hodin

h2. Iterace 

slabé (0-1b) slušné (1-2b) dobré (2-3b) výborné (3+b)

* + pozitiva
* - negativa
* 0 neutrální

h2. Technická kvalita

slabé (0-1b) slušné (1-2b) dobré (2-3b) výborné (3+b)

* + pozitiva
* - negativa
* 0 neutrální

h2. Postupy a praktiky

slabé (0-1b) slušné (1-2b) dobré (2-3b) výborné (3+b)

* + pozitiva
* - negativa
* 0 neutrální

h2. Doporučení

* -

Hodnocení¶

5b

19.3.2021

Doporučení¶

• prostudovat ASWI proces, co vlastně je třeba v prvních iteracích projektu provést
• in particular zadefinovat očekávaný účel, rozsah, vlastnosti produktu

Průběh a stav projektu¶

• 1.iterace ukončena -2 dny
• běží komunikace se zákazníkem, řeší se technické detaily
• tým zjevně funguje
• další iterace naplánována

pozitiva

• aktivně se pracuje

negativa

• není plán projektu
• tým se předčasně věnuje detailní technické práci před analýzou problému

další komentáře

• Celkový strávený čas: 26h

Hodnocení: slabé (0)

Iterace¶

• "Cílem je provázat aplikaci s novou databází, provázat funkce serveru s klientem, dodat detail záznamů a přizpůsobit zobrazovaná data dříve specifikovaným požadavkům"

pozitiva

• cíl stanoven a víceméně dosažen (zbytek “na straně zákazníka”)
• rozsah naplánován rozumně

negativa

• cíl neodpovídá aktuální potřebě a fázi projektu podle obecných zásad

Hodnocení: slušné (2)

Technická kvalita¶

• Zhodnoceny jen Redmine záznamy, jiné nejsou k dispozici.

pozitiva

• v ALM správně strukturováno a zaznamenáno vč. odhadů času, popisy a detaily ticketů v pořádku

negativa

• není zachycená úvodní formulace účelu, rozsahu, vlastností, kontextu cílového produktu (natož zadefinovaná v podobě odpovídajícího artefaktu)
• jsou zčásti známé ale nejsou zpracované informace o produkčním prostředí, předchozích verzích

Hodnocení: slabé (1)

Postupy a praktiky¶

• Probíhají hlavně technické práce, použité postupy tomu odpovídají.

pozitiva

• rozdělování práce rovnoměrné, odhady prováděny
• použití Redmine OK, vč. workflow

další komentáře

• git v tuto chvíli minimální, v pořádku
• retrospektiva nezaznamenána, byla jen velmi neformální, v tuto chvíli není kritické

Hodnocení: slušné (2)

Hodnocení
11¶

Malus/Bonus¶

n/a

Doporucení¶

• co je dobré poslat zákazníkovi? postavit se do jeho role a přemýšlet o přidané hodnotě; v nejistotě se zeptat nebo prostě poslat
• při schůzkách rozdělit mezi členy sdílení obrazovky (použité při plánování a zavírání, ale hodí se i burndown a statistiky při diskuzi retrospektivy)
• retrospektivní/plánovací schůzka zahrnuje 1) sync (ala standup), 2) retrospektivu samotnou a 3) plánování - rozmyslet pořadí a zapojení timeboxingu
• jednosměrné vazby commit ticket se v Redmine ještě dají dohnat
• pozor aby se z procesu (zbytečně) nestal vodopád
• diskuze o invalidování úkolů
• pokud se bude zdát, že projekt výrazně překročí 320 šlověkohodin, řešit co nejdříve
• zkusti "prioritizovat" rizika
• rozmyslet kategorizaci úkolů aspoň na nutné minimum - tj. vývoj a tetování (zvlášť i dohromady) vs. ostatní aktivity (ale může být i podrobnější v závislosti na best practices a potřebách)

Pruběh a stav projektu¶

• negativa
  • diskutovat se zákazníkem pro něj polatná rizika (klidně mimo schůzky) - stejně tak drobné nejistoty, aby neblokovali postup na 14 dní
• pozitiva
  • komunikace uvnitř týmu i navenek
  • výborný start, postupy zvolené s rozumem a fungující
• další komentáre
  • Vize sice neposlaná předem zákazníkovi, ale nejasné body probírány na demu
• hodnocení: skvělé 3

Iterace¶

• pozitiva
  • dvotýdenní
  • dosažení PRI
  • náplň a scope ok, cíle splněny, odhad solidní, burndown také
  • už probíhá i průzkum problému (technologicky) a příprava na vývoj
  • plán na 2. iteraci obsahově relevantní, cílí na LCOA
• hodnocení: skvělé 3

Technická kvalita¶

• negativa
  • user stories v dokumentu jde trochu proti jejich účelu - snáze upravitelný seznam, popř. použití v Issues se zdá efektivnější
  • US navíc netrasované na požadavky z Vize/DSP
  • vazby commit-ticket jen jednosměrné
• pozitiva
  • kvalita dokumentů (formát, verzování)
  • popis iteračních dodávek
  • Vize
    • reflektuje min akceptační kritéria v prioritách
    • seznam dodávaných artefatků
    • popis zamýšlených testů (ač nutně nespadá do scopu dokumentu)
  • příprava demo serveru
  • Plán projektu
    • obsah nad rámec harmonogramu
    • zahrnuje i testovací plán
  • existence user stories
  • DSP
    • pěkný a postupně rozpracovatelný dokument
    • use case diagram
  • využití nadřazených úkolů
  • Glosář
  • vlastní Teams prostor
  • Google Docs pro tvorbu dokumentů, výsledky pak v DMS
  • zápisy schůzek na wiki včetně šablony + formát
  • dále na wiki knowledge-base, technologie, schéma komunikace
• další komentáre
  • rizika jako vlastní dokument není standard, ale dobře identifikovaná + strategie
• hodnocení: skvělé 3

Postupy a praktiky¶

• negativa
  • neprolínání disciplín mezi fázemi vede k velkým (a těžko odhadnutelným) úkolům kolem architektury (není ponětí, které všechny aspekty modelovat)
  • konvence neřeší kategorizaci úkolů -> nemožnost vyfiltrovat jednotlivé disciplíny, plán vs. backlog, atd.
• pozitiva
  • trasování požadavků mezi Vizí a DSP (na popud zákazníka)
  • posílání výstupů zákazníkovi předem
  • konvence - obsahují hodně a má to smysl
  • společné zavírání úkolů, otevřené vyjadřování k retrospektivě a plánování (odhadování, přiřazování)
  • kompletní workflow ticketu včerně nezávislé review
  • zohledňování scopu a priorit při plánování
  • v Redmine používání mezilehlých start a due date
• další komentáře
  • priority v Redmine téměř 50/50 mezi normal a high - není nutně problém, ale pokud to tak bude pořád, priorita skoro zrácí smysl ("grade on a (bell) curve")
• hodnocení: skvělé 2

Použitý proces¶

ASWI std

Datum schůzky¶

15.3.2021

Datum schůzky (uzávěrky)¶

8.6.2020

Artefakty předané týmem¶

• Předávací protokol - ANO
• Archiv projektu - ANO

Použitý proces¶

ASWI std

Tým a komunikace¶

• negativa
  • pomalejší rozjezd
• pozitiva
  • komunikace uvnitř týmu a se zákazníkem
  • zohledňování připomínek
• hodnocení: Slušné

Projekt¶

• negativa
  • opomenutí v plánování zohlednit ostatní předměty
• pozitiva
  • domluva na pokračování přes léto
• další komentáře
  • Celkový strávený čas [h] - 285,35
    • rozložení zvláštní - PM se stará pouze o admin -> méně času, ale tým bez problému
• hodnocení: Slušné

Postupy a praktiky¶

• negativa
  • release tagy
• pozitiva
  • postupný nájezd na většinu praktik
  • viditelný přínos
• hodnocení: Slušné

Technická kvalita¶

• negativa
  • některé artefaktu zpočátku nedomyšlené/nepochopené
  • dlouho nebyla centralizovaná architektura
• pozitiva
  • zásadní artefakty, zacházení s tickety, trasovatelnost, feature branche
• hodnocení: Slušné

Otázky na tým (post-mortem review)¶

• Co nevyhovovalo, nefungovalo, komplikovalo život
  • nezkušenost s procesem
• V čem vidí tým největší přínos, co se naučili
  • Redmine (i když těžkopádnější), mentoring, některé praktiky (plánování, iterace, demo)

Hodnocení
10¶

Datum schůzky¶

8.6.2020

Použitý proces¶

ASWI std

Průběh a stav projektu¶

• pozitiva
  • projekt předán se zákazníkovi s domluvou na pokračování v pracech přes léto
  • odevzdáno se všemi náležitostmi i mentorovi
• hodnocení: skvělé

Iterace¶

• pozitiva
  • náplň a splnění odpovídající
• další komentáře
  • krátká, dodělávková
  • burndown už nepodstatný
• hodnocení: slušné

Technická kvalita¶

• pozitiva
  • dokumentace včetně ERA, package diagramu
  • doupravená specifikace - highlight toho, co se bude dodělávat v létě
  • testovací scénáře
• hodnocení: slušné

Postupy a praktiky¶

• další komentáře
  • standardní dojezd
• hodnocení: skvělé

Hodnocení
10¶