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

Mi a cél és Mi az eszköz az agilis fejlesztésben?

Mi a cél és Mi az eszköz az agilis fejlesztésben?

Egy olyan triviális kérdés fogalmazódott meg bennem reggel, ami az agilis fejlesztés alapjait érinti: mennyire fontos az agilitás?

Mert ugye az agilis fejlesztési módszertanok kiinduló tézise, hogy a felhasználóknak agilitásra van igényük, a formális módszertanok ezt nem képesek nyújtani tehát új módszertanokra van szükség, stb stb.

Na jó, de valaki tényleg elgondolkodott-e azon, hogy mennyire fontos, mi az értéke a rugalmasságnak? Megkérdezte-e valaki az ügyfelét, hogy légy szíves csinálj egy 10-es listát, hogy mi fontos számodra? – aztán megnézzük, hogy az agilitást hányadik helyre teszi.

Csak azért, mert ilyen adatokat, felméréseket nem igazán láttam. Agilisan fejlesztő programozót viszont annál többet. Nem-e lehetséges, hogy az agilitás valójában eszköz, és nem cél? És hogy az agilis fejlesztés csak kalapács lett a mindenhol szöget kereső fejlesztők kezében?

Arra kérném a kedves Olvasókat, hogy osszák meg véleményüket. Akkor is, ha egyetértenek, és akkor is, ha egyáltalán nem.

Gondolatébresztőnek íme a saját tapasztalatom:

Ahol most dolgozok, a belső ügyfelem, az üzleti terület amit kiszolgálok, eléggé változás-intenzív. Az üzleti igények és a folyamatok állandóan változnak. Mi kapjuk a legtöbb változásigényt és projektet, összehasonlítva más üzleti területekkel.
Megfogalmazott és kimondott üzleti igény a rugalmasság és az agilitás.

Mi formális módszertan szerint fejlesztünk, ezért a kulcsfelhasználók morognak, hogy nem vagyunk agilisak.

De ha nem pontosan azt és nem pont úgy szállítottuk le, ahogyan azt kérték, akkor kiabálnak.

Ha pedig nem szállítunk az előre megbeszélt határidőre, akkor üvöltenek és eszkalálnak.

Tehát józanul végiggondolva, az ő listájukon az agilitás nem lenne első. Sőt igazából egész jól megvannak agilitás nélkül, ha hozzuk a tervet, és a terven belül biztosítunk némi rugalmasságot.
Pedig ez egy sokat változó üzleti terület – bele se merek gondolni, mi lehet a helyzet máshol.

Mint agilis, sok változással járó üzlet, van nálunk formálisan és agilisan fejlesztett szoftver is. Éppen ezért össze tudom hasonlítani a kettőt.
A fentiekhez képest az agilis fejlesztés abban tér el, hogy az nem tudja hozni a határidőket, rendszeresen összeomlik, és egyre több problémát okoz a rugalmasságot igénylő felhasználóknak.

Címkék: fejlesztés agile agilis

A bejegyzés trackback címe:

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

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.

Hesz Roland 2010.07.25. 18:56:20

"A fentiekhez képest az agilis fejlesztés abban tér el, hogy az nem tudja hozni a határidőket, rendszeresen összeomlik, és egyre több problémát okoz a rugalmasságot igénylő felhasználóknak. " akocsis, keresztre fognak feszíteni ezért a véleményért :))

Ismeretlen_102125 2010.07.26. 09:27:22

Elnézést provokatív voltam, véleményeket szeretnék látni :)

takacsot · http://www.qualityontime.eu 2010.08.12. 15:01:36

1. Agilitás fontos lehet az ügyfélnek, ha nem csak egy-egy aspektusát nézi. Pl. Agilitás egyik jellemzője, hogy gyakori releasek vannak és a kiadott releasek alapján visszajelzéseket ad, ami igen hamar meg is jelenik a rendszerben. 2. De az ára gyakran nem kell: magasabb fejlesztési költségek, hiszen a gyakori változtatások több járulékos költséggel is rendelkezik, amit már nem akarnak megfizetni. 3. Ügyfél félre van tájékoztatva, hogy mi az agilitás. lényeg: A z ügyfél minden előnyt akar annak hátrányai nélkül. DE: ha kiszámítható ütemben, kiszámítható gyakoriságban, kiszámítható minőséget hozol, akkor az ügyfél csak vár ér élvezi az életet. De ez már a win-win egyességek kategóriája, amiben mi Magyarok nem vagyunk erősek :)

Zsuffa Zsolt · http://www.itkodex.hu 2010.08.15. 22:22:22

Bár a címben megfogalmazott kérdés jó, az arra adott válaszokban több félreértés is megbúvik. Mielőtt még ezekre rátérnék, szeretném arra azt a kérdést felvetni, hogy a szerző miért nem keresi arra a választ, hogy a fejlesztők milyen előnyöket látnak az agilis fejlesztésben? Ha nekik előnyös, miért nem előnyös a projekt számára? A kiindulópont még rendben van: „Az agilitás olyan adottság, amely egyaránt képes létrehozni új dolgokat és reagálni a változásokra.” Jim Highsmith. Elvben, annak az ügyfélnek, aki nem akar reagálni a változásokra, nem akar új dolgokat létrehozni, nincs szüksége agilitásra. Mint azt a szerző maga is alátámasztja a mai üzleti világban ilyen személy, szervezet nemigen létezik. A "Na jó, de valaki tényleg elgondolkodott-e azon, hogy mennyire fontos, mi az értéke a rugalmasságnak?" kérdés egy kisség félrevezető, ugyanis nem általánossában fontos a rugalmasság, hanem azért, hogy a projekt a legnagyobb üzleti értéket biztosíthassa. Szerintem azt kell megkérdezni az ügyféltől, hogy mennyire fontos számára a befektetett pénzének megtérülése. Szeretne-e minél magasabb megtérülési arányt? Mennyit szeretne olyan tevékenységekért fizteni, amelyeknek nincs számára üzleti értéke. Az agilis szoftverfejlesztéssel kapcsolat legmakacsabb félreértés, hogy a rugalmasság, a változásokra való reagálás az egyben határidő csúszást, kaotikus fejlesztést jelent. Ennek éppen az ellenkezője az igaz. Az idő és a ráfordítás - definíció szerűen - fix, a szkóp szigorú szabályok által menedzselt! Ha "összeomlik", akkor legtöbbször azért, mert a felek nem tartják be a játékszabályokat. Mellesleg érdemes ezeket a szabályokat szerződésben rögzíteni, belső fejlesztés esetén pedig felső vezetői támogatást szerezni hozzá. Van egy fontos kérdés, amiről gyakrak megfeledkeznek az érintettek, ügyfél fejlesztő egyeránt. A szoftverfejlesztés új termék fejleszés, azaz szükségképpen egy fejlődési folyamat. Ha fejlődési folyamat, akkor ott változás is van! Mind az ügyfélben, mind pedig a fejlesztőben fokozatosan alakul ki, hogy milyen szoftvert szeretne. Nem lehetséges olyan követelményspecifikációt készíteni, amely 100%-ban meghatározná a végterméket. Ellenőrzésképpen: még egy lefordított, telepített alkalmazásban is vannak, lesznek, ELŐRE NEM LÁTOTT - hibák. Következésképpen minden olyan fejlesztési módszertan, amelynem nem szerves része az önkorrekció, az adaptivitás, nem megfelelő (adekvát) a szoftverfejlesztéshez. Amennyibe még nem sikerült meggyőznöm a kollégákat, olvasókat további érveket igyekeztem felsorolni egy könnyen emészthetőnek szánt írásomban: http://www.itkodex.hu/Hungarian/Frameset.html#Articles/StoryOfConservativeCustomerAndAgileDeveloper.html

Ismeretlen_102125 2010.08.16. 10:31:35

A kérdéssel a határokat kívánom kitapogatni. Nyugodtan átírhatjuk a kérdést: Mi biztosítja a nagyobb üzleti értéket? A) Az előre lefektetett igények megvalósítása B) Határidő betartása C) Reagálás a változásokra Szerintem a fontossági sorrend az itt említett, azaz A, B majd C Az összeomlásról majd lesz egy komolyabb előadás - meghívás esetén akárkinek - ugyanis az agilis fejlesztési projektek szükségszerűen magukban hordozzák az összeomlás kockázatát.

Ismeretlen_102125 2010.08.16. 13:10:05

Megnéztem linkelt írást, és vannak benne kérdéses pontok: 1) Az írást azt sugallja, hogy az ügyfél oldal 1 azaz egy személyből áll. Ez kkv esetében igaz is lehet, nagyvállalatnál biztosan nem áll meg. Több különböző szakterülettel és funkcióval kell egyeztetni, és azok az egyeztetések nem úgy fognak kinézni, ahogyan azt a leírás sugallja. 2) A beszerzők nem a leírtak szerint szoktak gondolkodni. Szükség van egy szoftverre, tehát ajánlatokat kell rá kérni, amiket összehasonlíthatóvá kell tenni. Semmiképpen nem fognak továbbengedni egy olyan vállalkozót, aki nem vállalja be a teljes scope-ot, de T&M alapon számlázna - nekik kész szoftver kell, nem mérnöknap. 3) A jogi osztály bele fogja akarni írni a szerződésbe, hogy mik a leszállítandók/átadandók, azaz mikor van kész a projekt. Ez idális esetben "1 darab szoftver, ami a melléklet szerinti funkciókkal bír" - a melléklet pedig nem más, mint az előzetes követelmény-specifikáció. 4) Valóban vannak esetek, ahol T&M alapon lehet fejleszteni, de ha projekt alapon dolgozunk, akkor annak keretei adottak. A projek-szerű működés miatt az igények, a költség és a határidő adott, ezeket kell teljesíteni. Ha ebédre húslevest akarok enni, akkor csak az fog érdekelni, elkészül-e a leves a megvásárolt alapanyagokból addigra, mire éhes leszek. Felesleges 10 percenként kostolgatni. 5) Mi van, ha az elején azt a kijelentést tesszük, a szoftver leszállítható 6 emberrel fél év alatt? Bele fog kerülni a szerződésbe. Mi lesz, ha köckázatmenetesen agilisen haladunk, az ügyfélnek ötletei lesznek, a projekt kissé félremegy, eltelik a fél év, és a szoftver hiányosságokat mutat az eredeti követelménylistához képest? Nyilván a szoftverfejlesztő cég számára kényelmes lesz rámutatni, hogy de hiszen 2 hetente megmutatta a szoftvert, és az ügyfél azt elfogadta... az ügyfél oldalon azt az embert ki fogják rúgni... Akkor ez most kinek az érdekeit védi, kinek a kockázatát csökkenti?

Zsuffa Zsolt · http://www.agilerenovation.com 2010.09.08. 05:23:54

5. "az agilis fejlesztési projektek szükségszerűen magukban hordozzák az összeomlás kockázatát" Természetesen bármelyik projekt összeomolhat, de ha szükségszerűségről és a módszertanba kódolt lehetőségekről beszélünk, akkor ez éppen fordítva igaz. Ezt szerintem igen egyszerű belátni: a) A klasszikus projektvezetés módszerei, technikái a - nagy - gyártó cégek módszerei alapján alakultak ki. Alapvető feltételezése, hogy a projekt (gyártmány, gyártás) eredménye előre tervezhető. Megbízhatóan tervezhető. b) A szoftverfejlesztés viszont ÚJ TERMÉK FEJLESZTÉS. Ez azt jelenti, hogy a feladat jellegéből fakadóan nem tervezhető, legalábbis nem úgy, és nem olyan pontosan ahogy egy gyártási folyamatot meg lehet tervezni. Új termék fejlesztés esetén a projekt végére érünk el a végleges és pontos specifikációhoz. Ha gyártani kell (szoftver esetében ennek nincs értelme), innen indulhat a klasszikus projektvezetés. Röviden: Ha új termék fejlesztést, pl. szoftver fejlesztését, a gyártási projektekre kidolgozott klasszikus módon tervezzük menedzseljük, abba eleve kódolva van a bukás. A "Fordítva a lovon" http://www.itkodex.hu/Hungarian/Frameset.html#Publications/Articles/ReverselyOnTheHorseback.html c. írásomban is ezt próbáltam meg kifejteni. Érdemes ránézni a statisztikákra is: http://www.itkodex.hu/Hungarian/Frameset.html#Publications/Articles/ParadigmChangeInSoftwareDevelopment.html. Ha jól értelmezem a számokat :-) éppen az előbbi állításomat igazolják.

Ismeretlen_102125 2010.09.17. 13:17:45

Teszt megjegyzés

Ismeretlen_102125 2010.09.17. 13:19:08

Zsuffa Zsolttól elnézést kérek a blogmotor nevében, amiért hozzászólása ideiglenes elveszett a mátrixban.

Ismeretlen_102125 2010.09.17. 19:02:18

Mint autóiparban dolgozó menedzsernek, érdekes az elgondolás, hogy új termék fejlesztése nem tervezhető. Ha ez igaz lenne, akkor nem lehetne új modelleket gyártani, és úgy összességében az autógyártás nem létezne. Éppen 3 új modell indításához van közöm, és ha valamikor személyesen találkozunk, akkor elmondom hogy is megy ez. A klasszikus módszerek köszönik szépen, jól működnek.

Zsuffa Zsolt · http://www.itkodex.hu 2010.10.19. 23:32:22

Arra tényleg nagyon kíváncsi vagyok hogyan lehet pontosan ugyan azokkal a projektmenedzsment módszerekkel, tervezéssel, ütemezéssel, erőforrás gazdálkodással 1db új modell megtervezni, illetve a megtervezett új modellt 100 000 példányban legyártani. Várom a személyes találkozót :-)

Fabók Zsolt · http://zsoltfabok.com 2011.01.09. 19:15:37

Csákó, David J. Andersonnak van egy jó példája az alap kérdésre (LESS 2010 Helsinki). Amikor pizzát rendelsz, akkor nem igazán érdekel, hogy a gyártó cég milyen módszerrel készíti el a pizzát (Anderson projekt management szempontból közelíti meg a problémát, de nagyon jól illeszkedik szerintem az agile/nem agile témakörre). Az érdekel, hogy időben megkapd és jó mínőségben. Ezt az elvárást át lehet ültetni a szoftverfejlesztésre is, azaz én, mint ügyfél, azt várom el, hogy amit kérek időben kész legyen és jól működjön (hiba mentesen, az amit szerettem volna). Ha ügyfélként, valamennyire jártas vagyok az iparban, és ismerem az agile módszertanokat, akkor olyan új partnert választok, aki ezeket követi, mert nagyobb valószínűséggel teljesülhetnek az elvárásaim. Az _új_ szót és a feltételes módot azért tartom fontosnak, mert az agile megjelenése előtt és hagyományos módszertanok használatáva is készültek/készülnek jó és használható szoftverek. Összefoglalva, az ügyfelet a legkevésbé sem érdekli a módszertan - lásd pizza rendelés példa. Ha jól vannak alkalmazva, akkor az agile elvek és módszertanok segítenek, hogy a partner ügyfélkapcsolat jobb legyen (minőség, határidő betartása), de ez nem 100%-os garancia. Ha én lennék ügyfél, akkor kizárólag olyan partnerekkel dolgoznék, ahol agile szofverfeljesztés van, mert a fenti két elvárás mellett az átláthatóság szintén fontos. Ezt a korábbi módszertanok nem adják úgy meg, ahogy szeretném... HTH, Zsolt
süti beállítások módosítása