Hogyan dolgozunk?

Hatékonyság és minőség mindenek felett.

Mi így alkotunk

  • Gyors release ciklusokban hiszünk, így könnyen reagálhatunk bármilyen változásra.

  • Láthatóság és átláthatóság. Hogy mindig helyes döntések születhessenek a projektek során.

  • A kockázatok csökkentése növeli a hatékonyságot. Mindenki számára így a jó.

  • Alkalmazkodunk, a visszajelzések alapján is gondolkodunk. Így lehet egy termék sikeres.

    SCRUM.

    Hogy miért? Olvass tovább és megérted.

    SCRUM

    A Scrum egy egyszerű, empirizmuson alapuló keretrendszer, amelyet az 1990-es évek eleje óta alkalmaznak komplex termékek fejlesztésére. A keretrendszer olyan eszköztárat kínál, amely használatával a lehető legmagasabb értéket képviselő termék készíthető és az erőforrások kihasználása optimalizálható.

    Alapgondolata, hogy a követelmények teljes körű, előzetes feltárása helyett működő terméket kell a lehető leghamarabb készíteni és gyakori prototípuskészítéssel, felhasználói teszteléssel célszerű ellenőrizni, hogy az elvárások elérik az kívánt üzleti értéket.

    Az alapgondolat helyességét kutatások és case study-k igazolják:

    A Missouri Egyetem kutatása kimutatta, hogy 2012-ben egy átlagos üzleti környezetben a ma érvényes követelmények fele 6 hónap alatt elavult. Ez azt jelenti, hogy egy 6 hónapos projekt végén átadott funkciók fele már nem szolgálja a Megrendelő céljait.

    Olyan vállalatok választották a Scrum-ot, mint a Google, Yahoo, Microsoft, KPMG vagy a Bank of America. Bár -nem meglepően- az IT szektorban a legelterjedtebb az alkalmazása, egyre növekszik a népszerűsége azon kívül is.

    A Scrum keretrendszer a Scrum team-ből, hozzájuk rendelt szerepekből, eseményekből, munkaanyagokból és alapelvekből/szabályokból áll.

    A következő fejezetekben a keretrendszer elemeire építve mutatjuk be a tervezett projekt főbb jellemzőit.

    Alapelvek, szabályok

    A Scrum szabályai kapcsolják össze az eseményeket, szerepköröket és a munkaanyagokat, meghatározva a köztük lévő viszonyokat és kölcsönhatásokat. A Scrum Team-ek saját szabályaikat, az alkalmazott munkaanyagokat és eszközöket a Scrum alapelveivel, értékeivel összhangban alakítják ki.

     

    • Érték alapú priorizálás (Product Backlog)
    • Együttműködés (Scrum Team-en belül és a stakeholder-ekkel)
    • Önszerveződés
    • Empirikus folyamatellenőrzés (felülvizsgálat a retrospective eseményeken, cél felé haladás (vízió, sprint cél) folyamatos ellenőrzése)
    • Iteratív fejlesztés (minden sprintben potenciálisan kibocsátható terméknövekmény)
    • Időkeret (time-boxed események)

    Érték.

    A Scrum keretrendszer segítségével a tisztán funkcionális követelmények szállítása helyett a Product Owner által meghatározott üzleti értékkel bíró követelményeket szállítunk, melyek megvalósítását a Fejlesztő csapat tervezi meg és hajtja végre.

    A Product Owner és a Fejlesztő csapat közötti hatékony és közvetlen kommunikáció nagyban hozzájárul ahhoz, hogy magas technológiai színvonalú és kiemelkedő minőségű megoldások készüljenek.

    A terméktervezés a működő szoftverre építve történik

    A projektjeink során – amennyire csak lehet - arra törekszünk, hogy minden, a projekthez egyedileg kialakított szállítási folyamatnak megfelelően, a szoftver élesíthetőségéhez szükséges tevékenységet a sprint folyamán végezzünk el. Ehhez kapcsolódóan javasoljuk a tartalom feltöltési feladatokat is folyamatos tevékenységként a sprintek tartalmához igazítva szervezni annak érdekében, hogy ezen feladatok ne torlódjanak fel, és ne késleltessék a termék élesítését.

    Az alkalmazott megoldások eredményeként elérhető reális cél, hogy a Product Owner egy ötletet akár egy sprint elteltével a kész termékben láthasson, és a termékkel kapcsolatos döntéseit nem egy dokumentációban vizionált terv alapján hozza, hanem már működő szoftvert látva, arra építve.

    Az üzleti terület a hozzá tartozó portál felületeket késlekedés nélkül megkaphatja üzleti validációra, így ellenőrizhető és biztosítható a számukra ideális megoldás szállítása a végleges termékben akár több visszajelzési kör alapján is.

    Az agilis projektek egyik legnagyobb előnye, hogy a folyamatosan szállított terméknövekmények által minden sprint végén potenciálisan élesíthető állapot érhető el.
     

    Gyors alkalmazkodás

    A visszajelzések rendszeres feldolgozása és a sprintenkénti tervezés lehetőséget ad a Product Owner-nek, hogy mindig az aktuális célokhoz és felhasználói elvárásokhoz igazítsa a követelményeket.

    Így biztosított, hogy a projekt végén leszállított termék olyan funkciókat tartalmaz, amelyet a végfelhasználók használni fognak és valós üzleti értéket képviselnek.

    A Scrum alkalmazásával jelentősen alacsonyabb a változtatások költsége, mint a hagyományos módszertanok esetén, ahol minden módosítás plusz költségként rakódik az eredetileg tervezett költségekre.


    Rugalmasság

    A hagyományos projektmenedzsment és fejlesztési módszertanok és az arra épülő szerződéses struktúrák esetén a módosítási igények kezelése nehézkes. A szállítók saját kockázatuk csökkentése érdekében a követelmény dokumentációkban rögzített igények megvalósításában érdekeltek, és gyakran a Megrendelő az üzleti területek között is konfliktus alakul ki a változtatási igények miatt.

    A Change Request-ek miatt a rendszer újratervezése és a projekt budget újragondolása is szükséges. Emellett a módosítási igények kihatással vannak a projekt határidőkre is.

    A Scrum-ban a projekt költségek és határidők rögzítettek, a scope-ot a Megrendelő folyamatosan finomhangolhatja. Az agilis Fejlesztői csapatok tisztában vannak azzal, hogy a követelmények teljes körű felmérése nem lehetséges, ezért elfogadják, hogy azok változhatnak.

    Így fix költséggel az előre megállapodott határidőre olyan funkciók készülnek, amelyek valóban értékesek a Megrendelő és a végfelhasználók számára.


    Magas minőség

    A Scrum-ban a minőség úgy határozható meg, mint annak képessége, hogy a termék vagy eredménytermékek megfelelnek a “Done” kritériumoknak és elérik azt az ügyfelek által elvárt üzleti értéket.

    • A „Done” kritériumokat és szükség esetén az együttműködési rendet a Scrum Team tagjai közösen alakítják ki és folyamatosan felülvizsgálják.
    • A magas minőség biztosításához elengedhetetlen a műszaki adósság csökkentése, megszüntetése. Ennek érdekében a forráskód minőségének ellenőrzését SonarQube forráskód-minőség ellenőrző és követő szoftverrel végezzük, és a manuális tesztelést selenium-os automatizált tesztekkel egészítjük ki.
    • Az elvárt üzleti érték vizsgálatánál a valós felhasználókon végzett tesztelések a leghatékonyabb megoldást kínálják.

    A tesztelés folyamatos tevékenységként jelenik meg, így a hibák nem a projekt végén derülnek ki

    A sprinten belül végzett manuális teszteket automatizált tesztmegoldásokkal egészítjük ki, ami lehetőséget ad, hogy rendszeresen átfogó tesztelés történjen a korábbi sprintekben átadott megoldásokra is. A stakeholder-ek aktív részvételével, gyakori (akár minden sprintet követő) felhasználói teszteléssel a hibás követelményelemzésből és tervezésből származó hibák korán felderíthetők és ezzel csökken a hibajavítás költsége.

    Aktuális igényeket és megoldásokat tartalmazó dokumentáció készül

    A user story készlet optimális szintjének fenntartásával a user story-k mindig aktuális elvárásokat tartalmaznak és a Fejlesztő csapat sebességéhez szükséges user story mennyiség is rendelkezésre áll.

    A rendszer dokumentációs eredménytermékei sprintenkénti frissítésével biztosítható a rendszerleírások és a termék összhangja.

    SCRUM projekt kivitelezése

    Pre-Sprint szakasz (Előkészítő szakasz)

    • A projekt kezdetekor a Product Owner a Termék vízióban rögzíti a projekt/termék célját és azokat a döntő információkat, amelyek a sikeres termék fejlesztéséhez szükségesek.
    • Majd a Product Roadmap-ben bemutatja, hogyan fejlődik a termék a tervezett kiadások (release-ek) során a vízióban felvázolt termékké: Lebontja az üzleti célokat és meghatározza azokat a képességeket (feature-ek) és elvárásokat, amelyeknek teljesülniük kell a célok eléréséhez.
    • A Pre-Sprint szakasz eredményterméke az induló Product Backlog.
      • A felhasználói igények és követelmények epic vagy user story formájában, a Product Backlogban kerülnek rögzítésre.
      • A Product Backlogba kerül minden olyan képesség, funkció, követelmény, továbbfejlesztések és javítások formájában megjelenő változtatás, amiket a termék jövőbeni kibocsátásaiban (release-eiben) el kell végezni.
      • A backlog elemeket a Product Owner sorba rendezi és besorolja a tervezett kiadásba.
      • A Product Backlog a projekt zárásáig folyamatosan változik.
    • Ahhoz, hogy megfelelő minőségű termék készüljön, az elvárásokat egyértelműen magában hordozó követelmények és a terméknövekményre vonatkozó, ellenőrizhető elvárások meghatározása szükséges. Ezt a cél szolgálják az ún. “Done” kritériumok (Definition Of Done).
      • A „Ready kritériumok(Definition Of Ready) jellemzően a backlog elemekkel szemben támasztott formai és tartalmi elvárásokat tartalmazzák. Betartásukkal biztosítható, hogy a megvalósító csapat jó minőségű követelményekhez tervezze és szállítsa a megoldást, így az elkészülő szoftver is pontosan szolgálja a célokat.
      • Az átgondolt „Done kritériumok” biztosítják, hogy minden elkészülő terméknövekmény megfeleljen a termék egészére vonatkozó elvárásoknak, így elkerülhetőek azok a helyzetek, amikor egy túl későn azonosított, a termék egészére vonatkozó követelményt a teljes projekten kell érvényesíteni magas költségszinten.

    Az előkészítő szakaszban megtörténik a Scrum Team felállítása és megkezdődnek a Fejlesztő csapat és a Product Owner közötti egyeztetések. A cél, hogy az előkészítő szakasz végére az első sprint indításához szükséges feltételek rendelkezésre álljanak, melyek:

    • Termék vízió elkészítése
    • Product roadmap elkészítése
    • Stakeholderek (internal és external) azonosítása
    • Induló termék backlog elkészítése (szereplők meghatározása, epicek rögzítése), storypont keret szétosztása epic vagy feature szinten
    • 3 sprintre elegendő sprint-ready user story elkészítése
    • KÉSZ (ready és done) kritériumok meghatározása
    • Scrum Team felállítása
    • Együttműködési terv kialakítása: a Scrum Team működésének legfontosabb alapelveit és szabályait összefoglaló terv/megállapodások gyűjteménye.
    • Hardver és szoftver Infrastruktúra

    Az előkészítő szakaszhoz rendelt feladatok elvégzését követően indítható az első sprint.

    Scrum ciklus

    • A Scrum ciklus az első sprint tervezéssel kezdődik.
      • A Sprint tervezés alkalmával a Product Owner és a Fejlesztő csapat együtt határozzák meg a sprint célját. A Fejlesztő csapat munkájának bemenetét a sprint-ready Product Backlog elemek adják. A Fejlesztő csapat minden a sprintbe tervezett user storyt story ponttal lát el és vállalást teszt a sprint scope-jára vonatkozóan (sprint backlog).
      • A sprint tervezés második felében a Fejlesztő csapat tervet dolgoz ki a sprint cél és a hatékony belső munkaszervezés megvalósítására vonatkozóan. Ahhoz, hogy minden sprint végén potenciálisan élesíthető terméknövekmény készüljön, minden a terméknövekményhez kapcsolódó feladatot sprinten belül végez el a csapat.
      • A tervezés eredményeképp a Fejlesztő csapat user storykat kisebb elemekre, subtaskokra bontja
    • A sprint ideje alatt minden nap a Daily Scrum alkalmával a Scrum Team összehangolja, egyezteti a megvalósításhoz, és a sprint céljának eléréshez szükséges tevékenységeket.
    • A megvalósítással párhuzamosan a Product Owner a következő sprintek user story-jain dolgozik. A Backlog Refinement (vagy Backlog Grooming) eseményeken a Product Owner és a Fejlesztő csapat egyeztetnek a Product Owner által megírt user story-król. A visszajelzések alapján a Product Owner frissíti a backlog elemeket és aktualizálja azok sorrendjét.
    • A sprint végén, a Sprint Review (vagy Sprint Demo) eseményen a Fejlesztő csapat az elkészült terméknövekményt bemutatja a Product Ownernek.
      • Amennyiben a terméknövekmény teljesíti az elfogadási kritériumokat és megfelel a „Done” kritériumoknak a Product Owner elfogadja az elkészült user story-kat.
      • Azok a user story-k, amik nem felelnek meg ezeknek a kritériumoknak visszakerülnek a Product Backlogba.
    • Minden sprint végén, a Sprint Retrospective eseményeken a Scrum Team megvizsgálja tevékenységét. A vizsgálat kiterjed az alkalmazott módszerekre, a csapattagok közötti együttműködésre és a készülő termék minőségére is. A csapatok minden feltárt eltérés esetén tervet készítenek a problémák megoldására, amelyeket folyamatosan ellenőriznek.
    • A sprintek javasolt hossza 1 hét, melyek kezdete és vége a hét azonos napjára esik a projekt során végig.

    Release és termék élesítés

    • A termék kiadása/élesítés a Product Roadmap-ben meghatározott időpontokban történik.
    • A kiadást részletes tervezés előzi meg, mely eredményeképp elkészül a release terv. A release tervezés segít, hogy a megrendelők felkészülhessenek a változásokra, megszervezhessék a szervezet alkalmazkodásához szükséges tevékenységeket (munkafolyamatok módosítása, oktatások).