Előző cikkemben elkezdtem a vitát a gyengén kialakult szokásokról egy scrum csapaton belül, amelyek végül (előbb-utóbb) a szállítás kudarcához vezetnek. Ebben a cikkben szeretném még egyszer kiterjeszteni ezt a témát, és most a csapaton belüli funkcionális folyamatokra összpontosítani.
Ezek hasonlóan fontosak, mint a csapat technikai kiválósága. Még akkor is, ha a bent tartózkodó emberek rendkívül képzettek az elvégzendő munkához, még mindig vannak olyan területek, amelyek tönkretehetik a tökéletességre irányuló erőfeszítéseiket. És ez nem annyira az ő hibájuk, hanem a projektmenedzsment döntéseinek közvetlen felelőssége, és az, hogy képesek-e a csapatot a célnak megfelelő folyamatokkal szolgálni, hogy egyértelmű szándékkal és kiszámítható tevékenységekkel támogassák a csapatot.
Tartalomjegyzék
Erősen szegregált csapat, különleges képességekkel
Képzelje el, hogy a csapat képzett fejlesztőkkel rendelkezik, akik tökéletesen függetlenek, és képesek betartani ígéreteiket, és a megbeszélt sprint tartalmat a sprint vége előtt még időben szállítani. Még egy ilyen tökéletes forgatókönyv esetén is (ami egyébként nagyon valószínűtlen), hogy a csapatnak gondja lesz lépést tartani az (egyre növekvő) lemaradási jellemzőkkel, ha a képességek szigorúan elkülönítve vannak a csapattagok között.
Néhány példa
- A csapatnak 1 vagy 2 DevOps mérnöke van, akik képesek bármilyen változtatást végrehajtani az automatizált folyamatokon vagy gondoskodni a platformon belüli szolgáltatásokról, de a csapat többi tagjának fogalma sincs ilyesmiről. Ezután a sztorik megvitatása a scrum ceremóniákon, például a finomításokon időveszteséggel jár a csapat többsége számára azzal, hogy részvétel nélkül ácsorog a megbeszélésen, és fordítva – a DevOps fejlesztőjét nem fogja érdekelni a többi funkcionalitás-orientált történet, és a találkozón eltöltött idő is többnyire elpazarolt lesz.
- Az egész csapat számára egyetlen adatbázis-szakértő áll rendelkezésre. A csapat által fejlesztett rendszerben lévő adatmegoldások összetettségétől és használatától függően előfordulhat, hogy ez a személy folyamatosan túlterhelt olyan történetekkel, amelyeket nincs esélye elég hamar befejezni, különösen, ha figyelembe veszik a prioritásait. Még rosszabb, hogy más történeteknek is várniuk kell, mivel ezek az adatbázis-sztorik által biztosított adatforrástól függenek.
- Amikor egy adott termék leginkább a háttérfejlesztésre irányul, akkor minden esetre ott van az egyetlen front-end fejlesztő (mert időnként mindenesetre szükség van némi változtatásra még a felhasználói felületen is). Ebben az esetben ismét a scrum ceremóniák nagy része időpocsékolás ennek a csapattagnak, hiszen tudása csak a front end-re korlátozódik, és semmi más nem számít.
Ahol arra a következtetésre jut
A fenti esetek bármelyikében az az eredmény, hogy az emberek vagy az idejüket vesztegetik, vagy pedig nem tudják utolérni a lemaradási keresletet. Megakadályozzák a csapat többi tagját a következő sztorikon való munka megkezdésében, vagy ténylegesen csökkentik a scrum csapat általános hatékonyságát, mert túl sok időt nem használnak fel a sprintben.
A csapatnak azonban még mindig ennyi fejlesztője van. Kívülről nem látszik (még ha nem is akarnak leleplezni), hogy a csapaton belüli emberek nem képesek felvállalni bizonyos történeteket, csak azért, mert túlságosan orientáltak egy-egy adott készségre. Így nem tudnak segíteni a többi csapattagnak a történetekben, még akkor sem, ha kapacitásuk ezt megengedné, és a történetek prioritásai is ezt támogatnák.
Még a terméktulajdonosnak is nehéz értelmes sprint tartalmat összeállítani a csapat számára, hiszen a terméktulajdonosnak mindig figyelembe kell vennie, hogy egy-egy sztorin hány ember tud dolgozni, és hogy egyszerre több hasonló sztori kerül-e a sprintbe. , végső soron a csapat kapacitása túlterhelt, még akkor is, ha valóban vannak emberek, akik esetleg dolgozhatnának ezeken a történeteken, de nincs meg az a képességük, hogy elkezdjenek velük foglalkozni.
A dilemma megoldása
Megoldandó dilemma, a projektmenedzsereknek tisztában kell lenniük a választható útvonallal. Konkrétan a következők közül választhat:
- Sok full-stack fejlesztő van, aki képes szélesebb tartalomra dolgozni, de nem igazán szakértők sok témában. Tehát szélesre mehetnek, de mélyre nem. Ekkor a szállítás gyorsan haladhat, de a minőség romolhat.
- Minden egyes technológiához elkötelezett szakértők állnak rendelkezésre, de aztán elfogadják a korlátokat, és keményebben dolgoznak a jobban illeszkedő nyomtatási tartalomért. Ekkor az emberek elmélyülhetnek, és nagyszerű történeteket építhetnek fel, de a történeteket egymás után kell megközelíteni, így tovább tart.
Gyenge terméktulajdonos
Ez nem feltétlenül „folyamatkérdés” értelemszerűen, de én csak azért kezelem így, mert a szilárd történetek létrehozása olyan folyamatként is felfogható, amelyet a csapatnak sziklaszilárdnak és a fejlesztőcsapattal kompatibilisnek kell lennie.
Gyenge alatt nem az egyén tudástulajdonságára kell utalni, hanem a terméktulajdonos azon képességére, hogy kiszolgálja a csapat történetét, amelyet a fejlesztők megértenek, és amelyek a termék ütemtervének szempontjából egyértelműek. Mindkettő nagyon fontos egy sikeres scrum csapat számára.
Ha a történetekből hiányoznak a részletek ahhoz, hogy a fejlesztők egyértelműen megértsék a célt, a funkcionális értéket vagy a technikai elvárásokat, akkor alapvetően két forgatókönyv történhet:
- A fejlesztők valami mást készítenek, mint amit a terméktulajdonos valójában akart. Magán a sprint alatt még nehéz is elkapni, mert többnyire a terméktulajdonosnak nem volt lehetősége ilyen részletesen nyomon követni a történetek menetét, és a PO többnyire csak arra számít, hogy a dolog (varázsütésre) megtörténik.
- A fejlesztők túl sok időt töltenek a történetek tisztázásával és újra és újra megvitatásával, ahelyett, hogy elkezdenék felépíteni őket. Ez számos további felhívást, ismételt megállapodásokat és a munka késői sprint fázisra való halasztását vonja maga után. Elérkezik egy olyan ponthoz, ahol a történetek eredeti becslései már nem tekinthetők pontosnak, és a történetek nem zárhatók le a sprintben, és a következő sprintekre gurulnak. A legrosszabb esetben a helyzet megismétlődik a következő sprintekben.
Idő az önreflexióra
Általában nehéz beismerni, de a terméktulajdonosnak találnia kell időt a gondolkodásra, át kell tekintenie a keletkezett lemaradástörténeteket, és végül össze kell vetnie azt a termék ütemtervével, ha van még értelmes kapcsolat a kettő között – ha van útiterv. egyáltalán. Ha nem, akkor először ezt kell megoldani. Néha a megoldás az, ha beismerjük, hogy a termék tulajdonosa túl messze van a csapattól és túl messze van a saját céljától.
Ilyen esetben a csapat terméktulajdonos részét kell megoldani. Ha mást nem is, de egy olyan szilárd üzleti elemzőt behozni a csapatba, aki inkább a csapat tartalmára, mintsem az üzleti tartalomra orientálódik (ehhez ebben az esetben már van terméktulajdonosunk), jó választás lehet, még az árért is. megnövekedett a csapat összköltsége.
Tesztelési folyamatok rögzített idővonal nélkül
Mi van akkor, ha a tesztelési tevékenységek nem szorosak a konkrét ütemterv szerint egy scrum sprintben?
Első pillantásra ez valami jónak tűnhet, amit szeretnénk egy agilis / scrum csapat számára. A rugalmasság mindig üdvözlendő, és kívülről jól hangzik.
Tapasztalataim azt mutatják, hogy ennek a szabadságnak az eredménye inkább a káosz, mint a rugalmasság. Ez nem jelenti azt, hogy a megoldást a „sprint belsejében lévő vízesések” létrehozása kell, hogy legyen, dedikált tesztelési fázisokkal, amelyeket közvetlenül a fejlesztés után követnek. Ebben az esetben semmiképpen sem ez a helyes megközelítés. Erről bővebben a scrum tesztelési stratégiáról és az agilis tesztelési életciklusról szóló bejegyzéseimben olvashat.
Továbbra is engedhetünk némi rugalmasságot, és úgy választhatjuk meg a tesztelési ütemezést, ahogy az a legmegfelelőbbnek tűnik a jelenlegi fejlesztőcsapatnak és a csapat által szállított adott terméktulajdonságoknak. Ezzel a választással azonban két fő célt kell elérni:
Ha ezek a feltételek teljesülnek, a csapat természetesen alkalmazkodik az illesztési folyamathoz, és a szállítási ütemezést nem befolyásolják a nem tervezett, elhúzódó tesztelési tevékenységek.
Végül, ami a legfontosabb, az a megbízható és kiszámítható sprint kiadás, ami a blog utolsó pontjához vezet.
Undefined Release Process
Nos, ez olyan nyilvánvaló dolog minden scrum csapat számára. Érdekes módon azonban általában ez az egyik leginkább alábecsült folyamat.
Nagyon gyakran egy scrum-csapat csak azt mondja, hogy minden sprint után kiadják, de ezt nem támasztja alá szilárd folyamat. Ami ezután történik, az a valóságban az, hogy sok kaotikus, előre nem látható tevékenység fog felmerülni a kiadás ideje alatt. Hirtelen mindenkit „kibocsátási feladatok” foglalkoztatnak, és senki sem tud arra koncentrálni, hogy folytassa az új sprinttörténetek kidolgozását. A sprint mérőszámai ki vannak kapcsolva, és az elengedés véletlenszerű, előre nem látható tevékenységnek tűnik a harmadik személy (általában az ügyfél) szemszögéből.
Az emberek annyira koncentrálnak a lemaradásra, a sprinttartalomra, a fejlesztésre, a tesztelésre és végül az eredmények bemutatására, hogy elfelejtik, ha mindezzel elkészültek, már megy a következő sprint, és már veszítenek az időből.
Jó időt keresek a kiadásra
Tehát pontosan mikor kell a csapatnak elkészítenie a tényleges kiadást? Az egyetlen fontos dolog, ami a végén számít.
A kérdésre adott válasz benne van a folyamatban, feltételezve, hogy van ilyen. Attól függ:
- a csapat által a sprintekben előállított tartalom összetettsége,
- egy sprint időtartama,
- a rendszer érintett összetevőinek száma
- a változtatásokat használók és kérők száma,
ismételt kiadási folyamatot kell létrehozni, és a továbbiakban követni kell. A folyamat pontos szabályait ismét rugalmasan lehet meghatározni. A tesztelési tevékenységekhez hasonlóan azonban, ha ez egy sziklaszilárd szokás, amely kiszámítható, és a jövőben konkrét napokra van ütemezve, támaszkodhat rá és hivatkozhat rá.
Választható lehetőségek
Egy ilyen folyamat lehetséges formái lehetnek a következők vagy mások:
- Fejezze be az aktuális sprint szolgáltatásainak tesztelését a következő sprint során, és adja ki a tartalmat a sprint végén (a tesztelés befejezése után). Ez azt jelenti, hogy minden kiadásban nem lesz semmilyen tartalom a legutolsó sprintből, de az előző 2 sprint történeteit tartalmazza.
- A megjelenés előtti utolsó sprint mindig az előző két sprint tartalmának tesztelésére szolgál.
- Ez nem jelenti azt, hogy a „tesztsprint” alatti fejlesztés leáll; csak annyit ír, hogy az abban a tesztsprintben kifejlesztett tartalom még nem kerül bele a következő kiadásba.
- Ha már van elegendő automatizált tesztelési tevékenység, törekedjen arra, hogy minden egyes sprint vége után végezze el a kiadást. Akkor ennek egy nagyon szigorú folyamatnak kell lennie, ahol az elkötelezett emberek 100%-ig erre a néhány napra összpontosítanak. Ez továbbra sem érintheti a fejlesztőcsapat többi tagját.
- Választhatja azt is, hogy havonta egyszer vagy N havonta egyszer kiadja-e, főleg ha ez a végfelhasználók szemszögéből jó. Ez növeli a tesztoldali erőfeszítéseket minden egyes sprint esetében (mivel a tartalom minden kiadásnál nagyobb lesz). Másrészt viszont ez idővel kevesebb ismétlődő tevékenységet jelent, ami ebben az esetben előnyökkel járhat a csapat számára. Ennek eredményeként lehetővé teheti a csapat számára, hogy több új funkciót építsen ki a kiadások között, annak ellenére, hogy a funkciók valójában lassabb ütemben kerülnek gyártásba.
De amint azt már néhányszor említettük, nem olyan fontos, hogy ezek közül a folyamatok közül melyiket választják. Sokkal fontosabb, hogy a csapat mennyire ragaszkodik ehhez a folyamathoz, és milyen megviselhetetlen szokássá válik.
Ezt az útmutatót a kiadáskezelési folyamatról és gyakorlatokról is elolvashatja.