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

Elkészül a szoftver, elküldjük az ügyfélnek, aki azonnal egy rakás hibát küld vissza. Ezeket kijavítjuk, elküldjük az új verziót, mire megint egy rakás hiba jön vissza. Beindul a tenisz, csúszik a projekt, és mindenki a másikat okolja.

Elkészül a szoftver, elküldjük az ügyfélnek, aki azonnal egy rakás hibát küld vissza. Ezeket kijavítjuk, elküldjük az új verziót, mire megint egy rakás hiba jön vissza. Beindul a tenisz, csúszik a projekt, és mindenki a másikat okolja.

Habár konkrétan nem szerepel a fejlesztési módszertanokban, de létezik egy úgynevezett stabilizációs fázis a szoftverfejlesztés során. Ez az a fázis, amikor már funkcionálisan elkészült a szoftver, de még nem elég jó ahhoz, hogy élesbe át lehessen adni. A stabilizációs fázis során hibák javítása zajlik. A „hiba” sokféle lehet: szoftver bug-tól kezdve tervezési hibán át rossz specifikáció, félreértés, új ötletek.

Ez az egész olyan, mint ahogy a repülő dugóhúzóba kerül. Egyre több hibát jelent be az ügyfél, amikre egyre gyorsabban válaszol új release-zel a fejlesztő, amiket az ügyfél aztán csak addig tesztel, hogy találjon megint 15 hibát és visszadobhassa azt. Az együttműködés helyett verseng lesz, ahol a felek egymás ellen dolgoznak és a szoftverrel teniszeznek. A viszony egyre rosszabb lesz, egyre kevesebb a hasznos munka és egyre több a politika. A meeting-ek hangvétele egyre rosszabb. Megindul az ujjal mutogatás, a fenékvédés és a helyezkedés.

Hogyan lehet egy a dugóhúzóból kirántani a gépet és simán landolni a célállomáson?

Úgy nem, ha jobban teniszezünk. Ha a labdát erősebben és gyorsabban átlőjük a másik térfélre, akkor erősebben és gyorsabban fogják visszalőni. A megoldás az, ha kilépünk a teniszjátszmából és rendbetesszük a projektet.

Hogyan lehet a teniszezést leállítani?

A teniszjátszma „üzemanyaga” a szoftverben szereplő hibák. Ha nincs üzemanyag akkor nincs teniszezés. Nem szabad olyan szoftververziót átadni az ügyfélnek, amiben hibák vannak, ami nem elég jó. A legtöbb esetben erre azért kerül sor, mert szorít a határidő és követelőzik a menedzsment – na ezt kell figyelmen kívül hagyni. Nem szabad feláldozni a projektet rövid távú sikerekért.

Hogyan lehet elfogadható szoftvert elállítani?

Úgy, hogy a QA funkciót nagyon komolyan vesszük. A szoftvert átadás előtt nagyon alaposan le kell tesztelni – ami azt feltételezi, hogy létezik egy részletes teszt terv, és megfelelő szándék annak végrehajtására.

A részletes teszt terv azt feltételezi, hogy a szoftverrel támasztott követelményeket pontosan ismerjük.

És van itt még egy dolog: az ügyféllel meg kell egyezni abban, hogy mit nevezünk elfogadható szoftverrel. Ha az ügyfél oldali tesztelés célja az, hogy minél több hibát találjanak, az nem tesztelés. És ha hibát is találnak, az nem feltétlenül jelenti azt, hogy a szoftvert nem lehet elfogadni. Ezeket előzetesen jó alaposan át kell beszélni, és megállapodni a részletekről.

Hogyan lehet a megőrizni az ügyfél bizalmát?

Csakis úgy, ha bízhat bennünk. Ha megcsinálunk mindent, amit ígértünk, és nem teszünk felelőtlen ígéreteket. Ha nem teszünk le egy félkész szoftvert az asztalra pusztán azért, mert jön a határidő. A trükkök duplán ütnek vissza.

Hogyan lehet egyensúlyozni a határidő és a minőség között?

Amikor abba a helyzetbe kerültünk, hogy választani kell a kettő között, akkor már késő. A megoldás kulcsa a megelőzés: legyen egy előzetes tervünk arra nézve, hogy teljesül mindkettő – egy igazi, megvalósítható, reális terv.

Az előre gondolkodás és a jó tervezés a kulcs. Viszont ahhoz, hogy előre tudjunk gondolkodni és jó tervezni, ahhoz tudásra és tapasztalatra van szükség.

Mit lehet csinálni, ha már válság van, és azonnal kell a megoldás?

Csodák nincsenek. Ha elszabadultak az indulatok és a projekt elsüllyedt a stabilizációs fázisban, abból csak úgy jöhetünk ki, ha újratervezzük a projektet. Le kell állítani a munkát (a teniszezést), és új, valós tervet kell csinálni. Ami azt jelenti, hogy vissza kell menni a fejlesztés korábbi szakaszába, és újracsinálni azt, ami nem lett megcsinálva. Ez értelemszerűen csúszást jelent (a projektet kvázi le kell állítani egy időre), de egy kis csúszással még mindig hamarabb lesz kész a szoftver, mint az elhúzódó teniszezéssel.

Ha elúszik a projekt a stabilizációs fázison, akkor azért ki visel jogilag felelősséget?

Amikor a felek szerződést böngésznek és jogásszal konzultálnak, akkor már késő. Ha meg akarnak állapodni, akkor tudomásul kell venni, hogy mind a Beszállító, mind a Megrendelő kénytelen veszteséget elszenvedni. A Megrendelő azért, mert nem készült el a szoftver, amit várt, és mert az üzleti szakértőinek tovább kell a projekttel foglalkoznia. A Beszállító azért, mert ugyanazért a fizettségért sokkal tovább kell dolgoznia (a programozókat fizetni kell hónap végén).

Meg tud-e bukni végérvényesen egy szoftverfejlesztés a stabilizációs fázisban?

Igen. A stabilizációs fázis az, amikor az ügyfél először találkozik a szoftverrel, és szembesül annak minőségével. Ha ez nagyon messzire van az elvárásoktól, akkor az járhat a projekt törlésével.

Éppen ezért kell nagyon alaposan megismerni az elvárásokat, és még a release előtt megismertetni a megrendelőt a szoftverrel, például képernyőtervek készítésével, prototípussal, vagy agilis fejlesztéssel.

Címkék: szoftver qa stabilizálás

A bejegyzés trackback címe:

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

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.

Viktor 2012.01.25. 11:02:34

"követelőzik a menedzsment – na ezt kell figyelmen kívül hagyni" beszélek is mindjárt a főnökömmel :-)

Ismeretlen_102125 2012.01.29. 14:18:23

@Viktor: Tudom hogy vicces volt a megfogalmazás. Azonban a nagy és látványos bukások abból szoktak adódni, amikor a vezetőség nem hajlandó engedni vagy megérteni a nyilvánvaló igazságot ("failure is not an option").

Viktor 2012.01.30. 10:29:00

@akocsis: persze, világos, meg tudom pontosan, hogy ezek a dolgok hogyan mennek ( most is éppen van a látótávolságomban ilyen ), csak ezt a magas labdát nem lehetett kihagyni :-)
süti beállítások módosítása