HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

Szoftvert fejlesztünk vagy hibákat javítunk?

Szoftvert fejlesztünk vagy hibákat javítunk?

Egy – sajnos - nagyon széles körben elterjedt antipatternről szeretnék ma írni. Szoftverfejlesztési szerződésekben szokott lenni egy rész, ami a szoftver elfogadását definiálja – azaz mikor mondható az, hogy a szoftver kész, lehet küldeni a számlát, és mindenki elmegy jól megérdemelt nyaralására a Bahamákra.

Tipikusan ezek a bekezdések a hibák számával definiálják a minőséget. Itt van például ez a szerződés, tessék megnézni a 2. oldal 12-es pontot:

Az elfogadási teszt akkor sikeres, ha a tesztelés során kritikus hiba nem merül fel, és a súlyos (de a rendszer működését alapvetően nem gátló) hibák száma nem haladja meg a 3 darabot, valamint a kis hibák száma a 10 darabot.

Első ránézésre jónak tűnik, mi ezzel a baj?

Hát az, hogy tönkreteszi a projektet, több módon is:

1) Értelmetlen teniszezés: A stabilizációs fázis stabilizálása cikkben már említettem, hogy amikor átadjuk a szoftvert, akkor az ügyfél és a beszállító teniszezni kezd: az ügyfél megnézi a szoftvert, talál benne egy csomó hibát, visszadobja, a programozók kijavítják a hibákat és küldenek egy új verziót, amit az ügyfél újra megnéz, talál benne egy csomó hibát, visszadobja… és ez megy a végtelenségig. Közben mindenki egyre idegesebb lesz, újabb és újabb határidők dőlnek meg, a vezetőség egyre hangosabban kiabál, a beosztottak stresszelnek, egymást követik az értelmetlen meeting-ek.

2) Az ügyfél és a beszállító ellenséggé válnak: A szoftverfejlesztés csak úgy tud működni, ha az ügyfél és a beszállító is közösen dolgozik a közös cél érdekében. Viszont ha az elfogadást a hibák számához kötjük, akkor a közös célból hirtelen ellentétes cél lesz: az egyik fél minél több hibát akar megtalálni, a másik minél kevesebbet. Megbomlik az együttműködés.

3) Mikor lesz valóban kész a szoftver? A szoftver akkor van valóban kész, ha teljesíti az eredeti célt. Például egy értékesítési szoftver akkor kész, ha lehet vele értékesíteni. Ez teljesen független dolog attól, hány és milyen hiba van benne. A szoftvert akkor kellene elfogadni, amikor a célját ellátja. Ezt igazából jól megtervezett teszt esetekkel lehet ellenőrizni.

4) Az ügyfél felelőtlensége: Az elfogadási teszt fenti definíciója azt sugallja, hogy az ügyfélnek nincs feladata és felelőssége az elfogadási teszt során, az teljes mértékben a beszállító ellenőrzése. Márpedig ennek az ellenkezője igaz: ahhoz, hogy az ügyféle valóban meggyőződhessen a szoftver megfelelőségéről, ahhoz sokat kell dolgoznia. Megfelelő teszt esetekkel készíteni, kompetens szakértőket hoznia, teszt környezetet előállítani, és azokat a teszt eseteket valakinek végre is kell hajtani. Ez munka, sok munka. Ha az ügyfél nem így tesz, akkor nem fog tudni meggyőződni a szoftver „jóságáról”.

5) Pánik: Talán meglepő lesz, de ha a minőséget a hibák számával definiáljuk, akkor az pánikot okoz. Ugyanis az teljesen normális, hogy egy szoftver az átadás előtt még tele van hibával. Az átadás előtti időszak stabilizációval telik, nagyon intenzív hibajavítás. Egy kezdeti szoftververzió – ahol már a funkciók megvannak, csak nem stabil - sok súlyos hibát tartalmaz. Ezen megijedni annyira jogos, mint azon, hogy este lemegy a nap és sötét lesz. Az ügyfél viszont tipikusan nem IT-s, ők megijednek attól ha kiderül, hogy van még 10 súlyos hiba a szoftverben. Pedig ez lényegtelen, hiszen az átadásra majd ki lesznek javítva. Az efféle információk csak arra jók, hogy mindenki jól megijed. Főleg a felsővezetés.

6) Hibamentes szoftver nincs: Klasszikus IT-s mondás, és igaz. Bármilyen tetszőleges szoftverben van hiba, legfeljebb nem tudunk róla, vagy nem volt elég időnk tesztelni, hogy megtaláljuk. Ilyen értelemben a 3 súlyos hiba relatív: ha akarom, keresek a szoftverben 3 súlyos hibát, ha akarom, akkor nem keresek és elfogadom.

7) Nem objektív: Hiába tűnik objektívnak a definíció, valójában objektív. Ahogyan az előbb írtam, a 3 súlyos hiba relatív. Ha az ügyfél akarja, addig keres hibákat, amíg talál. És az is előbb-utóbb szubjektív lesz, hogy mi a súlyos hiba. (pl súlyos hiba-e, ha a nyitóképernyő nem követi a cég vizuális megjelenését?) És innentől kezdve csak a jóindulatán múlik, hogy a szoftvert átveszi-e vagy sem.


Hogyan lehet ezt jól csinálni?

A megrendelő kötelezettségei közé fel kell venni a tesztesetek készítését. A szoftver minőségét a tesztek lefutásához kötni. Az elfogadási kritérium az legyen, hogy a tesztesetek hiba nélkül végrehajthatóak legyenek, vagy legalábbis bizonyos mennyiségű hibával (pl. fontos tesztek súlyos hiba nélkül, a nem fontosak közül max 3 lehet failed).

Most valaki mondhatja azt, hogy ha egy teszt eset nem hajtható végre, az ott súlyos hiba, tehát a két definíció ugyanaz: a szoftver akkor fogadható el, ha nincsenek benne hibák.

Ez a gyakorlatban nagyon nem igaz! És csak amatőrök gondolhatják azt, hogy ugyanaz!

A legfőbb különbség a két definíció között az, hogy a tesztgyűjtemény objektívan leírja, mit várunk el a szoftvertől, miközben hiba bármi lehet. Ha a szoftverrel kapcsolatos elvárások megfoghatóak, akkor azoknak sok munka árán eleget lehet tenni. Nem fog előfordulni, hogy a programozó kijavítja az összes megtalált hibát, mire az ügyfél küld egy új hibalistát.

A másik nagy különbség, hogy az ügyfél rá van kényszerítve az elfogadási teszt előkészítésére, és ezáltal arra, hogy átgondolja az elvárásait és formalizálja azokat. Lesz egy közös nevező (a teszteset gyűjtemény), ami alapján mind a két oldal tud dolgozni. A közös nevező közös munkát és együttműködést eredményez.

A harmadik érv pedig az, hogy míg a hibák száma egy aktuális információ és relatív, addig a sikeresen lefutott tesztesetek száma pontosabban megmondja, milyen messze vagyunk a kész szoftvertől. Például ha 100 tesztesetből 90 lefutott és 10 nem, akkor tudjuk, hogy azzal a 10-zel kell valamit csinálni, de amúgy közel vagyunk a célhoz. De ha a szoftverről azt tudjuk, hogy 30 hibát találtak benne, akkor most az messze van-e a késztől vagy közel?

Ha a végén a megrendelő a hibák ellenére is átveszi a szoftvert, akkor pontosan tudni fogja, hol kell megalkudnia és mi az, amit a szoftver biztosan tudni fog.


Miért írnak ilyen szerződéseket, ha ez ennyire rossz?

Mert kicsiben még működik. Amíg a szoftver kicsi és egy ember átlátja, addig nincs feltétlenül szükség tesztesetekre és addig elég jól lehet dolgozni a hibaszámmal. És mert a hibákon lehet vitatkozni – meggyőzni az ügyfelet, hogy az úgy jó. Az ügyfél is inkább a hibák számával definiálja a minőséget, hiszen így nem kell teszteseteket készítenie.

Az ügyvédek is örülnek ennek a definíciónak, hiszen könnyen leírható és könnyen számonkérhető. Ha fel akarunk mondani egy beszállítónak, elég lesz 4 súlyos hibát összegyűjteni.

 

Egy gondolat a végére: itt gyakorlatilag szemléletmódról van szó. Ha hibákat számolunk és hibajavítások után futunk, akkor a jelenre összpontosítunk és csak reagálunk az eseményekre. Ha tesztesetek, használati esetek alapján mérünk, akkor ott a specifikáció kerül fókuszba és a végső elfogadásra készülünk fel, tehát  jövőre összpontosítunk a jelen helyett. Reaktív helyett proaktív hozzáállás.

Címkék: hibák szerződés antipattern

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr465211803

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.

Cece 2012.02.11. 20:19:03

A végső átadás, ha addig a megrendelő nem is látta a szotfvert, eleve rosszul hangik. Iteratív fejlesztés és funkciónkénti folyamatos átvétel, ami tud működni. Ehhez még nem feltétlen kell scrumban gondolkodni.

Ismeretlen_102125 2012.02.12. 14:14:13

@Cece: A végső átadással elsősorban nem az a gond, hogy akkor látja először a megrendelő a szoftvert, hanem az, hogy akkor rá van kényszerítve egy döntésre. El kell döntenie, hogy átveszi-e a szoftvert vagy sem. Ha az átadás feltétele a hibák száma, akkor neki fog állni hibákat keresni teljes erővel. Nem meri felvállalni a döntést.

takacsot · http://www.qualityontime.eu 2012.02.14. 15:57:06

A hibák súlyosságában szubjektív volta soha sincs elég erősen kiemelve. Kedvenc tapsztalatom (mind a fejlesztők, mint a menedzsment belefutott már). Adott a rendszer, ami nyomtatványokat is készít. ha van a nyomtatványon egy (egyébként konstans) szöveg, ami hibás, akkor azt hova soroljuk? Ha nettó munkát (kb 1 perc) nézzük, akkor enyhe. De ha az a szöveg egy jogi formula, ami, ha kikerül a nagyvilágba, akkor az ügyfél jogilag felelőssé válik (egy szerződés) akkor már nagyon súlyos hibáról beszélünk. A gond az, hogy az ügyfelek is sokszor elbagatelizálják a fenti problémát és az éles rendszer indulás előtt még röpködnek a pániklevelek, hogy a nyomtatványok fix szövege nem jó (csak most nézte át a jogi osztály - még időben :) )

Kutya23 2012.02.27. 09:56:07

Ezzel a megközelítéssel nem fordul-e meg a dolog, hogy a fejlesztő csak és kizárólag a felhasználói tesztesetekre kezd el koncentrálni, hiszen ez méri a munkája minőségét?

Viktor 2012.02.27. 12:51:17

"akkor azt hova soroljuk?" szerintem egyértelmű. Üzleti hatás alapján kell priorizálni. Vagyis ez egy súlyos hiba lehet ( ha a szövegben akkora hiba van ).

Hesz Roland 2012.02.27. 13:30:54

@Kutya23 Ha a fejlesztő felhasználói tesztesetekre koncentrál, akkor a program úgy fog működni, ahogy azt elvárják, hozza azokat az elvárásokat, úgyhogy ez miért gond?

Kutya23 2012.02.28. 09:42:47

@Hesz Roland Igen, de ha a teszteseteken kívüli hibák nem tartoznak a szerződés körébe, akár el is hanyagolhatóak, mivel a fejlesztő cégen múlik a prioritása. Ezért gondolom h valahogy mégis bele kellene tartoznia a mérőszámba.

Ismeretlen_102125 2012.02.28. 20:17:22

@Kutya23: Ha bármilyen szoftverfejlesztő cég nem akarja kijavítani az általa fejlesztett szoftver hibáit, akkor azt páros lábbal rúgják ki.

Kutya23 2012.02.28. 22:20:09

@akocsis Igen, persze, csak akkor nem ugyanott vagyunk, hogy mit írjunk a szerződésbe? :)

Ismeretlen_102125 2012.02.29. 20:45:11

@Kutya23: Nem vagyunk ugyanott. Kirúgni bármikor lehet rúgni egy beszállítót, de a szerződésbe lehetőség szerint tiszta és világos leszállítandók kerüljenek. Mert azokat valaki valamikor majd számon fogja kérni.
süti beállítások módosítása