Magyar Banki Agilis Informatikai Körkép

2014. június 30. - TanacsLajos

Június 26-án tartottuk meg sorrendben ötödik rendezvényünket, melynek során kerekasztal beszélgetésre invitáltuk a magyar banki szféra informatikai projektekkel küzdő vezetőit. Vendégeink voltak:

Biszak Gábor (K&H Bank)
Buda Mónika (Cetelem Bank)
Fogarasi Sarolta (Raiffeisen Bank)
Lucskai Sándor (Erste Bank)
Makkai Balázs (MKB)

Még egyszer köszönjük mindannyiótoknak a remek és nagyon tanulságos estet! Nagy öröm volt látni, hogy vendégeink őszintén, nyíltan, tapasztalataikat egymással bátran és konstruktívan megosztva beszélgettek. Úgy döntöttünk, hogy ebben a posztban emlékezünk meg az eseményről: összeírunk néhány fontos, az est során elhangzott tanulságot emlékeztetőül, valamint kárpótlásul azok számára, akik nem tudtak ott lenni velünk aznap este. Ha valamit kifelejtettünk volna (biztosan van olyan), akkor ne tétovázzatok, írjátok meg kommentben a cikkhez!

Mi ezeket a gondolatokat vittük magunkkal az estről:

Rögös az út, ami az agilis banki projektek felé vezet, de a legtöbb magyarországi bank elindult már rajta
A bankok között vannak, akik már komoly agilis projekteket tudhatnak maguk mögött, mások még az első kísérleteknél tartanak
A módszertan elfogadtatása komoly kihívás a viszonylag merev, hierarchikus banki szervezettel: a fokozatosság kulcsfontosságú
Nem mindenki alkalmas az agilis projektekben való részvételre, de mindenhol vannak olyan tehetségek, akik örömmel élnek az agilitás nyújtotta nagyobb szabadsági fokkal: fontos a megfelelő beállítottságú emberek kiválogatása
A projektvezetők szerepe átalakul valamelyest, de az adminisztratív feladatokat, erőforrások kontrollját továbbra is érdemes náluk hagyni
És végül: a bankosok is emberek valahol :)

Nektek mik voltak az est fontos felismerései? Kommentezés indul!

...

Az első hozzászólás megérkezett, íme egyik kedves vendégünk, Ambrus András vizuális impressziója az elhangzottakról.

13 komment

vörös és fehér 2014.06.30. 14:26:02

az utolsó pontot nem tudom miből szűrtétek le, de köszönöm :)

amit én elvittem magammal (a D&H bögrén túl...), az az, hogy

- a PM szerepe egy külön estés beszélgetést is megér, agilis ide vagy oda. szerintem tisztán agilis projektben nem kell PM, tulajdonképpen egy specializálódott PM-ből könnyen lehet remek PO.
- jó hír a PM-eknek, hogy az agilitás nem csodafegyver, a banki projektek nagy részének akár árthat, ha agilisan állunk hozzá, működhet az esetek egy részénél a kalsszikus waterfall, igaz, itt sem árt, ha használunk agilis eszközöket (vizualizáció, iterációk, stand up, üzleti bevonással)
- legnagyobb kihívás a feladat feldarabolása kisebb egységekre, jó user storyt írni kutyanehéz feladat
- a magam részéről cáfolnám azt a (tév)hitet, hogy az agilitást ha elrontjuk, az árt a szervezetnek, és utána megbélyegzett lesz a módszertan mellett elkötelezett vezető: igenis tanulni lehet és kell a hibákból, nem a módszertant kell kidobni az ablakon
- az agilitás, az agilis eszközök használata sosem lehet egy vállalat célja - a cél a hatékonyabb, üzleti érték alapú szállítás. ennek sok olyan vetülete van, ami vezetői magatatásban kell, hogy megjelenjen. (bizalom, pl.)
- abban szerintem egyetértettünk, hogy a felső vezetői elkötelezettség fontos - alulról sokkal kisebb az esély az átállásra.

hirtelen ezek jutottak eszembe, és itt is köszönöm a lehetőséget.

a közönség remek volt, hajrá bankszektor, hajrá agilitás.

bg.

Válasz erre

trolltartó 2014.06.30. 15:06:57

Hát a banki projektekről megvan a magam kialakult véleménye, de inkább megtartom magamnak.
Néhány éve elhagytam a pénzügyi szektort, lehet, hogy pozitív irányba változtak a dolgok. Amikor nyakig benne voltam, akkor leginkább csak a fejetlenséget volt szerencsém megtapasztalni.

raki 2014.06.30. 18:07:16

A legjobb észrevétel a rafis kerekasztalbeszélgetőtől, Saroltától:

"De jó, hogy eljöttem, most már legalább tudom, hogy nálunk egész jó a helyzet"

:-)

vörös és fehér 2014.06.30. 18:30:50

@trolltartó: én a vörösborokkal voltam így pár éve, annyi lomha, unalmas került elém; aztán rájöttem, hogy a világ ennél színesebb :)

még az jutott eszembe, hogy másnap beszélgettem egy agilis tanácsadóval (ó, azok a másnapos beszélgetések), és azon meditáltunk, hogy vajon egy nagy, hierarchikus szervezetben nem pont a tulajdonosi zemlélet tűnik-e el, összehasonlítva mondjuk ezt egy kicsi, ne adj isten startup céggel, ahol talán épp ezért kap nagyobb teret az agilitás. mintha egy nagyobb szervezetben nem fájna annyira, ha némi pénz kirepül egy projekt során az ablakon.
de nem jutottunk dűlőre, persze.

Vén Márton 2014.07.01. 15:38:53

Nekem lenne pár kérdésem agilis módszertannal kapcsolatban. Kétszer próbáltam már használni projektekben, de bevallom, nem sikerült.

A cikket és a csatolt képet nézve felmerült pár kérdésem, ha lenne valaki olyan rendes, és agilis projektekben tapasztalt, megköszönném, ha válaszolna.

- Felelősségvállalás, elköteleződés a teljes teamtől. Normál esetben a PM az egyetlen igazán elkötelezett, mert megfizetik érte, és mert vele törlik fel a padlót a státusz meetingeken. Mitől válnak a projekt tagok elkötelezetté? Nekik kell kiállni az ügyfél elé bemutatni az eredményt? Időszakos elköteleződés, feladat keresés létezett eddig is, de ez sosem tart ki egy teljes projekten keresztül, a projekten belüli kiégés minden hosszabb projektben létezik. Egyedül a PM nem engedheti meg ezt a luxust. Lehetséges ezt mentálisan a teljes teammel megvalósítani?

- Egy projektben rengeteg ellenségeskedés van. Ügyfél osztályai közt, ügyfél-szolgáltató közt, szolgáltatónál a fejlesztőcsapatok közt, fejlesztők és rendszergazdák közt, egyes fejlesztők közt. Ezeket mind a PM-nek kell elsikálnia. Nekem sommásnak tűnik, hogy mindezeket a problémákat a team tagok elkötelezettsége képes ellensúlyozni és megoldani.
Egy projekt üzleti, technológiai vonatkozásainak átlátása sok időt igényel. Ezt normál esetben a PM csinálja. Nem várható el minden fejlesztőtől, hogy átlássa a projektet egészében, mert nincs ennyi idő. Sokszor az ügyféllel való kommunikációból derül ki, hogy projekt szinten mi fontos az ügyfélnek és mi kevésbé. Ki látja ezt át, ha nincs PM?

- Product owner feladatai - az igények megfogalmazása minden projekt buktatója. Még soha nem láttam olyat, hogy ügyfél oldalon legyen olyan ember, aki képes konszolidálni és megfogalmazni az igényeket, önmaga ellenőrizni az eredményt, és dönteni, és megfelelő ideje van a projektre.

Ez a Product owner definíció úgy hangzik, mintha a legtöbb eddigi PM felelősséget a - feltehetőleg ügyfél oldali - Product owner nyakába tennénk. Holott az ügyfél a felelősségeket a szolgáltatóra igyekszik hárítani, érthető módon. A gyakorlatban létezik ilyen?

- Nincs dokumentáció rész: A hagyományos rendszerdokumentáció a legtöbb projektben alapvető ügyféloldali elvárás, akár gyakorlati, akár jogbiztonsági okokból. Mi alapján mondana le erről az ügyfél?

- "Amire a projekt team vállalást tesz, azért felelősséget vállal". Bármennyire szeretné is az ember, hogy ne így legyen, a legtöbb projekt hazugsággal indul. Azzal a hazugsággal, hogy kész lesz határidőre. Mivel nincs projekt, ahol elegendő idő lenne a biztonságos megvalósításra, a PM belekényszerül ebbe a hazugságba, és majd lesz ami lesz. Erről ti is sokat írtatok. Ha azonban felelős (reális) határidőket kell adni egy team által, az az ügyfélnek/szponzori szintnek nem lesz elfogadható ilyen olyan független okokból (az x havi vezetői gyűlésen már be kell mutatni), vagy épp a szolgáltatói oldal szponzori szintjének (eddig van finanszírozás, tehát eddig át kell adni ezt meg azt, hogy számlázni lehessen).
Hogy sikerül ezt agilis projektekben keresztülvinni?

Előre is köszi, ha valaki válaszol!

raki 2014.07.01. 22:47:55

-- "Felelősségvállalás, elköteleződés a teljes teamtől"
Olyan csapatot és légkört kell felépíteni, ami ezt támogatja. Más mentalitás, más célok. Hogy ez mennyire lehetséges a gyakorlatban? Gyere el pár agile meetupra (www.meetup.com/AgileHungary/), kaphatsz benyomást arról, hol sikerül ez jobban és hol kevésbé. Nekem pl az utolsó dealogicosról egész az jött le, hogy azért ez valamennyire mindenképpen lehetséges. (www.meetup.com/AgileHungary/events/164457122/).

Szerintem ne a magyar banki vagy hasonló "agilis" fejlesztésekből indulj ki. A bankoknak nem a szoftverfejlesztéshez kell érteniük, hanem a pénzhez. Én láttam már olyan banki projektigazgatót, aki egy megbeszélésen megkérdezte, hogy mi az a Gantt chart. (nem vicc). De pl ha jól emlékszem, elhangzott, hogy van olyan, hogy agilis szerződést fix határidő, scope, pénzre kötnek. Hát öööö, ez nem az a klasszikus agilis mentalitás. Más világ, más célok, más eszközök, más értékek.

-- "Product owner feladatai- Még soha nem láttam olyat, hogy ügyfél oldalon legyen olyan ember, aki képes konszolidálni és megfogalmazni az igényeket, önmaga ellenőrizni az eredményt, és dönteni, és megfelelő ideje van a projektre"
Itthon is vannak cégek, ahol van product owner, gondolom, ők annyira biztos jól csinálják a dolgukat, mint egy "hagyományos" projektvezető. Egyébként meg én meg nem láttam a Hold túloldalát, de elhiszem, hogy van neki :-)

-- "Nincs dokumentáció rész (...) Mi alapján mondana le erről az ügyfél?"
Miért kellene lemondania? Ez egy alapvető félreértés, hogy az agilis módszertanoknál nincs dokumentáció. Az van, amit az ügyfél kér. Ha kell neki, akkor lesz dokumentáció. A másik nagyobb félreértés, hogy nincs semmi specifikáció. Ezt azok az ügyfelek hiszik, akik nem akarnak specet írni és egyáltalán semmivel sem foglalkozni, csak legyen készen, de hogy mi, azt nem akarják megmondani típusú igénnyel lépnek fel :-)

-- "Bármennyire szeretné is az ember, hogy ne így legyen, a legtöbb projekt hazugsággal indul"
Erre csak azt lehet írni, hogy van egy másik világ is, ahol másképp működnek a dolgok. Ott sem rózsaszín minden, de ennél azért szebb a helyzet.

"This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember, all I'm offering is the truth – nothing more."

:-)

Csaba Szirják 2014.07.02. 20:49:42

@Vén Márton:

"Nekem lenne pár kérdésem agilis módszertannal kapcsolatban..."

A kérdéseket végigolvasva elsőre az jutott eszembe, amit kb 1 éve tanultam: PARADIGMAVÁLTÁS. Nagyon fontos, hogy más szemüvegen keresztül is vizsgálódjunk, mert ha a meglévő paradigmáinkon keresztül nézzük azt, hogy mit csinálnak emberek, pontosan azt fogjuk kapni, amire számítunk. Pedig erre bizony van ráhatásunk, az egyik ilyen témakör a bizalom...

"- Felelősségvállalás, elköteleződés a teljes teamtől..."

Itt az első példa: Az emberek alapvetően jónak születtek és nem rossznak, ne így közelítsünk hozzájuk. A fejlesztők azért lesznek elkötelezettek, mert szinte mindent beáldoztak azért, hogy fejlesztők lehessenek és kreatív munkát végezve alkothassanak. Az elköteleződés nem hiszem, hogy azon múlik, hogy mennyi pénzt kapsz, felmossák-e veled a padlót, neked kell-e kiállni bemutatni az eredményt. Ezt inkább úgy hívnám, hogy félelem és hogy ezt vállaltad a pénzért, magyarán eladtad magad. Sarkallatosan fogalmazok, de próbálj a másik oldalra is áthelyezkedni. Egyébként a Scrum-ban nem véletlen, hogy a Team Demo-zik és nem az SM vagy PO.

"- Egy projektben rengeteg ellenségeskedés van...?"

Ejha, totál másképp látjuk a dolgokat :) Szerintem az osztályok és emberek között akkor van konfliktus, ha a seggüket védik és nem arra törekednek, hogy előállítsanak valamit közösen. Nem hiszem, hogy el kellene sikálni a problémákat, sokkal inkább kitenni az asztalra és konstruktívan megoldani. Vannak kommunikációs trainingek és egyéb programok is amik segítenek. Ami azonban ennél is fontosabb, az az, hogy lássuk a célt. Nem várható el egy fejlesztőtől, hogy átlássa a folyamatokat? Viccelsz? Az egyik szakma, ahol az átlag IQ toronymagasan van. Arra tették fel az életüket, hogy problémákat oldjanak meg. Ha nem vagy hajlandó elárulni a problémát, csak hogy te milyen megoldást találtál ki, akkor ne csodálkozz.
Példa: Vegyél le holnap a számládról 3500 Ft-t. Nem kell tudnod miétr, csak szólj ha megvagy vele. Jah, hogy jobb lett volna azt mondanom, hogy olvasd el Stephen R. Covey 7 szokás című könyvét? Te meg megrendelted volna online, mert úgy gyorsabb és olcsóbb... Ez az egyik első dolog, amit meg kell tanulni, célokat kell adni és hagyni az embereket, hogy megoldják. Ha nem tudják, akkor te vagy a béna, mert rossz embert vettél fel, rosszat választottál a csapatodba.

"- Product owner feladatai..."

Én nem olvastam sehol olyat, hogy a PO-t a megrendelő vagy a megvalósító lenne köteles adni. Az egyik fél elvileg jobban tudja, hogy mit szeretne, a másik meg jobban tudja, hogyan kell terméket fejleszteni és hogyan kell a fejlesztőknek ez átadni. A legjobb, ha az ügyfél oldalon van ilyen ember, de ha nincs, akkor a megvalósító cégnek kell legyen ilyen embere, aki képviselni tudja az ügyfelet megfelelően. Fontos az is, hogy az ügyfél nem érti sokszor a technológiai oldalt, ezért hagyni kell onnan is beszivárogni az ötleteket és a kettős hajtást megvalósítani, mert akkor lesz valami igazán jó termék.

"- Nincs dokumentáció rész...?"

Ez bullshit :) Szerintem az agilis módszertanok sokkal részletesebb dokumentációt kérnek, mint a waterfall. Csak azt mondják, hogy a következő iterációra tervezz és specifikálj alaposan, a távoliakra pedig elnagyoltabban. Ezzel szemben a waterfall langyosvíz. Írj sokat, de ne olyan részletesen, hogy az alapján bárki dolgozni tudjon, de legalább a végén mondhatod, hogy te kérted, de ők félreértették és nem azt csinálták meg amit kellett.

- "Amire a projekt team vállalást tesz, azért felelősséget vállal..."

Igen, ezt mondja a módszertan. Ez nem jelenti azt, hogy készen lesz, ez azt jelenti, hogy felelősséget vállal, ha nem lesz kész. Magyarán kollektíven lesznek "büntetve" és nem egyénileg. A hibákból tanulnak és már a következő iterációban jobban fognak teljesíteni.
Hazugság? Mi a fenéért kellene hazudni? Erre biztos nem jó rászoktatni az embereket. Játszunk tiszta lapokkal. Az agilis hozzáállás azt mondja, hogy adott idő alatt adott büdzséből kihozza a maximumot értékesség szempontjából.

Remélem, hogy sikerült némely kérdésedre válaszolnom és a jövőbeni projektjeidbe be tudod építeni. Itt-ott lehet keményen fogalmaztam, ezért elnézésedet kérem, de úgy éreztem kicsit a másik oldalt is meg kell mutatni.
Mindezt amúgy úgy mondom, hogy a te oldaladon állok már 3 éve, annyi előnyöm van, hogy 12 évig fejlesztettem is.

raki 2014.07.04. 00:09:55

"Az elköteleződés nem hiszem, hogy azon múlik, hogy mennyi pénzt kapsz, felmossák-e veled a padlót"
Igen, ezt én is akartam írni, csak kimaradt.

"agilis módszertan (...). Kétszer próbáltam már használni projektekben, de bevallom, nem sikerült. "
Érdekes, a vízesés módszertannak több esélyt szoktak adni, van aki egy egész életen keresztül próbálkozik vele :-)

eckerman 2014.07.07. 16:38:39

(Szia, én készítettem az ábrát, leírom a véleményem az általad felvetett jogos és nagyon érdekes kérdésekről. Az előző kommentekkel nagyrészt egyetértek, de nem tudom megállni a válasz írást :))

------------
Felelősség
------------

A felelősség kérdése kulcskérdés a projektekben: az erről való véleményalkotás nem véletlenül szerepel központi helyen a módszertanokban. És szerintem az agilis hozzáállás ebben a kérdésben jelentősen újat hoz: az elterjedt és jól megszokott, jogok és kötelességek dokumentációval megtámogatott, és ezáltal hosszú távon is biztonságosnak tűnő kalickája helyett szabadságot kínál annak minden fájdalmával együtt. A szabadság ebben az esetben például azt jelenti, hogy meg kell tanulnunk monduk két hétre előre becsülni: amit mondunk azt el fogják fogadni, de teljes felelősséget vállalunk érte. Meg kell tanulnunk beosztani az időnket, meg kell tanulnunk a nehéz döntéseket meghozni és felvállalni a tetteink következményét. Ez azzal jár, hogy nem hivatkozunk arra, hogy Bélára vártunk és a szerződésben (vagy valami "nagyon fontos" dokumentumban) rögzítve van, hogy ebben az esetben nem kell prezentálnunk a vállalásunkat. Nem azzal töltjük az időt, hogy Bélával levelezve bebiztosítsuk magunkat a már előre látható sikertelenség ellen, hanem ehelyett minden erőnkkel arra törekszünk, hogy a vállalásunkat teljesítsük. Bélával közösen. Oda kell mennünk egymáshoz (optimális esetben az asztal két oldalán ülünk) és együtt ki kell találnunk, hogy oldjuk meg a felmerülő helyzetet. Meg kell tanulnunk beszélni egymással, kreatívnak kell lennünk, folyamatos seggvédés és eszkaláció helyett a probléma megoldására kell koncentrálnunk.

Ez egy másfajta tudás, meg kell ismerni, tanulni, majd gyakorolni kell.

Lehet hogy ez nem mindenkinek megy, de ez már filozófiai kérdés. Én abban hiszek, hogy az ilyesmi felszabadítja az embert, de pont azért raktam az ábrára a _Mindenki alkalmas rá, hogy ilyen team-ben dolgozzon?_ kérdést, mert erről sokat kellene beszélnünk. Számomra ez lelkesítő, a korbács ("vele törlik fel a padlót a státusz meetingeken") semmiképpen sem az, a pénz meg ("mert megfizetik érte") szükséges, de nem elégséges feltétel.

Szerintem egy vagy két esélyt mindenki megérdemel, hogy kipróbálja ezt is.

-------------------
Ellenségeskedés
-------------------

Számomra ez is filozófiai kérdés. De azt gondolom, hogy egy projektben _alapból_ miért ellenségeskednének egymással az emberek (túl az evolúciós csoportkizárós elméleteken - lásd később)? Az a tapasztalatom, hogy ha lerakjuk a vállunkról a seggvédés terhét és nem másra hárítjuk a felelősséget, akkor az ellenségeskedés magától megszűnik. Időnk sem lesz másokkal foglalkozni, mert az összes időnket a kreatív problémamegoldásra fordítjuk.

Visszatérve a felelősség kérdésére: szerintem nagyon sokat segít, ha a team tagjai megismerik egymást. Egy helyen ülnek, beszélnek egymással, a másik az nem egy megfoghatatlan ködös valaki, akit könnyű utálni, hanem egy ember, akivel az előző sprintben is együtt szenvedtük ki magunkból a megoldást és bár nehéz volt, de büszkék voltunk rá. Ha a csoportod részévé válik, nehéz lesz utálni. Ha ezt sikerül felismerni, akkor azonnal felmerül a kérdés, hogy bárki lehet a csoport része? És ha az lett, akkor már nem kell utálni? Akkor minek utálni azt aki még nem az? Amíg nem csinált semmit, addig miért alapból ellenség?

A team együtt demózik. Ott van mindenki és ha nem működik a szoftver, akkor nem mondjuk azt, hogy azért, mert a másik elrontotta - és egy merev mutatóujjal rámutatunk. Hiszen együtt csináltuk és nem mellesleg ott áll mellettünk: ahogy minden reggel a standup-okon is. Így nem olyan egyszerű hárítani a felelősséget, mint emailben egy valahol a távolban ülő ismeretlenre. A standup-ok miatt ráadásul a probléma nem a sprint utolsó napján derül ki, hanem maximum 1 napon belül!

Nem fog tökéletesen működni az egész. Erre való a retrospective. A csapat tanul a hibáiból, megbeszélik, hogy mit tartsanak meg és min változtassanak. Két hét múlva pedig megnézik, hogy mi sikerült és mi nem.

Ilyen közegben miért lenne ellenségeskedés? Feszültség az persze lehet, de ellenségeskedés nincs.

eckerman 2014.07.07. 16:39:37

Folyt.

----------------
Product owner
----------------

Ha nem tudunk keríteni egy olyan embert, aki két hétre előre meg tudja mondani, hogy mivel foglalkozzunk, majd a 2. hét végén megnézi, hogy elfogadható-e számára amit készítettünk, akkor mi alapján és főleg miért csináljuk az egészet?

Szerintem a PO a kulcspozíció az agilis team-ben, és a lényeg pont a gyors visszacsatolásban van: ha csak egy nagy víziója van az elkészítendő termékről, amit a Product backlogjában story-kban megfogalmaz, a két hetente látott működő szoftver és a sok-sok beszélgetés alapján könnyebben alakítja ki a következő sprintre vonatkozó igényeit. A product backlog nem kőbe vésett, hanem a projekt előrehaladtával a PO alakítja.

Volt olyan, hogy teljes funkciókat újraírtunk, mert kiderült, hogy nem megfelelő volt az első változat. Olyan is előfordult, hogy már a negyedik sprintre szétfeszítettük az adatmodellünk kereteit: kértük, hogy a következő sprintet az adatmodell újragondolásával tölthessük, hogy a már látható igények alapján azokat is ki tudja majd szolgálni.

A PO behozza az igényeit a sprintre és a team-mel közösen eldöntik, hogy mi fog elkészülni a demóra. Itt is közös felelősség és közös munka van.

----------------
Dokumentáció
----------------

Annyit dokumentálunk, amennyit a megrendelő szeretne. De mindenki viszonylag hamar rájön, hogy az elavult dokumentáció semmire sem jó. Én személy szerint még a programkód kommentezésének sem vagyok híve, hanem sokkal inkább a megfelelő elnevezések használatának. Mire jó egy olyan kommnet, ami alatt a következő 3 sor már teljesen mást csinál (mert például lusta volt utánahúzni az, aki módosította a kódot)? És mire való egy olyan modell neadjisten egy hosszú szöveges leírás, ami egy olyan funkcióra vonatkozik, amit már régen kidobtunk vagy teljesen máshogy valósítottunk meg? Jól néz ki, hogy sok könyvtárban van sok ilyen dokumentum? Úgysem olvassa el senki.

Az a jó dokumentáció, amit rövid idő alatt fel tud dolgozni az, aki meg akarja érteni az adott funkciót a különböző absztrakciós szinteken.

Szerintem pont annyit dokumentáljunk ami ehhez szükséges és az mind élő és naprakész legyen.

(Tudnék példákat is írni, de már így is túl hosszú lett ez a komment.)

raki 2014.07.07. 19:14:38

"Annyit dokumentálunk, amennyit a megrendelő szeretne"

Ez nagyon hasznos arra, hogy a megrendelő megértse, hogy a dokumentációnak ára van. Így döntési helyzetbe kerül arra vonatkozóan, hogy hasznos-e neki kifizetni a dokumentációt, illetve milyen részletezettségűt vagy inkább a pénz egy új feature-re költi vagy egy bugfixre.

Persze mindenki agyondokumentált szoftvert szeretne, csak épp ingyen :-)

Mert egy jó dokumentáció előállítása kb még egyszer annyi embert igényel, mint ahányan írják a kódot, illetve persze karban is kell tartani, minden változásnál. És ezeknek az embereknek a költségét ki kell termelni.

Kaksi Kapitány 2014.09.29. 15:23:01

@eckerman: Egyetértek a litániáddal, főleg a PO szerepe es a kommentmentes kód ami tetszett. A jó kód öndumentáló, es mivel rövid methodok és kis classok jellemzik semmit értelme elmagyarazni mi történik mert átláthatató. Ha mindez mellékhatások nélküli jó névhasznalatú methodokkal párosul, akkor a kommentelés teljesen szükségtelen.

De a legfontosabb, hogy ha elkezded szarni a dokumentációt a korai szakaszokban, akkor nagy a valószínűlege hogy később dobhatod ki a kukába, mert a következő sprintekben minden megváltozik, (bankszektorban főleg) többnyire a hiányos üzleti követelmények miatt.

epitomester 2015.03.25. 15:26:18

Sziasztok,

Kis segítséget szeretnék kérni: gyakorló scrum masterként agilis módszertanokról írok megkésett szakdolgozatot :) Ambrus András ábrája nagyon attraktív, és szívesen beépíteném - tudnátok hozzá elérhetőséget biztosítani? Az email címem publikus.

Előre is köszi.

Derrick és Harry Projektmenedzsment Blogja