Szerző: Novák István
„Te István, milyen architektúrát javasolsz a … fejlesztésünkhöz, ha ezt agilisan, Scrum keretrendszerben szeretnénk végezni?”
Gyakran teszik nekem fel ezt a kérdést a fejlesztési projektek vezetői. Általában meglepődnek, amikor azt mondom, hogy önmagában attól, mert agilis módszerekkel dolgozunk, nem kell feltétlenül másfajta architekturális megközelítési módot használnunk. Persze mindez nem jelenti azt, hogy bármilyen architektúrát változtatások nélkül tudunk, illetve anélkül célszerű használnunk. Tényleg, létezik olyasmi, hogy agilis architektúra?
Polcról leemelhető kész agilis architekturális mintként nem találunk ilyet. Létezik azonban agilis architektúra szemlélet, vagyis olyan tervezési módok, amely kifejezetten támogatják az agilis megközelítést. Az egyes architekturális mintákat én három kategóriába szoktam sorolni annak megfelelően, hogy azok milyen módon segítik az agilis elvek érvényesítését/érvényesülését a termékfejlesztés folyamat során.
“Maradi” architekturális minta
Minden olyan szoftver- vagy alkalmazás-architektúrát ebbe a kategóriába sorolok, amely nem ad explicit (vagy legalább implicit) támogatást az agilis elvek követéséhez. Véleményem szerint ide azok a tervezési és implementációs minták tartoznak, amelyekben az itt felsoroltak közül akár csak az egyik jellemzőt is megtalálhatjuk:
- Nincsenek explicit szoftverrétegek, vagy nem egyértelmű azok felelősségi köre.
- Nem teszi lehetővé automatikus tesztesetek folyamatos előállítását a munkadarabok fejlesztésével egy időben, vagy mindezt csak nagyon alacsony hatékonyság mellett támogatja.
- A használata során gyakran kell szembesülnie a fejlesztőcsapatnak azzal, hogy a termékképességek átalakítása, bővítése az architektúra jelentős részének refaktorálásával jár együtt.
Ez a tervezési minta komoly veszélyforrást jelent minden agilis projekten, mert a hatékonyságra, a produktivitásra és a folyamatosan alacsony szinten tartott műszaki adósságra való törekvésben akadályozza meg a fejlesztőcsapatot.
Hasznos architekturális minta
Az előző “maradi” minta ismérvei alapján értelemszerűen ebbe a kategóriába sorolom az összes olyan mintát, amely az alábbi alapvető elvek mindegyikét teljesíti:
- Explicit szoftverrétegekkel rendelkezik, azok explicit felelősségi körrel bírnak.
- Az architekturális megoldás egyszerűvé teszi az automatikus tesztek előállítását a munkadarabokkal egy időben, és ez reális ráfordításot kíván a fejlesztőcsapat részéről.
- A meglévő termékképességek bővítése, új képességek kialakítása általában jól beilleszthető a már elkészült architektúrába, az esetleg szükséges strukturális változtatások csak az architektúra egy jól meghatározott szegmensének a refaktorálását igénylik.
Azok a minták, amelyek a fenti képességeket támogatják, hatékonnyá, termelékennyé tudják tenni a csapatot, és lehetővé teszik, hogy a műszaki adósság alacsony szinten tartása a napi fejlesztői munka természetes részévé válhasson.
Agilitásra hangolt architekturális minta
A fentiekből világosan látszik, hogy számomra az agilitás szempontjából a minták alábbi viselkedése számít kifejezetten fontosnak:
- Rétegzettség, explicit felelősségi körök támogatása. Bár ez az elv nem kifejezetten csak az agilitás szempontjából fontos, de agilis fejlesztést enélkül végezni nem lehet. Egy kisebb alkalmazás esetében, amelyen egyetlen fejlesztő dolgozik, lehet szoftverrégtegek nélkül is haladni, bár egy ilyen alkalmazás karabantarthatósága erősen megkérdőjelezhető. Csapatban, folyamatos termékbővítmények elkészítésére viszont ez a megközelítési mód alkalmatlan, ugyanis nagyon megnehezíti a közös munkát, minözben elősegíti a műszaki adósságok felhalmozódását.
- Automatikus tesztelhetőség és annak hatékonysága. Minden agilis projekt alapelve a folyamatosan kiváló minőség, aminek mértékét, jellemzőit a csapat definiálja. Ez ma már automatikus tesztelés nélkül nem működhet. Azok az architekturális minták, amelyek nem támogatják az automatikus tesztesetek hatékony elkészítését, hátrányt jelentenek a csapat számára, mert erőforrásaik nagyobb részét kell a minőség fenntartására fordítaniuk, mintha egy megfelelő architekturális mintát választottak volna.
- Az architektúra rugalmassága. Az agilis fejlesztés a változások, változtatások állandóságát jelenti. Minél jobban tud ezekre az változásokra reagálni az architektúra, annál jobban segíti az termékbővítmények előállítását.
Gyakran figyelem meg azt ügyfeleim projektjein, hogy sok architketúra-tervezéssel foglalkozó szakember a rugalmasságot úgy igyekszik biztosítani, hogy az architektúrát “túlfinomítja”. Extra rétegeket, felelőségi köröket, komponenseket tervez bele abba azért, hogy az a későbbiekben (előre látni vélt módon) képes legyen a változásoknak megfelelni, és a jövőbeli igényeket az architektúra jelentősebb átalakítása nélkül elviselni. Ez jó megoldásnak tűnik, de valójában mégsem az. A jelenben extra erőforrásokat (az architekturális minta összetettsége miatt) kell feláldoznunk azért, hogy a majd a jövőben hatékonyabbak lehessünk. Ez egyfajta veszteséget jelent (készletezés). Sokkal hasznosabb lenne az így elvesző erőforrásokat inkább a kézzelfogható termékképességek előállítására fordítani.
Az architektúra túlzott finomítása helyett olyan tervezési mintákat célszerű használni (mindig a konkrét fejlesztés alatt álló termékhez igazítva), amelyik sprintről sprintre hatékonyan módosítható, ha erre szükség van.
A hasznosnak tekintettek minták közül én az ilyen értelemben rugalmasnak tekinthetőket tartom kifejezetten fontosnak, és agilitásra hangolt architekturális mintának nevezem őket.