Scrum
Az Arkon IT osztályán már több, mint két éve bevezetésre került a scrum nevű agilis módszertan. A hozzánk állásinterjúra érkezők többnyire már hallottak róla, ritkábban pedig próbálkoztak is már korábbi cégüknél a bevezetésével, vagy már alkalmazták is azt a gyakorlatban. A sikeres bevezetés nem könnyű, számos buktatója van, nálunk is voltak nehéz időszakok. Ebben a blogbejegyzésben az alapokat gyűjtöttem össze, és pár bevezetéssel kapcsolatos problémára is igyekszem rávilágítani. Nem utolsósorban az is mindjárt kiderül, hogy mi köze van a Csongor és Tündének az agilis fejlesztéshez!
Mi az a scrum?
A scrum egy agilis módszertan, mely szabályai miatt leginkább fejlesztőcsapatok számára kínál előnyöket.
Mi az, hogy agilis?
Az agilis szó jelentése tevékeny, tapasztalt, mozgékony, fürge. Alapvetően latin eredetű, bár a szónak a magyarban több gyökerére is rá lehet akadni.
Egyrészt az „agilis”, vagy „ágyilus”, „árgyilis”, „árgyélus” szó olyan jobbágyot, vagy gyermekeit jelölte, aki nemes nőt vett feleségül. Ők szabad emberek voltak, s bár nem számítottak nemesnek, de szabadon élhettek, innen ered a mozgékonyság, tevékenység jelentés.
„Árgyélus királyfi” egy XVI. századi mesehős (ebből a meséből született Vörösmarty Csongor és Tündéje is) neve a bizánci Argyrus király (például Rómanosz Argürösz származik ebből a családból) népies változata. Árgyélus királyfi Tündérszép Ilonát vette el a mese végén – a halandó-tünde házasság párhuzamba állítható az előbbi jobbágy-nemes házassággal.
Az „árgyélusát” káromkodásban a szó nem a jelentése, hanem az „arkangyal” szóval való hasonlósága miatt szerepel. Ezt enyhítésnek hívják, ahogyan az „istenit” helyett is az „istállóját” szokás mondani (de ilyen még a basszuskulcs is például).
Mik a scrum szabályai?
- csapat: Egy scrum csapat kisméretű, keresztfunkcionális, önszerveződő legyen.
- backlog: Folyamatosan össze kell gyűjteni, nyilván kell tartani az elvégzendő feladatokat, prioritást rendelve hozzájuk. Ez a lista a backlog.
- sprint: Fix hosszúságú szakaszokban (1–4 hét) szállítsunk le a backlogból választott feladatok közül potenciálisan élesíthető, kész megoldásokat. Ezeket a szakaszokat hívjuk sprinteknek.
- standup: Mindennapos, rövid, hatékony megbeszéléseket kell tartani. Ezeket a megbeszéléseket hogy ne húzódjanak el, állva szokás megtartani, innen a standup elnevezés. Mindenki három kérdésre kell, hogy válaszoljon:
- Mit csináltál az előző megbeszélés óta?
- Mit fogsz csinálni a következőkben?
- Akadályozza valami a munkádat?
- hatékonyságnövelés: A sprint lezárásakor értékeljük az eltelt időt, összegyűjtve a jó és rossz elemeket, majd keressünk megoldást az utóbbiakra. A backlog tartalmát ha kell, folyamatosan értékeljük át.
Milyen kalapok vannak a scrumban?
A scrum főbb szereplői a következők:
- scrum master: A folyamatokat adminisztrálja, s a legfőbb felelős azért, hogy minden a tervek szerint haladjon. Ő teszi fel a standupokon a kérdéseket, őhozzá lehet fordulni, ha akadály merül fel. Egy scrum csapatnak csak egy scrum mastere lehet, de egy scrum master elláthatja szerepét akár 2-3 csapaton belül is.
- product owner: Rövidítve PO. Az a személy, aki meghatározza a fejlesztések sorrendjét priorizálva a backlog feladatait. Ő írja a story-kat, hozzá lehet fordulni a feladatokkal kapcsolatos kérdésekkel. Szigorúan egyetlen egy PO-ja lehet csak egy csapatnak. A PO nem feltétlenül termékmenedzser, az ő feladata a kívülről (termékmenedzser, tulajdonos, ügyfél, sales stb.) és belülről (leginkább a fejlesztők) érkező igények fogadása, az egyeztetés ezzel kapcsolatosan, és egyetlen felelős személyként a priorizálás.
- megrendelők: Ahogy az előbb is említettem, a feladatokat nem feltétlenül a PO találja ki, azok sok irányból érkezhetnek, a különböző megrendelők felől. Megrendelőből jellemzően több van, ők szigorúan csak a PO-val kommunikálhatnak.
- fejlesztők: A fejlesztő a backlogból kiválasztott feladatokat valósítja meg, továbbá az oda újonnan bekerülő feladatok egymáshoz képesti bonyolultságát is ő esztimálja.
Egy scrum csapatnak ezeken a szerepeken kívül lehetnek további tagjai is (ahogyan nálunk is vannak). Az például egy örök kérdés, hogy a tesztelő és a tesztelési folyamat (egy része) a fejlesztői csapat tagja, illetve a sprint része legyen-e.
Hogyan zajlik le egy sprint?
Egy sprint a következő szakaszokból áll:
- planning: A sprint indulásakor meghatározásra kerül, hogy a fejlesztők mely feladatokat szeretnék elkészíteni a sprint során, a fejlesztők korábbi teljesítménye (velocity), illetve bevállalásaik alapján a backlogból választanak story-kat, nagyobb feladatokat a tervezésen, planningen. A backlogban ekkor mindegyik feladathoz már van egy úgynevezett story pont rendelve, mely a feladat egymáshoz képest való bonyolultságát határozza meg, a korábbi sprintek alapján pedig adott egy körülbelüli szám, a csapat velocity-je, mely segítségével meghatározható, hogy a csapat körülbelül mennyi story pontot tud bevállalni. Ezen részt vesz a scrum master, a PO és a fejlesztők, s célszerű ha részt vesznek az adott feladat megrendelői is, hiszen ők tudnak információkkal szolgálni. Célszerű csak olyan feladatok bevállalása, melyek jól specifikáltak, s minden információ rendelkezésre áll már induláskor.
- taszkosítás: A bevállalt feladatokat a sprint elején a taszkokra bontják a fejlesztők, melyek maximum 1 napos részfeladatokat jelentenek. Ez segít a feladatok átgondolásában, és az esetlegesen felmerülő kérdések megválaszolása még itt megtörténhet. Alapvetően csak a fejlesztők vesznek részt a taszkosításon.
- standupok: A sprint megindulásával beindulnak a standupok is, jellemzően napi egyszer, a korábban már írtak szerint. Ezeken a scrum master és a fejlesztők vesznek részt, a PO hasznos, ha ott van, és instant tud válaszolni az esetlegesen felmerülő kérdésekre.
- esztimálás: A sprint során rendszeresen meg kell vizsgálni a backlogot, hogy vannak-e új, még esztimálatlan feladatok, s ha vannak, akkor ezek becslését el kell végezni. Ezen a scrum master, PO, fejlesztők vesznek részt, és jó ha a megrendelő is ott van.
- elődemózás: Amennyiben elkészül egy feladat, a fejlesztők megmutathatják a PO-nak, megrendelőnek. Itt esetlegesen kiderülhetnek félreértések, vagy jellemzően a feladatra itt pont tehető. Az elődemózás nem kötelező, de fontos a sikeres sprintek érdekében.
- demózás/sprint review: A sprint végén a fejlesztők bemutatják a fejlesztéseket. Ha volt már elődemózás, akkor ez hatékonyabban tud működni, ha nem, akkor itt is elég lehet egy lezárt feladatot bemutatni. Itt a PO dönthet arról, hogy a feladat kivitelezését elfogadja, vagy pedig nem, s a következő sprintben tovább kell dolgozni rajta. Egy feladat sikertelensége nem csak a fejlesztők hibájából adódhat, külső tényezők is szerepet játszhatnak. A scrum master, a PO és a fejlesztők vesznek részt rajta, célszerű ha a megrendelő is jelen van.
- retrospektív: A demózás után a fejlesztők brainstorming szerűen összefoglalják, hogy mi volt jó, s mi volt rossz az adott sprintben, majd pontozzák az egyes elemeket. A scrum master és a PO van jelen, akcióelemek és felelősök kerülnek meghatározásra a kritikus pontok felmérése után.
Miért jó, hogy sprintek vannak?
Az, hogy pár hetes ciklusokban történik a fejlesztés, számos előnnyel jár. A scrum szabályai szerint ezen időszak alatt nem módosulhatnak a célkitűzések, a fejlesztők védettek a külső behatásoktól, így koncentráltan tudnak a feladatokkal foglalkozni. A vállalások felelősséget jelentenek, illetve célkitűzéseket, melyek motiválják a résztvevőket. A fejlesztők önállóan tudják beosztani az idejüket, az ezirányú szabadság (vagy annak illúziója) is motivációs tényező lehet.
A felmerülő fejlesztési igényeket ki kell dolgozni, át kell gondolni, s mindezt időben kell megtenni, így az ad-hoc, átgondolatlan feladatok száma is csökken, mely a termék minőségén is javít.
Miért jó, hogy standupok vannak?
A standupokon láthatóvá válik, hogy ki mivel, s milyen sebességgel halad, ha valaki hatékonyan, vagy lassan dolgozik. Elősegíti az egymással történő kommunikáción kívül azt is, hogy a problémák kiderüljenek, kérdéses részekre a PO megoldást tudjon kínálni. Itt is látszik még a csapat haladása a feladatokkal, mely szintén egy visszajelzés a szereplők számára.
Miért jó a scrum?
A scrum hatásmechanizmusa összetett. Empirikus módszertan, az előnyei leginkább nem a szabályokban, szerepekben, hanem az azokból adódó élmények, következmények kapcsán jönnek elő. Más, nem agilis módszertanokhoz képest a rugalmasságot, illetve az iterativitását érdemes még az előnyei között kiemelni.
Mikor nem jó a scrum, mi van még?
A scrumot előre tervezhető feladatokhoz, projektszerű munkákhoz találták ki. Ha a feladatok jellege, vagy a munkakörnyezet szervezettsége nem ad lehetőséget a szabályok betartásához, akkor a scrum akár hátráltathatja is a hatékony munkavégzést.
A scrum egyike a számos agilis módszertannak. Egy szintén népszerű módszertan a Kanban, melyet jelenleg a cégnél a SWAT csapat tesztel, s sikeressége esetén esetlegesen más osztályokon is szóba jöhet a bevezetése.
Problémák bevezetéskor
A scrum bevezetésekor vannak tipikusan felmerülő problémák, ezekből próbáltam meg összeszedni párat:
- Keresztfunkcionális fejlesztők: A scrum szerint a csapat tagjai keresztfunkcionálisak, avagy „mindenhez” értenek, az architekt szereptől a sitebuilderségig. Ilyen persze nincs, vagy csak nagyon ritkán. Ha változatos feladatok érkeznek be a scrum csapathoz, akkor jellemzően jól fel lehet a fejlesztők tudására szabva osztani azokat, de az ideális az, ha széles tudással rendelkező fejlesztőkből áll a csapat, akik adott esetben bizonyos témakörökben jártasabbak másoknál, de szívesen dolgoznak bármely szerepben.
- Külső elfogadottság: Az egyik legproblémásabb dolog úgy nekivágni egy scrumnak, hogy „kívülről”, vagyis a vezetés, megrendelők stb. felől nincsen meg a megfelelő támogatottság, elfogadás. A sprintbe felvett feladatoknak kidolgozottaknak, átgondoltaknak kell lenniük, nagyon rossz, ha sprint közben gyakran változnak, s talán még ennél is rosszabb, ha sprint közben, vagy még akkor sem derül ki, hogy mi is a konkrét feladat.
- Hibajavítások: A hibajavításokat nehéz összeegyeztetni a sprintekkel. Mi több utat is megjártunk: volt, hogy a fejlesztők rotálva „supportosok” voltak egy-egy sprint erejéig, majd dedikált „SWAT csapat”-ot hoztunk létre, végül pedig most a hibajavítás a sprint részét képezi, a sprint egy részét fenntartjuk a hibajavításokra. A jelenlegi felálláshoz az is kell, hogy a hibák megfelelően értékelve legyenek, s adott esetben egy fejlesztés prioritásosabb lehessen, mint egy nem túl kritikus hiba.
- Storypontok: Nehéz elfogadni, hogy miről szólnak a storypontok. Alapvetően egy csapat teljesítményét mérik, e köré lett kialakítva a teljes folyamat. Az eltérő fejlesztői tudást tudja kiegyenlíteni ez a gondolkodás, a jól végiggondolt storypontok jól mutatják meg, hogy a csapat együtt mennyi munkát tud elvégezni a sprint ideje alatt. A scrum szereplői azonban akarva-akaratlanul időben gondolkodnak, és ez szokott disszonanciát okozni.
- Scrum master: Kell egy jó scrum master. A scrum masterség sok adminisztrációval és ügyintézéssel is jár, van akinek ez fekszik, van akinek nem. Sokszor nem jó az sem, ha a scrum master fejlesztő, mert egyrészt elfogult lehet, másrészt a konkrét fejlesztésektől vannak elvonva az erőforrásai. Itt is kipróbáltunk többfajta felállást, igazából nem tudom megmondani melyik a legjobb. A több csapat scrum mastere ugyanaz felállással nekem az volt az egyik problémám, hogy néha úgy érezte a fejlesztő csapat, hogy nem képviseli eléggé őket a scrum master. Most egy nagyrészt dedikált scrum masterünk, és egy fejlesztőként dolgozó helyettese van.
Bevezessem én is?
Nem ez volt az összes problémánk, de talán rávilágítanak arra, hogy mikre kell számítani, ha valaki a bevezetés mellett dönt. A problémákkal együtt a scrumos hozzáállás nagyon sok pontban fényévekkel jobb, mint a waterfall jellegű. A scrum kikényszeríti, hogy a fejlesztési feladatok átgondoltak, kidolgozottak, tervezettek legyenek, segít a fejlesztők együttműködésében, kommunikációjában, és egyéb okokból is megéri kipróbálni, így – ahol ezeket meg tudja csinálni együtt, közösen az egész cég – célszerű bevezetni. Ha nem jönne be, akkor is érdemes más agilis módszertanok, pl. a Kanban környékén keresgélni, melyek szintén közel állnak ezekhez az értékekhez.
■
Esztimálás :)
Azért a 'taszkosítás' meg 'esztimálás' nagyon tsúnya vördök ám!
Ha már 'planning' volt akkor lehetett volna angolul hagyni, vagy mindegyiknek akkor egy magyar megfelelőt keresni.
(Feladatra bontás, becslés - a becslést használod is benne)
Amúgy tudod mi az Esztimálás? Amikor egy Eszter nevű hölgy arcára kent alapozó kezd lepotyogni... :D
Nem szép
A Scrummal az a baj, hogy nem
Nem lattam meg olyan ceget, ahol a valosag es a Scrum ne kerultek volna osszeutkozesbe egymassal.
Hivhatjuk ezeket kivulrol jovo problemaknak, az a hulye ugyfel nem erti, a juzer miert nem tud varni 2 hetet egy critical bugfixszel (a volt cegem siman megcsinalta, hogy a rendszert hasznalhatatlanna tevo, a fo funkcionalitast lehetetlenne tevo blocking bug bennmaradt 2 hetig, mert kov scrum...), egyaltalan, a feladatok miert nem irjak meg magukat, es mi az, hogy az ugyfelnek nincs PhD-ja adatmodellezesbol, ha meg van, miert szol bele, nem fejleszto, ne irja elo hogy fejlesszunk.
Mondanam azt, hogy kodszintem az ilyeneket hamar eszrevesszuk es kib.sszuk, de sajnos a J2EE is tobbet elt a szuksegesnel, a Springtol is fogom sokszor a fejem meg mindig.
Sz'al ha a ceg nem erti a scrum-ot, a hiba az on keszulekeben van.
Ettol meg az iterativ fejlesztes egy fontos dolog, de a scrum fele netto marhasag.
bugok
A Scrum picit
http://www.scrumalliance.org/articles/52-empowering-teams-the-scrummasters-role
vs.
http://agilemanifesto.org/
nyilván ennek is megvannak az okai, de nem szabad elfelejteni, hogy eredetileg az Agile mozgalom az XP-vel karöltve futott fel, a Scrum-ot picit egy kompromisszumnak tartom az pure agile és a corporate Waterfall között, még meghagy annyi kontrollt a management kezében, hogy el lehessen "adni" a bevezetését.
de hogy a konkrét felvetésre reagáljak: igen, a bugfix/maintenance kérdése a leggyakoribb probléma (legalábbis saját tapasztalat alapján), kb. mindenki végigjárja a tipikus fázisokat:
- a naív, majd a kövi sprintben javítjuk hozzáállás(ez általában nem éli túl az első sprintet).
- a majd úgy tervezzük a sprintet, hogy hagyunk időt a beeső hibajavításokra (ezt nehéz becsülni, emiatt kb. mindig bukni fognak a sprintek)
- majd dedikálunk rá embert (ha ugyanaz az ember/csapat viszi, akkor egyrészt biztos a kiégés, másrészt könnyen átcsaphat torzsalkodásba, harmadrészt lustává teheti a fejlesztőket (majd a SWAT kijavatja, ugyanez megfigyelhető ott, ahol van tesztelő részleg, az átlag fejlesztő elkezdi nem tesztelni a munkáját).
bármelyiket is választod, szerintem mindenképp érdemes legalább 2 dolgot figyelembe venni:
- legyen valamiféle timebox
- lehetőség szerint még ha nem is egyszerre, de javítson mindenki hibát, ezáltal jobban rögzül, hogy ha most összetaknyolok valamit, hogy elkészüljön a sprintben a feladat, utána ugyanúgy mi/én fogunk szopni a hibajavítással.
Tyrael
meg nem olvastam vegig, de ha
nem értek egyet azzal, hogy a Scrum csak szoftverfejlesztésre használható, és emiatt a Team = fejlesztők megfeleltetést is kicsit mesterséges szűkítésnek érzem.
azzal egyetértek, hogy a heterogén csapatok esetében (ahol 1-1 feladatot nem tudna minden csapattag elvégezni) nehezebbé válik a kapacítástervezés illetve sérül a csapat önrendelkezési joga a feladatok végrehajtását illetően (a szűkösebb erőforrás egyenletes terhelése illetve a "bizonyos feladatot csak bizonyos csapattag tud megoldani" felállásból adódóan).
a szerepek kapcsán megemlítettem volna a csirkék és disznók fogalmát.
planning kapcsán kiemeltem volna még, hogy a PO/PM/Stakeholder nem szabad hogy befolyásolja a csapatot a vállalásokban ("Én hiszek abban, hogy ez a csapat képes még 50 story pontnyi feladatot megcsinálni ebben a sprintben"), illetve a csapatnak is inkább érdemesebb arra törekedni, hogy ne vállalják túl magukat:
Project Management szempontból hasznosabb egy lasabb de kiszámítható fejlesztési ütem, mint egy (esetenként) gyorsabb, de (a korábbi sprintben túlvállalás miatt összecsapott munka következményeként) sokkal hullámzóbb, kiszámíthatatlan teljesítés.
esztimálás kapcsán megemlítettem volna a Planning Pókert, jó eszköz a csoportgondolkodás negatív következményeinek a csökkentésére (http://en.wikipedia.org/wiki/Groupthink).
a sprintek kapcsán megemlítetted ugyan, de picit általánosan:
- a folyamatban lévő sprinten a megrendelő nem módosíthat, nem rakhat be új feladatot.
- a backlogot viszont nyugodtan módosíthatj ilyenkor is a PO
- amennyiben mégis olyan körülmény merül fel, ami miatt nem lehet befejezni az adott sprintet, akkor abortálni kell, és tervezni egy újat.
A saját tapasztalatom az, hogy valamifajta fejlesztési módszertan mindenképpen szükséges, az ad-hoc a létező legroszabb megoldás, bár a megrendelő szempontjából (legalábbis rövid távon) a legkényelmesebb.
Általában a Scrumot a bevezetésen láttam elbukni a legtöbbször: a megrendelő/stakeholder nem elég elkötelezett, akarja a kiszámítható fejlesztést, de nem hajlandó betartani a rá vonatkozó elvárásokat:
- nem készít user story-t, vagy segít annak elkészítésében
- nem biztosítja a sprintek zavartalanságát
- erőlteti hogy a fejlesztők túlvállalják magukat, ami vagy technical depth-et okoz(ami egyre lassítja a fejlesztést), vagy folyamatosan sikertelen sprinteket.
- nem hajlandó elfogadni hogy nem kap határidőket, nem lát túl az éppen aktuális sprint vállalásain.
Tyrael
igaz
jah, bocs a lenyeget
jo a cikk, hianypotlo, nagy koszonet erte.
magam is terveztem valami hasonlot, ezert is dobtam be azt, amire en kitertem volna.
Tyrael
Az egyéni motivációt/auditálást én így oldottam meg:
---
Készíts minden nap TERV-RIPORT beszámolót!
A TERV-RIPORT készítés azért van, hogy auditálva legyenek az általad elvégzett feladatok és, hogy veled együtt betekintést nyerjünk az időd felhasználásába.
Előnye, hogy önmenedzselésre késztet egyben önjutalmaz és motivál az idő leghatékonyabb kihasználására.
Eredménye: kiegyensúlyozott és boldog emberek a XY-nél, ahol kiszámítható a munka menete.
Ahhoz, hogy sikeres legyél abban amit csinálsz elengedhetetlen az időgazdálkodás optimalizálása, amihez nagyon-nagy segítséget ad a TERV-RIPORT készítése! Használd ki ezt a fantasztikus önmenedzselési lehetőséget és elsősorban úgy készítsd, el a TERV-RIPORT beszámolóidat, hogy Neked is hasznodra váljon!
TERV leadása aznap 08:15-ig
RIPORT készítése aznap 16:45-től
Hogyan néz ki a TERV?
–
TERV:
Napi rutin feladatok:
- felsorolás címszavakban 1
- felsorolás címszavakban 2
- felsorolás címszavakban 3
Egyéb feladatok:
- felsorolás címszavakban 1
- felsorolás címszavakban 2
- felsorolás címszavakban 3
–
Hogyan néz ki a RIPORT?
--
RIPORT:
Elvégzett/befejezett feladatok:
- felsorolás 1
- felsorolás 2
- felsorolás 3
Folyamatban lévő feladatok melyeken ma dolgoztam:
- felsorolás 1
- felsorolás 2
- felsorolás 3
--
Köszönöm!
? Tyrael
Tyrael
Hiányoltam az egyén tervét az
pedig ott van
Lehet ezzel többen így
spamnek nem nevezném, de
(igaz, üzemeltetésen kicsit mások voltak a körülmények, mint a fejlesztőknél, de nagyon nem örültünk a plusz adminisztráció ötletének ;) )
A Scrum nem fogalmaz meg
azaz nem korbaccsal "erobol" hanem repaval "esszel" motivalod a dolgozott a jobb munkara.
nekem az a tapasztalatom, hogy ha latjak a fejlesztok, hogy van beleszolasuk a fejlesztesi folyamatokba (esztimalas, mit/mennyit rakunk be a sprintbe, ki mit csinal, etc.) akkor oda fogjak tenni magukat, a logosokat meg egyreszt kiveti egy ido utan a kozosseg, masreszt a szamokbol (ki mit/mennyi story pontot csinalt meg) ugyis kijon.
szoval magam reszerol en annak a hive vagyok, hogy a fejlesztoktol nem kell kulon napi/heti jelentes, viszont issue tracking rendszerben adminisztralni kell, hogy mivel mennyit dolgoztak, hany szazalekon all, ebbol is nagyon jo kimutatasokat lehet csinalni.
ja, es nyilvanvaloan az impediment-ek szoba kell hogy keruljenek a standup-on, ott ki lehet szurni, ha valaki mar 3 napja ugyanazon a taszkon porog, vagy hogy fel napja nem tud dolgozni, mert telepitik a gepet.
ps: http://www.drjohnizzo.com/treat-people-like-adults-at-work/
Tyrael
Jó, hasznos cikk
Egy-két apró megjegyzés:
- A magam részéről a "Mi az, hogy agilis?" részben nagyon örültem volna, ha megkímélsz a káromkodás konkrét leírásától. Ha csak az enyhített változatot ("istállóját") írtad volna le, akkor is értette volna mindenki.
- A "Mik a scrum szabályai?" rész végén:
- Amit többen is említettek: vagy magyar, vagy angol fogalomnevek.
Ezek csak apróságok, összességében egy jó bevezető cikk. Folyt. köv.?
Szereplők?
Nekem a szereplők kiválasztása is már problémát okoz. Egy olyan csapatban, ahol nincs egyértelmű mindenhez legjobban értő személy, ott mi alapján válasszunk scrum master-t?
A PO és a hagyományos értelemben vett projekt menedzser között mi a különbség? (Amit én hagyományos PM alatt értek: ő beszél az ügyféllel, a vezető fejlesztőkkel egyeztetve adja ki a feladatokat a fejlesztőnek, csak azt mondja meg, hogy mit, de sosem azt, hogy hogyan)
Az engem meglepett, hogy a cikkben szerepel, hogy SM helyettes is létezik. Az eredeti koncepciótól ez mennyiben tér el? :)
Konfliktus esetben ki dönt? Kitalált példa: SM backend-es, van olyan fejlesztő, aki jártasabb frontend téren, koncepcionálisan másként tervezne. PO ezen a szinten szakmailag nem ért hozzá. Az ilyen helyzeteket hogy oldhatjuk itt fel? Az SM szava dönt? Vagy a PO szava? (aki persze konzultál azzal a fejlesztővel, aki másként csinálná)
Kicsit más kérdés: mi a scrum előnye attól a koncepciótól szemben, amit megfogalmaz az agilis szoftverfejlesztésről szóló kiáltvány? Mert az természetesnek veszem, hogy jobb a vízesésmodellnél, de azt nem látom, hogy a „többi”-re mi szükség, illetve mi pluszt ad hozzá? Nekem ez elsőre (illetve már többedszerre is) csak egy nagy adag átnevezésnek tűnik. Mi nem sprint-nek hívjuk, de az ott leírtak között sok ismert elem található, de a szereposztás, illetve a felelősség ennél szerteágazóbb. (Bár a kérdésem amiatt íródott, mert nem tartom ezt az állapotot ideálisnak:)
Scrum Master-nek ket fo
altalaban PM tipusu embereknek jol szokott allni a szerep, de nem feltetel. (viszont szerintem hosszu tavon egy nem PM iranyultsagu embernek nem biztos hogy fekszik a szerep).
PM-bol altalaban ket felet lattam, az egyik az a mar majdnem ugyvezeto tipusu, aki rugdossa a csapat segget, az ovet meg a vezetes, van dontesi jogkore a megrendelest illetoen (mit, mikorra, milyen sorrendben), bar beszamolni tartozik a vezetesnek.
a masik fele PM az, aki inkabb a PMO-s vonalat viszi (http://en.wikipedia.org/wiki/Project_management_office) vihet egyszerre tobb projectet, elsosorban folyamatiranyitassal foglalkozik, megkapja/megbeszeli a megrendelovel/vezetessel hogy mit kellene megcsinalni, csinal belole WBS-t, project tervet, microsoft projectben felvezeti a csapattol kapott infok alapjan a feladat dependenciakat, mi mennyi ido, ebbol kijon a kritikus ut, ez alapjan lesz valamifele vallalas, hogy mi mikorra keszulhet el, ha kell kilincsel kapacitasert, vagy a hataridok kitolasaert, etc. majd az igy elkeszult projectterv alapjan le is vezenyli a projectet, ha csuszas van utananez, intezkedik.
tehat klasszikus PM feladatok.
szerintem SM csak az utobbibol lehet, PO mindkettobol, de inkabb az elso verziobol.
szerintem, aztan majd jon valaki okosabb es megmondja. :)
SM helyettesrol meg en sem hallottam mashol, de mivel reszben moderator, reszben lotifuti szerep, ezert vegulis jogos, hogy ha epp nincs keznel az SM, akkor se alljon a csapat.
konfliktus: SM nem biro, csak moderator, vitas helyzetben nem donthet, viszont iranyithatja a beszelgetest, hogy az konstruktiv maradjon. technikai tervezesbe az SM illetve PO nem szol bele, a Scrum nem definial erre processzt, ha akarjatok csinaltok konszenzus alapu demokraciat, de lehet egy technical lead a csapatban (aki ugyanugy csapattag es esetleg lehet PO, bar itt lehet erdekellentet) aki megtervez mindent (amit aztan a Team ez alapjan majd esztimal, mert azt viszont definialja a scrum).
nalunk ugy mukodott, hogy a user story alapjan volt esztimacio, ha szukseges volt valami gyors technikai egyeztetes az esztimaciohoz, akkor megtettuk a helyszinen, ha tobb idore volt szukseg, akkor vagy tartottunk elozetes meetinget, ahol picit mar eloterveztuk a user story-kat, vagy szetbontottuk a user story-t tervezesre es implementaciora, elso sprintbe csak a tervezest tettuk be (arra mar tudtunk esztimalni, hogy mennyi ido lesz korbejarni, es kidolgozni a feladatot olyan szinten, ami utan mar esztimalhato a feladat maga).
Nem scrum specifikus, de nalunk 1-1 tervezes tipusu feladaton mindig legalabb 2 embernek kellett dolgoznia, es az elkeszult terveket meg a tobbiek is megnezhettek, hogy az esetleges problemak meg idejekoran kideruljenek.
utolso bekezdesre valasz:
az agile manifesto olyan mint az agressziv futball.
kijelenti hogy ugy akar gyozni, hogy harcban legyozi az ellenfelet, nyilt sisakkal, szembol.
de nem mondja meg, hogy sok passzos jatekkal, esetleg kontrakbol, vagy beadasokra epitkezve szeretne ezt megvalositani.
mindharom modszerrel lehet agressziv focit csinalni (mar banom a peldat, nem vagyok jo a labdarugasbol), de ez nem egy konkret taktika.
az xp, kanban, scrum, etc. ugyanannak a temanak egy picit mas mas variacioja, a kulonbozo aspektusok eltero hangsulyu kombinacioja.
az xp azt mondja, hogy legyen pair programming, uljon egymas mellett a fejleszto meg a megrendelo, a leheto legkissebb iteraciokban a leggyorsabb feedbackkel.
a kanban meg mindig nagyon agilis metodika, de azert itt mar kikotjuk, hogy amin epp dolgozik valaki, azt nem ildomos piszkalni, de az uj taszkot nyugodtan betehetjuk a kupac tetejere, lehetove teszi a dontesek/valtoztatasok az utolso pillanatig torteno halogatasa.
a scrum ehhez kepest meg merevebb, tobb aldozatot var a megrendelo(hosszabb iteraciok, csak a sprintek elejen van direkt kontrol a fejlesztesi folyamatokra) es a team reszerol is (vallalaszok a megrendelo fele az elkeszulo munka mennyisegerol), de cserebe mindket fel nyer is az uzleten (a megrendelo kap hataridoket, a csapat meg nemi nyugalmat, es szintugy tervezhetoseget: tudja a csapat hogy mit fog csinalni a kovetkezo ket hetben, ez sem a kanbannal sem az XPben nincs meg imo)
ezen kivul is vannak agilis modszertanok en a Scrum-ot ismerem behatobban XP-rol illetve kanbanrol csak olvasgattam.
Tyrael
Tyrael
Köszönet
Amikor először olvastam az agilis szoftverfejlesztésről, akkor rögtön éreztem, hogy ez egy nagyon jó dolog, és hogy pontosan így kellene ennek működnie. Amikor viszont először olvastam a scrumról, főleg a disznós-csirkés szereposztással, akkor meg elhelyezni sem tudtam a történetet.
Könyv ajánló
http://www.infoq.com/minibooks/kanban-scrum-minibook
amit Csutorás Zoltán és Marhefka István magyarra is lefordított:
http://www.adaptiveconsulting.hu/dokumentum/kanban-es-scrum-mindkettobol-legjobbat-magyar-forditas
Nekem nagyon sokat segített ez a könyve tisztázni pár kínzó kérdést, hasonlóakat mint amiket fentebb is olvasok. Természetesen azt se hallgathatom el, hogy a két uriemberrel együtt dolgoztam, így élőben láthattam hogyan is működik ez a metodika.
Pár dolog amit kiemelnék:
A sprint végén mindig valami működő, bemutatható, az ügyfél számára is látható/érthető termék készül, amit azon nyomban használatba is vehet. Ezért én a módszer agilis tulajdonsága helyett az adaptív tulajdonságát tartom fontosabbnak. A termék folyamatosan épül, úgy, hogy bármikor abbahagyhatod, van működő terméked, nem az van, hogy hónapokig tolod bele a lóvét és egy nagy semmi.
Ehhez természetesen gyakran kell refaktorálni, ami tesztek nélkül elképzelhetetlen. (refaktor alatt azt értem, hogy átírom a kódot, hogy ugyan úgy működjön, de bővíthető legyen) Nálunk standupon egy cetlit csak akkor lehet a tervezés alatt a megvalósításba tenni, ha van hozzá tesztforgatókönyv.
Ha már a „cetlit tenni”-nél tartunk, rámutatnék a másik nagyszerű dologra. Nem kiosztják(push) a feladatokat, hanem a programozók veszik ki(pull) a feladatokat. Ami elsőre nem tűnik fontosnak, de ez is az egyéni felelősség vállalást erősíti, annak ellenére, hogy csapatban gondolkodunk mindig. Köszönhetően annak, hogy a célok mindig világosan megfogalmazottak és az egész csapat(beleértve a megrendelőt) is e célok felé húzzák a szekeret.
Természetes, hogy az olyan környezetben, ahol folyamatos push alatt van a programozó és mindig több melót tolnak rá mint amit bír, elkezd kummantani. Mivel ezt ugye mindenki tudja, még több melót tolnak rá, amitől még többet kummant és beindul az ördögi kör(egy informatikai projekt az mindig csúszik) amiből nem nagyon lehet kiutat találni.
Erre kínál egy lehetőséget a scrum és érthető a hitetlenkedés, hisz pusztán a szabályok nem fogják meghozni a változást. Pl. a PO és SM szerepkörök célja pont az, hogy ezeket a feladatokat/szerepköröket ne egy ember lássa el mint a hagyományos PM, mert akkor önmagával kell küzdeni (felfelé ezt kommunikálom, lefelé amazt) PO célja, hogy minél több feladat menjen át, akár úgy is, hogyha egy feladat túl nagy falat akkor azt átfogalmazza, kijelöljön belőle olyan részfeladatot ami legjobban szolgálja az elérendő üzleti célt. A SM célja, hogy maga a vállalás teljesüljön/teljesülhessen. Ha valaki nem ilyen szellemben dolgozik, akkor hiába hívja magát PO-nak, vagy SM-nek. Nem attól fog működni a módszer.
Mint minden a Scrum is csak egy módszer ami valamire jó, valamire nem. Hogy pontosan mire és hogyan arra lehet szerintem választ találni a könyvben (meg a gyakorlat során ugye :) ).
pp
Lehet, hogy ezzel egyedül
Köszönöm a válaszokat :)
Módszer
(remélem nem hagytam ki semmit)
Ezek a módszerek azért jók, mert van benne mindenre válasz. Választhatod akármelyiket, vagy kitalálhatsz újakat, módosíthatod őket, de ezeket a lépéseket konzekvensen követni kell. Így sikeresen le lehet vezényelni egy fejlesztést.
Egyetértek
Pszichológus? :)
Sajnos erre csak Te tudhatod a választ, javasolt egy megfelelő szakember aki segít neked kimondani a válaszokat.
Legkönnyebben úgy tudsz új fogalmakat bevezetni, ha kitalálsz rá új szavakat. Szerintem itt pusztán erről van szó. (de természetesen egy scrum csapatban mindenki mosolyog és megváltozik az élete, a megrendelő és a programozók egymásbafont kézzel, vidáman ugrálva énekelnek rég elfeledett gyermekdalokat, miközben éppen átvágnak a virágoktól, kis édibédi állatoktól hemzsegő mezőn, közösen az elérendő cél felé haladva...:))
pp
A kérdésem persze költői
Amikor kicsi, vagy 1 fős a csapat
Mostanában sokat foglalkozom az agilis fejlesztés témakörével, szeretném fejleszteni munkám hatékonyságát. Nagyjából ismerem a scrum, az XP, és most már a kanban elveit is. Mindez arról szól, hogy egy csapat hogyan lehet hatékony, hogyan válhat hatékonyabbá.
A kérdésem, mit javasoltok, ha a csapat 1-2 fős?
Adott egy örökölt projektem, amit fejlesztenem, refaktorálnom kell.
Jelenleg egységteszteket írok hozzá, és próbálom megérteni a jelenlegi rendszert.
A problémám, hogy mit tehetek, ha egyedül dolgozom, vagy mondjuk egy kis csapatban (két fejlesztő). A scrum szerintem adott esetben erősen túlbonyolítaná a helyzetet, bár vannak részletei, amik egy fős csapatban is használhatóak. A kanban valószínűleg alkalmazható, de tanácstalan vagyok.
Elnézést kérek, ha nagyon off a kérdés, de szerintem sokak dolgoznak egyedül egy-egy projekten, és velem együtt őrlődnek, hogy hogyan is tudnának hatékonyabban fejleszteni, amikor az ügyfél változtatgat, és ebből újabb és újabb hibák generálódnak.
videó a scrum master szerepéről
Alapjaban veve a cikk jo es
Az elso dolog ami zavart, hogy a "kell" szo tul sokszor van hasznalva. Az egesz agilis szoftverfejlesztesnek az a lenyege, hogy "Responding to change over following a plan". Semmi mas nem lehet fontosabb, mintsem "Responding to change over following a plan", legyen az Scrum vagy Kanban.
Hogy miert is?!
Charles Darwin
Magyarul semmit sem _kell_ csinalni, minden csapatnak az a feladata, hogy egy default patternbol, mint pl. Scrum
strukturalt workflowt teremt, ami total a csapatra van szabva, sem pedig koveti a dogmatikus Scrum-t a konyvbol. Lattam ilyenre peldat, hogy a PO meg az SM nezeteltereskor mar majdnem ott tartottak,hogy fellapozzak a SCRUM "kezikonyvet", hogy ilyenkor mi a ateendo. wattaf****. Ha 3-4 sprint utan meg mindig ez megy, akkor nagy a baj.
Es akkor jojjon az elso :-)
Mit csináltál az előző megbeszélés óta?
Mit fogsz csinálni a következőkben?
Akadályozza valami a munkádat?
Szerintem egy jo standup meetingen (max 15 perc limit) ennel sokkal tobbet is meg tud beszelni a csapat. Nagyon sokszor a fejlesztők észre sem veszik, hogy csak elmondjak a kotelezőt aztán next turn. A standup lenyege, hogy synceld a csapatot, de ne csak ugy, hogy felelnek a 3 fenti kerdesre. Ha pl. nem hallasz ilyet egy stanup meetingen, hogy "Offtopic, beszeljuk meg standup utan", vagy rogton a meeting utan a fejlesztok visszaulnek a helyukre, akkor a standup nem hatekony. Egy jo standup meeting parbeszedeket valt ki amik rendszernt a stanup utan folytatodnak.
Ha meg a fejlesztők már egymásnak tesznek fel erdekes, es helyenvaló kérdéseket, akkor az meg szuperebb.
Alapveto kerdesek tippnek:
- Ki a kovetkező release master (a release-ert felelos szemely)?
- PO elmondhatja az utolso release hatasait (pl. 15% profit novekedes az uj payment window miatt) -> ez motivalja es inspiralja a csapatot
- Van-e critical bug?
- Valtozott e-prioritas, ha igen -> standup utan mindenki egyutt marad es dontes szuletik.
Masik dolog:
A "taszkositas" es "becsles" szerintem nem valasztható ketté. De ez megint attól függ, hogy melyik csapatban ez hogy működik. Nálunk van 2 grooming meeting plannig meeting előtt, ahol kisebb egységekre bontjuk a feladatot es ha lehetseges azonnal becsuljuk is (minek varni vele, ha mar amugy is ott ul minden erintett). Ha nem lehet becsulni, mert nincs eleg info, akkor valaki gondoskodik rola,h a kovetkezo meetingre tiszta legyen a user story. 2x1 ora grooming meeting + 1 ora planning egy 2 hetes sprintben megfeleloen utemezve (4 napos kihagyasok), mi igy csinaljuk.
Harmadik:
Ezert volt problemad a bugfixekkel, mert a dogmatikus SCRUM-t probaltatok kovetni. Erre ket megoldast tudok adni szamodra:
1. Continuous Integration es deployment megfelelo _TDD_-vel!!!
2. Persze ezutan is lesz bug, de sokkal kevesebb, ha jol toljatok. Ilyenkor nincs mit tenni, a PO-nak fel kell tenni a nagy kerdest: "Van ez a hiba annyira kritikus, hogy azonnal meg kell javitani, vagy varhat a kovetkezo sprintig?" Ekkor a PO dontest hoz, es ha raer, akkor nyert ugy, kov sprint backlogban ott kell majd figyelnie. Ha nem varhat, akkor 3 opcio van:
1. Trivialis hiba, gyorsan fixelheto, gyors release ami <1h alatt meg van post release sanity check-el. Ez nem igényel semmilyen sprint adjustment-t, csak egy szep tapsot a masnpi standup-n a release masternek ;-).
2. Komplex hiba, tudjuk a megoldast, gyors becsles a csapattal (max 10 perc) -> 1SP megy a sprintbe, akkor 1SP-nek megfelelo story kimegy a sprintbol, lehetoleg olyan, ami a legkisebb prioritasu, es meg senki nem dolgozott rajta.
3. Komplex hiba, nem tudjuk a megoldast -> Timeboxed investigation -> 0.5SP mondjuk, aztan ha megvan a megoldas (fel nap, vagy 1 nap mulva), arra kulon user story/bug story-t kell kesziteni es becsulni (ez legyen mondjuk 1SP), teahat 1,5SP-nek megfelelo masik storynak kell mennie a sprintbol.
Ami nagyon fontos, hogy minden bug TDD-vel fixelendő, hogy megakadalyozzuk annak ujboli elofordulasat. Ha ez nem tortenik meg, akkor a fejleszto kormere kell csapni fakanallal jonagyot :-DDD. Kivetel ez alol persze, ha az egesz site meghalt es ultrakritikus szituacival allunk szemben.
Bocs a hunglishert elore, de lustva vagyok on-the-fly forditgatni :-)
Ja és még annyit, hogy sokan
Magyarul semmit sem _kell_
strukturalt workflowt teremt, ami total a csapatra van szabva, sem pedig koveti a dogmatikus Scrum-t a konyvbol.
tehat semmit nem kell csinalni, de minden csapatnak integralni kell a Scrum-ot a sajat szajize szerint? ;)
egyetertek, hogy nem kell mindenben a konyvhoz ragaszkodni, figyelembe kell venni a kornyezetet, amiben a Scrum hasznalva lesz, viszont:
1, altalaban mindenki azt hiszi, hogy az o esetuk kulonleges, mikozben az esetek 95%-ban azonos, vagy nagyon hasonlo a nagy atlaghoz.
2, vannak a Scrum-nak olyan elemei, amiket ha elveszel, akkor ami marad, az mar nem Scrum, vagy nem hatekony Scrum. Pl. ha nincs empowerment, nem a csapat time estimate-el, vagy nem ok dontik el, hogy mennyi User Story-t emelnek be a sprintbe, vagy ha a Team zavartalan munkaja nem biztositott, vagy ha a Stakeholderek nem elerhetoek, a User Story-k nincsenek kidolgozva, etc.
Utolag eszre vettem, hogy kicsit felreertettem amit irtal, te is azon az allasponton vagy, hogy ezeknek az "offtopic" megbeszeleseknek a standup utan kell folytatodnia.
Azert itt hagyom amit irtam, hatha segit masnak a megertesben:
A Daily standup nem a folyamatos megbeszeleseket helyettesiti a fejlesztok kozott, hanem egy napi biztos pontot ad, hogy a csapattagok es az SM mindenkepp tudjanak arrol, hogy ki mivel halad, mik a problemak.
Ez a megbeszeles azert time-boxed, es azert allva tortenik (es nehany helyen meg token is jar korbe es csak az beszelhet akinel van), mivel az egesz csapat jelen van, es nem akarjuk a csapat idejet rabolni a csak a csapat egy reszet erdeklo problemak melyebb megbeszelesevel.
Az en tapasztalatom alapjan pont hogy az a jellemzo a fejlesztokre, hogy nehezukre esik nem belemenni a reszletekbe ilyenkor, de idovel hozza lehet szokni.
Ez egy statusz report, nem pedig egy oldjuk meg a problemakat meeting. Azokra is szukseg van, es a Daily utan sor is kerulhet ra, de oda mar csak azokat az embereket fogjuk meghivni, akiknek ez relevans.
A daily scrum utan nyugodtan, illetve kozben is, ha tenyleg mindenkit erint, de egyebkent ez gyorsan el tud fajulni egy feloras technikai brainstormingba, ami nem feltetlenul erdekli az egesz csapatot.
Ez nem (csak) BA problemaja, kb. mindenki belefut ebbe, amikor elkezdi bevezetni a Scrum-ot. Nyilvan van ra tobb megoldas (pl. te is hoztal, o is irt), de alapvetoen en azt gondolom, hogy ha nem tudsz fenntartani egy csak feature-t fejlesztunk csapatot, es a hibajavitast mas eroforrasokkal megoldani, akkor a Scrum altal elkepzelt/elvart "a csapat mindenfele negativ kulso behatastol mentes, legures terben dolgozik" csak utopia.
Tyrael
A daily standup-n nagyon
Igy van, viszont sokszor a feloras brainstormingok indokoltak, de semmi esetre sem a standup kozben ;-). A SM, mint "meeting natzi" kozbeszol az ilyen esetekben es visszatereli a topicot a megfelelo iranyba, majd foglal egy szobat a brainstorming meetingre ;-).
Szerintem a SCRUM ugy magaban utopia... :-D Szerintem semmi problema nincs a bugokkal. Bug mindig volt, van, es lesz is. Ezt vagy elfogadod, mint tenyt, vagy csak magad fogod hiu abrandokba kergetni. En azert nem partolom a feature/bugfix csapatok jelenletet, mert teljesen ellene van kozos felelosseg, kozos tudas a kod felett cimu pontoknak, amik szerintem nagyon fontosak. Nem beszelve arrol, hogy rengeteg tapasztalatot lehet szerezni a rendszerrol bugfix kozben. Kb. az "edge case"-k 80%-a ott jon ki ami lehetove teszi, hogy a fejleszto ne kovesse el ugyanazt a hibat maskor, illetve segit neki behato ismeretekre szert tenni olyan komoponensekrol is ahol feature implementalaskor ugymond "nem jar". Nagyon sok mas pozitiv hatasa is van a bugoknak, folyamatos deployment meresehez is lehet hasznalni, es kideriteni hol a bottleneck a folyamatban. Meselhetnek meg sokat, de kozben meloznom is kene, dehat pentek van :-)
Kérdés - scrum master feladatai
Még ismerkedőben vagyok a scrum-mal. Mi a feladata egy scrum masternek ?
Pl az, hogy a csapaton belül van bárkinek bármi igénye (telefonja tönkremegy stb) az scrum master intézi ? És ha csapaton kívülre kolbászol egy kérdés, igény ? Mondjuk telepíteni kell valamit és a vállalat egyéb részei intézik, azt is a scrum master hajtja végig ?
Mi a meglátásotok arról, hogy ha az alkalmazás rendszerszervezője a scrum master egy olyan projektben, ahol egy új alkalmazást csinálnak ? Elbírja egy scrum master és egy rendszerszervező feladatát egy ember ? Nem kell ilyenkor még egy rendszerszervező ?
Üdv, Pista
feladatok
http://infokukac.com/2013/05/scrummastert-keresunk/
SCRUM
Azt kell, hogy mondjam, hogy - szerintem - a scrum csak addig a pontig működik jól, amíg a tervezésnél sikerül lehetőleg minden körülményt figyelembe venni. Mivel mi kis csapat voltunk, így nálunk ez megközelítőleg egész jól sikerült. Mindig tudtunk időt hagyni bugfixre, új funkciók tervezésére, stb. Persze volt, hogy maradt szabad időnk, de azt el tudtuk tölteni értelmesen. Egyébként a scrum - megint csak szerintem - nem agilis, mert ha nem tervezel be valamit, akkor mindegy milyen új, gyorsan megoldandó feladat jön(ne), nem tudsz vele foglalkozni, mert nincs rá időd (feltéve, ha nem terveztél be előre ilyen esetekre).
Szóval scrumnál minden a tervezésen múlik, hogy mennyire sikerül mindenre felkészülni.
:-)