Agilis szoftverfejlesztés és Scrum

Átírás

1 Információs rendszerek tervezése hallgatói prezentáció Tartalom Projektmenedzsment alapvetı ismertetése Klasszikus modellek ismétlése, hátrányai Agilis szoftverfejlesztés és Scrum Agilis projektvezetés Scrum Esettanulmány Miskolc, Készítette: 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) 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 Erıforrás (resource) Teljesítmény Minıség 3 4

2 Projektmenedzsment - korlátok Projektmenedzsment háromszög 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 5 6 Projektmenedzsment háromszög Irányítás: A P.M. Háromszög egyensúlyban tartása Ha bármelyik sarok irányába billen, a másik kettı hangsúlyozásával visszaállítható Példa Határidı veszélybe kerül Erıforrások átcsoportosításával / Pótlólagos erıforrások bevonásával az egyensúly helyre billenthetı! Projektmenedzsment az informatikában Egyre összetettebb, jobb minıségő sw.-ek igénye a piacon Több idıt igényel a fejlesztési tevékenység koordinálása Versenyhelyzet: állandó nyomás a fejlesztıcégeken hatékony módszer szükséges a fejlesztés menedzsmentjéhez 7 8

3 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 Szükségessé vált újabb, hatékonyabb sw fejlesztési modellre Projektmenedzsment az informatikában 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! 9 10 Tradicionális modellek áttekintése Vízesés modell Vízesés modell Inkrementális (iteratív) modell Spirál modell Cleanroom modell RAD modell Requirements Design Implementation RUP modell Verification 11 Maintenance 12

4 Vízesés modell Jellemzık Egymás után következı elhatárolt, de összefüggı fázisok (általában 5) Hátrány 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) Már a korai szakaszokban komoly döntéseket kell hozni (rugalmatlan) 13 Inkrementális (iteratív) modell Jellemzık 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 Spirál modell Célok tisztázása, alternatívák 1 Értékelés Új ciklus indítása Alternatívák értékelése Kockázatelemzés 2 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

5 Cleanroom módszer RAD Gyors alkalmazásfejlesztés Jellemzık Statisztikai minıségbiztosítás (MTTF) Létezik matematikai modell a megadására MTTF -ben megadott megbízh. egy idıben fejeszthetı a termékkel (hiba korai kiszőrése) 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 17 Jellemzı Rapid Application Development Ciklikus fejlesztés 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ı Hátrány RAD módszertana gátat szabhat a használhatóság és futási sebesség területén 18 RUP modell RUP modell Jellemzı Nem egy kész modell, inkább csak keret (ajánláscsomag) Szervezetre / projektre igazítható Üzleti modell Követelmények Elıkészítés Kidolgozás Megvalósítás Átadás Nagy projektekre van kitalálva, ahol több csapat is dolgozik Iteratív sw fejlesztési módszertan (teret ad a megbízói visszajelzésnek) 4 fázis minden iterációban (vizsgálat, kidolgozás, létrehozás, átállás) Hátrány Elemzés Tervezés Implementáció Teszt 1. iter 2. iter n-1. iter n. iter

6 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 Cél Minél gyorsabban Minél költséghatékonyabban A szoftverfejlesztés találékonyságra és kommunikációra épülı kooperatív játék. /Alistair Cockburn/ Az elvárt igényt minél jobban kielégítı végeredmény Megoldás alternatíva Agilis, agilitás Agilis módszertanok Különbözı területeken Projektvezetés Rendszertervezés Szoftverfejlesztés Szó jelentése: fürgeség Kiegészítés 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

7 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ó Nem lehet gyártási folyamatról beszélni A projektmenedzsment értékei másképp (idı,pénz,tartalom,minıség) 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: Az egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél. A mőködı szoftvert, az átfogó dokumentációnál Kiáltvány az Agilis Szoftverfejlesztésért (folyt.) A megrendelıvel való együttmőködést, a szerzıdéshez való merev ragaszkodással szemben. Összehasonlítás a klasszikus módszertanokkal Agilis Iteratív Vízesés 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. Adaptív (alkalmazkodó) Átfedés a módszerek között Iteratív használata Agilis Vízesés -szerő Prediktív (elıre megjósolt) 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 28

8 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 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... Néha külön változáskezelı bizottság Az idı szerepe az agilis fejlesztésben Agilis fejlesztés alapelvei I. Hónapok helyett hetek A határidık nem flexibilisek Összesen 12 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 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. Részfeladatokra bontás 31 32

9 Agilis fejlesztés alapelvei II. Hátrányok 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. 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 Statisztika, felmérés ( ) Statisztika, felmérés ( ) Bevezetettek-e már agilis projektet? Forrás: Agile Adoption Rate Survey Mikor vezeti be az agilis fejlesztést? 12% 9% Igen 69% Nem 31% A válaszadók 69%-a jelezte, hogy szervezetüknél egy vagy több agilis projektet hajtanak végre. 21% Soha Nem tudja 6 hónapon belül 2 éven belül Több, mint 2 év múlva 46% 12% 35 36

10 Statisztika, felmérés ( ) Agilis módszertanok extreme Programming (XP) 33% 12% 5% Test Driven Development (TDD) Feature Driven Development 6% Scrum... Kevesebb, mint 25% 44% Agilis fejlesztések sikeressége 25-49% 50-74% 75-90% Több, mint 90% Scrum Kialakulás Rögbibıl átvett kifejezés Jelentése: Viaskodik, összecsap,dulakodik Egyéb jelentése: kavarodás scrummy = pompás, remek Hirotaka Takeuchi és Ikujiro Nonaka Vízesés modell, mint váltófutás 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) 39 40

11 Alapgondolat Publikálás (1990) 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 Ken Schwaber és Jeff Sutherland Megfigyelések, tanulmányozások --> SCRUM kialakulása Scrum, mint agilis módszer 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 Fejlesztı csapat EGYSZERRE kezd dolgozni Üzleti elemzı Tervezı Fejlesztı Teljes mértékben együtt felelısek a végeredményért Scrum Team 43 44

12 Scrum jellemzıi (folyt.) Szerepkörök Adaptív menedzsment biztosítása Megfelelı kommunikáció 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 Mire a disznó: Jó ötlet, mi legyen a neve? Köztes termék A csirke erre gondolkozik, majd azt feleli: Mielıbbi hiba felfedezés Nevezzük Sonkás-tojásnak! (Ham and eggs) Átlátható, világos, moduláris tervezetek A disznó erre: Ki, miért, milyen határidıvel felelıs Hatékony munkaóra kihasználás Túlóra nem feltétlen pozitív! 45 Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne. 46 Disznók 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 Vélemény, részeredmény (visszacsatolás) Scrum Master Stakeholder-ek Maga a scrum mőködtetés, akadálymentesítés Pl.: rendszergazda, igazgató Scrum Team Tanácsadó szakértık 5-9fıs csapat, különbözı területekrıl Akik nem szükségesek folyamatosan, csak 1-1 szakaszban válnak disznóvá 47 48

13 Dokumentumok Egyéb definíciók Story a megrendelıtıl érkezı lényegi leírás Product backlog a story feldolgozása és priorizálása Sprint backlog a konkrét feladatok feltüntetése az adott sprintre (ki, mit, milyen határidıvel vállalt be) Backlog item 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 Scrum meeting Fejlesztés menete A biztos kommunikáció...bár nincsen igazi forgatókönyve... Mindennap 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

14 Határidı és demo Esettanulmány, tapasztalat Kulcsfontosságú a határidı Csúsztatni nem lehet, csak Visszamondani Korrigálni az adott backlog item-t 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) DocuGuard2 (evosoft Hungary Kft.) Story (Requirement Specification) Komplexitás becslés Product Backlog Sprint backlog Burn down chart Ö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