játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5448
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2520

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
SCRUM - garázsprojectre kiélezve 2008.06.23 14:24
- Nyisztor Károly (Carlos) C - Játéktervezés
- Ugrás a hozzászólásokra


Nem csak a rögbiben működik!

A SCRUM egy agilis szoftverfejlesztési módszertan, amelyet Jeff Sutherland, John Scumniotales és Jeff McKenna fejlesztett ki 1993-ban, az Easel vállalatnál. A módszertan egyre népszerűbb, ami Ken Schwabernek, valamint a Scrum Alliance (www.scrumalliance.org) tevékenységének is köszönhető. Sikeréhez az is hozzájárul, hogy egy demokratikus, rugalmas, felelősség- és eredményközpontú megközelítést alkalmaz.

Elsősorban kis csapatok (5-9 fő) esetén alkalmazható jól, de némi fantáziával és leleményességgel egyemberes project esetében is működik.

A módszer sokkal emberközpontúbb, mint más, jól bejáratott és szokványos modellek (V-modell, vízesés-modell): itt mindenki osztozik felelősségben és sikerélményben egyaránt, és nincsenek beégetett felelősségi körök. Ha valaha is úgy érezted, hogy túl sok a kis és nagyfőnök, akkor ezt a megközelítést imádni fogod!

A SCRUM két szerepkör-csoportot definiál: "csirkék" és "malacok" - a következő viccből kiindulva (az eredeti, angol nyelvű változat a cikk végén szereplő wiki oldalon olvasható):

"A malac és a csirke együtt sétálgatnak. A csirke kisvártatva megszólal:
- Figyelj, mi lenne, ha beindítanánk közösen egy gyorsbüfét?
A malac felkapja a fejét az ötletre:
- Benne vagyok! Már csak valamilyen frappáns menüt kellene összehozni!
A csirke rávágja:
- Mit szólnál például a sonkás rántottához?
A malac rövid gondolkozás után ezt válaszolja:
- Inkább hagyjuk az egészet, ez a buli mégsem érdekel annyira..."

Lássuk a "malacokat" - tehát azokat a résztvevőket, akik mindent "beleadnak" a projectbe:

A termékgazda (Product Owner)
A termékgazda a megrendelőt képviseli, akivel - jó esetben - folyamatosan tartja a kapcsolatot, egyeztet és tisztázza a követelményeket. A tevékenységének a végeredménye a fontossági sorrendbe állított tennivaló-lista, avagy a "Product Backlog".

A ScrumMaster
Elsődleges feladata az akadályok elhárítása, ezzel elősegítve a csapat zavartalan munkáját a közös cél elérése érdekében. (Példa: amennyiben az egyik csapattagnak sok projecten kívüli tevékenysége van, akkor elintézi, hogy mentesüljön ezek alól.)
A másik fontos szerepe a Scrum folyamatainak betartatása.

Megjegyzés
A félreértések elkerülése végett: a ScrumMaster nem "főnök", ugyanolyan csapattag, mint a többi szereplő - bár egyesek hajlamosak ezt félreérteni és hibásan alkalmazni. Ez valószínűleg annak tudható be, hogy más, kevésbé "demokratikus" módszertanokban hierarchikus megközelítést alkalmaznak, és ezek elterjedtebbek, mint a SCRUM.
Gyakorlatilag nincs klasszikus értelemben vett "főnök", csak egyfajta mentor - a már említett termékgazda -, illetve moderátor - a SCRUM master.

A csapat (Team)
A csapat felelős a kitűzött cél eléréséért, végezetül a termék leszállításásért.
Általában 5-9 fő az ideális csapatméret - illetve nagyobb létszám esetén ilyen méretű SCRUM-teamekre érdemes osztani az embereket. Különböző szakterületeket lefedő képességekkel rendelkező emberekből ajánlott összeállítani a csapatot, úgy mint: rendszertervező, fejlesztő, tesztelő, minőségügyis szakember.

Megjegyzés

Természetesen lehetnek átfedések a szaktudást illetően, sőt! Nem titkolt cél annak elérése, hogy mindenki kóstoljon bele kicsit a többi szakterületbe. Ez ismét furcsa lehet, bár nagyon is ésszerű hozzáállás egy kis méretű csapat esetében, ahol nincs lehetőség helyettesek biztosítására; ezért kifejezetten jól jön, ha például a felhasználói felületet vagy a pályaeditort fejlesztő kolléga megbetegedése esetén sem áll meg az élet.

A "csirkék" - azaz azok a szereplők, akik a szó szoros értelmében ugyan nem vesznek részt a projectben, mégis figyelembe kell venni őket:

A Felhasználók
Nekik készül a termék, ezt jobb szem előtt tartani.

Megjegyzés
Léteznek nagyszerű szoftverek, amelyek mérnöki szempontból nagyszerű alkotások, azonban látszik, hogy nem vették figyelembe a tényleges felhasználói igényeket (aki használta már a Blender-t, az tudja, miről beszélek! ;))

Ügyfelek, forgalmazók, támogatók, üzleti elemzők (Stakeholders)
Ők azok, akik érdekeltek a végtermékben, esetleg a SCRUM folyamatban, azonban nem vesznek részt a fejlesztésben. Ebbe a csoportba tartozik például a vevő vagy a külső szakértők.

Megjegyzés
Az agilitás egyik fő jellemvonása, hogy bevonja a vevőket és az üzleti szereplőket a folyamat bizonyos részeibe. Azáltal, hogy érdekeltté tesszük őket a készülő termékben, hasznos információkhoz juthatunk.

Némileg adaptálva, a garázsprojectek esetében ez leginkább annak felel meg, amikor megfelelő fórumokon demókat bocsájtunk közszemlére, és figyeljük a visszajelzéseket. Jótanács: számítsunk a negatív kritikára, és ne legyük sértődősek.

Rövid (általában egy hónapos), sprintnek nevezett szakaszokban folyik a fejlesztés. A sprint három szakaszból áll:

1. Sprint megtervezése (Sprint Planning)
A tervezési értekezleten az egész csapat részt vesz, és megtervezi a sprint céljait. Az alap a Product Owner kívánságlistája, azaz a korábban említett, tennivalókat tartalmazó lista ("Product Backlog"). A lista az újabb fejlesztési igényeket, illetve az előző sprint eredményében talált hibákat tartalmazza.
A tervezés során a csapat kiválasztja azokat a feladatokat, amelyeket bevállalhatónak tart a fennmaradó időszakra. Az összetettebb feladatokat a termékgazdával egyeztetve részfeladatokra, kisebb fejlesztésekre bontják, amelyek beleférnek a viszonylag rövid sprint időszakba. Időnként a sprint-tervezési folyamat belassulhat - például az összetettebb feladatok szétbontása, az elvárások pontosítása miatt - ezért nem ritka, hogy egy sprint megtervezése akár két napot is igénybe vesz.
A tervezés végére létrejön - közös megegyezés alapján - egy részletes, lebontott akciótervvel, időbecslésekkel ellátott feladatlista. Ez az úgynevezett "Sprint Backlog".

Megjegyzés
Rossz jel, ha a feladatlista két napnál hosszabb feladatokat tartalmaz - az ilyen monolitokat ajánlott jobban szétbontani. A "nagy falatok" arra utalnak általában, hogy a teendő nem elég világos, és ebből szinte biztosan adódnak problémák. Persze vannak kivételek, de tapasztalataim szerint ilyenkor érdemes kielemezni a témát.

Egyszemélyes project esetén is kell tervezni, hiszen itt a legfontosabb a precizitás és az önfegyelem. Javaslom az AbstractSpoon ToDoList nevű eszközét erre a célra (http://www.abstractspoon.com/tdl_resources.html)

2. A sprintcélok megvalósítása
Következik a megszakítás nélküli közös munka, amikor a csapat a munkára koncentrálva megvalósítja a sprint céljait. (A zavaró tényezők kivédése a Scrum master feladata.)
A gyakorlatban ez úgy néz ki, hogy mindenki magához vesz egy feladatot a sprint backlog-ból, majd ha befejezi, jöhet a következő, gazdátlan teendő.
A haladásról a naponta megtartott, negyedórás összejöveteleken számolnak be egymásnak: ez az úgynevezett "daily scrum", ahol a fejlesztők kizárólag három kérdés megválaszolására szorítkoznak:
- Mit csináltál az előző "daily scrum" óta?
- Mit csinálsz ma?
- Akadályozza valami a munkádat?

A megoldási javaslatokat, részletekbe menő vitákat kerülni kell ezeken az összejöveteleken - ennek kivédése a SCRUM master feladata. A kérdések tisztázását a daily scrumot követő megbeszélésen ajánlott megejteni, lehetőleg kizárólag az érintett felek bevonásával. Itt érvényesül a "szabad lábak" elve, azaz bárki távozhat, akit nem érint a tisztázandó témakör.

A "daily scrum" feladata, hogy minden csapattag értesüljön a project előrehaladásáról, a sikerekről és az esetleges gondokról egyaránt. A gyakorlatban (szoftveres) eszközök segítenek a statisztika karbantartásában - ez lehet speciálisan kifejlesztett célszoftver, azonban az Excel is megteszi.

Megjegyzés
Kifejezetten motiváló lehet - nálunk legalábbis bevált - az úgynevezett "burndown chart", amely az elvégzendő és a már elvégzett feladatokat követi és ábrázolja grafikusan.

Mindez az információ-áramlást biztosítja, ugyanakkor rosszul alkalmazva gátolhatja a hatékony munkát. Nem az a cél, hogy a nap nagy részében megbeszéléseken pazaroljuk el az időnket, hanem hogy ésszerű keretek közt információt cseréljünk egymással.
Egy másik, gyakori tévedés a "daily scrum"-ot munkaindítóként felfogni: a megbeszélés előtt is illik dolgozni.
A daily scrum egy nyilvános fórum, azaz bárki részt vehet rajta. Fontos szabály azonban, hogy kizárólag a csapat tagjai szólalhatnak meg.

3. Sprint bemutató, elemzés
Minden sprint végén fel kell mutatni valamilyen eredményt - lehetőleg egy működő, látványos terméket (amolyan "demózás" a megrendelő számára).
Ez az úgynevezett "sprint review". Több szempontból is hasznos ez a megoldás, hiszen:
- látszata van a közös munkának,
- a megrendelő figyelemmel kísérheti a termék alakulását
Ezáltal nem csak a project késői szakaszában (legrosszabb esetben a végén) derül ki, hogy egyáltalán nem azt hoztuk össze, amit a vevő eredetileg szeretett volna (biztosan sokan ismeritek a hintás analógiát). Ilyesmi pedig sűrűn előfordul, a megrendelő ködös igényeinek vagy a tervezők, UI-designerek tévedései miatt.

A retrospektív elemzés azt szolgálja, hogy az esetleges hibákból okulva leszűrjük a következményeket.
Három lényeges kérdésre válaszolnak ilyenkor a csapat tagjai:
- Mi volt jó a sprint során?
- Mik voltak a negatívumok?
- Hogyan lehet javítani a problémás területeken?

Nem az ujjal egymásra mutogatás a cél, hanem a fejlődés!

Mivel a SCRUM előfeltétele a szabad információáramlás, nagyon ajánlott a csapattagokat egy közös térbe szervezni.
GP esetében ez nem mindig működik, de szerencsére létezik számos lehetőség a hatékony kommunikációra akkor is, ha nem dolgozunk egy irodában.

A fejlesztés eredményeit követhetővé kell tenni; ehhez szükséges a folyamatos integráció és a tesztelés. Ezzel biztosíthatjuk, hogy az alkalmazás nem romlik el, és emiatt ajánlott - bár talán inkább kötelező - a tesztvezérelt szoftverfejlesztés (Test Driven Development) alkalmazása . Az utóbbi témakört egy következő cikkben részletezem.

A SCRUM-ban talán a határidők kezelése a legszimpatikusabb: a határidő szent és sérthetetlen. Nem lehet eltolni, tehát ami nem készült el, azt becsületesen, problémaként szerepeltetjük a review-n.
A megvalósíthatatlan követelményeket így viszonylag gyorsan (akár egy-két sprint után) ki lehet dobni, nem csak több hónapos megbeszélés-sorozat, tervezés és kódolás, tesztelés után, ahogy az más módszertanoknál előfordulhat.
Természetesen a SCRUM sem tökéletes megoldás mindere, azonban könnyű megszeretni, és rövidebb (< 1-1,5 év) projectek megvalósításához véleményem szerintem kiváló.

Értékelés: 8.24

Új hozzászólás
Carlos          2008.07.03 04:18
ACsi
Az OFF után pedig a SCRUM témához is szeretném hozzátenni a magam két fillérjét: ha nem csalnak emlékeim a Google is ezt a fejlesztési modellt alkalmazza.



SCRUM-ban dolgoznak még a Microsoftnál (bizonyos részlegei), a Siemensnél, az evosoft-nál nemrég vezették be, az SAP egyes projectjei, és még sorolhatnám. Persze ezek nem GP-vel foglalkoznak, de én továbbra is fenntartom a véleményem, hogy itt is működhet a dolog.
A motivációt meg kell teremteni, legyen az lelkesedés, vagy pénz, becsvágy vagy referencia-gyártás.

Ez az agilis módszertan máris megfertőzött több nyugati vállalatot, és egyre több cégnél leváltja a vízesés- vagy a V-modellt. Az persze más lapra tartozik, hogy egyes hazai cégeknél gyakorlatilag nincs semmilyen módszertan, mindössze annyi:
"- Pityukám, jövő keddre dobd össze ezt az izét, mert a vevő most jelezte, hogy nem tud várni. Ja, és vidd el ezeket a leveleket a postára, aztán nézd meg, mi van a gépemmel, mert nem indul az autlúk." (Bármilyen hasonlóság élő vagy halott személyekhez tisztára véletlenszerű! - amúgy egy haverom mesélte a sztorit. Amúgy nem Pityunak hívják. )

Robsoft
Te magad se akarsz csinálni egy itteni projectbe ingyen semmit, pedig értesz hozzá, a csapattagok se tinédzser suhancok és a project se egy torpedó kategória. Akkor meg miről beszélünk?



Akkor sem szállnék be, ha fizetnének. Egyszerűen nincs rá időm, anyagilag meg nem érné meg. Akkor már inkább bajtársi alapon segítek itt-ott, privátban.
Elég nagy falat nekem a Gamma meg a könyv folytatása, nem fér bele további GP.
Ashkandi          2008.07.02 15:17
Sajnos én elég casual módon fejlesztek, napi óra megvan csakhát ugye nem HC programozás, csak modolás, de azért leírom a véleményem.
Egy emberes GPnél én se látom értelmét ennek a módszernek mert általában akkor csinálom a projectet amikor engedi az időm vagy ha van hozzá kedv, esetleg ihlet ( volt olyan, hogy ültem és bambultam az üres folyosót mert egyszerűen nem tudtam mit rakni bele, viszont másnap 2-3 szobát megtudtam csinálni u.a. idő alatt ).Itt maximum akkor jó ez a rendszer ha nagyon szerteágazó a lista, hogy mit is kell csinálni, például programozás biztos ilyen része a fejlesztésnek ( nem értek hozzá ). Pont azért is szeretek egyedül csinálni mindent mert így könnyen átlátom, hogy mivel vagyok kész és mivel kell még foglalkoznom, számomra időpocsékolás lenne ilyen naplószerűen vezetni a dolgokat. A projectemnek van egy oldala egy MOD portálon ahova kirakom az újdonságokat, képeket és így énis tudom, hogy kb mennyi van kész a játékból.

Csapatban viszont tetszik az ötlet. Ha befejeztem ezt az egy fős projectet pár hónap múlva, szeretnék énis csapatban dolgozni és "egy szinttel feljebb lépni". Ez kicsit ilyen baráti társaság szerűnek tűnik nekem de ennek ellenére megvan benne minden ami a sikeres munkához / fejlődéshez kell.
Bár a motiváció megtartásához kell egy leader aki fenntartja a hangulatot, sikerélményt biztosít. Viszont GPnél nincs termékgazda aki ezt megteheti, így egybefolyhat a termékgazda és a ScrumMaster egy Project leaderré.
ACsi          2008.07.02 06:39
Idézet
a pénz csak az eszköz, amivel megteremted a tekintélyt , ugyanis a tudáson alapulo tekintély nem müködöképes

A tudás alapú tekintélyre alapuló kultúra végülis csak olyan dolgokat hozott létre mint a Linux és a hozzá kapcsolódó milliónyi project. Ez teljesen használható szemlélet amit te is beláthatsz ha kicsit jobban beleásod magad egy egy ilyen project fejlődésébe, esetleg be is segítesz.
// nézz körül launchpad.net-en, a közösségi fejlesztés kánaánja

Az OFF után pedig a SCRUM témához is szeretném hozzátenni a magam két fillérjét: ha nem csalnak emlékeim a Google is ezt a fejlesztési modellt alkalmazza.
Robsoft          2008.07.02 06:12
Most úgy vagyok vele freeware projectekhez ami kell megcsinálom magam és megtanulom amit kell. Eddig azt tapasztaltam másoktól igényes munkát nem fogok csakúgy ingyen kapni azért cserébe, hogy ott lehet a neve a készítők listáján. Mire megy vele? Jelentkezik egy komoly céghez és ott van, hogy Robsoft freeware TPS game, meg az ő neve is. És akkor mi van?
Komolyabb játéknál meg meg kell bízni egy kft-t, vagy külsősöket, akik értik a szakmát és nem az motiválja őket, hogy sikeresen le tudjanak modellezni egy kockát. Véletlenül lehet, hogy 1-2 rendes arc bedolgozik két hétig csinál pár koncept rajzot, amit a netről copyzott le, vagy az ut2007-ből, de ennél többre csak nagy szerencsével lehet számítani. Elég csak végignézni a jf.hu projecteken hogy haladnak és milyen minőségben.
Lehet menet közben más tapasztalatok is lesznek és akkor más lesz a véleményem. amit eddig írtam a jelenlegi véleményemet tükrözi. Próbálkozni mindig fogok, sose adom fel.
newversion          2008.07.02 05:57
Robsoft látom te fogod a lényeget
Robsoft          2008.07.02 05:49
"robsoft, te vállalnád, hogy összegyúrod amit mondjuk egy kínai, egy orosz, két indiai meg egy magyar hozott össze úgy, hogy nem is tudják, mihez fejlesztenek, és nem kommunikálnak egymással?"
Például egy sound designer-nek elég csak azt tudni, hogy milyen hangok lesznek, amiből ugyan sejti milyen játék, de, hogy pontosan mi lesz, mikor lesz kész stb semmi köze hozzá és nem kell együttműködni senkivel se. Komolyabb szinten nem is szokták csakúgy akárkinek mutogatni a dolgokat.
Konceptezőnél szintúgy. Megmondom, hogy ilyen és olyan képek és pont. Soha az életben nem találja ki, hogy ez flipper, vagy mmo lesz és nincs is köze hozzá.
Programozásnál is megírja a fizikai részt, a többihez nincs köze.
Nyilván ez abban az esetben kényszermegoldás, ha az embernek nincs pár 100 milliója és egy iroda épülete, hanem kisebb költségvetésből akar elérni valamit megbízások útján. Itt megint csak a pénz a döntő tényező. ellenkező esetben beülök az irodába és scrummozgatok a szerződésben lévő alkalmazottaimmal, akik onnan semmit nem vihetnek ki, de az már más tészta.

A scrum meg pénz úgy jön össze, hogy általában az emberek olyanok, hogy gyakorlás céljából maguknak csinálnak sokmindent. A mindentbele teli van ilyenekkel. Onnantól kezdve, hogy másnak kell csinálni valamit, elveszik a motiváció és arra nehéz bármilyen fejlesztési tervet is alapozni, ha egyszer nem akarja csinálni. Abból már értenek, ha van egy munka és azt pénzért meg kell csinálni, de akkor nem a sarki fűszerest fogom megbízni értelem szerűen.
Te magad se akarsz csinálni egy itteni projectbe ingyen semmit, pedig értesz hozzá, a csapattagok se tinédzser suhancok és a project se egy torpedó kategória. Akkor meg miről beszélünk?
Carlos          2008.07.02 04:39
Idézet
Osztálytársakkal, haverokkal el lehet scrummozgatni pár hónapig ingyen, de abból nem lesz színvonal.


Ez esetben semmiképp nem lesz színvonal, módszertan ide vagy oda. Sőt, talán akkor sem, ha havonta utalsz a padtársadnak 100 kHUF-ot. Lehet, hogy motiválja a pénz, de ha nincs meg a szükséges tudása ( pl. nem hallott még a fuzzy logikáról, állapot etrvezési mintáról, stb.), akkor sem lesz jó a korábban emlegetett MI-modul, ha beleszekad.

Amúgy már említettem korábban, hogy a módszer feltételezi a képzett, és/vagy összeszokott, rutinos társaságot.

Idézet
Mégcsak ne is sejtsék milyen játékhoz lesznek részek, csak mindenki csinálja meg a kis részét, utána ki lesz fizetve és jó napot.

Ahhoz viszont, hogy ez működjön (és ne Frankenstein-project legyen a végeredmény) olyan részletes rendszertervet kell készíteni és átadni a fejlesztőknek, hogy abból már szinte a StarUML is legenerálja a kódot.

Együttműködés nélkül nem nagyon lehet alkotni, ezért találták fel a csapatmunkát. Különben az szív majd vele, aki a végén összeintegrálja.

robsoft, te vállalnád, hogy összegyúrod amit mondjuk egy kínai, egy orosz, két indiai meg egy magyar hozott össze úgy, hogy nem is tudják, mihez fejlesztenek, és nem kommunikálnak egymással?
Carlos          2008.07.02 04:28
Csak nem értjük meg egymást: a módszertan nem foglalkozik a pénzzel, tehát nem is zárja ki azt.

Másrészt hiába vagy te pénzeszsák, nem tudod megítélni, hogy Misike miért képtelen optimálisabban megírni az MI-modult: lehet kirúgod (ok nélkül), és nem találsz jobbat, de az is lehet, hogy megtartod, mert nem ismered fel, hogy gyenge kóder.
Ismétlem magamat: a csapat jobban megítéli az ilyesmit.

(A pénzes-szervező-projectvezető státuszod mellett meg kétlem, hogy marad időd kód-reviewkra is - ha esetleg te magad akarnád ellenőrizni ezt a részét is.

Szép dolog az önszerveződés, és a SCRUM-ban működik is. Már ha helyesen alkalmazzák.
Robsoft          2008.07.02 01:52
Nem kell ezt így túlbonyolítani. Kis költségvetésű kommersz, vagy freeware játéknál úgy kell összerakni, mint Nemo a hajóját. Mégcsak ne is sejtsék milyen játékhoz lesznek részek, csak mindenki csinálja meg a kis részét, utána ki lesz fizetve és jó napot. Én is arra jutottam, hogy ennél többre nem lehet számítani senkire sem. Osztálytársakkal, haverokkal el lehet scrummozgatni pár hónapig ingyen, de abból nem lesz színvonal.
newversion          2008.07.01 07:17
a pénz csak az eszköz, amivel megteremted a tekintélyt , ugyanis a tudáson alapulo tekintély nem müködöképes

" Ha négy ember azt látja, hogy az ötödik miatt nem haladnak, elég meggőzően tudnak rá hatni, talán jobban, mint egy mitugrász kisfőnök "

és mit csinálnak az 5-ikkel , kirugják a nem létezö fizetésü munkakörböl ne röhögtess már
ez akkor müködne ha mindegyikük számláján lenne pár misi, és nem a pénzért hanem a elismertségért, hirnévért csinálnák

2-3 embert eltudok képzelni csapatban dolgozni, de többet semmiképpen és ezt is csak fél éves intervallumon belül. 2-3 éves project viccnek is rossz


" Jaja, Kína meg India világtekintélyek, ami a videojátékipart illeti. "

olcso és jo grafikusbol sok van , bedolgozni betudnak, nem mindegy hogy egy casual projectet itthon 10 milliobol vagy 5-böl rakod össze
Carlos          2008.07.01 06:57
Idézet
ma már pénz nélkül senki meg se mozdulna(énse)

Egyik módszertan sem tartalmazza a pénz tényezőt, mint ahogy itt sem volt szó pénzről.
A csapat játssza a főnököt, és ezáltal demokartikusabb is az egész - nekem ezért tetszik a SCRUM.

Ha négy ember azt látja, hogy az ötödik miatt nem haladnak, elég meggőzően tudnak rá hatni, talán jobban, mint egy mitugrász kisfőnök.

Idézet
"grafikusok kinábol,indiábol olcson koncept rajz alapján, piszok olcson dolgoznak és rengeteg a tehetség, nem ugy mint itthon"


Jaja, Kína meg India világtekintélyek, ami a videojátékipart illeti.
Multi-kulti GP? Merész próbálkozás, még a nagyvállalatok is szívnak vele rendesen.
newversion          2008.06.29 11:44
a saját modellem ugy néz ki, amit alkalmazni fogok remélhetöleg a közeljövöben, hogy a concept artist ,programozok itthonrol ,
grafikusok kinábol,indiábol olcson koncept rajz alapján, piszok olcson dolgoznak és rengeteg a tehetség, nem ugy mint itthon
newversion          2008.06.29 11:07
szerintem itthon ez nem müködik, gp-nél meg tuti reménytelen
ma már pénz nélkül senki meg se mozdulna(énse)
viszont ha van megfelelö mennyiségü pénz akkor tulkinálat van , igy a geri által vázolt modell a legjobb, aki nem nem dolgozik az repül, vasszigor kell akkor lesz kész a project
Carlos          2008.06.28 00:37
fpeti
Egy embernél akkor se értem, mire lehet jó, addig ok, hogy leírom mit akarok holnap, de aztán vagy az lesz, vagy nem.

Nem csak ezt a részét lehet adaptálni: megtervezed a sprintet, kitűzöd, mikorra lesz valami bemutatható, majd kielemzed az eredményeket, és készülsz a következő sprintre. Egy idő után - esetleg csak a következő projectednél - már pontosaban saccolsz. Eleinte sokszor félremegy a dolog, ez belefér még professzionális, céges környezetben is. Az viszont már nagyon rossz jel, ha egy két éve fennálló SCRUM-csapat még mindig 150%-kal mellélő a becsléssel.
Adacs          2008.06.27 18:06
Egyedül azon van a hangsúly hogy a feladatokat részfeladatokra osszuk és azok is részfeladatokra. Azért hasnos mert átlátod hogy mennyi van hátra, és ha határidőre csinálod (minigame) akkor tudod hogyan is állsz az idővel. És ki tudod választani mindig a kedvedhez legjobban passzoló munkát, persze a végén úgyis a maradék lesz, de akkor meg legalább már látod a végét
fpeti          2008.06.27 12:44
Jó ki cikk, tényleg nem lehet rossz így csapatban, jó, hogy mindennap van beszéd, így senki se megy sokáig rossz irányba - 'nem fejleszt mellé'
Egy embernél akkor se értem, mire lehet jó, addig ok, hogy leírom mit akarok holnap, de aztán vagy az lesz, vagy nem.
Előre csak akkor tud (szvsz!) valaki tervezni, ha már csinált olyat, amúgy csak tippelhet. -Persze, ha tényleg fontos neki, akkor megcsinálja határidőre, legfeljebb meggebed.
A másik oldal, saját bőrömön tapasztalom, ha nincs határidő, akkor hujuj, mikorra lesz kész akármi is.
- nekem is voltak önhatalmú határidőim, most tartok márciusnál (kb).
robar          2008.06.27 11:52
Jut eszembe végre végeztem a vizsgáimmal és megint van idő a Designed-ra
Szidi_Rezegh          2008.06.27 08:45
A SpaceHunters valóban esettanulmány volt a Designed az nem, az teljesen hobbi és önképzési céllal készült. Több fejlesztő is csatlakozott hozzá és rengeteget hozzá tudtak tenni, az egységek és épületek, kezelőfelület rajzolása, szinkrohangok saját honlap, játékzenék mind-mind csapatban készültek és egy fillért sem látott belőle senki sem közvetlenül. Ami viszont nem lebecsülendő, hogy egy grafika/zene/honlap jobban mutat, ha egy nagyobb projekt részeként van bemutatva így pl.: referenciaként is többet ér mint önmagában.
Robsoft          2008.06.27 08:31
A Designed rossz példa, mert ha jól tudom és a doksim sem false az egy beadandó esettanulmány volt, akárcsak a SpaceHunters, ergó vagy megcsinálod, vagy megbuksz. Ez elég nagy motiváció nemde? Most ha én kitalálom, hogy írjunk egy autós játékot elvagyok magamban, de hogy ehhez még csatlakozzon is 2-3 ember, ráadásul ingyen elég esélytelen.
Ha esetleg betévednék valami art fórumra tuti, hogy nagy fizetés nélkül egy pálcika embert se fognak lemodellezni, nemhogy szalonképes modelleket. A prog.hu-t meg már meg se említem. Fél millió alatt a gépet se kapcsolják be.
Szidi_Rezegh          2008.06.27 07:54
Jó a cikk! Mi a Desinged fejlesztését is hasonlóan kiviteleztük eddig. Voltak demó verziók előre kitűzött határidővel ezeket lehet sprintnek tekinteni. 3-4 héttel előtte bejelentettük, hogy kiadunk egy új verziót mik várhatóak benne és mindenki azon dolgozott a csapatból, meg a fórumolvasók is számíthattak rá, hogy érdemes lesz nézegetni a topicot. Pénz abszolút szóba se jött, az motivált bennünket, hogy láthattuk egymás munkáját illetve, hogy mit tudunk hozzátenni a projekthez.
Geri          2008.06.27 07:39
A lényege az énközpontúság, és a csapattagok állandó cserélgetésére való lehetőség. A fejlesztés két részre szedhető, a csapattagok pedig 3 külön csoportra oszthatóak. Nincsenek közbülső leaderek, egy kézben fut össze minden. Nincs munkakör alapján való bontás. Előnye: a projekt biztosan elkészül, ha a vezér azt akarja. Hátrány: a vezérnek polihisztornak kell lennie. Szűkséges skillek: a vezér elfogadása az átmeneti tagok szemében. Az átmeneti tagok nem szűkséges hogy ismerjék egymást. Akit bővebben érdekel a felépítes, nagyon szívesen elmagyarázom részletesen is.
Carlos          2008.06.27 07:30
Idézet
Kár, hogy ez GP-ben nem működik. Nem, kicsit sem. Nekem van egy jobb módszertanom, amit 11 évnyi GP-zés után alakítottam ki. Akit érdekel, elmesélem msn-en.

Kellően fegyelmezett emberek esetében sem? Melyik része megvalósíthatatlan?

Tényleg leírhatnád, legalább nagyvonalakban, hogy mi a módszered lényege. Agilis vagy inkább klasszikus (V-modell, vízesés) módszertan?
kicsy          2008.06.27 07:28
Motiváció GP esetén nem a pénz lehet, régen rossz ha majd-ha-egyszer-ki-lesz-adva álomvilágból szalajtott rózsaszín húszdollárosok lebegnek a csapattagok szemei előtt, az ilyesmiből hamar csalódás lehet. Az eddigi tapasztalatok alapján - hosszabb fejlesztésnél - leginkább az mozgatja meg a tagokat, ha látják hogy halad a project, hogy a többiek mit hegesztenek. Nálunk a belső fórumba általában bemutatásra kerülnek a concept rajzok, modellek különböző fázisokban, programozás oldalról pedig szöveges beszámolók meg ninjás shotok.
Egyébként mi is egy hasonló irányba indultunk el mint a fent kifejtett módszertan, és a programozás részlegen elég jól működik is eddig - nyilván alapvetően kisebb falatokkal meg nem napi adagokkal.
Geri          2008.06.27 07:14
Cikket írni lusta vagyok, amúgyis mindenki csak tiltakozna ellene, mert hogy az úgy neeeem jóóóó, másfelől meg rajzolni is kell hozzá. De msn-en nagyon szívesen elmondom mindenkinek, akit érdekel.
Kuz          2008.06.27 06:42
Ha már itt említetted meg, illene itt kifejtened, nem? Itt egyszer kell elmondanod, míg msn-en minden kíváncsi embernek előadást fogsz róla tartani, vagy hogy? Vagy jobbat mondok, írj cikket te is!
Geri          2008.06.27 06:36
Kár, hogy ez GP-ben nem működik. Nem, kicsit sem. Nekem van egy jobb módszertanom, amit 11 évnyi GP-zés után alakítottam ki. Akit érdekel, elmesélem msn-en.
Carlos          2008.06.27 03:26
Idézet
Addig marad az egyedüli munka és magamnak egy ehhez hasonló fejlesztési módszer.

Én is ezt választottam (mint korábban már említetted), bár egy jó grafikus meg egy modellező - esetleg zenész - jól jönne. A legjobb helyzetben ilyen szempontból a játékfejlesztő cégeknél összeszokott emberek vannak. Viszont ők inkább szervezet keretek között működnek (lásd saját cég), ami már nem GP.
Robsoft          2008.06.27 02:07
Ha ezt így ebben a formában nem is, de hasonló rendszernél garázs projectben nehéz a motiváció, mivel nincs havi fél milla fizu, max a kecsegtető cél, hogy esetleg, ha kiadják, vagy árulásra kerül a játék lesz valami honorárium. Ilyen körülmények mellett nehéz olyan csapatot még akár csak 2-3 hónapra is összeszedni, akik hajlandóak együttműködni és befejezni egy projectet, ami lehet akár csak egy casual játék is, nem feltétlen MMO-ra kell gondolni. Hiába barát, vagy osztálytárs, ez nem garancia semmire, hacsak nem szakdolgozatról van szó, hiszen az nagy motiváció. Lehet csak eddig rossz helyen próbálkoztam, majd ha eljutok oda még próbálkozni fogok. Addig marad az egyedüli munka és magamnak egy ehhez hasonló fejlesztési módszer.
Carlos          2008.06.27 01:11
Valóban nem árt, ha a csapatban több a profi, vagy legalábbis fegyelmezett egyén. De enélkül amúgy sem működik, módszertan ide vagy oda.

Ami a leggyengébb láncszem megtalálását illeti: ez egy hosszú folyamat, több sprint után kiderül, ki az, aki nem, vagy rossz irányba húzza a szekeret. Nem a büntetés, pellengérre állítás a lényeg, hanem a motiválás.
Robsoft          2008.06.26 12:06
"A kimutatásokból (burndown chart), illetve a retrospektív során előbb-utóbb kiderül, ki a legggyengébb láncszem, és akkor a csapat eldönti, hogyan tovább."
Jó hát ha ez ilyen egyszerű lenne, de sajnos nem az. Örülni kell annak is, ha valaki egy hónap alatt összehoz egy autó kereket, vagy egy emberi figurának a kezét.

Jó kérdés az amúgy, hogy ezt módszert egy garázs fejlesztésben mennyire hajlandóak komolyan venni. Eddigi csapatkereső próbálkozásaim során az derült ki, hogy még ettől puritánabb megoldást sem vett komolyan senki. Ahogy látom te is egymagad gammázol, talán nem véletlenül.
Carlos          2008.06.25 15:05
Idézet
Amit én láttam rendszert (MSProject) ott is több ember (nagyon tapasztaltak) hetekig számolgatták, tologatták, ki hova, mennyi időre. Olyan emberekkel akiket ismertek, és még ez is elcsúszott. Pontosan belőni nem lehet, csak nadjából.

Te másról beszélsz: ez a nem agilis megközelítésnél szokott így történni, amikor az egész, akár több éves projectet előre megtervezik.
A SCRUM nem erről szól: itt rövid, általában max. négyhetes iterációkban dolgozunk (ezt nevezik sprintnek). Ezt könnyebb megtervezni, és nem tart tovább két napnál.

Idézet
Amit itt olvastam, az nyugaton követelmény, nállunk álom de mindenképpen követendő példa lenne.

Eddig is tudatosan kerültem a magyar cégeket, ezután is kerülni fogom. Sajnos csak ez az út járható, ha az ember nem akar megrekedni egy szinten, hogy aztán pár év múlva rájöjjön: nincs semmi használható a kezében (hacsak nem képezi magát autodidakta módon). Persze multinál is meg lehet rekedni, de ez már az egyénen múlik: időben váltani tudni kell!
twilek          2008.06.25 14:55
Hi

Amit én láttam rendszert (MSProject ) ott is több ember (nagyon tapasztaltak) hetekig számolgatták, tologatták, ki hova, mennyi időre. Olyan emberekkel akiket ismertek, és még ez is elcsúszott. Pontosan belőni nem lehet, csak nadjából.

Amit itt olvastam, az nyugaton követelmény, nállunk álom de mindenképpen követendő példa lenne.
Carlos          2008.06.25 14:24
Igen, én is alkalmazom. Mint a cikkben is írtam, én a ToDoList-et használom - meg persze az itteni és a honlapomon található fejlesztési naplót.

Ami pedig a becslések pontosságát illeti: természetesen lehetnek eltérések. A retrospektív elemzés pontosan azt hivatott kideríteni, hol volt a bibi. Legközelebb, hasonló esetben már jobban becsültök. Ez egy tanulási folyamat.
A kezdők, juniorok hajlamosak mindent beígérni rövid határidőre. A tapasztaltabbak már rutinosan pufferekkel és szorzókkal dolgoznak, ami általában lényegesen magasabb - ámde mint utóbb kiderül, pontosabb - számokat eredményez. Nincs kapkodás, sem frusztráció, legfeljebb legközelebb mindenki óvatosabb lesz.
A kimutatásokból (burndown chart), illetve a retrospektív során előbb-utóbb kiderül, ki a legggyengébb láncszem, és akkor a csapat eldönti, hogyan tovább.
Robsoft          2008.06.25 12:25
Ezt a módszer saját magadnál is alkalmazod? Például leírod egy naplóba, hogy mit csináltál a gammában a múlt héten és mit fogsz a jövőhéten? Nálam ez csak sima devlog, újabban blog. Nagyon rövid távra meg csak egy sima txt, amibe beleírom, hogy holnap mit is kéne folytatni egyéb teendőim mellett. (Most például rendszerterv. )
Ezekkel a határidőkkel amúgy az a baj, hogy nagyon nehéz megjósolni. Még ha teljesen tisztában is vannak a csapattagok egymás képességeivel is előfordulhat, hogy ugyanazt a feladatot rajtuk kívülálló okok miatt egy délután helyett egy hét alatt oldják meg, míg más feladatnál alábecsülték magukat és gyorsabban halad a munka. Velem is előfordult sok esetben ilyen. Sőt ha garázsproject, akkor egyszerűen megtagadhatja hetekig a grafikus a munkát, mondván ingyen nehogymá' és akkor borul az egész módszer úgy, ahogy van.