[Javalist] Agilis projekt

2013. Sze. 29., V, 22:00:38 CEST

Eloszor is, en megprobalnam a meglevo rendszert optimalizalni. Azt
mondod, hogy sok Excel van, sokfele verzioban, sok gepen. Ezt egy
kozos Google Docs alapu megoldas kivaltana, es legalabb a verziok
egysegesek lennenek, ha es amennyiben a Product Ownerek azt az apro
dolgot keresztul tudjak vinni a megrendelokon, hogy mindenki ugyanazon
a GDocs sheeten dolgozik. Ez elvben nem tul nagy feladat, tehat
barmely Product Ownernek meg KELL tudnia birkozni vele.

Azutan le kell ulni a vezetokkel, es beszelni. Es
beszelni-beszelni-beszelni. Akar meetingen kivul is. Ha a csapat nem
erti, nem tudja, hogy az adott funkcionak mi a celja, akkor csak
lefejlesztik a funkciot, aminek azutan semmi koze nem lesz a
szoftverhez. Egy alapvetoen sarga falon is nagyon rosszul fest egy
bugyirozsaszinre festett konnektor, barmily apro resze is legyen ez a
fal egeszenek. Ha nem illik bele az adott funkcio a szoftverbe, akkor
valaki valahol mar nem erti az igenyeket, es ezt mindenkepp el kell
kerulni. Ha a Product Owner nem hajlando ezt figyelembe venni, akkor
melyebbrol, de visszajelzesnek kell mennie, hogy baj van, mert egy ido
utan mar a sokkal komolyabb problemak is el fognak sikkadni.

Nem tudom, en nem ertek ezekhez a modszertanokhoz, es amikor en nem
ertek valamihez, akkor mindig eloveszem a sufnibol a jozan paraszti
eszemet, es raengedem a problemara. Most az jott ki, hogy lehet egy
modszertan akarmilyen dinamikus, viselhet akarmilyen szep es jol
hangzo nevet, ha alapveto problemak vannak a csapaton beluli, illetve
a csapat es a vezetes kommunikaciojaban, ha nem erti meg egyik a
masikat, akkor NEM MUKODIK. Az kulon rossz dolog, ha a csapat azt sem
erti, hogy honnan indultak es hova tartanak. Itt tenyleg az van, hogy
nalatok a cegvezetes elokapott egy jol hangzo modszertant, es annak
alapjan elnevezte a cegeteknel uralkodo kaoszt. Ettol azonban a
kaoszbol meg nem lett rend, csak nevet kapott, oriasi kulonbseg.

Ha es amennyiben nem lehet keresztulvinni azt, hogy a meetingen belul
a csapat szamara letfontossagu informaciok elhangozzanak, akkor addig
kell rangatni a kollegialis szalakat, amig ezek az informaciok
elhangoznak valakitol. Ezen felul valakinek a sarkara kell allni, es
megszervezni legalabb a csapaton beluli es a csapatok kozotti
informaciocseret. A ti erdeketek is, hogy ne homlokegyenest ellenkezo
iranyba menjetek csak azert, mert ellentmondasos dokumentaciok es
ellentmondasos informaciok keringenek. Elso szabalykent el is lehet
fogadni: ha valaki megtud valamit, azt korbekuldi a csapaton belul.

Egyebkent en megkockaztatom azt, hogy a megfelelo kerdesek
megvalaszolasa van olyan fontos, hogy akar keresztul is gazoljunk a
szervezeti hierarchian, es egybol a megfelelo embertol kerdezzunk.
Persze, lenyeges, hogy olyan legyen a kollegialis viszony, hogy ez
megteheto legyen kellemetlen mellekhatasok nelkul. Tudom, hogy ez
gyakorlatilag minden modszertan ellen valo, azonban a modszertanok es
a szervezeti hierarchiak elsosorban a kommunikacio hatekonysagat es a
termek gyors es pontos elkeszultet KELL hogy szolgaljak, es nem szabad
az iranyokat megforditani. Nem szolgalhatja a termek a ceg hierarchiat
vagy a kommunikacio a modszertant.

Ne varj gyors javulast, ez hosszu folyamat. Es azt se vard, hogy
minden csettintesre megvaltozik, csak ki kell varni: neked is boven ki
kell venned a reszed a dolgokbol. Keress olyanokat, akik legalabb az
altalad felvetett problemak egy reszet latjak, ulj le veluk, es
probaljatok meg ertelmes megoldasokat kitalalni. Ha vezetoi szinten
nem latszik a problema es megfelelo tajekoztatas mellett (!!!) sem
tortenik meg a problema letenek elfogadasa, akkor nektek kell
kitalalnotok, es valahogyan megszervezni a megoldast is, akar segitseg
nelkul is.

Van meg egy lehetoseg: kulsos scrum-szakerto bevonasa aki elkezd
monitorozni bizonyos jol definialhato metrikakat a cegnel, es a
vezetes szamara tenykent kezelheto formaban bemutatja, hogy ennel a
cegnel bizony kaosz van, espedig azert, mert a munkatarsakkal valo
kommunikacio nem megfelelo, es/vagy akar azt is, hogy a valasztott
modszertan a ceg projektjei szamara nem megfelelo. Mert ilyen is
letezik. Ugyanis egy modszertant nem a korulotte levo hype vagy a
nepszerusege alapjan kell kivalasztani, hanem meghatarozo az, hogy
milyen jellegu projektek vannak es milyen jellegu ugyfelek.

Egy scrum-hoz nalam jobban erto ember majd ugyis elmondja ezt a
megfelelo szakkifejezesekkel harom mondatban, nekem ez 7 bekezdesbe
telt.

Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
MSN: hrgy at vipmail.hu
Skype: hron84

2013/9/29 Molnár Miklós <timortinj at freemail.hu>:
> Sziasztok,
>
> Köszönet a sok reakcióért, egy rövid feedback:
>
>>>>>>>>>>>>>>>>>
> Ez itt egy komolya gond szerintem. Egy BA-nak feladata az információ
> beszerzése és azok karbantartása. Ha ezt nem teszi meg, akkor
> szereptévesztésben van. Én azt gondolom, hogy a felelősségi köröknek a
> folyamatban tisztának és egyértelműnek kell lenni.
>>>>>>>>>>>>>>>>>
>
> A BA beszerzi, karbantartja, tudja, el is mondja az információt, ha kérdezik
> őt. Csak nem írja le. ;)
> Illetve hazudok. A két amerikai BA egymással sem konform néha, ami aztán
> nálunk derül ki, adott esetben implementálás után. ;)
>
>>>>>>>>>>>>>>>>>
> A kapkodva az egy kényelmetlen dolog és eszi az ideget. A hibákkal
> kapcsolatban a kérdés, hogy ezek elfogadhatóak az ügyfél számára vagy sem? A
> QA processz nem fogja meg őket? Visszavezethetőek arra, hogy nem kaptok
> nomális, használható információkat a BA-től?
>>>>>>>>>>>>>>>>>
>
> Ne is mondd. Ezért is fojtottam bánatomat betűkbe.
> Igen elfogadható a megrendelőnek, hiszen folyamatosan fizet.
>
> De. A QA megfogja:
> Amire nekem nem nagyon volt korábbról tapasztalatom az egyik excel-sheet
> tömegnek a rossz verziója került hozzám (alapjaiban volt más), ami csak a
> validálásnál derült ki. "Nem probléma", kifizették az elsőt is.
> Komolyan mondom: mindezt leírom és nem akarom elhinni még magamnak sem. ;)
>
> Amúgy meg normális infót kapunk, csak elegendőt nem. ;)
>
>>>>>>>>>>>>>>>>>
> A másik, hogy az agilis világnak része a processz folyamatos fejlesztése.
> Újabb dolgok kipróbálása és azt kell megtartani, ami műkszik.
>>>>>>>>>>>>>>>>>
>
> Na erről is tudnék mesélni. ;)
> Helyhiány miatt a részletekbe nem belemenve (ezt nekem kell sajnos
> elhiggyétek), a lényeg, hogy az architektúra koncepcionálisan agyrém, és
> bármi változtatás rosszabbá teszi az eddigi tapasztalat szerint.
> Egyetlen dolog lehet, ami feloldhatja ezt, hogy van valami olyan érv, amiről
> mi nem tudunk és az üt mindent.
>
>>>>>>>>>>>>>>>>>
> Szerintem itt van a válasz a kérdésedben. Ha a CR magával vonja azt, hogy
> több időt kaptok a fejlesztésre, és azt ki is fizetik, akkor innentől fogva
> nem értem a kérdést.
>>>>>>>>>>>>>>>>>
>
> Főnököm is ezt mondja. ;)
>
>>>>>>>>>>>>>>>>>
> Szerencsére az összekötőnk jól menedzselte az egészet, és ha jeleztük, hogy
> egy cr megvalósítása sok időbe kerül, akkor azt szépen leegyeztette a
> megrendelővel. Plusz kb a projket fele után csak minimális változtatásokat
> engedett be, a nagyokat visszadobta, vagy több időt kért hozzá.
>>>>>>>>>>>>>>>>>
>
> Kb. nálunk is, annyi nehezítéssel, hogy mindenki szerteszanaszét dolgozik és
> időhiány miatt ezen a fronton is csúsznak be hibák, ami aztán később
> négyzetre is tudnak emelődni.
>
>>>>>>>>>>>>>>>>>
> Most lehet, hogy magamra fogom haragitani az osszes agile hivot a listan. De
> oszinten szolva nem erdekel.
> Eloszor is, a ketoras telefonos meetingek feleslegesek, mert egyaltalan nem
> az tortenik rajta, aminek tortennie kellene. Ha nincs, nem tud kialakulni a
> megfelelo informacioaramlas abbol jo minosegu kesztermek az eletben soha nem
> lesz. Lehet, hogy lesz kesztermek, sot azt mondod van is, de el kellene
> gondolkodni, hogy hany olyan bugotok volt, ami informaciohiany miatt alakult
> ki, esetleg egy uzleti igeny nem pontos, nem megfelelo ismerete miatt.
> Szerintem az, hogy mindenki tisztaban legyen mindennel elengedhetetlen a jo
> minosegu szoftvertermek eleresehez.
> Aztan, en nem gondolom azt, hogy az agilis modszertannak koze kellene hogy
> legyen a dokumentaciohoz. Minden projektnek rendelkezni kell _valamilyen_
> dokumentacioval. A dokumentacioba mindenkepp bele kell tartozzon a
> specifikacio, illetve adott esetben az user storyk is.
> Szedett-vedett excel fajlokbol csak szedett-vedett szoftverek szoktak
> szuletni, ahol senki nincs tisztaban az igenyekkel.
> Raadasul a szoftver karbantarthatosaga sinyli meg, ha a fejlesztes soran nem
> keszulnek el a megfelelo kiegeszito dokumentaciok, legalabb a deploymenttel,
> az uzemeltetessel illetve a fejlesztoi kornyezet setupjaval kapcsolatban. Es
> ez fuggetlen attol, hogy a cegnel agile, waterfall, vagy valami mas
> modszertan alapjan fejlesztenek.
> "Még az se látszik, hogy miből indulunk és hová tartunk, annyira komplex,
> több-sheetes(sit-es) a cucc"
> Ez a mondat az, ami leirja szamomra azt, hogy a cegetek nagyon nem jol
> mukodik, a belso kommunikacio nalatok valahol nagyon kisiklott, a vezetoitek
> nem, vagy rosszul kommunikalnak feletek.
> Viszont ezek ellen elsosorban te tudsz tenni. Emeld fel a hangod,
> hangoztasd, hogy nem erted a dolgokat, es mondd el, hogy bajok vannak.
> Ugy gondolom, hogy egy fejlesztoceget nem az altala hasznalt modszertannak
> kell jobba tennie, hanem az ott dolgozo embereknek. Es nem gondolom azt,
> hogy barmely csapattarsad jobban atlatja a dolgokat, legfeljebb mar jobban
> hozzaszokott ehhez az orult szaguldashoz.
> Garami Gábor
>>>>>>>>>>>>>>>>>
>
> Gábor annyira egyetértek veled, hogy az egész szöveget visszaidéztem. :)
>
> Sajnos kimondott definitiv cél, hogy nincs dokumentálás. Ahogy Viktor
> beszúrta http://agilemanifesto.org/, úgy szereznek neki érvényt.  Én még
> mindig emésztési fázisban vagyok.
>
> Így van: rengeteg a párhuzamosság, a redundancia. Semmiképpen nem mondanám,
> hogy egyenszilárd szoftvert fejlesztünk. És ez nekem baromira fáj szintén:
> csak azt nem látom át, hogy mi minek a folyománya.
>
> Jogos és fel is emeltem a hangom: de több víznek kell lefolynia a Dunán,
> hogy ennek foganatja is legyen.
>
> Így van: én vagyok lassabb, a többiek meg "őrülten száguldoznak", sőt
> mondanám, hogy vígan (legalábbis kívülről nézve). Ez is nehezíti a
> hepciáskodásomat. "Nem lehet, hogy egyik szembejövő autó vezetője sem ismeri
> a kreszt"-szindróma (egyirányú utcában).
>
>>>>>>>>>>>>>>>>>
> Ha nincs lehetőség változtatásra, a processz hangolására, akkor az nem igazi
> agilis fejlesztés. Akkor mégsem csináljátok jól.
>>>>>>>>>>>>>>>>>
>
> Permanens változás van ilyen téren is. Csak a komfortzóna van a béka feneke
> alatt konstansan. ;)
>
>>>>>>>>>>>>>>>>>
> A Business Analyst kérdést nem nagyon értettem. Agilis fejlesztésnél Product
> Owner van. Ha BA is van a csapatban, az megint nem agilis fejlesztés hanem
> valami ad hoc dolog.
>>>>>>>>>>>>>>>>>
>
> Nem adhoc, hanem mix. ;)
>
>>>>>>>>>>>>>>>>>
> Speckó, doksi abszolút attól függ, hogy milyen célra készül.
>>>>>>>>>>>>>>>>>
>
> Speckó mint olyan nem készül(t). ;)  Kószáló állományok vannak, különféle
> verziókban, különféle gépeken. ;)
>
> Ráadásul verziókezelés nélkül. Szombatra készült el végre valahára az az
> SVN, ahová a megrendelő is, mi is tudunk már végre dolgozni (nem nálunk).
> Egy "kicsit" ideje volt már. ;)
>
>>>>>>>>>>>>>>>>>
> A user story-kat általában illik leírni pár szóban.
> Ha félreértések vannak, akkor a további user story-kat részletesebben kell
> leírni. Ha mindenki tud mindent és nincs félreértés, nem kell annyira
> részletezni. Lehet hogy tényleg le sem kell írni. (Alkalmazkodni kell.)
> Definition of Done-t is illik leírni, hogy mikor gondolja úgy a csapat hogy
> készen van egy sztori. Van ahol ezt kiteszik a falra 48 pontos bold fonttal
> nyomtatva.
> Hasznos dolgokat illik leírni. Azonos helyen működő csapatoknál néha a
> "dokumentációt" egy halom színes post-it jelenti a falon. Van ahol működik
> (van ahol nem).
>>>>>>>>>>>>>>>>>
>
> Na ilyenünk van. Az egy kérdés, hogy mennyire tekintjük működőképesnek.
> Szerintem
> - túl nagy falat a feladat, agilis projekthez
> - túl sok minden változik, túl gyakran
> - túlterheltek vagyunk
> - de a lényeg, hogy az ördög a részletekben lakozik (ami nem fér ki a
> táblára).
> Hiába értem én, hogy egy Excel-t kell kiváltani, meg hiszi mindenki, hogy jó
> Excel van nálam, ha mégsem. ;)
>
>>>>>>>>>>>>>>>>>
> Jira, Wiki, Google Docs, ilyeneket szoktak használni.
>>>>>>>>>>>>>>>>>
>
> Én azt gondolom ez csak akkor ér valamit, ha a megrendelőnél van és ő is
> komolyan veszi (olvasását és írását).
>
>>>>>>>>>>>>>>>>>
> UML diagramokat és többszáz oldalas Word doksikat gyártani (generálni), csak
> hogy meglegyen kilóra...az értelmetlenség másik formája.
>>>>>>>>>>>>>>>>>
>
> Abszolút egyet van az értés. De nálunk nem a doksi-szállítás a probléma,
> hanem a -begyűjtés. Illetve mint ugye kiderült az sem. ;)
>
>>>>>>>>>>>>>>>>>
> Megjegyzés: én a cégnél viszonylag új vagyok, de kiderült, hogy az agilis
> fejlesztés már egyszer ellaposodott, és bizonyos elemei el-elmaradoztak, míg
> végül teljesen kifújt. Az egész fejlesztési metodológiát kb. 3 év után újra
> kellett indítani egy külső scrum tanácsadó segítségével. Nem tudom, hogy ez
> nálunk sajátosság, vagy máshol is előfordult.
>>>>>>>>>>>>>>>>>
>
> Valahogy én is így érzem, de a világ körülöttem nem ezt mutatja. ;)
>
>>>>>>>>>>>>>>>>>
> http://derrickesharry.blog.hu/2013/09/01/besenyo_pista_bacsi_agilis_modszert
> ani_tanacsai_1_resz
> http://derrickesharry.blog.hu/2013/09/08/besenyo_pista_bacsi_agilis_modszert
> ani_tanacsai_2_resz_napi_stand-up_meeting
> http://derrickesharry.blog.hu/2013/09/15/besenyo_pista_bacs_agilis_modszerta
> ni_tanacsai_3_resz_napi_munka
> http://derrickesharry.blog.hu/2013/09/22/besenyo_pista_bacsi_agilis_modszert
> ani_tanacsai_4_resz_a_bemutato
>>>>>>>>>>>>>>>>>
>
> Köszi István, mégegyszer.
> Fájt a nevetés az olvasásakor: a szó szoros és átvitt értelmében is. ;)
>
> MM
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist