Az agilis szoftverfejlesztés kihívásai a való világban Aki kérdez: Kocsis Árpád Section Manager Warranty IS, Nissan Europe Aki válaszol: 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
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.
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.
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
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
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
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 Beszerzési Osztály Jogi Osztály Projektmenedzsment PMO/QA Compliancy Üzemeltetés Globális környezet Cross-functional Menedzsment Nincs félkész szoftver IT Roadmap Megoldás Pilot Mozgatható Scope-ról meggyőzni Pilot, Dokumentáció negatív BV Módszertani elemek adaptációja Micro-scrum, ha más nem megy Dokumentáció tetszőleges lehet Árazás, árazás, árazás Tisztában lenni a kihívásokkal C-level nélkül nincs agilitás Scope=100 a modellben, T<;$<. Felkészült PO kell, aki menedzser
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.
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.
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 akocsis@nissan-europe.com Janovszki Zsolt CSM, Stratégiai igazgató agilitas.hu zsolt.janovszki@agilitas.hu