Nem érünk oda

Az aktuális projektem közepe felé (5-7. sprint) a mérőszámok alapján már láttuk, hogy nem fogunk odaérni az aktuális velocityvel, ahova terveztük, időben. A csapat egy része számára ez nagy teher volt, a másik fele próbálta behozni, de csak kudarc lett belőle a sprintek végére. Az egész csapat stresszben volt, velem együtt, a demot nem ünnepnek éltük meg, a hétvégék is ennek a rossz érzésnek a hatalmába kerültek. Mit tehet ilyenkor egy PO vagy a csapat?

Kép forrása: stressz-m

A becslések nem voltak mindig pontosak, és a 2 hetes sprint nem adott elegendő kontrollt., tehát nem tudtunk időben beavatkozni, hogy sikeres legyen a sprint. A csapat mindig úgy látta, érezte, hogy a sprint végére össze fognak érni a szálak, be fogják hozni a storykat, de valahogy sosem sikerült. Egy-két story kihagyása végülis nem a világvége, de a sprintek számának növekedésével a le nem hozott storyk összege is emelkedett.

A másik probléma, hogy görcsösen ragaszkodtunk minden story elkezdéséhez. Így ha például 12 story volt betervezve a sprintbe, akkor a végén lett 10 darab 90%-ban kész story és két darab el sem kezdett story. De ha arra koncentráltunk volna inkább, hogy befejezett storykat hozzunk le, akkor lett volna 9 darab 100%-osan befejezett story, ami az ügyfél számára is nagyobb értékkel bír, mint több, de itt-ott sántikáló funkció.

Fontos volt valami akció tervet hozni, különben nagy baj lesz a végén. Két eszközt használtunk a sprint közbeni ellenőrzésre.

Meghatároztunk sprint közbenre egy milestone-t, ami a planningen definiált, és az előzetes becslés alapján addigra lehozható storykat tartalmazta. Ezeknek a storyknak a milestone-ra el kell készülnie, ha más külső akadályozó tényező nincsen.

A másik módosítás a feature freeze volt, ami arra irányult, hogy a sprint forduló előtt 1 nappal nincs több új task fejlesztés, hanem a meglévő bugok javítása, az addig elkészült storyk jobbítása volt a cél. Mivel a tesztelő 1 nappal a sprint forduló előtt kapja meg az összes storyt (vegyük figyelembe, hogy jelen esteben komoly függések voltak a storyk között), így kevés idő maradt a funkciók összefüggésében való tesztelésére és a feltárt hibák javítására, sajnos sokszor előfordult, hogy a demo előtt 10 percel még volt merge request.

A milestone beiktatása technikailag annyit jelentett, hogy kedd délután már csak bug javítás volt, új task fejlesztése nem, és szerda reggel tartott egy mini demot a tesztelő nekem.

Ugyan a milestone felfogható pótcselekvésnek a burndown chart helyett, de amíg nem működik jól egy csapat, addig nem ez nem ad pontos visszajelzést, és segít a csapatbak fokúszálni arra, hogy hol tratanak és valóban oda tudunk-e érni a sprint végére, a projekt végére.

A bevezetett intézkedések több kontrollt adtak a kezünkben és az elmúlt 3 sprint tapasztalata alapján elmondható, hogy pozitív hatással volt a csapat teljesítményére, az ügyfélnek szállított értékre.

És hogy ez mennyire agilis? Miért nem álltunk át inkább 1 hetes sprintekre?

A csapat félt attól, hogy a plusz agilis események annyi időt vesznek el, amit jelen szituációban a csapat nem vállalt be.

Mindenképpen szerencsésebb az a fajta hozzáállás, hogy kevesebb, de teljesen jól működő storykat hozzunk le egy sprintben, mint folyamatosan magunk előtt görgetünk minden storyt sprintről-sprintre.

Amikor összeérnek a cégen belüli projektek

Jelenlegi ügyfelemhez gyárlátogatást szerveztünk csapatomnak és egyszer csak az alábbi kép fogadott:

Egyrészt fura, másrészt felemelő érzés látni, hogy a cégen belüli projektek, hogyan érnek össze. :-)

Feeling great!

Scrum review okosan

A jelenlegi projektem során felmerült, hogy hogyan lehetnénk hatékonyabbak, hol tudnánk időt spórolni. Az ötletelést közösen a csapattal csináltuk és az egyik ilyen felvetés érdekes módon a demo volt. Az az esemény, aminnek egy ünnepnek kéne lennie, ahol a csapat átadja a terméket a PO-nak. Vajon elég, ha csak a demozó és a PO van jelen?

Boncolgattuk a dolgot, és összeszedtük a problémákat, hátrányokat és az előnyöket az elképzeléssel szemben.

Probléma:

- ott ül az egész csapat, de csak 1 ember demozik
- mivel mindenki ott van, ezért sokba kerül
- ha nem megy gördülékenyen, akkor nem érzik ünnepnek

Előny (ha nincs ott a csapat):

- közben tud termelni a csapat
- nem érzik kínosnak, ha nem megy simán
- olcsó

Hátrány (ha nincs ott a csapat):

- a csapat nem szembesül a szarral
- a csapat nem szembesül a jóval, nincs ünnep
- nincs meg a sprint lezáró élmény

Látható, hogy az egyik kulcs tényező, hogy milyen maga a demo. Ha rendben megy, gördülékeny, gyorsan, akkor az előnyök eltörpülnek és nem jelenthet kifogást, kapaszkodót. De mit tehetünk azért, hogy gördülékeny legyen egy sprint review?

Tippek:
- legyen felkészülve a demozó
- storykat nézzünk, ne DC pontokat
- legyen előkészített tartalom, anyag, ahol szükséges
- nem vihet be magával senki laptopot
- PO is készüljön fel, mondja el kezdésként, hogy mit szeretne látni
- legyen megfelelő műszaki háttér (SM intézze)
- adjunk körbe post-it lapokat, hogy a kérdéseket, észrevételeket le tudják írni

Veszprémi Technology Meetup előadásom témája: Startup buktatók

Jövő héten előadok a Veszprémi Technology Meetup-on:

Update (pár kép az előadásról):

Az élesítésen túl

Adott egy projekt, amelynek keretében egy információs és támogató weboldal létrehozása a cél. Product Ownerként a funkció lista elkészítése, egyeztetése és a projekt levezetése volt a feladatom, a meglévő követelményelemzés alapján. Nagyon inspiráló volt a feladat, mivel nemes célt szolgált az oldal, így szép kerek és valóban hasznos funkciókból állt össze a végső backlog.

Az első komolyabb egyeztetés folyamán azonban az ügyfél részéről az alábbi aggályok merültek fel:

- Ezeket nekünk kell feltölteni tartalommal?

- Ki fogja moderálni a bejegyzéseket, kérdéseket, hozzászólásokat?

- Ki fog válaszolni a felhasználók kérdéseire?

Stb.

Gondolom kitalálta a kedves olvasó, hogy erre nem volt erőforrás tervezve, így nem volt más hátra, mint olyan fontos funkciók kihúzása, amitől igazán hasznos és kiemelkedő lett volna a weboldal. Így csak egy szokásos, élettelen, információs oldal lett a végeredmény.

Sajnos itt is előjött az a probléma, ami nagyon sok webáruházat indító személynél homályos pont, hogy ki is fogja életben tartani a weboldalt. Sajnos sokan azt hiszik, hogy az élesítés után már nem kell foglalkozni az adott oldallal, az majd működik magától. Ez tévedés, a munka nagyobbik része, csak ezután következik: információ és termék feltöltés, ügyfél kezelés, marketing stb. Az üzleti tervnek ennek is része kell, hogy legyen, ki és mennyit fog az adott részfeladatokkal foglalkozni. És természetesen ezt órában és összegben számszerűsíteni kell, hogy a megtérülést és egyéb mutatókat számolni tudjunk.

Sajnos a legtöbb helyen csak az indulásról beszélnek (startup - sicc) és nem esik szó arról, hogy maga az üzemeltetés, a folyamatos működtetés mennyi energiát és időt emészt fel. Ha pedig nincs rá erőforrás, hogy bizonyos feladatokat (pl. marketing) kiszervezzünk, akkor még jobban elaprózódunk, hiszen olyan területtel kell mi magunknak foglalkozni, amihez nem értünk, így a tudás felszedése is időbe telik. Ráadásul sosem leszünk olyan profik,mint akik napi 8 órában ezzel foglalkoznak.