Scrum: a csapatmorál és az ügyfél-elégedettség növelője

Az agilis szoftverfejlesztési módszerek használata, és a folyamatos visszacsatolás az ügyféltől elkerülhetetlen ahhoz, hogy sikeresen záruljon egy programozási megbízás.

Az agilis szoftverfejlesztési módszerek használata, és a folyamatos visszacsatolás az ügyféltől elkerülhetetlen ahhoz, hogy sikeresen záruljon egy programozási megbízás. A Scrum keretrendszer, amit kifejezetten komplex problémák megoldására találtak ki, pont ezeken az elveken alapul, így hatékonyabbá válhat a használatával a fejlesztési folyamat. A Sigma Technology Kft. az elmúlt években nagyobb ügyfél-elégedettségre tett szert a Scrum módszer alkalmazásának köszönhetően úgy, hogy közben még az ott dolgozó fejlesztői csapatok morálját is emelték. Erről beszélgettünk Tóth Árpád Product Ownerrel, aki elmesélte, hogyan használják a mindennapokban ezt a megközelítést a lehető legmagasabb hatékonyság elérése érdekében.

Hogy működik a Scrum?

A Scrum módszertan lényege, hogy a Product Owner, azaz a termék koordinátora folyamatosan kapcsolatban van az ügyféllel, akivel a meetingek során megbeszélik a termékhez fűzött elvárásokat és az irányvonalakat. Majd ezeket a Product Owner a megrendelő elképzeléseinek megfelelően olyan apró részekre bontja, melyek önállóan is értéket képviselnek, és megválaszolják a fejlesztők által feltett „Mit kell fejleszteni?” kérdést. Ezeket nevezik User Story-nak. Majd második lépésben a fejlesztő csapat ezeket a story-kat még tovább osztja olyan egységekre, amik a „Hogyan valósítsuk ezt meg?” kérdésre adnak választ. Ezt pedig Technikai Task-nak hívják. Ezután ezeket a feladatokat önszervező módon kiosztják egymás között a csapat tagjai az úgynevezett grooming session-ök során. Ez a meeting továbbá arra is szolgál, hogy a fejlesztői csapat feltegye a felmerülő kérdéseit a user storykkal, vagy a termékkel kapcsolatban a Product Ownernek, hogy még jobban képbe kerüljenek az elképzelésekkel. A grooming session további elemei közé tartozik az egyes feladatokhoz tartozó becslések elkészítése is, ami alapján a fejlesztő csapat meg tudja tervezni az egyes iterációkba, azaz sprintekbe bekerülő feladatok mennyiségét. Az ilyen keresztfunkcionális fejlesztői csapatok lényege az, hogy nincsenek előre leosztott szerepek, mint például architect, tesztelő, fejlesztő stb., illetve hierarchia sincsen a csapattagok között.

Hogyan zajlik a fejlesztés folyamata?

A csapat fejlesztési ciklusokban, a már korábban is említett iterációkban, vagy másnéven sprintekben dolgozik, ez a Sigmánál két hetet ölel fel. A sprintek hossza cégenként változó lehet, de egy projekten belül mindig ugyanazt az időintervallumot kell használniuk. Ezeknek a célja 1-1 működő termékfunkció elkészítése. Iterációkba osztják a már lebontott, és a Product Owner által priorizált Technikai Task-okat, és a backlog tetejéről indulva döntik el, hogy pontosan hány elemet fognak beletenni az adott ciklusba. A sprintek során folyamatosan ürítik a termék backlog-ját, ami az elkészítésre váró feladatokat tartalmazza, addig, amíg a projekt teljes egészében el nem készül. Mivel magának a fejlesztésnek a “hogyanja” nincsen meghatározva, csak a cél van kiszabva, a fejlesztők kreativitása is jobban szárnyra kaphat. Több esélyük van megismerkedni új megoldásokkal és kamatoztatni tudásukat. Így a dolgozók elégedettsége, és megítélése is nő a munkáltatóról és a pozíciójukról.

Aki elhárítja az akadályokat: a Scrum Master

A keresztfunkcionális csapat jobb keze, vagy a „kiszolgálója” a Scrum Master, aki az agilis folyamatok koordinálásáért felelős. Nincsen menedzsment hatásköre, az ő feladata 1) elhárítani a csapat haladásának útjában álló akadályokat, illetve 2) megszervezni a Scrum ceremóniákat, mint például a Sprint Review vagy a Daily Standup – amiről lentebb lesz szó részletesen – és támogatni azok problémamentes lefolyását. Ezeken felül a Scrum Master felelős a 3) sprintek megtervezéséért is. A Sigma csapatának egy része. Készítette: Kovács Tamás A haladás ellenőrzése érdekében a Scrum módszer tartalmazza az elkerülhetetlen daily standup-ot, ami egy napi rendszerességgel történő meeting, ahol minden csapattag a következő kérdésekre válaszol:

• Min dolgoztam tegnap?
• Min fogok ma dolgozni?
• Van-e olyan akadály, ami miatt nem tudok haladni?

Ami nélkülözhetetlenné teszi a daily standup-okat, az az, hogy ezeken a megbeszéléseken a csapattagok beszámolója alapján kiderül, hogy hogyan haladnak a feladatokkal, továbbá megegyeznek, hogy az adott napon hogyan haladjanak tovább. Ez a 15 perces rövid megbeszélés mindig ugyanazon a helyen és ugyanabban az időben zajlik, ezzel is csökkentve a komplexitást. Ezeken felül a Scrum keretrendszerben helyet kap a Sprint Review meeting is, ahol a csapat bemutatja a Product Ownernek, stakeholdereknek, vagy akár közvetlenül a megrendelőnek a már elkészült szoftvert, vagy annak egy funkcióját. Ezen a meetingen az is kiderül, ha rossz irányba indult volna el a fejlesztés, és valamin változtatni kell.  Ebben az esetben még időben kiszúrhatják a hibákat, és minimális energia-, és költségveszteséggel folytathatják tovább a procedúrát a megfelelő technológiák használatával. Az itt kapott visszajelzéseket a Product Owner beépíti a termék backlogjába, így alakítva sprintről-sprintre a terméket. A Scrum Master másik nagy felelőssége az, hogy megszervezzen minden egyes sprint végén egy retrospektív meetinget, ahol a csapat a saját folyamataira reflektál. Ellenőrzik, hogyan tudtak együttműködni, mik voltak a jó megközelítések, és milyen folyamatokra kell a következő sprint alkalmával más megoldást találniuk. A Scrum Masternek elő kell segítenie a kommunikációt, és felszínre kell hoznia a lappangó, feszültséget okozó tényezőket, és problémákat.

A Product Owner egyenlő lenne a Project Managerrel?

A Product Manager és a Product Owner közötti legnagyobb különbség, ami a Scrum módszer egyik alapelve is, hogy a PO-nak egyáltalán nincsen menedzsment hatásköre. Nem a csapatot menedzseli, hanem a terméket, viszont azért kizárólag ő a felelős, hogy a termék fejlesztésének a backlogjába hozzáadjon, vagy módosítson elemeket, illetve az, hogy az egyes elemek sorrendjét módosítsa. Ennek ellenére azt már nem ő dönti el, hogy az egyes iterációkba mely elemek kerülnek bele, tehát például nem kardoskodhat a fejlesztő csapattal, hogy többet készítsenek el az adott időszak alatt, mint amennyit ők terveznek. Ezen felül a Product Ownernek nem kell rendelkeznie mély technológiai ismeretekkel, viszont egy jól definiált és részletes vízióval annál inkább. Megfelelő határozottság, kommunikációs készségek és kezdeményező képesség segítségével kisebb, tördelt, de önállóan is értéket képviselő darabokban kell átadni ezt a víziót a keresztfunkcionális csapatnak úgy, hogy ők is teljeskörűen átláthassak az ügyféligényeket, és tervezett funkcionalitásokat. A másik nagy különbség a Project Manager és a Product Owner között az, hogy a PO heti többször személyesen is találkozik a megrendelővel, és együtt beszélik meg a fejlesztés alakulását, illetve az esetlegesen újonnan felmerülő kérések betervezését. A Product  Owner sokkal ügyfélcentrikusabb, mint a PM, hiszen ő a megkerülhetetlen kapocs a két fél között.

Összefoglalás

Mindent összevetve, a Scrum célja az ügyfél elégedettségének növelése, a hibák detektálása már egy korai fázisban, és azok javítása a termék minőségének folyamatos növelése érdekében.  A Scrum nagy előnye az, hogy nagyon kis idő telik el a fejlesztés és aközött, hogy az ügyfél egy kézzelfogható dolgot kap. Így folyamatos a visszacsatolás és mindig az aktuális piaci- és ügyféligényeknek megfelelően halad a fejlesztés. A Scrum módszerrel megnő a kommunikáció mennyisége és minősége a megrendelő és a kivitelező cég között, így kevesebb a félreértés, és a nem megfelelően elkészített funkció. Ezáltal az esetleges változásokra sokkal gyorsabban lehet reagálni a fejlesztés során. A Scrum nemcsak a fejlesztő cég külső kapcsolatait képes javítani, de a csapatmorált is emeli azáltal, hogy nincsenek kőbe vésett fejlesztői pozíciók, és előre megírt folyamatok, hanem minden csapattag saját tudása szerint vállalhat feladatokat az egyes iterációban, sőt, még egymás segítésére is sokkal alkalmasabb megoldás a daily standupok miatt, mint egy hierarchikus rendszer. Amennyiben szeretnél hasonló tartalmakat olvasni, kövess minket a Facebook vagy LinkedIN oldalunkon is!