26.5.
Iterace¶
obsah a průběh 5., 6. iterace v pořádku, nadhodnocená pracnost (o 1/4)
7. iterace (předání) ještě last minute úpravy a bugfixy
doplněny formality u artefaktů SRS, Arch + README per project
v rámci 5. a 6.iterace v Redmine uzavřeny feature issues vázané na SRS požadavky, slušně udělaná trasovatelnost reqts - features - tasks - commits
důkladné testování v závěru projektu, nějaké chyby nalezeny a evidovány
5.it 12b, 6.it 12b, 7.it 10b
Projekt celkově¶
cca 40h navíc kvůli last minute reqt finalizace + dolaďování
na začátku míň efektivní, např. účast všech na schůzce spálila hodně člověko-hodin i když se neřešily věci pro celý tým
cílili na cca 400h ale trochu podcenili náročnost (hlavně design+impl vyznačování anotací) + schůzky delší (domlouvání po schůzce) + last minute reqt
citace: "výhoda je, že čas nestojí peníze jako ve firmě" :-)
provedeny dílčí úpravy procesu (zejm. customer demo), dobré ale uděláno spíše intuitivně než plánovaně - např. není zachyceno v retrospektivách
tým v průběhu laboroval s délkou iterací; negativem je (zvnějšku pozorováno) až moc intuitivní způsob tohoto laborování, pozitivem je schopnost rychle zjistit problém a opravit kurs (nesetrvat v nevhodném procesu)
udělán doc zhodnocení prj, vůči vizi a kritériím úspěchu; dobré
získali (ve Vizi plánovanou) zpětnou vazbu od uživatelů
zákazník spokojen nad míru/očekávání, reflektuje že zkomplikoval situaci opomenutým požadavkem
Reflexe - "příště případně jinak":
- upravit ticket workflow tak, aby closed bylo udělané hned po review a merge na dev; původní myšlenka zavírat to společně se ukázala jako ne potřebná resp. jen u několika málo případů
- ne úplně se osvědčilo reportování chyb napřed do discord channel a pak do RM, protože v discordu toho bylo hodně a v šumu se vcelku dost info ztratilo nebo byly duplikované, otázka je co by se hodilo použít pro prvotní reporting chyb (trello, diskuse s vlákny) aby bylo lightweight ale přehledné; ale bylo to v poslední iteraci a už nemělo cenu řešit
- na konci se ukázalo, že 2-týdenní iterace byly dlouhé kvůli potřebě zaplánovávat zpětnou vazbu, dělali 1-týdenní, ty by se možná byly hodily i dřív kvůli zaplánování hodin co se kdy stane (“oslava u babičky” apod.) – a přitom v průběhu prj měli v úmyslu udělat 3-týdenní implementační iterace ;)
Hodnocení¶
10b
Průběh a stav projektu -- dobré
Iterace -- výborné
Technická kvalita -- slušné až dobré
Postupy a praktiky -- výborné
10 bodů
12.5.
Souhrn¶
Hlavní poznatky
- effort estimation relativně klasicky - planning meeting at iteration start, assignee navrhne, případná diskuse a úpravy, pak zanesení do ALM
- upravený proces “customer demo”, sice nereflektovaný jako změna metodiky ale udělané dobře
buffer 7h
- retrospektivy jen “rekapitulace průběhu”, reflexe podprahová, diskutováno
- QA postup rozumný (systematické vyřešení před reportováním bugu)
- [PPí] plánováno o 170h víc než by mělo nominálně být (!), diskutováno (pečlivé reportování času + opravdu strávili hodně času ale nevadí)
Kvalifikovaně vyřešený last minute požadavek zákazníka (výměna za lower-priority funkčnost), byť znamenalo zvýšení pracnosti.
Customer demo: zákazník nemůže synchronně v den konce iterace a potřebuje čas na dodání zpětné vazby => dávají přírůstek zákazníkovi v průběhu iterace a feedback sbírají průběžně, zapracování do plánu další iterace (na toto alokovaný čas v plánu it.)
DSP: jako základní checklist funkční; není žádná viditelná vazba (trasovatelnost) na features ve Vize; není použita žádná std forma specifikace jednotlivých požadavků; P-13 a P-14 nejsou striktně řečeno funkčními požadavky, spíše jde o pravidla; mezi NFR zjevně chybí důležitost UX a objemové charakteristiky (cf FURPS+); pěkně zaznamenané změny reqts “ručním změnovým režimem” DSP
Testování: základní testy OK, pokrývají všechny úrovně testování, funkční a UX testy teprve v přípravě. Proces řešení chyby dobrý (tester nalezne -> Discord diskuse -> Redmine nebo quick fix nebo vysvětleno)
Hodnocení¶
Průběh a stav projektu -- výborný
Iterace -- výborný
Technická kvalita -- slušné
Postupy a praktiky -- výborné
9 bodů
review 14.4. (~3 dny před dokončením iterace)
Doporučení¶
- ze strany týmu aktivně konzultováno, jak přistoupit k naplánování následující(ch) iterací: původní očekávání delší implementační iterace vs reálná potřeba získat feedback během cca týdne. doporučeno vždy hlídat principy (cíle milníků WRT rizika, struktura a cíl iterace obecně).
Průběh a stav projektu - dobrý¶
- projekt “on track”, identifikováno (správně) “jsme za LCOA”
- přístup k plánování iterací celkem dobrý: podle nejdůležitějších požadavků, nicméně děláno nikoli dle priorit ve vizi apod., ale ze záměru “předat brzy [MVP] pro včasný feedback od zákazníka” (což je také správný přístup)
další komentáře
- dosud strávený čas: odhad 314h, stráveno 198h
Iterace - dobrá¶
- iterace přehledná, podle “hours burndown” zpoždění - většinu plací plánováno dokončit o dlouhém víkendu
- (iterace ještě běží => retrospektiva zatím není)
- diskutováno, zda do iterace ještě zahrnout práce pro “docker deploy” (nebylo v plánu, hodilo by se) nebo zda je mít v rámci následující iterace
Technická kvalita - slušná¶
- vize finalizována dle zpětné vazby, dobře udělaná
- backlog, specifikace požadavků, popis architektury - viz 2. iterace
- popis architektury nereflektuje přesně skutečný stav, diskutován obsah diagramu vnitřní architektury (chybějící vazby)
Postupy a praktiky - výborné¶
- ALM, VCS stále dobré
- QA: testování je součástí prací implementace, v tuto chvíli odpovídá postupu v projektu
- problém s GitLab autentikací u jednoho člena, podchycen jako (nové) riziko, aktivně vyřešen
11 bodů
review: 14.4.
Doporučení¶
- pro retrospektivu doporučeno použít G/S/M nebo L/L/L schema (současnou šablonu možno zachovat, ale krom “jak dopadly změny…” zatím použita jen pro faktografii, chybí reflexe)
Průběh a stav projektu - výborné¶
- projekt “on track”
- negativa nezaznamenána
další komentáře
- dosud strávený čas: odhad nezjištěn, stráveno 167h
Iterace - dobré¶
- přehledná (mj. velmi podrobné úkoly), vcelku dobře řízené (ale viz backlog)
- burndown OK – “ocásek” kvůli nejasnosti jak řešit úkoly ne zcela dokončené během iterace (konzultace 11.4. => uzavřít “closed” s částečnými hodinami + nové tasky pro další iteraci)
- retrospektiva zaznamenána, není v ní příliš reflexe
Technická kvalita - slušné¶
- diskutován backlog, nemá vlastnosti DEEP, vztah k (podrobnější) specifikaci požadavků, ke sledování naplnění v průběhu projektu a možnostem změn rozsahu.
- specifikace požadavků (google dokument) – není zřejmé, zda jde / má jít o samostatný artefakt, požadavky nemají formu dle doporučení a tím pádem v nich chybí podklady pro rozhodování a sledování
- architektura - věcný návrh zřejmě dobrý, u popisu není zřejmé, zda jde / má jít o samostatný artefakt
- na wiki chybí odkaz do gitlab
Postupy a praktiky - výborné¶
- práce s ALM dobrá, dodržované konvence při práci issues, použity vlastní dotazy, rozpad na pod-úkoly, rozumně používané popisy úkolů a komentáře
- VCS patterns dobré, vazby ticket-commit systematické (dle konvencí)
Projekt na začátku, jasno v hlavních fcí a prioritách, návrh UI udělaný, rozmyšlená arch + technologie; krátce za LCO
Práce s ALM - výborné
- postup v gitlab využívá větve a zahrnuje code review
- práce s úkoly v Redmine rozdělena, oddělené plánování a kontrola
- doc na konvence je udělaný, potřebuje doplnit role/lidi
Plán a řízení projektu - dobré
- tým zjevně ví co a jak dělat, postupy vymysleli víceméně sami ze zkušeností
- plán (po iteracích) na wiki, není promítnutý do redmine - prodiskutováno, proč by mělo být.
- trasování vize - features - tasks zatím není, prodiskutováno; vytvořen vlastní dotaz v Redmine na top-level úkoly
- rizika jsou v redmine napsaná vč. “možné řešení”, diskutována práce s riziky
Technické činnosti a výstupy - dobré
- týmem vypíchnutá důležitost kvality GUI pro anotování, diskutován dopady na plánování
- doc vize – dán zákazníkům k finálnímu vyjádření, zatím není výsledek; celkově udělaný dobře, obsahové nedostatky okomentovány v dokumentu
- plánované jsou budoucí automatizované testy přes gitlab runner
Formality - výborné
- na wiki pořádek, dělají zápisy ze schůzek, dokumenty systematicky v gdoc adresáři
- dělení práce mezi členy organizované a (jeví se) dobré
Review a hodnocení 5.-7. iterace, projektu