Agilis szoftverfejlesztés

Elhúzódó projekt helyett gyors piacra lépés

Új termékek létrehozása és az ötletek gyors kipróbálása. Az üzleti potenciál kihasználása és a meglévő határok feszegetése. Az eredményekből való gyors tanulás. Néhány hangzatos hívószó, ám az e-kereskedelem egy olyan terület, ahol erre valóban mind szükség van, ha eredményesen szeretnénk innoválni. Ezért az OANDER-ben egy olyan közeget teremtettünk, ahol az ügyfeleinkkel valódi, egyenrangú együttműködésben alkotunk új dolgokat. Ebben az egyik legnagyobb segítőtársunk az a módszertan, amely ahogy az egész szoftver iparágat felforgatta, úgy nálunk is teljesen új fejezetet nyitott.

Milyen problémára válaszol az agilis szoftverfejlesztés?

A nagy volumenű fejlesztési projektek egyik csapdája, hogy mindent egy lépésben és egyszerre szeretnénk megvalósítani. A valóság ezzel szemben az, hogy a projekt kezdetén sosem látható előre tökéletesen az a műszaki tartalom, amire végül szükségünk lesz és a szállítandó szoftver követelményei menet közben változnak. A fejlesztés közben akár extrém mértékben is megváltozhat, hogy ténylegesen mire lehet szükség.

Aki részt vett már komplex IT projektben az bizonyosan tapasztalta már, hogy bármilyen alapos is a tervezési előkészítés, az eredetileg elképzelt és specifikált igényhez képest a végeredmény sokszor eltér, a megrendelő nem pont azt kapja, amire eredetileg szerződést kötött. Ennek az az oka, hogy az eredménytermékkel szemben támasztott követelmények menet közben természetszerűen változnak és a projekt már-már követhetetlenül sok változáson megy keresztül. Számos digitális szegmensben egy fél évvel ezelőtt készült üzleti specifikáció már elavultnak számít. Így fordulhat elő, hogy a fejlesztés kezdetekor szükségesnek ítélt és gondosan megtervezett funkciócsomag élesítéskor már nem helytálló. Ez gyakorta okoz konfliktust szállító és megrendelő között.

agilis
Egy komoly portálfejlesztés fél-egyéves időszakot is jelenthet. A kereskedelem pedig egy olyan kompetitív közeg, ahol lehetetlen egy ma megtervezett terméket 6-12 hónap múlva sikeresen piacra vezetni, ha ez idő alatt az egész piac megváltozik.

Gondolkozz nagyban, kezdd kicsiben és szállíts gyakran!

Az innováció és helyes termékfejlesztés egyetlen útja, ha teret engedünk a követelmények változásának. Olyan munkafolyamatra van szükség, ahol új funkciókat és követelményeket gyorsan hozzá lehet adni a fejlesztési tervünkhöz, másokat pedig gyorsan el lehet távolítani belőle. Ehhez első lépésben érdemes elfogadnunk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Miközben fejlesztjük a terméket, új ötletek merülnek fel, a konkurencia egy váratlan húzása átírja a terveinket vagy éppen változik a szabályozói környezet. A változás bekövetkezik, ha akarjuk, ha nem. 

Azért, hogy minderre reagálni tudjunk, az agilis szoftverfejlesztésben rövid iterációkon keresztül egy minél gyorsabb piaci bevezetést igyekszünk elérni (MVP – Minimum Viable Product). A rendszeres funkciófrissítések – a folyamatos szállításnak és a rövid termékfejlesztési ciklusoknak köszönhetően – pedig lehetővé teszik a korai tanulást és növelik a befektetés potenciális megtérülését. Vagyis az agilis szoftverfejlesztés során a minél hamarabbi piacra lépésén dolgozunk, majd a terméket gyors release ciklusokban fejlesztjük tovább a valós felhasználói visszajelzések alapján.

Az agilis módszertannal minimalizáljuk annak a lehetőségét, hogy olyan, eredetileg fontosnak vélt fejlesztéseket csináljunk, amikről – mire sorra kerülnek – kiderül, hogy valójában annyira nem is fontosak és helyettük akár teljesen új igényeket is kiszolgáljunk, amikre a projekt kezdetén nem is gondoltunk. A projekt üzleti követelményeit definiáljuk ugyan, ám a pontos műszaki tartalmat menet közben, közösen alakítjuk ki.

agilis fejlesztés

Build, measure, learn

Az agilis szoftverfejlesztés szemlélete az, hogy nem a tökéletes megoldást keressük és fejlesztjük nagyon hosszú időn keresztül, hanem mindig az eggyel jobb változatot adjuk ki a szoftverből, amelyet aztán minél gyorsabban eljuttatunk a felhasználónak. Ezáltal hamarabb kapunk visszajelzést az felhasználótól, hogy az adott szolgáltatást szereti-e használni, jó-e neki, vagy sem. Így ha kell, tudunk rajta változtatni, méghozzá elég gyorsan. Az agilis szoftvfejlesztés tehát a build-measure-learn folyamatot követi.

agilis megoldások

Pontosabb kép arról, hogy mit célszerű fejleszteni

Különböző kutatások 20-40% közé teszik a webes portálok azon funkcióhalmazát, amit a felhasználók ténylegesen használnak. Ha minden ma elképzelt műszaki követelményt egy lépésben lefejlesztünk, akkor a pénzünk 60%-át kidobtuk. Ne készítsünk olyan megoldásokat, funkciókat amelyekre nincs bizonyított felhasználói igény! Teszteljük az ötleteinket kicsiben, adjunk ki minél gyakrabban önmagukban is értéket jelentő funkciókat, és akkor invesztáljunk beléjük komolyabban, ha már bizonyítottak!

agility

Azonnal használható terméknövekmények

Agilis szoftverfejlesztés mellett nem kell előre sokrétű üzleti funkcionalitást és azok egymásra gyakorolt hatását átgondolni, ami amúgy sok idő, illetve drága dolog. Azt a legfontosabb üzleti inkrementumot keressük, ami az elkövetkező hetekben a legfontosabb számunkra és a felhasználóinknak. Ez nem jelenti azt, hogy ne gondolkoznánk hosszú távon. Csak miközben tervezünk, szállítunk is. Azokat az igényeket, amik éppen nincsenek fejlesztés alatt, lehetőségünk van addig kitalálni, és priorizálni, amíg az előző igényeket már szállítjuk.

agilitás

Gyors reagálás a változásokra

A gyakori szállítás eredményeképpen ha valamilyen üzleti igény vagy prioritás megváltozik, gyorsabban tudunk reagálni rá és a változás tényleg gyorsan el is jut a felhasználóig. 2 hetes sprintekben dolgozunk, amelyek meghatározzák, hogy milyen fejlesztéseket készítünk el az adott két hét alatt. Azt, hogy a munka mivel folytatódjon, a kétheti sprintfordulón döntjük el a megrendelővel közösen. Így a product owner kézben tartja az irányítást, és ha változnak a prioritások, a tervező csapat munkája gyorsan tud azokhoz igazodni. Ez a kompetitív e-kereskedelemben azért fontos, mert az igények és prioritások ténylegesen gyakran és kiszámíthatatlanul változnak.

agilis

Komplex projektből átlátható fejlesztési folyamat

Hogyan lehet egyszerűen megoldani komplexnek tűnő problémákat? Úgy, hogy a munkát kisebb, könnyen belátható és gyakran átadható részekre bontjuk és az előrehaladást folyamatosan transzparensen tartjuk. A fejlesztési ciklusok (sprintek) végén demó tartunk, amelyek valójában ellenőrzési pontok. Az egyes sprintekben ténylegesen felhasználható terméknövekményeket állítunk elő, a gyakori demók által pedig a megrendelő gyakran visszajelzést tud adni, hogy tényleg az az elképzelése valósul meg, amit szeretne. Ráadásul a sprintről sprintre való tervezés révén a tesztelés, kipróbálás is könnyebb, amelybe felhasználók is bevonhatók. A projekt mindettől sokkal könnyebben menedzselhetővé válik.

agilis webfejlesztés

Transzparencia és közvetlen munkakapcsolat

Az agilis módszertanban dolgozó kivitelező csapatainkkal nem egy elszigetelt ügynökségként vagyunk jelen a megrendelő projektjében, hanem folyamatos iteráció mellett tényleges részeseivé válunk. A projekt ideje alatt közvetlen megrendelői munkakapcsolat alakul ki az elemzőkkel, UX tervezőkkel, designerekkel és fejlesztőkkel. Ezzel minimalizáljuk a kommunikációs asszimetriát. A szoros együttműködés nemcsak abban segít, hogy éppen mindig azon dolgozzunk, ami a termék vagy üzlet szempontjából aktuálisan a leginkább hasznos, hanem  inspirálja is a csapatot, mivel minden egyes apró feladat egy újabb sikerélményt eredményez.

oander munkák

Mi kell ahhoz, hogy az agilitás előnyeit ki tudjuk használni?

bizalom

Bizalom

Mi akkor vagyunk sikeresek, ha a webáruházad és kereskedelmi tevékenységed is az. Nekünk semmilyen motivációnk nincs Téged nem sikeressé tenni, hiszen a mi cégünkre ez minden szempontból hátrányosan hatna. Üzleti sikered a mi sikerünk is, ezért az élesítés után is megadunk minden támogatást, szakmai tudást ahhoz, hogy egyre jobb és jobb legyél. Folyamatosan optimalizálunk, innoválunk, hogy együtt fejlődjünk.

Felhatalmazás

A szállítás és az értékteremtés akkor tud gyors és hatékony lenni, ha a döntéshozatal is az. Minimalizáljuk a döntésben szereplő szinteket és bízzunk meg az egyes szereplőkben, hogy megmutathassák, ugyanazon közös célért dolgoznak és képesek rá. Ehhez szükség van a Te oldaladon egy PO-ra (product owner), aki egyrészt rendelkezik a döntési képességgel és felhatalmazással, másrészt ebből a felhatalmazásból felénk is át tud adni egy adagot.

transzparencia

Transzparencia

Tegyük az információkat, döntéseket átláthatóvá, így minden szereplő informált tud lenni, ha szükséges, tud inputot adni a döntéshez vagy akár beavatkozni. Ehhez az kell, hogy légy jelen a szállításban. Gyere el sprintfordulóra, vegyél részt minél több ceremónián, nézd meg mit és hogyan csináltunk meg, adj visszajelzést és hagyd hogy mi is feedback-et adjunk neked! Akkor működik ez jól, ha te a mi csapatunk részévé válsz és mi a tiédé.

SCRUM módszertan a gyakorlatban - Agilitás szótár

Sprint

A SCRUM-ban a gyors és iteratív átadási ciklusok eszköze a sprintekre bontott fejlesztés. A sprint rövid, jellemzően 2 hetes fejlesztési ciklusokat takar. A sprint egy, a fejlesztő csapattal közösen végzett tervezéssel kezdődik, ahol átbeszéljük és priorizáljuk a soron következő eredménytermékeket. A sprint demózással ér véget, ahol a megrendelő megtekinti és használatba veszi a leszállított fejlesztéseket. Így a tesztelés nem a projekt végén történik, hanem tulajdonképpen folyamatosan. Fontos szabály, hogy a sprinteknek mindig önmagukban is teljes értékű terméknövekményt kell leszállítaniuk. A sprint eredményeit a megrendelőnek azonnal használatba kell tudni vennie. Vagyis ha a sprintben a feladatunk például egy hitelkalkulátor fejlesztése, akkor azt a sprint végére kompletten le kell szállítanunk, minden komponensével együtt letesztelve, demózásra kész állapotban. Másik fontos szabály, hogy az éppen futó sprinten menet közben nem változtatunk. Egy agilis release ciklus gyors, ám ehhez az kell, hogy a fejlesztő csapat azon zavartalanul tudjon dolgozni. A folyamatban levő sprint egy olyan időszak, ami alatt nem módosulhatnak a célkitűzések, a fejlesztők védettek a külső behatásoktól, így eredményesebbek.

Sprintforduló

A sprintek kulcsfontosságú momentuma a sprintforduló, amely scrum master szervezésével zajlik. Ezen az eseményen a megrendelő Product Owner-e személyesen is találkozik a fejlesztő csapattal, így közösen tudják értékelni a projekt előrehaladását. A sprintfordulón történik az előző sprint eredményeinek bemutatása, amelyet maguk a fejlesztők demóznak a megrendelőnek, tehát nem egy projektvezető ismerteti az elkészült fejlesztéseket, hanem közvetlenül azok, akik alkották azokat. Ugyancsak a sprintforduló az az esemény, ahol eldöntésre kerül, hogy a következő 2 hétben min dolgozzunk. A sprintforduló egy nagyon fontos esemény az agilis szoftverfejlesztésben, hiszen sokkal egyszerűbb csak a soron következő sprint funkciókészletét jól megtervezni mint a teljes projektet annak indulásakor. Megrendelőként pedig sokkal könnyebb az előző sprintben leszállított terméknövekményt átvenni, megismerni és használatba venni, mintha a teljes projektet egy az egyben, egészben “zúdítaná ránk” a fejlesztőcég tesztelésre. A rendszeres személyes találkozó az egész csapattal továbbá segít megteremteni a projekt transzparenciáját és kiépíteni a felek közötti bizalmat. Ennek a ceremóniája a sprintforduló.

Backlog

A backlog a projekt elvárt eredménytermékeinek lelke, tulajdonképpen egy üzletileg priorizált igénylista, amely tartalmazza a user story-kat. A jövőbeli elvégzendő igényeket tároljuk benne, annak érdekében, hogy a termék versenyképes maradjon és folyamatosan fejlődni tudjon. A backlogban szereplő elemek változó kidolgozattságban vannak. Itt gyülekeznek azok a feladatok, amelyek már szállításra elő vannak készítve, megtalálhatók benne a tervezés vagy kidolgozás alatt álló fejlesztési teendők, de megjelennek benne azok az igények is, amik még csak ötlet szintjén merültek fel. A backlogban jelöljük azt is, hogy mely feladatra milyen előbecsléseink vannak, illetve, hogy az adott feladat sprint ready-e, azaz kezdhető állapotban van-e. Vagyis a backlog ad egy átfogó képet arról, hogy aktuálisan min dolgozunk, min tervezünk dolgozni a következő sprintben és milyen további igények vannak az előkészítés különböző stádiumaiban. A backlog természetéből adódóan folyamatos változásban van. Mindig kerül be új elem, más pedig kikerül belőle vagy hátrébb sorolódik. Tehát folyamatosan változnak a prioritások. Tartalmáról, prioritásairól a Product Owner dönt. A backlog azon elemei, amelyek kezdhető állapotban vannak és a legmagasabb prioritást élvezik a product owner döntése alapján kerülnek be a következő sprintbe.

User Story

A SCRUM-ban a leszállítandó fejlesztéseket mindig igyekszünk a végfelhasználó szemével megfogalmazni, amit User Story-k formájában készítünk el. Ezek hétköznapi nyelvezettel megfogalmazott követelmények a szállítandó termékkel kapcsolatban, amely teljes mértékben érthető olyan személyeknek is, akik nem jártasak az adott szakterületen. Így biztosítható, hogy a megrendelő is tökéletesen ugyanazt értse a szállított terméknövekmény kapcsán, mint a fejlesztők, továbbá ennek révén a fejlesztő csapat is könnyebben megérti az igény “miértjét”. A szállítás során az elfogadott user story-t már a fejlesztő csapat forgatja át konkrét fejlesztési feladatok formájába. A user story akkor teljes, ha sikerkritériumok is tartoznak hozzá. A sikerkritériumok olyan feltételek halmaza, amelyek megerősítik, hogy ha egy User Story elkészült, ezek alapján egyértelműen eldönthető, hogy sikeres-e az implementáció. A példa kedvéért nézzük egy taxi rendelő applikáció User Story-ját: Utasként szeretném, hogy az úticél kiválasztását követően különböző elérhető sofőrök legyenek megjelenítve a képernyőn, azért hogy ki tudjam választani a számomra legmegfelelőbb lehetőséget. Sikerkritériumok:
  • az applikáció mutatja azokat a sofőröket, akik online voltak az elmúlt 20 percben, és nincsen éppen folyamatban lévő szállításuk
  • az applikáció csak 5 sofőrt mutat, akik a legközelebb vannak a felhasználóhoz
  • a felhasználó minden sofőrnek a profilját meg tudja tekinteni, hogy milyen értékeléseket kaptak, képpel ellátva
  • az egyes sofőröknél kijelzésre kerül a felhasználóhoz való megérkezés várható ideje
 

Story Point

Szorosan kapcsolódik a User Story-hoz. Az egyes fejlesztési feladatok nemcsak előbecsléssel (óraszám előrejelzéssel) rendelkeznek, hanem mindegyik, a backlog-ban szereplő feladat kap egy-egy SP-t is. A Story Point egy a SCRUM által használt mérőszám, ami az órabecslést egészíti ki. Ez az érték egy komplexitási szintet jelöl, amely azt határozza meg, hogy mennyire összetett fejlesztésről beszélünk. Egy indiktátor arra vonatkozóan, hogy mekkora a valószínűsége a becsült óraszám tartásának, illetve hogy a jövőben - ha a fejlesztés nem kezdődik el a becslés készítésekor, de közben a rendszer a modulra potenciálisan kiható egyéb további fejlesztésekkel bővül - milyen valószínűséggel igényel újrabecslést. Minél komplexebb egy feladat, annál magasabb az SP értéke, és minél jobban kidolgozott egy igény a becslés pillanatában, az pedig éppen fordítva hat rá, lefelé mozgatja az SP értéket.

Refinement

A legfontosabb dolog, ami befolyásolja a módszertan sikerességét az igény maga, ami minden szállított érték minőségének alapja. Ha az nem megfelelő minőségű, ha nincs ott időben, ha nincs priorizálva, ha nincs alaposan megértve, ha nincs a sikeresség egyértelműen és mindenki számára érthetően definiálva, akkor ez már a kiindulási ponttól kezdve kihat a végeredményre és annak minőségére. Tehát a legfontosabb, amellyel szabályozni lehet az agilis szoftverfejlesztésben zajló munka minőségét, az az igényeket priorizáltan tartalmazó backlog minősége. Ezért miközben a csapat fejleszti az éppen futó sprint feladatait, a Product Owner és az őt támogató tanácsadói stáb a következő sprintek user story-jain dolgozik. Bizony sokszor előfordul, hogy egy-egy igény megfogalmazásában, a mikéntjének kitalálásában a fejlesztőkre is szükség van, valamint ahhoz, hogy dönteni lehessen a prioritásokról, ismerni kell az egyes feladatok várható bekerülési költségét. Továbbá egy specifikáció attól lesz jó, ha azt a csapattal még a munka elkezdése előtt átbeszéljük, közösen megértjük, minél kisebb darabokra szedtük és mindenki ugyanazt érti alatta. Ezen információk megszerzésére és az igény pontos átbeszélésére szolgál a refinement, amelyen a PO és a fejlesztő csapat közösen egyeztetnek az igényekről. Tehát ez egy közös találkozó a csapattal, ahol a következő sprintekbe szánt feladatokról zajlik egyeztetés, és amelyet követően a Product Owner - a kapott visszajelzések alapján - frissíti a backlog elemeket és aktualizálja azok prioritását.

MVP

Minimum Viable Product, azaz egy működő prototípus. Az agilis szoftverfejlesztés célja a minél korábbi piacra lépés egy lecsupaszított, de stabilan működő termékkel, hogy korán elkezdjünk valós felhasználói visszajelzéseket gyűjteni, illetve a termék minél korábban elkezdjen pénzt termelni. Az agilis fejlesztésben ennek a prototípusnak a továbbfejlesztése zajlik az ügyfél által kijelölt és a valós felhasználók visszajelzései alapján, ezzel biztosítva, hogy a műszaki tartalom a ténylegesen üzletileg hasznos irányba haladjon egy kezdetben elképzelt, de nem validált terv szolgaszerű követése helyett.

Keresztfunkcionális csapat

A SCRUM-ot alkalmazó fejlesztőcégeknél, így az OANDER-nél is keresztfunkcionális (cross-functional) csapatok dolgoznak a projekteken. Ez azt jelenti, hogy nincsen külön backend divízió, külön sitebuild team, külön rendszerintegrációs gárda vagy éppen tesztelői team, hanem csapaton belül elérhető az összes kompetencia és szerepkör, amely a sikeres szállításhoz szükséges. A csapat tagja a projektvezető is és a scrum master is. Vagyis a megrendelő egy olyan csapattal dolgozik együtt, amely összeszokott és komplett szállítási szaktudást alkot. Ezek a teamek önszerveződők, vagyis ők osztják be, hogy a sprintben elvállat fejlesztéseket miként és milyen sorrendben valósítják meg és az elkészült terméknövekményeket ők maguk demózzák a sprintfordulón a megrendelőnek.

Product Owner

A sikeres fejlesztés fontos feltétele, hogy a megrendelő bevonjon a projektbe egy olyan Product Owner-t, aki a fejlesztési stratégia prioritásai mentén haladva, technikai rálátással menedzseli a teljesítéseket és veszi át azokat. A megrendelő oldali Product Owner együtt dolgozik a tervező és fejlesztő csapattal, dönt az egyes sprintek tartalmáról és kezeli a backlog-ot. Legfontosabb feladatai:
  • Felelős a projekt üzleti sikeréért
  • Képviseli a projektet a stakeholderek felé
  • Kezeli és priorizálja a backlogot üzleti érték alapján
  • Dönt arról, hogy mi lesz leszállítva
  • Megfogalmazza az igényeket és a sikerkritériumokat
  • Dönt arról, hogy a demón látott fejlesztés élesbe mehet-e
Nemcsak az agilis módszertanban, de minden szoftverfejlesztési kezdeményezésnél égetően fontos, hogy megrendelő oldalon jelen legyen egy olyan projektvezető, aki döntési kompetenciával rendelkezik, aki képviseli a projektet a stakeholderek felé, felelősen megfogalmazza az igényeket és akinél összegyűlnek a projekttel kapcsolatos információk. Ennek hiánya a projekt törvényszerű kudarcát eredményezi. A SCRUM ezt a szerepet hívja Product Owner-nek.

Scrum Master

A SCRUM működtetése nem egyszerű feladat, egy olajozottan működő csapat és egy közös értésen alapuló munkafolyamat szükséges hozzá. Ebben segít a Scrum Master, aki felel a fejlesztési szabályok és folyamatok betartatásáért és biztosítja azt, hogy a csapattagok emlékezzenek a játékszabályokra, vállalásokra, ígéretekre. Elhárítja az akadályokat, zavaró tényezőket és azt segíti elő, hogy a csapat hatékonyan dolgozzon. A Scrum Master erősíti a projekt szervezet tagjai közötti kapcsolatot, kommunikációt, ugyanakkor coach szerepe is van: mentorál és segít a konfliktusok megoldásában. Nem utolsó sorban pedig ő facilitálja a scrum ceremóniákat (mint például a sprintforduló, refinement, standup, stb.)