Scrum tapasztalatok IV.

Ügyfél

Ő az, aki fizet. De mit, ha scrum alapú a fejlesztés? Óradíjat, vagy fix project költséget? Ha nincs tisztázva előre a scope, akkor mire fizet fix project költséget? Hol a határ, meddig mehet el?

Ezek mind nagyon nehezen megválaszolható kérdések. Csak olyan ügyfélnél működik, akit régóta ismerünk, és megbízik a fejlesztő cégben/fejlesztő csapatban. Vagy olyanban, aki tisztában van vele, hogy mi az a scrum. Ha nincs tisztában vele, akkor meg lehet próbálni elmagyarázni, leoktatni róla, és meggyőzni, hogy neki miért jó. A mi esetünkben az volt, hogy ismerte az ügyfél a fejlesztő céget, és hajlandóságot mutattak a scrum elv megértésére/elfogadására. Nem mellesleg a tender/projekt kiírásban olyan milestone-ok szerepeltek, amit 2 hónapos tervezéssel nem lehetett volna tartani (2 hónap alatt egy kattintható, működő valamit akartak látni).
Megint csak nagyon jól jött, hogy az ügyfél összeírta pontosan az igényeit. Ez egy kicsit megint sántít, hiszen a scrum arról szól hogy csak adott periódusokra előre nézünk. A teljes scope-ot nem ismerjük. Ha ez nincs, akkor nem lehetett volna projekt alapon csinálni.
A product owner volt az, aki a koncepció tervtől eltérő, új igényeket kezelte, és adott esetben eldöntötte, hogy mi az ami belefér, és miből lesz CR. Ezt persze a scrum masterrel megbeszélte, hogy mi mennyi plusz munka, mekkora szívás.

Szóval ez egy olyan scrum alapú projekt volt, ahol a koncepció és a scope látszott az elején, így mehetett projekt alapon. Óradíjas alapon pedig olyan ügyfelet kell szerezni, akivel tényleg el tudjuk hitetni, hogy neki ez jó. Ez meg az ügyfélmenedzser vagy sales-es dolga, hogy jól meg tudja indokolni.
Erről az árnyoldalról itt egy cikk, ahol pont ezzel a kérdéskörrel foglalkoznak. Érdemes megnézni a hozzászólásokat is, és a hozzászólásokban belinkelt cikkeket, pdf-eket.

Most hogy megint elolvastam, már megint nem tudom eldönteni hogy mennyire jó vagy nem jó :)

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.

Scrum tapasztalatok I.

Legutóbbi projektemen volt szerencsém egy kicsit közelebbről megismerni, hogy milyen is a scrum módszertan.

Fél éve már írtam róla ebben a postban, itt van 2 link ami összefoglalja hogy mi is ez, ad egy képet róla. A projekt amiben részt vettem, egy kísérleti nyúl volt, első valódi Scrum projekt (nem csak nekem, hanem a cégnek). Mellesleg a fent linkelt cikkekben az interjú azzal a manussal készült, aki a csapatot felkészítette úgymond a scrum módszertanra. Nem reklám, inkább info, hogy a Sprint Consulting volt aki ezt a tanácsadó szerepet betöltötte.

Megpróbálom összefoglalni a tapasztalataimat, így 3 hónap távlatából. Kezdem ott, hogy én úgy indultam neki, végre egy scrum project, eddig mindig csak olvastam, meg hallottam róla. És persze volt már hogy scrum-nak hívtunk valamit, de nem nagyon volt az. Szóval kíváncsian vártam, hogy mi lesz ez. Meg kellett ismerkednem a metodikával, az eszközökkel. A ScrumDo egy kifejezetten erre a célra készült, ingyen is használható (korlátozásokkal) projekt menedzsment site (olyasmi mint pl a JIRA). Nem tudom miért ő lett, de a célnak megfelel, valószínűleg a tanácsadó ezt ajánlotta. Az első pár napban kezdett kikerekedni, hogy jé, tényleg van product owner, van scrum master, van minden nap 10-kor standup, van eszközünk amiben vezetjük hogy mit csinálunk. Jó volt a benyomás, hogy komolyan vette mindenki, és mindenkinek tetszett.

Harmadik napomon már egy sprint záró meetingen is részt vettem, ahol nem sokat tudtam hozzátenni, mert nem ismertem a fogalmakat sem.

Nah, ezen a megbeszélésen kezdtem egy kicsit szkeptikus lenni. Oké, hogy jó ha mindenki rálát kicsit a projektre, milyen taskok vannak meg ilyesmi, de hogy egy egész délután (5 óra) 6 fejlesztő üljön és meetingeljen, nem tartottam túl hatékonynak. Azért ez mégiscsak 30 munkaóra... És 2 hetes sprintek vannak, vagyis 2hetente 30 munkaóra elmegy sprintzáró-nyitó meetingre.

Kicsit meginogtam. Nem akarok sokmindent egy postba zsúfolni, következőben néhány fogalom is lesz, hogy lehessen érteni miről írok, és tudjuk hova tenni, mi is az a sprint záró.

A Scrum módszerről

Találtam egy egész jó, tömör, 2 részes összefoglalót arról, hogy mi is az a scrum. Sok helyen csak scrum-nak neveznek valamit. Pl ha naponta egy közös beszélgetés van, néha már azt is.

Íme a 2 link:
"Megértik és átélik a munkájukat" - a Scrum módszerről (1. rész)

"Nagy lépés, ha egy cég rájön arra, hogy problémái vannak" - A Scrum módszerről (2. rész)

Némi kiegészítés, hogy mire jó még figyelni, ami a cikkben nincsen benne