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

Hodnocení
10+11¶

Průběh a stav projektu¶

• + uzavřeno, předáno
• + objevili se komunikační potíže, ale zdárně vyřešené
• + vysoká spokojenost zákazníka
• 2.5+3b

Iterace¶

• + proces šel trochu stranou kvůli snaze dotáhnout produkt
• 2.5b

Technická kvalita¶

• + protokol
• 0 zatím nejsou formuláře a archiv, ale dožene se -> drive byl na dokončení produktu
• + pěkná technická dokumentace, dokumentace DB samostatně
• - kvůli focusu na produkt nižšní kvalita SCM a VCS
• 2.5+3b

Postupy a praktiky¶

• + domluvené předvedení dalším uživatelům se zákazníkem
• + připravené náměty na TSP2
• + focus na produkt na úkor prj dat
• - komunikační zádrhel jednoho člena je jeho věc, nicméně "nezastupitelnost" je otázka prj/tým managementu (je z toho zjevná důležitost sdílení vědomostí, pop. řádného dokumentování už během vývoje)
• + řešení výpadku člena s mentorem
• 2.5b

Použitý proces¶

ASWI std (+Jira a GitLab.com)

Datum schůzky¶

30.5.2024

Hodnocení
11¶

Doporučení¶

• pokud budou problémy se členem týmu přetrvávat, řešit společnou schůzkou s mentorem, popř garantem TSP

Průběh a stav projektu¶

• + na konci další iterace finální revize a feedback od zákazníka, o týden až 2 později uzávěrka
• 0 přiznání podcenění CICD, ale už funkční
• 0 zpoždění mimo jiné vlivem problémů s jedním (TSP) členem - tým to řeší
• + spokojený zákazník
• 2.5b

Iterace¶

• + náplň a plány odpovídají
• 2.5b

Technická kvalita¶

• + dotahuje se přechod na gitlab.com
• + funkční a integrační testy
• + CICD - tag trigger
• 3b

Postupy a praktiky¶

• + změna politiky code review, resp. rozdělení mezi více lidí
• + plán na staging prostředí po TSP1 a po RTP
• + objevení a řešní problému s jedním členem
• + produktivní diskuze nad prj mgmt
• + dopředné potvrzování schůzek
• 3b

Použitý proces¶

ASWI std (+Jira a gitlab.com)

Datum schůzky¶

9.5.2024

Hodnocení
9+9¶

Průběh a stav projektu¶

• + přechod na gitlab.com po táhlých problémech s KIV instancí
• + spent time skoro 80% spodní hranice
• - zádrhele s testováním, deploymentem, dokumentací
• + IOC příští iteraci, 80-85% freq proti MVP, 80-85% všeho
• 2b

Iterace¶

• 0 v it 5 zákazník nemohl na schůzku
• + retrospektivy, náplň se zdá rozumná
• 2b

Technická kvalita¶

• + změna VCS, udržení trasování a dalších konvencí
• + CI pipeline
• + release v gitlabu včetně notes
• + deploy těsně po review
• 2.5b

Postupy a praktiky¶

• + změna konvencí (subtasky)
• + starost o tickety a vykazování
• - nulová snaha o přeplánování schůzek, nebo jejich dopředné potvrzení (vysvětlení na Teams je pochopitelné, ale ne úplně dostačující - probereme příště osobně)
• + úprava plánu - využití rezervy
• 2.5b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

25.4.2024 (offline)

Hodnocení
10¶

Doporucení¶

• o náslech mentora na dalším demu už se nemusíme snažit
• 5 minut na retrospektivu je možná trochu restriktivní, pokud bude treba zvýšit na 15-30 minut, není to problém

Prubeh a stav projektu¶

• + LCA (nebo velmi blízko)
• + projekt nejeví známky budoucích problému (krom možná zvyšující se záteže per iteraci v implementacní fázi)
• + komunikace a fugování týmu ok
• 2,5b

Iterace¶

• 0 neprobehlo std demo (díky chybe zákazníka) - bude dorešeno online
• + dobrý obsah retrospektivy
• + nápln a plán dál
• - scope menší - problém "najít, co víc delat"
• 2b

Technická kvalita¶

• + adr. struktura je více UX záležitost pro zákazníka / usability aspekt
• + UML architektury a domény pekný
• + zajištení prod serveru od CIVu
• + deployment plán formou diskuze v ticketu s popisem možností a vybraného postupu
• + executable architecture - spustitelné minimalistické verze obou cástí aplikace + rozhraní mezi nimi
• 3b

Postupy a praktiky¶

• + timebox retrospektivy na 5 minut + použití RetroTool
• + korekce zodpovednosti v týmu (za tvorbu ticketu)
• + úprava procesu používání ticketu
• + zmena architektury, nyní bez ORM - mrzí, ale je to tak lepší
• + poucení - ne príšte potvrzovat schuzku den predem
• + dobrá diskuze nad procesy a významem jednotlivých prvku obecne
• + oprava z minula - zápisy schuzek jsou suplovány na Discordu
• 2,5b

Použitý proces¶

ASWI std (+Jira)

Datum schuzky¶

28.3.2024

Hodnocení
9¶

Doporučení¶

• není-li jasné, čím "vyplnit" iteraci (resp. co ještě se dá dělat), zeptat se mentora
• obdobně, pokud se zdá, že některé artefakty se dělají "jen aby byly", prodiskutovat s mentorem

Průběh a stav projektu¶

• + doladění LCO, kroky směrem k LCA
• + to co tým dělá, zdá se dělá dobře (otázka je jestli se toho nemá dít víc)
• + komunikace
• 0 projekt se zdá v dobrém stavu v danou chvíli, ale existují indikace budoucích problémů (např. strávený čas, monitoring vitálních indikátorů, nejasnosti v účelu artefaktů a pochopení procesu, atd.)
• 2,5b

Iterace¶

• + náplň a plán na další ok
• - zdá se malá
• 1,75b

Technická kvalita¶

• - potřebná data se z Jiry dostávají trochu přes ruku, pro hodnocení ok, ale znesnadňuje to monitoring
• + plán formou Jira sprintů
• + epicy jako high level požadavky se specifikací, postupně rozlámané na menší kusy
• + orientace v Jiře, přidání worklog reportů
• + CLI mockupy, ERA, UI návrhy, adr. struktura - poměrně kreativní způsob zachycení návrhu
• + specifikace požadavků (existuje, i když zatím jen v draftu)
  • - neodkazuje ID požadavků z Vize
• + první commity, odkazují issues (ač s Jirou nepůjde plná vazba), dodržují konvence
• + práce s tickety
• 3b

Postupy a praktiky¶

• Vize
  • + nová verze
  • + rozpis požadavků podle priorit, více požadavků, vyjasněné MVP
  • - pořád odkazuje na neexistující Plán artefakt
• - nezdá se, že by někde byly zápisy, což znemožňuje hlavně kontrolu standupů a výstupu retrospektivy
• 0 snaha vyhovět požadavkům procesu (artefkaty, atd.), ale trochu dogmaticky, bez pochopení jejich účelu a významu
• 1,75b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

14.3.2024

Hodnocení
8¶

Doporučení¶

• zrevidovat, co všechno má řešit retrospektiva
• do plánování faktorovat scope
• v Jiře najít jednoduchý způsob, jak monitorovat základní fakta "zdraví" projektu
  • plynulost a rozložení prací přes lidi, kvalitu odhadů a další
  • možná sestavit dashboard?

Průběh a stav projektu¶

• + dobrý start
• + PRI určitě, do LCO nechybí moc
• + komunikaca a spolupráce se zdá dobrá dovnitř i ven
• 2,5b

Iterace¶

• Retrospektiva
  • + diskuze deploy plánu jako mimofunkčního požadavku
  • - trochu přetéká do věcné diskuze mimo rozsah retro
  • - nepadlo explicitní vyjádření k dosažení cílů/milníků
  • + diskuze code review, maintenance repa -> konvence
• náplň a průběh ok
• 2b

Technická kvalita¶

• + přechod na Jiru a její zprovoznění
• + Vize pěkná formátově
• 0 repo zatím nepoužito, resp. v přípravě
• + gDrive pro artefakty
• 2b

Postupy a praktiky¶

• Demo
  • + vyjasňování požadavků, probírání deploymentu, potvrzení UI a obsah obecně
  • 0 vývoj na produkci není u green fieldu takov problém, ale hodilo by se uvažovat i o testovacím prostředí, hlavně do budoucna
  • + rekapitulace a next steps
  • 0 trochu neasertivní vystupování, ale to je o zkušenostech
• Vize
  • + obsahuje většinu zásadních informací
  • - není z ní jasné MVP (jsou to pažadvky nej vyšší priority?)
  • + rizika u jednotlivých požadavků
  • - chybí rizika projektu jako celku, nevázané na konkrétní požadavek
  • 0 identifikátory požadavků jsou dobrá věc, pokud se na ně bude dál odkazovat pro trasovatelnost, jinak jsou trochu zbytečné
• Plánovaní
  • - trochu chybí uvažování nad scopem (hodinově)
  • 0 pozor, přehled na CW je modelová situace, nikoli šablona
• - Vize zmiňuje vlastní artefkat pro plán, ten ale není k nalezení
• + plánované používání wiki na GitLabu k rozumným účelům (např. kódové/gitové konvence, instalační návod, apod.)
• 1,5b

Použitý proces¶

ASWI std (+Jira)

Datum schůzky¶

29.2.2024