[Javalist] Agilis projekt

2013. Sze. 30., H, 11:28:33 CEST

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

Ehhez az ugyfelnek nagyjabol koze nincs, egyebkent meg szerintem
elbagatellizalod a kerdest. Eloszor is, a cegnek sem jo, ha a
munkavallaloi nem erzik jol magukat a cegen belul. Meglatszik a
minosegen, meglatszik a hozzaallason, meglatszik a lojalitason. Senki
nem szeret olyan cegben dolgozni, ahol teljes mertekben ignoraljak, a
legtobb ember menekul az ilyen helyekrol. Ma mar szerencsere van annyi
munka es van annyi fejlesztoceg, hogy igazabol senki nem kotelezhet
teged arra, hogy az XY Kft-nek dolgozz. Valamit a cegnek is tennie
kell, hogy erdekeltte tegyen abban, hogy ot valaszd es huseges legyel.
Arrol nem is beszelve, hogy egy ignoralt dolgozo kozep- vagy
hosszutavon nagy esellyel motivalatlanna valik. Az pedig aztan vegkepp
rossz minden szereplonek.

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

Nem ertem, hogy jon ide az agilitas. Alapvetoen eleve nem ertem azt,
hogy miert nincs nalatok vagy belul egy dokumentumtarolo (Samba
megosztas, vagy valamilyen kimondottan ilyesmire tervezett megoldas),
ahol mindenki kozpontositva latna az egyes projektekhez tartozo
dokumentumokat. El nem tudom kepzelni, hogyan lehet ugy dolgozni, hogy
nem lehetek biztos abban, hogy Jozsi pont ugyanazokat a
dokumentaciokat latja, mint en.  Lehet, hogy egymasnak ellendolgozunk,
es ez csak a vegen derul ki? Hogy lehet ilyet megengedni
projektvezetokent? Tudom, megint siralmasan tudatlan vagyok.

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

Az a problema, hogy ha mindenki azt mondja, hogy "de hat elmukodik igy
is a ceg", akkor ezek a problemak soha a budos eletben nem lesznek
megoldva. Egeszen pici kulonbseg van a "megy a szeker" es a "jol megy
a szeker" kozott, megis teljesen mas a ketto.
Mondok elvont peldat: Vagy elviseled azt, hogy egesz ejjel csepeg a
csap, vagy nekiallsz megjavitani magad, vagy kihivsz egy szerelot. Ez
a harom variacio van, ebbol lehet egy megoldast valasztani. Nyilvan a
legegyszerubb es a legocsobb a csap ala rakni egy szivacsot, hogy
legalabb ne csapkodjanak a cseppek, aztan tobbet nem foglalkozni a
dologgal.
Viszont a csepego csap a vegen rosszabbra fog fordulni, teljesen
bevizkovesedik, vagy esetleg eltorik a cso. Es amikor mar nagyon nagy
a baj, akkor nagyon fajdalmas es draga a megoldas.
Addig kell beavatkozni, amig a problemak nem latszanak meg a termeken,
mert addig meg kommunikacioval, belso atrendezodessel kezelheto a
dolog, es nem kell az ugyfel szintjen megjelenjen a baj. Amikor mar a
termek minosege szenvedi meg a problemakat, akkor az nagyon draga lesz
mind a cegnek, mind pedig az ugyfelnek.

A te dontesed, vegulis azt csinalsz amit akarsz. Csotoresnel is lehet
a kikoltozesi opciot valasztani. De azert a cseppeket szamolni sosem
teljesen haszontalan.

Udv,

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