[Javalist] Agilis projekt

[Gábor Garami]

Egy nagyon fontos felreertesrol szeretnek meg beszelni:

"Igen elfogadható a megrendelőnek, hiszen folyamatosan fizet."

A kettonek semmi koze egymashoz. A megrendelo azert fizet, mert
egyszer kapott mar valami termeket, es a legolcsobb mindig az eredeti
csapatot megbizni a karbantartassal is. Mondjuk inkabb ugy, hogy a
megrendelo valoszinuleg meg nem elegedetlen annyira, hogy ne fizessen.
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 Gábor Garami <gabor.garami at hron.me>:
> 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