Agilis trendek

Agilis trendek

Skálázott agilis

A skálázott agilis gyakorlatok tovább terjednek és fejlődnek. A kiáltványt 2001-ben adták ki. Voltak keretrendszerek a nagyobb csapatösszeállításokhoz (Scrum of Scrums, FDD, Crystal), de ez az évtized inkább a kiscsapat alapú Agilisé volt. Ez idő alatt a csapatok sok Agilis keretrendszert alkalmaztak. Néhányan úgy döntöttek, hogy váltanak – például Scrumról Kanbanra, és ez olyan új kezdeményezéseket indított el, mint a Scrumban. Nagyobb szervezetek figyelték a fejlődést, és próbálták megérteni az agilis alkalmazhatóságát az ő bonyolultabb szervezeti kereteiken belül. A következő évtized egyértelműen az agilis kiterjesztéséről szólt a nagy szervezetekre. Csak 2 népszerű példát említek: a SAFe, DA már az elején elindult, majd az évtized során tovább fejlődtek. A DA-t végül a PMI felvásárolta. A SAFe jelenleg 5.1-es verziójú. Noha elég hosszú út vezetett idáig, kétségtelenül az összes skálázott keretrendszer és eszköztár folyamatosan fejlődik.

Design Thinking 

A design thinking egy felhasználó-központú iteratív folyamat, amelyet a termékfejlesztésben használnak. Igyekszik megérteni az üzleti igényeket, megkérdőjelezni a feltételezéseket és újrafogalmazni a problémákat. Alapvető eleme az empátia, egyéni és csapatgyakorlatokat használ, mint például ötletbörze (brainstorming), interjúk, felhasználói úttérkép (user journey mapping). Kísérletezés, vázlat, majd prototípuskészítés és tesztelés a javulás ellenőrzésére. Végül a történetleképezés (Story mapping) használata a szükséges funkciók kifejezésére. Ez a megközelítés egyre inkább átveszi az üzleti elemzés hagyományos eszköztárát, így biztosítva a megfelelő eredményt.

A DEVOPS gyakorlatok tovább terjednek  

Mi az a devops? Ez egy gondolkodásmód, amely messze túlmutat néhány gyakorlaton. A DEVelopment és OPerationS csapatokat egyesíti, hogy az automatizálás és a nagyobb megbízhatóság révén gyorsabban kerüljön a termék, vagy frissyítés a piacra. A CI/CD folyamatos integrációval (CI-continuos integration). Egy lépéssel továbblépve már a folyamatos leszállítás (CD- continuos delivery). Ez azt jelenti, hogy a lekötött kód átmegy, és az automatizált fordításon, a builden átkerül egy tesztrendszerbe, ahol automatizált tesztek futnak. A fejlesztők látni fogják, hogy a hozzáadott kód a várt módon működik-e, és nincs-e semmilyen rossz hatással a meglévő kódra és a korábban már működő funkciókra. A continus delivery azt jelenti, hogy a telepítőcsomag létrehozása folyamatban van, de még mindig kézi munkára van szükség ahhoz, hogy éles állapotba kerüljön. Végül a folyamatos üzembe helyezés (szintén, de a D egy másik szó kezdőbetűje: CD-continuos deployment), ami azt jelenti, hogy a tesztelt kód automatikusan be is kerül az éles rendszerbe. Előfordulhat, hogy a funkciók a konfigurációból ki vannak kapcsolva, így a végfelhasználók nem ismernék fel a változást, és így lehet elkülöníteni a telepítést (deployment) a kiadástól (release). A DEVOPS csapatok mind a területi készségeket, mind a tudást felhasználhatják ennek a koncepciónak az elsajátításához. Teljesen automatizált tesztlefedettség segíti a megbízhatóságot, de fokozott visszaállítási és visszaállítási gyakorlatokra is szükség van, mivel a kód automatikusan élesítődik, és a legjobb automata tesztelés, az élesre legjobban hasonlító környezet használata mellett is kiszabadulhatnak olyan hibák, amik gondot okoznak az éles rendszerben. A továbbfejlesztett telemetria és mérőszámok segítenek az ilyen problémák feltárásában, a helyreállítás gyors végrehajtásában és a működés minimális megszakításokkal történő fenntartásában. Ezen gyakorlatok alkalmazását csak a DEVOPS kultúrát és gondolkodásmódot átvevő csapatokkal lehet egyeztetni, megtervezni, a megfelelő eszközöket kiválasztani és működtetni. 

A Scrum Guide frissítései 2020-ban 

A Ken Schwaber és Jeff Sutherland által készített srcum útmutató 2020-as frissítése számos érdekes frissítést tartalmaz. Lehet, hogy csak néhány szónak tűnnek, de ezek fontosak.  
A csapattal kezdődik. Most egy csapat van, a Scrum Team. A Product Owner, a Scrum Master és a fejlesztők (Developers). Ez utóbbit korábban fejlesztőcsapatoknak nevezték. A 2 „csapat” némi zavart okozott. Egy csapattal az egész csapat felelős a sprint eredményekért, nem csak a fejlesztők. A „szerepek” kifejezést felváltotta az felelősségvállalás. 
Érdekes frissítés a napi scrum 3 kérdésének eltávolításával (Mit történt az előző napi scrum óta, mi fog a következőig történni, vannak-e nehezítő körülmények, Akadályok). Továbbra is használhatók, de már nem szerepelnek az útmutatóban. Ez nagyobb szabadságot jelent a csapat számára, a napi scrum levezetésében. Az előző verzióban is szó volt arról, hogy a scrum mesternek gondoskodnia kell arról, hogy a napi scrum megtörténjen, és coach-olnia kell a fejlesztőcsapat tagjait, hogy hatékonyan, zökkenőmentesen menjen a megbeszélés. A frissítésben csak azokra a scrum mesterekre hivatkozunk, amelyekben ők (valamint a PO-k) fejlesztő csapat részeként (is) aktívan részt vesznek a sprint szállításában. A fejlesztők felelősséggel tartoznak a napi scrumért, és nem ez az egyetlen és kizáróalkalom, amikor módosíthatják tervüket a sprint hátralévő részére. 
Egy új fogalmat vezetünk be, a termékcélt (product goal). Ahogy a sprint cél (sprint goal) a sprint backlog vállalása, a termékcél a teljes termékhátralékra vonatkozó vállalás. A kész definíciója (DoD) a növekmény (Increment) vállalása – így tehát megvan a 3 vállalás a 3 artifakt-hez (product, sprint, increment). 
Támogató vezetők (servant leader)– bár ez a kifejezés sokat használt számos agilis megközelítésben, és a Scrum-irányelvben is szerepelt, a 2020-as frissítés során megváltozott. Ma már valódi vezetőket (true leader) használ, akik segítik a csapatot. Ez nem csak egy szövegmódosítás, hanem egyértelműen nagyobb hangsúlyt fektet a vezető részre. 
A fentiekkel kapcsolatos saját gondolataim: a frissítések nagyszerűek, és a keretrendszer egyértelműen fejlődik az idő múlásával, ezért jó ötlet ezekre gondolni. Az is a Scrum brilliánas kezdeti megfogalmazását jelenti számomra, hogy 20 év alatt alapvető változás nem történt. Viszont ahogy egyre több ember és csapat használja a scrumot, rengeteg a tanulság, a visszajelzés, és azt úgy tűnik használják is. Ne feledjük – mivel a Scrum keretrendszer és nem módszertan, azt jelenti, hogy rugalmas, és számos lehetőséget ad az alkalmazóknak, hogy a részleteket igényeik szerint testreszabják. Ezeket a 2020-as frissítéseket megfontolhatjuk, szükség szerint alkalmazhatjuk, de nyilván nem kötelező. Továbbra is van helye néhány szabály meghatfogalmazására is, a csapat igényei, fejlettsége alapján. Üdvözlök minden pontosítást és több szabadságot, ugyanakkor különösen a kevésbé tapasztalt csapatok számára továbbra is hasznos lehet a standup 3 kérdésének alkalmazása, valamint a Scrum Master jelenléte, aki segíti és támogatja a csapatot, és továbbra is felelősséggel tartozik a Daily Scrum létrejöttéért.