Tým a komunikace - excelentní
- Tým velmi soudržný, sehraný, dobře komunikující navzájem i se zákazníkem.
Projekt - slušný
- Bez zásadních zádrhelů, na začátku příliš implementace a málo analýzy, postupně lepší odhady, ale na konci se vymstila nedostatečně udělaná analýza stávajícího řešení (převod SQL implementace, import dat) -- výrazně podceněné odhady pracnosti příslušných několika (málo) úkolů, dodělávky na poslední chvíli.
Celkový čas
- 235h (relativně málo, dáno pravděpodobně rozsahem zadání + efektivitou týmu)
Postupy a praktiky - excelentní
- (+) výborně zvládnuté git flow
- (+) postupně zavedený planning poker, osvědčil se
- (+) dobré QA a komentáře nad tickety (dva nebo tři páry očí)
- (-) zpětně viděno slabší analýza rizik - složitostí v původní aplikaci
- (+-) procesní řízení projektu průměrné, viz "programátorský" začátek a mírně nezvládnutý rozsah na konci
Technická kvalita - slušné
- ALM, VCS viz postupy a praktiky
- (+) zřejmě kvalitní architektura a implementace
- (+-) dokumentace vytvářená v odpovídajícím rozsahu, užitečné analýzy (výběr technologií), architektura a programátorský popis spíš slabší
Průběh a stav projektu - slušné
- Projekt dokončen (později, než byl úplně původní plán, ale bez komplikací)
- (-) dodělávky implementace z předchozí iterace
Iterace - slušné
- (+-) cíl v souladu s fází projektu, ale obsah ne zcela (dodělávky implementace)
- (-) ještě v průběhu a ke konci přidány Enhancements
- (+) burndown rámcově ok
Technická kvalita - slušné-skvělé
- (+-) vytvořena technická dokumentace, věcná, ale obsahuje zbytečně moc informací o historii a zadání projektu
- (+) backlog a plán iterace začištěny
- (-) není zřejmé, jestli jsou po dokončení projektu známy nějaké zůstávající chyby, nedodělky
- (+-) finální merge na master branch, vytvořen tag na konci iterace, ale není označen jako release
- (+) systém nasazen a v provozu na cílovém serveru
Postupy a praktiky - slušné
- (-) některé tasky velmi rozsáhlé (#7507, #7580), hodně jich bez odhadů - spěch konce projektu
- (+) beta-testování na dálku, předání osobně, připomínky řešeny (viz Iterace), OK
Průběh a stav projektu - skvělé
- finalizace implementace, ale ještě ne IOC
- podstatnou část času byl tým na dovolené, plánováno dopředu
- (+) projekt on track
Iterace - slušné
- (-) cíl nedosažen úplně, zbytek produktu nedokončen zcela
- (-) výrazně podhodnocený odhad (29h) oproti realitě (43h), dobře vyřešeno (práce navíc + přeplánování nekritických prací)
- (+) retrospektiva dobře popsaná
Technická kvalita - slušné
- (-) chybí low priority v backlogu (přeplánování uděláno ad hoc)
- (-) testy nejsou explicitní (specifikace, report), jsou dělány ručně bez scénářů v rámci QA na jednotlivých úkolech
- (+) src dobře strukturované a komentované
Postupy a praktiky - skvělé
- (+) výrazně dobře používáno komentování v Redmine
- (+) vytvořen tag na konci iterace, správně
Konečnou retrospektivu jsme pojali v duchu odpovědí vyplněním dotazníku po uzavření projektu.
Retrospektiva:¶
Plánování:
- Za týden po dovolené jsme zvládli všechny úkoly až na úkoly, kde se vyskytly problémy. Export/import textů byl velmi časově podhodnocen a přidávání textů se potkalo s problémy mnoha komponent na jednom místě.
- Vše bylo zvládnuté, přidávání textů posunuto na další iteraci (ze 70% hotovo), řešení času u bodu odhadů.
Komunikace:
- Bez problémů, až na dokumentace. Jakmile se zmíní že se musí něco přidat do dokumentace, nikomu se nechce.
- Bude se muset vzít bič..
Iterace:
- Dovolená + implementace, proběhlo bez problémů
Odhady:
- Všechny odhady seděli až na import/export. Byly to poslední úkoly, které se ohodnocovaly a po hodinovém střílení hodin došla všem energie a první číslo, které se řeklo se odsouhlasilo.
- Vynechali jsme z poker planningu pauzu na kafe, je vidět, že je důležitá.
Výsledek aplikace:
Poznatky z weekly
Co máme:¶
Co jsme zjistili:¶
- Object a Surface type nefunguje mazání ajaxem (gridy)
- V přidávání object type ve formuláři je typo "Object Tyoe"
- V editačních formulářích některých chybí tlačítko pro odstranění daného záznamu + jednou je tlačítko na smazání vlevo, jednou v pravo... takže sjednotit
- https://aswi2019medici.zcu.cz/www/transliteration/view/8945 přidat odkaz na editaci transliterace
- Statické stránky jako contact & members přidat obsah (edited)
- Export neni zcela dynamický, při přidání nového typu surface se nepřidá nová zkratka ke zpracování transportu, protože jsou nakóděný "natvrdo"
- Filip ještě udělal zálohu DB z ostrý
Průběh a stav projektu
skvělé
- (+) nasazena první fční verze na server, projekt on track
Iterace
skvělé
- (+) cíl dosažen, burndown ok, retrospektiva provedena
Technická kvalita
slušné
- (+-) práce s backlog: obsah aktualizován ve sdílené excel tabulce, ale není vidět, které reqt (user stories) jsou už hotové: v excelu není status, v redmine issues není vždy story ID
- (+-) doc arch: doplněn, napsaný stručně pragmaticky ale rozumně, chybí snad jen info o použitých plug-ins pro Nette
- (-) nejsou testy, diskutovali o tom ale z časových důvodů nerealizovány
Postupy a praktiky
skvělé-
- (+-) retrospektiva udělaná slušně, ale jen jako soupis faktů z iterace, chyběly poznámky "co s tím"
- (+) planning poker funguje dobře ale některé odhady nadhodnocené
- (+) SCM postupy zaběhlé a správné
- (-) QA postupy nedetekovatelné "v datech"
Týmová dynamika a různé
- bez problémů, programátorský tým, který je "ve svém živlu"
Jaká byla dána doporučení
- Prodiskutováno, jak přistupovat k QA/testování a jeho dokumentaci, a jak k retrospektivě.
Co máme:¶
- Dokumentace vize, frameworky, use-case diagramy, dokumentace architektura (tak napůl, dost formálně)
- Funkční login, začátky implementace, afs přístup
Co jsme probrali:¶
- Ověřovat na redmine dokumentace? (resolved>closed)
Ne, části dokumentace se uzavřou ihned, pouze výslednou dokumentaci někdo překontroluje a pak uzavře.
- Příprava na zákazníka.
Ukážeme co máme již implementováno. Musíme se dotázat: Budeme jí to ukazovat nebo si to bude moci testovat sama přes testovací doménu aswi2019medici.zcu.cz? Otázky na slovník a ostatní moduly.
- Následující iterace, co bude, jak bude. Jak budeme řešit další iteraci společně s dovolenou, jak bude probíhat poker planning, kdo předplánuje tasky/enhancementy co budem probírat?
Tasky enhancementy připraví podle user stories vedoucí týmu podle vlastního uvážení, jak bysme to mohli stihnout. Výsledné hodiny na pokerplanningu. Nesmíme to přepálit jelikož máme jen 2 týdny. Hlavní bude implementovat klíčové funkcionality (login, vyhledávání, základní administrace, minoritní editace).
- Jak to je s tím zču serverem. Jaké jsou ty detaily na databázi/přístupy na zču afs? Zabezpečení přístupů?
Máme doménu, nemáme přístupy na databázi. Nebo zatim ani nevíme jak se s přistupy dostat na afs server, jak tam nahrávat, upravovat. Filip se do toho horlivě pustí aby to do začátku iterace bylo možno používat.
- Ostatní architektonický modely
Zeptáme se Šaškové jestli to vyžaduje, podle nás to neni třeba. Stavíme na brownfield projektu, era diagram je ze zkušeností postačující, ostatní modely budou z bývalých zkušeností jen jako přítěž sloužit k nepřehlednosti v dokumentaci.
Průběh a stav projektu *
slušné-skvělé
- Projekt je "on track", dosažen (ale ne plně dokladovatelně) milník LOA, proces odpovídá.
Iterace *
slušné
- Cíl iterace OK vzhledem k průběhu projektu
- Retrospektiva nezaznamenaná
- Burndown -- vysvětlení: přibylo trochu práce na dokumentaci, neodhadnuto na začátku + čekání na odpvědi z CIV zdrželo další práce
- Mají zavedené customer demo přes email, schůzky se zákazníkem on demand
Technická kvalita *
slušné-skvělé
- Doc vize velmi dobře udělaný, na základě zpětné vazby z minulé schůzky, jen drobné nedostatky (kritéria úspěchu nerealistická v kontextu projektu, chybí požadavek na převod stávajících dat) -- kandidát na "vzorový artefakt"
- User stories velmi rozumně zachycené (excel, struktura), existuje jistá vazba mezi US a Vizí a Enhancements, ale není úplně systematická -- dáno genezí
- Doc arch v podstatě neexistuje, jak má arch vypadat mají v hlavách a na některých věcech ještě nejsou domluveni (fasády na modelu), ale task "vytvořit doc arch" je Closed :-/
- Vlastní struktura aplikace je dle Nette konvencí a v pořádku
- Validace arch neudělána, doufají že to bude OK
- Struktura git repo dle konvencí, OK
Postupy a praktiky *
skvělé-slušné
- Snaha odvozovat úkoly z požadavků (trasovatelnost Vize - User stories - Enhancements - Tasks), i když ne vždy systematická a úplná (key reqts ve Vize odvozeny z User stories => chybějící "převod dat" apod.), některé Enhacements jsou technické nikoli uživatelsky zajímavé
- Na vývoji dělají "všichni vše" - Kanban style přiřazování ticketů
- Použit planning poker a verifikace při resolved-closed na ticketech, oboje vnímáno jako užitečné
- Task branches s merge request/commits
Týmová dynamika a různé
- Tým funguje společně; planning poker užitečný pro vyjasnění i technických nuancí řešení. Zúročovány zkušenosti z práce (RT Soft).
Jaká byla dána doporučení
- Burndown jako námět, co řešit v retrospektivě
Průběh a stav projektu *
(slušné)
- správně se identifikují uprostřed fáze Elaboration
- činnosti prováděné během iterace ale neodpovídají fázi projektu, viz další bod
Iterace *
(špatné)
- diskrepance mezi deklarovaným cílem "Pochopení cíle projektu a potřeb zákazníka" a provedenými činnostmi (analýza konverze DB, technologií pro impl.)
- výběr backend frameworku předčasný resp bez možnosti zohlednit info z analýzy stakeholders a zpřesnění zadání, které běží až v následující iteraci
- burndown typický "collective procrastination", důvod = měli hotovo v průběhu ale úkoly uzavřeny až na konci
Technická kvalita *
(slušné)
- dobrá analýza front- a back-end frameworků, ale nezohledněn aspekt dlouhodobé udržovatelnosti, viz předchozí bod
- artefakty typu SQL DDL a prototyp web UI jsou udělané, ne všechny jsou v úložišti
- popisy ticketů velmi stručné ale ještě použitelné, odhady atd. vedeny v pořádku
- DMS nešikovně strukturováno podle iterací
Postupy a praktiky *
(slušné/skvělé)
- artefakty dělají v Overleaf, proto nejsou na wiki ale v DMS - trochu overkill a kostrbatě přístupné, ale dobře udělané i po formální stránce, takže ok
- vzniklé artefakty jsou odkazovány v příslušných ticketech, správně
- plánování a odhady dělal team leader, nadhodnocené; zohlední v dalším plánování
- mají task branches + oddělené role a autorizaci pro git branches, výborně
Týmová dynamika a různé
- iterace začínají vždy další den po skončení předchozí
- jsou domluveni, že na třetí iteraci zkusí planning poker
Jaká byla dána doporučení
- tým si má vyjasnit, zda plánování N+1 iterace je činnost "v mezidobí mezi iteracemi, nebo v N-té iteraci, nebo v N+1 iteraci"
Co máme:¶
- Datový model, prototyp UI, soupis požadavků v prezentaci, funkční nástroje
Co jsme probrali:¶
- Poupravit dokumentaci projektu, nepsat tam žádné zbytečnosti (zapsaná analýza do samostatných částí a na DMS)
- Domluvení na konvenci zápisu kódu, pushování a mergování na gitlab
- Domluvení na konvenci práce s redmine issues.
Volné Tasky > developer si dá assign -> po zhotovení resolved -> jiný developer vezme k otestování
> (prošlo testováním) closed
-> (neprošlo testováním) assign zpět developerovi s popisem bugů
- Databáze a její funkcionalita - Paleček tomu porozumí a sepíše to do privátní dokumentace (nebo DMS)
- Pojedeme na dovolenou ve 3. iteraci -> přesuneme některé části implementace už do 2. iterace
- Na další schůzi se zákazníkem je potřeba si upřesnit, jestli budem přesouvat pouze konkrétní aplikaci nebo všechny na které jsou na webu odkazy (1 projekt nebo všech 5 = db peklo)
- Tuto iteraci to chce dělat hodně dokumentace (use case, specifikace, business case, atd.)
- TDD style? ne
- Dořešit poslední části v první iteraci, přeplánovat zbylé
Celkové hodnocení projektu
