Redmine

Hodnocení
9¶

Tým a komunikace¶

• + komunikace a spolupráce
• 0 jeden člen méně času než čekáno, 2 více -> probráno, tým s tím nemá problém -> nebudeme dále řešit
• 0 obtížnost zákazníka - data pozdě, nároky na out of scope změny - (+) tým se s tím dobře vyrovnal
• 2.5b

Projekt¶

• - pomalejší rozjezd, pozdější start, díky tomu skončil projekt za deadlinem, ale srážky podle CW se neaplikují
• + tah na produktu - z části daný zákazníkovou potřebou použít už v půlce projektu
• + zákazník spokojen, produkt vyzkoušen už na 100+ reálných případech
• 2.5b

Postupy a praktiky¶

• + pozorovatelná zlepšení v průběhu
• + sběhlost části týmu ve Scrumu (z práce)
• - trochu lightweight proces, kde asi být nemusel (zápisy schůzek, retrospektivy)
• 2b

Technická kvalita¶

• - obecně artefaktů není moc, ani v moc dobré kvalitě, od zápisů schůzek se upustilo už měsíc před koncem projektu, návrh až na konci
• + naopak kvalita toho, co jde k zákazníkovi velmi dobrá
• + dobrá práce s VCS (tagy, CICD, commity, branche, merge)
• + test-fix-release smyčka ve finálních fázích projektu
• - na začátku chaos v ticketech (klasifikace atd.) -> (+) časem srovnáno
• 2b

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

• Co nevyhovovalo, nefungovalo, komplikovalo život
  • GitLab, trochu "manýry" zákazníka
• V čem vidí tým největší přínos, co se naučili
  • sjednocení formátu ticketů a commitů
  • část týmu, která pracuje - komunikace se zákazníkem
  • část, která ne - práce v týmu

Použitý proces¶

ASWI std

Artefakty předané týmem¶

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

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

13.4.2024

Hodnocení
11+11+9¶

Doporučení¶

• začistit Redmine tickety - smazat/zavřít/invalidovat/nechat (mimo iterace) jen ty, co se použijí v TSP2
• 7. iterace není sama o sobě ani moc hodná hodnocení, proto zvolené takové, které co nejméně ovlivní celkový průměr

Průběh a stav projektu¶

• + komunikace ok, pozitivita, dotažení projektu
• + REL
• 0 nevyrovnanost spent time probrána a tým s ní interně nemá problém
• 3b

Iterace¶

• + obecně dobré, obzvlášť 5 (včetně burndownu)
• - chybí retrospektivy, 5 má trochu přepálený odhad
• + 7 přidaná pro uzavření a administrativu po nemálo otočkách na testování se zákazníkem a stále dalších nárocích na změny
• 2.5b

Technická kvalita¶

• + protokol, archiv, dotazník
• + uživatelská dokumentace a její konstantní úpravy
• 0 návrh - (+) že existuje a působí ok, (-) přišel pozdě (částečně dáno náturou projektu, tzn. tlak na použitelnou verzi rychle)
• + VCS super (tagy, branche, commit message) - některé zdánlivé nedostatky jsou vlivem GitLabu, jiné vlivem časového tlaku
• - neuzavřené tickety (duplikáty, nebo přehlédnuté)
• 2.5b

Postupy a praktiky¶

• + explicitní označení commitů nepřiřazených žádnému ticketu
• + vypořádání se s chováním zákazníka - poskytnutá data buď nerealistická, pozdě, nebo mimo domluvené požadavky
• 3b

Použitý proces¶

ASWI std

Datum schůzky¶

13.6.2024

Datum: 6.6.2024
Hodnocení: 8b

Předané artefakty¶

• předávací protokol - ano
• archiv projektu - ještě TODO

Tým a komunikace¶

slušné (3b)
individuální penalizace 1 člen

• + se zákazníkem dobře řízená komunikace, časté schůzky, týmem zapojeni i koncoví uživatelé
• + rozdělení rolí dobré
• + (ne)komunikace jednoho člena v průběhu projektu, tým byl schopen (s jednou konzultací s mentorem) vyřešit samostatně, byť to vedlo ke zdržení a zvýšení celkově odpracovaného času

Projekt¶

slušné (2b)

• 0 snaha o podrobné řízení, ale zpočátku ne vždy vycházelo + monitorovatelnost zvenku (mentor) spíše slabá
• - výrazně přesahnutý rozsah (přes 820 hodin)
• + proces postupně mírně upraven/doladěn (ticket workflow)

Technická kvalita¶

slušné (2b)

• 0 dokumentové artefakty zpočátku slabé, postupně dopracovány
• 0 produkt ve výsledné implementaci funkční ale s architektonickými i impl. slabinami
• 0 web projektu zpočátku velmi nepřehledný, nakonec OK-ish

Postupy a praktiky¶

slabé (1b)

• 0 práce s úložištěm nakonec OK, ale vůbec nepoužity tagy
• - burndown nefunkční kvůli použitému workflow ticketů
• - potíže s trasovatelností požadavků, zejm. vazbou tasků na výchozí potřeby / požadavky
• + plánování a výsledná přesnost odhadů vcelku dobré
• - nezřídka používány rozsáhlé tasky (na nich přesnost odhadů malá)
• + retrospektivy (části "co zlepšit" a "čemu se vyhnout" ) pomohly najít a upravit postupy (komunikace, SCM)
• - retrospektivy nepoužily zavedené schema, obsahují pravidelně velkou část "udělali jsme, co jsme naplánovali" což ale patří do uzávěrky iterace se zákazníkem (toto zhodnotí product owner)

Post-mortem review¶

Provedeno jen velmi krátce.

• tým a komunikace
  • rozdělení rolí: v předchozím studiu už měli ve stejném složení jinak rozdělené, tj. teď si zkusili "zamíchat", užitečné
  • k diskusi po skončení ASWI je složení týmu pro pokračování v TSP2
• technická kvalita produktu
  • k diskusi zda refactorovat nebo použít jen jako prototyp a (v pokračování projektu) reimplementovat
  • příčinou zčásti to, že architektonický prototyp byl pouze Proof of Technology nikoli Proof of Concept (neimplementovány business / architecturally critical requirements)

Použitý proces¶

ASWI std

Datum: 5.6.2024

Hodnocení: 6.it 9 bodů, 7.it 11 bodů

Průběh a stav projektu¶

dobré (3b)

• + IOC
• + tým do značné míry konsolidován
• 0 postup prací setrvalý

• dosud strávený čas: (nezaznamenáno)

Iterace¶

6.it slušné (1b)
7.it dobré (3b)

• + cíle v souladu s fází, splněny bez nutnosti změn
• + 7.it burndown i objem prací realističtější
• - 6.it backlog not DEEP
• - velké úkoly (odhad 15-30h), na nich výrazné rozdíly odhad vs skutečnost
• + slušná přesnost odhadu pracnosti na menších úkolech
• + užitečné body v retrospektivě (6.it "co zlepšit" a "čemu se vyhnout")

Technická kvalita¶

slušné (2b)

• + trasovatelnost commit-ticket systematicky používána
• 0 použity unit testy a základní perf testy (tým se sám naučil, neměli ve výuce)
• - v polovině 6.it se objevil nesoulad očekávání zadavatele s implementací webové části (funkčnost, technologie, architektura, kvalita src kódu)
  • zčásti příčina v dřívějších komunikačních potížích v týmu (první impl. nešlo dříve demonstrovat/konzultovat), zčásti neuchopením "executable architecture"
• - src slušná struktura, ale ve zdrojáku občas magická čísla a hesla v plaintextu (v repository) :(
• + základní uživatelská dokumentace

Postupy a praktiky¶

dobré (3b)

• + v 7. iteraci uzavírání issues při dokončení => burndown umožňuje sledovat postup
• + testy pro ověření výkonu aplikace vůči specifikaci požadavků
• 0 jinak standardní

Hodnocení
10¶

Tým a komunikace¶

• + komunikace a spolupráce ok, domluva na převážně online schůzkách
• + na konci komunikační potíže na straně zákazníka, správně řešeno
• 3b

Projekt¶

• + na začátku slabší, ale postupné vylepšení
• - IOC až na konci projektu spolu s REL
• + hrubý scope na TSP2
• 2.25b

Postupy a praktiky¶

• 0 více lightweight proces díky menšímu týmu (ne mnoho artefaktů, nekomentované změny ticketů, atd.)
• + zapracovávání feedbacku
• 2.25b

Technická kvalita¶

• + zápisy schůzek a retrospektiv
• - zadavatel chce dokumentaci až na konci, ale nějaká forma by měla být součástí release (i kdyby jen interní)
• + repository obecně, mnoho branches, tagy
• + tickety úměrné procesu
• + testování a report
• 2.5b

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

• Co nevyhovovalo, nefungovalo, komplikovalo život
  • gtilab, na konci komunikace se zákazníkem
• V čem vidí tým největší přínos, co se naučili
  • hlavně technologie - už pracují, takže dílčí postupy jim nebyly cizí

Použitý proces¶

ASWI std (lightweight)

Artefakty předané týmem¶

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

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

5.6.2024

Hodnocení
12¶

Průběh a stav projektu¶

• 0 problémy s komunikací na straně zákazníka
• + IOC a REL
• 2.75b

Iterace¶

• 0 protažená kvůli zákazníkovi, ovlivňuje burndown
• + scope, náplň, odhady, retro
• 3b

Technická kvalita¶

• + integrační a finkční testy -> bug reporty
• 0 zákazník požaduje dokumentaci až při finálním releasu, nicméně dobrá praktika je brát nějaký level jako automatickou část releasu obecně
• + repository - commity, mrge, tagy, trasovatelnost
• + zápisy schůzek
• + protokol, formulář, archiv
• 2.75b

Postupy a praktiky¶

• + přidání rizika na komunikaci se zákazníkem
• + úprava plánu
• 3b

Použitý proces¶

ASWI std (lehce lightweight)

Datum schůzky
5.6.2024¶

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í
12¶

Bonus¶

• kostantně dobrý burndown - 3b
• šablony (retro, plán iterací, testování), rizika jako tickety a kompletní trasovatelnost - 3b

Tým a komunikace¶

• + skvělé fungování týmu, komunikace ven i dovnitř
• hodnocení: Excelentní (3)

Projekt¶

• + skvěle podchycené už od začátku
• + projekt bez problémů, prokazatelně díky pečlivému vedení
• + konstantně skvělý burndown
  • Celkový strávený čas [h] - 570 (přesně v očekávaném intervalu)
• hodnocení: Excelentní (3)

Postupy a praktiky¶

• + důsledné analýzy, plánování a retrospektivy
• + vyzkoušení si i nepoviných praktik jako planning poker
• + konvence a jejich dodržování
• + drobné a opodstatnělé změny procesu - posun přelomu iterací, protažení iterace kolem velikonoc
• hodnocení: Excelentní (3)

Technická kvalita¶

• + ukázková práce s tickety i úložištěm
• + podrobné a užitečné analýzy, šablony pro retro, plánování i testování
• + Vize, plán, Architektura, plán testování a nasazení, protokol z testování
• + přehledně uspořádaný workspace (Google Drive)
• + 5 různých prototypů
• hodnocení: Excelentní (3)

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

• Co nevyhovovalo, nefungovalo, komplikovalo život
  • lehce Gitlab
• V čem vidí tým největší přínos, co se naučili
  • ozkoušení si všech rolí v projektu, plánování a přeřdepsaný proces

Použitý proces¶

ASWI std

Artefakty předané týmem¶

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

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

28.5.2024

Hodnocení
12+12¶

Průběh a stav projektu¶

• + projekt úspěšně ukončen
• + spent time
• + zákazník spokojen
• 3b

Iterace¶

• + refactoring, bugfixing, dokumentace, testování (6.), administrativa (7.)
• + 7. týdenní
• + plány, náplň, scope, rozložení práce, retrospektiva 6 (7 je zbytečná)
• odhad pro 6 lehce přepálený ale není problém
• 3b

Technická kvalita¶

• + standard z předchozích iterací
• + smergování, tagy, trasovatelnost
• + videa bugů, protokol a záznamy z testování
• + plán testování a nasazení
• + dotazník, protokol, archiv
• 3b

Postupy a praktiky¶

• + standard z předchozích iterací
• 3b

Použitý proces¶

ASWI std

Datum schůzky¶

28.5.2024