[Javalist] Agilis projekt

[Molnár Miklós]

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