[Java lista] várom a véleményeteket

2010. Jún. 7., H, 14:17:57 CEST

Biztos, hogy egy nyelvet beszélünk? Csak mert a "specifikáció", az nem a tervezés. Nem véletlenül írtam mögé a "tervezést", hanem mert az egy későbbi fázis. A specifikáció sokkal inkább az üzleti elemzés (probléma megértése), és a fejlesztendő rendszer határainak kijelölése (célkitűzés), valamint a nem funkcionális követelmények meghatározása (megvalósíthatóság). Ezután jöhet az üzleti döntés, és ha az pozitív, csak akkor indul a tervezés (ha úgy tetszik, a projekt csak innentől él, a specifikációt kvázi "ingyen" csináltad).

Az üzleti elemzés pedig nem arról szól, hogy "a programom majd ezt kell csinálja", hanem arról szól, hogy a napi munka során a tisztelt reménybeli user mit is csinál. Ha ez mind megvan, akkor kezdődik a rendszer határainak kijelölése (jön a mágikus "na és hol szeretnéd hogy segítsen neked a gép" kérdés). Eddig minden módszertan közel azonos. Az agile esetén viszont a határok mellett kiválasztjuk a "leggyorsabban elérhető legnagyobb előnyt" is, és azt el is kezdjük megvalósítani.

De hiába elemezted az üzleti folyamatokat, viszonylag gyorsan rá fogsz jönni, hogy egy-két alapvető információt a jóember kihagyott. Nem azért, hogy veled kibaltázzon, hanem azért, mert neki az teljesen természetes. Jönnek továbbá a kivételes esetek, amik közül nem gondolt mindegyikre, neked viszont majd a programban valahogy kezelned kell, amikor bekövetkeznek. Ha tehát vízesve lefejleszted a speckó alapján a programot, akkor ezek átadáskor fognak kiderülni - és akkor már elég késő, mert akár alapvető változtatást is okozhat egy ilyen eset (hányszor láttam tök jó adatbázis modelleket felborulni, és a továbbiakban tojásfestő kőbaltaként üzemelni csak azért, mert tervezésekor figyelmen kívül maradt egy-két "apróság"). Agile esetén viszont a fontos funkciók hamar ott lesznek a felhasználónál, elkezd velük játszani, és hamar kibuknak a speckó hiányosságai. Ekkor még viszonylag kevés befektetett munkát kell újra megcsinálni.

Vegyük példának a főkönyvi könyvelést. Ha megkérdezed az expertet, akkor elkezd neked akasztófáról beszélni, meg gyűjtő- és analitikus számlákról, meg számviteli törvényről, meg egyéb hasonlóról. Nagy eséllyel egy szót sem értesz belőle. Pedig amikor megérted, akkor csak arról volt szó, hogy ha van egy könyvelendő összeg, akkor először addig könyvelem azt a 'tartozik' oldalon, amíg nulla nem lesz a maradék, majd addig könyvelem azt a 'követel' oldalon, amíg nulla nem lesz a maradék (vagy fordítva). Amire könyvelhetek, azt tekinthetem analitikus számlának, és minden számlának van egy "apukája", aki az ő gyűjtőszámlája; de van összesen legfeljebb 10 olyan gyűjtőszámla, akinek már nincs apja. Ezek a számlaosztályok. Ennyi tudás nagyjából elég lenne.

Namost ha elkezdesz akasztófát könyvelni, akkor tele fogod rakni bonyolult szabályokkal (ki lehet az egyik oldalán, ki a másikon, milyen számlák lehetnek a bal oldalon, melyek a jobb oldalon, mikor tartozik az akasztófa bal oldala, és mikor követel, meg egyéb hülyeségek. A usert ez mind nem érdekli, mert ezt ő már mind tudja, és nem fogja rosszul használni, de néha fel kell rúgnia a szabályokat. Szóval ha szállítod a funkciót, hamar kiderül, hogy mitől kényelmes és érthető neki - és ezen szabályok nagy része meg sem jelenik a rendszerben, mert az neki mind felesleges. Szólni fog viszont, hogy vannak "könyvelési naplók", és marhára nem mindegy, hogy éppen melyikbe könyvel. Ezt viszont szinte biztos, hogy elfelejti előre megmondani, annyira alapvető tudásnak tartja.

Na mindegy, nem ragozom tovább. Hidd el, egy titka van. Jól kell csinálni. Ha ez teljesül, akkor olcsóbb és gyorsabb lesz, mintha a szintén jól csinált vízeséssel vezetnéd a projektet. De a jól csinált vízesés valószínűleg jobb, mint a rosszul csinált agilis (mert ha rosszul csinálod, akkor pont a lényegét rontod el). Az agilis nem egyenlő a nulla dokumentációval, vagy nulla tervezéssel, vagy pláne a nulla specifikációval.

Üdvözlettel,

István Ketler
Team Leader 
Lufthansa Systems Hungaria Kft. 
Airline Management Solutions 
Schedule & Revenue Management 
Neumann János u. 1/e
1117 Budapest
Hungary 
Tel: +36 1 887-2815 
Fax: +36 1 887-2977 
Room: Infopark E, Room LH1-31 
e-mail: istvan.ketler at lhsystems.com 
Internet: www.LHsystems.hu

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

From: javalist-bounces at javagrund.hu [mailto:javalist-bounces at javagrund.hu] On Behalf Of ern0
Sent: Monday, June 07, 2010 1:02 PM
To: javalist at javagrund.hu
Subject: Re: [Java lista] várom a véleményeteket

> Gondoljátok végig a saját bármilyen projekteteket.
 > Hányszor fordult elo, hogy valamit látszólag teljesen jól
 > lespecifikáltatok, megterveztetek, kifejlesztettetek,
 > átadtatok, majd

Na, itt van a hiba. A folyamatból hiányzik a munka 40%-át kitevo

   helyzetfelmérés

ami nélkül nem igazán lehet normális rendszert csinálni. Ezért van 
létjogosultsága nagyobb cégeknél helyi prgmozói gárda fenntartásának, 
mert kvázi nem kell mindig teljesen nulláról megismerni a céget, hiszen 
benne élnek a srácok.

Ha a helyzetfelmérést elsummantod, akkor waterfall esetén a vezérfasz 
nagy erovel tör az arc felé, elkerülhetetlenül. Agile esetén kvázi 
együtt csinálod az implementálással, mert miközben szép lassan építgeted 
a rendszert, egyre jobban beleásod magad a t. felhasználó problémájába.

Én valami kibtt alaposan interjúztatok, aztán minden szart leírok az 
utolsó szögig, de tutira kimarad mindig valami, szerencsére csak 
apróság. A legintenzívebb élmény a helyzetfelmérés során, amikor 2-3 
meeting után azt mondod a t. megrendelonek: oké, akkor most kezdjük 
elorol, mert itten epic ellentmondások vannak, nem úgy mennek a dolgok, 
ahogy képzeled, illetve mások tök mást mondanak. Általában az derül ki, 
hogy valami (mondjuk a jelenlegi rendszer) bekorlátozza ot egy olyan 
modellbe, ami nem stimmel az élettel, máskor pedig ezeréves rossz 
gyakorlatot kell széttörni, mert ha leprgmozod, akkor újabb ezer évre 
bebetonoznád.

Nem, nem a tervezéssel kezdodik a meló.
-- 
ern0
dataflow programmer & evangelist
_______________________________________________
Javalist mailing list
Javalist at javagrund.hu
http://javagrund.hu/mailman/listinfo/javalist