Még egy gondolat eszembe jutott. Az, hogy közösen, nagy egyetértésben módosítja a megrendelő és a szállító a tervet, semmit nem árul el a minőségről. Csak azt, hogy a két fél igényességi szintje találkozott. A komplexitás és az inkompatibilitás ugyanúgy része maradt a rendszernek.
Ha minőségi termékek születnének, akkor nem lenne nagy hagyománya it szakmai berkekben a kódminőségen való gúnyolódásnak, összekacsintásnak. Meg az a rengeteg mém. Nem hangzanának el időről időre fejlesztők szájából, hogy "ki írta ezt a szar kódot?!" Ahogy olyan se hangozna el utána, hogy: "Ja, én, 4 hónapja." Nem lennének ismertek, az olyan fogalmak, mint techdebt, hanem megbújnának egy kis szubkultúra alig ismert szleng nyelvében. De ugyan ilyen példákat lehetne hozni a teljes stack-ből, az SM-től a PO-ig. "Ezeknek így is jó lesz." Ismerős mondat? :-)
Egyébként nem rossz dolog az agilitás, de igyekszem helyén kezelni. Nincs köze a minőséghez. Egy olyan idealizált világban lehet hozzá talán köze, ahol a résztvevők bármilyen áldozatot hajlandóak bevállalni a jóság elérése érdekében. Élén a megrendelővel. Viszont ez esetben felesleges az agilitás és az elégséges produktumhoz való ragaszkodás. Ha az ember nem az elégségesre hajt, hanem a jóra, a jelesre, a kitűnőre, akkor az már nem agilitás, az valami más. Más, ami a valóságban nagyon nagyon ritka jelenség. Túl drága jelenség.
Sosem az előre meghatározott kritériumokkal van a baj. A baj az emberi igénytelenséggel van. Amit az agilitás csupán még inkább a felszínre hoz, mert mindkét felet abban teszi érdekeltté, hogy csak egy elégséges termék szülessen meg. Hogyan is mondják? Minimális munkával maximális értéket.
Nos ez egy garázs projektnél rendben is van. Ami többet akar nyújtani, mint egy garázs projekt, ott felmerülnek olyan döntések, hogy például lefejlesztem-e újra a kereket, vagy használom azt a kereket, amit egyszer valaki már lefejlesztett. Könnyű kérdés, nem igaz? Természetesen használom a kész kereket. Akkor most ugorjunk a kerékről a szoftverek világába. Szerinted a mai szoftverek egy keréknél komplexebbek? Mennyire? Nem tudok egzakt választ adni rá, de közelítőleg: NAGYON.
Ha otthon vagy mondjuk a frontend világban, meg tudod mondani hány js framework létezik a világon? Hány js lib? Ugyanarra a funkcióra hány darab? Elgondolkodtál már azon, ha ilyen megszámlálhatatlanul sok létezik, vajon miért? Ha létezne egy darab jó, akkor mindenki azt használná, nemde? Az ember képben lehet az összessel? Nem. Az ember profi lehet akármelyikben is? Akkor, ha mással nem foglalkozik. Van olyan élethelyzet, hogy nem kell mással foglalkoznia? Egy idealizált világban igen.
Ez rögtön magával hozza a következő döntési helyzetet: összedrótoztam egymással több tucat számomra többé-kevésbé ismert és ismeretlen komplex rendszert, közülük sokkal most találkozom először. Tisztában vagyok vele, hogy egyik rendszer sem jó (különben nem létezne belőle számtalan másik). Azzal is tisztában vagyok, hogy ezek a rendszerek még véletlenül sem pontosan kompatibilisek egymással, pont annyira, hogy minden jónak tűnjön, értsd: potenciálisan élesíthető.
Van arra idő, hogy a szállító alaposan körbejárja a területet? Arra sincs, hogy az alkalmazott komplex rendszereket teljesen átlássa, arra meg főleg nincs, hogy az összes többi alternatívát is. Utóbbi ugye azért lenne illendő, mert így lehet jól választani közülük. Van arra pénz, hogy a megbízó ezt finanszírozza? Többnyire arra sincs, hogy a teljes igénylista lefejlesztésre kerüljön. Húzza a száját a megrendelő, de amikor meghallja, hogy ez még mennyi munka lenne, inkább nem kéri.
A következmény a potenciálisan élesíthető termékben potenciális, feltérképezetlen bugok és optimalizálatlanságok tömkelege, melyekből az következik, hogy egy teljesen véletlenszerű hiba miatt elúszott az aznapi munkád. Vagy éppen rád dőlt a ház, ha megelégedtél az elégségessel, amikor a mesterembert felkérted.
Engem pusztán egy dolog zavar: hogy elvesztem az aznapi munkám egy gombnyomás miatt. Azért vesztem el, mert bizonyos emberek megelégednek az elégségessel. Pedig lehetne ezt másként is. Csak az emberek nem szeretik a minőséget, mert túl drága. Az agilitás meg olcsó. Nem véletlenül.
@nagyeszteranna: Ezek szerint téged még sosem zavart, amikor az általad használni kívánt alkalmazás egy csigal lassúságával indult el? Annak ellenére, hogy egyébként nem szokott. Sose zavart, hogy általában a kritikus pillanatokban adja meg magát? Jó esetben csak a pörgő homokórát kell nézned súlyos percekig, órákig. Rosszabb esetben az addig elvégzett munkádat is viszi magával. Sose zavart, hogy az a gomb nem ott van, ahol lennie kéne, vagy nem azt csinálja, amit szeretnél? UX vagy bug miatt, nem számít.
Nem feltétlenül csak hibákra gondolok, hanem optimalizálatlanságokra, olyan funkciók kispórolására, ami a megrendelő számára nem képvisel (kézzelfogható) értéket, a beszállító pedig nem csinálja meg, mert ha minden ilyen apróságot megcsinálna, akkor évekig tartana mindennel végezni. Arra meg senkinek sincs ugye ideje. Tapasztalatom szerint a pénz az úr, a határidő a szent, nem láttam még megbízót, aki boldogan fizetett volna még 1-2-5 sprintet csak azért, hogy az alkalmazás továbbra is ugyanazt csinálja mint eddig, de a beszállító becsületszavát adja, hogy márpedig jobb lett. Általában azt látom, hogy minden fillér számít, és amit meg lehet csinálni egy sprint alatt gyorsan, kár lenne több sprintet pazarolni a jobb megoldásra. Örülök, ha neked mások a tapasztalataid.
Ezernyi más dologra gondolok még, amelyek valahogy sosem passzoltak bele nálam az agilitás tündérmeséjébe. Elmondva nagyon szép, a gyakorlat viszont mocskos dolgokat hoz magával.
A házépítés analógiájával: Te vagy az építőbrigád. A megrendelő elmesél mindent, hogy milyen házat szeretne, kis, egyszintes családi ház. Kiásod az alapot, lebetonozod, húzod a falakat, mikor a megbízó eléd áll és közli, hogy nagyon tetszik neki, amit eddig csináltál, de szeretne még egy szintet. Mire közlöd vele, hogy ehhez nem elég erős az alap, mindent vissza kell bontani, feltörni az alapot, vasalással újraönteni, tartóoszlopok, miegymás. A horribilis időráfordítás megy a kukába. De szerencsére mindig van választás. Mondhatod neki azt is, hogy ha egy kicsit megtámogatod innen meg onnan, akkor talán nem kell mindent előről kezdeni, és hidd el, a szoftveriparban sokkal könnyebb megtámogatni a ház falait, csábító ajánlat. És sokkal több hátraarcra lenne valójában szükség, mint azt ahányszor elkövetik... ha egyáltalán elkövetik. Mert vagy a megrendelő nem akar hallani a dologról, vagy a proaktív szállító fogja azt hazudni, hogy van kompromisszumos megoldás. Végülis nem neki kell abban a házban élnie, ami bármelyik pillanatban rádőlhet a lakóira. És a jó hírneve is megmarad, hogy milyen gyorsan és milyen "szép" munkát végzett. Az meg, hogy olmadozik a vakolat? Nos, ez a természet rendje. Senki meg nem mondja kívülről, hogy mi az omladozó vakolat valódi oka. Igaz, hogy a megrendelő 48 forradalmi ötlettel állt elő menet közben, garázs, terasz, medence, de szerencsére a ház minden egyes alkalommal potenciálisan élesíthető volt, és viszonylag kevés idő ráfordítással el is készült. Mindenki elégedett.
Kedves @rmgm!
Szerintem a két fogalom között sokkal kisebb a távolság, viszont érdekelne, hogy szerinted mit jelentenek.
Potenciálisan élesíthető szoftvert szállítunk párhetente, azaz olyan nem fordul elő, hogy hibáktól nyüzsgő valami készül hónapok múlva. Pont azért dolgozunk agilisan, hogy minimalizáljuk ezt a kockázatot.
Úgy gondolom, a minőség ott kezdődik, hogy az előre meghatározott - akár menet közben, közösen módosított - technikai, üzleti, funkcionális kritériumoknak megfelel a termék ergo felhasználható arra a célra, amiért készül.
Kedves Anna! Az, hogy valami minőségi vagy működőképes, nos, mint Makó Jeruzsálemtől.
Hogyan adnád be a türelmetlen megrendelőnek, hogy a teljeskörűen működő termékből hátra van még kb. 20%, ami főleg teszt és hiba javítás a megfelelő minőség eléréséhez?
És azt, hogy ez várhatóan az idő / pénz 80%-át teszi még ki?
@rmgm: Király, hogy ezt észrevetted! Abszolút igazad van, nem túl jól van kifejezve. Aggodalomra semmi ok, voltak a retrón fejlesztők, utána néhányan a DoD review-n is részt vettek. Három csapat dolgozott a terméken, így nem minden csapattag vett részt, velük pedig ismertetni kellett. És persze volt beleszólásuk a tartalmába.
"@YX elővszei a DoD-t, és tisztázzuk, minek kellene benne szerepelnie, ezután SM/PO ismerteti a csapattal"
Ismerteti?? A csapat nem vesz részt a retrón és nem ő határozza meg a DoD-t? Minden retróról kihagyjátok a csapatot, vagy csak az EGYÜTTműködést érintőről? Lehet, hogy máshol van a probléma, mint ahol keresitek. :)
@rmgm:
Köszi a kommentet!
Az agilitás nem az, hogy azt csináljuk, amit az ügyfél akar. Ennek előfeltétele, hogy az ügyfél edukált legyen agilis termékfejlesztésből, ami ritkán fordul elő. Az agilitás az igények változásának gyors reagálásáról szól. Ha semmi nem változott, csak az ügyfél fejében nincs rendben, hogy miről szól a termék, és hasraütésre változik a PB, akkor az nem agilis, mert ebből semmilyen érték nem származik, és a végkimenetel egy funkcióhalmaz lesz.
Az teljesen rendben van, hogy rájövünk, hogy rossz az út, vagy új ötletek születnek, és változtatunk a terven, de ebben a példában nem ezt a scenáriót próbáltam leírni.
"Fókusz: Az ügyfél sprintenként változtatja a product backlogban lévő elemek sorrendjét, és folyamatosan bukik a release terv."
Szerintem teljesen valid, hogy az ügyfél sprintenként változtat a product backlogon. Nyilván nem kellemes érzés, amikor akkorát változtat, hogy a világ kifordul magából, de ez az agilitás. Azt csinálni, amit az ügyél akar, és ha az előző sprintben kiderül, hogy vakvágányon haladtunk, akkor a következőben meg lehet próbálni egy másik utat. Akár egy teljesen másik utat. Az meg a PO dolga, hogy az ügyfél ne legyen saját maga ellensége a backlog abuzálással. Főleg ha a változtatások köszönőviszonyban sincsenek a roadmap-pel.
scrumster
Utolsó kommentek:
rmgm 2020.07.08. 23:05:39
Ha minőségi termékek születnének, akkor nem lenne nagy hagyománya it szakmai berkekben a kódminőségen való gúnyolódásnak, összekacsintásnak. Meg az a rengeteg mém. Nem hangzanának el időről időre fejlesztők szájából, hogy "ki írta ezt a szar kódot?!" Ahogy olyan se hangozna el utána, hogy: "Ja, én, 4 hónapja." Nem lennének ismertek, az olyan fogalmak, mint techdebt, hanem megbújnának egy kis szubkultúra alig ismert szleng nyelvében. De ugyan ilyen példákat lehetne hozni a teljes stack-ből, az SM-től a PO-ig. "Ezeknek így is jó lesz." Ismerős mondat? :-)
Egyébként nem rossz dolog az agilitás, de igyekszem helyén kezelni. Nincs köze a minőséghez. Egy olyan idealizált világban lehet hozzá talán köze, ahol a résztvevők bármilyen áldozatot hajlandóak bevállalni a jóság elérése érdekében. Élén a megrendelővel. Viszont ez esetben felesleges az agilitás és az elégséges produktumhoz való ragaszkodás. Ha az ember nem az elégségesre hajt, hanem a jóra, a jelesre, a kitűnőre, akkor az már nem agilitás, az valami más. Más, ami a valóságban nagyon nagyon ritka jelenség. Túl drága jelenség.
Bejegyzés: Agilisak vagyunk (jelentsen ez bármit is)
rmgm 2020.07.08. 22:38:32
Sosem az előre meghatározott kritériumokkal van a baj. A baj az emberi igénytelenséggel van. Amit az agilitás csupán még inkább a felszínre hoz, mert mindkét felet abban teszi érdekeltté, hogy csak egy elégséges termék szülessen meg. Hogyan is mondják? Minimális munkával maximális értéket.
Nos ez egy garázs projektnél rendben is van. Ami többet akar nyújtani, mint egy garázs projekt, ott felmerülnek olyan döntések, hogy például lefejlesztem-e újra a kereket, vagy használom azt a kereket, amit egyszer valaki már lefejlesztett. Könnyű kérdés, nem igaz? Természetesen használom a kész kereket. Akkor most ugorjunk a kerékről a szoftverek világába. Szerinted a mai szoftverek egy keréknél komplexebbek? Mennyire? Nem tudok egzakt választ adni rá, de közelítőleg: NAGYON.
Ha otthon vagy mondjuk a frontend világban, meg tudod mondani hány js framework létezik a világon? Hány js lib? Ugyanarra a funkcióra hány darab? Elgondolkodtál már azon, ha ilyen megszámlálhatatlanul sok létezik, vajon miért? Ha létezne egy darab jó, akkor mindenki azt használná, nemde? Az ember képben lehet az összessel? Nem. Az ember profi lehet akármelyikben is? Akkor, ha mással nem foglalkozik. Van olyan élethelyzet, hogy nem kell mással foglalkoznia? Egy idealizált világban igen.
Ez rögtön magával hozza a következő döntési helyzetet: összedrótoztam egymással több tucat számomra többé-kevésbé ismert és ismeretlen komplex rendszert, közülük sokkal most találkozom először. Tisztában vagyok vele, hogy egyik rendszer sem jó (különben nem létezne belőle számtalan másik). Azzal is tisztában vagyok, hogy ezek a rendszerek még véletlenül sem pontosan kompatibilisek egymással, pont annyira, hogy minden jónak tűnjön, értsd: potenciálisan élesíthető.
Van arra idő, hogy a szállító alaposan körbejárja a területet? Arra sincs, hogy az alkalmazott komplex rendszereket teljesen átlássa, arra meg főleg nincs, hogy az összes többi alternatívát is. Utóbbi ugye azért lenne illendő, mert így lehet jól választani közülük. Van arra pénz, hogy a megbízó ezt finanszírozza? Többnyire arra sincs, hogy a teljes igénylista lefejlesztésre kerüljön. Húzza a száját a megrendelő, de amikor meghallja, hogy ez még mennyi munka lenne, inkább nem kéri.
A következmény a potenciálisan élesíthető termékben potenciális, feltérképezetlen bugok és optimalizálatlanságok tömkelege, melyekből az következik, hogy egy teljesen véletlenszerű hiba miatt elúszott az aznapi munkád. Vagy éppen rád dőlt a ház, ha megelégedtél az elégségessel, amikor a mesterembert felkérted.
Engem pusztán egy dolog zavar: hogy elvesztem az aznapi munkám egy gombnyomás miatt. Azért vesztem el, mert bizonyos emberek megelégednek az elégségessel. Pedig lehetne ezt másként is. Csak az emberek nem szeretik a minőséget, mert túl drága. Az agilitás meg olcsó. Nem véletlenül.
Bejegyzés: Agilisak vagyunk (jelentsen ez bármit is)
rmgm 2020.07.08. 22:36:56
Nem feltétlenül csak hibákra gondolok, hanem optimalizálatlanságokra, olyan funkciók kispórolására, ami a megrendelő számára nem képvisel (kézzelfogható) értéket, a beszállító pedig nem csinálja meg, mert ha minden ilyen apróságot megcsinálna, akkor évekig tartana mindennel végezni. Arra meg senkinek sincs ugye ideje. Tapasztalatom szerint a pénz az úr, a határidő a szent, nem láttam még megbízót, aki boldogan fizetett volna még 1-2-5 sprintet csak azért, hogy az alkalmazás továbbra is ugyanazt csinálja mint eddig, de a beszállító becsületszavát adja, hogy márpedig jobb lett. Általában azt látom, hogy minden fillér számít, és amit meg lehet csinálni egy sprint alatt gyorsan, kár lenne több sprintet pazarolni a jobb megoldásra. Örülök, ha neked mások a tapasztalataid.
Ezernyi más dologra gondolok még, amelyek valahogy sosem passzoltak bele nálam az agilitás tündérmeséjébe. Elmondva nagyon szép, a gyakorlat viszont mocskos dolgokat hoz magával.
A házépítés analógiájával: Te vagy az építőbrigád. A megrendelő elmesél mindent, hogy milyen házat szeretne, kis, egyszintes családi ház. Kiásod az alapot, lebetonozod, húzod a falakat, mikor a megbízó eléd áll és közli, hogy nagyon tetszik neki, amit eddig csináltál, de szeretne még egy szintet. Mire közlöd vele, hogy ehhez nem elég erős az alap, mindent vissza kell bontani, feltörni az alapot, vasalással újraönteni, tartóoszlopok, miegymás. A horribilis időráfordítás megy a kukába. De szerencsére mindig van választás. Mondhatod neki azt is, hogy ha egy kicsit megtámogatod innen meg onnan, akkor talán nem kell mindent előről kezdeni, és hidd el, a szoftveriparban sokkal könnyebb megtámogatni a ház falait, csábító ajánlat. És sokkal több hátraarcra lenne valójában szükség, mint azt ahányszor elkövetik... ha egyáltalán elkövetik. Mert vagy a megrendelő nem akar hallani a dologról, vagy a proaktív szállító fogja azt hazudni, hogy van kompromisszumos megoldás. Végülis nem neki kell abban a házban élnie, ami bármelyik pillanatban rádőlhet a lakóira. És a jó hírneve is megmarad, hogy milyen gyorsan és milyen "szép" munkát végzett. Az meg, hogy olmadozik a vakolat? Nos, ez a természet rendje. Senki meg nem mondja kívülről, hogy mi az omladozó vakolat valódi oka. Igaz, hogy a megrendelő 48 forradalmi ötlettel állt elő menet közben, garázs, terasz, medence, de szerencsére a ház minden egyes alkalommal potenciálisan élesíthető volt, és viszonylag kevés idő ráfordítással el is készült. Mindenki elégedett.
Bejegyzés: Agilisak vagyunk (jelentsen ez bármit is)
nagyeszteranna · https://www.linkedin.com/in/annaeszternagy/ 2020.07.06. 14:37:40
Szerintem a két fogalom között sokkal kisebb a távolság, viszont érdekelne, hogy szerinted mit jelentenek.
Potenciálisan élesíthető szoftvert szállítunk párhetente, azaz olyan nem fordul elő, hogy hibáktól nyüzsgő valami készül hónapok múlva. Pont azért dolgozunk agilisan, hogy minimalizáljuk ezt a kockázatot.
Úgy gondolom, a minőség ott kezdődik, hogy az előre meghatározott - akár menet közben, közösen módosított - technikai, üzleti, funkcionális kritériumoknak megfelel a termék ergo felhasználható arra a célra, amiért készül.
Bejegyzés: Agilisak vagyunk (jelentsen ez bármit is)
rmgm 2020.07.02. 22:24:09
Hogyan adnád be a türelmetlen megrendelőnek, hogy a teljeskörűen működő termékből hátra van még kb. 20%, ami főleg teszt és hiba javítás a megfelelő minőség eléréséhez?
És azt, hogy ez várhatóan az idő / pénz 80%-át teszi még ki?
Nem értem, miért keverik ide mindig a minőséget.
Bejegyzés: Agilisak vagyunk (jelentsen ez bármit is)
nagyeszteranna · https://www.linkedin.com/in/annaeszternagy/ 2019.05.25. 00:07:18
Bejegyzés: Az ügyféllel való együttműködés nem opcionális
rmgm 2019.05.24. 23:07:35
Ismerteti?? A csapat nem vesz részt a retrón és nem ő határozza meg a DoD-t? Minden retróról kihagyjátok a csapatot, vagy csak az EGYÜTTműködést érintőről? Lehet, hogy máshol van a probléma, mint ahol keresitek. :)
Bejegyzés: Az ügyféllel való együttműködés nem opcionális
nagyeszteranna · https://www.linkedin.com/in/annaeszternagy/ 2018.04.30. 12:39:16
Köszi a kommentet!
Az agilitás nem az, hogy azt csináljuk, amit az ügyfél akar. Ennek előfeltétele, hogy az ügyfél edukált legyen agilis termékfejlesztésből, ami ritkán fordul elő. Az agilitás az igények változásának gyors reagálásáról szól. Ha semmi nem változott, csak az ügyfél fejében nincs rendben, hogy miről szól a termék, és hasraütésre változik a PB, akkor az nem agilis, mert ebből semmilyen érték nem származik, és a végkimenetel egy funkcióhalmaz lesz.
Az teljesen rendben van, hogy rájövünk, hogy rossz az út, vagy új ötletek születnek, és változtatunk a terven, de ebben a példában nem ezt a scenáriót próbáltam leírni.
Bejegyzés: Scrum Master vs. Puppet Master
rmgm 2018.04.30. 09:00:44
Szerintem teljesen valid, hogy az ügyfél sprintenként változtat a product backlogon. Nyilván nem kellemes érzés, amikor akkorát változtat, hogy a világ kifordul magából, de ez az agilitás. Azt csinálni, amit az ügyél akar, és ha az előző sprintben kiderül, hogy vakvágányon haladtunk, akkor a következőben meg lehet próbálni egy másik utat. Akár egy teljesen másik utat. Az meg a PO dolga, hogy az ügyfél ne legyen saját maga ellensége a backlog abuzálással. Főleg ha a változtatások köszönőviszonyban sincsenek a roadmap-pel.
Bejegyzés: Scrum Master vs. Puppet Master