3 Scrum csapdái és hogyan javíthatom őket

Megszabadulunk a szörnyű stand-up találkozóktól, a pokol becslésétől és a felhasználói érték biztosításától, és ehelyett nagyszerű termékeket építünk.

Fotó: Randy Fath az Unsplash-en

Amikor a szoftvermérnökök állásait böngészi, szinte mindig van egy univerzális készség, amelyet a potenciális jelölteknek elsajátítaniuk kell. Ez a képesség „Scrum”. Függetlenül attól, hogy a Scrum valóban olyan készség, mint a szőnyezés vagy a kódírás -, mindig is érdekesnek tartottam, hogy a vállalatok túlnyomó többsége a Scrumot tényleges működési módjává tette.

Az agilis munka előnyei - ami szinte mindig a Scrum bizonyos megvalósítását jelent - vezetői szempontból nyilvánvalóak. Rendszeres időközönként el kell döntenie, hogy milyen értékes munkát végez, nem pedig megbotlik magával a negyedéves útitervekben, és a munkát oly módon kell felosztani, hogy elméletben mindenkinek képesnek kell lennie arra, hogy elvégezze azt.

2018-ban írtam egy cikket, amely felvázolja azt, amit akkoriban gondoltam, az az ár volt, hogy a Scrumot szoftverfejlesztésre használják. Ez a cikk sok dicséretet kapott a csalódott fejlesztőktől, valamint rengeteg kritikát kapott azoktól, akik ragaszkodnak ahhoz, hogy a leírtak szerint a műfaj Scrum volt.

Azóta utaztam, hogy megtudjam, mi képezi ezt a „rossz” Scrumot. Ahelyett, hogy a Scrumot teljes egészében úgy írtam le, hogy az valószínűleg nem működik szoftverfejlesztésben, a rossz elemek meghatározására összpontosítottam, és megkíséreltem megfogalmazni módszereket arra, hogy értelmes, produktív elemekké alakítsák azokat.

Ebben a cikkben arra gondolok, amit megtanultam az előző cikk írása óta, és azt gondolom, hogy a Scrum hogyan segíthet Önnek és a csapatának jobb szoftver felépítésében.

Hasznos napi készenléti találkozókat tartson

Ez egy érdekes téma. A stand-up találkozók a Scrum egyik sarokköve. Az ötlet az, hogy egy projektcsapat kora reggel összejön, feláll és tájékoztatja egymást az előrehaladásukról és minden akadályról, amelyben segítséget nyújthatnak. Ezek a találkozók elméletileg nagyszerűek. Mindenki ugyanazon az oldalon található, és mivel a nap elején fordul elő, mindenki hatékonyan töltheti napjait.

Azt tapasztaltam azonban, hogy ezeket a találkozókat a vezetők gyakran visszaélnek annak megállapítása érdekében, hogy mindenki megfelelően végzi-e a munkáját, és hogy a projekt továbbra is ütemezett-e. Ha nem biztos benne, hogy ez a helyzet vagy nem a stand-up-okban, akkor jó jelzés, ha látja, hogy a beszélő személy kapcsolatba lép-e a menedzserrel vagy valamelyik kollégájukkal. Ha elsősorban a menedzserükön vezetik a beszélgetést, akkor valószínű, hogy ez egy álruhában levő jelentéskészítő találkozó.

Ha az stand-up menedzser-orientált, akkor gyakorlattá válik a beszédem során, senki sem hallgat. Mindenki csak a távolba bámul, unatkozva a fejéből, és arra vár, hogy a találkozó vége legyen. Ironikus módon az ilyen típusú stand-up szükségtelen részleteket is tartalmaz, csak hogy a menedzsernek jelentést tegyen, és ez sokkal hosszabb időt vesz igénybe, mint amilyennek valójában kellene.

Szerencsére az ilyen stand-up megoldása egyszerű lehet. Először távolítsa el a kezelőt az állványról. A Force működik, de valószínűleg meggyőzheti őket erről, ha velük is beszél. Feltételezve, hogy mindenki, aki a találkozón marad, ugyanazon a projekten dolgozik, a találkozó hangja egy idő után megváltozik.

Ahelyett, hogy a találkozó azt bizonyítja, hogy a tegnap értelmes munkát végzett, és ma is folytatja, a találkozó több problémamegoldó jellegű. A helyszínen eldönti, hogy melyik feladatot kell megtennie a továbbiakban, és ha van valami, amely akadályozza az utadon, akkor ott és ott megkeresheti.

PS Ha te vagy a menedzser ebben a történetben, akkor tudom, hogy nehéz megszabadulni a találkozótól. A csapat tagjai számára még nehezebb kérni az Ön távollétét. Lehet, hogy ennek megbeszélése a csapattal és a menedzser nélküli rövid ülések kipróbálása rövid időre jó módszer annak mérésére, hogy az ülés nélküled eredményesebbé válik-e.

Rob Hampson fotója az Unsplash-en

Ne megszállja a felhasználói értéket

A vállalatok egyik oka az, hogy a Scrumhoz hasonló kereteket valósítanak meg, mert azt akarják, hogy gyors értéket biztosítsanak a végfelhasználóiknak. Ez szépen párosul az egyes sprint rövid időtartamával, valamint azzal a képességgel, hogy fókuszbeállításokat végezzen közöttük.

A legnagyobb hibát, amelyet itt elkövethet, megszállottja lehet annak, hogy csak a végfelhasználók számára adjon értéket. Ugyanúgy, mint nincs értelme extra padlót hozzáadni rothadó tartógerendákkal rendelkező épületekhez, nagyon kevés értelme van hozzá olyan funkciókat hozzáadni egy projekthez, amely a saját súlya alatt morzsolódik.

Ugyanúgy, ahogyan az autóvezetés nem jelenti azt, hogy tudjuk, hogyan kell egy autót építeni, a fejlesztői csapatot „vezetõ” személy nem feltétlenül ismeri a szoftver elkészítésének legjobb módját. Ha az autószerelő azt mondja, hogy az autóval már nem biztonságos vezetni, akkor tudja, hogy ha legközelebb vakációra veszi, óriási kockázatot vállal. Ugyanezt az óvatosságot kell megtennünk, amikor egy tapasztalt mérnök azt mondja nekünk, hogy valami hozzáadása, amelyet a felhasználó kétségbeesetten akar, nagy hatással van a kódbázisunk minőségére.

Azok a szoftvermérnökök, akik minden nap kódbázison dolgoznak, szintén a legintenzívebb felhasználók. A szokásos felhasználókkal ellentétben nem csak a boldog utat követik; minden utat követnek. Ha egy termék megvalósítása megváltozott, a mérnököknek fokozatosan nehezebb lesz értelmes munkát végezni. Napjaik nagy részét a dolgok helyett inkább dolgok körül fogják tölteni.

Noha kétségtelenül fontos a funkciók létrehozása a végfelhasználók számára, sokkal valószínűbb, hogy hosszú távon olyan termékkel rendelkezik, amely hosszabb ideig megtartja mind a végfelhasználókat, mind a fejlesztőket. Ez azt jelenti, hogy néha jó ötlet lehet a nagy refaktoros munkákat vagy az általános takarítást sprintben is megtervezni. Nem mint másodrendű munka, hanem mint első osztályú - kezelje azt olyan munkaként, amely ugyanolyan fontos, mint új szolgáltatások létrehozása.

Ne vegye be az evangéliumra vonatkozó becsléseket

A sprintben elvégzhető munka mennyiségének meghatározása érdekében a hátralék minden egyes feladatát prioritássá kell tenni, és becsülni kell a munkáját. Időnként ezt úgy végezzük, hogy becsüljük meg a feladat elvégzéséhez szükséges órákat, más esetekben homályosabb helyettesítőket, például pontokat vagy akár pólóméreteket.

A sprint során elvégzendő munka becslése vitathatatlanul Scrum egyik legbonyolultabb része. Úgy tűnik, hogy a fejlesztők soha nem értenek egyet egy adott feladat elvégzésében, és ez azt feltételezi, hogy még nyilvánvaló is, hogy mi kezdődik. Számos oka van annak, hogy a becslések aligha lesznek pontosak.

Ezen okok egyike a korábbi tapasztalat. Ez lehet az egyén korábbi tapasztalata, vagy a csapat tapasztalata, de soha nem vonatkozik a csapat minden egyes egyénére. Tegyük fel, hogy egy csapattag nagy tapasztalattal rendelkezik egy hitelesítési mechanizmus végrehajtásában, egy bizonyos szabványt követve. Lehet, hogy hajlamosak a hitelesítés megvalósítását sokkal kevesebb „erőfeszítéssel” becsülni, mint valaki, aki kevésbé ismeri a témát. Ennek ellenére a becslésnek pontosnak kell lennie a csapat tagjai számára, függetlenül attól, hogy ki végül elvégzi a munkát.

Egy másik ok az, hogy a becsült munka aligha lesz egyértelmű. Egy pékség esetében meglehetősen egyértelmű előre becsülni, hogy mennyi ideig tart a száz kenyér sütése. Tudják, mennyi ideig tart, hányat tud sütni egy időben, és akkor csak elvégzel egy egyszerű matematikát.

Mint minden szoftvermérnök tudni fogja, a kódoláskor nem így működik. Minden alkalommal, amikor belemerül egy adott kóddarabba, nemcsak elemeznie kell és meg kell értenie, hanem meg kell értenie és elemeznie kell a végrehajtandó változtatásokat és azok lehetséges következményeit is. Ez rendkívül kihívást jelent, nem is becsülve.

Valószínűleg felsorol egy csomó más okot, amelyek miatt a munka becslése nehéz, de a lényeg az, hogy ne vegyen semmilyen becslést evangéliumként. Tegyük fel, hogy a csapat legjobban oktatott kitalálást készít azokkal az emberekkel, akikkel abban az időben rendelkeznek.

Noha a csapatok jobban meg tudják becsülni a munkát az idő múlásával, mindig tartsd észben, hogy a legkisebb dolgok teljes mértékben elhagyhatják a becslést. A valós érték a ténylegesen elvégzett munkában van, nem abban, hogy a becslés helyes volt-e vagy sem.

Következtetés

Nyilvánvaló, hogy a Scrum több, mint a részei. A szertartások sebészi végrehajtása és a Scrum-nak való elnevezés csak egy csomó szertartást hagy magának, amelyeken az embereknek hirtelen részt kell venniük, de ez nem feltétlenül teszi hatékonyabbá vagy még agilisabbá a fejlesztési folyamatot.

A Scrum végrehajtását folyamatosan javítani kell. Ha valami nem működik a csapatod számára; adaptálni. A súrlódásnak nem szabad változtathatatlan ünnepségek és találkozók sorozatának lennie. Folyékony dolognak kell lennie, amely növekszik a csapatán, és olyan iránymutatásokkal szolgál, amelyek elősegítik a termelékenység és hatékonyság növekedését.

Semmi esetre sem vagyok lelkes agilis rajongó, és valószínűleg soha nem is leszek. De ellentétben a 2018-ban írt cikkel, amelyre hivatkozhattam, nem hiszem, hogy a Scrum mint intézmény természetéből adódóan rossz a szoftverfejlesztő csapatok számára.

Ha Scrum nem érzi megfelelőnek az Ön csapata számára, nyissa fel a beszélgetést. Nézze meg, hogy a csapat többi tagja ugyanúgy érzi-e magát, és ha igen, próbálja meg pontosan meghatározni, mi érzi pontosan a termelékenységet, és végezzen fokozatos változtatásokat együtt.

A szoftver fejlesztésének legjobb módja az a módszer, amely a csapata számára működik. Összpontosítson erre. Felejtsd el a többit.