Az elmúlt négy évben három különböző projektben használtam a SCRUM-ot. Úgy tűnik, hogy a SCRUM egyik előnye a rugalmassága és alkalmazkodóképessége, például a változó vásárlói igényekhez igazodva. További előny, hogy a menedzsment könnyen nyomon tudja követni a projekt előrehaladását.
A SCRUM rugalmassága előny lehet például egy webalkalmazás megvalósításakor, ahol a követelmények nagyon gyorsan változnak, és az ügyfelek valóban megértik, mit akarnak, miután meglátták a prototípust.
Másrészt vannak másfajta szoftverprojektek is (pl. az űrkutatásban) ipar), ahol a követelmények meglehetősen rögzítettek: kap egy követelményspecifikációs dokumentumot, és hat hónappal később vissza kell térnie működő szoftverrel és teljes dokumentációval. Az ilyen típusú projektekhez kétlem, hogy szükség van-e a SCRUM által kínált rugalmasságra (bizonyos értelemben hogy nem kell prototípusokat készítenie és megmutatnia az ügyfélnek, hogy visszajelzést kapjon a követelményekről): inkább nagyon strukturált és szisztematikus megközelítésre van szüksége, amelyet valószínűleg minden projekt esetében újra és újra megismételnek, kevés a meglepetés.
Tehát a SCRUM támogatói általános célú szoftverfejlesztési módszertannak tekintik-e, vagy különösen alkalmasak-e bizonyos kategóriájú projektekre vagy alkalmazási területekre?
Például nemrégiben megnéztem egy repülőgépipar számára szoftvereket gyártó vállalat weboldalát, és észrevettem, hogy ők a V-modellt használják. Azt mondaná egy SCRUM szószóló, hogy az SCRUM kevésbé alkalmas ilyen típusú projektekre, vagy inkább azt javasolja, hogy ennek a vállalatnak próbálkozzon a SCRUM-ra való áttéréssel?
Megjegyzés hogy nem kérem a fórum olvasóinak véleményét, de szeretném tudni, mi a kialakult vélemény a SCRUM javaslattevői körében: a SCRUM általános célúnak tekinthető-e, vagy inkább alkalmas bizonyos osztályok számára csak a projektek közül? Utóbbi esetekben, milyen típusú projektek esetén?
Megjegyzések
- Lásd: stackoverflow.com / questions / 596916 / mikor-nem-kell-buknod és eweek.com/c/a/IT-Management/…
- Hogy ” kapjon egy követelményspecifikációs dokumentumot, és hat hónappal később vissza kell térnie működő szoftverrel ” dolog mítosz. Még akkor is, amikor valami formálisan meghatározott nyelvhez fordítót készít (ahol a funkcionális követelmények valóban egyértelműek és rögzítettek), el kell döntenie és rangsorolnia kell a megvalósítandó dolgokat, vannak nem funkcionális követelmények, amelyeket meg kell vitatni a felhasználóval , és több fokú szabadsága van, mert az egyiknek el kell döntenie a dolgok megoldását. Tehát az agilis megközelítésnek még az ilyen típusú projektek esetében is van értelme.
- ” Tehát az agilis megközelítésnek még az ilyen típusú projektek esetében is van értelme. “: Míg az agilis lehet rugalmasabb, addig más módszerek is rugalmasak. Lehetséges, hogy más módszerek elég rugalmasak, és az agilisek túl rugalmasak bizonyos projektek esetében. Csak ötleteljen itt.
- ” Ez ” kap egy követelményspecifikációs dokumentumot, és hat hónappal később vissza kell térnie. működő szoftverrel a ” dolog mítosz. “: Nem gondolom, hogy ‘ . Bár gyorsan megváltoztathatja egy weboldal címkéjének címkéjét, mert az ügyfelek meggondolták magukat, miután megnézték, nem lehet olyan egyszerűen megváltoztatni a repülőgép mozgó részét vezérlő repülési szoftver kritikus részét. Lehet, hogy késői változtatásokra lesz szükség, de kíváncsi vagyok, hogy egy agilis módszer a megfelelő-e a kezelésükre, vagy szükség van-e egy másik módszer (pl. A V-modell) összetettebb ismétlésére.
Válasz
A SCRUM egy általános célú módszertan, amely jól használható a legtöbb projektnél és csapatméretnél, de kevésbé hasznos nagy csapatok számára, amelyek nagyon nagyokat végeznek projektek. Az egyes projektekben részt vevő emberek puszta száma bármely agilis módszertant rendkívül nehézzé teszik szinte lehetetlenné, mert a rend megőrzéséhez merevebb struktúrára van szükség. A repülőgépipar jó példa egy olyan iparágra, amelynek olyan hatalmas projektjei vannak, ahol az agilis megközelítés nem mindig megvalósítható.
Megjegyzések
- bármilyen információ arról, hogy egy projektet túl nagynak tartanak-e ahhoz, hogy SCRUM-tal együtt lehessen végrehajtani? Gondoljon például egy 18 hónapos projektre egy 15 fős csapat számára: profitálna-e egy ilyen csapat az SCRUM-ból, vagy megfelelő lenne-e egy másik modell is, például a V-modell Azért kérdezem, hogy 18 hónapon keresztül a követelményeknek és a megvalósításnak elegendő ideje van az érésre és stabilizálódásra, és talán nincs is igazán szükség a SCRUM által nyújtott rugalmasságra.Inkább egy közép- és hosszú távú megközelítés alkalmas itt. Van erről valamilyen szakirodalom?
- @Giorgio projektidő nem számít ‘, de 15 ember elegendő ahhoz, hogy hasznot húzna többszörös scrum készítéséből csoportok, de még mindig a SCRUM kezelhető tartományában van. amikor a kommunikáció menedzsmentje teljes munkaidős munkává válik csapata számára, itt az ideje elkezdeni egy V-modellt nézni
- Komolyan gondolja? Korábban V-modellt használtunk, és átálltunk a SCRUM-ra. Valójában az az érzésünk, hogy ‘ lassabban haladtunk éppen ezért: túl sok könyvelés.
- @Giorgio, amely minden váltásra igaz lenne, te Eleinte lassabban fog érezni magát, mert az új, a Pierre 303-hoz hasonlóan azt mondta, hogy jobb ötletet kap néhány sprint után.
- @Giorgio – ez ‘ igaz, sok ” mozgékony ” módszertan nehezebb, mint azok a nehéz folyamatok, amelyeket ‘ feltételeznek cserélni! Ez nyilván azt jelenti, hogy ‘ tévednek – állítólag az agilis könnyű és szabad, és a kívülállók számára kaotikusnak tűnik. Ez azt jelenti, hogy a csapatának nagyon szervezettnek és fegyelmezettnek kell lennie, de ez ‘ általában előny. Próbáld inkább az Alistair Cockburn (az Agile egyik alapítója) Crystalját.
Válasz
Bármilyen típusú projekt ! Jól működik nagy és kis projekteknél is.
Az emberek esküvők, házak stb. Tervezéséhez használták. Tehát még csak nem is szoftverprojektek.
Én szilárdan hiszem, hogy sok olyan üzleti művelet létezik, amelyek számára előnyös lehet a Scrum-szerű megközelítés.
Hozzászólások
- Saját véleményt osztanak meg a SCRUM javaslattevői, azaz olyan szerzők, akik kodifikálták és népszerűsítették a SCRUM-ot?
- Igen – ezt nemrég mondta Cheryl Hammond ( blog.bsktcase.com ), ALM-tanácsadó Northwest Cadence-szel egy beszélgetésen, amelyet ” címmel tartott A Scrum Masters Day In The Life: The New Visual Studio “. Itt nézheti meg: msevents.microsoft.com/CUI/…
Válasz
Felhívjuk figyelmét, hogy a Scrum nem módszertan, hanem keret.
A Scrum fog a legjobban működni a c ross-funkcionális csapat 5 – 9 fejlesztőtől id = “f0778fd50c”>
közepes vagy nagy méretű projekt (4 hónaptól több évig). Ha a projekt nagyobb, a Scrums of Scrums segítségével méretezhet.
A keresztfunkcionális dolgot itt nem tárgyalom, hanem itt ezeket mondja el a hivatalos Scrum Guide a csapat méretére vonatkozóan:
Optimális fejlődés A csapat mérete elég kicsi ahhoz, hogy fürge maradjon, és elég nagy ahhoz, hogy jelentős munkát végezzen. Háromnál kevesebb fejlesztői csoport tagja csökkenti az interakciót, és kisebb termelékenységnövekedést eredményez. A kisebb fejlesztői csapatok a sprint során szaktudásbeli korlátokkal szembesülhetnek, ami azt eredményezheti, hogy a fejlesztői csapat képtelen leadni egy potenciálisan felszabadítható növekményt. A több mint kilenc tagú tagság túl sok koordinációt igényel. A nagy fejlesztői csapatok túlságosan összetettséget generálnak egy empirikus folyamat kezeléséhez. A terméktulajdonos és a Scrum Master szerepkörök nem szerepelnek ebben a számban, kivéve, ha ők is végrehajtják a Sprint Backlog munkáját.
Egy sprint körülbelül egy hónap.
A sprintek száma egy naptári hónapra korlátozódik. Ha egy Sprint horizontja túl hosszú, akkor az épülő definíciója megváltozhat, bonyolultsága és kockázata nőhet. A sprintek lehetővé teszik a kiszámíthatóságot azáltal, hogy legalább minden naptári hónapban biztosítják a cél elérésének előrehaladásának ellenőrzését és alkalmazását. A sprintek a költségeket egy naptári hónapra korlátozzák.
Szerintem nincs értelme iteratív folyamaton alapuló keretrendszert használni kisebb projektekkel mint 4 hónap. 4 hónap = 4 sprint. Arra is gondolnia kell, hogy 3 sprint után pontosabb sebességet ér el.
Ez azt mondta , Én személy szerint a Scrum korlátozott változatát használom kisebb projekteknél. De akkor nem igazán nevezheted Scrumnak. Ebben a konkrét esetben a Scrum néhány alapelvét használja a keretrendszer saját megvalósításában.
Válasz
kezdőknek , úgy gondolja, hogy a SCRUM csak egy iránymutatás az agilis gyakorlatok megvalósításához. Soha ne gondolja úgy, hogy “szent könyv” a projektek végrehajtásáról. Sok olyan projekt esetében, ahol a feladatok folyamatos áramlása szükséges, a Kanbam megfelelőbb például.
Az agilis projektek általában ott esnek le, ahol olyan projekteket végez, amelyek rögzített befejezési dátumot vagy fix költséget igényelnek. Bár ezeket a projekteket továbbra is agilis módszerekkel hajthatja végre, mindent előre meg kell tervezni. annak megállapítása, hogy valószínűleg eltalálja-e a célt, nem a szokásos mozgékony mód – agilis esetben hajlamos vagy folytatni a munkát addig, amíg el nem fogy a tennivalód, vagy elfogy az idő a teljesítésre. A legtöbb projekt esetében ez rendben van mivel a követelmények egyébként is változnak a projekt során.
Megjegyzések
- Csapatunkban mozgékonyak vagyunk, ha hagyjuk, hogy az ügyfél prioritást állítson a történetekhez. (a legfontosabbtól a legkevésbé fontosig) a pókerkártyák segítségével becsüljük meg a felhasználói történeteket, és annyi történetet tervezünk meg, amennyit megvalósíthatunk a holtpontig. Ha gyorsabbnak bizonyulunk, több történetet ütemezünk, annak megfelelően, hogy mi következik a prioritási listán.
- Néhány hónap múlva újra elolvastam a válaszát, és ez valóban felvilágosító. +1