Agilis szoftverfejlesztés és Esettanulmány Scrumusers.iit.uni-miskolc.hu/ficsor/inftervseg/agilishand.pdf · Scrum Készítette: Sereg Ákos Varga Balázs Miskolc, 2008.10.15 Információs
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Agilis szoftverfejlesztésés
Scrum
Készítette:Sereg Ákos
Varga BalázsMiskolc, 2008.10.15
Információs rendszerek tervezése – hallgatói prezentáció
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.
25
Agilis projektvezetés és szoftverfejlesztés
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)
26
Kiáltvány az Agilis Szoftverfejlesztésért
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ótAz egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél.
A mőködı szoftvert,A mőködı szoftvert, az átfogó dokumentációnál.
27
Kiáltvány az Agilis Szoftverfejlesztésért (folyt.)
A megrendelıvel való együttmőködéstA megrendelıvel való együttmőködést,, a szerzıdéshez való merev ragaszkodással
szemben.
A változásra való reagálást,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 28
Összehasonlítás a klasszikus módszertanokkal
Adaptív(alkalmazkodó)
Prediktív(elıre megjósolt)
Iteratív
Agilis Vízesés
Átfedés a módszerek között Iteratív használata Agilis „Vízesés”-szerő
29
Fıbb jellemzık
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 30
Iteratív, mint alap
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...
31
Az idı szerepe az agilis fejlesztésben
Hónapok helyett hetek A határidık nem flexibilisek „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
32
Agilis fejlesztés alapelvei I.
Összesen 12 Legfontosabbak
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.
33
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.
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.
34
Hátrányok
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
35
Statisztika, felmérés (2007.03)
Forrás: Agile Adoption Rate Survey
A válaszadók 69%-a jelezte, hogy szervezetüknél egy vagy több agilis projektet hajtanak végre.
Igen 69%
Nem 31%
Bevezetettek-e már agilis projektet?
36
Statisztika, felmérés (2007.03)
12%
46%12%
21%
9%
Mikor vezeti be az agilis fejlesztést?
SohaNem tudja6 hónapon belül2 éven belülTöbb, mint 2 év múlva
37
Statisztika, felmérés (2007.03)
6%
5%
12%
33%
44%Agilis fejlesztések sikeressége
Kevesebb, mint 25%
25-49% 50-74% 75-90% Több, mint 90%
38
Agilis módszertanok
eXtreme Programming (XP) Test Driven Development (TDD) Feature Driven Development Scrum ...
39
Scrum
Rögbibıl átvett kifejezés
Jelentése: Viaskodik, összecsap,dulakodik
Egyéb jelentése: kavarodás
„scrummy” = pompás, remek
40
Kialakulás
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)
41
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
42
Publikálás (1990)
Ken Schwaber és Jeff Sutherland Megfigyelések, tanulmányozások --> SCRUM
kialakulása
43
Scrum, mint agilis módszer
Magában hordozza az adaptív jellemvonásokat Nincs „forgatókönyve” Sokan emiatt csak hozzáállásnak tartják,
módszertan helyett
44
Scrum jellemzıi
Fejlesztı csapat – „EGYSZERRE” kezd dolgozni Üzleti elemzı Tervezı Fejlesztı
Teljes mértékben együtt felelısek a végeredményért
Átlátható, világos, moduláris tervezetek Ki, miért, milyen határidıvel felelıs
Hatékony munkaóra kihasználás Túlóra nem feltétlen pozitív!
46
Szerepkörök
A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal:
„Te, nyissunk egy éttermet!” Mire a disznó:
„Jó ötlet, mi legyen a neve?” A csirke erre gondolkozik, majd azt feleli:
„Nevezzük Sonkás-tojásnak!” (Ham and eggs) A disznó erre:
„Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.”
47
„Disznók”
Akik „mindenüket” beleadják Terméktulajdonos
A vásárlót reprezentálja
Scrum Master Maga a scrum mőködtetés, akadálymentesítés
Scrum Team 5-9fıs csapat, különbözı területekrıl
48
„Csirkék”
Közvetetten részei a folyamatnak Felhasználók
Vélemény, részeredmény (visszacsatolás)
Stakeholder-ek Pl.: rendszergazda, igazgató
Tanácsadó szakértık Akik nem szükségesek folyamatosan, csak 1-1
szakaszban válnak „disznóvá”
49
Dokumentumok
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)
50
Egyéb definíciók
Backlog item Egy teendı (funkció) a backlog dokumentumból
Sprint Rövid idıszak Ez alatt kell megvalósítani az adott backlog item-
eket
Burn down chart egyfajta kimutatás; a csapat teljesítıképesség
51
Scrum meeting
A biztos kommunikáció 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
52
Fejlesztés menete
...bár nincsen igazi forgatókönyve...
53
Határidı és demo
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)
54
Esettanulmány, tapasztalat
DocuGuard2 (evosoft Hungary Kft.) Story (Requirement Specification) Komplexitás becslés Product Backlog Sprint backlog Burn down chart
55
Ö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!”