A product backlog, ahogy mi szoktuk (Scrum-sorozat 2. rész)

Scrum-ról szóló cikksorozatom első részében egy rövid összefoglalást adtam arról, hogy mik a Scrum alapszabályai. Ígéretemhez híven folytatom azzal, hogy mi hogyan alkalmazzuk a Scrum-ot.

Ez a post product backlog-ról szól.

Mi a product backlog?

Az összes hátralévő funkció listája. Semmi “cicó”, egy sima lista. Semmi hierarchikus fastruktúra vagy az elemek között ide-oda mutató hivatkozások, függőségek. (Mint ahogyan egyesek szeretik a követelménykezelést emígyen túlbonyolítani.)

product backlog célja, hogy priorizálva tartalmazza, hogy mik azok a funkciók, amelyek a szoftver fejlesztéséből még hátra vannak. A Scrum nem is a funkció, hanem igazából a sztori kifejezést használja. Ennek a célja az, hogy rámutasson, hogy a product backlog-nak üzleti szempontból kell tartalmaznia a hátralévő feladatokat, funkciókat. (Story = mese, történet.) Tehát a product backlog nem tartalmaz olyan sort, hogy “admin felület szerveroldala”, lehetőség szerint olyat sem, hogy “admin felület” (helyette inkább pl. felhasználók és jogosultságaik adminisztrálása). Olyan sor sincs benne, hogy “telepítés” vagy “XY funkció tesztelése”. A product backlog egy banki webes rendszernél például ilyen sorokból (sztorikból) állhat:

  • Átutalás,
  • Számlatörténet lekérdezése,

Jó kérdés, hogy a szoftverben talált hibák bekerüljenek-e a product backlog-ba. Valakik szerint igen, valakik szerint nem. Én azok táborába tartozom, akik azt mondják, hogy általában ne kerüljenek be a hibák a product backlog-ba, kivéve akkor, amikor új sztoriról van szó. (Erről külön blogbejegyzés fog szólni.)

product backlog a Scrum stratégiai mozgatórugója. Ez jelöli ki, hogy a következő sprintben milyen sztorikat kell megvalósítani, ill. az azt követő sprintekben várhatóan milyen sztorik következnek. Ha a csapat már rutinos, és az adott projekt is zökkenőmentesen halad, akár pár hónappal előre is tervezhetünk a segítségével. (Mi meg tudjuk mondani, hogy a product backlog-ból milyen sztorikkal leszünk kész fél évvel később.)

Mi Excelt használunk. Sok programozó utálja (én szeretem). Soha nem akartam célszoftvert a product backlog szerkesztéséhez. Meggyőződésem, hogy nem lehet semmi sem olyan rugalmas erre a feladatra, mint maga az Excel.

Mi van pontosan a product backlog-ban?

product backlog nálunk a következő oszlopokat tartalmazza:

  • (A) azonosító: S-001-től indultunk (“S”, mint sztori). A következő felmerülő sztori a következő sorszámot kapja.
  • (B) sztori megnevezése: a sztori rövid megnevezése (pl. “számlatörténet lekérdezése”),
  • (C) prioritás: egy szám (súly), ami minél nagyobb, annál fontosabb a sztori, (OK-t írunk be, ha elkészültünk vele)
  • (D) sprint: melyik sprintben készült el a sztori (ha már kész van),
  • (E) becsült sztoripont: egy becslés, hogy az adott sztori mennyi ráfordítással készül el,
  • (F) megjegyzés: bármilyen szabad szöveges információ.

(A) Az azonosító

Minden sztorinak van egy egyedi azonosítója. Ez igen hasznos:

  • mert könnyen megtalálhatunk bármit, ha később újrapriorizáljuk a táblázatot;
  • a sprint során is hasznos a sztorik azonosítására;
  • amikor commit-álunk, feltüntetjük a sztori azonosítóját is a logban, hogy szükség esetén könnyebben összegyűjthetőek legyenek az egy sztorihoz tartozó commit-ok;
  • az ügyfél is megkapja a product backlog-ot, a sztorik azonosítói segítik a nagy táblázatban történő eligazodást.

A sztorik azonosításához az első felmerülő sztorihoz az S-001-et, a következőhöz az S-002-et s.í.t. használjuk. A sorszám nem utal a prioritásra, csak egy “buta” egyedi azonosító minden egyes sztorihoz.

(B) A sztori megnevezése

Teljesen nyilvánvaló, hogy szükséges egy rövid megnevezés minden sztorihoz. Az elnevezéskor vegyük figyelembe, hogy úgy adjunk nevet a sztorinak, hogy – lehetőség szerint – az ügyfél külön magyarázat nélkül is megérthesse.

(C) A prioritás

Valakik azt mondják, hogy úgy priorizáljuk a sztorikat, hogy ne legyen két olyan sztori, amely ugyanazt a prioritást kapja. A szándékuk érthető, mert azt szeretnék hangsúlyozni, hogy adott helyzetben mindig el lehessen dönteni két sztori közül, hogy melyik a fontosabb. Az én tapasztalatom viszont az, hogy ha sok elemű a product backlog (több tucatnyi sztori van benne), igencsak macerás egyedi prioritást adni minden sztorinak, mert product backlog folyamatosan változik.

Hogyan kezdjük a priorizálást, amikor épp egy nagy számosságú sztorihalmaz előtt ülünk? Az első sztori, ami szembe jön, legyen – mondjuk – 1000 prioritású. Jöjjön a következő. Hát, ez kevésbe fontos, mint az előző, legyen ennek a sorszáma 900. A harmadik sztori vajon milyen prioritású legyen? Az elsőnél nem fontosabb, viszont a másodiknál igen. Akkor legyen – mondjuk – 950.

Látható, ahogy egyre több sztorit priorizáltunk, egyre nehezebben találjuk meg az éppen vizsgált sztori helyét a sorban, mert mindig végig kell néznünk az összes már bepriorizált sztorit. Ezért célszerű inkább mérföldkövek alapján priorizálni. (Mi legalábbis erre jutottunk.) Ld. esettanulmány a cikk végén.

(D) Sprint (mint product backlog táblázat oszlop)

Amikor egy sztori elkészül, beírjuk a táblázat megfelelő oszlopába, hogy melyik sprintben készült el. Ezáltal utólag is látható, hogy milyen ütemben készültek el az egyes sztorik. (Pl. ügyféllel történő találkozáskor.)

(E) Becsült sztoripont

A sztorikat előzetesen “besztoripontozzuk”, azaz minden sztorihoz megbecsüljük, hány sztoripontot ér. (A sztoripontról majd a tervezési részben írok részletesen.) A csapat teljesítménye a sprintek során nagyjából állandó, de legalábbis előre tervezhető (szabadságolás, új ember kerül a projektre, valaki elmegy stb.) Ha tudom, hogy az elmúlt sprintek alatt hány sztoripontot teljesített a csapat, akkor elvileg kiszámíthatom, hogy – a prioritások alapján – az elkövetkezendő sprintekben milyen új sztorik fognak elkészülni.

A sprint tervezéssel ellentétben, ahol a csapat közösen becsli meg, hogy az adott sprintre betervezett sztori hány sztoripontot ér, a product backlog priorizálása közben a sztoripontozást én magam végeztem. (Mivel elég stabil volt a projekt és a csapat is, ezért viszonylag egyszerűen (és gyorsan!) ment a dolog. Utólag visszanézve stabilan 20%-kal felé lőttem a valóságnak, de ez annak is tudható volt, hogy mindig biztonságosan próbáltam előre több hónapra becsülni.)

Az angol szakirodalomban a becslés ezen módszerét Yesterday’s weather-nek hívják, azaz ha tudom, hogy az előző sprintben mennyit teljesített a csapat, akkor azzal számolva jól becsülhetem, hogy a közeljövőben hogyan fogunk tudni újra teljesíteni.

(F) Megjegyzés

Ezt az oszlopot csak időnként töltjük, ha úgy látjuk, hogy egy sztori kapcsán felmerült valamilyen releváns információ, amit célszerű feljegyezni. Akkor használjuk pl. ha a sztori megnevezése nem elegendő, vagy pl. azt is beleírjuk, ha az ügyféllel előre egyeztetni kell a sztori kapcsán.

Hogyan készül a product backlog?

Ha elkezdjük a Scrum-ot, csináljunk egy hozzávetőleges listát. Nem kell félnünk soha: a product backlog arra teremtetett, hogy változzon. Ha elszúrunk valamit, bármikor javíthatunk. Csináljuk kövspec alapján, csináljuk emlékezetből, nézzük a szoftver elkészült képernyőit, esetleg képernyőterveket, ami eszünkbe jut, és még nincs kész, jegyezzük fel. Ha terméket fejlesztünk, akkor különösképpen érdemes vizionált funkcionalitásokat is bele írni. Így lesz már egy jó kis listánk.

Pár jótanács:

  • A nagyméretű sztorikat próbáljuk több kisebbé alakítani! Ezáltal külön is fogjuk tudni priorizálni őket, és adott határidőre valójában kevesebb feladattal kell végezni (mert a nagy sztori egyik fele általában későbbre is elég).
  • Próbáljuk végig gondolni reálisan azt, hogy mi a tényleges(!) hatása annak, ha nem készül el időre egy sztori! Amin ilyenkor el szoktam gondolkozni: tényleg olyan nagy gond? Meglepően sokszor nem az, csak mindenki túldramatizálja a helyzetet. Járjuk körbe a témát, ne dőljünk be senkinek elsőre!
  • Végezzül el a priorizálást az ismert határidők, mérföldkövek alapján! (Ld. esettanulmány a cikk végén)
  • Ha már minden kötél szakad, és tényleg az látszik, hogy teljesíthetetlen határidőre a dolog, azonnal jelezzük az ügyfélnek a dolgot! A saját projektünkben az volt a tapasztalat, hogy a problémákat már idejekorán fel lehetett ismerni. (Nem két héttel a határidő előtt derül ki, hogy abszolut teljesíthetetlen a dolog.)

A product backlog állandóan változik. Mik a tipikusak?

  • Ha az ügyfélnek menet közben jön ötlete: semmi gond, bele rakjuk a listába, és bepriorizáljuk. Ha valóban fontos, akkor sorra fog kerülni, ha nem, akkor elsínylik. Sokkal jobb annak az optikája, hogy mindent, amit mond, betervezünk, és majd az idő (és pénz!) függvényében meglátjuk közösen, hogy tényleg belefér-e, mintha egyből figyelmen kívül hagynánk, amit mond.
  • Nagy sztorik vannak a product backlog-ban, amiket később lebontunk. Előbb-utóbb ki fog derülni, hogy vannak-e ilyenek, mert túl nagyok: nehezebben becsülhetőek, és hogyha mind megcsinálnánk őket, kicsúsznánk az időből.
  • Sprint (implementáció) közben kiderül, hogy van valami, amire nem gondoltunk. Ilyenkor két döntésünk van: vagy beleértjük a sprintbe az előre nem tervezett dolgot, és ezzel a sikeres sprintet kockáztatjuk, vagy pedig új sztoriként bevesszük a kérdéses elemet a product backlog-ba.
  • A későbbiekben a tesztelés során is kiderülhet, hogy valamire nem gondoltunk. Nem arra gondolok, hogy a programozó hibázott, hanem arra, hogy egy probléma hátterében valójában üzleti probléma áll. Mi rengeteg ilyennel találkozunk.

product backlog és az ügyfél

product backlog-ot az ügyféllel történő státusz egyeztetésekre is használjuk. Minden sprint végén el szoktunk látogatni az ügyfél megfelelő vezetőjéhez, és elmondjuk, miket csináltunk meg az elmúlt sprintben, és mik várhatóak az elkövetkezendőkben. Amikor az ügyfél szakmai embereivel beszélgetünk, akkor közösen egyezünk meg a sztorik prioritásáról. Magunktól végezzük el a sztorik priorizálását, és nekik ezt már csak “tálaljuk”. Így nekik nem kell sokat dolgozni, viszont ha valamivel nem értenek egyet, akkor azon közösen változtathatunk.

A product backlogot A3-as lapra nyomtatjuk, és úgy adjuk át az ügyfélnek. A közös megbeszélésen mindenkinek van egy saját példánya. Nagyon szokták szeretni. Be szoktuk rajzolni a táblázatba a mérföldköveket is.

Esettanulmány (prioritás meghatározása)

Mi a következőképpen gondolkoztunk 2008 év elején, amikor átnéztük a product backlog-ot:

  • (A) az ügyfélnek májusban oda kell adni a szoftvert, hogy az ügyfél kulcsoktatói (3 fő) felkészülhessenek az oktatásra,
  • (B) júniusban kezdőnek az oktatások és egész nyáron át tartanak (a rengeteg szabadságolás miatt), kb. 90 főt kell oktatni,
  • (C) október 1-jétől indul egy kéthónapos próbaüzem, amelynek célja, hogy a felhasználók megállapíthassák, hogy alkalmas-e a szofver az éles használatra, és kiderülhessenek valós felhasználás közben a szoftver hiányosságai,
  • (D) következő év (2009) január 1-jétől indul az éles üzem.

Ügyfél mondása 2008. januárjában: “a júniusi oktatásokig _mindennel_ el kell készülni!”

Szeretem ezt a mondatot. Annyiszor hallottam már. A háttérben arról van szó, hogy mindenki a saját s*ggét védi. A valóság persze ennél sokkal árnyaltabb. Ha a dolgok mögé nézünk, és ügyesek vagyunk, a mission impossible szituációkat is megoldhatjuk.

A product backlog nálunk akkoriban kb. 100 sztorit tartalmazott. Először elvégeztünk egy gyors “vágást”, és kizártunk minden olyan sztorit, aminek nem kell még működnie a 2009. január 1-jei éles indulásra. Ezeket elláttuk a 100-as prioritással. Ezzel a vágással a sztorik egy nagy részét sikerült a hatókörünkből eltávolítani. Minden sztorit, ami nem 100-as prioritást kapott, 1000-es prioritással láttunk el.

Minden 1000-es prioritású sztorit megbecsültünk. Ez alapján kijött, hogy az éles induláshoz (D) lefejlesztendő funkciókkal nem tudunk májusra (A) végezni, sőt, az összes funkció lefejlesztése nagyjából a teljes évet igénybe veszi (vö. ügyfél mondása). Kényszerhelyzetben voltunk, ezért tovább kellett gondolni a dolgot.

A következő lépés az volt, hogy meghatároztuk, hogy mik azok a funkciók, amik az (A) ill. (B) mérföldkőhöz kellenek (azért így párban, mert viszonylag közel voltak egymáshoz, és hasonlóak voltak az elvárások a két mérföldkőnél). A cél az volt, hogy azokat a sztorikat valósítsuk meg addigra, amiket a felhasználók túlnyomó többsége a leginkább használ. (Az nem annyira baj, ha van egy ritkán használt funkció, és nincs kész. Hiába oktatnák le a felhasználóknak, mire október lesz, addigra úgyis elfelejtik, és úgyis meg kell nézni a felhasználói kézikönyvet, vagy meg kell kérdezni a kulcsoktatót.)

A próbaüzemig (C) nagyjából mindennel készen kellett lenni. Ha egy funkciót nem tudtak leoktatni (mert az oktatások során készültek el, vagy idő közben megváltoztak), azokról készítettünk egy külön doksit a felhasználóknak.

Az időzítés nagyon fontos volt. Nem lehetett egy olyan rendszert oktatni, ami a használatba vételig (próbaüzem) a felhasználók zöménél jelentősen megváltozik. Sokat osztottunk-szoroztunk, sztorikat bontottunk fel kisebb sztorikra, abban a reményben, hogy az egyik része fontos, a másik nem annyira, végül sikerült egy olyan prioritást megalkotnunk, amely a mérföldkövekkel egybevágott. Az egyes mérföldkövekhez tartozó prioritások nagyjából a következők voltak:

  • A: 1000,
  • B: 900,
  • C: 500,
  • D: 300,
  • egyéb: 100.

Az érdekesség az volt, hogy még tudtunk játszani azzal is, hogy az oktatások során milyen sorrendben készüljenek el az újabb funkciók, ugyanis a felhasználók jól elkülöníthetően 3 csoportba tartoztak:

  • ügyintézők (kb. 75 fő),
  • vezetők (kb. 10 fő),
  • “admin jellegű” felhasználók (kb. 5 fő).

Tehát az oktatások elejéig az ügyintézői funkciókkal kellett meglennünk, és az oktatások végére kellett csak a vezetői ill. az “admin jellegű” felhasználók által használt funkciókkal elkészülnünk. Ígyhát a B és C közötti mérföldkövek között is fel tudtunk állítani plusz mérföldköveket, ill. prioritásokat.

Így sikerült megoldanunk azt a helyzetet, amikor az ügyfél kijelentette, hogy júniusra minden funkció kell.

Share
This entry was posted in Módszertan and tagged , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Comments

  • Izgalmas! Hol dolgozol? :)

  • Egyre inkább érdekel a SCRUM-mal kapcsolatban, hogy ki és mi alapján priorizál? Ebből a cikkből nekem az jön le, hogy a csapat végzi ezt. Nem a Product Owner feladata lenne ez? vagy a Product Owner is tagja a csapatnak?

  • pcjuzer: A Synergonnál.

  • Bárki lehet a product owner. A mi helyzetünk speciális, mert az ügyféltől jött át hozzánk Endre, ezért vele közösen csináljuk mindig a priorizálást (ő és én), és utána az ügyféllel is egyeztetünk.

    A product owner normál esetben nem a csapat része, de a mi esetünkben pont a csapatból van a product owner is.

  • Gáspár György

    Dec 13th, 2009

    A priorizálásban az a nagyszerű, hogy gyorsan látható, hogy mikor mivel kell majd foglalkozni, és mivel nem. Itt ez egy kétszintű dolog. Nagy segítség az on-the-site-customer, aki pontosan tudja, hogy az ügyfélnek mire van szüksége. Ha mégis vmi probléma a fejlesztés alatt derül ki, akkor ez a csapattól jön a product owner felé, és meg kell nézni közösen, hogy mit lehet vele kezdeni. Szerintem ezért tűnhet úgy, hogy a csapat végzi a priorizálást.

  • Nem gondoltam hogy válaszolni fogsz a céges kérdésre :), de ha már nem titok azt is megkérdezem, hogy a többi projektetekre is általában jellemző az agilis módszertan használata vagy csak a projektek kisebb részhalmazára?

  • pcjuzer: Egyáltalán nem jellemző. Egy projekt (egy csapat) esetében sikerült megvalósítani ezt a cég szoftverfejlesztéssel foglalkozó üzletágában. Szívesen írok még ezzel kapcsolatban, de inkább magánban :)

  • Kristof Jozsa

    Dec 18th, 2009

    függőségekre mi az utolsó best practice? :)

  • Kristóf: a product backlogban nem jelöljük a sztorik között függőséget.

    A sprinten belül az egyes kártyákon viszont igen. Ha valamelyik feladatot hamarabb kell elvégezni a többinél, azt más szinű cetlire nyomtatjuk (piros színűre). Így jelezzük, hogy az adott feladat "blokkol".

  • Kristof Jozsa

    Dec 18th, 2009

    és ha a product backlogból olyan prioritásos feladat kerül be a sprintbe, ami épül valamire ami nem került be? vagy ezt fejben kezelitek?

  • Kristóf: igen, fejben kezeljük, és ha szükséges a prioritással fejezzük ki a függőséget. (Ha egy sztori a másikra épül, akkor a másik prioritása is legalább akkora lesz, mint a ráépülő sztorinak.)

    Egyébként jellemzően nem volt problémánk azzal, hogy a függőségekkel kelljen foglalkozni a product backlog szerkesztésekor. Elegendő volt a prioritásra figyelni.

  • [...] érdemes legalább elgondolkozni pl. a Scrumban alkalmazott becslési módszereken. Kulcsszavak: product backlog, iterációk (sprintek, timeboxing), iterációk előtti tervezés, yesterday’s weather, [...]

  • Tibi bácsi az igazi DJ

    Aug 10th, 2010

    Nálunk is scrum van, és alapjában véve jól megy, de van egy-két bajom vele. Az egyik, hogy nem minden típusú projektnél lehet tiszta scrum, sokszor előre meg kell mondani, hogy mennyi idő és mennyi zseton lesz az adott projekt. Ilyenkor két részre szakad a projekt, az egyik az ajánlattétel előtti rész, amikor elég sok terv is elkészül. A második rész ilyenkor már csak valami imitált scrum a megvalósításra. Van haszna ekkor is a napi scrumok meg a feladatkiosztások rutinja miatt, de a teljes projektre akkor sem használható az első rész miatt.
    A másik gond, hogy a scrum (meg más agilis rendszerek is) egyenlőségjelet tesznek a résztvevők közé (bár némelyik megkülönböztet role-okat). Ennek sokszor nem tűnik fel a jelentősége, ha a csapat a scrum előtt hagyományosabb, hierarchikus felépítésű volt, pl volt egy vezető programozó, most lett belőle scrum master, és ha kell, fel tudja venni a diktátor sapkát (persze jó esetben erre nincs szükség), és idejében közbeavatkozni. Nálunk úgy alakult a csapat, hogy kb egy szinten voltunk. Nekem, mint scrum masternek lényegében csak adminisztrátív feladataim vannak a többiekhez képes. Emiatt hivatalosan csak szakmai véleménnyel és kritikával tudok fellépni a másik munkájával szemben, amit vagy megfogad, vagy nem. Van egy emberke, aki ezeket kevéssé fogadja meg, emiatt már sprintek óta megfekteti a demót (mert túltervez és nem lesz kész). Persze, így három sprint után már látszik magasabb szinten, hogy ott gond van, de magasabb jogosítványokkal ennek két hónapja elejét lehetett volna venni.
    Emiatt (és korábbi tapasztalatok alapján) szerintem van veszélye annak, ha nincs egy vezető programozó jellegű ember a scrumon belül, aki diktálhat, ha kell.

  • Tibi bácsi az igazi DJ

    Aug 10th, 2010

    “egy vezető programozó jellegű ember a scrumon belül, aki diktálhat, ha kell.”

    Úgy értem, deklarálni kell, hogy ő a többiek felett áll herarchiában, és döntési joga van fejlesztési kérdésekben.

  • Marhefka István

    Aug 10th, 2010

    Tibi bácsi az igazi DJ: Mindkét problémafelvetésed teljesen jogos, és a Scrum ezekre a kérdésekre nem is ad választ. Az agilitás adaptálása és alkalmazása körüli problémákat feszegeted. Leírom, mit gondolok én. Ezek további hosszas vitákat generálnak, remélem, nem is olvassák el sokan ;)

    Önmagában nem gond az, hogy fix a pénz, és fix az idő, csak a szkóp legyen mozgatható. Azaz, ne akarjuk kőbe vésni a legelején, hogy mit csinálunk meg, hiszen a bizonytalanság miatt senki nem képes megbecsülni, hogy az adott funkciókat időre meg lehet-e csinálni. És nem csak a becsléssel van a gond, hanem azzal, hogy az elején értelmetlenül túlspecifikált problémának a szolgai megvalósítása még több időt emészt fel, ahelyett, hogy értelmesen (=legtöbb értéket teremtve) használnánk fel a rendelkezésre álló időt.

    Ehelyett jobb, ha meghatározzuk az elérendő célokat, és “nagyvonalúan” specifikáljuk a problémát. (Hagyunk mozgásteret abban, hogy az elérendő célt a prioritások mentén hogyan érjük el.)

    Természetesen ennek megvalósítása számtalan problémát vet fel fejlesztői és ügyfél oldalon is. A felelősség áthárítása helyett a szerepet a bizalomnak kellene átvennie.

    Egy szigorú közbeszerzési eljárás keretein belül pl. nem is biztos, hogy ez így megvalósítható. Azonban ha az ajánlati kiírás nem akar mindent túlspecifikálni, viszont világosan megfogalmazza a célokat, akkor arra adható olyan ajánlat, ami hasonlóan nagyvonalú, és a megvalósításra például felajánl egy előre meghatározott embernapot. (Mi most épp ilyen közbeszes projektet nyertünk el.)

    Másik téma. A csapatmunka kérdése önmagában is érdekes. Én úgy gondolom, hogy a csapatnak egyet kell értenie a szakmai döntésekben. Az idő, amíg összeszokik egy csapat (ha egyáltalán sikerül neki), és eljut egy olyan szintre, hogy egymásban képesek megbízni a csapattagok, és közösen döntéseket hozni. Véleményem szerint ha valaki azon a véleményen van, hogy vezető fejlesztőt kell kinevezni a csapat élére, mert nem lehet érvényesíteni a megfelelő szakmai érdekeket, az azt jelenti, hogy nem sikerült csapatot építeni, és diktatúrával próbálják “helyreállítani a rendet”. Ezért fontos, hogy legyen egy nagyon jó ScrumMaster a csapattal, aki segít belőlük valódi csapatot kovácsolni. Ehhez megfelelő soft skillek kellenek ScrumMaster oldalról. Bennünk az is felmerült, hogy szakmai embert nem érdemes ScrumMasternek beállítani, mert a saját szakmai véleményét próbálná ráerőltetni a csapatra. (Mint ahogy Te is említetted, hogy nehezen tudod megállni, hogy ne szólj bele az egyes szakmai vitákba.) Javaslom egyébként a HVG kiadásában megjelent, “Kell egy csapat” c. könyvet.

    Az “idegen elemeket” pedig, akik nem képesek a csapatjátékra, és tönkre teszik a csapat munkáját, el kell távolítani.

  • Tibi bácsi az igazi DJ

    Aug 11th, 2010

    Érdekes, hogy pont azt írod, hogy a szkóp legyen mozgatható, amikor a pénz és az idő fix. Általában a scope creep az egyik ördög, ami az árokba tudja vinni a projektet. “Ja, mi ezt nem így gondoltuk, hanem így + meg úgy meg amúgy” és ott van ötször annyi munka ugyanannyi pénzért ugyanarra a határidőre. Igen, pont ez magyarázza, hogy mért jó a scrum, de ezt a megrendelőnek is el kell fogadnia. A scrumhoz nagy bizalom kell, valljuk be, és az üzleti életben ez magyarországon (de biztos máshol is) kicsit kényes. Elméletileg a scrumban a megrendelő pont annyit fog fizetni, mint amennyit az adott munkáért fizetni kell. A fix költség és időkeret esetén ugye azt csinálta az ember, hogy meghallgatta a megrendelőt, kalkulált idővel + emberrel, megszorozta egy realítási szorzóval (pl 1.4) és erre adott ajánlatot. Ha jól becsültek tervezésnél, akkor a megrendelő kifizette a fejlesztéshez szükséges pénz 1.4-szeresét. Ha rosszul, ott volt a puffer. Ha nagyon rosszul, akkor kezdődőtt a háború a fejlesztőcég és a megrendelő között. A megrendelő igazából akkor járt jól, ha a középső eset valósult meg (felhasználta a realitási szorzó által adott puffert) mert akkor kb annyit fizetett, amennyi munkaértéket kapott. A scrumnál nincs ilyen gond, és mégis, a megrendelő nehezen fogadja el, hogy “khm, nem igazán tudom megmondani, hogy mennyibe kerül, de csináljuk úgy, hogy menetközben fizeted”. Ez teljesen ellentmond a mai pénzügyi tervezési módszereknek. A megrendelőnél a pénzügyesek nem tudják kiszámolni az excel táblázatokat, a vezetésnél meg a diagrammok végén ott fityeg egy bazinagy tölcsér, mint az időjáráselőrejelzésnél a 3-10 nap közötti rész. Szerintem ezt nagyon sokan és sokáig még nem fogják elfogadni. Nem jó, hogy így van, de hát a megrendelő az úr, akkor jöjjön a realitási szorzó, és reménykedünk, hogy más szoftverházak nem dolgoznak kisebb szorzókkal.
    Csapatmunka tekintetében, bár jól hangzik az együttműködés, azért aki már sok emberrel dolgozott együtt, az tudja, hogy ez egyáltalán nem síma ügy. Ha veszünk tíz fejlesztőt, abban nagy valószínűséggel akad egy olyan, akinek gyakran van különvéleménye (ami nem baj) és emellett meggyőzhetetlen (na ez a baj). Egy csapatban, bár azt mondjuk, hogy egyenrangúak, meg konszenzus, meg minden, azért az a jellemző, hogy egy vagy két ember kiemelkedik a szakmai előnye miatt, a többiek ezt többnyire automatikusan elfogadják, sőt, az emberek egy részének igénye van rá, hogy amit gondol, azt valaki nyugtázza, ezek maguktól kikérik a tapasztaltabbak véleményét (ami amúgy nem biztos, hogy a legjobb, de nagy valószínűséggel nem rossz). A meggyőzhetetlen kollegával szemben ezek a dolgok nem működnek. Jó esetben ki lehet könnyen pakolni, de ha a korábbi cowboyos időszakban az emberke bedrótozta magát a cégbe, akkor ezekkel a hirtelen mozdulatokkal vigyázni kell. A vezető programozó rang legalább rövid távon megoldás lehet, hogy ne szülessenek HammerFactory<HaftFactory, HeadFactory> típusú megoldások, ha a szerencsétlen rendszerben csak gumifejű kalapácsok lesznek, és soha semmi más. Persze az így korlátozott ember, ha nem meggyőződésből csinál valamit, a munkája sokkal rosszabb minőségű lesz, de ebben a kicsavart esetben amúgy is rossz lett volna. A többi emberrel szemben meg nem kell alkalmazni a vezető programozó sapkát, mert azok úgyis szakmai vezetőnek tekintik az embert, ha ki lett mondva, ha nem.
    Szóval biztonsági szempontból szerintem jól jön egy deklarált vezető.

  • Tibi bácsi az igazi DJ

    Aug 11th, 2010

    ok, bár nem lényeg, leszedte a kacsacsőrőket, szóval:
    HammerFactory(HaftFactory(Wooden), HeadFactory(Rubber))

  • Marhefka István

    Aug 11th, 2010

    Mi baj a mozgó szkóppal? Nem arról van szó, hogy végül 2x annyi funckiót fogunk lefejleszteni a végére, mint amennyit kellett volna, hanem sokkal inkább arról, hogy sok felesleges funkció (amit az elején a megrendelő emberei megálmodtak) nem kerül kifejlesztésre. Ezek helyett az értelmetlenül kitalált funkciók helyett pedig megvalósulhatnak olyanok, amelyekre valójában nem is feltétlenül gondoltak. Prioritások mentén haladva hamar készíthető olyan rendszer, amely működik, és használható, és ezzel elég sok kockázatot lehet kiküszöbölni.

    Nem értem, miért írtad, hogy nem tervezhető pénzügyileg a projekt, hiszen fix az árad (és a határidőd is). A Scrum nem azt jelenti, hogy addig húzzuk a projektet, ameddig csak akarjuk, és közben meg tejel az ügyfél. (Bár ha az ügyfélnek sok pénze van, akkor ezt meg lehet tenni.)

    “A fix költség és időkeret esetén ugye azt csinálta az ember, hogy meghallgatta a megrendelőt, kalkulált idővel + emberrel, megszorozta egy realítási szorzóval (pl 1.4) és erre adott ajánlatot.” – Ez az én olvasatomban annyit jelent, hogy a hasunkra ütünk. A valóság az, hogy fogalmunk sincs mennyi idő alatt lehet megcsinálni a rendszert (áltatjuk magunkat mindenféle becslésekkel), és tudjuk (sejtjük) azt, hogy a megrendelő mennyi pénzt szán a projektre. Az árat pedig ahhoz lőjük be.

    Ha az ügyfél nem hajlandó megérteni, hogy jobb neki, ha más munkamódszerrel dolgozunk, és makacsul ragaszkodik a tradicionális módszerekhez, akkor az elején nincs sok lehetőséged. Azonban ha például a háttérben “scrumszerűen” dolgozol, tehát a legfontosabb prioritású feladatokat veszed előre, és bizonyos rendszerességgel az elkészült funkciókat bemutatod, akkor a folyamat során az ügyféllel bizalmi viszonyt tudsz kialakítani. Látja, hogy merre megy a projekt, van lehetősége beleszólni, és – ha szerencséd van – idővel tudsz majd hatni rá, és olyan irányba terelheted a fejlesztést, ahogyan az elején még nem tudtad volna. Ki tudja? Lehet, hogy a végére már nem is fog annyira ragaszkodni a sok mindenhez, amit az elején kitalált, mert látja, hogy már így is működik a rendszer, és jobb is, mint amire számított.

    Persze, ha megnézni sem hajlandó menet közben a készülő rendszert, akkor nem tudsz mit tenni. Ilyenkor számomra az is megkérdőjeleződik, hogy valóban akarja-e, hogy a rendszer elkészüljön, vagy csak a főnökei erőltetik rá a dolgot. Ez egy olyan probléma, amivel szoftverfejlesztőként nem tudunk mit kezdeni.

    A háborúval egyetértek, és az egész agilitásnak pont az a lényege, hogy az ilyen helyzetek ne forduljanak elő.

    A csapatmunkával kapcsolatban nem tudok fix receptet mondani, minden csapat más és más. Hajlok egyébként egyetérteni Veled, hogy kell vezető fejlesztő a csapatba, de valójában – mint ahogy írtad is – a csapaton belül idővel kialakul egy “erőegyensúly”, és meglesz, hogy kik azok, akikre jobban hallgatnak a többiek. Egyébként a mi 3 éve tartó scrumos projektünkben hosszú ideig két vezető fejlesztő beosztású ember is dolgozott. Az egyik én voltam, de a másik srác volt a kinevezve a projektbeli vezető fejlesztőnek. Nemigen kellett érvényesítenie a srácnak a vezető fejlesztői szerepkört, mert mindig meg tudtuk beszélni a problémákat, és a csapattal közösen kitalálni a legjobb megoldást.

    Én egyébként elrugaszkodnék a Scrumtól, hiszen az csak egy konkrét recept (persze, sok helyen tesreszabható), inkább azon gondolkoznék, hogy mik a valódi okai annak a sok problémának, ami a szakmánkban előfordul. Érdemes revidiálni azt a sok marhaságot, amit az elmúlt évtizedekben egyesek kitaláltak, és mások pedig vakon követtek. Nincs olyan, hogy valamit így kell, vagy úgy kell csinálni.

  • Marhefka István

    Aug 11th, 2010

    Ezt a gumifejű kalapácsos hasonlatot nem ismerem. Felvilágosítanál? :)

  • Tibi bácsi az igazi DJ

    Aug 11th, 2010

    A mozgó szkópnak te a jó oldalát írtad le, én meg a rosszat. Sajnos láttam már olyat, hogy a megrendelő még “mögé gondolt” dolgokat a feladatnak, és aztán lehetett birkózni, hogy az még belefér-e, vagy nem. És teljesen igazad van, nincs fogalmunk arról, hogy egy feladat mennyi idő. Nagyságrendekről van, hogy napok, hetek, vagy hónapok. Emlékszem, ebből a második munkahelyemen jó 15 éve sok probléma volt, kérdezték tőlem, hogy miért nem lehet megmondani, és előrántották az ócska házépítős példát, hogy bezzeg ott meg tudják. Azt mondtam, hogy ha mondok egy találós kérdést, akkor meg tudja-e mondani, hogy mennyi idő alatt fejti majd meg? Mert a szoftverfejlesztés egyik része találós kérdés, a másik pedig rutin feladat. A ház építésénél meg majdnem minden rutinfeladat. Persze ettől még meg kellett mondani, hogy mi mennyi idő, mert ki kellett (volna) számolni a pénzeket. Kétezer körül már jöttek a gyakorlatban is az iterációk (RUP), mostanra meg egyre több scrum-os vagy más agilis fejlesztés van egészen rövid iterációkkal. Szóval a világ kezdi belátni, hogy a szoftverfejlesztés más, mint a házépítés, nyilván ez a nézet belülről terjed, de remélem előbb utóbb majd az ügyfelekre is tömegesen ragad. Te azt írod, hogy fix az ár és a határidő is, de az igazi scrum esetén ez nem fix, max abból a szempontból hogy adott típusú fejlesztőért naponta ugyanannyi pénzt kérek. Nyilván, ha csak laza feladatdefinícióm van a projektre (product backlogok, amik változhatnak is) akkor nem tudok időt mondani még annyira sem, mint a hagyományos vizesés jellegű módszereknél. Hallottam olyan cégről, akiknek ezt néhány ügyfele már megette, és így dolgoznak (lényegében bérlik a fejlesztőket idő alapon). Ezért kicsit bizok benne, hogy egyszer majd ez általánosabb lesz, bár teljesen tuti nem. Ha van egy cégnél egy keret valamire, akarják majd tudni, hogy az elég-e vagy nem. Vagy megtérüléssel akarnak számolni, ehhez nekik kell pontosan, mennyibe kerül a program. Szóval sok pénzügyi számításhoz kell a fix összeg (vagy legalább egy maximum összeg). De igazad van, hogy a háttérben a scrumot még ekkor is érdemes csinálni, nagyos sok jó rutinja van (feladatok ütemezése, számonkérés, stb).

    Az szoftverfejlesztés problémái szerintem sok forrásból táplálkoznak. Az egyik például a már említett találós kérdés jellegű feladatok, ami rengeteg bizonytalanságot tesz bele. Egy másik probléma, hogy a szoftverfejlesztést, akik szeretik csinálni, egyfajta művészetként fogják fel (és a művészet öncélú) ugyanakkor ipari célokra használják (csináld ezt és ezt, mert erre fogjuk használni). Ez a programozóban ellentéteket sző, mert szeretné megcsinálni minél jobban és szebben, ugyanakkor üzletileg a “legyen éppenhogy jó” a cél. Nagyon sok “Gold plating” antipatternt gyakorló fejlesztőt láttam már, és kb erre akartam utalni a HammerFactory-s példával is. Megmondom őszintén én nem nagyon örülök például a design patterns-nek és a napjainkban köré épített kultusznak. Azokat a patterneket egy jó eszű fejlesztő kb ugyanúgy használta régebben is, csak más nevekkel. Ma viszont sok tejfeles szájú azon erölködik, hogy minél több patternt belevigyen a munkájába, még akkor is, ha teljesen felesleges, de elegáns. Ja, elegáns, csak tizszer annyi idő lefejleszteni, mások számára nehezen átlátható az absztrakciók miatt, és bár biztos bazi rugalmas adott szkópon belül, de az ügyfél tutifix mond egy olyan esetet, amit már nem tud, és akkor lehet átszabni a tíz szintű objektum és interfész hierarchiát. Ez a túltervezés talán az engem legjobban idegesítő dolog manapság. Aztán ami gondot láttam még, az “Architetcs dont code” anti-pattern (bár a design patterneket annyira nem szeretem, az anti patterneket irdatlan hasznosnak látom, minden fejlesztőnek negyedévente át kéne nézni őket). Azokban az időkben, amikor két év alatt kidobnak egy új .net verziót, pedig az ember még az előzőt sem volt képes megtanulni, akkor megengedhetetlen, hogy valaki beleszóljon architektúrális kérdésekbe anélül, hogy gyakorló fejlesztő lenne. Sőt, az a véleményem, hogy az architectnek kell lenni a legűberkirályabb programozónak a vidéken. Ellenben pár helyen az a gyakorlat, hogy az emberke olyan előrelépésnek veszi ezt a titulust, hogy a koszos munkát ő már nem csinálja. Ugyanez igaz azokon a helyeken, ahol egy kisebb csapatot (pl 10 főt) irányító emberről van szó. Ha más nem, az ideje 10%-ban programoznia kell, mert kiesik a ritmusból, két év múlva nem fogja ismerni a lehetőségeket és problémákat, és irreális elképzelései és elvárásai lesznek. Ezzel kicsit kapcsolatos probléma, hogy a nagyobb cégek (microsoft, oracle) termékbejelentőin csinálnak olyan bemutatókat, amit az előbb említett már nem programozó középvezető megnéz, és azt hiszi, hogy három sor meg két kattintás, és készen van a program. Ezeket a bemutatókat be kellene tiltani :D. Nagyobb cégeknél láttam olyat, hogy úgy vesznek fel embereket, hogy ki sem tesztelik őket, és ráadásul havi 10-20-at. Ez öngyilkosság, egyrészt havi 10-20 jó embert nem lehet szerezni a piacról, másrészt tesztelés nélkül felvenni valakit milyen dolog, harmadrészt havi 20 fős bővülést menedzselni szerintem nagyon nehéz, nem tudják beilleszteni az újakat ilyen gyorsan. Volt is ebből gond annál a cégnél később, rengeteget csúsztak a projektek. Aztán olyat is láttam, hogy elküldték az embereket tanfolyamra, és azt hitték, hogy majd most már majd ismerik a területet. Nem tudom voltál-e már ilyen technológiai tanfolyamon, de szerintem ott alig lehet valamit tanulni. Eldarálják az anyagot, de azt egyrészt megjegyezni sem lehet, mert sok, másrészt az összefüggések is csak nagyon halványan derülnek ki, mert a sok újdonságot nehéz átlátni. A cég azt hiszi, hogy sokat tesz az emberekért, amikor elküldi őket többszázezer forintos tanfolyamra, és ennyi pénzért joggal el is várja, hogy az emberek jók legyenek. De az oktatás támogatása szerintem nem ebből áll. Abból áll, hogy megfelelelő mennyiségű időt enged tanulásra, megveszi a fél amazon.com-ot, esetleg homokozós projekteket indít a technológia próbálgatására. Különben lesz pár lelkes ember, aki a szabadidejét próbálja tanulásra fordítani, és fogja tudni, a többiek meg lemaradnak. És ezek az új technológiák nagyon összetettek, sok idő kell nekik.
    Hát, én hirtelen ezeket a jellemző gondokat látom, ha van valami ötleted még, szívesen olvasom.

  • Marhefka István

    Aug 13th, 2010

    Nagyon sok jó dolgot írtál!

    “Sajnos láttam már olyat, hogy a megrendelő még “mögé gondolt” dolgokat a feladatnak, és aztán lehetett birkózni, hogy az még belefér-e, vagy nem. ” A kockázat sajnos, mindig megvan, hogy utólag derül ki még egy-két dolog. Annyit tehetünk, hogy profi módon folyamatosan csökkentjük a kockázatokat. A folyamatos visszajelzések (http://infokukac.com/2009/08/a-visszajelzesek/) segítenek abban (pl. a Scrum demói), hogy ne csússzanak félre a dolgok, és fontos az is, hogy úgy kezdjünk egy szoftverfejlesztési projektbe, hogy értünk is az üzleti oldalhoz valamit. (Ha nem értünk, akkor hozunk valakit.)

    Igen, én is “imádom”, amikor a házépítős példát veszik elő műkedvelő menedzserek. Pár évvel korábban, amikor még hajlamos voltam elhinni dolgokat, egy PM azt mondta nekem, hogy ha nem volt jó a becslés, akkor azért a vezető fejlesztő a felelős. Ugyanis az ő szakmai kompetenciája az, hogy megmondja, hogy egy projektet mennyi idő alatt lehet elvégezni. És ha nem tudja megmondani vagy rosszul becsült, akkor nem jó vezető fejlesztő.

    Egyetértek, hogy kezd a világ rájönni, hogy lehet jobban is szoftvert fejleszteni, mint ahogy eddig képzeltük. Csak még nem látom a fényt az alagút végén :) A szoftverfejlesztésben nagyon nagy a bizonytalanság és irtózatosan komplex is, ezért nem is működhet, ha az nem az emberekről szól, és nem alap a bizalom. (Kivéve persze, ha 100 év múlva már úgy fejlesztünk szoftvert mintha a szoftverfejlesztés is gyártásipar lenne. A fejlesztők munkások lesznek, akik “a futószalag mellett” illesztgetik össze az előre legyártott modulokat.)

    “Te azt írod, hogy fix az ár és a határidő is, de az igazi scrum esetén ez nem fix”. Én a fix árat és határidőt csak példaként említettem, és tudomásom szerint a Scrum egyáltalán nem írja elő, hogy milyen legyen a projekt határidő és finanszírozás tekintetében. Az agilis projekteknél általában annyi csupán a felvetés, hogy a három korlátozó tényezőből (ár, szkóp, határidő) legalább 1 legyen, ami nem rögzített. Ahonnan én jövök, ott általában az a jellemző, hogy a projektnek van egy költségvetése (fix ár) és meghatározott határideje, és persze – “jó” szokás szerint – a szkópot is bebetonozzák, biztos, ami biztos alapon. Ebben a fejlesztő cég és a megrendelő együtt tevékenykedik.

    “Ez [a szoftverfejlesztés művészet] a programozóban ellentéteket sző, mert szeretné megcsinálni minél jobban és szebben, ugyanakkor üzletileg a “legyen éppenhogy jó” a cél.” Azzal én is egyetértek, hogy amit csinálunk, az funkcionálisan a lehető legminimálisabb dolog legyen, amit még használni lehet. Ennek nagyon sok előnye van: hamar elkészül valami, amit használatba lehet venni, és a tényleges visszajelzések alapján lehet rajta finomítani, és azáltal hogy nem fejlesztünk felesleges funkciókat, időt nyerünk, és egy egyszerűbb szoftvert is kapunk, amit – a kisebb komplexitás miatt – könnyebb továbbfejleszteni, karbantartani. Viszont annak ellenére, hogy a funckionalitásban az egyszerűségre törekszünk, a kód szintjén a minőséget meg kell tartani (clean code, automatizált tesztek). Ez nem azzal egyenlő, hogy túltervezem, túlabsztrahálom a kódot (overengineering).

    A design patternekkel kapcsolatosan is teljesen egyetértek Veled. Túlbonyolítottak és túllihegettek. (Ez megér egy önálló posztot.)

    Az, aki nem kódol, az számomra nem hiteles, ezért ne is hozzon architecti döntéseket a projektben. Másrészt saját véleményem, hogy egy projektben minimalizálni kell azon emberek számát, akik effektíve nem kódolnak. (Ez nem azt jelenti, hogy egy csapat csak fejlesztőkből álljon.) Így az olyan ember, aki architekturális döntéseket akar meghozni, és nem kódol, ilyen értelemben mellőzhető, mert nem termel értéket, csak okoskodik.

    A nagy cégek által tartott agymosó prezentációkat én is utálom. Vannak ismerőseim, akik egy időben egy ilyen nagy cégnél fejlesztőként/tanácsadóként dolgoztak. Amikor velük beszélgettem, akkor – szó szerint – fanatizmussal szembesültem a saját mammutcégünk termékei iránt. Egyetértek azzal is, hogy általában nincs sok értelme a fejlesztői tréningeknek. Az előadók elfogultak a technológiájukkal kapcsolatban, mindig csak a felszínt kapargatják, és persze a valóságban mindig kiderül, hogy nem úgy vannak ám a dolgok, ahogy azt mi hittük… Csak akkor már késő. Aki tanulni akar, használjon Google Readert (vagy más blogolvasót), és iratkozzon fel egy csomó blogra. Sokkal többet tanulhat napi 20-30p olvasással, mintha tréningekre járna.

    Hát, most nem kezdenék bele abba, hogy mi az, amivel nem értek egyet, és rosszul működik az iparban :) Erről szól az egész blogom :) Ha most kapásból egy dolgot kellene említenem, az a szakmai analfabetizmus lenne.

    Remélem, kommentelsz majd más cikkekhez is. Bár nem tudom, mi pontosan az érdeklődési köröd a szoftverfejlesztésen belül, kíváncsi vagyok az adott témák kapcsán a véleményedre!

  • Hesz Roland

    Aug 17th, 2010

    “előrántották az ócska házépítős példát, hogy bezzeg ott meg tudják.”
    Aki látott már építkezést, az persze tudja, hogy bezzeg ott sem. :)

    “A design patternekkel kapcsolatosan is teljesen egyetértek Veled. Túlbonyolítottak és túllihegettek.”

    Igazából nem túlbonyolítottak. Az értelem nélküli használatuk ami túlbonyolított.
    Mindenki azt felejti el, amit a kezdetektől kezdve minden könyv és cikk sújkol (már a mérvadók :) )
    “A mintákkal ésszel kell bánni, a cél nem az, hogy beleszuszakoljuk a programba őket, hanem hogy ha valaki azt mondja Proxy vagy Chain of Command, akkor mindenki tudja miről van szó.
    Egy egységes nyelvezet kialakítása volt a cél a már meglévő, és mindenki által használt megoldásokra.”

    Csak hát ugye az emberek ráugrottak, és anélkül, hogy megértették volna miről szól, elkezdték tuszkolni mindenhová, ha kell, ha nem.
    A “Silver Bullet” vagy “Buzzword” anti-pattern.
    Ésszel használva hasznosak, ész nélkül meg semmi sem az.

  • Marhefka István

    Aug 23rd, 2010

    “A mintákkal ésszel kell bánni, a cél nem az, hogy beleszuszakoljuk a programba őket, hanem hogy ha valaki azt mondja Proxy vagy Chain of Command, akkor mindenki tudja miről van szó.”

    Egyetértek. Azonban szerintem jobban jár azzal valaki, ha a GoF-os könyv helyett inkább a refaktorálásra, TDD-re és a clean code írására fekteti a hangsúlyt. (A munka során úgyis mindenki megtanulja, mi az a factory, singleton stb.)

    Pár hete osztottam meg egy cikket Twitteren a szükségtelen absztrakciók kiküszöbölésével kapcsolatban. Szerintem jól szemlélteti, miért nem érdemes design patternekben gondolkozni. http://raptureinvenice.com/?p=103

  • Hesz Roland

    Aug 26th, 2010

    Egyetértek, nem szabad patternekben gondolkodni.
    A cikk a -szerintem is – helyes pattern használatot írje le. Megírod a kódot, azonosítod, hogy mi lehet esetleg jobb egy pattern megoldásban, refactorálsz.
    Nem pedig rögtön pattern-eket irogatsz.

    Azzal, hogy valaki ne a GoF-os könyvet olvassa rögtön, azzal egyetértek. Elég száraz, nehézkes olvasmány. Sajnos amikor én kezdtem ismerkedni ezekkel, akkor finoman szólva is nehéz lett volna munka során megtanulni a Factory meg Singleton fogalmakat.
    Ha nagyon őszinte akarok lenni, akkor még ma sem mindenhol evidens. Mint ahogy a refactoring és a TDD sem.

    Ahová most szerződtem, itt hála istennek ismert dolgok. És ennek örülök. Talán még kódolnom is sikerül majd valamennyit :)

  • Elég sok kérdést felvet a scrum. Az is része a módszertannak, hogy ne legyen sok dokumentáció, ahol a végletekig specifikáljuk a megvalósítandó rendszert. Ugyanakkor a backlog itemekben mégis csak le kell írni, hogy mi afenét is kellene csinálni. Van olyan fejlesztő, akinek nem elég, ha nincs minden részletesen meghatározva, mert akkor ideges lesz, hogy ő nem tudja mit kell csinálni és így nem lehet dolgozni. Vannak olyanok, akik hozzászoktak már a részletes specifikációhoz és igénylik is, mert így a felelősség részben áttolható annak a készítőjére.

  • Igen, a Scrumot mindig adaptálni kell a helyi viszonyokhoz, de ez természetes is, hiszen minden projekt és szervezet más és más, nem lehet egy egyenfolyamattal minden igényt kielégíteni (no silver bullet).

    Tapasztalatom szerint a következők nagy hatással vannak arra, hogy feleslegesen növeljék a dokumentáció méretét:

    1. A fejlesztő egyéni motivációja. Motiválatlan fejlesztő azt akarja, hogy “tollba mondják”, mit kell csinálni. Motivált fejlesztő maga találja ki és maga jár utána, hogy mit és hogyan kell csinálni. (Ugyanaz a személy különböző környezetekben más és más motivációs szinten dolgozhat.)

    2. Diszfunkcionális projektszervezet, bizalom hiánya.
    a) Bizonyos szerepkörökben dolgozó emberek, hogy igazolják munkájukat, felesleges dokumentumokat gyártanak (tipikus betegsége a BA-knak és tesztelőknek).
    b) Szereplők, akik nem bíznak egymásban, dokumentumokban rögzítik az elvárásokat egymással szemben. (Megrendelő-szállító cég, BA-fejlesztő, tesztelő-fejlesztő stb.).

    3. Értelmetlen szoftverfunkciók, rossz döntések, amik növelik a komplexitást. Példák:
    a) ha a megrendelő egy nagyvállalat/állami cég, hajlamos feleslegesen duzzasztani a szkópot, hogy a belső politikai viszonyoknak eleget tegyenek.
    b) fejlesztő cég felesleges funkciókat fejleszt (lenyűgözze a megrendelőt/felhasználókat, azonban a funkciókat a kutya se használja majd, “ezt majd úgyis meg kell csinálni 1 hónap múlva”, “legyen általános” stb.)
    c) rossz architektúra, rossz csapatfelosztás, rossz folyamatok.

Leave a Comment