Economic subjects | Project management » Németh-Nusser - Agilis projektmenedzsment, fikció vagy valóság

Agilis projektmenedzsment fikció vagy valóság? Németh-Nusser Lénárd 2010.0930 Ahogy az ügyfél definiálta Fejlesztés és projektmenedzsment Ahogy a projektvezető értette Ahogy a Designer tervezte Amire a felhasználónak valójában szüksége volt Ahogy a programozó megvalósította Ahogy az üzleti tanácsadó ígérte Ahogy a projekt dokumentálásra került 2 Vízesés vs agilis megközelítés A Standish Group – Chaos Report • Vízesés módszertannal megvalósított projektek esetén: „Az egyedi fejlesztésű rendszerekben megvalósított funkciókat milyen arányban használják a felhasználók?” • • • • 20%-nyi lényeges funkció vs 80%-nyi mellőzhető 80%-a az üzleti értéknek az idő 20 %-ban előállítható a kihagyott funkciók emésztik a ráfordítást a fejlesztés során keletkezett változások visszavezetése költséges Hagyományos megközelítés Adaptív megközelítés 3 Agile manifesto – Agilis

kiáltvány Tizenkét elv: • • • • Fontosabb: az egyén és a személyes kommunikáció, a módszertanoknál és az eszközöknél a működő szoftver, az átfogó dokumentációnál a megrendelővel való együttműködés, a szerződéshez való ragaszkodásnál a változásra való reagálás, a tervek rigorózus követésénél. Noha, fontosak az utóbbiak is, fontosabbnak tartjuk az előzőeket. 1. Ügyfél elégedettség a hasznos szoftverelemek gyors és folyamatos szállításának eredményeként 2. Működő szoftverelemek sűrű szállítása (hetek) 3. A működő szoftver a fejlődés fő mércéje 4. A követelmények késői változása is elfogadott 5. Napi, közeli együttműködés az üzlet és a fejlesztők között 6. Személyes beszélgetés a kommunikáció legjobb formája (azonos hely) 7. A projektek mindenki által elfogadott elhivatott egyénekre épül 8. Technikai és design elemek folyamatos szem előtt tartása 9.

Egyszerűség 10. Önszerveződő csapat 11. Folyamatos alkalmazkodás a megváltozott körülményekhez. 12. Fenntartható egyensúly és kompromisszum az egyes ellenérdekelt szereplők között. 4 Az agilitás a gyakorlatban • A szoftver nem gyártás, hanem termékfejlesztés, • A „termék” számos jellemzőjét nyitva hagyják egészen a fejlesztés végéig, • Sprintek: iteratív, inkrementális fejlesztés a teljes projekt életciklusban (planning, requirements analysis, design, coding, testing, documentation) • Minden sprint végeredménye egy tesztelt és elméletileg átadható funkció, • Szóbeli, intenzív és hatékony kommunikáció az írásbeli helyett, • A működő alkalmazás a haladás mértéke, • „Éppen elegendő” szemlélet, • Önszervező, öntevékeny teamek, • Kis release-ek, rövid sprintek, • Azonos földrajzi elhelyezés, • Tervezés: csak egy iterációra, • Teszt vezérelt fejlesztés. 5

Agilis módszertan pozitívumai Embercentrikus • Ügyfélbarát, ügyfél elégedettség a fő cél • Nem a ledokumentált folyamatokon van a hangsúly, hanem az eredményen • Épít a csapattagok kreativitására • Fejleszti, képzi az embereket • Folyamatosan bevonja a leendő felhasználót és beépíti az észrevételeket • Segíti a csapatok összeszerveződését • Érdemi tevékenységre ösztönöz Költséghatékony • A felesleges ráfordításokat csökkenti (MUDA) • Csak lényegi feladatok valósulnak meg • Rugalmas, és alakítható a scope 6 Agilitás feltételei, ismérvei • Az ügyfél igényei gyakran módosulnak: „dinamikus, innovatív projekt” • Önállóságot, felhatalmazást támogató szervezet, ebben megbízható munkatársak, önálló hatáskörrel • Kis projektek (kicsi, de maximálisan kompetens csapat, rövidebb átfutási idő) • Hajlandóság a közös kockázatvállalás, kölcsönös

bizalom és tisztelet alapkövetelmény • A vitára és tárgyalásra nyitott szervezeti kultúra • A szervezetnek olyan környezettel kell rendelkeznie, amely lehetővé teszi a gyors kommunikációt a csapattagok között • A szervezetnek együtt kell élnie azokkal döntésekkel amiket a fejlesztők meghoznak • Úrrá kell lenni a „káosz”-on 7 a Agilis vs hagyományos megközelítés • A legnagyobb különbség: a projektben bekövetkezett változásokra adott reakció • A tervezés más-más szakaszban valósul meg • Az agilis projektben a tervezésről áttolódik a hangsúly a végrehajtásra • Nagymértékben eltérő alkalmazott projektvezetési technikák Agilis megközelítés Vízesés modell Sokszor a hibrid megoldások az üdvözítők! 8 QS agilis megközelítése 9 Agilis tévhitek, félelmek Tévhitek • Az agilis projekt lazán kezeli a határidőket • Az agilis projekt során nincs tervezés • Az agilis

fejlesztői közösségek • Az agilis megközelítés projektekben teamek felelősségmentes, nem alkalmazható laza fix-price Félelmek • Struktúra és dokumentáltság hiánya • Csak vezető fejlesztőkkel működik • Túl nagy szervezeti kultúra átalakítást kíván a bevezetés • Nehézkes szerződéses tárgyalásokhoz vezethet • Sok változás esetén hatékonyatlan lehet (refactoring) • Nehezen becsülhető egy projekt vagy nagyobb feladat erőforrásigénye • Scope-kezelés nehézkes követelményspecifikáció miatt lehet a hiányzó 10 SCRUM – egy elterjedt agilis eszköz • Praktikus ötletek gyűjteménye • Sprint (max. 2 napos feladatokkal) • Sprint Burn Down Chart • Product backlog (feladatok listája + prioritások) • ScrumMaster • Product Owner • Disznók és csirkék • Scrum stend-up meeting • Vizuális menedzsment eszközök • Team board • Burn-down chart További agile eszköz

példák • Lean menedzsment • A lean/kanban fejlesztés • TPDS (Toyota Product Development System) 11 Agilis esettanulmány NRG: Napi Földgáz és Kapacitás Kereskedelmi Piac által végrehajtott ügyletek klíringjét és elszámolását biztosító rendszer. Az agilis megközelítést választottuk mert: • Rögzített határidő, kevés idő, • Technológia ismerete, senior fejlesztők, • Kis csapat, rövid átfutási idő, rugalmas erőforrástervezés, • Nyitott követelményspecifikáció, • Erős tesztcsapat, automatizált tesztelés, • Az agilis fejlesztés követelményei iránt fogékony szervezet • Szenioritás, rendelkezésre állás, • Gyors reakcióidő, • Szóbeli konzultáció lehetősége, • Közös, helyszíni munkavégzés, • Közös kockázatvállalás, kölcsönös tisztelet, kompromisszumkészség. bizalom Hibrid megoldás vált be! 12 és Qualysoft agilis projektek NRG BOMA (Bonus Malus)

Kártörténeti Portálrendszer UniWeb (Univerzális KGFB és CASCO webservice) 13 QS Agilis konklúzió • Agilis projekt csak az ügyfél teljes támogatása mellett, közös erőfeszítésként lehet megvalósítani, különben garantált a kudarc. • Agilis projekt olcsóbb egy hagyományos (vízesés) projektnél, és lényegesen olcsóbb egy félrement (irányfunkcionalitás-technológia) projektnél. • Az agilis projekt alacsonyabb profitabilitást ígér a beszállítónak, (kevesebb CR lehetőség, több redundancia), de csökkenti a megvalósítási kockázatot és nagyobb ügyfélelégedettséget eredményez. • Az igazság félúton van, a hibrid megoldások beválnak. 14 Qualysoft Informatikai Zrt. 1124 Budapest, Németvölgyi út 97. Tel.: +36 1 889 9800 Fax: +36 1 889 9810 E-mail: office@qualysoft.hu www.qualysofthu Qualysoft Ressource und Entwicklung für Informationstechnologie GmbH 1180 Wien, Plenergasse 1/3 Tel.: +43 1 409 5987 Fax: +43 1 409

5987/11 E-mail: office@qualysoft.at www.qualysoftat Qualysoft Ressource und Entwicklung für Informationstechnologie GmbH 80336 München, Bavariaring 9 Tel.: +49 89 599 4360 Fax: +49 89 599 436/25 E-mail: office@qualysoft.de www.qualysoftde Qualysoft Informatics d.oo 11000 Beograd, Gospodar Jovanova 16/15 Tel.: +381 11 2624 679 Fax: +381 11 2624 679 E-mail: office@qualysoft.coyu www.qualysoftcoyu Qualysoft Information Technology SRL R - 011741 Bucharest Sector 1 Bvd. Iancu de Hunedoara 2 Tel.: +4 021 311 1865 Fax: +4 021 3185520 E-mail: office@qualysoft.com www.qualysoftcom