03 óra

Agilis módszertanok

Az agilis fejlesztésről általában

Az agilis fejlesztési módszertanok olyan gyakorlatok, munkaszervezési módszerek, amelyek az agilis értékek mentén iterációkban zajlanak. Az egyes iterációk során mind a fejlesztés, mind a tesztelés megvalósul, ezek a tevékenységek párhuzamosan zajlanak. Az agilis módszertanok alkalmazásával a fejlesztők folyamatosan tartják a kapcsolatot a termék felhasználóival, ezért gyorsabban érkezik visszacsatolás a fejlesztett funkcionalitással kapcsolatban, valamint az ügyfelek által bejelentett változásokra is gyorsabban reagál a fejlesztői csapat. A legfontosabb agilis módszertanok közé tartozik a Scrum, az Extreme Programming (XP), a Crystal módszertan, a DSDM (Dynamic Software Development Method), az FDD (Feature Driven Development), a Kanban, és a Lean szoftverfejlesztés.

Miért van szükség az agilis módszertanokra?

Korábban az egész életünk működése lassabb, kiszámíthatóbb volt, és ez stabilabb elvárásokat, követelményeket eredményezett egy szoftverrel szemben. Volt idő átgondolni, tervezni, és a terveket követve fejleszteni. Ezek a korai fejlesztési módszerek (például a vízesés modell) a mérnöki szemléletet tükrözték. Manapság a követelmények gyorsan változnak, ugyanakkor a felhasználók is hamarabb szeretnének működő szoftverhez jutni tekintettel arra, hogy a kiélezett verseny erre kényszeríti őket. Ma már egy fejlesztésre sokszor fél év, vagy annál kevesebb idő áll rendelkezésre. Ha elfogadható minőségű terméket szeretnénk, akkor ahhoz erőforrásokat, és időt is kell rendelni, valamint a megfelelően részletezett specifikációt is a fejlesztők rendelkezésére kell bocsátani. Ha ezek a feltételek nincsenek meg, akkor annak következményeként komoly technikai adósságokkal kell szembesülnünk. A fenti problémák kezelésére a hagyományos fejlesztési módszertanok nem adnak kielégítő választ, ezért olyan fejlesztési módszerek kidolgozására volt szükség, amely képes az említett kihívásokat megfelelően kezelni.

Az agilitás alapelvei (bővebben http://agilemanifesto.org/):

• működő szoftver szállítása minél gyakrabban,
• a követelmények változtathatósága,
• fejlesztők és szakértők együttműködése,
• csapatközpontúság,
• motivált csapat,
• személyes kommunikáció,
• a csaptműködés fejlesztése,
• fenntartható fejlesztés,
• rendszeres tervezés és minőségi kód szállítása,
• egyszerűség.

Az agilis szó arra utal, hogy a fejlesztés változásbarát, azaz elfogadja, hogy a követelményekben változások lehetnek. Az üzleti szoftverek fejlesztésében ez a szempont alapvető, ugyanis például jogszabályváltozás miatt is gyakran változhatnak a követelmények. Az agilis módszertanok lényegében arra fókuszálnak, hogy a teljes fejlesztési folyamatot olyan kisebb egységekre bontsák fel, amelyek önmagukban már képesek az ügyfél számára értéket szállítani, ugyanakkor változás esetén a lehető legkevesebb munka vesszen kárba.

Annak ellenére, hogy az agilis módszertanok alkalmazása az üzleti fejlesztésben szinten egyeduralkodóvá vált, nem váltak semmissé a korábbi módszertanok sem. Vannak olyan fejlesztési projektek (jellemzően biztonságkritikus fejlesztések), ahol a bevált mérnöki szemléletet kell alkalmazni (pl. repülésirányítás).

A továbbiakban a két leggyakoribb módszertannal foglalkozunk, a Scrum és a Kanban agilis módszertanokkal.

Scrum

A Scrum olyan fejlesztési módszertan, amelyben a fejlesztési feladat egészét kis méretű fejlesztési feladatokra bontva, iteratív módon, csapatmunkában oldjuk meg, ahol az egyes iterációk által készült eredményekre érkezett visszajelzések előmozdítják mind a szoftver fejlesztését, mind a fejlesztési folyamat hatékonyságát.

Scrum csapat

Egy Scrum csapat az alábbi szerepköröket foglalja magában:

• Product Owner: Feladata a Product Backlog kezelése. Egyetlen személy, aki az ügyféloldali érdekeket képviseli. A gyakorlaton a gyakorlatvezető tölti be ezt a szerepkört.
• Fejlesztő csapat: Önszerveződő csapat, ahol minden tudás megvan a termék fejlesztéséhez. Jellemzően 4-8 főből áll.
• Scrum master: Olyan személy, aki a Scrum folyamat működéséért felelős. A fejlesztő csapatot vezényli, illetőleg segíti. Ő maga is tagja a fejlesztői csapatnak.

Backlog

Termék, illetőleg feladatlista, amely az aktuális feladatokat és azok prioritásait tartalmazza.

• Product Backlog: azon feladatok listája, amelyeket meg kell oldani ahhoz, hogy elkészüljön a rendszer. A gyakorlaton a Product Backlog a fejlesztési feladatokat tartalmazó, a GitLab felületén elhelyezett issue-k listája lesz.
• User story: olyan dokuementum, amely a felhasználó szempontjából fogalmazza meg a fejlesztendő funkcionalitással szemben elvárt követelményeket. Formális szerkezettel rendelkezik:
  • As a [end user role], I want [the desire] so that [the rationale].
  • A user storyból kiindulva a fejlesztési feladatokat task szintre bontjuk le.
  • Acceptance criteria: azok a feltételek (követelmények), amelyeket a fejlesztett funkcionalitásnak teljesítenie kell annak érdekében, hogy azt a Product Owner elfogadja és a fejlesztés eredményét átvegye. A user story-hoz kapcsolódik, de külön is megfogalmazható. Lényegében a követelmények listája.
• Prioritási sor: a Product Backlog prioritási sorrendet határoz meg, amelynek alapján a fontosabb, jobban kidolgozott feladatok előre kerülnek a sorban.
• Dinamikus tervezés: a feladatokat, azok lebontását megelőzpen pontosítani és priorizálni kell.
• Sprint backlog: ez a lista egy konkrét Sprint alatt végrehajtandó feladatokat tartalmazza. A lista a Sprint tervezés során jön létre. Tartalmát a Scrum csapat választja ki a Product Backlog tartalmából, ahol a prioritásokat és a várható ráfordítást (story point) is figyelembe veszik.

Backlog refinement

A grooming vagy backlog refinement a terméklista (Product Backlog) pontosítása, finomítása, illetőleg előkészítése a jövőbeli sprintekhez. A terméktulajdonos (Product Owner) és a csapat megvitatja, rangsorolja a backlog elemeket, biztosítva, hogy a következő sprintek számára megfelelően előkészített elemek álljanak rendelkezésre. A grooming során kerülnek egyeztetésre és pontosításra a user storyk, az elfogadási kritériumok, illetőleg kerülnek finomításra a user storynál nagyobb fejlesztési egységek, az epicek is.

Mik azok az epicek?

Gyakran előfordul az az eset, amikor a megrendelői igény komplexebb funkcionalitást tartalmaz, mint amelyet a user story segítségével le lehetne írni. Ilyen eset például egy számviteli beszámoló elkészítését támogató modulra megfogalmazott igény. Ebben az esetben a Product Owner a csapattal egyeztetve bontja le ezeket az epiceknek hívott egységeket user story-k halmazára. Az epicek felbontására a grooming folyamán kerül sor.

Használati esetek (use case) az agilis módszertanokban

Elsőre talán furcsának tűnhet a tananyagban az UML eszközök, különösen a használati esetek alkalmazása a funkcionalitás leírásában, mikor épp az imént került említésre egy másik, egyszerűbb eszköz, a user story. A valóság ezzel szemben az, hogy a két eszköznek teljesen más szerepe van. A user story egy funkcionalitást fogalmaz meg, amely a követelményeket is tartalmazza. A használati eset ezzel szemben a funkcionalitás konkrét működését mutatja be forgatókönyvek formájában. Míg a user story-ban tehát a mit várunk el kérdésre adunk választ, addig a használati eset azt mondja meg, hogy miként teljesítjük ezeket az elvárásokat a felhasználó felé.

Modellező eszközök az agilis fejlesztésben

Az agilis fejlesztés nem írja elő, hogy milyen eszközökkel modellezzük a problémát. Az agilis fejlesztés magának a változásbarát fejlesztési folyamatnak a támogatására szolgál, célja a fejlesztési feladat olyan granularitásának biztosítása, ami lehetővé teszi a fejlesztés alatt történő változások menedzselését. A modellezés során a fejlesztői csapat ismeretének és ízlésének megfelelően bármilyen eszköz alkalmazható.

Sprint

A Scrum iteratív a fejlesztésre épül. Ebben a módszertanban minden iterációnak konkrét időkeretet szabunk, amelyben az iteráció tervezése során kiválasztott jellemzők fejlesztése, tesztelése zajlik. Ennek az időintervallumhoz kötött iterációnak a neve Sprint. A Sprint végére kész és működő inkremens (a fejlesztendő szoftver egy jól meghatározott része) kell, hogy előálljon.

A Sprint jellemzői:

• Fix időtartam: min 2 hét, max 1 hónap
• Sprint tervezés:
  • a csapat tesz vállalást,
  • a Sprint cél általában a Product Backlog elemeiből tevődik össze,
  • a cél és a magas minőségi elvárás nem változhat.
  • Sztoripontokat kell megszavaznia a csapatnak minden egyes feladathoz. Ez egy relatív mérőszám, amely összefüggésben van azzal, hogy az adott feladat elvégzéséhez mekkora munkabefektetés szükséges. Nem a ráfordítandó időt méri, hanem egy relatív mérőszám, amelyet a legegyszerűbb feladathoz szükséges ráfordítás alapján becsülnek meg a csapattagok.
• Napi Scrum, vagy daily meeting:
  • max. 15 perc, a teljes csapat részt vesz benne, ahol áttekintik az elvégzett munkát, a további terveket és a felmerült problémákat.
  • A meeting eredményét érdemes memoban rögzíteni.
• Sprint áttekintés:
  • inkremens ellenőrzése, bemutatása a megrendelőnek. Az egyes inkrementumokat a Product Owner tételesen ellenőrzi, illetőleg fogadja el, vagy utasítja vissza.
• Sprint visszatekintés:
  • a csapat kiértékelése, fejlesztési lehetőségek keresése. Ez a csapat belső ügye, a Product Owner ezen a meetingen nem vesz részt.

Burndown chart

Hasznos diagram, amelynek a szerepe az, hogy tükröt tartson a csapat felé az aktuális teljesítményéről. A diagram azt mutatja, hogy a tervezetthez képes milyen gyorsan tudja a csapat a vállalt fejlesztési feladatait teljesíteni.

Kanban

A Kanban egy lean módszer, amelyenek célja az emberek csoportos munkájának hatékony menedzselése és fejlesztése. A Kanban az igények és a rendelkezésre álló kapacitás egyensúlyára épít, s úgy építi fel a munkafolyamatot, hogy az adott munka készültségi szintje folyamatosan látható legyen.

Mi a lean?

A lean jelentése az, hogy karcsú. Olyan menedzsment módszer, amely arra fókuszál, hogy egy vállalat minél gazdaságosabban állítsa elő a termékeit és szolgáltatásait. A lean középontjában az áll, hogy mely áruk és szolgáltatások, illetve azoknak mely jellemzői képeznek értéket a vevőnek. A vevők ebben az esetben lehetnek belső vevők, azaz a vállalat más osztályai, részlegei is.

A Kanban munkafolyamatok megjelenítésére a Kanban táblát használjuk. Ezek a táblák nemcsak a Kanban esetében, hanem más agilis módszertanoknál (pl. Scrum) is használhatók. A különbség a megjelenített tartalomban van, a Kanban mivel a kapacitást figyelembe veszi, kötelezően tartalmazza a WIP (Work In Progress) limiteket.

A Kanban jellemzői:

• Nagyon megengedő módszertan (nincsenek sprintek, napi stand up meetingek stb.)
• A Kanban szabályai:
  • Vizualizáld a workflow-t!
  • Korlátozd a párhuzamosan folyamatban lévő feladatok számát!
    • WIP (Work In Progress): minden munkafázishoz hozzárendeljük azt az értéket, hogy maximálisan mennyi task lehet az adott munkafázison belül (kivéve a backlog és az elkészült elemeket tartalmazó oszlopokat). Ha például a WIP értéke egy adott munkafázisban öt, akkor egyszerre csak öt task szerepelhet az adott munkafázist jelképező oszlopban, és mindaddig nem kezdhet bele új task feldolgozásába a csapat (az adott munkafázist érintően), amíg fel nem szabadul egy hely (vagyis amíg az adott fázist egy adott taskra vonatkozólag be nem fejezik).
  • Legyen minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban!
• Kockázatok és problémák:
  • Könnyen lehet Kanbannak látszó módszertant összerakni.
    • Csak szóban cél az agilitás, de a valódi változásra nincs hajlandóság, ezért eredményt ebben az esetben ez a módszer nem hoz.
  • A sikerhez hatalmas önfegyelemre van szükség.

Scrum vs. Kanban

A Scrum fix időtartamú Sprintekre bontott, egy Sprint tartalmában a Sprint időtartama alatt nem változik. A Sprint kezdetét követően a Product Ownernek nincs módja a Sprint munkájába beleszólni, kivéve a rendkívül sürgős eseteket. A Scrum időkeretével szemben a Kanban az egyszerre végezhető feladatok számát korlátozza. A Scrum definiál olyan szerepköröket, amelyek a Kanban-ban nem léteznek. A Kanban csak a fejlesztő csapat szerepkörét ismeri (illetőleg a Product Owner említhető, de ő nem része a csapatnak). A Scrum definiál továbbá kötelező tevékenységeket, mint például a napi meeting, vagy a Sprint tervezés, ilyen kötelezően végzendő tevékenység a Kanban keretrendszerben nincs. Az ismertetett technikai elemeket (burndown chart, Scrum/Kanban tábla, user story) mindkét módszerben használják.

Az, hogy melyik módszertan alkalmazható egy adott fejlesztési tevékenységhez, sok tényező befolyásolja. Egyrészt a Scrum megköveteli a napi szintű, preferáltan személyes találkozókat. A földrajzilag diverzifikált fejlesztések esetében így csak nagyon korlátozottan alkalmazható. Mindazonáltal, ha a megrendelő számára fontos a rendszeres kontroll, a prioritások dinamikus meghatározása, úgy a Kanban alkalmazása sem javasolt. A Kanban ugyanis csak a párhuzamosan végzendő feladatok számának korlátozását írja elő, ami a fejlesztői csapat kapacitásának egyensúlyban tartásához lett kitalálva, a megrendelő számára nem biztosít formális kontroll lehetőséget. A módszertan kiválasztásánál ezért rendkívül fontos a fejlesztői csapat, a megrendelői elvárások, és az adott feladat jellemzőinek együttes értékelése. A fentiek miatt sokszor nem is alkalmazzák tisztán egyik módszertant sem, hanem egy hibrid megoldás (Scrumban) kerül kidolgozásra, amely az adott fejlesztésre vonatkozó követelményeknek megfelelően vesz át módszertani elemeket a két ismertetett keretrendszer repertoárjából.

Feladatok lebontása, issuek kezelése

A fejlesztési projektünkhöz kapott issuek általában egy komplex feladatot tartalmaznak (epic szint), amelyek úgy lettek kidolgozva, hogy több hallgató összehangolt csapatmunkájára legyen szükség annak határidőre történő megoldásához.

Feladatok lebontása

A gyakorlatvezető által kiválasztott issue komplex, egyetlen user story-val általában nem írható le. Az így kapott issue-t tehát részekre kell bontani, user story-kat, valamint taskokat kell képezni belőlük. A lebontást addig kell elvégezni, amíg egy-egy részfeladat (user story, task) hozzárendelhetővé válik egy konkrét felelőshöz. Ezt a felelőst mindenképpen jelezni kell az adott alfeladatot tartalmazó issue-n. Az alfeladatokra bontás során specifikálni kell a konkrét feladatot, a felelőst, a határidőt, és folyamatosan követni kell a feladatok állapotát.

Issue, epic, user story, task?

Ne zavarjon meg senkit a terminológia. Az issue egy gyűjtőfogalom és tartalmazhat epic-et, user story-t és taskot is. Az issue egy fejlesztési feladat, nem veszi figyelembe a granularitást. Az epic/user story/task viszont olyan fogalmak, amelyek figyelembe veszik a feladat részletezettségét. A továbbiakban ha issue-ról beszélünk, akkor általában a fejlesztési feladatról szólunk, illetőleg az azt tartalmazó GitLab eszközről. Ha szükséges megadni azt is, hogy a feladat milyen szinten van részletezve, akkor az epic/story/task szavakat fogjuk használni.

Mérföldkövek

A nagyobb projekteket mérföldkövekre szokás osztani. A mérföldkövek olyan nagyobb egységek a projekten, amelyeknek előre meghatározott határidejük van, jól definiálható projekttermékek tartoznak hozzájuk, és jellemzően az ellenőrzés számára is tájékozódási pontot nyújtanak. Az ilyen mérföldkövekkel leírt projektek esetében minden issue egy konkrét mérföldkő része lesz.

Issuekezelés a GitLab felületén

Az issue projektekhez rendelt eszköz, amelyet ötletek megvitatására, problémák megoldására és a munka tervezésére használjuk. Az issuek segítségével követhető nyomon az egyes feladatok státusza, javaslatok elfogadása, kérdések, kérések fogadása, vagy implementációs részletek megvitatása.

A GitLab az issuek kezelését lista, vagy az issue board segítségével támogatja. Ez utóbbi használható a Scrum/Kanban táblák digitális formájaként is. A board testreszabható, minden projekten belül definiálni kell azokat az oszlopokat, amelyek az adott projekt szempontjából relevánsnak számítanak.

Az oszlopok testreszabásához először címkéket kell definiálni, amelyet a GitLab felületen a Project information->Labels menüpont segítségével tudunk elvégezni.

Egy új címke létrehozásához a NEW LABEL nyomógombon kell kattintani, majd a megjelenő dialógusban megadni a címke nevét, opcionálisan a leírását és egy alkalmas színkódot. Ezt követően a CREATE LABEL nyomógomb segítségével az új címke elkészül.

Az Issue board a Issues->Boards menüpontból aktiválható. A CREATE LIST nyomógomb segítségével az alkalmazás egy új oszlopot hoz létre, ahol a Select a label kombinált listából kiválaszthatjuk azt a címkét, amelynek megfelelő oszloppal bővíteni szeretnénk a boardot, majd az ADD TO BOARD nyomógombra kattintva az így létrehozott elemet a boardunkhoz tudjuk rendelni.

A boardon lévő oszlopok a drag and drop módszer segítségével tetszőlegesen rendezhetők, a jobb felső sarokban lévő 3 pont pedig lehetőséget add issue-k felvitelére, illetőleg az adott lista (oszlop) szerkesztésére.

Akár a boardon, akár az Issues->List menü útján, lehetőségünk van az issuek felvételére, keresésére és módosítására. A kereséshez a keresőmezőbe tudunk műveletek felvinni. Ha belekattintunk, akkor az alkalmazás felajánlja azokat a jellemzőket, amelyek értékei alapján a keresés megtörténik. Csak rá kell kattintani a kiválasztott jellemzőre, majd ezt követően a kapcsolódó műveletek közül választhatunk, amelyeket az alkalmazás automatikusan felkínál részünkre. A műveleteket követően pedig a jellemzőhöz rendelhető lehetséges értékeket is felkínálja részünkre a rendszer. A rendszer támogatja több szűrő megadását, azok egyszerű felsorolásával logikai ÉS kapcsolatot hozhatunk létre közöttük.

Szűrési példa: Assignee is Hallgató

A korábban említett címkék a keresésben is segítséget nyújtanak. A címkék nemcsak arra használhatók, hogy az issue board oszlopait meghatározzuk, hanem tetszőlegesen hozzárendelhetők az egyes issue-khoz, amely alapján kereséseket is tudunk végezni.

Az issue-k elemei

Az egyes issue-k az alábbi adatokat tartalmazzák:

• Felelősök (Assignees): Egy issue-nak több felelőse is lehet.
• Címkék (Labels): Több címke is hozzárendelhető egy adot issue-hoz.
• Mérföldkő (Milestone): A mérföldkövekkel a fejlesztési feladatot tudjuk felosztani kisebb egységekre. Használhatjuk a mérföldkő elemet például Sprintek definiálására. A mérföldköveket az Issues->Milestones menüpontban adminisztrálhatjuk, a NEW MILESTONE nyomógomb segítségével új mérföldkő hozható létre. A mérföldkő kötelező eleme annak címe, kezdeti, valamint záró dátuma. Opcionálisan, megadható egy leírás, amelyben részletezhetők a mérföldkőhöz tartozó fejlesztéseket érintő elvárások.
• Határidő (Due date): Az adott issue-hoz tartozó határidő. Ez a határidő minden esetben legyen korábbi, mint az issue-hoz rendelt mérföldkő záró dátuma.
• Idő követése (Time tracking): Amennyiben követjük az issue-hoz kapcsolódó munkavégzés idejét, az időbejegyzéseket itt vihetjük fel.
• Bizalmasság (Confidentiality): Ezt az opciót, ha lehet ne használjuk. Ha a gyakorlatvezető nem fér hozzá az issue-hoz, értékeléni sem tudja azt.
• Zárolás (Lock issue): Az issue módosításának tiltása.
• Értesítés (Notification): Bekapcsolható az értesítés, ha valami változás történik az issue-n, a felelősök kapjanak-e értesítést, vagy sem.
• Feladatok (Tasks): Egy issue feladatokra osztható, ezek a feladatok hozzárendelhetők az issue-hoz. Ezeket a hozzárendeléseket mindig végezzük el, hogy a fejlesztéssel kapcsolatos tevékenységek egy pontból kiindulva elérhetők legyenek. Az Add nyomógombbal vehetők fel új feladatok, illetőleg kapcsolhatók meglévők az adott issue-hoz.

Terminológia

A tananyagban követett terminológiához kapcsolódva ezek a feladatok lehetnek storyk és a konkrét fejlesztéseket tartalmazó feladatok (taskok). Az epic esetére javasolt kapcsolódó elemeket felvenni, amelyekről a következő pontban olvashatunk.

• Kapcsolódó elemek (Linked items): Hasonlóan a taskokhoz, további issue-k kapcsolódhatnak az aktuálishoz. Ezeket a kapcsolódásokat akkor kell megadni, amennyiben a két issue között függőségi reláció áll fenn.
• Tevékenység leírása (Acitivity): A fejlesztés során részletezni kell milyen tevékenységeket végeztünk el az adott issue-hoz vagy feladathoz kapcsolódóan. Ebbe a mezőbe kell felvenni majd a megvalósított fejlesztéshez kapcsolódó dokumentációt, illetőleg itt fogjuk kezelni a tervezéshez és teszteléshez kapcsolódó információkat is.

Fontos, hogy az issuek és a kapcsolódó feladatok életciklusát kezeljük, azaz az issue board megfelelő oszlopába helyezve őket (drag and drop módszer) követhető legyen az aktuális státuszuk. A gyakorlat során elvárás az is, hogy a csapatfeladatot tartalmazó issue-ból kiindulva a gyakorlatvezető minden kapcsolódó információt el tudjon érni külön keresgélés nélkül. Minden hivatkozást, feladatot be kell linkelni a csapatfeladatot tartalmazó issue alá, és az adminisztratív információkat is napra készen kell tartani minden kapcsolódó feladaton, issue-n.

Használati esetek kinyerése

A használati esetek az adott fejlesztési feladat felhasználói szempontokat tartalmazó funkcionális modelljei. A használati esetek maguk olyan forgatókönyvek, amelyek az adott fejlesztéssel érintett rendszerelem felhasználó szemszögéből történő működését írják le részletesen. A használati esetek modellezésére többféle megoldás is létezik. A gyakorlaton az UML használati eset diagramját és a kapcsolódó lefutásokat javasoljuk használni, illetőleg jól használhatók még a már ismertetett user story-k is.

Használati esetek és user storyk

Minden tanult modellező eszköznek megvan a maga szerepe. A user storyk tömör és a felhasználó szempontjából releváns leírást adnak egy funkcionalitásról és az arra vonatkozó követelményekről (az acceptance criteria pontban felsorolt követelmények útján). A használati esetek ezzel szemben az egyes használati esetek forgatókönyveire fókuszálnak. A user story segítségével tehát felső szinten definiálható egy használati eset és a kapcsolódó követelmények, míg a használati eset modellezésével a használati esetek közötti kapcsolatok, valamint az egyes használati esetek lefutása specifikálható.

Az issue-khoz kapcsolódó használati esetek kinyerésére nincs formális módszer. Meg kell érteni az issuek célját a Product Owner bevonásával (grooming során) finomítani, lebontani azokat olyan szintre, amelyekhez már elemi műveletek definiálhatók. A forgatókönyveket ezen elemi műveletek sorrendjének és feltételeinek definiálása útján ettől kezdve lehet specifikálni.

Mesterséges intelligencia és specifikáció

Az utóbbi időben a nagy nyelvi modellek (LLM) megjelenésével a mesterséges intelligencia és gépi tanulás alapú alkalmazások fejlődése robbanásszerűvé vált. Ma már vannak olyan lehetőségek (többnyire prémium előfizetéssel), amelyek segítséget nyújtanak szöveges módon specifikált (akár hibás nyelvtani szerkezetben) követelmények formalizálására, ezáltal formális modellek generálására. Fontos azonban megemlíteni, hogy ezek az eszközök legyenek bármilyen fejlettek, nem képesek arra, hogy az ügyfél igényeit pontosan értelmezni tudják. A specifikációs feladatok ezért továbbra is emberi munkát igényelnek, és bár az MI eszközök támogatást tudnak nyújtani, ezt a feladatot nem tudják az embertől átvenni.

Ne bízzuk rá magunkat vakon a reverse engineering eszközökre!

A reverse modelling eszközök rendkívül hasznosak, de amíg egy programkódban az osztályok és kapcsolataik azonosítása egyértelmű, addig a természetes nyelvben természetszerűen meglévő bizonytalanságok, kétértelműségek miatt a nyelvfeldolgozásra épülő reverse modelling mindig rejt magában hibalehetőséget. Ha használunk is ilyen eszközt, az eredmény ellenőrzését és ügyfél általi validálását nem szabad kihagyni.

A chatGPT téves választ is adhat

A nagy nyelvi modellek használata elővigyázatosságot igényel. Mivel ezek az eszközök úgy vannak tanítva, hogy az általuk generált válasz abból adódik, hogy a felhasználó által adott kérdés (prompt) elemei milyen környezetben fordulnak elő a legnagyobb valószínűséggel, a tévedés lehetősége fennáll. Különösen igaz ez azokban az esetekben, amikor szakmai kérdésekkel fordulunk ezek felé a modellek felé. Egy hibás, de gyakran megjelenő vélemény a tanító halmazban az LLM-ek esetében is hibás működést fog eredményezni. Minden esetben ellenőrizzük a választ, amennyiben használjuk ezeket a modelleket, illetőleg használjuk őket információ gyűjtésre, esetleg kivonatolására, ne arra, hogy helyettünk gondolkodjanak. Ez utóbbira nem alkalmasak.

A használati eseteket vigyük fel az issue megfelelő rovatába, a validáció folyamatát is dokumentáljuk tartalmilag a kapcsolódó issue-ban, folyamat szempontjából pedig a megbeszélés jegyzőkönyvekben, illetőleg memokban.

Kidolgozott példa

Tekintsük az alábbi issuet:

Smoke and fire should be used to mark outliers: Place (camp) fires near buildings with much higher or lower values of the important attribute than the rest of the buildings. In this way, those can be found from a distance due to the smoke emitted from the fire.

Issue elemzése, megértése

A gyakorlatban előforduló feladatok, különösen az agilis szoftverfejlesztés területén hasonló stílusban, tömör megfogalmazásban vannak megadva. Egy ilyen a példában is látható feladat jellemzően egy komplexebb user story része, amelyet a finomítás során jól definiálható feladatokra bontottak.

Ahhoz, hogy a feladatot megértsük, vizsgáljuk meg a szöveg szerkezetét. A cím mellett két mondatot találunk benne, ahol az első mondat felszólító módban egy utasítást közöl, míg a második mondat egy egyszerű kijelentés, ami rövid magyarázatot tartalmaz az utasítás céljáról.

A cím önmagában is beszédes, azt mondja, hogy outliereket kell megjelölni füst és tűz használatával.

Mik azok az outlierek?

Az “outlier” kifejezést a statisztikában használják, és olyan adatpontokra utal, amelyek jelentősen eltérnek a többi adatponttól. Az outlier-ek gyakran hibás mérések vagy rendkívüli események eredményei, és befolyásolhatják az adatelemzés eredményeit. Például, ha egy osztályban a diákok átlagosan 10 és 15 közötti pontszámot érnek el egy teszten, de egy diák 100 pontot kap, akkor azt mondhatjuk, hogy ez az eredmény egy outlier.

Az utasítást tartalmazó mondatban maga az utasítás a place, tehát el kell helyeznünk valamit. A jól megfogalmazott mondatok elemzésével, a mondatrészek azonosításával pontosan láthatjuk, hogy mit is kell konkrétan kódolnunk. A fenti példában az állítmányt már meghatároztuk (place). Az alany ugyan nincs konkrétan jelölve, de könnyen kitalálható, hogy kinek kell a cselekvést végrehajtani, nyilván a gépen futó programnak. A tárgy, azaz amit el kell helyezni a fires. Ezenkívül van egy összetett helyhatározónk. Maga a helyhatározó azt írja le, hogy hol kell elhelyezni a tüzet (near buildings). Maga a teljes határozói szerkezet near buildings with much higher or lower values of the important attribute than the rest of the buildings. A with szó után lévő részt tekinthetjük egy szelekciós feltételnek is, ami specifikálja, hogy mely épületek mellé kell tüzet elhelyezni. A szerkezet egy összehasonlítást tartalmaz, azt mondja amelynek fontos attribútumai jelentősen nagyobbak vagy kisebbek, mint a többi épület esetében.

Jó jó, de mégis mi az, hogy much higher or lower?

Ez a megfogalmazás valóban pontatlan, de könnyen megfejthető. Csak nézzük meg az attribútumok átlagos értékekeit és a szórásukat. Ha a szórás egy általunk választott n-szeresénél (a gyakorlatban ez legtöbbször 3) nagyobb, vagy kisebb egy attribútum értéke, akkor azt a fenti módon megfogalmazott mondat szerint fogja értékelni a legtöbb ember, vagyis outlier lesz.

A második mondatban látjuk, hogy mi ennek a feladatnak a célja, ami tulajdonképpen a használati esetünk is egyben. Mivel a CodeMetropolis szoftvermetrikák vizualizálását végzi a város metafora használatával, a kiugró értékek megtalálása jogos felhasználói igény. A tűz füstje ezt szolgálja, ha távol vagyunk az érintett programrésztől, a füst mint irányjelző segíteni fog annak megtalálásában.

Használati esetek

A fenti issue tartalmazza a használati eset leírását. A második mondat, ami a célt fogalmazza meg, lényegében magát a használati esetet specifikálja. Ebben a használati esetben egyetlen szereplőt (aktort) találunk, mégpedig a felhasználót, aki a kiugró eseteket (outliereket) szeretné megtalálni a város épületei között. Ugyanakkor az issueban az is benne van, hogy a fontos attribútumok megtalálása a cél. A fontos attribútumok nincsenek specifikálva, ezt a leképezés során kell specifikálni. Az, hogy mi lehet fontos, a felhasználói igények határozzák meg, a szoftverfejlesztés esetében ezek jellemzően olyan metrikák, amelyek valamely minőségi mutató meghatározásában vesznek részt. Tehát az aktorunk nemcsak az outliereket szeretné megtalálni, hanem szeretné könnyebben megkülönböztetni az általa fontosnak tartott atrribútumokat a többitől.

Fontos tulajdonságok megjelölése

A fontos tulajdonságokat megadhatóak a mapping során mint constant.

Hova helyezzem el a tüzet?

Olyan helyre célszerű, ahonnét messziről is látszik. Például lehet a garden, ground. A floor, cellar elemeket ne használjuk, mert ezek belső elemek, amelyek egymásra helyezhetők és így nem látszik a tűz füstje távolról.

Az issue-ban leírt feladat két fő használati esetben foglalható össze. A felhasználó a könnyített navigációt használja, hogy megtalálja a kakuktojásokat, kilógó eseteket. Illetve a felhasználó a mapping fázis során megjelöli hogy mely attribútumok "fontosak".

Kapcsolódó issuek

Ezen a szinten, azaz az issue felderítésének a szakaszában a kapcsolódó issuekat az eredeti issue-ban lévő, illetőleg a fenti folyamatban meghatározott kulcsszavakra történő kereséssel tudjuk meghatározni. Amennyiben a specifikáció következetes, és a használt terminológia is konzekvens, úgy ez a módszer kielégítő hatékonyságot biztosít.

A találat a keresésben használt kifejezések specifikálásával szűkíthető, vagy azok elvétele útján bővíthető. Azt, hogy egy bővebb vagy specifikusabb keresési feltételből indulunk ki és szűkítjük/bővítjük a találatot, egyéni preferenciánktól függ.

Címkék használata

Ha az issuek specifikációja során kiterjedten használjuk a címkéket, akkor az a keresési tevékenységet nagyban tudja támogatni.

A fenti issue-hoz kapcsolódó issuek lehetnek például a következők:

• Use water flow as a representation of some properties : The Render tool should be able to place water sources near or onto the levels which is a way to indicate a metric. The vertical offset of the water source and the number of water flows can indicate different metrics. The vertical offset will be measured in percent of the levels' height, while the number has a lower and an upper limit (for example according to 2D connectivity of the building). The source and their supporting block should be placed so that the flow does not destroy any other building. The name of the properties in the IXML file should be water-source-height and water-source-count. While the mapping tool is not ready to produce this property, several appropriate sample files must be created manually.
• Self-destructs for release fustration (TNT) : The Rendering tool should be able to place self-destruct devices (TNT blocks with some support) inside or near buildings. If the graphical property self-destructs was set to yes the building should be generated with an unarmed device. The trigger needs to be placed in an easily accessible way. The user could relax a little bit by activating the device and watching the destruction. This is meant to be a fun feature. However, the explosion should be limited as much as possible to the building which has the device. Need further research on how to trigger all TNT-s and demolish the most frustrating buildings. While the mapping tool is not ready to produce this property, several appropriate sample files must be created manually.
• Use lava to label as a representation of some properties: The Render tool should be able to place lava sources near or onto the levels which is a way to indicate a metric. The vertical offset of the lava source and the number of lava flows can indicate different metrics. The vertical offset will be measured in percent of the levels' height, while the number has a lower and an upper limit (for example according to 2D connectivity of the building). The source and their supporting block should be placed so that the flow does not destroy any other building. The name of the properties in the IXML file should be lava-source-height and lava-source-count. While the mapping tool is not ready to produce this property, several appropriate sample files must be created manually.

Gondolkozzunk !

Melyek a fenti issue leírásokban azok a jellemzők, amelyek alapján a példa issue-val történő kapcsolatot jellemezhetjük?