MÓDSZERTANOK A HATÉKONYSÁG ELLEN METHOLODY VS EFFECTIVENESS Nyitrai Attila YGOMI Europe Kft (ROC Development) Összefoglaló A debreceni székhelyű ROC Development Kft, ami a YGOMI Europe Kft részeként működik, mint a McDonald s cég első számú távoli rendelésfelvételt megvalósító komplex informatikai megoldásszállítója, három éve alakult, és két éve sikeresen alkalmazza a SCRUM fejlesztési módszertant, ebben az előadásban rá akarok világítani egy kicsit a műhelytitokra, bár az elsődleges cél egy általánosabb kép kialakítása volt. A SCRUM tud sikeres lenni, ha azt jól átgondoltan, esetleg az igényekhez igazítottan használják, veszik át. Az előadás címe a Módszertanok a hatékonyság ellen is arra akar utalni, hogy sok olyan fejlesztő cég működik, ahol egy-egy módszertan sokban tudja hátráltatni a tényleges munkát, és sokszor a fejlesztők úgy érzik, hogy a felesleges adminisztráció viszi el az idő nagy részét. Az én meglátásom az, hogy ha a fejlesztők így érzik, akkor ez így is van. Ezen tudni kell változtatni, hatékonyabbá tenni egy módszertant, de ahhoz az kell, hogy ki is legyen próbálva, és rá legyen világítva az egyes gyengeségeire, ami még a legjobban megkomponált, és tapasztalati tényeke alapuló technikáknál is előfordul, hiszen minden cég más, minden termék egyedi(nek kellene lennie) Kulcsszavak Fejlesztési módszertan, SCRUM Abstract The ROC Development is seated at Debrecen and works as a branch of the YGOMI Europe Kft. as the first service provider of McDonald s remote order taking solution. ROC Development was formed 3 years ago and has been using SCRUM methodology for 2 years now. However the original plan was to form a general picture, in the lecture I am highlighting workshop secrets as well. Used wisely and adjusted to the needs, SCRUM can be a success. The title of the lecture is Methodologies Against Efficiency (Módszertanok a hatékonyság ellen) refers to those development companies, where different methodologies can serious drawbacks on work efficiency and where developers feel that administration takes most of the time. My view is that if many developers see it this way, they must be right. Companies must be ready for a change and to enhance the methodology they are using but this requires testing the methodology, finding the weak spots of the methodology, what is quite common even in case of experience based methods as all companies are different and all products are (should be) unique. Keywords Methodology of IT development, SCRUM 1
1. SCRUM módszertanról pár szóban - bevezetés 1.1. Történet A Scrum egy projektmenedzsment módszertan, az agilis szoftver fejlesztés egyik eszköze. Bár a scrum eredetileg szoftverfejlesztési projektek menedzselésére készült, szoftverkarbantartásra is használják. Ellentétben a hagyományos, prediktív, tervezős módszerrel a scrum egyik alapelve az, hogy a megrendelő a fejlesztés során meggondolhatja magát azzal kapcsolatban, hogy mit akar. A scrum nem törekszik a probléma teljes megértésére és definiálására, hanem arra törekszik, hogy a csapat gyors legyen és reagáljon a változó követelményekre. 1.2. SCRUM az YGOMI ROC-nál A YGOMI ROC-nál 2005-től kezdve kezdtük el használni és hasznosítani a módszertant, ha nem is egészében véve, pontról pontra az ajánláshoz tartva magunkat, de a sarokköveket kötelező érvénnyel betartva. Mivel Ken Schwaker-rel a SCRUM egyik atyjával az amerikai központunkban dolgozók közül többeknek is szerencséjük volt előzőleg együtt dolgozni, az elkötelezettség már korábban is megvolt. 2. Dedikált személyek 2.1. Product owner - az ügyfél A fejlesztés szempontjából tekinthető kívülállónak, bár tőle jönnek a többé-kevésbé megfogalmazott igények elsősorban. Majd egy üzleti elemzést követően pontosítja a képet, de akkor már a fejlesztő csapat dedikált személyével együtt. 2.2. Scrum master - az irányító A scrum master sokszor egy már létező csapat vezetője (team leader) vagy egy nagyobb szervezeti egység irányítója (PM). Minden megb eszélésnek kell lennie egy irányítójának (moderátor), aki úgymond levezényli az adott témakörben összehívott meetinget. A scrum master főbb feladatai A csapat szakmai irányítása A csapat irányítása humán-erőforrás kezelés szerint Feladatok koordinálása o Irányadás o Code-review (átadható más senior státuszú csapattagnak is) Megbeszélések levezénylése o Felkészülés a megbeszélésre, témafelvetés o Dokumentálás 2.3. Scrum team - a megvalósítók Egy adott feladat végrehajtására mindig egy csapatot kell deklarálni, ahol jól k övethetőek a hatáskörök, jogok és kötelességek. A team a feladat kiszabása előtt véglegesedik, összetételét felső vezetők határozzák meg. 2
2.4. Mindenki más... Az iterációba szükség szerűen bekapcsolódnak olyan személyek, akik a csapat munkáját segítik, de nem tekinthetőek szorosan véve a csapat tagjainak. Ilyenek lehetnek például: Business analyst (üzleti elemző) Architect (tervező-mérnök) Project manager Technical writer (Műszaki Dokumentáció Készítő) IT director (műszaki igazgató) Tesztelők (software assurance és teszter team) Más csapatok tagjai Külső szakmai és üzleti tanácsadók 3. A SCRUM folyamatlépcsői 3.1. Üzleti igények Sokszor előfordul, hogy az ügyfél nem tudja (akarja) pontosan, lépésről-lépésre meghatározni azokat a sarokpontokat, amik támpontok lehetnek egy informatikai projectben. Természetesen alapvető elképzelése (vision) van a kész termékről, de elfogadható az az álláspont is, hogy ő nem kivitelező, ebben az esetben informatikai szakember, nem tudja, nem kell tudni lépésekre lebontani a teendőket. Ilyen kor lép be a képbe a fejlesztő cég (csapat) által kirendelt személy, az üzleti elemző, aki alapos górcső alá veszi a meglévő (átírandó) rendszert vagy interjúk során kialakítja az az elképzelést, ami pontosan le tudja fedni az új rendszer funkcionalitását. Ennek kimenete az úgynevezett "requirement document", azaz igénydokumentáció. Majd ezt követően a "detailed functional specification", ami már részletesen leírja, kifejti a születendő megoldáscsomag működését. 3.2. Rendszer igényei Miután képet kapott a fejlesztő csapat arról, hogy mi is lenne a feladat. Ismert a komplexitása, kapcsolatrendszere más rendszerekkel, elvárt funkciói, akkor meg kell határozni a következő tényezőket Infrastruktúra Szükséges idő (emberórában vagy embernapban) Szükséges fejlesztő cs apat o fejlesztők száma o csapatösszetétel (junior, developer, senior) 3.3. Tervezés Habár a fejlesztés a SCRUM-ban iteratív, ami magában foglalja, az egyes részekre való visszatérés lehetőségét is, a fejlesztés soha nem indulhat el szakmai tervezés nélkül. Ennek a folyamatnak a dedikált személyei: Team leader Mivel az ő feladata a team koordinálása, neki kell elsődlegesen magáénak érezni a feladatot, és minden lépésével tisztában lennie. Development project manager 3
Felsőbb irányítás valósítja meg a team szempontjából kapcsolattartó is az ügyféllel. Vertikális irányban nyújt segítséget, azaz a konkrét fejlesztésnél is jelen van. Architect A rendszer egészéről alkotott képpel rendelkező személy, ő dönti el, hogy az egyes fejlesztések beleillenek-e és ha igen, hogyan az egészbe. Horizontális rálátással rendelkezik, interfész definíciókkal, kapcsolatrendszer felépítésével, fejlesztési irányadásokkal segíti a team-et. Business analyst 3.4. Fejlesztés (kódolás, tesztelés) A fejlesztést a csapat (team) végzi, a team leader segítsé gével, aki opcionálisan végezhet fejlesztést is. Mivel a fejlesztés nem csak a kódolásból áll, szükség szerűen be kell vonni más részlegek team-jeit, elsősorban a SA (teszter) csapatra kell gondolni. Bár a tesztelés több fázisú developer teszt - a fejlesztő csapat tagja tesztelik SA teszt - informatikus szakemberek, de nem csapat tagok tesztelik preproduction teszt - a megrendelő (ügyfél) szakemberei tesztelik 3.5. Integráció Összetett rendszereknél fontos tényező a rendszer integráltsága. Nagyon fontos, hogy milyen verziójú komponensek, milyen más verziójúakkal tudnak, képesek együtt működni. Az ROC-nál a verziókövetés több lépcsőjét is elkülönítjük, úgymint developer verzió - legfrissebb, fejlesztés alatt álló, de nem publikus released verzió - tesztelésre kiadott verzió, de még házon belül marad sign-off verzió - tesztelők és felsőbb vezetők által szignózott publikus verzió in production verzió - az ügyfél tesztjén átesett, be élesített verzió 3.6. Telepítés A termék (fejlesztési) életútja végén mindig a telepítés áll. Az ügyfélnél lévő informatikai specialistákból álló csoport, az úgy ITOps (információtechnológiai operátorok csoportja) végzi a telepítést miden esetben. Persze ez "éles" rendszer telepítése (inicializálás vagy frissítés) már akkor jöhet szóba, ha az ún. preprod rendszeren ők azt kitesztelték. A tesztelési folyamat leírására, megkönnyítésére több dokumentum is a rendelkezésükre áll. Mindkettő a technical writer csapat által előállítva. user guide - felhasználói kézikönyv deployment guide - telepítési útmutató 4. A sprint mint a fejlesztési folyamat A sprint az a folyamat, amelyben egy termék vagy egy termék jól körülhatárolható részegysége elkészül vagy magasabb készültségi szintre ér, azaz eléri a megfelelő verziót. 4
4.1. Az iteráció mint alaptényező A sprint mint iterációs folyamat A fej lesztés iteratív folyamatként zajlik a ROC-n belül, ez annyit is tesz, hogy egy problémára való legjobb megoldást nem biztos, hogy az első fejlesztési folyamat végén (sprint) el tudják érni a csapattagok. Tehát lehetőség nyílik arra, hogy egy sprint végén levonva a tanulságokat, újra neki lehessen futni a probléma jobb, célszerűbb, lényegre törőbb megoldásának. Bár ez inkább rekurzió A megoldást szinte soha nem egy lépésben, azaz egy sprint alatt tudják elérni, hanem több sprint végeredménye egy jól működő termék. 4.2. A sprint ideális hossza A sprintnek mindig könnyen lefuthatónak kell lenni. Mivel az iterációk gyors egymásutánban következnek, nem célszerű egy sprintet egy hónapnál hosszabb időre tervezni. Bár a túl rövid sprintnek is megvan az a hátránya, hogy az elkészült termék nem tesz hozzá kellő mértékben az összképhez. Az egy hónapnyi átfutás pedig elégnek kell lennie ahhoz, hogy értékelhető és produktív legyen a termék. 4.3. Önmenedzselés vs feladatkiosztás Minden egyes feladatot a csapat tagjai kérik maguknak. Ugyanis az üzleti elemző által megfogalmazott product backlog item-eket a scrum master fejlesztési szempontból jól körülhatárolt sprint backlog item-ekké konvertálja. A sprint indulásakor ezeket a részfeladatokat kell majd kiosztani, de úgy, hogy csak akkor lehet rátaksálni valamit egy csapattagra, ha az a item előzőleg nem kelt el, azaz els ődlegesen mindenki magának választ feladatot. Természetesen a scrum master meghatározhatja azon csapattagok körét, akik bizonyos feladatokból nem választhatnak. Ergo kritikus feladatot ne kapjon már meg egy újon. 5
5. Megbeszélés típusok 5.1. Sprint tervezés A sprint tervezése egy úgynevezett sprint plannaing meetingen megy végebe, de ekkor már az üzleti elemzések lezajlottak, és a scum master által létrejönnek az egyes részfeladatok. Itt publikálódik a sprint célja, végtermékének (amennyire csak lehet) pontos meghatározása. Többször előfordul, hogy ezt a megbeszélést meg kell előznie egy másik, ezt előkészítő meetingnek, ahol a scrum master a product owner-rel egyeztet, ez a sprint pre-planning meeting. Szoftver háttér A sprint ledokumentálásához a Microsoft Team Fundation Server-ét használjuk, ami megenged saját lekérdezések definiálását is, de sok előre beépített riport, grafikon, ellenőrzési pont segíti a munkát. Moduláris szemlélet Minden esetben moduláris megközelítést alkalmazunk, még akkor is, ha ez nehéz vagy körülményes. A sprint jól meghatároz egy terméket, részterméket, modult. Ergo már a metodika is úgy kívánja meg, hogy egymással kommunikáló, de jól elkülöníthető részegységek alkossák a solution-t. A verziókról pár szóban Egy termék három fázison esik át a fejlesztési fázisban o release Ha egy csapat elvégezte a munkát, és a scrum master kiadás kész állapotúnak ítéli meg a terméket, akkor a csapat egy dedikált tagja release-t készít belőle. Ami annyit tesz, hogy installálható verziót készít el, és csatolja hozzá a fejlesztés alatt keletkezett ún. develop dokumentumokat, ezek többnyire folyamatábrák, funkcionális leírások. o SA sign-off A software assurance team felel azért, hogy a kiadot termék minőségét leellenőrizzék, az esetleges hibákat ledokumentálják, priorizálják, és egy bizonyos minőségi szint felé érve minősítsék kiadhatónak. Ez abban valósul meg, hogy az SA team által letesztelt, és jónak ítélt termék egy igazgatói aláírást (sign-off) kap, és így elhagyhatja a fejlesztői területet, kiküldhető az ügyfélhez. o in production Az ügyfél szükség és igény szerint még saját tesztelési metódusoknak is alávetheti a terméket, kipróbálhatja, funkcionális, integrációs és stressz tesztelésnek vetheti alá, bár ez megtörténik az SA által is. 5.2. Stand-up meeting Mikor már elindult a sprint, minden egyes munkanap kezdetén lennie kell egy ún. stand-up meetingnek. Ezt természetesen a scrum master vezeti, és nevéből adódóan nem lehet túl hosszú, hiszen elvileg le sem lehet ülni, mert az is csak a megbeszélés hosszát növeli. A stand-up meeting-nek több állandó eleme van 6
a csapattagok visszajeleznek az előző napi munkájukról, mit sikerült teljesíteni, mivel vannak elmaradva a csapattagok ismertetik, hogy aznapra milyen munkát terveztek (ebbe a scrum master csak akkor szól bele, ha valaki kifutott a munkából) az esetleges szűk keresztmetszetekről (előre nem látott nehézségekről) mindenkinek tájékoztatást kell adni a team számára (itt nagy szerepe van a scrum master-nek, mert az ő feladata ezeket megoldani szakmailag (kutatás) vagy erőforrás áthelyezéssel) 5.3. Sprint closing meeting A sprint ugyan rövid átfutású, és sokszor kézzelfogható végterméke van, de egy közös szemléletmód kialakítása céljából mindig javallott egy összegzést csinálni, erre hivatott ez a meeting. Sok más mellett a következő pontokra mindenképpen ki kell térni a sprint lezárásakor Előremutató megoldások ebben a sprintben Előre nem látott, de a továbbiakban kikerülhető buktatók Megfelelő hatékonyságú erőforrás elosztás Információáramlás megfelelő volta Esetleges szakmai képzések (belső/külső) Intersprint (sprintek közti) idő tervezése 6. Feladatok 6.1. Taskok, bugok, issue-k, A TFS több fajta feladattípust enged deklarálni, de ez a három mindenképpen kiemelendő. Task Tervezett feladat, ez már a sprint kezdetekor tudott Bug Az SA (vagy developer) által talált hiba, aminek a mértéke lehet több féle cosmetic, low, normal, high, critical, issue Az issue lényegében egy rendszerfüggetlen bug, ergo egy olyan hátráltató tényező, ami nem volt tervezett, de a csapatnak kell megoldani, ha időre akarják implementálni a feladatokat 6.2. Dokumentálás A dokumentálást a technical writer team csapathoz kapcsolt tagjai végzik. Ebben a fázisban több típusú dokumentumnak kell elkészülnie, hogy az SA által elfogadott minőségűnek lehessen minősíteni egy terméket Deployment guide Telepítési útmutató. Részletes, pontokba szedett leírás arról, hogyan lehet az adott terméket működésbe helyezni, illetve beintegrálni a már működő rendszerbe, vagy upgrade-elni egy előző verziót Operational manual 7
Működtetési kézikönyv. Hogyan, kiknek, mikor kell manuális interakciót folytatni a komponenssel mint adminisztratív személy (hálózati rendszergazda, DBA, technikai személyzet, stb...) User guide Felhasználói kézikönyv. Ez a dokumentáció szól a végfelhasználónak. 7. A sprint végterméke 7.1. Termék-e a termék? Ha erre egy szóval akarok válaszolni, akkor azt kell mondjam, hogy NEM. Mint az előzőekből kiderült a sprint végtermékeként előálló informatikai szoftver vagy szoftvercsomag, még nem biztos, hogy életképes önmagában, és be kell várnia más termékeket, amit esetleg más csapatok fejlesztenek, más határidőre. 7.2. Egymásra épülő sprintek A project managerek egyik fő feladata az, hogy az alájuk tartozó csapatok munkáját koordinálják. 8. Mikor érdemes sprintben fejleszteni, mikor nem? 8.1. Gyakorlati példa - YGOMI ROC Reporting team Az ROC kereten beleül működő reporting team nem fejleszt sprintekben. Ennek az az oka, hogy olyan mennyiségű ad-hoc jellegű riportra van még jelenleg is szükség a tengerentúli üzleti egységeknek, hogy itt maximum pár napos sprintekről beszélhetnénk, és annak tetemes részét csak a feladatok ledokumentálása venne el, s így bár tartanak stand-up meetingeket, és a feladataikat TFS-be rögzítik is, de nem futnak sprinteket. 9. Mit érdemes részben átvenni a SCRUMból, ha az egészet nem is? 9.1. Gyakorlati példa a ROC egészéről Az itt leírtak nem fedik le teljes egészében a SCRUM fejlesztési módszertant, ez "csak" az a vetülete, amit mi jónak láttunk átvenni. S bár maga a SCRUM jól körülhatárolt, pontosan definiált feladatokat, feladatköröket fogalmaz meg, mi megpróbáltunk a saját ritmusunknak, elgondolásainknak is teret engedni, és azokat a sarokköveket megtartani, amikről mi is úgy gondoljuk, hogy alapjában véve pozitív irányba befolyásolják a munkánk hatékonyságát. Van olyan csapat, aki nem fut sprintet soha, van olyan akiknek nincs project managere, van olyan, hogy bizonyos termékeknél nem ragaszkodunk a rögzített release folyamathoz. Mindez azt mutatja, hogy megpróbálunk rugalmasan alkalmazkodni a felmerülő igényekhez, hogy minél hatékonyabban oldjuk meg a feladatainkat, javítsuk a hibáinkat, és végső soron a hatékonyságunkat. 10. Összegzés A debreceni székhelyű ROC Development Kft, ami a YGOMI Europe Kft részeként működik, mint a McDonald's cég első számú távoli rendelésfelvételt megvalósító komplex informatikai megoldásszállítója, három éve alakult, és két éve sikeresen alkalmazza a 8
SCRUM fejlesztési módszertant, ebben az előadásban rá kívántam világítani egy kicsit a műhelytitokra, bár az elsődleges cél egy általánosabb kép kialakítása volt. A SCRUM tud sikeres lenni, ha azt jól átgondoltan, esetleg az igényekhez igazítottan használják, veszik át. Az előadás címe: Módszertanok a hatékonyság ellen végül is arra akar utalni, hogy sok olyan fejlesztő cég működik, ahol egy-egy módszertan sokban tudja hátráltatni a tényleges munkát, és sokszor a fejlesztők úgy érzik, hogy a felesleges adminisztráció viszi el az idő nagy részét. Az én meglátásom az, hogy ha a fejlesztők így érzik, akkor ez így is van. Ezen tudni kell változtatni, hatékonyabbá tenni egy módszertant, de ahhoz az kell, hogy ki is legyen próbálva, és rá legyen világítva az egyes gyengeségeire, ami még a legjobban megkomponált, és tapasztalati tényeke alapuló technikáknál is előfordul, hiszen minden cég más, minden termék egyedi(nek kellene lennie) Felhasznált irodalom [1] Mező Csaba - SCRUM interpretation in ROC (2008, belső dokumentum) [2] Szacsúri László - Csoportmunka- és feladatszervezési methodológiák (2007, DE) 9