Mit tegyünk, ha a Scrum nem jó?
Mikor Agile szoftverfejlesztés szóba kerül, akkor önkéntelenül mindenki a Scrum-ra gondol, pedig nem így van. Korábbi írásomhoz érdekes és tanulságos hozzászólások születtek. Több ötletet és elgondolást találtam, amit hasznosítani tudok.
Egy dolog biztosan kiderült: az agile módszereknek van feltétele. Ezt a feltételt leginkább cég szinten kell biztosítani erre nagyon jó megoldás lehet, ha a cégvezetés elsajátítja a Franklincovey cégvezetési elveket. Az elvek azonosak és megvalósításban is nagy hasonlóság van. Pár hete voltam és az egyik legzseniálisabb képzésen, amin valaha részt vettem.
A nagycéges környezetben való agile használat majdnem lehetetlen abban a formában ahogy a manifesztóban szerepel. De szerencsére nem kell ragaszkodunk hozzá. Agile csak alapelvek. A konkrét fejlesztési módszerek és technikákból össze lehet rakni egy olyan “saját” fejlesztési folyamatot, ami a adott keretek között a leghatékonyabb tud lenne. (Egyébként szeretem a Scrum-ot, sőt SCM papírom is van)
Pár olyan technika és módszer, ami saját tapasztalatom szerint bevált és javítja a fejlesztési folyamatot:
- Iteratív fejlesztés: A nagyot tervezünk és onnantól kezdve kidolgozzuk és fejlesztünk és a végén majd meglátjuk mennyire sikerült elkészülnünk nem olyan hatékony. Sokkal praktikusabb, ha rendszeres ellenőrző visszacsatolásokat iktatunk be. Ügyfélnek lehetősége van megvizsgálni az eredményeket és mi az alapján módosíthatjuk a munkafolyamatunkat.
- Inkrementális delivery: tapasztalatom szerint minden fejlesztés felbontható önállóan is kerek egész, tesztelhető falatokra. Ezeket a falatokat elkészítjük és átadjuk. Az átvevő nem is minden esetben a végső ügyfél hanem egy belső tesztelő csapat. Az tesztelés eredményeként megkapjuk azt a visszajelzést, amivel korrigálni tudjuk a szoftvert. A legjobb az, ha az iteratív fejlesztést összekombináljuk az inkrementális szállítással.
- “big visible charts”: burndown, sprint dashboard stb. Alapszabály, hogy minden résztvevőnek minden pillanatban tisztában kell lennie, hogyan is áll a projekt. Alapszabály, hogy 3 másodperc alatt képet kell kapnunk. Ez egy eszköz arra, hogy a célok világosak legyenek és mindenki tudja, mi a legfontosabba projekt egészére vonatkoztatva. Sokan lebecsülik ezt az eszközt, mert olyan “gyermeteg”, bagatel. De ugyan ezek az emberek küzdenek azzal, hogy nem tiszta ki mit csinál és kérdezgeti a fejlesztőt, hogyan is áll mosta fejlesztés. Pedig ha lenne egy egyszerű burndown a kérdései java részére választ kapna.
- Daily standup: folyamatos kommunikáció. Ritmust ad a napnak. Minden információ naprakészen előkerül. Csak azok nem profitálnak belőle, akik nem akarnak.
- Retrospektív: Nincs fejlődés, ha nem, vizsgáljuk meg önmagunkat. Panaszkodásban jók vagyunk. Még ötleteink is akadnak arra nézve, hogy miként lehetne jobbá tenni a saját életünket. De cselekvés rutinja nélkül mindez semmit sem ér.