A Scrum egy komplex termékek fejlesztésének kerete vagy kerete. Alkotói " iteratív holisztikus keretként határozzák meg, amely a közös célokra összpontosít, a lehető legmagasabb értékű termékek produktív és kreatív szállítása révén". A Scrum olyan gyakorlatok csoportjának számít, amelyek többnyire megfelelnek az Agilis kiáltvány ajánlásainak .
Scrum alapul körzet egy projektet „ idő dobozok ”, az úgynevezett gyorsul ( „speed tüskék”). A sprintek néhány órától egy hónapig tarthatnak ( két hét alatt egy sprint mediánnal). Minden sprint egy becsléssel kezdődik, amelyet az operatív tervezés követ. A sprint a befejezettek bemutatásával zárul. Új sprint megkezdése előtt a csapat visszamenőleges képet végez. Ez a technika elemzi az elkészült sprint előrehaladását annak gyakorlata javítása érdekében. A fejlesztői csapat munkafolyamatát önszerveződésük segíti , így nem lesz projektmenedzser.
Hibrid szoftverfejlesztési keretrendszerek létrehozása, amelyek összekapcsolják a Scrumot és más keretrendszereket, mivel a Scrum nem terjed ki a termékfejlesztési ciklusra. Például felhasználhatjuk az extrém programozás gyakorlatait , a RAD módszer strukturált felépítési szakaszától kezdve , vagy a projekt csapat tapasztalatai alapján egy sor szoftverminőségi gyakorlatot.
A Scrum-ot különböző területeken használják, például szoftverekben, repülésben vagy építőiparban.
A scrum metaforája (a „ rögbi- scrum ”) 1986-ban jelent meg először Hirotaka Takeuchi és Ikujiro Nonaka kiadványában , amely az akkori ipari világra érvényes The New New Product Development Game címet viselte . Rögbi megközelítés néven egy új holisztikus módszert írnak le, amely növeli az új szoftvertermékek fejlesztésének sebességét és rugalmasságát. Az egész fejlesztést iteratívan végzi egy multidiszciplináris csoport, amely különböző fázisokon megy keresztül, és a fázisok és az iterációk erősen átfedhetnek. Összehasonlították ezt az új módszert a rögbi szakszervezettel , ahol a csapat tagjai végig megpróbálnak haladni, blokkolni, átadni és átadni a labdát.
A 1995 , Ken Schwaber bemutatott egy papírt leírja az alapjait, mi lesz a Scrum módszerrel OOPSLA . Ő majd bemutatni elveinek Scrum részletesebben a cikk Controlled Chaos: Living on the Edge a 1996 .
A 2002 , Ken Schwaber összeállt Mike Bogar leírni a módszer a könyvben Agile Software Development With Scrum .
A 2010 , Jeff Sutherland és Ken Schwaber ismertetett elvek módszer a Scrum Guide . Az utolsó frissítés 2020-ra nyúlik vissza.
A Scrum egy empirikus folyamat, amely három pilléren nyugszik: az átláthatóságon, az ellenőrzésen és az alkalmazkodáson. Az agilis kultúra elveit is követi . A Scrum hangsúlyozza a termékkel kapcsolatos összes szereplő közötti közös nyelv használatát. Ennek a közös nyelvnek lehetővé kell tennie, hogy bármely megfigyelő gyorsan megismerje a projektet és annak előrehaladásának állapotát. Rendszeres időközönként a Scrum felajánlja, hogy számba veszi a különféle előállított műtárgyakat a nem kívánt változások észlelése érdekében. Ha bármilyen eltérést észlelnek az ellenőrzés során, akkor a folyamatot ki kell igazítani. A Scrum „eseményeket” biztosít, amelyek során ez az adaptáció lehetséges. Ezek a sprinttervezési értekezlet , a napi teszt, a sprint- áttekintés, valamint a sprint retrospektív .
A Scrum azon a meggyőződésen alapul, hogy a szoftverfejlesztés olyan tevékenység, amely természeténél fogva nem determinisztikus, és hogy egy komplex projekt megvalósításában részt vevő összes tevékenységet nem lehet előre látni és tervezni. A Scrum itt áll szemben a prediktív megközelítésekkel, például az V ciklussal . Ennek a kiszámíthatatlanságnak a megválaszolására a Scrum módszer empirizmuson alapuló folyamatszabályozási modellt kínál, a valós üzleti körülményekhez való folyamatos alkalmazkodás és a változásokra való gyors reagálás révén. A sprint retrospektívák végén bekövetkezett tényleges aktivitási viszonyok elemzését és az ebből adódó folyamatos fejlesztési tervet rendszeres időközönként végezzük, ami inkrementális fejlődési ciklust eredményez ( Sprint ).
A Scrumot szoftverfejlesztési projektek során tervezték. A karbantartó csapatok is használhatják. Abban az esetben nagyon nagy projektek, a csapatok többszörösen, és mi majd beszélhetünk nagyszabású dulakodás ( pl: a dulakodás a scrums vagy KEVESEBB ).
A termék- és iterációs naplók karbantartásán kívül a referencia-dokumentációban nincsenek olyan folyamatelemek, amelyek egy adott eszköz használatát igényelnék. A Scrummal végzett agilis projektmenedzsmentben Ken Schwaber példát hoz a táblázatban vezetett termék- és iterációs könyvekre, amelyek lehetővé teszik a leégési diagramok („előrehaladási diagramok”) kiszámítását is . A leégési diagramokat csak a Scrum Guide idézi, és nem kötelező gyakorlat.
A kifejezés petyhüdt dulakodás használják Martin Fowler a 2009 azonosítani a hibás dulakodás gyakorlatot, ahol a szoftver minőségét elhanyagolt, és a kifejlesztett termék halmozódik technikai adósság . Fowler azt mondja, hogy bár Scrum nem írja le, hogy mit technikák gyakorlati életbe, az eljárás nem ösztönzi hiányában az ilyen gyakorlatok és scrummer s élenjáró mindig ragaszkodott a hatékony technikákat gyakorlatokat. Fowler megemlíti, hogy az extrém programozás technikai gyakorlatai jó kiindulópontot jelentenek a Scrum csapatai számára, és jobbak, mint a semmilyen gyakorlat. A 2014 Fowler úgy véli, hogy a probléma továbbra is fennáll, és arra ösztönzi a felhasználókat a Scrum és agilis módszerek általában, hogy legyen óvatos a hatásos műszaki gyakorlatot.
Nem ritka, hogy a scrum mester álruhás vagy hivatalos projektmenedzser, és túl szigorú ellenőrzést alkalmaz a csapattagjai felett. A következmények ebben az esetben heves viták vagy többé-kevésbé tartós konfliktusok formájában jelentkezhetnek a csapattagok között. Néha megfigyelhetjük, éppen ellenkezőleg, a napi találkozás másfajta megközelítését is: kimondatlan vagy homályos megjegyzések a felmerült problémákkal kapcsolatban. Így az értekezleteket udvariasabban lehet lebonyolítani, de fennáll annak a kockázata, hogy nehézség esetén a továbbiakban nem kérjük a csapat támogatását. Ami éppen a Scrum alapelveivel ütközik.
Egyszerűen arról van szó, hogy egy V ciklusú projekt megvalósításának szakaszát a Scrum követésével kell végrehajtani. Ennek következménye, hogy bezárjuk a Scrum-ot egy folyamatba, ahol a kerület rögzítve van, és az érték (irányítás) szerinti menedzsmentről a terv szerinti irányításra kell lépnünk (ciklus V-ben).