Agilis módszertan = teljesítési kényszer?
2022-09-15T11:27:29+02:00
2022-09-30T16:09:56+02:00
2022-09-30T16:26:17+02:00
  • Szerintem azert a becsles ertelme az, hogy valaszt adjon ezekre a kerdesekre, nem?

    De erre születik válasz. Az iterációnak van egy fix hossza, tudjuk mit képes szállítani a csapat egy adott iterációban. Ami benne van, az kész lesz az iteráció végére.

    Senkit nem erdekel hogy "Mennyire osszetettnek gondolja a csapat", ha az ido/penz dologra nem tudnak ertelmes valaszt adni.

    Dehogynem érdekli. Minél összetettebb valami, annál nagyobb bizonytalanság van a becslésben.

    Egyébként miért ne tudnának értelmes választ adni az idő/pénz-re? Tudnak, de ez nem a fejlesztési módszertan feladata. A fejlesztési módszertan annak biztosítására való, hogy a vállalásokat (tehát már megbecsült, árazott, szerződött dolgokat stb) teljesítse a cég határidőre.
    Mutasd a teljes hozzászólást!
  • Márpedig ha időben fejezed ki a csapat velocityjét, akkor kilóra méred a teljesítményüket. És akkor jön a teljesítménykényszer, az alul, vagy túlvállalások stb.

    Ha át kell írnod valamit egy configban, az mennyi idő? És ha 5 másik rendszerrel együttműködve lehet csak végigtesztelni és végigvinni a környezeteken, akkor mennyi idő? Ha ez egy kritikus váltás, amit ki kell vigyél prodba sprint közepén? Ki tudod ezt fejezni idővel a becslés során?

    Szerintem azert a becsles ertelme az, hogy valaszt adjon ezekre a kerdesekre, nem? Azaz "Mikorra lesz kesz?" meg "Mennyibe fog kerulni?". Senkit nem erdekel hogy "Mennyire osszetettnek gondolja a csapat", ha az ido/penz dologra nem tudnak ertelmes valaszt adni.

    Azert valahol a fejlesztett rendszer egy uzleti problemat fog majd megoldani, es egyreszt az uzletnek nem mindegy hogy ket honap mulva tud megjelenni a piacon a megoldassal vagy ket ev mulva, masreszt meg ritka az olyan uzleti terv is hogy a koltsegek oldalon fekvo nyolcasok szerepeljenek mert a lenyeg hogy rugalmasak legyunk meg hogy a fejlesztoket ne nyomasszuk azzal hogy kilora merik oket...
    Mutasd a teljes hozzászólást!
  • Minden becslés figyelembe veszi a csapatot, annak összetételét. Ha kicserélsz egy embert, akkor nem feltétlen tartható a cél tök mindegy, hogy miben mérsz.

    És mi fog történni, ha az látszik, hogy A csapat X órányira becsült taskot szállít sprintenként, B csapat pedig 0.75*X-et ugyanannyi emberórányi sprint alatt? Most akkor B csapat kevésbé hatékony, vagy kevésbé becsül jól? Esetleg bonyolultabb feladatokon dolgozik? Itt azonnal el is vesztetted az idő alapú becslésből az idő alapot. Időt írsz rá, de valójában egy absztrakt valamivel becsültél, nem idővel. Akkor meg miért hívod időnek?

    Egyszer megesett, hogy egy felsővezető ki akart rúgatni párunkat, mert a githubra ránézve azt találta, hogy mi a többiekhez képest alig commitolunk. Aztán szóltak neki, hogy nem kéne, mert mi vagyunk a leadek, meg a tesztelők. Ilyen vicces dolgokhoz vezet, ha kilóra akarod mérni a fejlesztőket. Márpedig ha időben fejezed ki a csapat velocityjét, akkor kilóra méred a teljesítményüket. És akkor jön a teljesítménykényszer, az alul, vagy túlvállalások stb.
    Mutasd a teljes hozzászólást!
  • Amikor beérkezik a megkersés, akkor mi alapján adod az árajánlatot és határidőt? Emberórákkal számolsz és az alapján költségekkel vagy hogyan?

    Nyilván azzal, mert neked is így jelentkezik a költséged. Megbecsülöd pl t-shirt sizinggal, hogy mi mekkora meló a korábbi tapasztalatok, és egy durva tervezés alapján. 

    Ha idővel, akkor mi szükség a storypointokra?

    Amit mondtunk. A ticketeket méretező, és majd a velocity mérésére, iteráció tervezésére szolgáló absztrakt mérőszám. Ebből fogod tudni, hogy mit vállalhat be a csapat a következő iterációban. És mivel a SP a fejlesztés során összegyűlt feladattal kapcsolatos és egyéb tapasztalatokból áll össze folyamatában, ezért előre nem is tudod rátenni az összes storyra, csak azokra, amik már a "csőben" vannak.

    Egyáltalán miként tudod védeni magadat jogilag, hogy ebbe a szerződésbe csak az fért bele, amit szállítottál?

    Waterfallnál, RUP-nál stb hogy véded magad? És miért kéne ennek a fejlesztési módszertan feladata legyen?

    Ahol dolgoztam nagyobb projekten, ott a nagyobb részfeladatokra is összességében is egy SP-t mondtunk és az alapján ment a pénzügyre, gondolom minden szint szépen felszorozta a saját biztonsági tényezőjével.

    Megpróbálom tömören megfogalmazni a gondolataimat: Teatyaúristen! :) Egyébként nekem is volt olyan élményem, ahol valaki hallott valamit a standupról, és amikor eszükbe jutott, akkor a fél délutánt egy nagy tárgyalóban töltöttük 15-en egy projector előtt...

    Igazából olyan, hogy nincs fix scope, az nagyon ritkán fordulhat elő. Ugyanis ha nem az készül el, amit elvárt az ügyfél, akkor nem lesz boldog.

    Soha nincs fix scope :) A triviális eseteket leszámítva az ügyfél nem fogja tudni megmondani, hogy pontosan mit szeretne. Nem ért hozzá, nem tudja lefordítani a gondolatait specifikációra. És még ha le is tudja, egy hangyányit is nagyobb lélegzetvételű feladatnál menet közben fognak olyan függöségek, és még át nem gondolt részletek kiderülni, amit menet közben ki kell fejteni. Ha segítesz neki az eredeti gondolataitól a tervezett költségek között a valós igényéig eljutni, akkor lesz a legboldogabb.

    Persze, nagy cégeknél. :)

    Teljesen mindegy mekkora cégeknél. Ha időben értelmezhető a feladat (outsourcing, támogatás, karbantartás stb), akkor idő alapon veszel programozót.

    És miért akarod eltüntetni az időt az issuek becsléséből ill. az egész módszertanból?

    Nincs eltüntetve belőle. De nem csak időn múlik. Ha át kell írnod valamit egy configban, az mennyi idő? És ha 5 másik rendszerrel együttműködve lehet csak végigtesztelni és végigvinni a környezeteken, akkor mennyi idő? Ha ez egy kritikus váltás, amit ki kell vigyél prodba sprint közepén? Ki tudod ezt fejezni idővel a becslés során?

    Annyi még, hogy az SP semennyire nem kötelező része az agilis módszereknek. És agile != Scrum. 

    Ami szerintem egyébként hülyeség az egésszel kapcsolatban, hogy rengetegen nagyon szigorúan (meg félre)értelmezik, és a munkájukat alakítják a módszertanhoz, nem pedig fordítva. Szerintem ez egy totál félreértelmezés, és pont az egész agile módszertanok fő alapvetésével megy szembe. Az egyik kedvencem a sprint buktás tor megülése egy kis valami el nem készülte miatt. Adjunk a csapatszellemnek :)
    Mutasd a teljes hozzászólást!
  • Én azért élesen szétválasztanám az agilis fejlesztést az agilis sales-től.
    Az agilis fejlesztés és módszertana nagyjából az, ami itt elhangzott, és valóban arról szól, hogy tervezhető legyen a fejlesztés ideje és ezáltal költsége is, továbbá a csapaton belüli elakadásokat a lehető legrövidebb időn belül megoldják, nyilván ezt is az idő- és költséghatékonyság jegyében. Amit én itt problémásnak érzek, az csupán annyi, hogy kicsi az esélye annak, hogy egy fejlesztői csapat igazán hosszú időre egyben maradjon. Kilépések, lebetegedések, vállalaton belüli átcsoportosítások satöbbi satöbbi mind mind csak arra jó, hogy a tegnapi sprint velocity egy sima tegnapi mérőszám maradjon, amire vagy lehet a jelenben alapozni, vagy sem. A másik problémás része ennek az agilitásnak a hodályméretből adódik. Ok, 8-10 ember esetén ez tök jól működhet, 20-30-nál már problémásabban, 100 ember meg tuti csak az idejét vesztegeti azzal, ha időnként összeröffen és elmeséli a többieknek a baját.
    Az agilis sales az meg más tál tészta, egyrészt tudnod kell nagyjából, hogy mik az ügyfél elvárásai, aztán meg vázolnod kell a lehetséges szcenáriókat, szépen beárazva, és persze az sem árt, ha a B verzió simán megépíthető az A-ból, a D meg a C-ből, nem kell lerombolni mindent, felszántani és sóval behinteni a helyét az előző fejlesztésnek, ha az ügyfél a kicsit szofisztikáltat kéri mégis.

    ügyfél és a fejlesztő között folyamatos legyen a kommunikáció

    Mi épp most fejeztük be egy közepesen komplex rendszer ráncfelvarrásos élesítését, de szerencsére egyetlen-egyszer sem kellett az ügyféllel kommunikálnunk, mert volt olyanunk, hogy "PM". Amúgy szerintem a folyamatos anyázás is kommunikációnak számít, az meg kétlem, hogy előre vinne

    Valahogy ez jut eszembe erről:

    Nekem inkább a modern autótervezés és -gyártás: ha van egy okosan és jól kitalált alapmodelled, abból kicsi városit, meg nagyobb családit, meg áruszállítót meg platóst is lehet gyártani, ilyen, olyan, amolyan és mégamolyanabb motorizációval. És az erősebb motorhoz komolyabb féket teszel be, az áruszállítóhoz pedig kicsit keményebb hátsó futóműt szerelsz, de semmiképp nem hisztizel, hogy "háde miért akarsz te evvel az autóval járólapot szállítani, hát ez nem arra lett kitalálva"
    Mutasd a teljes hozzászólást!
  • az SP egyrészt egy csapatszintű absztrakt mérőszám,

    Minden becslés figyelembe veszi a csapatot, annak összetételét. Ha kicserélsz egy embert, akkor nem feltétlen tartható a cél tök mindegy, hogy miben mérsz.
    Mutasd a teljes hozzászólást!
  • Egyesek könyveket is írnak a témáról.

    Igen, sejteni vélem, hogy miért. :)

    Modern agile contract

    Most sikerült elolvasnom. Ezt kb. az, amit lassan 10 éve én is alkalmaztam külföldi ügyfélnél try and hire-ként, de ő is nagy ügyfél volt. Nem azzal van problémám, akik nagy IT ügyfelek, ott van pénz és értik ezeket a dolgokat.
    Mutasd a teljes hozzászólást!
  • Az agilis fejlesztés sarokköve egyébként az, hogy az ügyfél és a fejlesztő között folyamatos legyen a kommunikáció. Ha ez megvalósul, akkor már nagy gond nincs.

    ezer százalékosan egyetértek! :)

    Ha a megrendelőnek új igénye merül fel, akkor vagy pótmunkában rendeli meg

    nem feltétlen új igény, hanem "nem úgy gondoltuk","ez nekünk így nem jó"... :)

    vagy egy hasonló komplexitású, még le nem fejlesztett funkciót lecserél vele.


    hát ha partner, akkor igen. :) Valahogy ez jut eszembe erről:

    https://pbs.twimg.com/media/DrV1AojWkAAH_x-.jpg
    Mutasd a teljes hozzászólást!
  • annyi kontextust hozzá szeretnék tenni a mondandómhoz, hogy a megfogalmazott kérdések, nem azokról a cégekről szólnak, ahol van pénz dögivel és akik tisztában vannak a scrum/agilis fejlesztés mikéntjével. Bár a kérdések szerintem ott is megállnak, csak ők eleve jobban értik, hogy miként működik ez a szakma.

    És mégis hogyan lehetne SP-re szerződni...másrészt pedig az SP-k menet közben kerülnek rá az issuekra bőven a szerződések

    Amikor beérkezik a megkersés, akkor mi alapján adod az árajánlatot és határidőt? Emberórákkal számolsz és az alapján költségekkel vagy hogyan? Ha idővel, akkor mi szükség a storypointokra? Egyáltalán miként tudod védeni magadat jogilag, hogy ebbe a szerződésbe csak az fért bele, amit szállítottál? (az hogy sprintenként mutatsz valamit a csapattal, az nem jelenti azt, hogy az idő 90%-ban ne mással foglalkoztatok volna, vagy eléggé kompetens a csapat a feladathoz. A tanuló pénzt meg miért a megrendelő fizeti?)
    Ahol dolgoztam nagyobb projekten, ott a nagyobb részfeladatokra is összességében is egy SP-t mondtunk és az alapján ment a pénzügyre, gondolom minden szint szépen felszorozta a saját biztonsági tényezőjével. Épp az a lényeg az egészben, hogy bevezetünk egy absztrakciót, a valós élet dolgai és a módszertan között, ahol ha nincs összefüggés a két rész között, akkor jogilag miként védekezel esetleges peres ügyekben?

    A programozás az esetek igen jelentős részében nem egy előre pontosan megbecsülhető dolog.

    Igazából ezt a programozók szeretik kiemelni, de tökre elképednek, amikor házfelújításkor, vagy autószereléskor jóval magasabb számlát kapnak, mint az előzetesen becsült. :) (ismerettségi körben tapasztalat) Egyébként ez tök jogos, és ez az élet sok területén így van, nem csak az IT-ban. A nagyobb baj, hogy az IT-ban szerintem nagy időpazarlás is folyik, amit az ügyfél fizet, de persze minden megideologizálható (pl. azért jobb, hogy "mindenki csinál mindent", mert könnyebben helyettesíthetőek lesznek az emberek, elosztott tudás lesz, scrum ceremónikák, stb-stb., de ez már egy külön thread lenne és nem is szeretnék mélyen belemenni).

    Mármint milyen szerződést? Rengeteg olyan project fut a világban

    Nem voltam elég egyértelmű, de a threadből kiderül, hogy elsősorban nem a multikra és nem az IT tudással rendelkező cégekre gondoltam. Nyilván tisztában vagyok azzal, hogy sok helyen használják, de tapasztalatom szerint jellemzően nagy cégek

    Vagy a scope fix, vagy a határidő és a költség.

    Igazából olyan, hogy nincs fix scope, az nagyon ritkán fordulhat elő. Ugyanis ha nem az készül el, amit elvárt az ügyfél, akkor nem lesz boldog. Na, és ekkor jön a következő probléma, hogy akkor kié a költség. Miként van/lesz ez a szerződésedben ami jogilag is védhető?

    időalapú elszámolás

    Persze, nagy cégeknél. :) És egyébként több helyen ott is próbálják ezt felszámolni, mivel rájöttek, hogy felelősség nélkül a fejlesztők nem igazán motiváltak, és az óradíjas munkát az élet semelyik területén sem szeretik épp annak hátránya miatt, hogy akkor "Józsi 10 nap alatt végez a 10nm burkolással". Erről is írtam, hogy ahol van pénz, ott minden belefér.

    Nem attól agile, vagy nem agile valami, hogy milyen elszámolással köttök szerződést.

    Nem is mondtam ilyet. De ha belsőleg használsz csak egy ilyen absztrakciós szintet, akkor mi szükséged van rá, ha még jogilag sem véd? És miért akarod eltüntetni az időt az issuek becsléséből ill. az egész módszertanból? (Tudom a választ, nem kell leírni)
    Mutasd a teljes hozzászólást!
  • Egyébként a story point az agilis manifesztóban nem jelenik meg sehol. Nálam most fut olyan agilis project, aminél nem csináltunk story pontozást, mert a fejlesztőknek egyszerűen nem volt rá igénye. (Az elején csináltuk, aztán egy sprinten belül el lett engedve a sprintezéssel együtt és a SCRUM-szerűségről kanban-szerűségre álltunk át. A projectet két héttel a határidő előtt zárni fogják.)
    Mutasd a teljes hozzászólást!
  • Ez elég furcsa, ugyanis nem egy scrum coach-tól hallottam, hogy így kellene szerződni. :) 

    Ez bizonyítja, hogy sok a hozzánemértő SCRUM coach.
    Mutasd a teljes hozzászólást!
  • Szerintem a story pointok több kárt okoznak, mint hasznot. Az a csapat belügye, mert nincs egy objektív skála, ami alapján több csapat is legalább hasonló becslést tudna adni. Amíg a csapaton belül egy sprint megszervezésére használják, addig jók, ha továbbszivárog a management felé (gyorsuláshoz kötött bónuszkifizetés az állatorvosi ló) akkor jön a pokol.

    Én kétféle szerződést tudok elképzelni:
    A rövid távú projectekre (< 1 év) jól definiált mérföldkövekkel és átbeszélt, értelmezett feladattal tud az alvállalkozó költséget becsülni. Ha a megrendelőnek új igénye merül fel, akkor vagy pótmunkában rendeli meg, vagy egy hasonló komplexitású, még le nem fejlesztett funkciót lecserél vele.

    Ennél hosszabb projectekre szerintem már havi díjas szerződést kell írni. (Vagy felbontani kisebb projectekre.)

    Az agilis fejlesztés sarokköve egyébként az, hogy az ügyfél és a fejlesztő között folyamatos legyen a kommunikáció. Ha ez megvalósul, akkor már nagy gond nincs.
    Mutasd a teljes hozzászólást!
  • Ez elég furcsa, ugyanis nem egy scrum coach-tól hallottam, hogy így kellene szerződni. :)

    És mégis hogyan lehetne SP-re szerződni, amikor az SP egyrészt egy csapatszintű absztrakt mérőszám, ami folyamatában egy stabil velocity mellett számolható át időre és pénzre (ha egyáltalán), másrészt pedig az SP-k menet közben kerülnek rá az issuekra bőven a szerződések aláírása után.

    Igen, de ehhez kell egy olyan szerződést aláíratnod, amit egy megbízó sem szívesen ír alá. :)

    Mindenki ilyen szerződést ír alá, max nincs vele tisztában. A programozás az esetek igen jelentős részében nem egy előre pontosan megbecsülhető dolog. Vagy a scope fix, vagy a határidő és a költség. Ez ellen szoktak úgy védekezni, hogy felszorozzák a becslést egy tapasztalati úton kialakult számmal, és az alapján adják az ajánlatot. Hogy ez valóban jobb-e a megrendelőnek, mintha ténylegesen azt fizetné, ami elkészült, menet közben a büdzséjéhez igazítva a követelményeket, az egy jó kérdés. És nem csak programozásban.

    Egyedül azt vitatom, hogy ez mennyire életszerű a való világban. Mekkora eséllyel kapsz így szerződést?

    Mármint milyen szerződést? Rengeteg olyan project fut a világban, ami agile és az ügyfél is be van vonva, és tisztában van a leírtakkal. Ettől még lehet fixáras akár a project, és lehet időalapú elszámolás stb. Nem attól agile, vagy nem agile valami, hogy milyen elszámolással köttök szerződést.
    Mutasd a teljes hozzászólást!
  • válaszolok még, csak kicsit később. :)

    EmberÓra / nap / hét / hó elszámolású contract

    Igen, és épp erre jöttek rá a megbízók, hogy ez nem feltétlen annyira jó nekik, mert elkényelmesedik a csapat. :) Ezért megprübálnak több felelősséget belevinni a projektbe. :) De erről lentebb te is írsz. Egyébként a felsoroltak keveredhetnek is, mivel a belsős fejlesztés is kiegészülhet Time in materiallal.
    Mutasd a teljes hozzászólást!
  • A story pontoknak meg semmi közük semmilyen külső vállaláshoz.

    Ez elég furcsa, ugyanis nem egy scrum coach-tól hallottam, hogy így kellene szerződni. :) Másrészről, ha nincs köze, akkor miként kezeled a szerződést? Sőt, mi értelme, ha amúgy is határidő van és scope meg ár?

    Azt kell felismerni, hogy ha menet közben kiderül valamiről, hogy sokkal komplexebb (időigényesebb, így költségesebb) megoldást kíván, mint elsőre gondolták, akkor két lehetőség közül kell választani. Az első, hogy valaki kifizeti a csekket....

    Igen, de ehhez kell egy olyan szerződést aláíratnod, amit egy megbízó sem szívesen ír alá. :) Miszerint majd csinálunk valamit, valamikorra valahogy, de igyekszünk a legszükségesebbeket leszállítani. :) Ez meg nem épp az a jól eladható dolog. Egyébként én értem amit mondasz, meg egyet is értek vele. Tisztában vagyok ezekkel a problémákkal. Egyedül azt vitatom, hogy ez mennyire életszerű a való világban. Mekkora eséllyel kapsz így szerződést?

    Nem utolsósorban ha a megrendelő is része a fejlesztési folyamatnak, akkor annak a menetéhez, várható eredményéhez tudja igazítani az egyéb folyamatait

    igen és eljutottunk oda, amit írtam is a legeljén:

    A szakik (értsd: certekkel rendlekező scrum coach-ok) meg erre annyit tudnak mondani a legjobb esetben is, hogy "nem megfelelően használják a scrumot". Jaja, persze, aztán mondanak egy olyat, hogy át kellene alakítani az egész cég hozzáállását, menedzsmentjét, stb.... Aha, hát persze... :)

    Viszont két gátja van alapvetően.

    Egyetértek
    Mutasd a teljes hozzászólást!
  • Az a tapasztalatom, hogy azon ügyfeleknél, akik az agilis fejlesztéssel nincsenek tisztában, nem nagyon lehet szerződni. Választanak olyan céget, akik nem ennyire "körülményesek".

    [...]

    A fentiek miatt az az érzésem, hogy ez az egész agilis/scrum fejlesztés "enterprise dolog". KKV szinten alkalmazni nehéznek látom a szerződések miatt.

    Azt kell felismerni, hogy ha menet közben kiderül valamiről, hogy sokkal komplexebb (időigényesebb, így költségesebb) megoldást kíván, mint elsőre gondolták, akkor két lehetőség közül kell választani. Az első, hogy valaki kifizeti a csekket. Vagy a megrendelő, jellemzően az ilyen problémák előre nem láthatósága miatti akár vad buffer-túlárazásokkal. Ha nincs ilyen felmerülő probléma, ezt akkor is kifizeti a megrendelő. De kifizetheti a vállalkozó is, ha nincs már a bufferben pénz rá, vagy nem is volt (mert a KKV-nál nincs tér a bufferképzésre). A másik lehetőség, hogy ha menet közben megjelennek ilyen problémák, akkor a követelmények szükséges átalakításával (pl nem létszükséglet fejlesztések elodázásával) kezelhetővé válik a helyzet a fejlesztésnek még azon pontján, amikor még nem dobtak ki pénzt egy rossz irányra. És nem utolsósorban ha a megrendelő integrálva van a fejlesztési folyamatba, akkor meg tudja érteni a problémát, és bele tud szólni a követelmények hajlításába, hogy az neki is megfelelő legyen. Így a megrendelő is megkapja a pénzéért, amit szeretett volna - még ha módosításokkal is -, és a vállalkozó is a pénzét. 

    Nem utolsósorban ha a megrendelő is része a fejlesztési folyamatnak, akkor annak a menetéhez, várható eredményéhez tudja igazítani az egyéb folyamatait (tesztelés, marketing, oktatás stb), és ezzel akár párhuzamosan tud dolgozni, ami jelentősen lecsökkentheti az elkészült termék használatbavételi idejét. Az agilis fejlesztés központi eleme a rendszeres és rövid iterációjú feedback loopok. Hogy eköré hogy épülnek ki a fejlesztési módszertan részletei (hogy scrum vagy más, hogy mennyire scrum ha scrum stb), az viszonylag részletkérdés.

    A KKV-kra elvileg ugyanúgy alkalmazható az agilis módszertan. Viszont két gátja van alapvetően. Az egyik, hogy a KKV-k nem tudnak/akarnak senkit delegálni a fejlesztésekbe, a KKV szektorban gyakran jelentkezik a vezetői rugalmatlanság ("én fizetek, te meg megoldod, nem érdekel hogyan"). A másik a KKV vállalkozói oldal tapasztalatlansága a témában, így el se tudják mondani a megrendelőnek, hogy az agilis fejlesztés adott esetben neki is érdeke lenne, és hogy miért lenne érdeke. Ezek kéz a kézben járnak, így sokkal nehezebben tör be az agilis módszertan a KKV szektorba, mint a corporate szektorba, ahol vannak ennek szakértői, van pénz és szándék tanfolyamokra is akár. 

    A story pontoknak meg semmi közük semmilyen külső vállaláshoz. Az SP nem egy abszolút értékű valami, az kizárólag a csapat belügye, és a csapat velocityjének mérésére, a vállalások méretezésére használható. Annyira a csapat belügye, hogy ha ugyanazon projecten, ugyanannál a cégnél 2 csapat is dolgozik, azok SP-jai nem feltétlenül összehasonlíthatóak. Nem az lesz a "jobb" csapat, amelyik több SP-t szállít, hanem amelyiknek stabil a velocity-je, így jól tervezhetőek az erőforrásai.
    Mutasd a teljes hozzászólást!
  • Hát pont ez a probléma az egésszel szerintem. Ha szerződéssel nem véded magad, akkor mit szállítasz mikorra és mennyiért?

    Vannak agilis szerződések, "agile contracts". Egyesek könyveket is írnak a témáról.

    Négy vonal látszik kibontakozni:
    - Belsős fejlesztések
    - EmberÓra / nap / hét / hó elszámolású contract
    - Iteratív fejlesztés: Sprint, mérföldkő stb. "vásárlásával" (néha több) contract
    - Modern agile contract

    Bontsuk le ezeket.

    Belsős fejlesztés:

    - Lényegében munkaszerződés van amúgy is, a bank ha fenntart IT szoftverfejlesztést mondjuk házon belül, úgy agilizálhat ahogy akar.

    EmberÓra/nap/hét/hó elszámolás:

    - Lényegében semmi akadálya, hogy full agile-t csináljatok.
    - Míg vízesésnél te parázol, hogy megszivat az ügyfél, itt nettó ő parázik hasonlóan, így kell egy bátor ügyfél hozzá, vagy eleve kialakult jó kapcsolat, menő referenciák, valami.
    - De van sok ilyen - pl. amikor csapatokat adnak kölcsönbe: ugye láttál ilyet? Elég jellemző.

    Iteratív fejlesztés:

    - Ilyenkor sem sztori pontokat fizetsz, hanem iteratív a fejlesztés, jogilag olyan, mint a "Bohm féle spirális" csak a gyakorlatban házon belül akár agile-oztok (vagy mást csináltok).
    - Lényegében sok kisebb méretű vízesés van papíron a szerződés szerint. Ezek vagy egy szerződésben "mérföldkövek" (kifizetés is több tételben), vagy akár több külön szerződés is.
    - Sok ilyen van. Például ha van egy nagy rendszer, amit az ügyfél akar és annak van 6 modulja, akkor megtehető, hogy egyetlen nagy integráns monolitikus rendszer helyett 6 kommunikáló modult csináltok egyesével úgy, hogy külön külön is használni tudják ami már elkészül. Ez valamennyivel több erőforrás, de egyébként nagyon tiszta és szép architektúra.
    - Jellemzően nem értelmezhető, hogy sprinteket adtok el, mert az ügyfél azt a granularitást nem tudja kezelni. Szóval minimum hónapnyi mérföldkövet fogtok eladni, vagy lehet hogy 3 hónapos dolgokat. Ebből házon belül tudtok csinálni két/egy hetes sprinteket ha akartok és sokkal kevesebb effort lesz az már.
    - Ez balanszírozza azért azt, hogy az ügyféllel mennyire kell jóba lenni, vagy jó benyomást kelteni, vagy bátornak lennie: Ugyebár az idő alapú elszámolásnál azon parázhat, hogy húzod az időt, itt meg azon, hogy későbbi mérföldköveknél "titokban árat emelsz", vagyis ugyanannyit csináltok már drágábban és ugye bele se nagyon lát, hogy tényleg többe kerül, vagy sem. Illetve azt se látja, hogy mennyire könnyű másnak átadni a másik modulok fejlesztését mondjuk - mert ugye eleve kötődni fog hozzátok, a szerzett tudás miatt, de ha ki akarod használni őket, akkor meg is nehezítheted, hogy más cég foglalkozzon a dologgal. Azért ezeket még így is könyebb megítélni ha van közös üzleti kapcsolat a cégek között, mint az óra és egyéb idő alapú elszámolásnál...

    Modern agile contract:

    - Ezt a zosztrákok egyes cégeinél látni egyébként, hogy nyitottak rá. 
    - A lényeg, hogy fix áras szerződéssel pályázol feléjük, mint egy nem-agile cég
    - Ez azonban "becsült fix ár". Nem szeretik kimondani, de lényegében tehát változhat. Ezt persze nehogy "hangoztasd" erősen, ha ilyet akarsz kötni olyan féllel aki nem ismeri a témát!
    - Ellenben a szerződés két körös: tartalmaz egy kisebb adagnyi (mondjuk egy éves projektnél 3 hónapos, egy hónapos projektnél egy hetes, stb) fejlesztést, külön elszámolással. Az első és második kör között nagyságrendi különbség van méretben.
    - Ezt projekt jellegtől függően nevezhetjük "ellenőrzési fázisnak", vagy "prototípus fázisnak". Az utóbbi főleg a K+F intenzívebb területeken, ahol pl. technikailag is sok a nyitott kérdés, az előbbi inkább akkor ahol az üzleti együttműködést tesztelitek.
    - Az első fázis tényleg az eredeti fix áron, annak eredeti scope-jával történik. Minimálisan valami MVP-szerű el kell készüljön, mert az ügyfélnek is látnia kell az együttműködés sikerességét, módját, hatékonyságát, stb.
    - Fontos: az első fázis után új - most már végleges ajánlatot adtok egymásnak a teljes projektről. Itt úgy tud bekúszni az agilitás, hogy te mint kivitelező is jobban tudod mennyire kell betonba vésned a scope-ot és mennyire lehet "beszélni" az ügyféllel, együttműködni normálisan, illetve ő is jobb képpel rendelkezik arról, hogy mi várható tőletek el és azt is nagyjából látja ugye így, hogy mely csapat, milyen emberekkel dolgozik a projekten (ez max bővül, nagy-nagy ritkán, ha epic kicsi a projekt akkor csökken, de a core ugyanaz).
    - Ezen a ponton az is lehetséges mindkét fél számára, hogy Istenhozzád-ot mondjon és másnak adja a melót, vagy elsétáljon, hogy "fú, ez egy halálos fejlesztés lenne ezzel az ügyféllel".

    Külön előny, hogy a fenti konstrukcióban eleve úgy próbál mindenki "tenni", mintha jó, normális cég "lenne". A vicc az, hogy közben könnyen jut az ember arra a felismerésre, hogy kényelmes és jó az együttműködés ha nem ölitek egymást és emiatt az egész "úgy marad", baráti alapon.

    Sok menedzser egyébként erre az utóbbira ráérez olyan formában, hogy ha új ügyfél kerül látótérbe és az új kivitelezőt keres, akkor "néznek valami egyszerűbb és kisebb melót és először azt megcsinálják közösen" mielőtt valami "nagy fába vágnák a fejszét". Ez ilyen formában végülis elég bevett dolog, de az amit vázoltam - és erre vannak szerződés template-ek sok cégnél, stb. - az viszont lehetővé teszi a dolgot akkor is, ha nincs "kisebb és egyszerűbb meló", vagy ugye csak kevésbé kritikus, nem annyira lényeges téren lenne.

    Persze a fentiek mellett az is egy mód, hogy elfogadod a diszkrepanciát a szerződés és az agile kivitelezés között - tehát egyszerűen rájössz, hogy soha nem tudsz úgysem totális specifikációt írni, mindig van tér "értelmezésre" és ezt nem negatívnak éled meg, hanem hagyod, hogy az ügyfél a sprint demókon elmondja mit képzelt másként. Szintén ha elég jó az üzleti bizalom, akkor nem probléma ez - főleg ha több termékét te fejleszted mondjuk.

    Más: A fix áras, fix idejű, fix scope-os fejlesztés egyébként nem csak az ügyfélnek jó, hanem az üzletnek is. Például ha kis kft vagy, akkor nem mindegy, hogy van egy aláírt, fix szerződés 20 millás tételről max másfél év időben, amivel számolni tudsz pl. kiket vegyél fel, vagy gördülő szerződés modulokról, amikből nem biztos, hogy te fejleszted le az összeset (vagy esetleg rosszul megy a megrendelőnek egy időszak és senkivel nem fejleszti le a maradék három modult, hanem "megoldják excelben" stb.). Szóval én nem megrendelő vs. kivitelező ellentétet látok, hanem üzlet vs. technikai szintű ellentétet abban kinek melyik jobb.
    Mutasd a teljes hozzászólást!
  • Annyiban vitatkoznék, hogy a story pontokat nem próbálnám meg letolni a megrendelő torkán, mert nagyon szubjektív dolog.

    Hát pont ez a probléma az egésszel szerintem. Ha szerződéssel nem véded magad, akkor mit szállítasz mikorra és mennyiért? :) De a storypoint meg szinte eladhatatlan.

    Egy n+1. Webshop/fórummotor/akármi esetén a sales is egész jól megsaccolja az időt és a költséget, a projectek nagyrésze meg ilyen.

    Ha így van, akkor mi szükség a storypointra? :) (ha a szerződésnek sem a része.) Itt érzek egy hiányosságot az egésszel kapcsolatban. Mi van, ha a sales nem tud jól saccolni? Valójában hogyan lehet jól szerződni? A team saccol egy komplexitást sp alapon és egy sp értéke X Euro, összeszorozzák és tesznek rá egy kettes "biztonsági tényezőt"? :) Mit fog tartalmazni a szerződés? Ha így számolják, akkor az ár ugye fixálva lett, a határidő megint általában közel fix, szóval eleve 2 tényező a 3-ból közel fixé vált. A szerződésben meg nehéz olyat elfogadtatni, hogy a  kritikus funkciók fejlesztése azért benne lesz. :) Miként lehet ezt jól kezelni? Az a tapasztalatom, hogy azon ügyfeleknél, akik az agilis fejlesztéssel nincsenek tisztában, nem nagyon lehet szerződni. Választanak olyan céget, akik nem ennyire "körülményesek".

    A maradék (ahol K+F is van) meg mérföldkőről mérföldkőre kell haladjon, az anyagiakat is agilisen kezelve.

    Persze, de nem csak K+F projekteken, hanem hosszabb projekteken is. Ahol van zsé lóvéra, ott azért sok minden működik Tapasztaltam olyat, amikor pénzügyhöz ment a manager és előtte felvázolta a következő scope-ot, de a komplexítás miatt a team képtelen egy ilyenre becslést adni. Vagy hát hasból... aztán hasból konvertálja a manager is ezt költséggé és úgy megy a pénzügyre, mert a költségeket viszont tervezni kell. Aztán mindenki felül sacccol, és még akkor is pénzért kell a végén kuncsorogni valakinek. :) De ez olyan környezetben sokszor nem gond, ahol van pénz és hozzászoktak az IT-s projektek bizonytalanságához.

    A fentiek miatt az az érzésem, hogy ez az egész agilis/scrum fejlesztés "enterprise dolog". KKV szinten alkalmazni nehéznek látom a szerződések miatt.
    Mutasd a teljes hozzászólást!
  • Sajnos igazad van. Valahogy el kell nekik magyarázni, ha egy házat építtetsz, az sem úgy néz ki, hogy leírod email-ben az igényeid és egy év múlva beköltözöl, hanem konzultálsz állandóan a tervezővel és a kivitelezővel, részt veszel a burkolatok/festékek kiválasztásában, stb... Nagyon sokat voltam az alvállalkozói oldalon és megrendelőnek jobb lenni. :D

    Annyiban vitatkoznék, hogy a story pontokat nem próbálnám meg letolni a megrendelő torkán, mert nagyon szubjektív dolog.

    Egy n+1. Webshop/fórummotor/akármi esetén a sales is egész jól megsaccolja az időt és a költséget, a projectek nagyrésze meg ilyen.
    A maradék (ahol K+F is van) meg mérföldkőről mérföldkőre kell haladjon, az anyagiakat is agilisen kezelve. (Úgy értem, a managementnek értenie kell, hogy bármikor kijöhet egy olyan eredmény, hogy egyszerűen bukjuk az eddigieket, tovább menni pedig nem éri meg.)
    Mutasd a teljes hozzászólást!
  • Alapvetően egytértek azzal amit írtál, de nem minden ügyfélnek van fogalma a fejlesztési módszertanorkól. El lehet magyarázni nekik, hogy mi miként működne. Melyik módszertannak mi az előnye-hátránya, de jellemzően egy árat, határidőt és elvégzett feladatot akarnak látni a végén. Amit leírtál, azt szinte csak azon cégeknél látam "működni", akik nem csak hogy hallottak az IT-ról, de ezen módszertanokat is ismerik és elfogadják a hátrányait. Dolgoztam sok fajta méretű projektben, de ezt az agilis dolgot szinte képtelenség eladni még startupoknak is. Eleve meg sem értik, hogy a pénzükért X db storypointot vesznek. Ami egy érdekes absztrakció, mert a való világban időt mérünk és elvégzendő feladatok vannak valamilyen vállalási díjért.

    Nagy projektekben, multiknál láttam csak valójában "működni", de leírtam korábban, hogy ott mit tapasztaltam. Gyakorlatilag ott is megmarad a probléma, hogy van egy konverzió az idő, költség, feladatok és storypointok között. Egy olyan konverzió, aminek az az ígérete, hogy próbáljuk a legtöbbet kihozni a dologból, de nem tartozik hozzá konkrét váltószám. (Vagyis, ha a sprintből és az elvégzett sp-ből kihozzuk az időt. Tapasztalatom szerint egyébként sok fejlesztő ezzel is számol, még ha scrum pokerben sp-t is saccol.)

    A megbízó oldaláról eleve ott lehet már nagy félreértés, ha alulbecsülik, hogy nekik mekkora erőforrást kell beletenni a projekt sikeressége érdekében.

    Az "üzletileg kritikus funkciók" sajnos eléggé képlékeny. :) Nyilván a megrendelőnek az az érdeke, hogy minél több minden benne legyen az árban.

    Egyébként mint korábban írtam elfogadom, hogy jobbat még nem sikerült kitalálni.
    Mutasd a teljes hozzászólást!
  • Ahol alkalmazzák, ott nem szokott túlóra lenni, tehát valószínűleg nem "megcsinálod vagy itt éjszakázol" elvre találták ki.

    Nem a tulora elkerulesere talaltak ki.

    aztán kiderül, az élesen kell létrehozni máshonnan, majd azt lehúzni, mert a kód közvetlenül az id-kra épül. Hát persze, nyilván amikor majd megkérdezik "mi akadályozott ebben?" Majd azt fogom mondani "az egész úgy ahogy van...".

    Igen, azt fogod mondani. Csak nem olyan formaban, hogy akkorra rakat "valami" az a valami, hanem kulturaltan megfogalmazod a problemat, jelenleg hogy mukodik es milyen valtoztatast kell vegrehajtani. --> erre adtok becslest, es itt mar lehet vita targya, hogy mennyi ido. 

    Nem tudom, hogy az aggodalmaid abbol szarmaznak-e, hogy a management egyfele despota modon ra van telepedve a csapatra es kvazi akarmi van, mindenert valaki mas a felelos, kiveve ok.
    Amugy lehet, hogy mar igy is 5-10 ember munkajat vegzed, csak mivel meg nem volt semmilyen keretbe foglalva, amit ontottek rad, azt megcsinaltad es meg nem vetted eszre mennyit dolgozol.
    Arra is remek alkalom lesz, hogy vitaba szallj ha nem ertesz egyet, plane ha valaki le akarja tolni a torkodon, hogy a 8 napos task az neki 2. Dehat nem is az a manager vagy solution architect vagy po vagy akarki csinalja majd, akinek nem tetszik, hanem te, kezdjuk itt....
    Mutasd a teljes hozzászólást!
  • A daily nem napi jelentés. A resztvevők nagyrészének annyit kellene mondania, hogy "Az XY tickettel dolgozom, egyelőre tudom tartani a határidőt és nem akadalyoz semmi."

    Ha pedig nsm tudod tartani de tudod, miért:
    "Az XY tickettel dolgozok, sajnos rosszul mértük fel a munkaigényét, de nincs vele kérdésem."
    Mutasd a teljes hozzászólást!
  • Igazából tök mindegy, mivel a projektek túlnyomó része továbbra is határidővel van eladva az ügyfél felé

    Ha az ügyfél waterfall -modell szerint (merev határidő, neminkrementális teljesítés) várja a projectet, a csapat pedig agilis próbál lenni, akkor ott csúnyán el fognak beszélni egymás mellett. (Pl mert az agilis fejlesztés egyik sarokköve az ügyfél és a fejlesztők közötti állandó kommunikáció.)

    Mi sok szoftverfejlesztést csináltatunk meg külső cégekkel. Ilyenkor azt csináljuk, hogy mi adjuk a product owner-t, aki szorosan együtt dolgozik a fejlesztőkkel a projectzárásig.

    Aztán hogy a product owner és a csapat SCRUM-ban, kanban-ban vagy sör mellett dolgoznak együtt, az már az ő dolguk, hiszen "Individuals and interactions over processes and tools".

    Határidő nyilván van, mert a világ azért annyira nem agilis, de a product owner feladata, hogy ha a csapat ki is csúszik a határidőből, az üzletileg kritikus funkciók fejlesztése priorizálva legyenek.

    Az agilis fejlesztési metódusok nem tudnak (definíció szerint) úgy működni, ha az ügyfél és a fejlesztők nem partnerek. (A vízesésmodell pedig nem működik nagyobb projecteknél, szóval az ügyfelek kénytelenek partnernek lenni.)
    Mutasd a teljes hozzászólást!
  • Miből gondolod, hogy minden standupon látványos haladást kell bejelenteni? Ha az volt a feladatod, hogy kijavíts egy elgépelt szöveget valahol, akkor furán fog hangzani hogy két napja ezen dolgozol. De ha valami rejtélyes komplex hibát kell kijavítani, akkor simán előfordulhat hogy napokig tart. Normális esetben sizing alatt ez tisztázódik, a komplex probléma magas pontszámot kap és senki nem fog rajta problémázni hogy sokáig tart.

    A sizing eredménye sem kőbe vésett dolog, néha előfordul hogy valami kisebb vagy nagyobb mint aminek előre tűnt, normális helyen ezért nem fognak felelősségre vonni. Az viszont szerintem jogos elvárás, hogy el tudd magyarázni miért nagyobb effort mint először kinézett, olyan részletességgel hogy a többi fejlesztő megértse, még ha a management nem is érti esetleg. Az ilyet később esetleg fel lehet használni, ha hasonló feladat jön elő. Nálunk simán van olyan sizing alatt, hogy "ez simának tűnik de múltkor sokat szívtunk egy hasonló feladattal, úgyhogy most nagyobb méretet kap a biztonság kedvéért".
    Mutasd a teljes hozzászólást!
  • Nem hagyom itt. Ahol alkalmazzák, ott nem szokott túlóra lenni, tehát valószínűleg nem "megcsinálod vagy itt éjszakázol" elvre találták ki.
    Ugyanakkor mégis lehetnek olyan dolgok, amik miatt lehetetlen tartani. Mondjuk, egy wp oldalnál úgy csináltunk menüt adminra, hogy kódba felvittük. Ok, itt egy másik wp oldal, nosza, ma megcsinálom ezt a menüt ma, mèg talán korábban is végzek mint ma.
    Aha, aztán jön a fejvakarás, hogy ezt egy plugin vezérli, mire kinyomozod, aztán kiderül hogy 10 éve a kutya nem fejleszti, aztán kiderül, az élesen kell létrehozni máshonnan, majd azt lehúzni, mert a kód közvetlenül az id-kra épül. Hát persze, nyilván amikor majd megkérdezik "mi akadályozott ebben?" Majd azt fogom mondani "az egész úgy ahogy van...".

    Továbbá én túlságosan aprólékos dolgoknak tartom a fejlesztést. "Frissítettük a php verziót" - több nap teszteléssel, javításokkal. "Kijavítottam a szálkezelési hibát" már a megtalálása önmagában 3 nap is lehet. Mi olyat lehet mondani napiszinten, ami látványos haladás? Ok, 2 hetente még igen, de naponta...
    Mutasd a teljes hozzászólást!
  • Off: ha nem is feltétlenül élőszóban, de fontos, hogy valahogy kommunikáljunk, különben jó eséllyel egymástól függetlenül futunk rá ugyanarra a problémára. pl.:


    Jocó: Három napja küzdök a keystore-ral, és kezdem úgy érezni, hogy vagy az OpenSSL 1 és 3 *.pkcs12 fájljai nem kompatibilisek, vagy a Java8 és Java11 *.jks fájljai
    Fecó: Mindkettő igaz, én és is három napot küzdöttem vele a múlt héten.
    Jocó: És nem írtad fel valahová, hogy másoknak segítsen?
    Fecó: De, először egy kis papírra írtam, amit azóta elvesztettem, azután meg egy *.doc fájlba, amit a szerver egyik legeldugottabb könyvtárába tettem.
    Jocó: Kíváncsi lennék, hogy csinálják ezt a "nagyok".
    Fecó: Valahogy így: https://www.rfc-editor.org/rfc-index.txt vagyis van egy tartalomjegyzék, amiben rákereshetsz mondjuk arra, hogy "avian carrier" és megtalálod az "IP továbbitása postagalambbal" témára vontakozó doksikat.
    Mutasd a teljes hozzászólást!
  • "Ha 3-as vagy 4-es értékelésű a ticket, akkor megbecsüljük a feladat komplexitását fibonacci pointing pókerrel. Időben mi nem adunk becslést, és nem is tartunk nyilván."

    Igazából tök mindegy, mivel a projektek túlnyomó része továbbra is határidővel van eladva az ügyfél felé. Persze, vannak olyan nagy és/vagy belső projektek, ahol megy ez a "pontozgatás", de a való életben az ügyfél határidőre szeretné kapni az elképzelését ismert áron. Sőt, nagy cégeknél is ott borulékony az egész, hogy adott belső projektre is egy büdzsét kell igényelni előzetesen a menedzsereknek. Aztán persze a fejlesztés folyamán már lehet pontokkkal játszani, de az csak a csapatnak szól, mert a büdzsé és a határidő már ismert, csak nem feltétlen a fejlesztők előtt. Láttam én már managert pénzért menni és csak vakarta a fejét, hogy mennyit kérjen pluszba!, mert ezt ugye a csapat nem képes megmondani, nem is akarja a felelősséget ezért válllalni. 1M Chf biztos elég lesz.... vagy nem... :) A pénzügy meg nem tudja értelmezni a sp-kat. :) Az üzletnek meg szüksége van arra, amit szeretne. Ok, hogy a feladat, idő, költség háromszögbe szeretnénk bevinni rugalmasságot, de ez csak látszólagos. Külső ügyfélnek meg kis-, közepes projektnél ezt eladni szinte reménytelen.

    A pontokból, a sprint hosszából, velocityből bárki kiszámolhatja, hogy kb. mennyi időnek felel meg egy sp.

    Stressznek sosem éltem meg, ellenben elvesztegetett időnek igen. Még ha időlimit is van megadva minden egyes elem átbeszélésekor is. Kérdés, hogy 8-10 ember x 1 nap (nálunk 1 nap elment ezzel kb. 3 hetente 1 csapatnál, és közben volt sok kis csapat.) időkiesésnek van-e hozadéka a projekttel kapcsolatban. Igazából nekem azért volt jó, mert 1 napi "játékra" is kiszámláztam a pénzem, és szívesen játszok, ha fizetnek érte. :) De 8ember*8*óra*140-180Chf/óra azért már kézzel fogható összeg 1 napnyi játékra a cégnél is, ráadásul 1 ember majdnem 2 heti munkája.

    Aztán akkor ugye ott van a SAFe is, ahol viszont már több száz fejlesztőnek van egyidejűleg tervezés.Na, az meg aztán tényleg horribilis összeg. Igaz, az nincs olyan sűrűn.

    Nekem valahogy erről az egészről az az érzésem, hogy elméletben mind szép és jó, de a való világ meg megint más. Ráadásul szinte csak olyan projektet láttam, ahol akadtak a módszerrel ilyen-olyan problémák. A szakik (értsd: certekkel rendlekező scrum coach-ok) meg erre annyit tudnak mondani a legjobb esetben is, hogy "nem megfelelően használják a scrumot". Jaja, persze, aztán mondanak egy olyat, hogy át kellene alakítani az egész cég hozzáállását, menedzsmentjét, stb.... Aha, hát persze... :) (Egyébként nálunk a coachok azt mondták, hogy mindent jól csinálunk, minimális javaslatuk volt csak)

    Ettől persze még mindig lehet ez a legjobb módszertan bizonyos esetekben (, mert pl. nem találtak fel még jobbat), de nekem leginkább a felelősség elfedéséről is szól.
    Mutasd a teljes hozzászólást!
  • Nem tudom milyen helyeken dolgoztal eddig, de en mar legalabb 9 eve olyan helyeken, ahol ezeket a modszereket "eroltetik".
    Nem mindenhol van ertelme. Pl voltam olyan helyen, ami nagyon nagy ceg, de azon belul egy picike csapatban, 3-an: 1 architect/dev team lead keverek es 2 dev, az egyik dev voltam en. Felvettunk taskokat, de az architect mondta, hogy nem fogunk reggeli standupokat, meg retrokat tartani, hogy magunkat szorakoztassuk, ugyis beszelunk rola eleget egymas kozt.
    De ha eleg nagy projekten vagy, akkor ott mar nagyon nehez kovetni, hogy mi van. Nem kell elhinned, de par eve voltam egy helyen, ahol kb 150 fore rugott azoknak a szama, akik csak a rendszerek kozti integracion dolgoztak, BA-k, tesztelok, dev-ek, PO-k, delivery manager-ek, miegymas, mindenki contractor. A tobbi reszlegrol ne is beszeljunk. Ilyen projekteken nem lehet csak ugy odaadni valamit, aztan majd jelentkeznek a megbizottak par honap mulva valami, talan egesz massal. Ezek mar nem pistike bt meretu projektek, egy ilyen utan latnad, hogy nemcsak annyi ertelme van, hogy te le legyel ellenorizve minden nap.

    Egyebkent en sem szeretem  :)
    Mutasd a teljes hozzászólást!
  • Hali!

    Kíváncsi vagyok, hogy ez a téma is a többi témádhoz lesz hasonló vagy nem: megnyitod, aztán hagyod a fenébe, nem szólsz többet.

    Mutasd a teljes hozzászólást!
  • Ez a tankönyvi példa mintaszerű követése. Jó tudni, hogy van olyan cég, ahol ez így működik, de sajnos többségében, a hétköznapi munka során ettől elég rendesen el szoktak térni máshol.
    Voltam már olyan meeting-en is, ahol inkább a hibáztatás, és a csúszás okának a kikérdezésére mentek rá keményebb hangvételben, mintsem konstruktív párbeszédben a megoldásra koncentrált volna mindenki. De ez nem az agilitás rendszerének a hibája, hanem azoknak a személyeknek hozzáállása, akik részt vesznek benne. Ettől függetlenül a legtöbb helyen a scrum és egyéb munkaszervezések általában a project-et segítik, nem pedig a stresszt fokozzák.
    Mutasd a teljes hozzászólást!
abcd