Tanulmányaink, munkánk során a leghangsúlyosabb szerepet az alkalmazandó programozási nyelvek, technológiák, algoritmusok kapják. Viszonylag kevés szó esik a szoftverhibákról. Álljon itt, hogy mik a leggyakrabban felmerülő téveszmék velük kapcsolatban!
A szoftver legyen hibamentes!
Ez pontosan egy olyan kijelentés, amivel semmit nem lehet kezdeni. Előszeretettel szajkózza ezt ügyfél vagy a fejlesztő oldalon a szoftverfejlesztéshez kevéssé értő menedzser. Azzal, hogy az ügyfél fizet, (jogosan) úgy gondolja, hogy a pénzéért hibamentes szoftvert kell, hogy kapjon. A szoftverfejlesztő oldalon ülő menedzser emiatt pedig “üti” a szoftverfejlesztő fejét.
Ha érezzük magunkban a bátorságot, világosítsuk fel őket, hogy a szoftverfejlesztés kicsit másképpen működik.
Egy szoftver jelenlegi ismereteink szerint nem tud hibamentes lenni. Ennek legfőbb oka, hogy egy szoftver nem matematikai alapokon készül.
Költői kérdés: atomreaktor vezérlőszoftvert tervezünk, vagy egy olyan üzleti alkalmazást, amely futása során a hiba bekövetkezése nem eredményez komolyabb következményt? (Komolyabb következmény = nagy üzleti veszteség, nagy felhasználói elégedetlenség.)
Csupán a hibák bekövetkezésének minimalizálására törekedhetünk, ebben pedig különféle technikák segíthetnek. Célszerű például automatizált teszteseteket készítenünk a szoftverünkhöz (unit tesztek, integrációs tesztek), amik rendszeresen (minden commit után, naponta egyszer) lefutnak. Hasznos lehet a páros programozás is, és a code review-k is sokat segíthetnek a nem kívánt hibázások elkerülésére.
Ez nem bug, hanem feature!
Szoftverfejlesztőként sokszor rácsodálkozunk egy, az ügyfél által bejelentett hibára. Ezt most miért jelentették be? A szoftver a követelményeknek/terveknek/megbeszélteknek megfelelően működik. Ez nem is hiba, ez így lett lefejlesztve.
Ez nem bug, hanem feature!
Attól függően, hogy a saját érdekem hogy kívánja, úgy értelmezem a hiba fogalmát. Ha fejlesztő vagyok, akkor ragaszkodom minden – a projekt során a dokumentumokban – leírt követelményhez, tervezési döntéshez. Sokszor könnyű is a dolgom, mert a dokumentációk alapján könnyen igazolhatom, hogy egy felmerült probléma nem is hiba, hanem új igény (pl. nincs benne leírva, nincs benne leírva pontosan, félreérthetően fogalmaz). Ha ügyfél vagyok, akkor a saját üzleti gondolkozásom mentén érvelek, és azt bizonygatom, hogy a szoftver nem alkalmas arra, amire hivatott, azaz az üzleti igényeim kielégítésére, ergo hibás.
Ha fejlesztő vagyok, akkor próbálom lerázni magamról a problémát, ha ügyfél vagyok, akkor pedig kötözködöm. Ez nem rossz szándék kérdése, egyszerűen alapviselkedés. Mindig saját magunkat védjük.
Kétféleképpen kezelhetjük a bug vs. feature problematikáját.
A védekező álláspont. Pontosan definiáljuk, mit jelent a bug és mit a feature, aztán továbbra is veszekedünk az ügyféllel. Végül lesz egy annyira nem jó szoftver, ami kompromisszumok mentén kerül kifejlesztésre. Az ügyféllel történő viszony nem a bizalmon fog alapulni, hanem a szigorú elszámoláson.
A reális álláspont. Elfogadjuk azt, hogy az, hogy valami hiba-e, csak nézőpont kérdése, és az állandó vitatkozás helyett inkább azt nézzük meg, hogy a felmerült probléma milyen következményekkel jár az üzletben, és ennek megfelelően közösen priorizáljuk. Ha nincs harc, akkor a két fél között kialakulhat egy bizalmi viszony.
A hibáért a programozó a felelős!
Ezt egy középkorú ügyféltől (hölgytől) hallottam, aki állítása szerint maga is programozó volt a hőskorban. Nagyon megdöbbentett a dolog, amikor meghallottam, és nem is tudtam hirtelen rá mit válaszolni.
A munkánkat (jobb esetben) próbáljuk a legjobb tudásunk szerint végezni, és erre ő azt mondja, hibásak vagyunk azért, ha bármi hiba bekerül a programba?!
Csak ismételni tudom magamat. A szoftver nem tud hibamentes lenni.
Tipikus probléma a fejlesztés során, hogy a fejlesztő és az ügyfél azt gondolja, értik egymást, és valójában nem ez a helyzet. Ez a probléma sokszor okolható bizonyos félresiklásokért. Ezért is a programozó lenne a felelős?
Fontos azzal is tisztában lenni, hogy az ügyfél nem tudja pontosan, mit akar. Ő elvárásokat kommunikál felém. Az, hogy ebből hogyan lesz használható szoftver, az már mindkettőnkön múlik, de alapvető felelőssége van a szoftverfejlesztőnek, akinek tudnia kell, hogy milyen módszerek mentén érhető el a cél.
Más teszteljen, mint aki fejleszt!
Az alapgondolat helyes, viszont a fejlesztőnek is ki kell vennie a részét a tesztelésből. Pl. legalább egyszer ki kell próbálnia, hogy amit alkotott, az működik-e. (Érdekes módon, nem mindenki gondolja így.) Ennél azonban többet is tehet: készítsen automatizált teszteket (end-to-end, acceptance, unit), mielőtt belekezd a feladatba!
Ezen tesztek megírása segít abban, hogy a későbbiekben egy gazdag automatizált tesztbázissal rendelkezzen a szoftver, ami bármikor futtatható. Ezen tesztek jelentősen csökkentik bármilyen későbbi változtatásból eredő programhiba elsiklását.
Ha ebből a szemszögből tekintem, akkor nem csak a tesztelő felelőssége a tesztelés, hanem magáé a fejlesztőé is.
Ha hiba van, osztályozzuk!
A hibák kezelésének egyik leggyakoribb módja az, hogy ha a szoftver életciklusának bármelyik pontján hibát detektálnak (akár maguk a fejlesztők, tesztelők, akár az ügyfél), akkor a hibát hibakövető rendszerben rögzítik. A hibát pedig bizonyos szempontok alapján osztályozzák is. Két dimenzió mentén szokott történni az osztályozás:
- severity: súlyosság, pl. low, moderate, high, critical.
- priority.
Minden környezetben maguk definiálják a csapatok, hogy ez a két fogalom mit jelent a számukra. Azonban egyfajta paradoxonra szeretném felhívni a figyelmet.
Tekintsünk egy helyesírási hibát a képernyőn. Ennek a súlyossága alacsony, hiszen ettől még működik a szoftver. Ez azt sugallja, hogy ennek a prioritása is alacsony kell, hogy legyen. Viszont sok felhasználó alapból kritikusan fogadja, ha helyesírási hibákkal találkozik egy szoftverben. Azt gondolják magukban: “Ez egy hibás szoftver!”
Nézzünk egy másik esetet. A szerver időnként lefagy. Nem tudjuk, mi az oka, igazából évente kb. egyszer fordul csak elő. Teljesen megmagyarázhatatlan a jelenség. Hogyan kategorizáljuk ezt? Ez nyilván súlyos probléma, hiszen leáll a rendszer, és nem lehet használni. A prioritásnak is ezt kellene tükröznie. Valójában a prioritása a problémának alacsony. Évente egyszer újra kell indítani a szervert, a rendszer 5p-ig nem elérhető, adatveszteség nincs vagy minimális. Bumm. A rendszerek többségénél ez kibírható.
Ebből is látszik, hogy a két tipikus dimenzió mentén történő kategorizálás (severity, priority) teljességgel félrevezető lehet. Az első eset alacsony súlyosságú, ellenben magas prioritású, a másik eset pedig magas súlyosságú, azonban alacsony prioritású besorolást kapott.
Szükségünk van-e erre egyáltalán?
Priorizáljuk a hibákat!
Egy hiba megítélésekor végeredményben egyetlen dolog számít. Milyen hatással lesz az üzletre, a felhasználóra? Tehát: mi történne, ha nem javítanánk ki a hibát, vagy valósítanánk meg a feature-t?
A “mi történne, ha nem javítanánk ki?” kérdés reális megválaszolása egy prioritást eredményez. Végeredményben ez kell(ene), hogy meghatározza, hogy mikor mivel foglalkozzunk.
A pusztán prioritások mentén történő besorolás újabb problémát vet fel. A tesztelői, ill. ügyfél általi hibabejelentések során a “mi történne, ha nem javítanánk ki” kérdés megválaszolása nagyon sokszor azt tárja fel, hogy valójában nincs is komolyabb következménye, ha nem foglalkozunk a problémával. Vagy kicsi az előfordulás valószínűsége vagy a hiba hatása elhanyagolható (vagy mindkettő). Ennek eredményeképpen nagyon sok bejelentés alacsony prioritást kap, és a lista közepére, végére kerül.
Összességében viszont ha sok hiba van a rendszerben, akkor azok együttesen már jelentős terhet jelentenek. Elburjánzanak, mert semmit nem kezdünk velük, “alacsony prioritásúak”.
Ezért hibás a Scrumot alkalmazók közül azok elképzelése, akik azt vallják, hogy a Product Backlogba kell elhelyezni az összes olyan hibát, ami nem igényel sürgős intézkedést, mert így végül azok soha nem lesznek javítva.
A probléma egyik megoldása, hogy függetlenül attól, hogy mi a hiba prioritása, egyéb teendőinkkel párhuzamosan időnk valahány százalékát mindenképpen a hibák javítására fordítjuk. Ezáltal biztosított, hogy a hibák folyamatosan javításra kerülnek, végül elfogynak. A probléma egy másik megoldása a Stop the line! módszer alkalmazása.
Stop the line!
A Toyota által alkalmazott Lean gyártás során a gyártósor mellett dolgozó munkás feladatai közé tartozik, hogy a teljes gyártósort leállítsa, ha hibás munkadarabot fedez fel a soron. (Stop the line!) Ilyenkor feltárják a gyártás közben talált probléma okát, kijavítják a hibát, és újra indítják a gyártósort.
A legtöbb gyártással foglalkozó vállalatnál a gyártósor végén ellenőrzik az elkészült munkadarabokat, és ott vizsgálják meg, hogy megfelelnek-e a követelményeknek. A gyártósor nem áll le selejtes darab esetén sem. A selejtet gyűjtik, kielemzik, osztályozzák, és meghatározzák, hogy mire lehet még felhasználni őket, tárolják, és szállítják őket.
A Lean-elv képviselői azt vallják, hogy a Toyota módszerének alkalmazása végeredményben hatékonyabb, ezáltal olcsóbb is, mert nincs szükség arra, hogy a selejtekkel külön foglalkozzunk (elemezzük, tároljuk, szállítsuk őket). A hiba azonnali javítása pedig elősegíti, hogy még kevesebb selejt keletkezzen.
Ezen Lean-elv lefordítása a szoftverfejlesztésre azt jelenti, hogy a detektált hibát azonnal javítjuk. Nincs szükség priorizálásra, és nincs szükség bugtrackerre sem, hiszen a rendszerben soha nem lesz egyetlen (ismert) hiba sem. Ennek a módszernek az alkalmazása közel 0-ra csökkenti a hibák kezelésének adminisztrációs költségét, a hiba felmerülésének és javításának közötti rövid idő miatt pedig csökken a hiba kijavításához szükséges idő hossza is. Pl. egyből konzultálhatunk a tesztelővel, aki a hibát találta, a javítás után hatékonyabb az ellenőrzés, mint a tesztelő emlékszik a hibára stb.
Konklúzió
A szoftverfejlesztés során felesleges a szoftverhibákkal kapcsolatos frusztráció. Mindenkinek el kell fogadnia, hogy a hibák, sajnos, velejárói a szoftverfejlesztésnek.
Ember a szoftverfejlesztő, ember az ügyfél. Bármelyik hibázhat. A kommunikációban is hiba, félreértés csúszhat be.
Ugyan hibák vannak a szoftverben, ez nem mentesít minket, szoftverfejlesztőket a felelősség alól. A mi feladatunk az, hogy minimálisra csökkentsük a nemkívánatos hibák bekövetkezésének valószínűsége. Ezt úgy érhetjük el, ha professzionálisak vagyunk, és megértjük, megtanuljuk, milyen a hibák természete, és hogy hogyan reagáljunk rájuk. A fejlesztési folyamat több pontján is alkalmazzunk hatékony visszacsatolási pontokat, amik lehetővé teszik, hogy a hibákat minél hamarabb észrevegyük, reagálhassunk rájuk, és végeredményben javíthassunk a szoftverfejlesztési folyamatunkon.
Stop the line!-elv megközelítése alapvetően változtathatja meg a világképünket a hibák kezelésével kapcsolatban. Érdemes végig gondolni, mit eredményezne, ha ezt az elvet alkalmaznánk saját szoftverfejlesztési projektünkben.
Kristóf
Jul 15th, 2010ez nem egy Acura? :))
egyébként a hibamentesség nem így igaz szerintem hanem úgy hogy az ügyfél mint product owner bátran prioritizálja be a hibák javítását, az ő jogköre (és felelőssége) hogy megmondja fontosabb-e az új feature, az X dokumentáció vagy az Y hiba javítása, ilyen értelemben semmi közünk hozzá..
Lóri
Jul 15th, 2010“Más teszteljen, mint aki fejleszt!
Az alapgondolat nem feltétlenül helytelen,”
Nem feltétlenül helytelen….. Nem tudom mennyit tudsz/tanultál/csináltál szoftvertesztelést, de a bejegyzés alapján elég lyukasak az ismereteid ebben a témában.
A Stop the line elvet szoftverfejlesztésre alkalmazni elég meredek dolog, főleg egy nagyobb projekt esetében.
kulcsi
Jul 15th, 2010Lóri: a stop the line elv valóban meredek, de hatékony, amennyiben a fejlesztői team kanban, scrum, vagy más agilis szoftver-fejlesztési módszertan szerint szerveződik. Ezt nem csak István gondolja így, hanem pl. Andy Singleton is.
Egyébként (kiosztás helyett) szerintem mindannyian szívesen vennénk, ha elmesélnéd, hogy Ti milyen módszereket alkalmaztok kritikus hibák javítására.
Marhefka István
Jul 15th, 2010Kristóf: Megfogtál az Acurával
Én úgy tudtam, hogy ez egy Lexus kémfotó.
Saját tapasztalatból írtam azt, hogy a sok nem fontos hiba annyira felduzzasztja a backlogot vagy a hibakövető rendszert, hogy így gyakorlatilag azok soha nem lesznek kijavítva (csak nő a hibák száma), és ez egyfajta időzített bombaként ketyeg az éles szoftver alatt.
Marhefka István
Jul 15th, 2010Lóri: A “más teszteljen, mint aki fejleszt” bekezdésem arra utalt, hogy a tesztelésből a fejlesztőnek is ki kell vennie a részét. Mégpedig úgy, hogy automatizált teszteseteket ír (unit teszteket, integrációs teszteket). Minden normális helyen így fejlesztenek (pontosabban: kellene fejleszteni).
A Stop the line! elv, ill. általánosan a Lean elvek alkalmazását a szoftverfejlesztésben nem én találtam ki, hanem Mary és Tom Poppendick. Annak ellenére, hogy agile módon fejlesztünk, nekem is hihetetlen volt ezt elsőre hallani. Egy idézet Poppendickéktől: „If software routinely enters final verification with defects, then it is being produced by a defective process.”
Az, aki hagyományos módon csinál fejlesztési projektet (követelményelemzés, tervezés, fejlesztés, tesztelés), az hitetlenül áll az elv hallatán.
Marhefka István
Jul 15th, 2010kulcsi: Igen, pontosan így gondoltam én is. Ha valaki a fejlesztési és tesztelési szakaszt teljesen különválasztja (az már jó eséllyel nem agile), az azokat az elveket fogja vallani, amiket én téveszmeként a cikkben említettem.
Pontosan azért írtam ezt a cikket, hogy felhívjam a figyelmet, hogy lehet, hogy nem úgy kellene működnie a folyamatainknak, ahogy tanultuk/látni szoktuk/szoktuk csinálni…
Egyébként kezdem azt vallani, hogy az mutatja meg, hogy valójában mennyire jó egy szoftverfejlesztési metodológia, hogy hogyan valósul meg a projektben a minőségbiztosítás.
Lóri
Jul 15th, 2010Az automata teszteket nálunk külön csapat írja és tartja karban.
Nagyjából scrum szerint dolgozunk, a tesztek “fejlesztése” (mind a manuális, mind az automata) egyszerre történik a szoftver fejleszétésvel, napi buildek vannak, minden éjjel regressziós teszt, A fejlesztés különböző szakaszaiban unit tesztek, function teszt, system teszt.
Prioritizálásra és bugkezelő rendszerre mindig szükség lesz, valahol nyilván kell tartani és kezelni kell azokat a hibákat, amiket az ügyfelek találnak. Az ügyfelek által talált hibáknál azt sem árt kielemezni, hogy hol kellett volna megtalálni és milyen teszteket kellene bevezetni az ilyen jellegű hibák idejében történő megtalálására.
A minden normális helyen így fejlesztenekre csak annyit tudok reagálni, hogy eddigi tapasztalataim alapján Magyarországon “tesztelési kultúra” nincs, a legtöbb helyen a tesztelés szükségességét is megkérdőjelezik.
Kicsit radikális dolog talán részemről, de aki “hagyományos” módon fejleszt (követelményelemzés, tervezés, fejlesztés, tesztelés), az hülye.
Az alapgondolat nem feltétlenül helyetelen mondatot kicserélném arra, hogy az alapgondolat helyes, azonban ez nem jelenti azt, hogy a fejlesztőnek nem kell tesztelnie, mivel a saját és a tesztelő dolgát nehezíti meg, ha a lefordított szoftver el sem indul.
(egyébként nem fejlesztő, tesztelő vagyok)
Marhefka István
Jul 15th, 2010Lóri: teljességgel egyetértek azokkal, amiket most leírtál, és hasonlóképpen dolgozunk mi is, ennek ellenére mégis az jött át nekem az eredeti kommentedből, hogy Te teljesen másképpen látod a dolgokat. Örülök, hogy nem ez a helyzet
Én a Stop the line! elvet gondolatébresztőnek szántam, amit mindenképpen tovább kell gondolni, mindenkinek a saját folyamata szerint. Azonban rendszeresen lehet találni olyan blogbejegyzéseket a neten, ahol arról számolnak be, hogy a módszer működőképes, és tényleg nincs szükség hibakövető rendszerre. Abban egyetértek, hogy valamilyen csatornán az ügyfélnek be kell tudnia jelenteni egy hibát, ha talál, de – az elv értelmében – ezeket nem szükséges szigorúan nyilvántartani, állandóan priorizálni és kategorizálni.
A Stop the line! egyébként többet jelent a szoftverhibák puszta azonnali kijavításán. Valójában a szoftver teljes életciklusára alkalmazható, alkalmazandó, és nem mondd mást, mintha bármilyen problémába ütközünk a szoftver kifejlesztése során, akkor tárjuk fel a probléma okát, és magát az okot szüntessük meg. Így például ha tele van hibával a szoftverünk, akkor nem csak az a feladatunk, hogy az egyes hibákat megszüntessük, hanem meg kell vizsgálnunk azt is, hogy hogyan alakulhatott ki az a helyzet, hogy átsiklottunk a hibák felett.
Erre sok módszer létezik (ahogy írtad is): automatizált teszteket lehet készíteni, refaktorálni lehet, code review-zhatunk, manuálisan tesztelhetünk, continuous integrationt alkalmazhatunk, ügyfeleknek rendszeresen demózunk, és akár utólag még csökkenthetjük is a rendszer komplexitását a már meglévő funkcionalitás egyszerűsítésével(!). Ezen módszerek külön-külön is finomhangolhatóak, ill. egymáshoz képest más-más arányban alkalmazandóak egy-egy projekten, vagy a projekt egy adott fázisán belül.
A javaslatod szerint módosítottam a cikk szövegén. Köszi.
Gyuri
Jul 21st, 2010szerintem is kicsit hiányosak a tesztelési ismereteid, annak ellnére, hogy két évig egymás mellett dolgoztunk!:) nekem igazából az írás második felével van gondom, ahol kicsit elszáll az elmélet egy utópisztikus irányba… az én véleményem, hogy egy lineáris priorizálás valóban elég, és elkerülhetetlen. ezzel együtt az is elkerülhetetlen, hogy a lista vége a product backlogban fog kikötni, de akár mennyire kevésbbé fontos, mint ismert hiba rendkívül fontos. innen egyenesen következik, hogy a Stop the line! csak megfelelő prioritású és súlyos hibánál működhet. nyílván, egy egyszerűbb helyesírási hibát azonnal ki lehet javítani, és nem kell megállni miatta a fejlesztésben. egy súlyosabb komponens hibánál sem kell leállítani az egész fejlesztést, ha az összes többi rendben van. ha pedig teljesen félre lett tervezve/fejlesztve a komponens, mást nem lehet tenni, mint leállni, és kijavítani. például egy hibás visszapillantó miatt nem fog leállni az egész folyamat, de ha a kocsi elektronikája a rossz, akkor már elég sok mindent át kell tervezni. a másik, hogy egy autógyártás, és fejlesztés leginkább ott különbözik, hogy az autó esetében egy alkatrész vagy jó és elkészült, vagy rossz. míg egy modul esetében simán van, hogy az még csak fél funkcionalitással rendelkezik, de az már jó, de még nincs készen. így az autógyártásban mást eleve nem lehet tenni, mint megállni. összességében egy jó nagy adag marketing van a toyota mögött, de azért mindegyiknek van vmi szériahibája! – beragadó gázpedál, kotyog vmi a motorháztető alatt, stb:)
én egyetlen módszerben hiszek amúgy, hogy a hibákat megtaláljuk: rogyásig tesztelni az alkalmazást! Boris Beizer és James Bach két nagy guru a témában, olvasom a blogjaikat, és ez a mondat kb. minden írásukban ott van: ha nem találsz elég hibát, vmit rosszul csináltál. vmi kis hiba mindenképpen marad a rovarölő effektus miatt, de a cél szerintem az, hogy a végén az ügyfél happy legyen!:)
Marhefka István
Jul 21st, 2010Gyuri: elég sok mindenről írtál a kommentedben.
Amit én írtam, az nem utópia, és nem is általam kitalált fantazmagória. (Mint ahogy ezt már említettem a kommentekben.)
[Stop the line]
Azt is olvashatod, hogy a Stop the line! elv a szoftverfejlesztésben nem csak azt jelenti, hogy ha egy hibát találunk, leállunk, és azt kijavítjuk, hanem azt is, hogy ha a fejlesztés teljes folyamata során bármilyen problémával találkozunk, akkor annak megvizsgáljuk a valódi okát, és azt orvosoljuk.
Pl. vki észrevesz egy szoftverhibát, ami azt indukálja, hogy kivizsgáljuk, miért találtuk az adott hibát a kérdéses modulban. Kiderül, hogy nem lett jól kitalálva (vízesés modellül megfogalmazva: specifikálva) a funkcionalitás. Ennek orvoslása millióképpen történhet, a projekttől függően. Pl. minden funkció előtt már szöveges (how-to-demo) forgatókönyveket írunk. Ezt ellenőriztetjük tesztelővel, üzleti elemzővel/ügyféllel, és csak utána kezdünk kódolni.
Ha egy jól működő szoftverfejlesztési folyamatról van szó, ahol nem söprik a problémákat a szőnyeg alá, és felmerülésükkör foglalkoznak vele, a problémák proaktív kezelése sok fejfájástól kímél meg a későbbiekben. (És a Toyota azt vallja, hogy ez meg is éri.) De ha csak “bután” vki a Stop the line! elvet akarja alkalmazni, és semmi mást nem változtat a szoftverfejlesztési folyamatán, csak azt, hogy ha szoftverhiba van, mindenki leáll, és a hibát kijavítja, akkor abba belebukik.
[Hibák priorizálása]
Amikor együtt dolgoztunk, láthattad Te is, hogy nagyon sok megtalált hibát bepriorizáltunk, és soha nem kerültek javításra (az alacsony prioritás miatt). Ennek az lett a következménye, hogy ezen hibák véletlenszerűen ki-kijönnek a valódi használat során (szerencsére ritkán), és foglalkozni kell velük. Ha akkor következetesen megvizsgáltuk volna, miért jelentkeznek ezek, és orvosoltuk volna a probléma gyökerét, akkor jobban állnánk. Véleményem szerint a legtöbb probléma abból adódott, hogy a szoftverben túl sok felesleges funkció lett kifejlesztve, és ezen funkciók annyira átláthatatlanná tették a szoftvert, hogy sok esetben nehezen lehetett már magát az elvárt működést is megfogalmazni. A probléma megoldása a megfelelő helyeken történő egyszerűsítés lett volna.
[Gyártás]
Igazad van abban, hogy a gyártástechnológiát nem szabad összekeverni a szoftverfejlesztéssel.
Az is igaz, hogy a Toyotának van beragadó gázpedálja, de ez számomra nem túl meglepő. Ha felidézed a post legelejét, már akkor leírtam, hogy helyes szoftver sem létezik. (Mint ahogy antennaproblémákban nem szenvedő IPhone4 sincs.)
Az egyetlen módszer, amiben hiszel, hogy mindig tesztelni kell az alkalmazást, nem firtattam, sőt. Attól viszont még lehet igaz a Stop the line! elv. De legalábbis törekedni mindenképpen lehet rá.
[Konklúzió]
A gond az, hogy kevesen vannak olyanok, akik a teljes folyamatot átlátják, és azon szeretnének optimalizálni. Legtöbbször van a fejlesztő, aki csak a unit tesztjeiben képes gondolkozni, és a tesztelő, aki meg azt hiszi, hogy majd a specifikáció alapján jól le kell tesztelni az alkalmazást. Ez önmagában kevés.
Ennél motiváltabb, és megújulni, tanulni képes emberekre van szükség.
Takács Ottó
Oct 5th, 2010A hibakezelés kényes téma, bár személyes kedvencem is. Alapműnek ajánlom Tom Gilb Evolutionarí Delivery-hez kapcsolódó könyvét. Ezen könyv és tudásanyag alapján nagyon jó cikkek is születtek http://www.malotaux.nl/nrm/English/WrkSlds.htm oldalon. Szépen sorban olvassátok el. Roppant hasznos.
Mi is az EVO? Még az Agile mint informatikai fogalom sem létezett és már akkor sikeres (nem csak informatikai) projekteket valósítottak meg ezzel. Olyan módszer, ami sokban kontrolláltabb, mint a scrum, de sokban lazább is. Tapasztalatom szerint nagycéges környezetben, olyan ügyfélnél, aki nem ismeri az agilis elveket jobban megvalósítható. Képzeld el, mint minden agile módszer nagyapja :)! (Tom Gilb-re több Agile könyvben is aktívan referálnak, bár ritkán emelik, ki, hogy ő már a 80-as években ilyen módszerrel dolgozott (sokunk akkor még meg sem született
)
Marhefka István
Oct 5th, 2010Köszi a tippet, olvasni fogok.
Az én véleményem a hibák kezelésének kapcsán az, hogy igazából itt csúcsosodik ki minden probléma, amivel a szoftverfejlesztéskor nagyvonalúan foglalkoznak. Meg merném kockáztatni: ha jó a hibák kezelése, akkor nagy baj nem lehet a szoftverfejlesztési folyamattal. (Itt most a hibákat tágabb értelemben gondolom. Tehát pl. azt is hibának tekintem, ha egy feature nem úgy működik, ahogy a felhasználó elvárja.)
Szabolcs
Mar 22nd, 2011Valójában ez egy Infiniti G37 Coupé.
Egy fontos tényező kimaradt a postból: a kedves fejlesztő addig tud zéró toleranciával hibát javítani, amíg ki nem adta kezéből a munkát. Rosszul is nézne ki, ha a vadi új fejlesztést ismert hibákkal adná át. Onnantól azonban a kedves megrendelő dönti el, hogy az általa feltárt hibák/hiányosságok/csúfságok közül melyiket éri meg neki javíttatni.