eckerman 2016.08.09 16:07:06

Köszönöm, hogy ennyien hozzászóltatok, sokat tanultam a hozzászólásokból! Nem számítottam rá, hogy ennyire megosztó lesz ez a kis írás, a célom az volt vele, hogy vitatkozzunk egy kicsit arról, hogy ki hogy látja a projekt szempontjából feleslegesnek tűnő és értékteremtő tevékenységeket és ezek arányát a projektvezető szerepkör szempontjából - hiszen ez egy projektmenedzsment blog. Amit írtam, nem minősítésnek szántam, mindez projektvezető szerepkörben nekem is szól, hanem visszajelzésnek és vitaindítónak. A stílusa azért lett ilyen, mert az a tapasztalatom, hogy ha túl udvariasan és konform módon beszélek ilyen problémákról, akkor azt nem mindenki hallja meg. Ha a Harry által írt bevezető nélkül elolvassátok, akkor láthatjátok, hogy nem szerepelt az írásomban, hogy milyen sapkában írtam: mégis visszatérő elem volt a viták közben, hogy az egyes szerepköröknek milyen problémájuk van a másikkal. Szerintem ha első lépésként betemetnénk ezeket az árkokat, akkor az jó kiindulási alap lehetne az előbbre jutáshoz. Ami ebben az esetben valószínűleg nem más, mint a minél hatékonyabb hozzájárulás a projekt céljainak eléréséhez.

eckerman 2016.08.10 09:37:23

@I_Isti: :) Projektenként változik hogy merre vagyok, ez elmúlt 2 évben scum master (hitelezési rendszer), fejlesztő (dokumentumfeltöltő rendszer front end és back end, szolgáltatás fejlesztés), projektvezető (köztes rétegek fejlesztése, ESB), IT architekt (több projekt) voltam különböző célú és méretű projektekben. Egyik sem jobb vagy rosszabb, mint a másik, csak más.

eckerman 2016.08.15 14:00:09

@_droid_: Csak ha megyünk és nem habozunk :) www.youtube.com/watch?v=2D27iue4G6w

eckerman 2015.12.21 09:27:12

A főzéshez :) "A piacon hõsünk elsõ dolga legyen a feketekávé, majd egy kis szíverõsítõ, ami nem jelent ilyenkor mást, mint a családiasan hétvégi hangulatra adott frappáns választ. " matula.hu/index.php?section=article&rel=8&id=102 és "A magányos férfi pénteken hamar berúg, ezért korán lefekszik." matula.hu/index.php?section=article&rel=5&id=70 Továbbá amikor a kitartás találkozik a hozzáértéssel: motoroskonyhaja.blog.hu/2015/09/18/vegyesporkolt_erdesz_modra

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.)

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 2012.09.24 20:44:43

Nagyon jó bejegyzés! Viszont: akkor nincs olyan méretű cég, ahol jó lenne projektet vezetni? :)

eckerman 2012.05.13 21:09:21

Nagyon jó lett, ilyesmi nem nagyon van a PM könyvekben.

eckerman 2012.04.26 14:18:30

Szerintem ez a folyamat minden bonyolult (értsd jól) készség megszerzésére általánosítható: aki már megszerezte, megpróbálja formálisan megfogalmazni, de teljes egészében nem lehet. A készség magas szintű ismeretéhez csak hosszú idő alatt, gyakorlással lehet eljutni. Leírtak elolvasása, kipróbálás a legegyszerűbb módon, működik, lelkesedés, gyakorlás, bukás, elkeseredés, folytatás, saját hibákból tanulás, mester-tanítvány viszony és így tovább. A módszerek változnak, de elsősorban azért, mert akik már megszerezték a készséget, azok különbözőképpen tudják elmondani: valószínűleg Grady Booch RUP használatával is nagyszerűen lemendzsel egy szoftverfejlesztési projektet, míg Robert C. Martin agilis módszert használva eléri ugyanazt az eredményt ugyanazon a projekten. De lehet hogy mi egyikkel sem jutnánk olyan messzire, mint ők. Malcolm Gladwell könyvében (www.hvgkonyvek.hu/index.php/Gazdasag-es-menedzsment/Kivetelesek/book_flypage.tpl.html?keyword=kiv%25C3%25A9telesek) olvastam a tízezer órás szabályról: úgy tűnik a szorgalom, a gyakorlás nagyobb szerepet játszik a sikerben, mint a veleszületett tehetség. Ez a jelek szerint igaz a szoftverfejlesztéshez kapcsolódó készségek megszerzésére is.

eckerman 2012.04.26 14:22:14

Ja a tanulságot kifelejtettem :) Ha valaki sokat gyakorol, egy idő után valószínűleg megszerzi a készséget és ha van hozzá motivációja, akkor megpróbálja megfogalmazni a tanultakat: és lehet hogy születik egy újabb módszertan... De ez szerintem ne akadályozzon meg bennünket abban, hogy kipróbáljuk amit mások leírtak: úgysem fog egy az egyben működni, úgysem tudjuk a tanulással járó nehézségeket megúszni.

eckerman 2012.05.02 17:00:37

@Kriminalhauptmeister Harry: A technológia gyorsan valtozik, de én a modszertanra gondoltam, mint a jo szakemberi készség gyakorlati útmutatójára. De hiába fiatal tudományág a mienk, szerintem Szent Gral nem letezik: soha sem lesz tokeletes leiras, megpedig azert amit irtam - elkepzelheto, hogy a modszertan csak a megfogalmazojanak a fogalmazasi es egyeb kepesseget tukrozi. O mar rendelkezik A készséggel es megprobalta megfogalmazni: es igy sikerult.

Szoval nincs tuti modszer es szerintem soha nem is lesz. Kungfu iskolabol is van legalabb otven es mindegyik hasonlo celt akar elerni. A leiras keves a kungfu mesterre valashoz: gyakorolni kell lehetoleg egy mester iranyitasaval. Es ha mar jol megy, akkor lehet a megtanult eszaki shaolin iskola tanitasat tovabbfejlesztve leirni es esetleg szuletik egy uj iskola.

Meg az autogyartasra sincs egyetlen mindig mukodo modszer: a Citroen mas utat kovet, mint a Toyota.

De szerintem senki sem lehet mester legalabb egy meglevo modszer alapos megismerese nélkül.

További megközelítés a tudományfilozófiai felvetésed miatt: kerdes, hogy az objektiv valosagban (van e egyaltalan ilyen) letezik valahol a MODSZER avagy nem. De ennel is fontosabb kerdes, hogy a megfogalmazások, amikről beszélgetünk, ennek a Szent Gralnak a kulonbozo minosegu formalis megfogalmazasai vagy inkabb az van, amit mondok, hogy ezek a modszerek annyit tudnak amennyire a megfogalmazojuk meg tudja fogalmazni a sajat tudasat.

Regen abban hittem, hogy letezik objektiv valosag es például a matematika, mint tudomány ennek egyre tobb szeletet irja le a sajat eszkozeivel. Az olvasmanyaim alapjan most azt gondolom, hogy az elobbirol nem tudunk semmit, az utobbi meg ugyanolyan formalis rendszer, mint a többi, azok korlataival (lasd Godel).

eckerman 2010.05.04 12:49:20

Lehet, hogy OFF, ha igen elnézést kérek.
Mi Nagy Rezsőéknél szoktunk megszállni, ha a Somlóra megyünk (ez évente 3-4szer elkerülhetetlenül bekövetkezik :)). Leírom Éva néni számát, hátha valakinek hasznos lehet: +3630/516-5281
ON