Sziasztok, az én nevem Papp Krisztián és ez itt a minicube podcast harmadik epizódja!
Láttatok már jól működő scrum csapatokat? Igen? Az tök jó, mert akkor kevesekhez tartoztok, akik még jobban tudjátok majd értékelni, ha egy olyat làttok, ami rossz.
De mitől is lehet rossz? Mik is azok a scrum csapatok?
Hàt akik scrumban dolgoznak, igaz?
Na és mi az a scrum? Igazából nem csak a scrumról szeretnék beszélni, hanem mindenről, amit az agile fedőnéven adnak el. Ez az egész a kis csapatok hatékony menedzseléséről szol, leginkább.
Régen kb minden szoftveres projektet úgy közelitettek meg mint paks kettőt és emiatt kb addig is tartottak. Hosszasan tervezték, engedélyeztették, embereket verbuvàltak, aztán ásót ragadtak az emberek és uccu neki. A végén még hosszasan tesztelték, hogy biztos minden klappol, majd átadták.
Egy ilyen beruhàzásnál lehet ez jó megoldás, de képzeljük el mi lenne ha kiderül, hogy az egyik reaktort nagyobbra kéne méretezni. Mindezt akkor amikor màr állnak a falak. Hát garantálom, hogy nem örülnénk neki. De minek is kellene változtatni?
Emelje fel a kezét, aki nem vezet és nem làtott még olyan szoftveres projektet, amiben menet közben vàltoztatni kellett!
De miért kell ilyet? Nos azért, mert szoftvert írunk, aminek ez a legfontosabb jellemzője. Gyorsan tudunk módositani benne és emiatt az ügyfelek gyorsan tudnak reagàlni a piac megváltozott igényeire, konkurenciára és még sorolhatnám. Erre jött az ötlet hogy akkor kis iterációkat csináljunk, amikben gyorsan tudunk reagálni a változásokra, ne dokumentáljunk feleslegsen, hanem inkább működő szoftvert adjunk át, ami működés tesztekkel igazolt, kommunikáljunk egy csapatként, de nem akarom ideidézni a komplett agile manifestot, akit érdekel járjon utána.
Na szóval az alapötlet tök jó, de a megvalósítás… akkor rant on:
Miféle szörnyszülötteket hozott mindez létre? Nos miután ez elterjedt valamikor kétezer elején, mindenki megpróbált felülni a vonatra, ahogy korábban mondtam, a cégek gyorsan akarnak reagálni. Néha talán túl gyorsan is. Emiatt lett igény mindenféle agile coachokra, scrum master gyorstalpalókra ésatöbbi. Gondolhatjuk, hogy mennyire is jól megy ez az egész. Na de mivel van nekem már megint bajom?
Kezdjük az egyik kedvencemmel, a tesztek v. épp a tesztelés hiánya. Tudom, biztos unjátok már, de komolyan, nem viccből emeltem ki, hogy tesztekkel bizonyitjuk, hogy az adott szoftver műküdik. Persze sokan úgy gondolják hogy megoldás az is, ha felveszünk x embert indiából bagóért és majd nyomkodják kézzel.
Ez jól is megy egy darabig, de szép lassan le fognak maradni a fejlesztők mellett. Miért is van ez? Mert a kód és a funkcionalitás csak bővül, emiatt a tesztelendő esetek száma is.
Az elején az lesz, hogy kell egy nap a tesztelőknek a sprint végén. Igen, már visszatértünk a scrumhoz. Utána kell kettő nap. Egy pillanatra nem nézünk oda és a sprintek fele elmegy tesztelésre.
Persze ez csak akkor van, ha minden sprintben akarunk egyszer releaselni, amivel el is jutottunk a mini waterfallhoz. Hangsúlyoznám, hogy a scrum az nem mini waterfall! Persze simán lehet az is, hogy a csapat úgy dönt, hogy nem is olyan fontos sprintenként releaselni, elég ritkábban is. Itt mentünk át végképp waterfallba.
Mi fog itt történni? A tesztelők csinálnak amit csinálnak, jó esetben automatizálnak, aztán amikor eljön a release ideje, lehúzzák a rolót és nekiállnak végignyomkodni mindent, mert az automatizált tesztek nincsenek még kész. Ha kész is vannak, nem bizunk bennük és igy tovább. Mi lesz akkor, ha találunk egy problémát éles környezetben? Ki kéne javitani mert ügyfelektől esünk el. Mindenki eldobja a vakolókanalat és elkezd rajta dolgozni. Na de várunk vele a sprint végéig? Persze, senki nem meri bevállalni, hiszen lehet mégnagyobb bajt okoz, amiről nem tudunk. Ezzel pedig el is mondtam a másik eshetőséget.
Nem mondom, hogy ez ugyanolyan szörnyű, mintha waterfallban nyomnánk, de a lényeg, hogy lehetne ez sokkal sokkal jobb. Ha lennének acceptance tesztjeink, amikkel legalább a happy path le van fedve, a qa pedig hozzáirja azt, amivel szerintük csecsre lehet futtatni az appot és ezek nem csak assert true-k, akkor ki merünk rakni egy új verziót szinte bármikor. Persze ehhez fontos, hogy ismerjük azokat a bizonyos kritériumokat. Na de akkor mit fog igy a tesztelőgárda csinálni? Előre dolgozik. Már akik maradnak, mert igy a munka mennyisége nem fog lineárisan nőni, tehát kisebb létszám is elég lesz. Tehát előre automatizálhatnak és nem ők lesznek betolva a release előtti utolsó pár napba egy rakás feladattal, ami lehet bele se fér, aztán ki tudja mit kell kihagyni belőle.
De túltoltam ezt a témát, menjünk tovább.
Ja igen, a sprint nincs bebetonozva. Ahogy az ügyféloldal, úgy mi is mondhatjuk, hogy állj. Ha valami nem lesz meg, akkor nem lesz meg. Nem szabad amiatt túlórázni, hogy minden meglegyen. A sprint egyik alternativ célja, hogy adatot szolgáltasson a sebességünkről. Ha túlórázunk, hogy valami beleférjen, semmi más nem lesz, mint hamis adatokat szolgáltatunk a product oldalnak, ami miatt később még több feladat fér be a sprintbe a velocity mentén.
Persze nem mondom, hogy tilos túlórázni, mert mint mindenhol, igy itt is vannak kivételek. De ez legyen látható. Ha viszont látjuk hogy nem fog beleférni, szóljunk minél hamarabb. Ne féljünk attól, hogy emiatt veszélyeztetjük az állásunkat. Ha mégis igy van, az a cég, vagy menedzser igazából nem érett még meg, hogy agile legyen. Ha szólunk, az olyan mintha egy veszélyre hivnánk fel a figyelmet. Ha időben teszzük, meg lehet tenni az óvintézkedéseket. Ha nem, akkor az olyan, mint mikor a titanicon felkiáltottak, hogy “jéghegy”, jó hogy szóltak, de már késő. Ha időben szólunk, akkor fel tudják terjeszteni az infót, az ütemtervet tudják megfelelően módositani és lehet semmi nem lesz belőle.
Persze minden product ownernek minden tegnapra kéne, de vajon tényleg ez a helyzet?
Próbáljuk ki legközelebb, hogy hogy reagálnak. Jól mutatja, hogy a vezetés mennyire is állt már át a régi módszerekről.
Áh, a retrospektiv. Ezt is szeretem, igencsak elhanyagolt téma. A scrum csapatok az elején elég gyengén teljesitenek, mert nincsenek adatok, rosszak a becslések, nincs összerázódva a csapat. Aztán szép lassan fejlődésnek indul az egész. De nem csak a becslések és az összeszokás tud fejlődni, hanem a folyamat ami eköré épül. Az ilyenek fejlesztésére szolgál a retrospektiv, amit szeretnek elhanyagolni, vagy leröviditeni. Ebből lesz az, hogy kb felirnak az emberek elemeket, de senkit sem fog érdekelni. Ugyanazokat a problémákat hozzák fel minden héten, de semmi változást nem hoznak. Ha szeretjük feleslegesen tölteni az időnket, akkor ez egy tök jó módszer rá.
Persze a tervezést se hagyjuk ki. Ebben aztán nagyon jók szoktak lenni. Nyilván, ha a sprintek nincsenek bebetonozva, akkor ez a hiba ez propagálódik felfelé is. Emiatt a hosszútávú terveket is valamennyi rugalmassággal kell kezelni. Na itt szokott az lenni, hogyha pl black fridayre kell valami, akkor nem lehet rugalmasan kezelni a dolgot, aznapra meg kell lenni. Teljesen érthető is. Akkor mi erre a megoldás? A kedvencem az volt, mikor egy hasonló helyzetben megkérdezték, hogy hány indiait kontraktor kell hogy meglegyen időre?
Minden projektmenedzser első gondolata az, hogy plusz erőforrással bármit meg lehet oldani. A gond az, hogy ez nem igy van, főleg rövid távon, amig be kell őket tanitani. Ráadásul lehet csak nekem volt ilyen “szerencsém” eddig, de a kódminőségük hagy némi kivánnivalót maga után, de ez egy másik téma.
Na de megkérdezem megint, mi lehet a megoldás? A minőség rovására menjen a dolog? Nem-nem, ezt már megbeszéltük, hogy amint pl teszteket stb elhagyunk, elindulunk egy lejtőn.
Akkor? Bizony a scope-ból kell vágni. Meg kell értetni az ügyféllel, hogy az amit ő akar ebben a formában nem fog beleférni az időbe, tehát valamit vágni kell belőle. Üljünk le és nézzük, hogy mi az amit ki lehet hagyni?
Persze az ügyfél nem enged, túlórák lesznek, rossz lesz a kód, ezzel pedig senki se jár jól.
Na de ennyi volt a rant mára, ez volt a minicube podcast, találkozunk legközelebb.
Hosted on Acast. See acast.com/privacy for more information.
