Scrum tapasztalatok III.

Az első 2 részben megpróbáltam összefoglalni, hogy hogyan zajlik egy scrum alapú fejlesztés. És most jöjjön az, hogy szerintem megérte-e azon a projekten vagy sem.
Azt szokták mondani, hogy folyamat alapú fejlesztéseknél nem nagyon érdemes scrum-ot használni, elég tiszta hogy honnan hova, mikor milyen állapotba jutunk, előre tervezhető az egész.
Az is szempont, hogy scrum-ot akkor érdemes használni, ha az ügyfél nem tudja még pontosan hogy mit is akar. Apró részleteket mindig kap, és mindig tovább tudja gondolni, hogy neki hogy lenne jó.

Toyota


A Toyota módszerrel szokták ezt összefüggésbe hozni, állítólag abból alakult ki a scrum módszertana. Ez arról szól, hogy mindig CSAK annyit kell lefejleszteni, amire az adott sprintben szükség van. A Toyota is így dolgozott, mindig pont annyi motorháztetőt-egyéb alkatrészeket gyártott, amennyire szükség volt az adott periódusban, nem végeztek olyan munkát, ami "felesleges".
Mi is ezt csináltuk, funkció alapon mindig csak annyit, amennyi kellett. Nagyjából sejtettük, hogy kell majd pl. helyettesítéssel vagy audit loggal foglalkozni, de nem kezdtünk el tervezgetni előre. Amikor adott sprintben szükség volt rá, elővettük a feladatot.
A fejlesztés közepe felé amikor olvasgattam hogy nagyjából mi van még hátra, azt gondoltam, hogy pedig mindenre jó lett volna előre gondolni, pl előre megtervezni, hogy a helyettesítést hogyan fogjuk kezelni, az audit logot milyen módon mentjük, hogy fogjuk majd visszaküldeni a folyamatot már teljesített állapotba stb. Azt gondoltam, hogy ezzel majd komoly mennyiségű vért fogunk izzadni, hogy összeálljon, mert annyi minden van már benne és akkora a kód, hogy nehéz lesz. Aztán meglepődve tapasztaltam, hogy amikor nekiálltunk egy olyan feladatnak, ami nagynak tűnik, a kódot/rendszert már jól ismerve pikk-pakk össze tudtuk rakni. Mindenki tudta hogy hova kell nyúlni, kialakult egy rutin, ismertük azokat a pontokat ahova az adott kódot be kell helyezni, új interface-t felvenni, kiegészíteni, db modellt befrissíteni, szóval gyorsan ment.
Ehhez az kellett, hogy úgy legyen kialakítva az architektúra, hogy könnyen lehessen bepakolgatni az egyes elemeket, és minden fejlesztő ismerje az aljától a tetejéig az egészet. Ez fontos, hogy vertikálisan lehessen kiosztani/végezni a feladatokat, nem várhatnak egymásra a fejlesztők. Aki pedig nem látja át összefüggésében az egészet, nem tudja mit hova tegyen, vagy akár csak egy LINQ-t nem tud megírni normálisan, nem nagyon fér bele a csapatba, hacsak nem mutat nagy-nagy hajlandóságot (és persze képességet) arra, hogy gyorsan beletanuljon.
Persze azért néha akadt olyan, amit tapasztalattal az ember előre meglát, hogy ezt vagy azt meg kellene csinálni, mert majd a lekérdezésekben segíteni fog. Pl denormalizálni itt-ott, felvenni olyan mezőket, property-ket, ami ugyan duplikál egy adatot, de egyszerűbb karban tartani a duplikációt mint lekérdezéseknél szopni vele.

Következtetések

Összességében a mai napig nem tudom eldönteni, hogy gyorsabban végeztünk-e, mint ha nem Scrum-al állunk neki. Ezt ugye akkor lehetne összehasonlítani, ha egy ugyanolyan kvalitású másik csapat ugyanazt párhuzamosan csinálta volna, de ez lehetetlen. Mindenesetre annyi biztos, hogy az ügyfél elégedett, a rendszer működik, és könnyen karban tartható, bővíthető. Anélkül, hogy 2 hónap elment volna tervezéssel, amikor az ügyfél nem lát ugye semmit, max ábrákat, dobozokat vonalakkal. Ebből meg sokat nem ért, max bután néz és vagy elhiszi hogy jó lesz, és jó irányba halad a dolog, vagy nem.
Talán egy picit úgy érzem, hogy igen, praktikusabb volt az egészét tekintve, még ennek a folyamat alapú és nagyrészt előre specifikált rendszernek az esetében is. Egy "átlagos" fejlesztés során pedig még hasznosabb. És hülyén hangzik, de tényleg pontosan tartani kell a scrum szabályokat, mert akkor van értelme ha mindenki komolyan veszi.
Mindezek ellenére nagyobb projekteken, ahol bazi nagy komplexitású és tudású rendszert kell tervezni (mint pl egy egészségügyi ERP), nem biztos hogy ezt választanám. De ezt a több scrum tapasztalattal  rendelkezők biztosan jobban tudják.

Lényeg: lehet hogy drága tapasztalt scrum tanácsadókat megbízni, de én úgy láttam hogy bejött, az oktatásuk és a bevezetésük is. És utána néhány sprint zárón-nyitón részt vettek még, hogy kicsit terelgessenek, megválaszoljanak felmerülő kérdéseket.
Amit még tudok, az EPAM-nál most kb 600 fejlesztő dolgozik, és náluk CSAK SCRUM alapon megy minden projekt. Kicsitől  nagyig. Kivétel nélkül.