Az agilis szoftverfejlesztés kihívásai a való világban. Aki válaszol: Aki kérdez: Kocsis Árpád Section Manager Warranty IS, Nissan Europe

Az agilis szoftverfejlesztés kihívásai a való világban

Aki kérdez:

Aki válaszol:

Kocsis Árpád Section Manager Warranty IS, Nissan Europe

Janovszki Zsolt CSM, Stratégiai igazgató agilitas.hu Társszerző: Dr. Birloni Ferenc

Amiről itt ma szó lesz I. – Scrum, ahogy oktatják


Amiről itt ma szó lesz II. – A való világ


Amiről itt ma szó lesz III. – Zátonyok, avagy a biztos sikertelenség faktorai


Amiről itt ma szó lesz IV. – Csak hogy teljes legyen a kép


1. kihívás: Beszerzési Osztály

A projekt nem ott kezdődik, amikor a fejlesztők elolvassák a követelményeket…  A megrendeléshez sikerrel kell teljesíteni a beszerzésen!  Kötött beszerzési folyamat – nagyvállalatnál is  Írásos ajánlat: határidő + leszállítandók + ár  Ajánlatok összehasonlíthatósága, nincs kivétel  Aki megrendelést akar, az alkalmazkodik  És ez már nem agilis…


1. megoldás: Beszerzési Osztály Vannak olyan vállalatok, aki pályáztatnak egy fejlesztést. Ha itt meg akar felelni valaki, és nem eleve agilis contracting van (Magyarországon ilyet egy helyen hallottam, meg nagyon sok helyen nem) akkor muszáj a kiírásnak megfelelő ajánlatot tenni.  Árpi mondja: És ez már nem agilis… Ezzel elég nehéz vitatkozni. Ha írásban kap valaki ilyen ajánlatkérést, leghelyesebb nem elővezetni az agilis koncepciót, mert kiértékelhetetlen lesz az ajánlata Megoldás: El kell érni a potenciális megrendelőinknél a pilotokat. Amikor meg tudjuk mutatni, hogy egy fontos, de kis fejlesztési igényű feladat kapcsán lehet 1 hónapnyi dokumentáció írás helyett kész terméket kapni, az segíteni szokott a Beszerzési osztály rigorózus hozzáállásán.


2. kihívás: Jogi Osztály, szerződés

 Szerződés nélkül ne fejlesszünk szoftvert, viszont…  Sablon szerződések  A Jogi Osztály nem alkalmazkodik – a dolgát végzi  A szerződésnek kell legyen tárgya - leszállítandók  Átadás-átvétel definíciója  Ki miért felelős, ki mit csinál a projektben?  A fejlesztést szükségszerűen kötött keretbe zárja a szerződés – elveszik az agilitás


2. megoldás: Jogi Osztály, szerződés A leszállítandókat és az átadás-átvételt a SCRUM-nál jobban, ami konkrét tesztesetekhez köti az átvételt, nem nagyon definiálja jobban semmi. Ezt nem nehéz szerződésbe íratni, még ha a keretek kötöttek is. A MEGRENDELŐ fogja érezni, hogy nem lehetséges annyira ledokumentálni egy innovatív szoftvermegoldást, hogy a fejlesztés során ne merülne fel számtalan, a dokumentációban szereplőnél egyszerűbb, korszerűbb, összességében jobb megoldás egy-egy üzleti oldali problémára. Amennyiben meg tudjuk mutatni a fejlesztés megrendelőjének, hogy rugalmasan alkalmazkodunk az igények változásához (belső scrum), netán mi magunk javaslunk jobb megoldást, a megrendelő konstruktív lesz, és a Jogi Osztály sem lesz elégedetlen.


3. kihívás: Projektmenedzsment módszertan  Szoftverfejlesztési módszertan vs projektmenedzsment módszertan  A projekt a változás eszköze a nagyvállalatnál  Kötelező, nincs kivétel  Kötött, folyamat alapú  Tisztes mennyiségű dokumentáció szükséges  A szoftver fejlesztésnek alkalmazkodnia kell a projektvezetéshez

„There is no such a thing as an IT project. There are only business projects with IT component.” June Drewry Az agilis szoftverfejlesztés kihívásai a való világban

3. megoldás: Projektmenedzsment módszertan  Szoftverfejlesztési módszertan vs projektmenedzsment módszertan Az agilisan fejleszteni kívánó cégeknek muszáj tudomásul venni, hogyha egy vállalat nem akar agilisan fejlesztetni velük, akkor a hibrid módszertanból többnyire katasztrofális projekt lesz. A módszertant hajlítani művészet, feladni az alapelveit hiba. Olyan projektet kell találni, amikor meg lehet győzni a nagyvállalatot, hogy projekt szinten a dokumentáció gyártásnak negatív BV-járól. (Business Value) Ez nem egyszerű feladat, biztosan nem több éves projekten fog elkezdődni. Az agilis szoftverfejlesztés kihívásai a való világban

4. kihívás: PMO, QA  Nem a fejlesztők döntik el, hogyan fejlesztenek!  Céges standard (előírt módszertan) – feltehetőleg vízesés modell lesz  Folyamat alapú minőségbiztosítás  Ellenőrzés, audit  A nem-megfelelést kommunikálják a felsővezetés felé - következmények


4. megoldás: PMO, QA  Meg kell nézni, hogy beleillenek –e a QA policy-ba az adott módszertani elemek.  Ha nem, át kell beszélni, hogy mik azok a kötelező elemek, aminek a függvényeként meg kell találni a módszertani oldalon a megfelelő dolgot.


5. kihívás: Compliancy  Kulcsfontosságú a törvényi megfelelőség  Csakis a 100% megfelelőség elfogadható  Mit jelent ez a gyakorlatban? Folyamatokat és dokumentumokat  Ellenőrzés, audit  Agilitásnak nincs helye  Lehet, hogy a Product Owner és a Scrum Master nem is tudja, milyen előírásoknak kell megfelelni

Példa: SOX, NHH előírások, Nissan esetén JSOX


5. megoldás: Compliancy  A Scrum nem más mint keretrendszer, az agilitás pedig irányelvek gyűjteménye „set of principles”, amit adott környezetben az adott szituáció által meghatározott követelményekre szabottan lehet alkalmazni.  Nincs olyan projekt, amiben ne lennének határidővel kiadott feladatok (nevezzük sub-projekteknek) Ezekre a megoldás során mindig lehet (akár mikro környezetben) a bevált legjobb gyakorlatot alkalmazni.


6. kihívás: Üzemeltetés Nagyvállalatnál elválik a fejlesztés és az üzemeltetés!  A fejlesztőnek nincs köze (és hozzáférése) az éles rendszerhez  Az üzemeltetés erősen folyamat és dokumentum alapú (lásd ITIL, MOF)  A fejlesztőknek produkálniuk kell az üzemeltetés számára szükséges dokumentumokat és követniük a folyamatot  Agilis üzemeltetés nem létezik


6. megoldás: Üzemeltetés  Az agilis módszertanok tervezési dokumentációja lehet sajátos, DE az elkészült rendszerhez készült dokumentációt egytől egyig rendkívül akkurátusan megkövetelik (ha ITIL szerinti, akkor olyat).


7. kihívás: Globális környezet A multi földrajzilag és kulturálisan erősen széttagolt. A kulcsfelhasználók/szakértők szerte Európában vannak, és bármelyikük ráhatással lehet a projektre.  Nincs személyes találkozó  Sok kulcsfelhasználó, különböző igényekkel  Helyi specifikumok  Kommunikációs kihívások (időzóna, nyelv, kultúra)  A megoldás a kellő dokumentáció és folyamat-alapú megközelítés lenne… de az nem agilis…


7. megoldás: Globális környezet  Az agilitás nem tudja megoldani a cég szervezeti problémáit (amennyiben vannak), DE kitűnő módszertan ezen problémák a kimutatására, láthatóvá tételére. Ez az első lépés, a Scrum Master ezután tudja javítani a kommunikációt, figyelembe venni a helyi specifikumokat.  Agilis fejlesztés esetén a PO-nak kell begyűjteni kulcsfelhasználók (illetve az összes stakeholder) felvetéseit, különböző igényeit, és BEÁRAZNI azokat.


8. kihívás: Cross-functional környezet A Projekt Szponzor jóváhagyása kevés a sikeres projekthez! Sok csapat, ráhatással a projektre (pl EA, auditor, DBA)  Minden mindennel összefügg – nincsenek silók  Nem egyszemélyi döntések  Folyamatos konzultáció  Nem cég, hanem cégcsoport!  Hagyományos fejlesztésnél a folyamatok/review-k betartása növeli a projekt túlélési esélyeit Mi rengeteg időt töltünk a csapatok közötti kommunikációval és az együttműködés javításával. Az agilis szoftverfejlesztés kihívásai a való világban

8. megoldás: Cross-functional környezet

Az agilis módszertanok kötött iterációkkal dolgoznak (time box) ami kikényszeríti az együttműködést és kitűnő minőségű „mikro management”-t tesz lehetővé a nagy szervezetek funkcionálisan megosztott fejlesztői környezetében. NAGYON FONTOS, akkor és csak akkor, ha van megfelelő vezetés. Nagyon fontos, hogy ahol felmerül az, hogy a menedzsment nincs tisztában a kihívással, amit az agilis tranzíció jelet, ott el kell végezni az ‘agilis readiness’ auditot, és javaslatot tenni a management felkészítésére Megfelelően felkészült, a kihívások nagyságával tisztában lévő management nélkül semmiképpen nem szabad belevágni egy agilis „nagyprojektbe” Az agilis szoftverfejlesztés kihívásai a való világban

9. kihívás: A menedzsment nem agilis A nagyvállalatra alapvetően jellemző:  Feladat-határidő-felelős rutin  PDCA  Üzleti terv és stratégia  Top-down vezetés

Következmények:  Nem agilis  Nem a fejlesztők mondják meg, hogyan működjön a cég

„Tetszik az agilitás” = „Ti legyetek rugalmasak, de mi maradunk a beváltnál” Az agilis szoftverfejlesztés kihívásai a való világban

9. megoldás: A menedzsment nem agilis Az agilitással az tud élni, aki látja, hogy problémái vannak, és javítani akar rajtuk. A bevezetés a céges kultúra bármely szintjén elindítható – ott érdemes, ahol a legnagyobb problémák tornyosulnak – és ezen szint sikereire építve terjedhet sikerrel a céges kultúra minden irányában. A változásra képtelen management-tel semmit nem lehet mit csinálni. Ha a menedzsment nem érti azt, hogy mi az értelme az agilis fejlesztésnek, akkor nem szabad elkezdeni.


10. kihívás: Nincs félkész szoftver Minimális elvárás a 100% funkcionalitás. 99%-os szoftvert nem tudunk átvenni. A szoftver vagy megfelel a folyamatoknak/igényeknek, vagy nem. Az üzletmenet nem állhat le, tehát vagy a régi folyamatokat követjük, vagy az újakat. Nincs köztes állapot, nincs félkész folyamat, nincs félkész szoftver. Leaf-es példa: a termék nem a szoftver, hanem az autó.


10. megoldás: Nincs félkész szoftver

Nagyvállalati környezetben tehát a fele annyi idő alatt elkészült 80%-os, de már működő szoftver nem jelent versenyelőnyt. A multi cégnél nem lehet sales-elni azzal, hogy milyen hamar előáll majd ‘valami’, ami használható. Ott vagy agyontesztelt bolondbiztos megoldás van, vagy Quick’n’Dirty. Amit igyekeznek bármi áron elkerülni. Ha a fejlesztés Scope-ja 100% fixen, akkor a gyorsabban, kisebb kockázattal előállt szoftver a versenyelőny. Ebben tudnak segíteni az agilis módszertanok.


11. kihívás: IT Roadmap A szoftver hosszú távú fenntarthatóságának biztosításához hosszú távú informatikai tervezésre van szükség. Üzleti terv: 1-2 év

Szoftver életciklus: 4-10 év

 A rövid ciklusidő illúziója…  Minden máról holnapra alakul  A Product Owner csak az üzleti tervvel foglalkozik  Az informatikusok csak a sprinttel foglalkoznak Következmény: nincs IT tervezés és fenntarthatóság Következmény: performancia és kapacitás problémák Az agilis szoftverfejlesztés kihívásai a való világban

11. megoldás: IT Roadmap Ha a PO rosszul végzi a dolgát, és a SCRUM Master is, akkor ez bizonyára így is van. Ha és amennyiben a PO jól priorizál, ÉS MINDIG AZ ÖSSZES STAKEHOLDERREL TARTJA A KAPCSOLATOT (pl. üzemeltetés, ami gyakran kimarad), akkor mindig a legfontosabb dolgon dolgoznak a fejlesztők. Akik ha jól vannak menedzselve, végre is hajtják a feladatukat. Így maximális BV áll elő. Hol lehet a gond? Csak ott, hogy a szereplők lazán kezelik a feladataikat, és/vagy alkalmatlanok. Ha egy szoftverfejlesztő cég nem győződik meg arról, hogy az agilis projektben megrendelői oldalon alkalmas –e a PO, akkor ki van zárva a Success Story


Összefoglalás Kihívás

Megoldás

Beszerzési Osztály

Pilot

Jogi Osztály

Mozgatható Scope-ról meggyőzni

Projektmenedzsment

Pilot, Dokumentáció negatív BV

PMO/QA

Módszertani elemek adaptációja

Compliancy

Micro-scrum, ha más nem megy

Üzemeltetés

Dokumentáció tetszőleges lehet

Globális környezet

Árazás, árazás, árazás

Cross-functional

Tisztában lenni a kihívásokkal

Menedzsment

C-level nélkül nincs agilitás

Nincs félkész szoftver

Scope=100 a modellben, T<;$<.

IT Roadmap

Felkészült PO kell, aki menedzser Az agilis szoftverfejlesztés kihívásai a való világban

Agilis Útikalauz Beszállítóknak I.  Mi van ha:  A PO nem ért az informatikához és a menedzsmenthez?  a PO menedzser! Ha nem ért hozzá, az menthetetlenné teszi az agilitást egy projektben! Ha nem informatikus, attól még lehet sikeres PO, de akkor egy IT koordinátort kell behozni stakeholderként

 A megrendelő korlátai miatt sérülnek a módszertani alapelvek?  A hajlított és kifacsart módszertan különbségéről volt szó

 A megrendelő ragaszkodik a saját projektvezetési módszertanához?  Meg kell vizsgálni, hogy megéri-e a közel dupla munka? Ha nem, nincs tere a belső agilis projektvezetésnek. Az agilis szoftverfejlesztés kihívásai a való világban

Agilis Útikalauz Beszállítóknak II.  A módszertani upgrade szükségtelenségét a fejlesztők jó képességeivel magyarázzák  A módszertannal az garantálható, hogy a projekt végrehajtására amúgy képes emberek jobb eredményt elérni, a korábbi teljesítményükhöz képest

 Azt akarnánk mondani, hogy az ügyfél a hibás, mert nem ismerte a módszertant  Gyors és könnyű út a lapátra kerüléshez…  GOTO Csak hozzáértő ügyféllel állni szóba

 Éppen eltörnénk a PO nyakát, mert dőlnek a csontvázak  A PO a single breakable neck az csak a mesében van!!!  A szakértő módon menedzselt SCRUM projektben nincsenek csontvázak, mivel az ügyfél folyamatosan jól informált a szoftver állapotával kapcsolatban. Az agilis szoftverfejlesztés kihívásai a való világban

Agilis Útikalauz Beszállítóknak III.  Az ügyfél csak a feladatot szeretné kiadni?  Az agilitás alapja az ügyfél közreműködés. Indulás előtt kell kialakítani azokat a képességeket, ami alapján a PO tudja végezni a dolgát, és a menedzsment számára transzparensek lesznek a folyamatok,

 Agilizálni szeretnénk egy nagyvállalatot?  Minden vállalati folyamat optimalizálható ROI, BV szempontjából, DE egy kis-középvállalathoz hasonló szinten (gyakorlatilag teljeskörűen) agilizálni egy nagyvállalatot nem lehetséges


Kérdések? Kocsis Árpád Section Manager Warranty IS, Nissan Europe [email protected]

Janovszki Zsolt CSM, Stratégiai igazgató agilitas.hu [email protected]


Az agilis szoftverfejlesztés kihívásai a való világban. Aki válaszol: Aki kérdez: Kocsis Árpád Section Manager Warranty IS, Nissan Europe

Recommend Documents