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

[Gergely Hodicska]

Szia,


> NA EZ AZ! Az Agilis módszertan tervezése során mindig csak egy lépést
> lépünk előre. És ha az út sokfelé ágazik, akkor nagyon nagy utat fogsz
> bejárni, mire kijutsz a  labirintusból. Addigra többnyire kifogy a
> budget, és megbukott a projekt. Csak akkor jó az agilis, ha
> valamennyire át lehet látni az egész utat. Akkor elég az egyes
> lépéseket megtervezni.
Szvsz rosszul látod az agilis módszertan lényegét. Ugyanúgy, ahogy az 
agile manifesto sem azt jelenti, hogy a jobb oldalon álló elemek nem 
fontosak, hanem azt, hogy a bal oldalon álló elevek előnyt élveznek.

Ha egy komolyabb projektnek kell nekiállnod agilis módon, akkor egyrészt
eleve hosszabb sprintek lesznek, plusz simán belefér az, hogy az elős 
pár srpintnek tervezés a célja, és egy "futtatható" (konkrét) tervet 
kell szállítani, vagy épp megvalósíthatósági tanulmányt. Nem úgy néz ki, 
hogy kitalálom a rendszer egy darabkáját, és nekiesek és megcsinálom, 
majd egy másikat.

Ez inkább olyan szmepontból érdekes, hogy nem állok neki megtervezni egy 
olyan távoli jövőt, ami már nagyon bizonytalan (ami kb. egy vízesés 
modelnél adott rengeteg okból kifolyólag [1]).

[1]:
- ügyfél nem tudja mit akar
- te nem tudod, hogy mit akarsz (idő, amíg ténylegesen megérted a domain 
modellt, és idő amíg kialakul a közös nyelv az ügyféllel, érdemes 
elolvasni a Domain Driven Design elejét)
- hosszabb távon maga a technológia is elavulhat, amire építesz
- ezer kis apróság jöhet közbe, amire nem tudsz előre felkészülni, 
teljesen biztos vagyok benne, hogy mint régi motoros ezt ezerszer 
megtapasztaltad


> Erről nem a kuncsaft tehet. Mivel ő a vevő, ő nem tehet semmiről. Ő a
> vevő. (Maximum ha nem fizeti ki a számlát, az összes teljesítés
> igazolás aláírása és a számla befogadása után, de ez megeshet a magyar
> állammal is mostanában, főleg ha valami nagyobb portál fejlesztésről
> van szó.)
Itt jegyezném meg, hogy pl. a Scrum egy nagy előnye, hogy rengeteg 
felelősséget levesz a váladról, mert a product owner (amit alap esetben 
a megrendelő ad) dönt, ezért ő lesz felelős a döntésekért.

> Addig kell vele kommunikálni, amíg nem vagy biztos benne, hogy tudod
> mi az amire tényleg szüksége van, mi az amit akar, és mi az amit át
> fog venni és kifizet. Ez lehet három különböző dolog, amit meg mond az
> a negyedik.
Ez jól hangzik, csak kb. elképzelhetetlen (főleg egy nagy projekt 
esetén). Ahogy említettem eleve nem egy nyelvet beszéltek (még akkor 
sem, ha úgy tűnik, hogy igen). Az agilis módszernek pont ezért nagyon 
fontos eleme, hogy bevonja az ügyfelet, és nagyon hamar jön tőle 
feedback, és pont ezért teljesül az, hogy nem fogsz túl sok ideig rossz 
irányba menni.

Aztán még lehet olyat is bedobni, hogy egy idő alapú becslés, illetve 
lépések egymásra épülésén alapúló model az kb. fixen magában hordozza a 
csúszást [2], és egy csúszás egy korai fázisban végig fog haladni a 
teljes projekten (és általában a QA-n fogod megnyerni ha nagyon muszáj).

[2]: Alapvető emberi tulajdonság (egy átlag fejlesztő esetén), hogy 
kitölti a rendelkezésre álló időt, plusz általában nem jól érzékeli, 
hogy hol is tart, ezért gyakori a csúszás. (Ok, lehet PM gyakorlattal 
ezt orvosolni, de maga jelenség jelen van, míg egy komplexitás alapú 
becslés esetén ez nem olyan nyilván való.)

És még van egy olyan motívum is, ami pl. Scrumban alapvető, hogy azokon 
az ügyeken dolgozol, ami a legfontosabb a usernek, ezért nem fordulhat 
elő mondjuk csúszás esetén, hogy kb. a teljes projekt 90%-on van, de még 
abszolút használhatatlan. Helyette lesznek funkciók, amik nem lesznek 
készen, de van egy használható szoftvered.


Üdv,
Felhő