Kispad

Kispad: közös blog
4230 cikk, 53894 hozzászólás
Szerzők | Tudnivalók | Feedek


Agile software development

eszpee cikke a Torokgeek rovatból, 2007. április 1. vasárnap, 12:22 | 18 hozzászólás

Az agile software development programozói berkekben a spanyolviasz legújabb neve. Az ugye megvan mindenkinek, hogy mi a „vízesés módszer”. A programozók összedugják a fejüket, precíz és részletes doksit írnak arról, hogy a program, amiből egyelőre még egyetlen sor sincs meg, pontosan hogyan fog működni. Aztán nekiesnek és elkezdenek gőzerővel kódolni. Ha elkészültek, akkor nekiállnak kigyomlálni a hibákat. Ez a művelet rendszerint tovább tart, mint a tényleges kódolás.

Az agile szoftvertervezési metódus feladja azt a hiú reményt, hogy előre ki lehet dolgozni egy bonyolult szoftver minden egyes részletét. Ehelyett nagyon rövid iterációkkal építkezik; a ciklusok pár hetesek, egyszerre csak egy-két funkciót implementálnak, és a körök végén olyan állapotba hozzák a projektet, hogy azt elvileg akár rilízelni is lehet. Tokkal, vonóval, dokumentációval együtt. Mindezt persze eddig is tudta az, aki írt már ötezer sorosnál hosszabb programot, csak eddig nem volt divatban ez a módszer.

Az agile metódusnak számos variánsa létezik, ezekről olvashattok itt, itt, itt, itt, itt, itt, itt, itt, itt, itt, itt, itt, itt, meg itt.

» Ugorj a hozzászóló ablakhoz

Megosztások Facebookon

Eddigi hozzászólások (18)

1

nyelv-ész, 2007. április 1. vasárnap, 13:08 (#)

Ez az agilis szoftverfejlesztés nagyvállalati környezetben egy rémálom. Eleve a megrendelő nem ad teljes specifikációt. Ráadásul nem is látja át a teljes it-infrastruktúrát, tehát fogalma sincs, hogy esetleg valahol már működik egy hasonló. Vagy hogy a megrendelt program esetleg olyan műveletet végez, ami máshol jól bekavar.
Szóval ez a módszer legfeljebb egy nulláról induló rendszer vagy egy standalone desktop szoftver esetén hozhat elfogadható eredményt.

2

eti, 2007. április 1. vasárnap, 13:10 (#)

A tizedik "itt" link kakukktojás?

3

Ali, 2007. április 1. vasárnap, 13:16 (#)

Ezt 2002-ben még extreme programming névvel illették, nem?

4

ee, 2007. április 1. vasárnap, 14:52 (#)

Nem, az extreme programming (XP) csak az egyik metodológia az agile családban.

A vízesés módszernek meg nem az a hibája, hogy tele lesz hibával a kód (ahogy talán a cikk sugalja), hanem hogy nagyon merev. Az csak akkor használható, amikor meg van egy 100%-os speckó, utána abból megcsináljuk a terméket (ami lehet akár a speckó szerint tökéletes), aztán teszteljük, stb. Mint #1-ben is olvastuk, ez azért nem szokott így lenni. Az agile technológiák egyik előnye, hogy kezelni tudja ezt a helyzetet, mivel iteratív jól (lásd fent).

Én konkrétan az XP-t ismerem és van benne elég sok jó ötlet, amit be szoktak építeni belőle még ott is, ahol nem kifejezetten XP szerint dolgoznak (pl. test-driven programozás, Continuous Integration, Collective Code Ownership). És vannak olyanok is, amit tényleg csak az extreme-k próbálnak ki (pl. pair programming: egy gép, egy billentyűzet, egy monitor, két fejlesztő)

Vannak persze más metodológiák. Pl. a (R)UP. Ez szintén iteratív, tehát a fent vázolt előnyöket tudja, de inkább nagyvállalatok használják. Kicsit kevésbé "agilis", sokkal több benne a kötöttség, pl. nagyon sok dokumentációt követel meg (hagyományosan a klasszikus agile metodológiák a dokumetációból nem csinálnak akkora nagy ügyet), előre definiált szerepek vannak, ott is le vannak fektetve a fázisok és iterációk, stb.

Én azt a mondást tudom, hogy néhány embereres projektben/vállalatban általában sokkal hatékonyabbak az agile metodológiák, de nagyvállalatoknál, nagy teameknél mindeképpen megemelkedik az adminisztráció igénye, és akkor a (R)up, vagy hozzá hasonló, de ingyenes megoldások jönhetnek szóba.

Az biztos, hogy metodológia kell, és még a vízesés módszernél is rosszab (ami ugye nem rossz módszer, csak a világ nem ideális hozzá), az hogyha ahogy esik úgy puffan, neki esünk és lesz valami.

5

ee, 2007. április 1. vasárnap, 15:05 (#)

Közben megtaláltam az erről szóló grafikont (pl. a Rational Unified Process Made Easy c. könyvben található meg)

http://www.awprofessional.com/content/images/chap1_0321321308/elementLinks/01fig01.jpg

A függőleges tengely a vízesés modeltől megy az iteratív megoldásokig. Ha kevés a kockázat (nem fog változni a speckó), akkor a vízesés és teljesen a jó.

A visszintes tengelyre ő azt mondja, hogy low/high ceremony. Nyilván egy kis projektben nem kell annyi doksit írni, mert ott van mellettem a koléga, mindent megbeszélünk és max. az eredményt rögzítük. Egy nagy projekt viszont átláthatatlan lesz a szereplők számára precíz dokumentáció nélkül, ami persze a programozástól veszi el az időt, ami miatt kevésbé lesz agilis a dolog.

Az agilis metodológiák a grafikon bal alsó kockájában vannak tipikusan, a fent idézet UP/RUP meg inkább a jobb alsóban (bár azt állítja magáról a TUP, hogy ő működik lightweight módban is, de tipikusan nem úgy).

6

Ali, 2007. április 1. vasárnap, 15:24 (#)

A munkahelyemen most állítottam be egy wikit arra a célra, hogy ez hátha effektívebb lesz, mint a "ja, nem tudom, melyik doc-ban van, ha leírtam egyátalán" és a "kinél van a legfrissebb változat?". Egyelőre lelkesen telik információval, de ezt még betudom az újdonság varázsának. :)

Az XP-re csak úgy láttam rá, hogy állítólag pár elemét alkalmaztuk a Nürnbergben, de igazából azt hiszem, mindig is iteratívan oldottam meg a problémákat, jó specifikációról meg sok embert hallottam beszélni, de látni még nem láttam olyat. :) Olyat viszont már láttam, hogy a nagy tárgyaló falait végig lehetett tapétázni az UML ábráival, de a project kétharmadánál már csak egy ember hitte azt, hogy aszerint haladunk. :)

7

ratoth, 2007. április 2. hétfő, 09:51 (#)

"Eleve a megrendelő nem ad teljes specifikációt." -> Ez pont waterfallnal jelent gondot, ahol egy sor kodolas nelkul meg szeretned tervezni az egesz rendszert. Iterativ modszereknel nem kell, hogy meg legyen az osszes requirement, csak egy iteracionyi. En nagyvallalalti kornyezetben tobb csoporttal hasznalok SCRUM (szinten egy agile vagy iterativ modszer)-ot, es mukodik.
Az erdekesseg kedveert hozzatennem, hogy iterativ modszereket mar az otvenes evek elejen hasznaltak a NASA-nal.

8

nyelv-ész, 2007. április 2. hétfő, 22:16 (#)

ratoth, viszonylag homogén környezetben el tudom képzelni. Ott, ahol azonban közel 20 évnyi IT-szemét felgyülemlett, a kőkorszaki rendszerek együtt élnek a modern megoldásokkal, ezernyi fájltranszfer és xml-üzenet próbál egységes adatstruktúrát teremteni, ott csak a nagyon precíz rendszerterv és az alapos implementáció ad némi esélyt, hogy egy fejlesztéssel ne vágj haza három másikat.

9

tapsihapsi, 2007. április 2. hétfő, 23:57 (#)

nem tudom tudjátok-e, hogy ezzel a cikkel az "agilis szoftverfejlesztés" keresőszóra a google 4-nek rangsorol titeket. WÁÁÓÓÓ és TAPs.

10

ratoth, 2007. április 3. kedd, 16:12 (#)

nyelv-esz, harom pelda, hogy eddig milyen agile projektekben voltam: 1 - uberosszetett telekom cucc C++-ban irva (kb 4 eves termek), 2 - uberosszetett telekom cucc SDL-ben es C-ben irva (kb 20 eves termek), 3 - J2EEs webes adatbazisos okossak (0 eves nem termek). Eddig mindharom kornyezetben mukodni latszanak az iterativ modszerek. Miert is ne mukodnenek, hiszen csak arrol van szo hogy nem hitegetjuk magunkat azzal, hogy mindent meg tudunk elore tervezni.
Az iterativ modszerek NEM azt jelentik, hogy nincs dokumentacio es hogy nem korultekinto a design! Ajanlom, hogy olvassatok el ezt, csak par oldal, de elgondolkodtato:

http://www.agilemanifesto.org/

tapsihapsi, orulok az otperces hirnevnek, de egy kicsit szomoru vagyok, hogy ez a ket napos topic ilyen elokelo helyezest ert el...

11

nyelv-ész, 2007. április 3. kedd, 20:57 (#)

ratoth, percig sem állítom, hogy nem célravezető a módszer bizonyos esetekben. Arra próbáltam rávilágítani, hogy bizonyos helyzetekben egyszerűen nem működőképes a koncepció, mert a fejlesztendő szoftver annyi már meglévő komponenstől függ, és annyi más rendszert érint, hogy nem lehet lépcsőfokonként haladni. Vagy működik az egész, vagy semmi sem működik.

Mondok példát, hogy egyértelműbb legyen:
Van kb. 3 millió rekordos ügyféladatbázisod, de ebből kb. 2 millió van az egyik rendszerben, 1 milla a másikban. Eltérő platformok, eltérő adatbáziskezelők, stb. Minegyikre ráépül egy-egy igen komplex kezelőszoftver. Ráadásul még 9 kisebb szatelit program is használja ezeket az adatbázisokat úgy, hogy nemcsak olvas, de bele is ír. A szoftverek egy része 8-10 évvel ezelőtti fejlesztés, van köztük mainframe, iseries, unix egyaránt. Van sql alapú és van hótpimitív fájlnyitogatós is.
Na most csinálj egy közös adatbázist, hozd össze az eltérő adatszerkezeteket, és oldd meg, hogy mindegyik szoftver egyformán ki legyen szolgálva. Mindezt úgy, hogy a napi munkát nem állíthatod meg, tehát egyik nap még a régi, másnap az új környezetben kell működnie mindennek.

12

mate, 2007. április 4. szerda, 13:13 (#)

nyelv-ész: azt hiszem ezt hívják kihívásnak :-)

13

gargoyle, 2007. április 4. szerda, 13:16 (#)

nem, ezt nem ennyire nyomdaturo nyelven szoktak hivni, de mindenesetre elkezdenek sok 0at rajzolni a tervezett dijazas rovatba, hogy estig vegezzenek (:

14

nyelv-ész, 2007. április 5. csütörtök, 07:03 (#)

mate: ezt szívásnak nevezik.
És ráadásul ez egy, az életből ellesett példa. Másfél éve dolgozunk rajta.

15

Ali, 2007. április 5. csütörtök, 08:10 (#)

Másfél év alatt egy komplett új rendszert fel lehetett volna állítani és párhuzamosan tükörként vinni, majd egyik napról a másikra átállni, szinte észrevétlenül. Mondjuk ahol én láttam ilyet, ott volt pénz tíz hónapon át párhuzamosan menni, a vendégmunkásokat ilyen melóra veszik fel szívesen. :)

16

nyelv-ész, 2007. április 5. csütörtök, 14:04 (#)

Lehetett volna, ha közben harminc másik fejlesztést nem kellene nyomnia ugyanannak a kéttucat fejlesztőnek - köztük olyanokat is, amelyek pont érintettek az ügyféladatbázis kapcsán.
A párhuzamos rendszer felállításának meg vannak akadályai: nem fog senki mellényzsebből kicsapni 100 millát IBM mainframe-re, iSeries-re, stb. A meglévőket persze particionáltuk, ahol tudtuk, egy vason most több oprendszert futtatunk, és haladunk is, csak kevés erőforrással akar a cég sokat markolni.

17

Czimi, 2007. július 22. vasárnap, 03:03 (#)

Mivel ez az egyetlen leírás, amit magyar nyelven találtam, némi kiegészítés:
http://xczimi-yvr.blogspot.com/2007/07/agile-scrum-vagy-amit-akartok.html

folytatása következik

18

ZsZs, 2008. január 29. kedd, 05:01 (#)

Kedves hozzászólók!

Szeretném felhívni a figyelmeteke az Agilis Szoftverfejlesztők Egyesületére:
http://www.agilealliance.hu/index.php/home

Várunk benneteket olvasóként, vitapartnerként vagy tagként.

- Zsolt


Hozzászólsz?

Igen

Hozzászólást csak névvel együtt fogadunk el. Ha linket írsz be, akkor előtte és utána hagyj egy szóközt, főleg akkor, ha zárójelbe teszed.


Az oldal tetejére | Szerzők, tudnivalók, feedek | sesblog és Kispad © 2003-2010 ervin, eszpee, stsmork