"Megértik és átélik a munkájukat" - a Scrum módszerről (1. rész)
Nagyszerű összefoglaló a Scrum-ról. Gyakorlatilag kötelező olvasmány olyan jó összefoglaló, főleg magyar nyelven :) Sajnos mint minden jó cikk ez is alkalmas arra, hogy félrevezesse az embereket. Nem melyti meg, hogy milyen feltételei vannak a Scrum alkalmazásának olyan módon, ahogy ez le van írva.
Ami hiányzik:
- Felső vezetés elfogadása: Nem működik, ha csak a fejlesztői csapat akar ilyen módon dolgozni. hiszen alapvető szerepkörök vannak, amiket tipikusan a fejlesztőkön kívülről kell hozni. Ilyen szerepkör triviálisan a Product Owner.
- Kooperatív ügyfél: Annak lennie kell. Ott ahol az ügyfél nem érhető el gyakorlatilag nem érhető el, vagy képviselőjének nincs számottevő döntési jogköre ott ez a rész ugrott. Anélkül viszont lehet iterativ és inkrementális fejlesztési módszert alkalmazni, de az nem lesz Scrum.
- Scope vagy release határidő változás kell. Természetesen a minőségből nem szabad engedni. Ahol úgy dolgoznak, hogy itt amit le kell fejleszteni erre meg erre a határidőre. Ott a munka elkezdése specifikáció és design kidolgozása nélkül veszélyes. Ha nem tudod, hogy pontosan mit fogsz csinálni, akkor felesleges elkezdened. Itt utalok a felső vezetés együttműködésére. Elsősorban a felső vezetés köti ki előre a projekt pénzügyi paramétereit és határidejét. Ez korlátozza a rugalmas munkavégzést. Ilyen esetben tudni kell előre, hogy mit tud a fejlesztő csapat elvégezni. Magyarán előre kell tisztázni a specet és a designt, hogy minél hamarabb lássuk, hogy beleférünk-e a költségkeretbe vagy sem.
- Fizetési konstrukciók: Megint szegény felső vezetők a ludasok. Mi alapján fizeted a Scrum csapatot? Órabérben? Ok, mert ebben az esetben tök jó az ügyfélnek, hogy üzleti érték alapján megy előre és megáll akkor, amikor már elégedett az eredménye, vagy éppen változtatásokat eszközöl, ha szükséges. De ekkor a fejlesztő csapat nem motivált indokolt mértékben, hiszen akkor járnak jól, ha minél tovább húzzák a munkát. Fix áras megoldás? Hmm akkor már a fejlesztői csapat motivált, hiszen bármi van, akkor is ugyan annyit kap. De akkor hogyan határozzuk meg a scopot? Mi alapján döntjük el, hogy a folyamatos változtatások mikor érik el a budget-et és mikor lépi túl? Ez egy szar téma. Nehéz is ezzel mit kezdeni. :)
- Bizalomhiány: Cikk zseniálisan felveti a projektvezetők és fejlesztők közötti bizalomhiány kérdést. Sajnos a bizalomhiány alapvető probléma, most már én is látom. Gyakorlatilag a bizalom hiánya okozza a munkahelyi problémák és panaszok jelentős részét.
Megértik és átélik a munkájukat - a Scrum módszerről - 1. rész
2010-05-19 09:49:38
akocsis
Bizony, bizony
Magyar nyelven már elég sok hasonló cikk szültetett, hogy miért nem működik az agilis/scrum/extreme programming valós üzleti környezetben.
Mert aki csinált már végig projektet, az könnyedén ír a fentihez hasonló listát.
Az agilis fejlesztés hívei eddig még nem vették a fáradtságot hogy ezekre a kérdésekre válaszoljanak.
2010-05-19 13:49:52
Marhefka István
?
akocsis: Tudnál nekem küldeni ilyen linkeket? Nagyon kíváncsi vagyok rájuk.
Azt hiszem egyébként, nem jó nyomon jársz. Az "agilis fejlesztés hívei" mindent megpróbálnak megtenni azért, hogy agilis projekteket csináljanak maguk körül. Nem azért, mert ők agilisek akarnak lenni, hanem azért, mert tudják, hogy így sokkal több értéket lehet teremteni az ügyfélnek, és nem kell értelmetlen, soha nem használt funkciókat, rossz minőségben fejleszteniük. (Igen, vannak olyanok, akiknek még számít, hogy milyen munkát adnak ki a kezük közül.)
Legtöbbször azért nem lehet agilis projektet csinálni, mert az ügyfél nem hajlandó erre. És ennek sok oka lehet. Az egyik oka a bizalomhiány (és erre - sajnos, rá is szolgált az ipar). A másik oka, hogy azt hiszik, hogy az a normális, hogy tonnaszámra kell a doksikat gyártani, és fél évig-évig kell követelményeket gyűjtögetni, és jól meg kell rágni, tervezni mindent. Aztán ha mindenki mindenben egyetért, és aláírta a papírokat, akkor fejleszthetünk. Sokan rájöttek már, hogy így nem működik a szoftverfejlesztés.
Ha úgy gondolkozunk, hogy hogyan tudjuk szerződésekkel, dokumentációkkal levédeni saját magunkat, akkor ne várjuk el, hogy minőségi, a saját érdekünknek megfelelő szoftver készül. Az ellenkező oldal is védekező mechanizmust fog felvenni, és tulajdonképpen a két oldal egymás ellenfele lesz, ahelyett, hogy kooperációban készülne el a szoftver.
Ha pedig államigazgatásról beszélünk, akkor a remek közbeszerzések kapásból garantálják, hogy agilis felfogásban nem dolgozhatunk.
Abban egyetértek Veled, hogy az interjúalany könnyen dobálózik mindenféle dolgokkal. Jogosan várja el a sok kérdező, hogy ha ennyire magabiztos a dolgában, akkor a feltett kérdésekre is adja meg az ugyanilyen magabiztos válaszait.
A kérdések mutatják, hogy a valóság sokkal árnyaltabb és bonyolultabb, mint ahogy az interjúalany állítja.
Azt is meg kell érteni, hogy az agilitás elveket jelent. Ez nem egy módszertan. Vannak ugyan agilis módszertanok és ezeknek eszközei a hatékony munkavégzéshez, de valójában pont arról van szó, hogy adaptálódni kell az adott környezethez. (Az agilitás egyik alapelve, hogy az embereket részesítjük előnyben a kőbevésett folyamatok és eszközök helyett. )
Sokan belebuknak az agile-ba. Véleményem szerint ezek az emberek akkor is buknak, ha nem agile-t használnak. Egyszerűen képtelenek az adott helyzet megfelelő értékelésére és a probléma megoldásra.
Lehet másokat hibáztatni, hogy nem működik az agilitás, szerintem inkább azzal érdemes foglalkozni, hogy hogyan tudnánk a munkánkat jobban csinálni.
Ha valaki recepteket, mintákat vár, amiket "bután" ismételgetve projekteket tud sikeresen véghez vinni, akkor egyelőre egy másik iparágat kell választania. Mondjuk az építőipart.
2010-05-19 15:59:18
akocsis
Majd küldök linkeket, most
Majd küldök linkeket, most röviden hozzászólnék.
Szeretnék rámutatni arra a lényeges dologra, hogy miközben az agilis fejlesztők az ügyfélnek akarnak értéket teremteni, addig pont az ügyfél az, aki ebből nem kér.
Mint ahogy megkaptuk a kommunizmust anélkül, hogy kértük volna, és ők is azt mondták, hogy értünk teszik.
2010-05-19 17:12:47
akocsis
Olvasnivaló
Agile sux?
http://delzubu.spaces.live.com/Blog/cns!CF46C6E2E1C94D25!251.entry
A macskákat terelő juhász
http://www.stratis.hu/files/szt_0513_PM.pdf
És saját termés:
Agilis fejlesztés multi környezetben
http://pasztor.freeblog.hu/archives/2009/03/09/Agilis_fejlesztes_multi_kornyezetben/
2010-05-19 23:45:07
nevada
Én multi és nem multi
Én multi és nem multi környezetben is vállalkozok. Az agile szerintem nagyon jó - de vannak feltételei amikor alkalmazható.
Agile nálam bevált, kisebb cégek motivált vezetőivel és csapatával, gyors és rugalmas fejlesztést tesz lehetővé, bizalom kell hozzá és hogy meggyőzd hogy ez neki is jó lesz. Az első projekt után jellemzően már nem szorul magyarázatra hogy miért így.
Agile nem volt jó multi környezetben, mert alapvető vezetői szabály az "Ülni és ülni hagyni." Persze a jó szoftver itt is fontos de inkább csak szóban, alapvetően nem ez mozgatja a dolgokat. Rengeteg rossz szoftver él túl évtizedeket, mert nagy galibát nem csinál, sok embernek munkát ad, és teszi a dolgát - így úgy, de működik. Nem érdeke senkinek a jelentős változás. A terület felelőse markolja a székét, a szoftverfejlesztő cég folyamatosan kapja a bevételt.
Lehet vitatkozni hogy ez jó e. Az agile hatékonyan megoldja a szoftverfejlesztési problémákat, van válasza és módszere a felmerülő kérdésekre. Kérdés hogy az adott projektnék van e erre igény.
Én csinálom mindkettőt és azt mondom, hogy jó jót csinálni is, meg sokat keresni viszonylag kevés munkával is.
Más kérdés hogy ez így jól van e, de szerintem jelenleg a multiknál többet nyom a latba a politika mint a módszertan.
Az előző hozzászóló azt írta hogy "Lehet másokat hibáztatni, hogy nem működik az agilitás, szerintem inkább azzal érdemes foglalkozni, hogy hogyan tudnánk a munkánkat jobban csinálni."
Ez attól függ mi a cél. Lehet a langyos vízben is sokáig fürödni. És lehet jövedelmező is. És lehet hogy az adott helyen pont erre van igény.
Kezdő fejlesztő koromban akartam mindent optimálisan csinálni. Ma már csak ott akarom optimálisan csinálni, ahol arra igény van.
2010-05-21 09:29:52
g.gyimesi
Tapasztalataim
Egy informatikai mikrovállalkozást vezetek, főként webes fejlesztésekkel foglalkozunk. Eddigi tapasztalataim szerint mindig az aktuális helyzet határozza meg, hogy milyen módon kell a projektet kivitelezni. Nem vagyok híve a módszertanok "vak" követésének, mert ezt a legtöbbször nem lehet. Tudni kell alkalmazkodni az új helyzetekhez, és nem félni menet közben változtatni a fejlesztési stratégián.
Eddig alapvetően két fajta ügyféltípust fedeztem fel.
1., "ne szólj hozzám" típus: Tipikusan konkrét elképzelése van, hogy mit szeretne, és nem is akar hallani rólunk, csak a fejlesztés befejezésekor. Ez esetben egy használható technika van: a projekt indulásakor mindent ledokumentálni, és egy lendületből lefejleszteni mindent.
2., "na hogy álltok?" típus: nekik üzleti elképzeléseik vannak. Általában, csak nagy vonalakban tudják, hogy mit szeretnének. Velük heti egyeztetés szükséges minden fejlesztési hét/2 hét végén relase átadás, és egyeztetés. Ez üzleti szempontból veszélyesebb, szerintem.
Ami nekem nagyon jól működött, hogy ügyfél típustól függetlenül megkeverem a két "hozzáállást".
Kap egy 80%-ban kidolgozott specifikációt és egy puffer időt ami lefedi azt a 20%-ot ami nincs specifikálva.
Ezután lefejlesztjük a 80%ot egy ütemben, onnantól minden héten kap egy új verziót, amit tovább gondolhat.
Kis céges környezetben én így látom a helyzetet. Fő az ALKALMAZKODÁS!
Természetesen ahogy nő a szervezet, minden elkezd egyre problémásabbá válni, ahogy az információ egyre nagyobb utat jár be a cégen belül. Általában a probléma mindig a felső vezetés eltérő gondolkodásmódjából adódik, vagy abból, hogy az információ nagy része el sem jut hozzájuk.
May 19, 2010