Dulakodás

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2022. szeptember 2-án felülvizsgált verziótól ; az ellenőrzések 27 szerkesztést igényelnek .
Dulakodás
Hivatalos oldal scrum.org
 Médiafájlok a Wikimedia Commons oldalon

A Scrum ( /skrʌm/ [1] ; scrum „  scrum”) egy könnyű keretrendszer, amely segít az embereknek, csapatoknak és szervezeteknek értéket teremteni az összetett problémák adaptív megoldásai révén [2] .

A Scrum nem csak a szoftverfejlesztés területén használható, hanem más gyártó iparágakban is [3] .

A szoftverfejlesztési projektek menedzselése mellett a Scrumot a szoftvertámogató csapatok is használhatják a szoftverfejlesztési menedzsment és karbantartás megközelítéseként.

Különbséget kell tenni a Scrum [4] és az Agile [5] között .

Történelem

A Scrum módszertan elsődleges forrásai a következők voltak: a Toyota gyártási rendszere és a katonai repülés használatának koncepciójának OODA ciklusa (OODA hurok, vagy OODA hurok, vagy Boyd hurok), amely négy összetevőből áll: megfigyelés („megfigyelés”). , orientál ("orient"), dönt ("dönt"), cseleked ("cselekszik"). [6]

Magát a megközelítést először Hirotaka Takeuchi és Ikujiro Nonaka írta le a The New Product Development Game -ben (Harvard Business Review, 1986. január-február). Megjegyezték, hogy a kis, multidiszciplináris csapatok által működtetett projektek szisztematikusan jobb eredményeket produkálnak, és ezt "rögbi megközelítéssel" magyarázták.

1991 -ben DeGrace és Stahl Unholy Problems, Righteous Solutions [7] című könyvében scrum-nak nevezték ezt a megközelítést , amely egy sportfogalom, amelyet Takeuchi és Nonaka cikkében talált meg. Ken Schwaber azt a megközelítést alkalmazta, amely a 90-es évek elején a Scrumot a vezette . A Scrum módszertant először Schwaber és Jeff Sutherland [6] dokumentálták, világosan határozták meg és írták le a nagyközönségnek az OOPSLA'95 [ 8] Austinban . K. Schwaber és D. Sutherland az elkövetkező években együtt dolgoztak azon, hogy az iparágban szerzett tapasztalataikat és bevált gyakorlataikat egyetlen egésszé dolgozzák fel és írják le a ma Scrum néven ismert módszertan szerint.

Schwaber 2001 -ben egyesítette erőit Mike Beadle -lel , hogy részletesen leírja a módszert az Agile Software Development with Scrum [9] című cikkében .

2002-ben Schwaber másokkal együtt megalapította a Scrum Alliance-t [10] , és egy sor tanúsított Scrum akkreditációt hozott létre. Schwaber 2009 végén kilépett a Scrum Alliance-ból, és megalapította a Scrum.org -ot, archiválva 2019. december 10-én a Wayback Machine -nél , amely a Professional Scrum egyidejű akkreditációs sorozatát gondozza [11] .

2009 óta a The Scrum Guide [12] nevű nyilvános dokumentum határozza meg hivatalosan a Scrumot. Több mint 5 alkalommal felülvizsgálták. 2018-ban Schwaber és a Scrum.org közösség a Kanban közösség vezetőivel együtt kiadta a Kanban útmutatót a Scrum csapatoknak [13] .

Definíciók

Scrum

Scrum (az angol "scrum" - egy kifejezés a rögbiből, a csapatok kiindulási állapotát jelöli a labda bedobása előtt) - az események, műtermékek, szerepek minimálisan szükséges halmaza, amelyre a Scrum fejlesztési folyamata épül, és lehetővé teszi a rögzített rövid időszakokat sprinteknek ( sprinteknek ) nevezett idő, hogy a végfelhasználónak egy működő terméket biztosítson új üzleti lehetőségekkel, amelyek számára a legmagasabb prioritást határozzák meg. A módszertan a Taekuchi és Nonaka " The New New Product development Game " cikkében hangoztatott gondolatokon, valamint a csapatmunkán alapul, hasonlóan ahhoz, ahogy a rögbiben a csapat együtt dolgozik egy közös cél érdekében. A következő sprintben való megvalósítás lehetőségeit a csapat a sprint elején a Sprint Tervező értekezleten határozza meg . A sprintben várható munkamennyiség becsléséhez leggyakrabban relatív becsléseket és a pókertervezés gyakorlatát (Planning Poker) használják.

A sprint végén a Scrum csapata egy sprint áttekintő megbeszélésen (Sprint Review - a Demonstration régi neve) találkozik az ügyféllel, és bemutatja neki az üzleti termék növekményt (egy olyan termékváltozatot, amely teljes körű funkcionalitással már átadták az ügyfélnek és a felhasználónak használatra), ami egy sprintben sikerült is neki. A Sprint Review célja, hogy visszajelzést kapjon az ügyféltől, hogy megértse, mire kell a jövőben hangsúlyozni, és mi legyen az üzleti termék következő lépése.

A szigorúan rögzített rövid sprint időtartam (1-4 hét) csökkenti a kockázatokat, és lehetővé teszi, hogy gyorsan visszajelzést kapjanak az ügyfelektől a terméklátás módosítása érdekében.

Sprint

A Sprint [14]  egy olyan időtartam, amely elegendő egy tervezett Scrum-műveletsorozat elvégzéséhez, amelynek célja egy üzleti termék növekményének létrehozása. Időben mereven rögzített. Egy sprint időtartama 1-4 hét. Minél rövidebb a sprint, annál rugalmasabb a fejlesztési folyamat, gyakrabban jelennek meg a kiadások, gyorsabban megérkeznek a visszajelzések a megrendelőtől, kevesebb idő telik el a rossz irányú munkával, de sok időt fordítanak a sprint tervezési értekezletekre, visszatekintésekre . Másrészt a hosszabb sprintekkel a Scrum Team csökkenti a megbeszélések, termékbemutatók stb. költségeit. A különböző csapatok a munkájuk sajátosságai, a többfunkciós csapatok és a követelmények szerint választják meg a sprint hosszát, gyakran próba-, ill. hiba. A sprintben végzett munka mennyiségének becsléséhez használhat egy előzetes becslést, amelyet történetpontokban mérnek. A sprint hosszának előzetes becslését a projekt hátralék rögzíti ( termékhátralék ; lásd alább).

A Scrum műtermékei

Leégési diagram

Az elvégzett munka mennyiségét és a hátralévő munka mennyiségét a projekt kidolgozásának idejéhez viszonyítva leégési diagramnak nevezzük.

Ezeket a diagramokat naponta frissíteni kell, hogy valós idejű előrehaladást és költségeket mutassanak a sprint és a projekt során végzett munka során, és a Scrum csapat minden tagja számára elérhetők: Scrum mester és terméktulajdonos.

A sprint leégési diagramja azt mutatja, hogy hány feladatot végeztek el, és mennyi van még hátra az aktuális sprintben.

Projekthátralék

A projekt kívánságnapló (projekt hátralék) tartalmazza a funkcionalitási követelmények fontossági sorrendjét, és ennek megfelelően a megvalósítás sorrendjét. A napló elemeit felhasználói történeteknek ( felhasználói történetek ) vagy hátralékelemeknek ( hátralékelemeknek ) nevezik . A projekthátralékot a Scrum folyamat minden résztvevője szerkesztheti. A projekthátralék karbantartásáért felelős személy a Scrum termék tulajdonosa.

Sprint lemaradás

Sprint kívánságlista (Sprint Backlog) – a terméktulajdonos által a projekthátralékból kiválasztott funkciókat tartalmazza. Minden funkció feladatra van lebontva, amelyek mindegyikét a Scrum csapata értékeli. A Sprint Planning Meetingen a tervezési póker módszert használja a csapat a sprint teljesítéséhez szükséges munka mennyiségének becslésére [15] .

Scrum board

A Scrum Board egy olyan eszköz, amely nyíltan bemutatja a Scrum Team folyamatban lévő munkájának állapotát. A Scrum tábla három oszlopból áll: „to do” ( to-do ), „in progress” ( folyamatban ), „done” ( kész ).

A Scrum Board tartalmazza a Sprint hátralék teljes terjedelmét, amelyet a csapat a Sprint tervezésben kiválasztott az aktuális sprintben való megvalósításhoz. Az üzleti feladatkártyákat jellemzően felülről lefelé helyezik el a táblán, csökkenő prioritási sorrendben (fent - legfontosabb, lent - legkevésbé fontos). Jó gyakorlat az üzleti feladatok konkrét (műszaki, szervezési és egyéb) munkákra bontani, amelyeket a csapatnak el kell végeznie az üzleti feladat végrehajtásához.

Az üzleti feladatok és a konkrét munkakártyák oszlopról oszlopra mozognak aszerint, hogy a csapat hogyan veszi őket végrehajtásra (Folyamatban) és hogyan fejezi be (Kész). A csapat munkájának előrehaladásának láthatósága érdekében a „munka csökkenése” napról napra megjelenik a Burndown Chart-on.

Leggyakrabban a munka kezdetén a csapatok flipcharttal ellátott táblákat használnak lapokra, míg a munkák nevét öntapadós matricákra írják és a táblára ragasztják. A találkozó előrehaladtával a csapat oszlopról oszlopra mozgatja a cetlikeket.

Gyakran használnak elektronikus táblákat is, amelyekben hasonló mechanizmusokat alkalmaznak. Például Atlassian Jira , Trello vagy kaiten [16] .

Sprint cél

Ez a sprint üzleti céljának rövid leírása. Műtermékként a sprintcél segít a csapatnak megalapozott üzleti döntések meghozatalában. Ez a műtermék szükséges ahhoz, hogy a projektcsapat önálló döntést hozhasson, amikor alternatív megoldásokat talál egy üzleti probléma megoldására.

Terméknövekedés

A terméknövekmény egy termék használatra kész darabja, amelyet egy sprint végére végre kell hajtani. A Sprint Review (Demonstration) csapata bemutatja a terméknövekedést a Scrum mesternek, a terméktulajdonosnak, az ügyfeleknek és más érdekelt feleknek [4] , hogy visszajelzést kapjanak tőlük, és döntsenek a termékfejlesztés további irányáról [17] .

Felhasználói történet

A projekthátralékhoz hozzáadott szükséges üzleti funkciókat gyakran felhasználói történetnek nevezik. A történet felépítése gyakran a következő: "Felhasználóként <felhasználó típusa> szeretnék <műveletet> tenni az <eredmény> elérése érdekében." Ez a szerkezet kényelmes, mert a fejlesztők és az ügyfelek számára is egyértelmű.

A felhasználói történet befejezéséhez szükséges erőfeszítések becslése (sprintfeladatok)

A könyvben [6] Sutherland az alábbi, általa használt és tapasztalatokkal alátámasztott hatékony módszert írta le a sprintfeladatok végrehajtásának munkaintenzitásának felmérésére bizonyos munkaintenzitási egységekben - emberórákban és hasonlókban.

A feladatértékelést a projektfejlesztők a Scrum Masterrel és a Terméktulajdonossal közösen végzik. A feladatok becslésének helyes módszere a póker tervezése . Kimutatták, hogy a munkaerő-ráfordítás ilyen értékelése sokkal pontosabb, mint a többi ember által végzett értékelés.

Minden fejlesztőnek saját, másoktól független értékelést kell adnia a feladat összetettségéről, a Fibonacci-sor számainak felhasználásával (1, 2, 3, 5, 8, 13, 20, 40, 100). A 21, 34, 55 számok helyett a 20, 40, 100. A becslések papírra rögzíthetők, vagy erre speciális kártyák használhatók (lásd tervezési póker ) és egyidejűleg kell kinyitni. . Az értékelésnek ez a szervezése elkerüli a lehorgonyzás hatását .

Ha a fejlesztők által választott összes érték nem több, mint három egymást követő Fibonacci szám intervallumába esik, akkor a csoport összes fejlesztőjének átlagos becslését használja a csoport a feladat végső értékeléseként. Ha a kiválasztott pontszámok ezen az intervallumon kívül esnek, akkor a legmagasabb és legalacsonyabb értékkel rendelkező fejlesztőknek meg kell indokolniuk választásukat, majd az értékelési köröket addig ismétlik, amíg a becslések halmaza három egymást követő Fibonacci-szám intervallumába nem esik. A gyakorlat azt mutatja, hogy ha a feladat összetettségének végső becsléséhez a három egymást követő Fibonacci-számnál nagyobb intervallumban fekvő becslések átlagolásával rendelkező változatot használjuk, akkor az eredmény sokkal kevésbé lesz pontos.

Bár kezdetben a feladatokat, és ennek megfelelően a történeteket és a projekt egészét a munkaerő-ráfordítás egy bizonyos egységében becsülik meg, a későbbiekben ezeket a becsléseket relatív munkaerő-ráfordításként pontként (pontként) használják fel a munka sebességének (termelékenységének) meghatározására. a Scrum csapat (Velocity). ).

Nyilvánvaló, hogy az egyes feladatok és a projekt egészének munkaintenzitásának felmérésére szolgáló fenti módszertan nemcsak a Scrumban, hanem más projektmegvalósítási módszerekben is alkalmazható.

A Kész (DoD) meghatározása

Kritériumok, amelyek meghatározzák egy elem készenlétét a felhasználó hátralékából.

Scrum csapat sebessége (Velocity)

A Scrum csapat által az előző sprintben szerzett összes pontja. Ez a mérőszám segít a csapatnak megérteni, hogy hány történetet tud teljesíteni egy sprint alatt.

Szerepek a Scrum folyamatban

A Scrum módszertan szerint a termelési folyamatban lehetőség van szerepek meghatározására, két csoportra osztva: „disznók” és „csirkék”. 2011 óta a "disznók" és a "csirkék" metaforái hiányoznak a Scrum kézikönyvből, mivel nincsenek speciális rituálék a csirkék számára [18] . A Scrum útmutató a disznókról szól. Ezeket a kifejezéseket egy anekdotából kölcsönözték: [6]

A disznó az úton sétál. A csirke ránéz, és azt mondja: – Nyissunk éttermet! A malac ránéz a csirkére, és azt válaszolja: "Jó ötlet, minek akarod nevezni?" A csirke elgondolkodik, és azt mondja: "Miért nem hívják szalonnának és tojásnak?" – Ez nem megy – válaszolja a disznó –, mert akkor teljesen a projektnek kell szentelnem magam, és te csak részben leszel benne.

A disznók megalkotják a terméket, míg a csirkék érdeklődnek, de nem annyira - mert nem érdekli őket, hogy sikeres-e a projekt vagy sem, ez nem nagyon fogja érinteni őket. A csirkék igényeit, kívánságait, elképzeléseit és befolyását figyelembe veszik, de nem engedik, hogy közvetlenül részt vegyenek a Scrum projektben.

Alapvető szerepek a Scrum módszertanban („disznók”)

A sertések teljes mértékben részt vesznek a projektben és a Scrum folyamatban. Scrum mester - értekezleteket vezet (Scrum meetings), felügyeli az összes Scrum-elv betartását, megoldja a konfliktusokat és megvédi a csapatot a zavaró tényezőktől, elősegíti a megbeszéléseket, felelős a Scrum leltár rögzítéséért, tárolásáért és kiadásáért. Ez a szerep nem jelent mást, mint a Scrum folyamat helyes lebonyolítását. Így a Scrum Master csapat szolgavezetője .

A Scrum mester fő eszköze a facilitátor bőröndje , melyben kártyadobozok, szögletes és kerek kártyák, öntapadós kártyák, gombostűk, markerek, írószer kés, ragasztószalag , Planning Poker kártyák, mágnesek, olló, szavazópontok találhatók.

Scrum terméktulajdonos – a végfelhasználók és a termékben érdekelt felek érdekeit képviseli .

A fejlesztői csapat (Scrum Development Team) egy többfunkciós projektfejlesztő csapat, amely különböző profilú szakemberekből áll: tesztelők , építészek , elemzők , programozók stb. A csapat létszáma 5-9 fő. A csapat az egyetlen, aki teljes mértékben részt vesz a fejlesztésben, és teljes egészében felelős az eredményért. A fejlesztőcsapaton, a scrum mesteren és a terméktulajdonoson kívül senki nem szólhat bele a fejlesztési folyamatba a sprint során. A csapat keresztfunkcionalitása lehetővé teszi, hogy a lehető leghatékonyabban tervezze meg az üzleti követelmények megvalósításának költségeit, és rövid időn belül valós üzleti alkalmazásokat szállítson a változó ügyféligényeknek megfelelően.

A Scrum csapat valójában egy fejlesztőcsapatból, egy scrum mesterből és egy terméktulajdonosból álló csapat kollektív képe. A csapat teljesen önellátó, nem függ külső szakemberektől vagy ügyfelektől.

További szerepek (Kiegészítő szerepek) a Scrum módszertanban („Csirkék”)

Felhasználói történetek

Kötelező mezők

További mezők

Néha további mezőket is használnak a projekthátralékban, főként azért, hogy segítsenek a terméktulajdonosnak prioritást adni a terméknek.

Főbb Scrum találkozók

A következő megbeszéléseket a Scrumban a rendszeresség, a fejlesztés ellenőrzésének elérése érdekében használják, és ezzel egyidejűleg minimalizálják a Scrumban előre nem definiált találkozók számát [20] .

Sprint tervezési értekezlet

Minden sprint elején tartják.

A sprint során elvégzendő munka teljes mennyiségét ezen az ülésen tervezik. A tervnek a Scrum Team minden tagjának munkájának kell lennie.

A találkozó időtartamát a sprint hossza, a csapat tapasztalata és egyéb tényezők határozzák meg, de nem haladhatja meg a 8 órát. Ezeket az idővonalakat a ScrumMaster figyeli.

A Sprint Planning Meeting választ ad a következő kérdésekre:

Az első kérdést közösen döntik el. A terméktulajdonos megbeszéli a sprint teljesítendő céljait, figyelembe véve a termékhátralékot, a korábbi terméknövekedést stb., új felhasználói történeteket ad a lemaradáshoz, és eltávolítja a teljesítetteket. A fejlesztőcsapat megpróbálja megjósolni a sprint során kifejlesztett funkciókat. Ezenkívül a Scrum Team minden tagjának közösen kell értenie és értékelnie kell a közelgő sprint összes munkáját.

A sprint megfelelő megtervezéséhez vegye figyelembe a következőket:

Csak a fejlesztőcsapat dolgozik a második kérdéssel. Mivel a sprint célt már meghatározták, a fejlesztőcsapatnak pontosan meg kell értenie, hogyan érhető el. Ők döntik el, hogyan valósítják meg a tervezett funkcionalitást annak érdekében, hogy sprintenként új késztermék-növekményt kapjanak.

A fejlesztőcsapat jellemzően a rendszertervezéssel és a sprint hátralék terméknövekményré alakításához szükséges munkával kezdi. A sprint első napjaira tervezett munka részletesebb, gyakran egynapos vagy rövidebb darabokra bontják a találkozó vége felé. A fejlesztő csapat önállóan szervezi meg a sprint hátralékban a munkát, mind a sprint tervezése során, mind a sprint során szükség szerint.

A Terméktulajdonos a fejlesztőcsapat véleményét figyelembe véve tisztázhatja a lemaradásból kiválasztott feladatokat-célokat, vagy kompromisszumos megoldást alkothat velük. Ha a fejlesztők úgy döntenek, hogy túl sok vagy túl kevés a munka, akkor a terméktulajdonossal együtt átgondolhatják a kiválasztott feladatokat-célokat. Ezenkívül a fejlesztőcsapat más szakértőket is felkérhet műszaki vagy tárgyi tanácsadásra.

A megbeszélés végén a fejlesztőcsapat elmagyarázza a terméktulajdonosnak és a Scrum Masternek, hogyan fognak önállóan dolgozni a sprintcélok elérése érdekében.

Daily Scrum meeting

Az ilyen megbeszéléseket a fejlesztőcsapat a terméktulajdonos és a Scrummaster esetleges részvételével minden nap ugyanott és ugyanabban az időben tart, legfeljebb 15 percig. Ezeken a megbeszéléseken a fejlesztőcsapat megtervezi a mai munkanap munkáját. Ezek a találkozók egyszerűsítik a csapatmunkát és növelik a termelékenységet azáltal, hogy áttekintik az előző Daily Scrum óta végzett munkát, és megtervezik az előttünk álló munkát.

Ezek a napi találkozók segítenek látni, hogyan halad a munka a sprint cél elérése felé. Növelik annak valószínűségét, hogy a fejlesztőcsapat teljesíti a kitűzött célokat. A megbeszélések során a fejlesztőcsapatnak meg kell értenie, hogyan kell összefognia a sprint céljainak elérése és a tervezett növekedés megvalósítása érdekében.

Az ilyen megbeszélések felépítését a fejlesztő csapat határozza meg, szükség esetén és adott esetben a megbeszélések szerkezete módosítható, miközben a fő hangsúlyt a sprint cél elérésére kell helyezni, azonban vannak kötelező szabályok:

A fejlesztőcsapat vagy csapattagok gyakran közvetlenül a Daily Scrum után találkoznak, hogy mélyebb megbeszéléseket folytassanak, vagy hogy személyre szabják vagy újratervezzék a munka hátralévő részét.

A Scrum Master garantálja ezeket a találkozókat, de a fejlesztőcsapat felelős a Daily Scrum lebonyolításáért. A Scrum Master arra is kiképzi a fejlesztőcsapatot, hogy a Daily Scrumot 15 percen belül tartsák, és gondoskodnia kell arról, hogy a megbeszélés ne szakadjon meg.

Az ilyen találkozók célja a csapatkommunikáció javítása, a további megbeszélések számának csökkentése, a jövőbeni kockázatok és nehézségek azonosítása, valamint a gyors döntéshozatal elősegítése.

Ez a fő eszköz a fejlesztőcsapat munkájának ellenőrzésére.

Sprint áttekintés

A sprint végén lefolytatják a terméknövekedés ellenőrzésére és szükség esetén a lemaradás módosítására. A sprint eredményeinek áttekintésében a Scrum Team és minden érintett részt vesz. Ennek az informális találkozónak és a növekmény bemutatásának célja a visszajelzések fogadása és az együttműködés fejlesztése.

A Sprint összefoglaló áttekintése a következő elemeket tartalmazza:

Az eredmény egy frissített lemaradás, amely meghatározza a következő sprintek céljait. A lemaradás egészében módosítható az új lehetőségekhez.

Retrospektív találkozó (Sprint Retrospective)

A retrospektív találkozó célja javaslatok kidolgozása a projekt megvalósítás folyamatának (eljárások, technikák, műveletek) javítására. Az elmúlt sprint retrospektív elemzése során a projekt megvalósítási folyamatának javítására a következő sprintre terv készül. A megbeszélésre a sprinteredmények áttekintése után kerül sor, a következő sprint megtervezése előtt, és nem tarthat tovább 3 óránál. Felügyeli a Scrum Master értekezlet előrehaladását.

A találkozó fő céljai:

A Scrum Master arra ösztönzi a csapatot, hogy tegyenek javaslatokat a fejlesztési folyamat hatékonyságának javítására. Minden egyes sprint retrospektív során a csapatnak meg kell keresnie és javasolnia kell a munkafolyamatok javításának módjait és eszközeit.

A sprint visszatekintésének végére a csapatnak azonosítania kell a fejlesztési javaslatokat a következő sprintben való megvalósításhoz. Bár az ilyen javaslatok bármikor megvalósíthatók, a sprint retrospektíva lehetőséget ad arra, hogy a csapat interakcióinak elemzésére és az aktuális feltételekhez való igazítására összpontosítsunk.

Sprint lemondása

A sprint törölhető, ha a sprint cél elavult. Csak a Terméktulajdonosnak van joga lemondani egy sprintet [21] .

További Scrum-találkozók

Lehet, hogy ezek a találkozók nem részei a teljes Scrum-munkafolyamatnak, de bizonyos helyzetekben mindenképpen megtörténnek. Akkor használatosak, ha több mint 7-11 fejlesztő van, vagyis több, mint a Scrum csapat ajánlott létszáma.

Scrum of Scrums

Ha a csapat több mint 11 fő, akkor a csapat nagyobb, mint az ajánlott Scrum méret. A Scrum of Scrum [22] a Scrum kiterjesztését javasolta .

Ezután a csapat több Scrum csapatra oszlik. Mindegyiknek megvan a saját Scrum mestere és terméktulajdonosa.

A csapatok Daily Scrumot folytatnak.

A napi Scrum találkozó után Scrum of Scrum (SoS [23] ) gyűlés következik. Ez a következőket jelenti. Minden csapatból kiválasztanak egy képviselőt. A képviselők 5-9 főre oszlanak. Minden csapathoz tartozik egy Chief Scrum Master [24] és egy Chief Scrum Product Owner [25] a projektben részt vevő Scrum mesterek és terméktulajdonosok közül. A különböző Scrum csapatok képviselőiből álló csapatot Scrum of Scrum Teamnek nevezik [26] . Ebben a kompozícióban a Scrum of Scrum (SoS) vagy a Meta Scrum vagy a Scaled Daily Scrum (SDS) 15 perces állógyűlését tartják [27] .

Ken Schwaber azt javasolja, hogy minden nap végezzen Scrum of Scrumot [28] .

Néhány Scrum of Scrum csapat azonban nem minden nap, hanem heti 2-3 alkalommal [28] . Ez sérti a Scrum alapelveit, és a ScrumBut klasszikus példája [29] [30] . Ez nem teszi lehetővé a Scrum [31] előnyeinek teljes kihasználását .

A Scrum of Scrum lehetővé teszi, hogy több Scrum Team megvitassa a munkát, a közös területekre és a kölcsönös integrációra összpontosítva. A Chief Scrum Master a Scrum of Scrum csapat minden tagjának négy kérdést tesz fel [28] , az első három kérdés megismétli a Daily Scrum kérdéseket:

A Scrum of Scrums módszertannal tovább növelheti a fejlesztők számát. Ha a Scrum of Scrum nem fedi le az egész csapatot, akkor egy Scrum of Scrum of Scrum (Scrum-3, SoSoS) [32] , Scrum of Scrum of Scrum of Scrum (Scrum-4, SoSoS [33] ) [34] találkozó is lehetséges. és így tovább [35] . A legújabb MetaScrum neve Executive Meta Scrum (EMS) [36] vagy Executive Action Team (EAT) [37] . Ez a megközelítés lehetővé teszi 4096 ember munkájának megszervezését mindössze egy óra alatt [34] .

A Scrum of Scrum sorrendje ugyanaz, mint a Daily Scrum [26] :

Hátralékos rendelés (Grooming)

A lemaradás úgy van megszervezve, hogy a fejlesztőcsapat és a terméktulajdonos [38] :

Egyéb Scrum Scaling Techniques

A klasszikus Scrum of Scrum (SoS) módszertanon kívül LeSS [39] [40] [41] [42] (2-8 csapat), Nexus [43] , RAGE [44] , DAD [45] , APM [46 ] ] [47] , SAFe [48] . Nagyon nagy projekteknél a LeSS Huge [40] (8+ parancs) használatos a LeSS helyett . Csak a SoS [49] és a Nexus [50] módszereket fejlesztette ki Sutherland és Schwaber [40] , és ezeket a CSM és PSM tanúsítási tanfolyamokon tanítják.

Scrum képzés és minősítés

A Scrumban a képzett Scrum mester, a Scrum terméktulajdonos és a Scrum csapat döntő szerepet játszik. A Scrum alapítói és okleveles oktatói (CST®) képzéseket biztosítanak a Scrum-szakemberek minősítésére. Mindenki számára kötelező alap a Scrum Master képességei. Ezután következik a Scrum mester, Scrum terméktulajdonos és Scrum fejlesztő (a Scrum csapat tagja) specializáció. A sikeres vizsgát végzők tanúsítványt kapnak: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Professional Scrum Developer (PSD™). Azok, akik tovább kívánják fejleszteni a Scrum ismereteit és készségeit, a Scrum ALLIANCE CSM, CSPO alaptanfolyamai és a rajtuk való sikeres vizsga után, akik legalább 1 éves tapasztalattal rendelkeznek a Scrum szerepkörben, Advanced Certified Scrum Master (A -CSM), Advanced Certified Scrum terméktulajdonos, Advanced Certified Scrum Developer [51] . A fejlesztők számára külön kurzuskészlet áll rendelkezésre a TDD -hez , DevOps -hoz stb. [52] . Azok vehetnek részt CSP®-SM, CSP®, akik elvégezték a CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD tanfolyamokat és sikeresen vizsgáztak, és legalább 3 éves tapasztalattal rendelkeznek a megfelelő Scrum szerepkörben. -PO tanfolyamok, CSP-D® [53] . A scrum.org minősítés részeként a tanfolyamoknak is több szintje van: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

A továbbképzés Scrum oktatói bizonyítvány – Certified Scrum Trainer (CST®) vagy Professional Scrum Trainer (PST™) – kiállításával lehetséges.

A CST-tanúsítvány megszerzésére CSP-SM vagy CSP-PO vagy CSP-D tanúsítvánnyal és legalább 5 év releváns Scrum-szerepkörben szerzett tapasztalattal rendelkező személyek jelentkezhetnek [55] .

A PST minősítés elismeri a Scrum Master Trainereket (PSSMT), a Product Owner Trainereket (PSPOT) és a Development Team Trainereket (PSDT) [56] [57] [58] . A Train-the-Trainer (TTT) felvételéhez és minősítéséhez:

A Scrum minősítés két évig érvényes. Ezalatt a két év alatt a tanúsítvány következő két évre történő megújításához bizonyos számú Scrum Education Unit (SEU®) felvételére van szükség [59] . A Scrum Oktatási egységeket a Scrum tanfolyamok elvégzéséért, a Global Scrum Gathering℠ [60] és a Regional Scrum Gathering℠ [61] rendezvényeken való részvételért, a Scrum oktatásáért és más, a Scrum készségeinek fejlesztését célzó tevékenységekért [59] díjazzák . Egy ilyen rendszer azt mutatja, hogy a Scrum tudásod naprakész, és mindig készen állsz alkalmazni és átadni másoknak. Ez nagymértékben növeli a Scrum tanúsítvány értékét. A Scrum oktatási egységeket a következők szerint ítélik oda: 1 óra Scrum képzés (részvétel gyűjtésen, tanításon, webináriumon való részvétel stb.) 1 SEU®. A tanúsítvány megújításához:

Több tanúsítvány esetén a megújításhoz szükséges SEU® számát egy speciális kalkulátor segítségével számítjuk ki: [62] .

Nem éppen Scrum

Scrumbut

A ScrumBut a Scrum elveinek csak egy részét használja, miközben fenntartja azt a meggyőződést, hogy a Scrum-on kell dolgozni [29] [30] . Ez nem csak abban akadályozza meg, hogy teljes mértékben kihasználja a Scrum előnyeit [29] , hanem a teljesítményt is rontja a módszertan teljes hiányához képest.

Tanulmányok kimutatták, hogy a ScrumBut az éves nyereséget 400%-ról 0-35%-ra csökkenti [31] . Ugyanakkor a munka termelékenységét a „vízesés” szerint 100%-nak, a Scrum szerint pedig 400%-nak vették. A ScrumBut okairól és következményeiről egy nagy tanulmányt végeznek a "ScrumBut in Professional Software Development" [63] című munkában .

A ScrumBut klasszikus példái [29] :

Számos ScrumBut-példa található a Scrum Alliance webhelyén, a Scrum ALLIANCE®-on [64] .

Scrum And

A Scrum mellett vegye figyelembe a ScrumAnd-ot is [65] . A ScrumAnd a Scrum és más bevált módszereket használja. Azonban nehéz lehet megkülönböztetni a ScrumBut a ScrumAndtól [66] . Például felteszik a kérdést: 6 hónapos sprintünk van, ScrumBut vagy ScrumAnd? A [66] szerzői ezt egyértelműen a ScrumButnak tulajdonítják, és módszert adnak a ScrumBut és a ScrumAnd megkülönböztetésére. Emlékeztetni kell arra, hogy a Scrum módszertana önellátó, és mind a ScrumBut, mind a ScrumAnd az üzleti alkalmazásfejlesztési folyamat hatékonyságának csökkenéséhez vezet. [67] .

Jegyzetek

  1. ↑ "scrum" angol-orosz fordítás . lingvo.abbyyonline.com. Letöltve: 2016. május 4.
  2. ↑ Schwaber Ken, Sutherland Jeff. Scrum Guide (2020. november).
  3. ↑ Archivált másolat . Letöltve: 2018. október 19. Az eredetiből archiválva : 2018. október 20.
  4. ↑ A SCRUM módszer 1 2 5 kulcsfontosságú eszköze (2017. április 27.). Letöltve: 2018. október 21. Az eredetiből archiválva : 2019. október 2.
  5. ↑ Agilis – agilis megközelítés a projektmenedzsmenthez (2016. november 4.). Letöltve: 2018. október 21. Az eredetiből archiválva : 2019. október 3.
  6. ↑ 1 2 3 4 Jeff Sutherland. DULAKODÁS. Forradalmi projektmenedzsment módszer = SCRUM. Az a művészet, hogy feleannyi idő alatt kétszer annyi munkát végezzünk. - Mann, Ivanov és Ferber, 2016. - 288 p. - ISBN 978-5-00057-722-6 .
  7. ↑ Leslie Hulet Stahl: Gonosz problémák, igazságos megoldások: Modern mérnöki paradigmák katalógusa Yourdon Press Computing Series, 1990 (első kiadás), ISBN 0-13-590126-X
  8. ↑ OOPSLA 2006 . Hozzáférés dátuma: 2010. január 26. Az eredetiből archiválva : 2010. június 25.
  9. ↑ Schwaber, Ken; Beedle, Mike. Agilis szoftverfejlesztés Scrum segítségével  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
  10. ↑ Maximini, Dominic. A Scrum kultúra: Agilis módszerek bevezetése a szervezetekben. Menedzsment szakembereknek  // Cham: Springer. - 2015. január 8. Letöltve: 2016. augusztus 25. .. - 26. o . — ISSN 9783319118277 .
  11. ↑ Partogi, Joshua. Minősített Scrum Master vs Professional Scrum Master // Lean Agile Institute. — 2013. július 7. Letöltve: 2017. május 10.
  12. ↑ Ken Schwaber; Jeff Sutherland. A Scrum útmutató. — Scrum.org, Letöltve: 2017. október 27.
  13. ↑ A Scrum.org bemutatja a Scrum with Kanban Course-t, amely nagyobb átláthatóságot tesz lehetővé a fejlesztőcsapatok között (letöltve: 2018. március 2.). Letöltve: 2019. május 22. Az eredetiből archiválva : 2018. november 18.
  14. ↑ Sprint - bunkó; dobás; Sprint.
  15. ↑ Ken Schwaber. Agilis projektmenedzsment a Scrum segítségével . - Microsoft Press, 2004. - 163 p. — ISBN 073561993X .
  16. ↑ Vizuális projekt- és csapatmenedzsment @ Kaiten . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. január 22.
  17. ↑ Mi az a Scrum-Agile kezdőknek ? Letöltve: 2018. október 20. Az eredetiből archiválva : 2018. október 21..
  18. ↑ Csirke és sertés . Letöltve: 2019. július 23. Az eredetiből archiválva : 2017. január 23.
  19. ↑ Elfogadási kritériumok agilis követelményekhez . Devprom ALM. Letöltve: 2016. április 3. Az eredetiből archiválva : 2016. április 1..
  20. ↑ Scrum Guide | Scrum útmutatók . scrumguides.org. Letöltve: 2020. június 3. Az eredetiből archiválva : 2020. június 16.
  21. ↑ Archivált másolat . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. január 14.
  22. ↑ (PDF) Scrum of Scrums megoldás nagy méretű csapatoknak Scrum módszertan használatával . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  23. ↑ Scrum of Scrum (SoS) definíció | innováció . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  24. ↑ A vezető scrum mester szerepe | SCRUMstudy Blog . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 25.
  25. ↑ Entava . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  26. ↑ 1 2 A Scrum of Scrum találkozója – Kiáltvány . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  27. ↑ Jeff Sutherland elindítja a Scrum@Scale Guide | Henny Portman blogja . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  28. ↑ 1 2 3 Scrum Alliance-tagok által benyújtott tájékoztató cikkek (hivatkozás nem érhető el) . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21.. 
  29. ↑ 1 2 3 4 Mi az a ScrumBut? | Scrum.org . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  30. ↑ 1 2 ITKaiZenClub "Scrum, de..." vagy tipikus problémák a Scrum bevezetésekor, február 8. | DOU
  31. ↑ 1 2 (PDF) Scrum+:: „ScrumBut” vagy „ScrumAnd” ? Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  32. ↑ A Scrum Team és a Scrum of Scrum . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  33. ↑ Agilis szervezet a Scrum@Scale segítségével, a Vimar Spa igazi példa
  34. ↑ 1 2 Agilis katonai hardver. Hogyan lett a SAAB Gripen a világ legköltséghatékonyabb katonai repülőgépe Archiválva : 2018. október 20., a Wayback Machine / Sutherland és Joe Justice , 2017 
  35. ↑ Scaling Agile Series 2. rész: Négy népszerű Agile Scaling Framework-ből kettő: SoS és LeSS – Gorilla Logic . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  36. ↑ Az ügyvezető MetaScrum | AgileGenesis . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. április 18..
  37. ↑ Vezetői akciócsoport – Scrum Inc. Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. február 28..
  38. ↑ "A proaktív üzlet hátralékos fésűs blogját keresem (hivatkozás nem elérhető) . Hozzáférés dátuma: 2018. december 8. Archiválva : 2018. december 27. 
  39. ↑ Nagyszabású Scrum (kevesebb) - Alekszej Krivitszkij - Agilis edző és Scrum edző . Letöltve: 2018. november 2. Az eredetiből archiválva : 2018. november 4..
  40. ↑ 1 2 3 Hogyan skálázható az Agilis? | nyílt rendszerek. DBMS | Kiadó "Nyílt rendszerek" . Letöltve: 2018. november 2. Az eredetiből archiválva : 2018. november 4..
  41. ↑ A LeSS – Large Scale Scrum (LeSS) bemutatása . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5..
  42. ↑ KEVESEBB - Scrum at scale - ScrumTrek Blog . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5..
  43. ↑ A Nexus útmutató | Scrum.org . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5..
  44. ↑ Düh | Scaled Agile Transformations | folyamat | cPrime . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 4..
  45. ↑ Archivált másolat (a hivatkozás nem elérhető) . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5.. 
  46. ↑ Agilis projektmenedzsment - mit és miért | APM . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5..
  47. ↑ Agilis projektmenedzsment a Scrum segítségével . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5..
  48. ↑ Archivált másolat (a hivatkozás nem elérhető) . Letöltve: 2018. november 4. Az eredetiből archiválva : 2018. november 5.. 
  49. ↑ Scrum of Scrum | Scrum.org . Letöltve: 2018. november 2. Az eredetiből archiválva : 2018. november 4..
  50. ↑ A Nexus útmutató | Scrum.org . Letöltve: 2018. november 2. Az eredetiből archiválva : 2018. november 5..
  51. ↑ Advanced Certified ScrumMaster (A-CSM℠) tanúsítvány . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. március 17.
  52. ↑ Tanfolyamkeresés – Scrum Szövetség
  53. ↑ Minősített Scrum Professional ScrumMaster® (CSP-SM) minősítő tanfolyam . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. március 17.
  54. ↑ Scrum Master tanúsítvány a Scrum otthonából . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. március 3.
  55. ↑ Certified Scrum Trainer (CST) tanúsítás jelentkezési folyamata . Letöltve: 2018. október 19. Az eredetiből archiválva : 2018. október 20.
  56. ↑ PSD oktató kiválasztási folyamat és jelentkezés | Scrum.org . Letöltve: 2018. október 19. Az eredetiből archiválva : 2018. október 20.
  57. ↑ PSPO oktató kiválasztási folyamat és jelentkezés | Scrum.org . Letöltve: 2018. október 19. Az eredetiből archiválva : 2018. október 20.
  58. ↑ PSM oktató kiválasztási folyamat és jelentkezés | Scrum.org . Letöltve: 2018. október 19. Az eredetiből archiválva : 2018. október 20.
  59. ↑ 1 2 Scrum Education Units® (SEU®) képzési kredit . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. április 20.
  60. ↑ Globális Scrum Gathering események információi és szponzorálás . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. március 4.
  61. ↑ Scrum Alliance regionális Scrum összejövetelek . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. január 28..
  62. ↑ Agilis és Scrum képzés és minősítés | Scrum Szövetség . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. április 21.
  63. ↑ Archivált másolat . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  64. ↑ Scrum Alliance-tagok által benyújtott tájékoztató cikkek (a hivatkozás nem elérhető) . Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21.. 
  65. ↑ A "ScrumAnd" álláspont (gondolkodást és fegyelmet igényel) | Scrum.org . Letöltve: 2021. március 15. Az eredetiből archiválva : 2021. április 14.
  66. ↑ 1 2 (PDF) Scrum+:: „ScrumBut” vagy „ScrumAnd” ? Letöltve: 2018. október 21. Az eredetiből archiválva : 2018. október 21..
  67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Lásd még

Linkek

Irodalom

  Ugrás a Wikidata elemre  Bibliográfiai katalógusokban