Van olyan, aki manapság programozóként nem Scrum metodológia szerint dolgozik?

10:

Abban tér el jelentősen a scrumtól, ami ott volt, hogy a sprint szerűségek teljesen máshogy működnek, más a céljuk, kizárólag a deploymentre fókuszálnak. A nagyobb feature-ök nem 1 vagy 2 hét alatt készültek, hanem akár hónapokig, majd az utolsó héten ugyanolyan módon kerültek deploymentbe, mint a kis feature-ök. A rendszert nem az agilitas, hanem a banki szabályozás alakította, ennek megfelelő adminisztráció és engedélyek kikérése, megadása jellemezte a deploymentet megelőző napokat, aminek csak kis része volt pl. a regreasion teszt vagy más konkrétan fejlesztéshez kapcsolódó dolgok.

#11

"hanem akár hónapokig, majd az utolsó héten ugyanolyan módon kerültek deploymentbe, mint a kis feature-ök"

Még mindig nem látom a különbséget. Igen, vannak olyan feature-ök, amik nagyobbak, de szintén belefér. Én is tudok olyat, aminek 1-1 része készütl csak el 1 sprint alatt és mondjuk 2-3-4 sprint-ben volt elnyújtva a teljes feature, de ez attól még agilis.

"ennek megfelelő adminisztráció és engedélyek kikérése, megadása jellemezte a deploymentet megelőző napokat, aminek csak kis része volt pl. a regreasion teszt vagy más konkrétan fejlesztéshez kapcsolódó dolgok."

Szintén nem látom a különbséget.

Nálunk az utolsó 2 hétben már bug-ot sem javítunk a legtöbb esetben, mert megy a papírmunka és a testing. És komoly bug esetén kell még javítani, egyébként simán lehet, hogy csak dokumentációban térünk ki rá.

#12

"ott tényleg vakon keleltt követni a szabályokat, mert ha hibáztál, akkor ezen szabályok betartásával óvtad a s.ggedet, illetve azzal, hogy ha hibáztál, azonnal szóltál, nem sunnyogtad el."

Szintén nincs különbség, igen, nálunk is vannak security szabályokat, amiket követni kell, mert céges policy, és nem bankszektorról beszélek.

Nem mondtál semmi olyat, ami teljes mértékben összeegyeztethetetlen lenne az agilis módszertannal.

Az látom, hogy agilisak vagytok/voltatok a feature elkészültét illetően. A másik két dolog meg simán kb. jogi kötöttség.

13:

A különbség az, hogy az agilis módszertanok a fejlesztés folyamatáról is szólnak, ami nálunk volt, ott nincs semmi a fejlesztés folyamatáról, nem rendeződnek a taskok sprintekbe, a fejlesztés alatt, csak a deployment van szabályozva.

#14

Nem, az agilis módszertannak a fejlesztés folyamata része lehet, de nem kötelezően az, ahogy a deployment is ugyanúgy része lehet, de az sem kötelezően az.

15:

Ok, csak akkor mikor a tervezés nem agilis, a feladatok szétosztasa nem agilis és nem sprintekhez kötött, a fejlesztés nem agilis, a tesztelés nem agilis, a csapatok nem agilisek, mivel külön fejlesztő és tesztelő, ílletve QAPM csapatok vannak, csak a deployment hasonlít nyomokban az agilis módszertanokhoz, de az is simán beleférne egy waterfall modellbe is, akkor ok, mondjuk úgy, hogy 10%-ban agilis a módszertan.