[Javalist] Agilis projekt

2013. Sze. 29., V, 23:47:27 CEST

>>>>>>>>>>>>>>>>>
Ezt egy kozos Google Docs alapu megoldas kivaltana
>>>>>>>>>>>>>>>>>

Security ok miatt tuti esélytelen. Ráadásul egy ilyen átállás nem megy
agilisen, szvsz.
Esetemben dolgozni kell és szállítani.
Csak olyan módosítás megy át, amit elbír az agilis projekt.
Ha meg tényleg újra kellene gombolni a kabátot arra meg öten hatfélét biztos
mondanának.
És az enyém lenne csak a hetedik ;)

>>>>>>>>>>>>>>>>>
Azutan le kell ulni a vezetokkel, es beszelni.
>>>>>>>>>>>>>>>>>

A scope nem az, hogy én jól érezzem magam, pláne a magam képére formáljam a
világot.
Hanem, hogy a kapcsolat fennmaradjon.
Mi dolgozunk, ők fizetnek.

>>>>>>>>>>>>>>>>>
ha alapveto problemak vannak
>>>>>>>>>>>>>>>>>

Van aki szerint nincs. ;)

>>>>>>>>>>>>>>>>>
Ezen felul valakinek a sarkara kell allni
>>>>>>>>>>>>>>>>>

Vannak diplomáciai, meg politikai problémák is, meg amikről nem is tudunk.
Vannak a projekt során - hogy is mondjam - nem kellő hangsúllyal eröltett
információk, amikre oda kell figyelni (kettős beszéd).
Szó nincs őszinteségről vagy pláne teljeskörű és objektív-szempontú
projekt-optimalizálásról.
A kétoldalú optimalizálás legfőbb célja, hogy a kapcsolat fennmaradjon, ők
megkapják, amit akarnak, mi meg megéljünk.
A perszonális problémák meg konvergáljanak a nullához. ;)

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

Ezek képlékeny dolgok és rakás pénzbe kerülnek.
Nem bírja el ez a projekt.
Ráadásul csomó más, másmilyen módszertanú projekt is van.

>>>>>>>>>>>>>>>>>
Keress olyanokat, akik legalabb az altalad felvetett problemak egy reszet
latjak
>>>>>>>>>>>>>>>>>

A problémák (egy részét mindenképpen) mondhatni mindannyian látjuk.
Viszont csak én csinálok ebből az egészből kabinetkérdést, engem nyomaszt a
legjobban, úgyis mint egyébként legöregebbet...

>>>>>>>>>>>>>>>>>
Mondjuk inkabb ugy, hogy a megrendelo valoszinuleg meg nem elegedetlen
annyira, hogy ne fizessen.
>>>>>>>>>>>>>>>>>

Ennek objektív számszerűsítésére még én sem vállakoznék.
A cégnek csak az én tudomásom szerint minimum 3+ éve dolgozunk
beszállítóként.
Símán benne lehet a pakliban, hogy csak én látok túl sötéten.
Meg én tudok a legkevesebbet: lásd dokumentálatlanság felhánytorgatásának
oktalansága. ;)

-----Original Message-----
From: javalist-bounces at lists.javaforum.hu
[mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Gábor Garami
Sent: Sunday, September 29, 2013 10:01 PM
To: Java lista
Subject: Re: [Javalist] Agilis projekt

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
_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu
http://lists.javaforum.hu/mailman/listinfo/javalist