Csak a tesztemen keresztül!

Szakmai gondolatok informatikai rendszerek teszteléséről.

Gazda

Friss topikok

  • Akron: @Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel) A cég ellenőrzi le és veszi át ... (2018.01.31. 14:09) Miért UAT
  • Verhás Péter: @ hrgy: Egy kicsit felhúztam magam, de sebaj. A lényegi állításokban igazad van, ám a személyekre... (2011.10.09. 00:25) A tesztelés nem mindenható
  • crix: Ez a hozzáállás. Sajnos most is. Aztán csodálkoztak itt a népek, amikor bevállaltam a hétvégi munk... (2011.10.05. 16:56) Újra fizetni kell
  • crix: és milyen specifikáció mentén ment át az ügyfél? elég blind? (2011.10.05. 13:41) Ügyfélteszt
  • fqqdk: fitnesse, concordion, és cucumber integráció lesz? (2011.03.05. 13:42) Automatizált tesztelés és üzleti tesztelés

Társblogok

Agilis? Nem agilis?

2010.05.25. 16:44 | Verhás Péter | 9 komment

Nem régen a következő levelet kaptam a blog.hu-n keresztül:


Ha lehet, egy érdekes szakmai kérdést szeretnék feltenni:
Van-e összefüggés a szoftver minősége és az alkalmazott fejlesztési módszertan között?

A saját megfigyelésem az, hogy az agilis módszerekkel fejlesztett szoftverekkel az ügyfelek elégedettebbek, de ugyanakkor ezen szoftverekkel rengeteg probléma van. Tipikusan olyan hibák, amik teszteletlen szoftver esetén bukkannak fel: regressziós hibák, összeomlások, a rendszer nem elérhető. Az üzemeltetés is egy rémálom

Az érdekelne, hogy ez a módszertan sajátossága, vagy csak az adott fejlesztők/menedzserek bénasága?


A válasz az, hogy igen. Ez a módszerek sajátossága, és fejlesztők, menedzserek bénasága. Azt is mondhatnám, hogy bénák választják az agilis módszertant, és az agilis módszertannal a profik is bénává lesznek, és sokszor a gyakorlatban ez így is van. De nem mindig. És ennek nem kellene így lennie.

A dolog nyitja, hogy mindig azt az eszközt kell használni, amelyik az adott feladatra és az adott ügyfélhez a legjobb. A módszertan csak egy eszköz, és semmi több. Egy olyan eszköz, amelyik arra szolgál, hogy emberek közötti együttműködést segítsen elő.

A vízesés módszernél a projekt elején hosszan tervezés van, és csak a projekt második felében kezdődik a fejlesztés. Türelmetlen, és tapasztalatlan ügyfél ettől nem boldog, nem elégedett. Sok idő elment, talán még fizetnie is kellett a tervekért és még nincs „semmi”.

Agilis fejlesztés esetén nem kell tervezni (?). Egyszerűen nekiállunk kódolni, elkezd működni a szoftver, legfeljebb újraírjuk. Ezzel elégedett az ügyfél, hiszen mindjárt van valami amit lát, hogy működik, mozog.

A vízesés projektek akkor szoktak megbukni, ha az ügyfél türelmetlen, nincs bizalma a fejlesztő csapatban, és leállítja a projektet. Na ilyenkor szív a fejlesztő csapat, ha nem fizettette ki előre a tervezési munkákat, és kezdődhet a pereskedés.

A vízesés projektek azonban úgy is megbukhatnak, ha a fejlesztő csapat ellógja a tervezést, és nincsenek rendes, jó tervek mire el kell kezdeni fejleszteni, és akkor nekiállnak agilisan kódolni. Ez persze nem csak úgy történhet, hogy ellógják a tervezést. Hasonló eset úgy is előfordul, hogy a tervezés során nem sikerül az ügyfélből „kiszedni” a megfelelő információt.

Az agilis projektek viszont lehetnek sikeresek is. Néha előfordul.

A személyes tapasztalatom az, hogy az agilis módszertant használók legnagyobb tévedése az a mondás, hogy agilis módszertan esetén nem kell tervezni. Kell. És minden olyan agilis projektnél amelyik sikeres volt is tervezés. Meglepő módon még akkor is, amikor a résztvevők szerint sem volt. Volt, csak nem vették észre, vagy nem tudtak róla.

Kiválóan lehet agilis módszertant alkalmazni olyan esetekben, amikor a feladat eléggé körülhatárolt, nem túl egyedi és olyan kertrendszerek állnak rendelkezésre, amelyek megadják az alap architektúrát, az alap szolgáltatásokat, és csak ezekhez kell valami kiegészítést készíteni. Ilyenkor valóban nem kell tervezni, mert a tervezés már megvolt akkor, amikor a kertrendszert elkészítették.

Ha például Groowiki-ben implementálok egy munkafolyamatot, akkor elég a munkafolyamatot leírnom XML-ben, megterveznem az egyes dokumentumok, és munkafolyamat lépések meta adatait (képernyőket) és le kell esetleg programozni a munkafolyamat elemi lépéseit. Nem kell architektúrát tervezni: neki lehet kezdeni, és egy nap alatt már mozog a kód, adatot lehet rögzíteni, lekérdezni, munkafolyamatot indítani. Két hetes sprintekkel ki lehet fejleszteni az összes folyamatot ami kell a cégnél, és minden sprintben lehet egy kicsit finomítani az előző sprintekben elkészült munkafolyamatokat. A projektben nem kellett tervezni.

De előtte, amikor a Groowiki workflow implementációja készült, akkor kellett.

A tesztelés megint egy külön téma, de ott meg aztán végképp nagyon rossz a tapasztalatom. Akár waterfall, akár agilis: tesztelés az nem nagyon szokott lenni. De, ahogy a levélíró is érzékeli: waterfall fejlesztésnél azért inkább. Ahhoz a habitushoz közelebb áll a fegyelem, a teszteléshez pedig fegyelem kell.

Összefoglalva: lehet egyik, és lehet másik módszertant alkalmazni, és egyik sem az ördögtől való. Vannak helyzetek, amikor még választani is lehet, hogy melyiket akarjuk. Van amikor a feladat, vagy az ügyfél miatt kell agilis, vagy éppen waterfall módszert választani, és van amikor keverni lehet vagy éppen kell a két módszertant: józan paraszti ésszel. És végül van olyan helyzet, amikor a probléma csak waterfall megközelítéssel és hozzáállással oldható meg, de az ügyfél viszont csak agilis módszertant visel el. Ilyenkor kell menekülni, különben vagy így, vagy úgy de bukik a projekt, és sem a fejlesztő csapat nem lesz boldog sem a felhasználó.

 

A bejegyzés trackback címe:

https://csakatesztemenkeresztul.blog.hu/api/trackback/id/tr202030565

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

zsotykai 2010.06.06. 18:22:01

Személyes tapasztalatként azt is hozzáfüzném, hogy a vízesés modell akkor is bukik, ha az ügyfél tervez rosszul, és/vagy a fejlesztő rossz szerződést köt, és/vagy nincs elég ereje betartatni (e.g. akár az üf. is fizethet kötbért, ha nem reagál időben) és/vagy a változásmenedzsment le van sz@rva.

akocsis · http://akocsis.blog.hu 2010.06.08. 19:06:30

Köszönöm szépen a válaszokat, tanulságos volt.
A cikket meglinkeltem saját blogomból.

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2010.06.08. 19:11:43

A kérdést feldobtam a java listán is. Ott eddig 53 válasz érkezett. Alkalomadtán egy külön blogba összefoglalom a válaszokat. A lista archívum elérhető addig is a

javagrund.hu/pipermail/javalist/2010-June/thread.html

oldalon.

fanta (törölt) 2010.06.09. 12:11:00

Kezdetben vala az "agilis programozas", de meg nem igy hivtak :). Aztan jott a vizeses modell, ahol a fejlesztok ellogtak a tervezesi fazist, uh. vissza kellett terni a jol bevalt modszerekhez, de valami jól marketingelhető kifejezest kellett valasztani. Így keletkezett az agilis módszertan.

akocsis · http://akocsis.blog.hu 2010.06.10. 09:15:36

Megnéztem a JAVA listát, és... hát izé...
A kérdés alapvetően a teszteléshez, másodsorban a minőségbiztosításhoz kapcsolódik. Nem vagyok meggyőződve arról, hogy akadt olyan hozzászólás, ami erre - azaz az eredeti kérdésre - vonatkozott.
Ellenben kiderült, hogy az ügyfél tehet minden rosszról, meg a körülmények, és hogy 1200 forintért kell venni egy szívlapátot aztán jól lerendezni a dolgokat :)

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2010.06.10. 10:14:36

@akocsis: Azért azt tudni kell, hogy a Java lista elég belterjes, nagyon sokan ismerjük egymást személyesen is. Ennek megfelelően többségében -- azt gondolom -- tudjuk értékelni az ott elhangzottakat.

A szívlapát dolgot senki sem gondolta komolyan. (Vagy igen?)

akocsis · http://akocsis.blog.hu 2010.06.10. 11:28:06

@Péter: valóban sok érdekes gondolat került elő, de talán mégis csak inkább ez a post ad érdemi választ a feszegetett kérdésekre.

Van_mikrohullámú_sütőtök? 2010.09.10. 17:32:40

Főnököm mondta vala (isten nyugosztalja), hogy az ügyfél szempontjából 2 módszertan/megoldás van: a jó és a rossz.

Az, hogy ez mennyi idő alatt, milyen költséggel, milyen technikai megoldással stb. valósul meg tárgyalás és részletkérdés.

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2010.09.10. 18:47:44

@sambalabammbumbumm: Ja, csak a megoldás mindig a részletekben rejlik. Mindig a részleteket kell megoldani, és akkor kirajzolódik az egész.