2011. december 2., péntek

Retrospektív - egy hasznos eszköz, de hogyan is...?

Visszatekinteni és végignézni, mit is csináltál jól vagy rosszul egy adott időszakban, mindig jó. Persze csak akkor, ha akció is követi a megbeszélést. Sok helyen, ahol a Scrummal próbálkoznak megfelelő irányba terelni a biteket és byteokat, a sprint végén vagy két sprint után szoktak retrót tartani (aki még nem tudná, a sprint egy időtartam, egy fejlesztési iteráció, 2-4 hét szokott lenni), mert úgy gondolják, hogy addigra már felgyűlt annyi megbeszélnivaló, hogy érdemes összeülni egy kicsit és dumálni egy jót. Jó ez így vagy ezen is lehet tuningolni? Lehet, persze.
Nem jó sokat meetingelni. Az emberek kiesnek a munkatempóból és/vagy elunják magukat, elkezdenek rajzolgatni, a telefonjukkal babrálni, vagy a laptoppal, ha pedig megtiltod nekik, hogy behozzák, akkor te egy despota vagy és tehetsz egy szívességet, és különben is, "nem az óvódában vagyunk, hogy parancsolgass nekem". A túl hosszú meeting nem hatékony és minél később van egy adott napon, annál rosszabb. Szóval csak akkor kell megbeszélni, ha már nincs más kiút.
Akkor hogyan kezeljük a retrókat? Elhagyni nem lehet, hiszen fejlődni mindig kell és az egyik eszköz erre a visszatekintés, mit csináltunk jól, mit rosszul, min és hogyan változtassunk. Viszont nem kell feltétlenül rendszeressé tenni, hanem csak akkor gyűljünk, ha már például összejött annyi megbeszélnivaló, probléma, amit már és még hatékony és gyorsan le tudunk kezelni. Egy 5-8 fős csoport esetében talán a 3-4 elég is lesz. Ha van egy Scrum vagy Kanban tábla használatban (akár elektronyos, akár fizikai formában), akkor elég egy kis sarkot/sort erre kijelölni, ahova mindenki felírja, ha talál valami dolgot, amit szerinte meg kellene beszélni. Ha összegyűlik három, irány a meeting room. Lehet, hogy ez csak három hónap alatt valósul meg, bár erre, valljuk meg, kevés az esély, még nagyon jól működő és kifinomult csoport esetében is (van egyáltalán ilyen?). Sokkal valószínűbb, hogy egyszer 1 hét, másszor 3 hét alatt lesz meg a szükséges mennyiség. Vagy 1 nap. Na és? A lényeg, hogy kezeljük a helyzetet, viszont fölösleges ne meetingeljünk.
Természetesen a három probléma mellé fel lehet vésni azt is, hogy mi működik jól. Hogy hízzon a májunk egy kicsit. A dícséret mindig jól jön és szinkronban tudunk bólogatni, hogy frankók vagyunk, de nagyon. Viszont az akciót sose felejtsük el. Osszuk ki, kinek mit kell csinálni és csináljunk cetliket az inbox vagy to-do oszlopba, bármi is a neve.
Retrózni kell, de csináljuk úgy, hogy ne az elv legyen a fontos, hanem az eredmény!

2011. december 1., csütörtök

Indulás - csak semmi planning!

Elég sokat keresgéltem a neten cikkeket, leírásokat, blogokat a szoftverfejlesztés, azon belül is a munkaszervezési módszerek világából, különös tekintettel a legújabb (de már így is több éves) trendekre, azaz az Agile-ra, a Scrum-ra, a Kanban-ra és végül, de egyáltalán nem utolsósorban a LEAN-re. Angol nyelven viszonylag sok van, ha kitartó az ember és van elég ideje (és miért ne lenne, például munkaidőben?), akkor találhat dögivel. 
Ha azonban magyar szóra szomjazik az egyszeri szoftverfejlesztő, akkor már sokkal, de sokkal nehezebb dolga van. Persze, olvashat a Wikipedián vagy találhat még 1-2 leírást itt-ott, de friss bejegyzések szinte sehol nincsenek, mintha senki nem követné nyomon a "szakma" változásait (javíts ki, ha tévedek!). Márpedig az egyik alapelv ebben a nem fantasy világban a folyamatos fejlődés, amit angolul a "continuous improvement" néven szokták emlegetni, míg japánul a kaizen a megfelelője. Ezen a ponton megkérdezhetnéd, hogy miért pont japánul említem ezt, miért nem mondjuk szuahéliül?
A válasz egyszerű. Azért, mert ez az egész Lean "okoskodás" a Toyota autógyáraiban indult el. Igen, ott, ahol nagy darab vasakkal, motorblokkokkal meg csavarkulcsokkal rohangáltak az emberek és még véletlenül sem öltönyben, laptoppal, okostelefonnal és fontoskodó arckifejezéssel, mint manapság a tipikus Manager az IT iparban. Hát szóval messziről indult és szerencsére már elég messze is jutott.
Visszatérve a kaizen-re, azaz a folyamatos fejlődés fogalmára, ami az úgynevezett Lean ház egyik alappillére (a másik maga az ember), azt gondolná a kockafejű kódtologató ülőmunkás, hogy józan paraszti ésszel is arra törekedik (törekszik?) mindenki, minden egyedi példány és minden csoport, hogy mindig előrébb lépjen. De sajnos ki kell ábrándítsalak, ez nem így van. Pláne nem csoport szinten és pláne nem akkor, ha egy vállalati környezetben a szerepek már kialakultak és minél feljebb tekintesz, annál jobban ragaszkodik az épp ott ülő a kialakult viselkedési normákhoz (tisztelet a kivételnek). Azaz, alapból mindenki elutasítja a változást, mert az ugye sokkhatással jár, még ha az kicsike is. Nem jó, pfúj. Ilyen az emberi természet. És ez az, amin kicsit változtatni kellene...a Lean talán segíthet ebben. A japánoknak mindenesetre segített, ugyanis a Toyota világelső lett az autóeladásokat tekintve - hát akkor nekünk miért ne? Állítólag még rokonok is vagyunk valamilyen szinten...
Ennyi bevezető után rátérnék a blog céljaira. Nem az, hogy definiáljam a fogalmakat, mi mit jelent, mi mivel hogyan függ össze. Ezeket megkeresheted a neten. Nem is az, hogy megmondjam, mit hogyan kell csinálnod, hogy jobb minőségű szoftver(rom)halmazt állíts elő sokkal rövidebb idő alatt. Mindössze a lehetőségeket szeretném bemutatni, merre megy a világ, mik az aktuális trendek, hova lehet fejlődni - mert azt bizony mindig kell. Fejlődni, tanulni, okosodni és merni változtatni!
Elsőként itt egy nagyszerű cikk az agilis szoftverfejlesztés jövőjéről. Meg jelenéről. Nem teljesen pozitív a vélemény, de ilyenek is kellenek. Azaz néha fel kell emelnünk a fejünket, hogy messzebbre lássunk...valaki azt mondaná, h húzzuk ki végre a s...ünkből. Hehe. Attól még hogy agilisek vagyunk, lehet ennél jobb is odakinn. Vagy odaát.
Remélem, sikerül felkelteni a nagyérdemű figyelmét!