Hodnocení 2. iterace

Přidáno uživatelem Petr Pícha před asi 1 rok

Hodnocení
7¶

zpřístupnit zákazníkovi/projet s ním (memontální) plán projektu, aby věděl co kdy čekat
více "řídit" schůzku - přijít s připravenou agendou, říct, co je třeba říct a nechat zákazníka reagovat
promyslet jaké popisy architektury/návrhové artefakty jsou vhodné pro 1) vývoj, 2) součást předání, a začít na nich dělat

- zdržení kvůli nepředvídaným problémům a podstřeleným odhadům
- LCO brání nedostatečná specifikace zásadních požadavků
+ interní komunikace dobrá, - externí "pasivní"
0 rozložení zátěže v týmu nevyrovnané, ale zatím má (snad) důvod
+ rozdělení kompetencí na vývoj vs. TC
+ snaha o zapracování feedbacku z minula
- zdá se, že nejsou plánované LCA artefakty
- projekt je pravda, specifický, přesto architektura a návrh řešení je neopomíjitelný
hodnocení: slušné 1,5

0 kapacita se naplnila podle odhadů, ale některé položky zabrali víc času, takže se nestihlo všechno
+ náplň, většina retrospektivy
- některé tickety ne uzavřené
+ dohnání náslechových schůzek mentora, vč. dema
hodnocení: slušné 2

+ přeplánování ticketu proběhlo správně
+ obecně práce s tickety, vč. systému zprávy 2 front (RM a GL) a odkazování v branches/commitech
0 tag jen výchozí, plánují se feature/iterační tagy?
+ konvence trochu nepřehledné, ale zachycují dost
+ instalační manuál
+ zápisy schůzek
+ oprava Vize, code reviews
hodnocení: skvělé 2,5

- "nepředvídané" problémy byly předvídatelné (souběh předmětů, neznámé technologie), jen se s nimy správně nepracovalo
demo
- - pasivní přístup, většinou mluvil zákazník
- - "jsme mysleli", "vypadá to asi dobře" jsou formulace, které by se ideálně měly objevit co nejméně
  - ne proto, že prozrazují nejistotu/problémy, ale proto, že nejistota/problémy vůbec existují
- - nebylo jasné, že obě strany ví, že demo má probíhat po každé iteraci
retro
- + identifikace podstřelených odhadů
  - - ale co s tím?
- - je dobré projekt monitorovat přes Redmine (od toho tam je) a reflektovat fakta do retrospektivy (když už ne do day-to-day řízení)
  - burndown, filtry, rozložení práce, atd.
- + reflexe výstupů minulé iterace
planning
- 0 možná trochu zbytečně nejdřív na papír a pak překlápění do Redmine (stejně jako zápis schůzky) - nežere to zbytečně čas?
- - neřeší se kapacity
hodnocení: slabé 1