ASWI - Pokročilé softwarové inženýrství » ASWI 2024 » Prostředí pro benchmarky kompresních algoritmů pro 3D modely - Underpaid devs

Hodnocení
9¶

Doporučení¶

• viz reakce na "Co nevyhovovalo, nefungovalo, komplikovalo živo" v sekci dole

Tým a komunikace¶

• + obecně dobré
• - dílčí problémy od začátku
  • zmatek s výběrem tématu
  • výpadky interní komunikace
  • někdy problematická domluva se zákazníkem na schůzkách - z většiny ne chyba týmu, nicméně dalo se udělat víc
• + někdy dotazy a hlášení problémů
• + nesnadná koordinace mnoha lidí na celkové škále celkem úspěšná
• 2.25b

Projekt¶

• + úspěšně dokončený release
• + zákazník spokojen
• - počáteční iterace menší, což se později vykompenzovalo, ač více "shodou okolností", než vlivem plánování; plus "ještě nemůžeme programovat" (nepochopení procesu)
• - na uzávěrce pouze protokol, bez formuláře a archivu
• + časově v normě (i individuálně)
• 2.25b

Postupy a praktiky¶

• na konci focus na produkt a kvůli tomu lehké zanedbání správy ticketů a dalších PM záležitostí
  • + obecě, v dané situaci správná praktika
  • - situace samotná ale pramenila ze špatné správy rizik
• + ve Vizi hezké identifikátory hlavních požadavků
• - specifikace na ně ale už neodkazuje, což je dělá v podstatě zbytečnými, a je navíc víš popisem aplikace než rozpisem požadavků přenostitelných do ALM nástrojů a trasovatelných
• + nastřádané návrhy na TSP2
• - přílišné spoléhání na to, že ostatní lidé se chovají tak, jak očekáváte, aniž znáte jejich kontext (zákazník, člen týmu, atd.) - proto se dělají rizika na komunikaci, práce se dělí tak, aby existovala zastupitelnost a výpadek jednoho čelna neparalizoval zbytek (nikdy nevíte, co se může stát), popř. to řeší dostatečná průběžná dokumentace návrhu, architektury a kódu
• 2b

Technická kvalita¶

• + volba Jiry
  • + pidání pluginu na worklogy
  • - krom ních a kanban boardu žádné nastavení pro ulehčení vedení projektu
  • + plná interaktivní trasovatelnost nemožná, ae přesto dodržovaná v commitech
• + problémy s GitLabem a rozhodnutí přejít na veřejnou instanci
• - roztříštěnost artefaktů (gDrive, různé wiki), což stěžuje jejich dostupnost
• - nezahlazené tickety - některé stále otevené i mimo těch pro TSP2 (na schůzce ok, bylo to těsně po dotažení produktu, ale čekal bych následné dohnání)
• + do poslední fáze projektu důsledná práce s tickety
• + CICD
• 2.5b

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

• Co nevyhovovalo, nefungovalo, komplikovalo život
  • Nezaměřovat se tolik na časovou dotaci předmětu. Cílem předmětu je si především vyzkoušet práci v týmu a techniky, např. ALM (Jira), VCS (Git), atd., než-li se stresovat tím, že jsem si napsal dostatek hodin v určitý den.
    • strávený čas není největší částí hodnocení, odchylky, pokud opodstatnělé, nejsou problém, ale je podstatný pro retrospektivy, plánování, řízení kapacit a zdrojů a další aspekty projektu - vše stěžejní součástí projektového řízení, což je náplní předmětu (nástroje jsou dalším jeho aspektem, ne hlavním)
  • Zároveň hodnocení body je velmi demotivující, když na prvním review bylo řečeno, že není prakticky možné dostat plný počet bodů - museli bychom udělat nad rámec mnoho věcí a přesto, že tomu tak v některých iteracích bylo a většina procesu byla podle mentorovo představ, maximálního počtu jsme nikdy nedosáhli.
    • 12 bodů za iteraci je vyhrazeno pro výjimečně skvělé případy, většina týmů jich nedosahuje, natož konzistentně - nejde jen o to "co" tým udělá, ale "jak", a o přístup více než o kvalitu
    • že je všechno dobře (tj. na očekávaném standardu), je chvalitebné, nikoli vynikající - hodnotící škála toto reflektuje
  • Byli jsme penalizováni za to, že jsme nepřipomínali zákazníkovi a mentorovi schůzky a že jsme nenaplánovali náhradní schůzku, když už teď bylo složité najít jeden časový slot, ve kterém se sejde 7 lidí.
    • jak bylo probíráno na bezprostředně následující schůzce, i pokud penalizace (resp. nedosažení plného hodnocení) byla zapříčiněna tímto (což nebyla), v celkovém hodnocení by se to projevilo nejvýše 0.375b na škále -6-60, tzn. zanedbatelně
    • šlo více o indikaci přístupu než o přímo to připomínání schůzek
    • nikde není řečeno, že na schůzce musí být přítomni všichni z týmu - v nejhorším je to označeno za ideální, ale jako všechno, pokud dobře zdůvodněno, není to problém (viz první cvičení a několik diskuzí v průběhu)
  • Na úvodní schůzce (před semestrem ještě) podat informace lépe. Připadalo nám to nepřipravené.
    • týká se asi spíše TSP
  • Neupřímnost s časovou dotací - po dotazu, zda ASWI + TSP je ~200h jeden řekl, že to je polovina, druhý řekl, že to je 160h, třetí 180h. Na CourseWare je to tím pádem špatně a vyučující se nemohli ani na tom shodnout. Jednak mentor, jednak garant ASWI -- oba měli jinou představu o časové dotaci.
    • dotace vychází z akreditace a popisu předmětů na STAG (jak bylo řečeno na společné schůzce v polovině projektů)
    • navíc rozebíráno už na úvodním cvičení (viz prezentace z něj) a na init schůzce s mentorem
    • máte-li konfliktní informace, je pro vás poplatné, co říká váš mentor, nebo lépe, zeptejte se
    • mimochodem, který "třetí"? CourseWare? formulace tam mluví o hrubé alokaci, kterou nepřesáhnout v rámci jedné iterace, ne o konzistentním tempu ani o celkové zátěži - nicméně je ní možno chybně interpretovat a proto se snažíme povzbuzovat dotazy v případě sebemenších nejasností (pokud vám něco na přímo řekne mentor, pak jsou konfliktní informace zjevně nevalidní, popř. ho na konflikt upozerněte)
• V čem vidí tým největší přínos, co se naučili
  • Jira plánování, Gitlab CICD

Použitý proces¶

ASWI std (+Jira)

Artefakty předané týmem¶

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

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

30.5.2024