Szemléletváltás a szoftverfejlesztésben

Insert title here

Szemléletváltás a szoftverfejlesztésben

A szoftverfejleszt?i szakma idestova három évtizede keresi a megoldást a fejlesztési projektek sikerességének növelésére. Elképzelések és elméletek hiányáról igazán nem panaszkodhatunk. Próbálkoztunk strukturált módszertanokkal ( Structured Systems Development, IDEF, SSADM) és objektumorientált módszertanokkal (OMT, Objectory, Catalysis, OPEN, Unified Process). A statisztikák szerint mindezek a törekvések nem váltották be a hozzájuk f?zött reményeket. Fejl?déstörténetünkben egy érdekes ciklikusság figyelhet? meg.

Kidolgoztunk egy szoftverfejlesztési módszertant, majd a sikertelenséget látván azt a következtetést vontuk le, hogy a fejlesztési folyamatunk nem elég pontos, részletes, jól szabályozott, tehát dolgozzunk ki egy precízebb módszertant. Így jutottunk el a Unified Process-ig, amelynek a leírása több mint 1000 oldal, a folyamat betartatásához, adminisztrálásához, az eszközök üzemeltetéséhez 2-3 f? szükséges. Tehát szoftverfejlesztésre nem igen marad már id?nk. Messzir?l nézve a történetet, úgy t?nik, mintha ezek a módszertanok gúzsba kötnék a projektet. Közelebbr?l nézve, azt állapíthatjuk meg, hogy egy alapvet? dolgot félreértettünk.

A szoftverfejlesztést a mérnöki tudományok közé soroltuk, közvetve feltételezve ezzel a tervezhet?séget, és szoros logikai következetességet. Egy precíz gépész és gyártástervez? valóban tud olyan tervet készíteni, amely alapján nagyon nagy biztonsággal a tervezett darabszámban, min?ségben és költséggel határid?re legyártható a termék. Csakhogy a szoftverfejlesztés nem gyártás! Mi mindig új terméket fejlesztünk! A mi alapvet? feladatunk az, hogy az üzletember fejében kipattanó üzleti gondolatot Java-ban, C#-ban valósítsuk meg.

Ez hatalmas kommunikációs feladatot jelent, és a gondolatok formalizmusában is jelent?s az eltérés. Ilyen körülmények között a gyártásban bevált elveket és módszereket használni? Botorság (volt). Ahogy Alistair Coockburn megállapította: „A szoftverfejlesztés találékonyságra és kommunikációra épül? kooperatív játék.” Újra kellett gombolnunk a kabátot, új alapelveket kellett lefektetni:

Kiáltvány az Agilis Szoftverfejlesztésért

Mi a jobb szoftverfejlesztés módjait fedezzük fel azáltal, hogy fejlesztünk és segítünk másokat fejleszteni. Ezen munkában értékesebbnek tartjuk:

Az egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél.

A m?köd? szoftvert, az átfogó dokumentációnál.

A megrendel?vel való együttm?ködést, a szerz?déshez való merev ragaszkodással szemben.

A változásra való reagálást, a tervek rigorózus követésével szemben.

...

Noha, fontosak az utóbbiak is, mi fontosabbnak tartjuk az el?z?eket.

Az agilis szoftverfejlesztés alapelvei

1. Legnagyobb prioritása a megrendel? igényeinek megfelel?, értékes szoftver korai és folyamatos átadásának van.

2. A követelmények változása elfogadott, még a fejlesztés kés?i szakaszában is. Az agilis módszertanok befogadják a változást a megrendel? versenyképességének érdekében.

3. Gyakran, néhány hetenként vagy hónaponként, kell m?köd?képes szoftvert átadni. A rövidebb periódust kell el?nyben részesíteni.

4. A megrendel?knek, üzleti szakembereknek és a szoftverfejleszt?knek naponta együtt kell dolgozniuk a teljes projekt során.

5. A projekteket motivált emberekre kell építeni. Meg kell teremteni a megfelel? környezetet, meg kell adni a szükséges támogatást, és meg kell bízni bennük, hogy megfelel? munkát végeznek.

6. Hatékonyabb módszer az információ átadásának a fejlesztési csapaton belül, a személyes beszélgetés.

7. A m?köd? szoftver az els?dleges mércéje az el?rehaladásnak.

8. Az agilis módszertanok el?segítik a fenntartható fejlesztést. A szponzoroknak, fejleszt?knek, felhasználóknak képeseknek kell lenniük a folyamatos sebesség meg?rzésére.

9. A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást.

10. Az egyszer?ség – az el nem végzett munkamennyiség maximalizálásának m?vészete – alapvet? érték.

11. A legjobb architektúrák, követelmények és rendszertervek az önszervez?d? csapatmunkából alakul ki.

12. A fejleszt?i csapat, rendszeresen id?közönként, megfontolja, hogy hogyan válhatnak hatékonyabbá és ennek megfelel?en finomítják viselkedésüket.

Ez volt 2001-ben. Mára az agilis szoftverfejlesztés mainstream szemléletté vált, módszerei átfogják a projektvezetést?l, a rendszertervezésen keresztül, a fejlesztésig terjed? hatalmas spektrumot.

A továbbiakban azokról a módszerekr?l szeretnék egy rövid áttekintést adni, amelyek az agilitás szemléletének jegyében születtek az elmúlt fél évtizedben.

A legismertebb agilis módszertanok

Agilis projektvezetés	Scrum, Lean Software Development
Rendszertervezés	Agile Modeling, Domain Driven Design
Fejlesztés	eXtreme Programming

Agilis projektvezetés

Az agilis projektvezetés szakítás a klasszikus projektvezetési elvekkel. Alapvet? felismerése az, hogy a klasszikus projektvezetés módszerei prediktív problémáknál - pl. gyártás – használhatók jól, de új termék fejleszt esetében –ilyen a szoftverfejlesztés is – a tapasztalati folyamatirányítási modellt kell alkalmazni. A tapasztalati (empirikus) folyamatirányítás a váratlan esemény bekövetkezését várja. Az irányítás gyakori vizsgálattal és adaptációval valósul meg, vagyis a pontatlanul definiált tevékenységeinket és eredményeit megvi

zsgáljuk, és ennek ismeretében definiáljuk a következ? tevékenységeinket. Drámai szakítást jelent a klasszikus felf ogással szemben a projekt meghatározó paramétereinek – id?, költség, min?ség, terjedelem - kezelése is. A klasszikus f elfogás szerint a projekttervezési szakasz célja éppen e négy paraméter meghatározása, majd a projekt „futtatása” és irányítása során a projektnek e korlátokon belüli megtartása. Új termék fejlesztésénél viszont a terjedelmet – a szoftver által biztosított funkcionalitást – el?re meghatározni lehetetlen. A terjedelem változhat! Az üzleti ötletek tipikusan nem Java-ban, C#-ban fogannak meg az üzletember fejében. A rendszerrel szembeni követelményeket sokkal pontosabban ismerjük a projekt végén, mint a projekt elején. Ha ez így van, márpedig így van, akkor olyan projektvezetési módszereket kell alkalmaznunk, amelyek adott keretekb?l – költség, id?, min?ség – a lehet? legnagyobb üzleti értéket produkálják a megrendel? számára.

Scrum

A Scrum iteratív és inkrementális fejlesztést valósít meg, a tapasztalati folyamatirányítási elveket érvényesíti:

Láthatóság Biztosítani kell a fejlesztési folyamatban, hogy azok a részfolyamatok és eredmények, amelyek befolyásolják a fejlesztés eredményességét, láthatóak legyenek a projektet irányítók számára. És nem csak pusztán láthatók, hanem igazak is.
Ellen?rizhet?ség A folyamatnak rendszeresen ellen?rizhet?nek kell lennie. A rendszeres ellen?rzés, vizsgálat el?feltétele a nem várt (nem tervezett) események miatti korrigálhatóságnak. Az ellen?rzés gyakorisága a nem várt események bekövetkezésének függvénye.
Adaptivitás Amennyiben az ellen?rzés, a célokhoz képest elfogadhatatlan mérték? eltérést talál, akkor fejlesztési módszernek lehet?séget kell adnia a korrekcióra, a kialakult helyzethez való alkalmazkodásra.

A fenti elvek részben a projekt életciklus révén, részben a projekt szerepek és felel?sségek kiosztása révén valósulnak meg. A projekt teljes id?tartamát egyenl? hosszúságú – 30 napos – iterációkra (sprintekre) bontja.

Az iterációk célja az úgynevezett Termék várólistában szerepl? elvárások egy részének megvalósítása. Egy meghatározott sprintbe kerül? elvárásokat az Termék tulajdonos és Scrum mester egyezteti, a Fejleszt?i csapat pedig elkötelezi magát a sprint célok megvalósítása mellett.

A Termék tulajdonos felel?s a termék várólista tartalmáért, a prioritások beállításáért és a lista nyilvánosságáért. A Termék várólista sohasem teljes. Amíg a termék létezik, addig a termék várólista is létezik, b?vül.

A Termék várólista úgy változik, ahogy a projekt bels? és küls? környezete változik. A Termék tulajdonos és a Fejleszt?i csapat közötti együttm?ködésnek az egyik legfontosabb szabálya, hogy a Termék tulajdonos bármikor változtathat a Termék várólistán – azaz a rendszerrel szembeni követelményeken – de a Sprint várólistán nem. Így biztosítható a változások befogadása és a stabilitás közötti egyensúly megteremtése.

További információk: http://www.scrumalliance.org/

Lean szoftverfejlesztés

A Lean szoftverfejlesztés a Lean Manufacturing, Lean Development adaptálása a szoftverfejlesztésre. Mary és Tom Poppendick ültette át más iparágak tapasztalatait a szoftverfejlesztés problémakörére. A Lean (szikár) gondolkodás Taiichi Ohno-tól - a Toyota mérnökét?l - ered, akinek az 1940-es évek végén azzal a problémával kellett megküzdenie, hogyan gyárthatnának kis sorozatban, de mégis olcsón autót a sz?k és alacsony vásárló erej? Japán piacra. Taiichi Ohno egy teljesen új gondolkodásmódot vezetetett be, amelynek a középpontjában a veszteségek kiküszöbölése állt. Onhno szerint mindaz veszteség, ami nem képez hasznot az ügyfél számára.

A megmunkálásra várokozó munkadarab veszteség.
Olyan tevékenységet végezni, amire akkor és ott nincs szükség, veszteség.
A mozgás, veszteség.
A szállítás, veszteség.
A várakozás, veszteség.
A feleslegesen elvégzett munka veszteség.

Mary Poppendick a következ?képpen ültette át a gyártásban jelentkez? veszteségeket a szoftverfejlesztésbe.

· Részben elvégzett munka

o A részben elvégzett munkákkal gyakran az történik, hogy elavulnak.

o A részben elkészített szoftverrel az a legnagyobb baj, hogy nem tudjuk m?ködni fog-e.

o A részben elvégzett fejlesztés leköti azokat az er?forrásokat, amelyeknek eredményt kellett volna termelni.

o Mi történik, ha a rendszer sohasem kerül felhasználásra?

o A részben elvégzett munka minimalizálása nemcsak a veszteség csökkentési stratégia, hanem kockázat csökkentési stratégia is.

· Felesleges folyamatok

o Elgondolkodott-e már valaha azon, hogy minden – jelenleg elvégzett - tevékenységre valóban szükség van? Például különböz? dokumentumok elkészítése.

o A felesleges munka lelassítja a válaszid?t.

o A felesleges – papírmunka – min?ségi problémákra utal.

o Annak a dokumentumnak, amelyet senki nem olvas nincs értéke.

o Jó tesztje a felesleges munkának, ha megnézzük, hogy ki vár az adott munka eredményére.

· Felesleges funkciók

o A dobozos szoftvere funkcionalitásának 60%-át egyáltalán nem vagy csak ritkán használják.

o Az egyedi szoftverek – visszacsatolás, iteráció hiányában – nem azt és nem olyan funkcionalitást biztosítanak, mint amire a megrendel?nek szüksége van.

o A fejleszt?k a „plusz” funkcionalitást gyakran el?nynek tartják. Pedig éppen fordítva, ez komoly veszteség. A felesleges funkcionalitást éppúgy, fordítani, integrálni, tesztelni, javítani kell mint a hasznosat.

· Feladatvállalás

o Az embereket párhuzamosan több projektben dolgoztatni veszteség!

o A feladatok közötti váltás, különösen innovatív területen - veszteséget okoz.

o Két, azonos er?forrásokon dolgozó projektet, egymás után a leghatékonyabb végrehajtani.

· Várakozás

o A szoftverfejlesztésben a legnagyobb veszteség bizonyos események bekövetkezésére várakozáskor jelentkezik. Várakozás a projekt kezdetére, a csapat összeállítására, a megrendel? válasz beérkezésére.

o A várakozás megakadályozza a megrendel?t a befektetésének gyors megtérülésében.

o A várakozás felesleges veszteséget termel a fejleszt?i oldalon is.

· Mozgás

o A szoftverfejlesztés kommunikáció intenzív tevékenység. Minél több mozgás szükséges az információcseréhez, annál nagyobb a veszteség. Az eXtreme Programming ezért javasolt egy helyen (szobában) foglalkoztatott fejleszt?i csapatot.

· Hibák

o A hibák okozta veszteség annál nagyobb, minél súlyosabb a hatása és minél kés?bb derül ki. A néhány percen belül felfedezett hibák okozta veszteség elhanyagolható, de a több hét múl, az üzemel? rendszerben jelentkez? hiba okozta veszteség óriási lehet.

További információk: http://www.poppendieck.com/

Rendszertervezés

Az agilis szemléletmód a rendszertervezés során a hatékonyságra való törekvés, a célnak megfelel? nyelv és eszközválaszban jelentkezik.

Az agilis modellezés

például az éppen elegend?en jó modell elkészítését t?zi ki célul, a szakterület vezérelt tervezés pedig – a sok lehetséges modell közül - arra a modellre koncentrál, amely a legjobban hasznosítható a fejlesztés során. Agilis modellezés Az agilis modellezés egy kaordikus (chaordic: chaos and order), gyakorlati alapokra építkez? modellezési és dokumentálási módszertan. Az agilis modellezés alapelvek és értékek által meghatározott praktikák gy?jteménye, melyeket a szoftverfejleszt? a napi munkájában alkalmaz. Az agilis modellezés nem el?író fejlesztési folyamat, nem tartalmaz részletes fejlesztési utasításokat pl. egy modell elkésztéséhez, hanem arról beszél, hogyan lehetünk hatékony modellez?k. Az agilis modellezés során nem kevesebbet, hanem többet modellezünk, de más szemlélettel. Az agilis modell:

megfelel a céljának,
érthet?,
elegend?en pontos,
elegend?en konzisztens,
elegend?en részletes,
a modellek egyenlege pozitív,
a lehet? legegyszer?bb.

Az agilis modellezés egyik legegyszer?bb, de mégis legfontosabb felismerése, hogy a táblánál alkotott modell is modell! Két célja van annak, hogy modellezünk. A modellezést egyrészt a probléma megértését segíti, másrészt a problémára adott válaszunkat dokumentálhatjuk modellek segítségével. A megértéshez b?ven elegend? a táblánál alkotott modell, amelynek „létrehozása” sokkal kevesebb befektetést jelent, mint a hagyományos modellez?eszközökben való modellalkotás.

További információk: http://www.agilemodeling.com/

Szakterület vezérelt tervezés

Eric Evans a Szakterület vezérelt tervezés (Domain Driven Design) c. könyvében az alábbi, nagyon fontos megállapítást tette: A szoftverfejlesztés során kétfajta komplexitással kell megküzdenünk. A komplexitás egyik forrása a támogatandó szakterület maga. Ma már nincs olyan szoftverfejlesztés, ahol a támogatandó szakterületi probléma, ne lenne önmagában is bonyolult. Ezt a nehézséget fokozza, hogy az a technológia (.NET. J2EE), amivel a megoldást szállítjuk, szintén bonyolult. Eric következtetése: A kétfajta komplexitást ne keverjük össze! Szoftvereinket olyan architektúrában valósítsuk meg, amelyben a szakterület bonyolultságát egyszer? objektumorientált nyelvi eszközökkel (Java, C#) oldjuk meg, technikai problémák megoldását pedig toljuk át más rétegekbe. Logikusnak hangzik, de még mindig nagyon sokszor nem ezt tesszük! A 4GL eszközök helytelen használata, tipikusan azt a fejlesztési attit?döt segítették el?, ahol az üzleti logika a felhasználói felület eseménykezel? m?veleteibe van elkenve. Vagy gondoljunk az üzleti logikának a tárol eljárásokkal való implementálására, ahol a perzisztencia technológiai problémáját mossuk össze az üzleti logikával.

Az a tény, hogy a szakterületi logikát tisztán objektumorientált nyelvi eszközökkel valósítjuk meg, egy további el?nyt nyújt. Nevezetesen érdemes a szakterület fogalmairól objektumorientált modellt – úgynevezett fogalmi modellt - készíteni. Érdemes, hiszen a fogalmi modell és a Java-s vagy C# implementáció között nincs tartalmi, csak formai eltérés.

Az objektumorientált fogalmi modell megjelenésével (kidolgozásával) egyúttal egy egyértelm? kommunikációs nyelvhez is hozzájutottunk. A szakterület vezérelt tervezés során a fogalmi modell képezi a megrendel? és a fejleszt? közös nyelvét. Ez óriási el?relépés két szempontból is. A klasszikus szabadszöveges fogalom meghatározáshoz képest az UML modell sokkal pontosabb, konzisztensebb. Ugyanakkor arról sem szabad megfeledkezni, hogy ezt a modellt a szoftverfejleszt? is érti, pontosan tudja, hogyan fogja megvalósítani.

A szakterületi modellre fókuszáló követelményspecifikálásnak van egy – nem elhanyagolható pozitív – következménye. A hagyományos követelményspecifikálás a szakterületi logikával szemben támasztott követelményeket tipikusan a felhasználói felület kontextusában fogalmazza meg. Azaz indirekt módon. Szakterület vezérelt tervezés során a szoftver rendszer legértékesebb és legid?állóbb részével szembeni követelmények közvetlen módon jelennek meg a fogalmi modellben. Ez segíti mind a megrendel?t, mind pedig a fejleszt?t a lényegre koncentrálni. A szakterület vezérelt tervezés természetesen nem jelenti azt, hogy a ne készíthetnénk használati eset, vagy tervezési modell, pusztán a hangsúlyok helyes megtalálásában segít.
A szakterület vezérelt tervezés nagyon komoly modellezési képességeket feltételez, és önfegyelmet az architektúrális szabályok betartásában. Amennyiben ez megvan, rendkívüli mértékben megnöveli a fejlesztés hatékonyságát. Magától értet?d?en Szakterület vezérelt tervezés során használjuk az Agilis modellezés módszereit.

További információk: http://www.domaindrivendesign.org/

Fejlesztés

Az agilis szoftverfejlesztés új szemléletének következményei legkorábban a fejlesztési technikákban jelentkeztek. Az összes agilis szoftver fejlesztési módszertan szakít a „szoftver gyártás” metaforájával és az önszabályozó csapatmunkára, egyedi szakértelemre, együttm?ködésre és hatékony kommunikációra helyezi a hangsúlyt.

eXtreme Programming

Az eXtreme Programming egy teljes kör? – agilis projektvezetést, rendszertervezést, fejlesztést és tesztelést magában foglaló – módszertan, de a mai gyakorlatban a korábban említett módszertanokkal együttesen szokták alkalmazni. Az eXtreme Programming nemcsak a nevében radikális, hanem a módszereiben is. Különlegessége éppen abban rejlik, hogy markáns, de egymásra épül?, egymást er?sít? szabályokat fogalmaz meg:

Dolgozz együtt az ügyféllel.
A bonyolult koncepciókat írd le metaforával.
Tervezz.
Legyenek rövidek a megbeszélések.
El?bb tesztet írj.
Egyszer? megoldásra törekedj.
Párban programozz.
Alkalmazz kódolási szabványt.
A kód mindenkié.
Folyamatosan integrálj.
Strukturáld át a kódot.
Kis egységeket bocsáss ki.
Ne égj ki (40 órás munkahét).
Fogadd be a változást.

Az XP elengedhetetlen összetev?je a fejlesztésben, teljes munkaid?ben, aktívan résztvev? ügyfél! A helyben foglalkoztatott ügyfél a fejleszt?kkel együtt valódi munkát végez.

? olyan személy, aki maga is potenciális rendszerfelhasználó, valamint képvisel?je más rendszerfelhasználóknak. Részt vesz a projekttervezésben, a felhasználói történetek (rendszerrel szembeni elvárások) definiálásában, valamint az elfogadási tesztek kidolgozásában. Az ügyfél az üzleti preferenciáit az elvárások prioritásának meghatározásával juttatja érvényre. Minden ellenkez? híresztelés ellenére az XP-s projektben is van rendszertervezés, de nincs hosszadalmas el?zetes tervezést, hanem a napi munkába épült be. Különlegessége az eXtreme Programming-nak azok a technikák, amelyek a csapaton belüli tudás gyors megosztását segítik el?. A páros programozás során egy feladaton két fejleszt? dolgozik, óránként cserélve a szerepeket. Az XP-s csapat a forráskódot közösen birtokolja, azaz bárki módosíthat a forráskód bármelyik részén. Ily módon nincsenek folyamatosan sz?k keresztmetszetet jelent? kizárólagos kód birtokosok. A csapat elkötelezettség vállalása és a tudás nivellálása szempontjából az sem elhanyagolható szempont, hogy a fejleszt?k jelentkeznek a feladatokra.

Az iteratív (id? alapú elszámolást feltételez?) fejlesztés egyik kényes pontja a megrendel?i bizalom megszerzése. Az XP a folyamatos integráció révén folyamatosan m?köd? – fejl?d? – szoftvert eredményez, azaz a megrendel?nek lehet?sége van bármikor kipróbálni a szoftvert, meggy?z?dni arról, hogy folyamatosan „értéket kap a pénzéért”. A folyamatos integráció egy másik következménye hogy a fejleszt?k rendkívül rövid id?n belül visszajelzést kapnak arról, ha az alkalmazás összeállítása sikertelen volt. A gyors visszajelzés következtében a javítási id? is lényegesen lerövidül.

További információk: http://www.extremeprogramming.org/

Teszt vezérelt fejlesztés

A teszt vezérelt fejlesztés valójában az eXtreme Programming-ban jelent meg el?ször, de mára szinte önálló „tudományággá” n?tte ki magát. A teszt vezérelt fejlesztés arra a felismerésre épít, hogy a teszt nem más, mint példa adatokkal ellátott specifikáció. Ha specifikáció, akkor a tesztnek kell el?bb meglennie, mint a tesztet kielégít? implementációnak. Ha a teszt specifikáció, akkor egyben dokumentáció is. Ha a tesztek futtatását automatizáljuk, akkor futtatható, a forráskóddal együtt fejl?d? dokumentációnk van!

A teszt vezérelt fejlesztési munkastílus tipikusan két résztvev?t érint. Az ügyfél et és a fejleszt?t. A rendszerrel szembeni elvárásokat az ügyfél – végs? soron – elfogadási tesztek formájában fogalmazza meg. Egy iterációba, csak olyan elvárások kerülhetnek, amelyekhez vannak elfogadási tesztek. Az elfogadási tesztek kidolgozása az ügyfél feladata és joga. Az automatizált elfogadási tesztek teremtik meg a megrendel? és fejleszt? közötti korrekt együttm?ködés alapját, hiszen a követelményspecifikációnak ez az a formája, amely lehet?ségekhez képest a legegzaktabb. Ha fejleszt? csapat olyan szoftver készít, amelyen az elfogadási tesztek lefutnak, akkor jó munkát végzett. A teszt specifikálásnak a megrendel?i oldalra való delegálásával azt is elérjük, hogy a megrendel? sokkal inkább tisztában lesz a kért funkcionalitás összetettségével, továbbá segít neki a saját elvárásait pontosan megfogalmazni.

A fejleszt? a forráskódot egy három lépésb?l álló, rövid ciklusban b?víti. Ír egy új elvárást megfogalmazó unit, vagy integrációs tesztet. Majd megírja azt az implementációt, amely a teszt sikeres lefutását eredményezi.

Végül változatlan elvárások – azaz tesztek – mellett úgy módosítja a kódot (refactoring), hogy az jobban strukturált legyen. Ezzel a munkastílussal, egyrészt az implementációval folyamatosan együtt fejl?d? automatizált teszt környezetet teremtünk magunk számára, másrészt a kód folyamatos átstrukturálása révén a megoldásunk, lépésr?l lépésre egy jobb architektúra irányába fejl?dik. A teszt vezérelt programozási stílusnak óriási el?nye, hogy a teljes kör? és automatizált teszt környezetnek köszönhet?en a fejleszt? biztonságban érzi magát, mer változtatni a forráskódon. Mer változtatni, hiszen ha megfeledkezett egy összefüggésr?l, a teszt csomag következ? futtatásakor – legfeljebb 1-2 órán belül – visszajelzést kap a hibáról. A hiba kijavításának költsége ily módon lényegesen kisebb, mint a klasszikus, utólagos tesztelés esetében.