Alapadatok
Év, oldalszám:2008, 14 oldal
Nyelv:magyar
Letöltések száma:27
Feltöltve:2019. szeptember 21.
Méret:898 KB
Intézmény:
-
Megjegyzés:
Csatolmány:-
Letöltés PDF-ben:Kérlek jelentkezz be!
Értékelések
Nincs még értékelés. Legyél Te az első!Legnépszerűbb doksik ebben a kategóriában
Tartalmi kivonat
Információs rendszerek tervezése – hallgatói prezentáció Tartalom Agilis szoftverfejlesztés és Scrum Projektmenedzsment alapvetı ismertetése Klasszikus modellek ismétlése, hátrányai Agilis projektvezetés Scrum Esettanulmány Készítette: Miskolc, 2008.1015 Sereg Ákos Varga Balázs Projektmenedzsment Projektmenedzsment Korlátok / tényezık felmérése (projektenként változó kritériumok, különbözı súlyokkal) - tradícionálisan: Idı (time) Pénz (cost) Hatókör (scope) Erıforrás (resource) Teljesítmény Minıség 3 Eredményességi mérce (Költségek, bevételek, tartalmak, idıbeli ütemezés betartása) Célja: Feladatok, erıforrások, határidık szervezése / összehangolása 4 Projektmenedzsment - korlátok Pénz, Idı: Egyértelmő Hatókör: Megvalósítandó funkcionalitás Amennyiben bıvül, változik a ktség/határidı
Projekttıl függıen egyéb korlátok, amiket figyelembe kell venni Adott Idı- és Költségkereten belül sikeresen teljesüljenek a projekt céljai Projektmenedzsment háromszög 5 6 Projektmenedzsment az informatikában Projektmenedzsment háromszög Irányítás: A P.M Háromszög egyensúlyban tartása Egyre összetettebb, jobb minıségő sw.-ek igénye a piacon Ha bármelyik sarok irányába billen, a másik kettı hangsúlyozásával visszaállítható Több idıt igényel a fejlesztési tevékenység koordinálása Példa Határidı veszélybe kerül Erıforrások átcsoportosításával / Pótlólagos erıforrások bevonásával Versenyhelyzet: állandó nyomás a fejlesztıcégeken hatékony módszer szükséges a fejlesztés menedzsmentjéhez az egyensúly helyre billenthetı! 7 8 Projektmenedzsment az informatikában Projektmenedzsment az informatikában Klasszikus sw fejlesztési modellek
nem optimális hatékonyságúak (késıbb részletezve) Versenyképesség megtartása + piaci igények kielégítése Gyakori problémák A megrendelı az esetek többségében nem tudja pontosan, mit akar Igények megváltozása a fejlesztés során Fejlesztési modellnek rugalmasnak kell lennie! Szükségessé vált újabb, hatékonyabb sw fejlesztési modellre 9 Tradicionális modellek áttekintése Vízesés modell Inkrementális (iteratív) modell Spirál modell „Cleanroom” modell RAD modell RUP modell 10 Vízesés modell Requirements Design Implementation Verification Maintenance 11 12 Vízesés modell Inkrementális (iteratív) modell Jellemzık Egymás után következı elhatárolt, de összefüggı fázisok (általában 5) Követelményanalízis és definíció (requirements) Rendszer- és szoftvertervezés (design) Implementáció, részegységek
tesztelése (impl.) Részegységek tesztelése, rendszer tesztelés (verification) Mőködtetés, karbantartás (maintenance) Hátrány Már a korai szakaszokban komoly döntéseket kell hozni (rugalmatlan) 1 Alternatívák értékelése Kockázatelemzés 4 Célszerőbb a nagy szoftverek fejlesztésénél Rugalmasabb a vízesés modellnél Elsı lépésben egy-egy kisebb probléma megoldása a cél Al-változatok egymásutánija Prototípus változat: UI (félreértések elkerülése) Gyors visszacsatolás Hátrány A folyamatos változások odavezetnek, hogy a rendszer rosszul strukturált lesz Fejlıdés mérése nehézkes 14 Spirál modell 2 Értékelés Új ciklus indítása 13 Spirál modell Célok tisztázása, alternatívák Jellemzık Megvalósítás, tesztelés Jellemzık 4 lépésen keresztül, ciklikusan történik a fejlesztés Újdonság: több alternatíva felajánlása (minimális
kockázatú a megfelelı) Minden ciklus egy célkitőzéssel kezdıdik Hátrány Alacsony kockázatú vagy kicsi projektnél költséges Jelentıs kockázatkezelési szakértelem szükséges 3 15 16 Cleanroom módszer Jellemzık Jellemzı Statisztikai minıségbiztosítás (MTTF) Rapid Application Development Létezik matematikai modell a megadására Ciklikus fejlesztés MTTF -ben megadott megbízh. egy idıben fejeszthetı a termékkel (hiba korai kiszőrése) Mőködı prototípusok létrehozása Integrált fejlesztıi környezetek használata SW komponensek újra felhasználása Lecsökken a fejlesztési idı RAD – Gyors alkalmazásfejlesztés Minden szakasz után bizonyítják, hogy hibátlan a szoftver Hátrány Speciáli szakértık Nem teszi hatékonyabbá a fejlesztést Hátrány 17 RUP modell RUP modell Jellemzı Elıkészítés Nem egy
kész modell, inkább csak keret (ajánláscsomag) Szervezetre / projektre igazítható Követelmények Nagy projektekre van kitalálva, ahol több csapat is dolgozik Elemzés Iteratív sw fejlesztési módszertan (teret ad a megbízói visszajelzésnek) RAD módszertana gátat szabhat a használhatóság és futási sebesség területén 18 Átadás Tervezés Implementáció 4 fázis minden iterációban (vizsgálat, kidolgozás, létrehozás, átállás) . Megvalósítás Üzleti modell Teszt 1. iter Hátrány Kidolgozás 19 2. iter . . . . . n-1. iter n. iter 20 Igény a változásra. .hiszen a szoftverfejlesztés NEM gyártás Változások gyors és rugalmas adaptálása Megszabadulni a klasszikus módszertanok hibáitól „A szoftverfejlesztés találékonyságra és kommunikációra épülı kooperatív játék.” Cél Minél gyorsabban Minél költséghatékonyabban Az elvárt
igényt minél jobban kielégítı végeredmény /Alistair Cockburn/ 21 Megoldás alternatíva 22 Agilis, agilitás Agilis módszertanok Szó jelentése: fürgeség Különbözı területeken Kiegészítés Projektvezetés Rendszertervezés Szoftverfejlesztés 23 Az agilitás olyan adottság, amely egyaránt képes létrehozni és reagálni a változásokra és ezzel elınyt szerezni egy turbulens üzleti környezetben Az agilis szervezetek befogadják, sıt generálják a változásokat, és ezzel versenyelınyhöz jutnak Az agilis szervezetek egyrészt fürgék és rugalmasak, másrészt képesek megtalálni a káosz és rend közötti egyensúlyt. 24 Agilis projektvezetés és szoftverfejlesztés Kiáltvány az Agilis Szoftverfejlesztésért Probléma felismerése: a szoftverfejlesztés nem gyártás Mindig új termék készül --> fontos a kommunikáció Mi a jobb szoftverfejlesztés
módjait fedezzük fel azáltal, hogy fejlesztünk és segítünk másokat fejleszteni. Ezen munkában értékesebbnek tartjuk: Nem lehet gyártási folyamatról beszélni A projektmenedzsment értékei másképp (idı,pénz,tartalom,minıség) Az egyént és a személyes kommunikációt, kommunikációt a módszertanoknál és az eszközöknél. A mőködı szoftvert, az átfogó dokumentációnál. 25 Kiáltvány az Agilis Szoftverfejlesztésért (folyt.) 26 Összehasonlítás a klasszikus módszertanokkal A megrendelıvel való együttmőködést, a szerzıdéshez való merev ragaszkodással szemben. Agilis Adaptív (alkalmazkodó) A változásra való reagálást, a tervek rigorózus követésével szemben. Noha, fontosak az utóbbiak is, mi fontosabbnak tartjuk az elızıeket. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 27 Vízesés Iteratív Prediktív (elıre megjósolt) Átfedés a módszerek között Iteratív használata Agilis „Vízesés”-szerő 28 Fıbb jellemzık Iteratív, mint alap Adaptív (alkalmazkodó) Nincsen elıre jóslás, hosszú távú tervezés Csak a közvetlen problémára koncentrálnak DE arra hajszál pontosan Csak azt tudják, mit fognak „a héten” csinálni Prediktív (elıre megjósolt) Elıre megtervezett lépések Minden lépés az EGÉSZRE optimalizálva --> nehézkes változás követés Néha külön változáskezelı bizottság Nincs éles elhatárolódás Iteratív megjelenésének oka: Vízesés modell rugalmatlanság javítása Módszer kulcsa: a szoftvert rövidebb idıközönként kiadni Ezen jellemzı átemelése, csak kicsit másképp. 29 Az idı szerepe az agilis
fejlesztésben 30 Agilis fejlesztés alapelvei I. Hónapok helyett hetek Összesen 12 A határidık nem flexibilisek Legfontosabbak „Kıbe vannak vésve” Az idı az alappillér a feladat helyett!!!!! NEM LEHET KICSÚSZNI A HATÁRIDİBİL Ha mégis, akkor A feladat „megoldhatatlan” Visszamondás Részfeladatokra bontás 31 legnagyobb prioritása a megrendelı igényeinek megfelelı, értékes szoftver korai, és folyamatos kiadása A követelmények változása elfogadott, még a fejlesztés késıi szakaszában is. A rövidebb periódust kell elınyben részesíteni. A megrendelıknek, üzleti szakembereknek és a szoftverfejlesztıknek naponta együtt kell dolgozniuk a teljes projekt során. 32 Agilis fejlesztés alapelvei II. A projekteket motivált emberekre kell építeni, kiknek megteremteni a megfelelı környezetet Hatékonyabb módszer az információ átadásának
a fejlesztési csapaton belül, a személyes beszélgetés. Hátrányok A legjobb architektúrák, követelmények és rendszertervek az önszervezıdı csapatmunkából alakul ki. A fejlesztıi csapat, rendszeresen idıközönként, megfontolja, hogy hogyan válhatnak hatékonyabbá és ennek megfelelıen finomítják viselkedésüket. Kiforratlanság (2001-ben „született”) Csak gyakorlott fejlesztıknél használható Nincs eléggé megtervezve a módszer Túlságosan meg kell változtatni a fejlesztési kultúrát, hogy jól mőködjön Sokan, TÉVESEN, azt állítják, hogy „cowboy” módszer 33 Statisztika, felmérés (2007.03) Bevezetettek-e már agilis projektet? Igen 69% Nem 31% 34 Statisztika, felmérés (2007.03) Forrás: Agile Adoption Rate Survey Mikor vezeti be az agilis fejlesztést? 12% A válaszadók 69%-a jelezte, hogy szervezetüknél egy vagy több agilis projektet hajtanak végre. 9% 21% 46% 35
Soha Nem tudja 6 hónapon belül 2 éven belül Több, mint 2 év múlva 12% 36 Statisztika, felmérés (2007.03) Agilis módszertanok 12% eXtreme Programming (XP) Test Driven Development (TDD) Feature Driven Development Scrum . 33% 5% 6% 44% Agilis fejlesztések sikeressége Kevesebb, mint 25% 25-49% 50-74% 75-90% Több, mint 90% 37 Scrum 38 Kialakulás Rögbibıl átvett kifejezés Hirotaka Takeuchi és Ikujiro Nonaka Vízesés modell, mint váltófutás Jelentése: Viaskodik, összecsap,dulakodik Egyéb jelentése: kavarodás „scrummy” = pompás, remek 39 A stafétabot a program A fázisok a futók Ha egy futó „rossz”, a csapat veszít Megmaradtak a sport szemléletnél (innen a rögbi kifejezés) 40 Alapgondolat Módszer, ahol a fázisok erısen átlapolódnak Több terület emberei kisebb csoportokban És az összes fázisban együtt dolgoznak
Lásd rögbi – együtt futnak, és közben passzolgatnak Publikálás (1990) Ken Schwaber és Jeff Sutherland Megfigyelések, tanulmányozások --> SCRUM kialakulása 41 Scrum, mint agilis módszer 42 Scrum jellemzıi Magában hordozza az adaptív jellemvonásokat Nincs „forgatókönyve” Sokan emiatt csak hozzáállásnak tartják, módszertan helyett 43 Fejlesztı csapat – „EGYSZERRE” kezd dolgozni Üzleti elemzı Tervezı Fejlesztı Teljes mértékben együtt felelısek a végeredményért Scrum Team 44 Scrum jellemzıi (folyt.) Adaptív menedzsment biztosítása Megfelelı kommunikáció Köztes termék Mielıbbi hiba felfedezés Hatékony munkaóra kihasználás 45 Túlóra nem feltétlen pozitív! „Disznók” A csirke erre gondolkozik, majd azt feleli: „Nevezzük Sonkás-tojásnak!” (Ham and eggs)
Átlátható, világos, moduláris tervezetek Ki, miért, milyen határidıvel felelıs Mire a disznó: „Jó ötlet, mi legyen a neve?” A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal: „Te, nyissunk egy éttermet!” Különbözı szakterületek Inkrementális fejlesztés Szerepkörök A disznó erre: „Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.” „Csirkék” Akik „mindenüket” beleadják Közvetetten részei a folyamatnak Terméktulajdonos Felhasználók A vásárlót reprezentálja Scrum Master Maga a scrum mőködtetés, akadálymentesítés 5-9fıs csapat, különbözı területekrıl Pl.: rendszergazda, igazgató Tanácsadó szakértık 47 Vélemény, részeredmény (visszacsatolás) Stakeholder-ek Scrum Team 46 Akik nem szükségesek folyamatosan, csak 1-1 szakaszban
válnak „disznóvá” 48 Dokumentumok Story a megrendelıtıl érkezı lényegi leírás a story feldolgozása és priorizálása Sprint backlog Backlog item Product backlog Egyéb definíciók a konkrét feladatok feltüntetése az adott sprintre (ki, mit, milyen határidıvel vállalt be) Egy teendı (funkció) a backlog dokumentumból Sprint Rövid idıszak Ez alatt kell megvalósítani az adott backlog itemeket Burn down chart egyfajta kimutatás; a csapat teljesítıképesség 49 Scrum meeting A biztos kommunikáció Mindennap 50 Fejlesztés menete .bár nincsen igazi forgatókönyve rövid megbeszélés (~15-30perc) 3 alapvetı kérdés mindenkihez Mit csináltál a tegnapi scrum óta? Mit fogsz csinálni a következı scrum -ig? Van-e valami, ami akadályoz az elırehaladásban? Scrum master vezeti le Fı a NYÍLT beszélgetés 51 52
Határidı és demo Esettanulmány, tapasztalat Kulcsfontosságú a határidı DocuGuard2 (evosoft Hungary Kft.) Csúsztatni nem lehet, csak Story (Requirement Specification) Visszamondani Komplexitás becslés Korrigálni az adott backlog item-t Product Backlog Sprint backlog Burn down chart Minden sprint végén: DEMO A megrendelı ellenırzi az aktuális állapotot Értékelés függvényében iterálódik tovább (visszacsatolás) 53 54 Összefoglalás Egyre nagyobb igények Egyre kisebb erıforrás használás mellett Változások gyors követése Nincs objektív megoldás „Van akinek tetszik, van akinek nem!” Köszönjük a figyelmet! :) Sereg Ákos <sigterm@c3.hu> Varga Balázs <varga27@gmail.com> 55 56
Projekttıl függıen egyéb korlátok, amiket figyelembe kell venni Adott Idı- és Költségkereten belül sikeresen teljesüljenek a projekt céljai Projektmenedzsment háromszög 5 6 Projektmenedzsment az informatikában Projektmenedzsment háromszög Irányítás: A P.M Háromszög egyensúlyban tartása Egyre összetettebb, jobb minıségő sw.-ek igénye a piacon Ha bármelyik sarok irányába billen, a másik kettı hangsúlyozásával visszaállítható Több idıt igényel a fejlesztési tevékenység koordinálása Példa Határidı veszélybe kerül Erıforrások átcsoportosításával / Pótlólagos erıforrások bevonásával Versenyhelyzet: állandó nyomás a fejlesztıcégeken hatékony módszer szükséges a fejlesztés menedzsmentjéhez az egyensúly helyre billenthetı! 7 8 Projektmenedzsment az informatikában Projektmenedzsment az informatikában Klasszikus sw fejlesztési modellek
nem optimális hatékonyságúak (késıbb részletezve) Versenyképesség megtartása + piaci igények kielégítése Gyakori problémák A megrendelı az esetek többségében nem tudja pontosan, mit akar Igények megváltozása a fejlesztés során Fejlesztési modellnek rugalmasnak kell lennie! Szükségessé vált újabb, hatékonyabb sw fejlesztési modellre 9 Tradicionális modellek áttekintése Vízesés modell Inkrementális (iteratív) modell Spirál modell „Cleanroom” modell RAD modell RUP modell 10 Vízesés modell Requirements Design Implementation Verification Maintenance 11 12 Vízesés modell Inkrementális (iteratív) modell Jellemzık Egymás után következı elhatárolt, de összefüggı fázisok (általában 5) Követelményanalízis és definíció (requirements) Rendszer- és szoftvertervezés (design) Implementáció, részegységek
tesztelése (impl.) Részegységek tesztelése, rendszer tesztelés (verification) Mőködtetés, karbantartás (maintenance) Hátrány Már a korai szakaszokban komoly döntéseket kell hozni (rugalmatlan) 1 Alternatívák értékelése Kockázatelemzés 4 Célszerőbb a nagy szoftverek fejlesztésénél Rugalmasabb a vízesés modellnél Elsı lépésben egy-egy kisebb probléma megoldása a cél Al-változatok egymásutánija Prototípus változat: UI (félreértések elkerülése) Gyors visszacsatolás Hátrány A folyamatos változások odavezetnek, hogy a rendszer rosszul strukturált lesz Fejlıdés mérése nehézkes 14 Spirál modell 2 Értékelés Új ciklus indítása 13 Spirál modell Célok tisztázása, alternatívák Jellemzık Megvalósítás, tesztelés Jellemzık 4 lépésen keresztül, ciklikusan történik a fejlesztés Újdonság: több alternatíva felajánlása (minimális
kockázatú a megfelelı) Minden ciklus egy célkitőzéssel kezdıdik Hátrány Alacsony kockázatú vagy kicsi projektnél költséges Jelentıs kockázatkezelési szakértelem szükséges 3 15 16 Cleanroom módszer Jellemzık Jellemzı Statisztikai minıségbiztosítás (MTTF) Rapid Application Development Létezik matematikai modell a megadására Ciklikus fejlesztés MTTF -ben megadott megbízh. egy idıben fejeszthetı a termékkel (hiba korai kiszőrése) Mőködı prototípusok létrehozása Integrált fejlesztıi környezetek használata SW komponensek újra felhasználása Lecsökken a fejlesztési idı RAD – Gyors alkalmazásfejlesztés Minden szakasz után bizonyítják, hogy hibátlan a szoftver Hátrány Speciáli szakértık Nem teszi hatékonyabbá a fejlesztést Hátrány 17 RUP modell RUP modell Jellemzı Elıkészítés Nem egy
kész modell, inkább csak keret (ajánláscsomag) Szervezetre / projektre igazítható Követelmények Nagy projektekre van kitalálva, ahol több csapat is dolgozik Elemzés Iteratív sw fejlesztési módszertan (teret ad a megbízói visszajelzésnek) RAD módszertana gátat szabhat a használhatóság és futási sebesség területén 18 Átadás Tervezés Implementáció 4 fázis minden iterációban (vizsgálat, kidolgozás, létrehozás, átállás) . Megvalósítás Üzleti modell Teszt 1. iter Hátrány Kidolgozás 19 2. iter . . . . . n-1. iter n. iter 20 Igény a változásra. .hiszen a szoftverfejlesztés NEM gyártás Változások gyors és rugalmas adaptálása Megszabadulni a klasszikus módszertanok hibáitól „A szoftverfejlesztés találékonyságra és kommunikációra épülı kooperatív játék.” Cél Minél gyorsabban Minél költséghatékonyabban Az elvárt
igényt minél jobban kielégítı végeredmény /Alistair Cockburn/ 21 Megoldás alternatíva 22 Agilis, agilitás Agilis módszertanok Szó jelentése: fürgeség Különbözı területeken Kiegészítés Projektvezetés Rendszertervezés Szoftverfejlesztés 23 Az agilitás olyan adottság, amely egyaránt képes létrehozni és reagálni a változásokra és ezzel elınyt szerezni egy turbulens üzleti környezetben Az agilis szervezetek befogadják, sıt generálják a változásokat, és ezzel versenyelınyhöz jutnak Az agilis szervezetek egyrészt fürgék és rugalmasak, másrészt képesek megtalálni a káosz és rend közötti egyensúlyt. 24 Agilis projektvezetés és szoftverfejlesztés Kiáltvány az Agilis Szoftverfejlesztésért Probléma felismerése: a szoftverfejlesztés nem gyártás Mindig új termék készül --> fontos a kommunikáció Mi a jobb szoftverfejlesztés
módjait fedezzük fel azáltal, hogy fejlesztünk és segítünk másokat fejleszteni. Ezen munkában értékesebbnek tartjuk: Nem lehet gyártási folyamatról beszélni A projektmenedzsment értékei másképp (idı,pénz,tartalom,minıség) Az egyént és a személyes kommunikációt, kommunikációt a módszertanoknál és az eszközöknél. A mőködı szoftvert, az átfogó dokumentációnál. 25 Kiáltvány az Agilis Szoftverfejlesztésért (folyt.) 26 Összehasonlítás a klasszikus módszertanokkal A megrendelıvel való együttmőködést, a szerzıdéshez való merev ragaszkodással szemben. Agilis Adaptív (alkalmazkodó) A változásra való reagálást, a tervek rigorózus követésével szemben. Noha, fontosak az utóbbiak is, mi fontosabbnak tartjuk az elızıeket. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 27 Vízesés Iteratív Prediktív (elıre megjósolt) Átfedés a módszerek között Iteratív használata Agilis „Vízesés”-szerő 28 Fıbb jellemzık Iteratív, mint alap Adaptív (alkalmazkodó) Nincsen elıre jóslás, hosszú távú tervezés Csak a közvetlen problémára koncentrálnak DE arra hajszál pontosan Csak azt tudják, mit fognak „a héten” csinálni Prediktív (elıre megjósolt) Elıre megtervezett lépések Minden lépés az EGÉSZRE optimalizálva --> nehézkes változás követés Néha külön változáskezelı bizottság Nincs éles elhatárolódás Iteratív megjelenésének oka: Vízesés modell rugalmatlanság javítása Módszer kulcsa: a szoftvert rövidebb idıközönként kiadni Ezen jellemzı átemelése, csak kicsit másképp. 29 Az idı szerepe az agilis
fejlesztésben 30 Agilis fejlesztés alapelvei I. Hónapok helyett hetek Összesen 12 A határidık nem flexibilisek Legfontosabbak „Kıbe vannak vésve” Az idı az alappillér a feladat helyett!!!!! NEM LEHET KICSÚSZNI A HATÁRIDİBİL Ha mégis, akkor A feladat „megoldhatatlan” Visszamondás Részfeladatokra bontás 31 legnagyobb prioritása a megrendelı igényeinek megfelelı, értékes szoftver korai, és folyamatos kiadása A követelmények változása elfogadott, még a fejlesztés késıi szakaszában is. A rövidebb periódust kell elınyben részesíteni. A megrendelıknek, üzleti szakembereknek és a szoftverfejlesztıknek naponta együtt kell dolgozniuk a teljes projekt során. 32 Agilis fejlesztés alapelvei II. A projekteket motivált emberekre kell építeni, kiknek megteremteni a megfelelı környezetet Hatékonyabb módszer az információ átadásának
a fejlesztési csapaton belül, a személyes beszélgetés. Hátrányok A legjobb architektúrák, követelmények és rendszertervek az önszervezıdı csapatmunkából alakul ki. A fejlesztıi csapat, rendszeresen idıközönként, megfontolja, hogy hogyan válhatnak hatékonyabbá és ennek megfelelıen finomítják viselkedésüket. Kiforratlanság (2001-ben „született”) Csak gyakorlott fejlesztıknél használható Nincs eléggé megtervezve a módszer Túlságosan meg kell változtatni a fejlesztési kultúrát, hogy jól mőködjön Sokan, TÉVESEN, azt állítják, hogy „cowboy” módszer 33 Statisztika, felmérés (2007.03) Bevezetettek-e már agilis projektet? Igen 69% Nem 31% 34 Statisztika, felmérés (2007.03) Forrás: Agile Adoption Rate Survey Mikor vezeti be az agilis fejlesztést? 12% A válaszadók 69%-a jelezte, hogy szervezetüknél egy vagy több agilis projektet hajtanak végre. 9% 21% 46% 35
Soha Nem tudja 6 hónapon belül 2 éven belül Több, mint 2 év múlva 12% 36 Statisztika, felmérés (2007.03) Agilis módszertanok 12% eXtreme Programming (XP) Test Driven Development (TDD) Feature Driven Development Scrum . 33% 5% 6% 44% Agilis fejlesztések sikeressége Kevesebb, mint 25% 25-49% 50-74% 75-90% Több, mint 90% 37 Scrum 38 Kialakulás Rögbibıl átvett kifejezés Hirotaka Takeuchi és Ikujiro Nonaka Vízesés modell, mint váltófutás Jelentése: Viaskodik, összecsap,dulakodik Egyéb jelentése: kavarodás „scrummy” = pompás, remek 39 A stafétabot a program A fázisok a futók Ha egy futó „rossz”, a csapat veszít Megmaradtak a sport szemléletnél (innen a rögbi kifejezés) 40 Alapgondolat Módszer, ahol a fázisok erısen átlapolódnak Több terület emberei kisebb csoportokban És az összes fázisban együtt dolgoznak
Lásd rögbi – együtt futnak, és közben passzolgatnak Publikálás (1990) Ken Schwaber és Jeff Sutherland Megfigyelések, tanulmányozások --> SCRUM kialakulása 41 Scrum, mint agilis módszer 42 Scrum jellemzıi Magában hordozza az adaptív jellemvonásokat Nincs „forgatókönyve” Sokan emiatt csak hozzáállásnak tartják, módszertan helyett 43 Fejlesztı csapat – „EGYSZERRE” kezd dolgozni Üzleti elemzı Tervezı Fejlesztı Teljes mértékben együtt felelısek a végeredményért Scrum Team 44 Scrum jellemzıi (folyt.) Adaptív menedzsment biztosítása Megfelelı kommunikáció Köztes termék Mielıbbi hiba felfedezés Hatékony munkaóra kihasználás 45 Túlóra nem feltétlen pozitív! „Disznók” A csirke erre gondolkozik, majd azt feleli: „Nevezzük Sonkás-tojásnak!” (Ham and eggs)
Átlátható, világos, moduláris tervezetek Ki, miért, milyen határidıvel felelıs Mire a disznó: „Jó ötlet, mi legyen a neve?” A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal: „Te, nyissunk egy éttermet!” Különbözı szakterületek Inkrementális fejlesztés Szerepkörök A disznó erre: „Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.” „Csirkék” Akik „mindenüket” beleadják Közvetetten részei a folyamatnak Terméktulajdonos Felhasználók A vásárlót reprezentálja Scrum Master Maga a scrum mőködtetés, akadálymentesítés 5-9fıs csapat, különbözı területekrıl Pl.: rendszergazda, igazgató Tanácsadó szakértık 47 Vélemény, részeredmény (visszacsatolás) Stakeholder-ek Scrum Team 46 Akik nem szükségesek folyamatosan, csak 1-1 szakaszban
válnak „disznóvá” 48 Dokumentumok Story a megrendelıtıl érkezı lényegi leírás a story feldolgozása és priorizálása Sprint backlog Backlog item Product backlog Egyéb definíciók a konkrét feladatok feltüntetése az adott sprintre (ki, mit, milyen határidıvel vállalt be) Egy teendı (funkció) a backlog dokumentumból Sprint Rövid idıszak Ez alatt kell megvalósítani az adott backlog itemeket Burn down chart egyfajta kimutatás; a csapat teljesítıképesség 49 Scrum meeting A biztos kommunikáció Mindennap 50 Fejlesztés menete .bár nincsen igazi forgatókönyve rövid megbeszélés (~15-30perc) 3 alapvetı kérdés mindenkihez Mit csináltál a tegnapi scrum óta? Mit fogsz csinálni a következı scrum -ig? Van-e valami, ami akadályoz az elırehaladásban? Scrum master vezeti le Fı a NYÍLT beszélgetés 51 52
Határidı és demo Esettanulmány, tapasztalat Kulcsfontosságú a határidı DocuGuard2 (evosoft Hungary Kft.) Csúsztatni nem lehet, csak Story (Requirement Specification) Visszamondani Komplexitás becslés Korrigálni az adott backlog item-t Product Backlog Sprint backlog Burn down chart Minden sprint végén: DEMO A megrendelı ellenırzi az aktuális állapotot Értékelés függvényében iterálódik tovább (visszacsatolás) 53 54 Összefoglalás Egyre nagyobb igények Egyre kisebb erıforrás használás mellett Változások gyors követése Nincs objektív megoldás „Van akinek tetszik, van akinek nem!” Köszönjük a figyelmet! :) Sereg Ákos <sigterm@c3.hu> Varga Balázs <varga27@gmail.com> 55 56
