scrumster

Agilisak vagyunk (jelentsen ez bármit is)

2020. július 02. - nagyeszteranna

Buzzwordé vált a kifejezés, mindenki használja, és mindenki ért valamit alatta. Valamit, ami sajnos gyakran messze áll a valóságtól. Nézzük meg, mi rejtőzik a kis, agyonhasznált, néha fenyegető, másszor ultramenő szavacska mögött!

ke_pernyo_foto_2020-07-02_19_03_17.png

Ez egy nem egy

Nem ment fel a tervezés alól. Sőt, tervezés nélkül nem tudsz agilis lenni, mivel ez az egész az újratervezésről is szól. Viszont fontos, hogy csak annyit tervezz, amennyi szükséges és elégséges. Nem kell minden részletet előre tudni. Sőt, egy csomó mindenre út közben, a visszajelzések által fogsz rájönni. Az agilis tervezési szinteknek bőséges szakirodalma van. Többnyire a következő szinteket különböztetik meg: vízió (3-5 évre), roadmap (fél-egy évre)/OKR, release (3-6 hónapra), iteráció (1-4 hétre) és napi.

Nem okozza a minőség csökkenését. Az agilis alapelvek között szerepel, hogy a minőség és a szakmai kiválóság fontos, és a termékednek működnie kell.

Nem egyenlő a scrummal. A scrum egy keretrendszer, amit ha jól implementálsz, segít, hogy a szemléleted is formálódjon.

Nem eszköz és nem módszertan. Nincsenek szabályok, csak értékek és alapelvek. Nem ír elő, hanem gondolkodásmódot ad.

Nem könnyen elsajátítható. Nem elég, ha elvégzel egy pár napos tréninget. Folyamatos tanulásra van szükség, hiszen a viselkedésedben és a gondolkodásmódodban, a problémákkal való megküzdési stratégiáidban kell változást elérned. Kellő nyitottság, alázat és rengeteg izzadtság kell a mesteri szinthez.

Nem egy szoftverszállítási mód. Olyan nincs, hogy waterfallban tervezünk, de agilisban fejlesztünk (hallottam már ilyet:):.

Nem csodafegyver. Nem oldja meg a problémáidat, inkább csak a felszínre hozza őket. 

Nem csak a fejlesztőket érinti. A felsővezetésnek, a középvezetésnek, meg mindenféle szintű vezetésnek el kell sajátítania, és oroszlánrészt kell vállalnia a kultúra kialakításában.

Nem zárja ki azt, hogy dokumentáljunk. De ahogy a tervezésnél, úgy itt is csak annyit, amennyi szükséges.

Nem egy termék vagy szolgáltatás. Bár sok ember sok pénzt csinál belőle, de nem megvehető, hanem megtanulható.

Nem a fejlesztőcsapat működésének módja. A sikeres implementálásához az egész szervezetnek értenie kell, hogy mi ez, és hogyan működik.

Ez egy

Bizonyítottan jó útja a szoftverfejlesztésnek.

Szemlélet, gondolkodásmód, négy érték és 12 alapelv összessége.

Segít elfogadni, hogy még az is jobb, ha későn jövünk rá, hogy zsákutcába futottunk, minthogy soha.

Teret ad a kísérletezésnek. Mivel az ügyfél rendszeresen jelen van, ezért hamar és gyakran kaphatsz visszajelzéseket a munkádról vagy a hipotéziseidről.

Működő szoftvert eredményez. Pár hetente szállítódik működő, potenciálisan élesíthető termék.

Felhatalmazza az embereket, így a döntéshozás a lehető legalacsonyabb szinten történik. Nincsenek megközelíthetetlen, elefántcsonttoronyban üldögélő górék.

A projekten való jó és folyamatos együttműködésre törekvést is jelenti az érintettekkel. Elégedett megrendelőt és felhasználót eredményez.

Kis létszámú, önszerveződő csapatokra épül. Senki nem menedzseli a munkájukat, maguk osztják el a feladatokat, nem silósodnak, és nincs közöttük hierarchia.

Értékvezéreltséget eredményez. Mindig a fontos dolgokkal kell foglalkoznod, olyanokkal, amik a legmagasabb értéket képviselik, vagy a legnagyobb kockázattal bírnak. Amik enyhítést adnak a felhasználó legnagyobb fájdalmára. Amiről tudjuk, hogy értelmes és segít, hogy a világ egy kicsivel jobb hely legyen.

Nagy elszántságot igényel. Meg kell változnod hozzá neked is, és a szervezeti kultúrának is. Sok-sok idő, amíg rutinos lesz benne egy szervezet.

Támogatja az újratervezést. Ennek előfeltétele, hogy legyenek tervek, és tudd, mit akarsz elérni vagy megmérni.

Könnyű azt gondolni, hogy tudod, mi ez. Könnyű megérteni, de még könnyebb elfelejteni a rendszerét és az összefüggéseit.

Tehát az agilitás ennyi csupán:

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more."

 

Ha tetszett, iratkozz fel a blogomra, vagy kapcsolódjunk linkedinen

 

A bejegyzés trackback címe:

https://scrumster.blog.hu/api/trackback/id/tr9714880606

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

rmgm 2020.07.02. 22:24:09

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?

Nem értem, miért keverik ide mindig a minőséget.

nagyeszteranna · https://www.linkedin.com/in/annaeszternagy/ 2020.07.06. 14:37:40

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.

rmgm 2020.07.08. 22:36:56

@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.

rmgm 2020.07.08. 22:38:32

@nagyeszteranna:

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.

rmgm 2020.07.08. 23:05:39

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.
süti beállítások módosítása