Agilis projektmenedzsment 2013. április 10.
1
Adaptive Consulting Kft.
Csutorás Zoltán Agile coach, tréner
[email protected]
2
www.scrummate.hu
3
Agilis ernyő
Scrum
eXtreme Programming Lean/Kanban DSDM
Crystal Clear
4
Háromszor eredményesebb 9%
100%
29%
75% 49%
50%
Bukott Kritikus Sikeres
57%
42% 14%
Vízesés
Agilis
25%
0%
Forrás: The Chaos Manifesto, Standish Group 2012
5
Az agilis kiáltvány ... é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 a megrendelővel való együttműködést, a szerződéshez való ragaszkodással szemben. a változásra való reagálást, a tervek rigorózus követésével szemben.... ... noha fontosak az utóbbiak is ...
6
Fejlesztési veszteségek Milyen arányban használjuk a rendszer funkcióit?
Átadott, de nem használt funkciók 45%
Elkészített, de élesbe nem állított funkciók Megtervezett, de le nem fejlesztett funkciók 19%
Részletesen felmért, de el nem készített funkciók
16%
13% 7%
Állandóan Ritkán
Gyakran Soha
Néha
Standish Group Chaos Report v3
7
A követelmények avulása Követelmények érvényességének felezési ideje
10-12 év
2-3 év 6 hónap 1980
2000
2011 University of Missouri, Kansas City
8
Túl korai, túl részletes követelményspecifikáció
9
Scrum 1993 - Első implementáció : Jeff Sutherland 1995 - Scrum paper : Ken Schwaber 2001- Agile Manifesto 2003 - Első CSM képzés
10
The new new product development game Harvard Business Review, 1986
Mi a közös a kiemelkedően sikeres termékfejlesztési projektekben?
Ikujiro Nonaka
Hirotaka Takeuchi
11
„Az egyszerű szabályok és világos célok komplex és intelligens viselkedés felé vezetnek. A komplex szabályok és bonyolult szabályzatok egyszerű és buta viselkedéshez vezetnek.”
Dee Ward Hock, a Visa alapítója 12
Scrum csapat Elkötelezett, erős motivációval rendelkező, állandó csapat Minden, a megvalósításhoz szükséges szakértelem jelen van a csapatban
Tanulási hajlandóság Nagyon világos, jól
definiált cél
13
Scrum Master
14
Product Owner A projekt vízióját alakítja ki és kommunikálja a csapat felé Miért fejlesztjük ezt a terméket? Kik fogják használni? Kik fogják megvenni? Miért pont a mi termékünket fogják választani?
Mit kell tudnia a terméknek? Mikorra kell tudnia? Mennyit ér meg nekünk a kifejlesztése?
15
Product backlog (termék hátralék) ‣ ‣ ‣ ‣
Az a funkcionalitás, amit a termékhez még hozzá kell adni Megvalósítási sorrendben Felhasználói érték megfogalmazásával A product owner vezeti
16
User voice ‘User voice’ szerkezet Mint <szereplő> szeretnék egy <szolgáltatást> azért, hogy elérjek egy
Visszatérő látogatóként listát akarok vezetni azokról a könyvekről, amiket később el akarok olvasni, hogy ne kelljen újra megkeresnem őket.
17
Sprint tervezés ‣
Célja, hogy a csapat minden tagja megértse, hogy mit kell megvalósítani (felhasználói szemszögből is!)
‣
A csapat közösen azonosítja a sprint során végrehajtandó feladatokat
‣
A csapat dönti el, hogy mit képes egy sprintben megvalósítani, azt „felülről” nem lehet erőltetni!
‣
Amit a csapat vállalt, azért felelősséggel tartozik!
18
Fejlesztési folyamat User story (backlog elem) Visszatérő látogatóként listát akarok vezetni azokról a könyvekről, amiket később el akarok olvasni, hogy ne kelljen újra keresnem őket.
Kedvencekbe tétel felület tervezése.
Adatmodell kiegészítése a kedvencekkel.
Kedvencként megjelölés front-end fejlesztés.
Kedvencként megjelölés logika fejlesztés.
Integráció és tesztelés.
19
Működő termék bővítmény ‣ ‣ ‣
Minden sprint végén bemutatható eredmény Tesztelt, hibamentes többlet képesség A „Kész!” fogalmának konzisztens, szigorú kezelése
20
Definition of Done Konzisztens kritériumrendszer a „Kész” fogalmára Fejlesztés kész Fejlesztői teszten átment
Mikor tekintünk késznek egy fejlesztett Automatizált tesztekkel lefedve funkciót? Funkcionális teszten átment Dokumentálva Demo környezetbe telepítve Felhasználói elfogadási teszten átment Éles környezetbe telepítve
21
Sprintek ‣ ‣ ‣ ‣
Egységnyi hosszúsági időszakok A team önállóan szervezi a munkáját Nincs projektmenedzser - van viszont Scrum Master Mindenki igyekszik megérteni a problémát és a legjobb tudása szerint részt venni annak megoldásában
22
Scrum keretrendszer Napi scrum (standup) meeting ‣ ‣ ‣ ‣ ‣
A team összehangolja a csapat tagjainak munkáját Mindenki képet kapjon arról, hogy hogyan állunk a sprinttel Mindenki számára legyen világos, hogy mit fog tenni aznap a célok eléréséért Mindenkinek legyen lehetősége segítséget kérni, kérdéseket feltenni Egyértelmű, vizuális eszközök használata (team board, burndown chart)
23
Team board Várakozik
43
6
5
3
3
5
5
Folyamatban
Kész!
Feladat elvégzéséig hátralévő becsült munkaóra
2
10
4
24
Burn-down chart 45 40 35 30 25 20 15 10 5 1
2
3
4
5
6
7
8
9
10 25
Team board Várakozik
43 29
6
5
3
3
5
5
Folyamatban 14
Kész!
2
10
4
26
Team board Várakozik
29
Folyamatban 11 14
2 6
3
5
Kész!
3 5
6 3
2
10
5
4
27
Team board Várakozik
29
Folyamatban 11
2 6
3
5
5
Kész!
3 5
6 3
2
10
4
28
Team board Várakozik
Folyamatban 11 9
29 21
3
5
Kész!
1 3
2
10
5
4
29
Burn-down chart 45 40 35 30 25 20 15 10 5 1
2
3
4
5
6
7
8
9
10 30
Scrum keretrendszer Sprint review ‣ ‣ ‣
Hogyan javíthatunk a folyamatainkon? Jó terméket fejlesztünk-e? Jól fejlesztjük-e a terméket?
31
Termék demo A sprint során elkészített termék funkciók bemutatása
Visszajelzés gyűjtés
Jó terméket fejlesztünk-e?
32
Retrospective A team munkamódszereinek kiértékelése
A team „belső ügye”
Jól dolgozunk-e?
33
Ütemterv áttekintés
34
Célzott elemzés (veszteség termelés)
35
Ismert hibák, változási kérések a rendszerben
36
Köszönöm a figyelmet! 37
