Számomra az egyik legkedveltebb része az agilis módszertannak, hogy a csapat saját maga határozza meg azt a szabály rendszert, amiben dolgozni szeretne sprintől sprintre. Ha a közösen megalkotott szabályok mégsem bizonyulnak megfelelőnek, akkor a csapat a retrospective keretében módosíthat rajta, elvethet egyet, hozzáadhat újat a listához. Jelenlegi csapatom egyik ilyen kitétele volt, hogy nem kötelező a logolás, vagyis nem fognak logolni. (ez amúgy céges szinten is sokszor vita tárgya)
Egy nagy projekt kezdetekor, tele lelkesedéssel és ekkora kihívással szemben állva PO-ként erre simán áldásomat adtam, hiszen úgysem ezen fog múlni egy sprint sikeressége. És valóban, nem is volt ezzel semmi gond, planningen megvolt a becslés és kész, jobban fókuszáltunk a SP-kra.
Az első problémák most adódtak, amikor realizáltuk, hogy csúszunk a projekttel és tudni kellene, hogy milyen sebességgel halad a csapat (óraszámmal) és a hátralevő taskok mennyi idő alatt hozhatóak le. Nem mindenki logolt, aki logolt az is össze-vissza, így nincs a kezünkben egy pontos mérőszám, így a jövőre vonatkozó kalkulációnk is csak becslés lehet. Meglepően alacsony napi óraszám jött ki, és nem csak a logolás miatt, hanem a lehozott storykra adott becsléseket összeadva is. A csapat elé tárva ezt az értéket ők is meglepődtek és realizálták, hogy ez valóban kevéske.
Úgy látszik a boardból, hogy rákapcsoltak, kíváncsi leszek ebben a sprintben mennyi lesz a vége.
Akcióként hoztuk, hogy mostantól mindenki pontosan logol a projekt végéig.
A jövőre vonatkozó tanulság, hogy sajnos nem mindenben lehet engedni a csapatnak, a mérőszámok fontosak a projekt egésze alatt. Megfelelő becslés, és következetes logolás mellett időben észre lehet venni a csúszást és időben reagálni, beavatkozni.
Tippek logoláshoz:
- backend és frontend külön subtaskra logoljon
- ha Jira-t használsz, akkor nézd át az exportot, mert nem mindig számol rendesen
- automatikus log tool használata
Nincsenek megjegyzések:
Megjegyzés küldése