Prima decizie ce trebuie luată în aplicarea proiectelor, indiferent de mediul de dezvoltare sau tehnologie, se referă la selectarea metodologiei optime de dezvoltare care ar trebui folosită. Această temă beneficiază de o atenţie progresivă. Multe articole se întreabă dacă nu cumva creativitatea programatorilor este restricţionată de adoptarea unor pași standard ce trebuie urmaţi. Acest aspect este vital deoarece metodologia aleasă determină modul de desfășurare a proiectului. Cele mai cunoscute metodologii sunt Waterfall și Agile. Deși SAP dispune de ASAP pentru implementarea ERP în dezvoltarea de software , Waterfall și Agile sunt și ele populare. Articolul se va concentra pe modul în care alegem cea mai bună variantă pentru universul SAP.
Deoarece SAP nu este un subiect familiar multor programatori, să începem cu elementele de bază. În lumea SAP, un "landscape" este un set de servere pe care rulează software SAP. Acesta poate fi divizat în unul sau mai multe medii ("environments"), care sunt instanţe separate, independente. Deși aceste medii nu sunt dependente unele de altele, conţinutul se poate muta între medii prin intermediul transporturilor ("transports"). Un transport conţine aplicaţiile și configuraţiile pe care dorești să le muţi, precum și niște instrucţiuni care explică cum se împachetează și cum se despachetează conţinutul. Totul poate părea complicat, dar e o metodă sigură. SAP este folosit pentru a automatiza funcţiile unui business. Așadar, dacă una din părţile acestui proces de automatizare nu mai funcţionează, nu vor mai funcţiona nici procesele dependente. Pentru ca acest lucru să nu se întâmple, SAP vă recomandă ca sistemul vostru să conţină o secvenţă de cel puţin trei medii: Dezvoltare (DEV), Asigurarea calităţii (QAS), Producţie (PRD).
Aceste medii sunt ca un filtru, iar problemele pot fi evitate în producţie. Primul filtru este mediul DEV, unde sunt create aplicaţiile și configuraţiile. Aceste obiecte sunt transportate în mediul QAS pentru testare. În mediul QAS, funcţiile business sunt simulate pentru a găsi erorile existente înainte ca soluţia să meargă în producţie. Bugurile găsite sunt reparate în mediul DEV, iar soluţia ajunge din nou în mediul QAS pentru retestare. Al treilea mediu este producţia (PRD.) PRD este ceea ce ce folosește clientul și soluţia finală de business. Modelul descris ar trebui să permită evitarea marilor probleme din cadrul procesului "Go-Live". Problemele neprevăzute ce vor apărea în ciclul de viaţă a sistemului vor fi rezolvate prin același ciclu.
SAP a dezvoltat metodologia ASAP (Accelerated SAP) pentru ca implementarea de proiecte să se muleze pe "landscape"-ul descris. Fazele implementării de proiect în ASAP sunt: pregătirea proiectului ("Project Preparation"), modelarea ("Blueprinting"), realizarea ("Realization"), pregătirea finală ("Final Preparation"), suportul și faza operativă ("Go- Live"). Este important de știut că fazele ASAP se succed una alteia, iar 70% din activităţile dintr-o fază depind de finalizarea activităţilor din faza precedentă. Totuși, unele activităţi trec de la o fază la alta. Deoarece SAP are o creștere mare în cloud, s-au introdus și metodologiile SAP Launch și SAP Active Implementation pentru portofoliul Cloud. Poate părea complicat la început, dar, odată ce l-aţi înţeles, vă va plăcea.
Waterfall este un model de dezvoltare secvenţială și non-iterativă. Este metoda de implementare cea mai structurată care trece prin următoarele faze: cerinţe ale aplicaţiei ("requirements"), modelare ("design"), scriere de cod și testare ("coding and testing"), de sus în jos.
Fiecare pas este un stadiu distinct al dezvoltării software, fiecare etapă terminându-se înainte să înceapă următoarea. Această abordare, ca oricare alta, are atât avantaje cât și dezavantaje.
Avantaje:
Dezavantaje:
Agile este o abordare iterativă, centrată pe echipă, ce pune accentul pe livrarea rapidă a unei aplicații formate din componente complet funcționale.
Activitățile ("tasks") și programul de lucru sunt împărțite în unități mici de implementare numite "sprints" sau iterații. Iterațiile sunt perioade limitate de timp ('time-boxed"). Fiecare sprint are o durată clar definită și o listă de elemente ce trebuie livrate și planificate la începutul sprintului. Dacă munca planificată în sprint nu este finalizată, aceasta este reprogramată pentru următoarea iterație.
Munca finalizată poate fi revizuită și evaluată de echipă și de client, prin builduri zilnice și demo-uri de final de sprint. Două dintre cele mai des utilizate abordări Agile sunt SCRUM și KANBAN. Un proces Scrum se distinge de alte procese Agile prin concepte și practici specifice, împărțite pe trei paliere: Roluri, Artifacte și Unități de timp ("Time Boxes").
Avantajele abordării Agile sunt:
Iată și dezavantajele:
Învațarea prin practica sa:
Lucrurile pe care trebuie să le învăţăm înainte de a le face, noi le învăţăm făcându-le - Aristotel
Pentru a lua o decizie în legătură cu proiectele unde se face tranziție de la Waterfall la Agile este nevoie de puțină istorie.
Limbajul ABAP (EN: Advanced Business Application Programming, DE: Allgemeiner Berichts-Aufbereitungs-Prozessor ) a fost dezvoltat în 1980 ca limbaj al rapoartelor SAP. Până în 1999, limbajul a fost un limbaj de programare procedural, iar aplicațiile SAP erau aplicații dezvoltate procedural (Rapoarte, Grupuri de funcții și Tranzacții) ce au funcționat perfect cu metoda Waterfall. La începutul și mijlocul anilor '90 programarea orientată pe obiecte a devenit metodologia predominantă de programare, susținută de cele mai populare limbaje de programare precum C++, Objective-C, Pascal, C# și multe altele. Deci, realitatea pieței a determinat concernul SAP să extindă limbajul ABAP ca să suporte și programarea orientată pe obiecte. Această extensie a apărut în 1999 și s-a numit ABAP Objects. Obiectivul programării procedurale este de a sparge o activitate ("task") de programare într-o colecție de variabile, structuri de date, subrutine, în timp ce obiectivul programării orientate pe obiecte este de a sparge o activitate ("task") de programare în obiecte care expun comportamente (metode) și date (membri sau atribute) ce folosesc interfețe. Cea mai importantă deosebire este că, în timp ce programarea procedurală utilizează proceduri pentru a opera asupra structurilor de date, programarea orientată pe obiecte le satisface pe ambele, astfel încât un obiect, ce este o instanță a unei clase, operează asupra propriei structuri de date. În aceeași perioadă, metodele de dezvoltare de software au evoluat ca alternative la abordarea Waterfall. De exemplu, în 1991 a apărut rapid application development (RAD), iar în 1995 Agile-Scrum. Putem spune că evoluția limbajelor de programare a dus la crearea de noi metodologii.
SAP a început să dezvolte noi aplicații ce au la bază orientarea pe obiecte utilizând metode Agile pentru a organiza activitatea de dezvoltare, dar au observat că aplicațiile vechi trebuie și ele actualizate.
O astfel de schimbare s-a produs în 2011. O aplicație veche de 20 de ani, dezvoltată în vechiul limbaj ABAP utilizând metoda Waterfall a fost adusă la zi, adăugându-se noi funcționalități și extensii. Deoarece estimarea efortului și pașii au fost greu de documentat și prezis, s-a decis utilizarea Agile-Scrum ca metodă pentru acest proiect. A fost nevoie de multă pregătire pentru a facilita migrarea. Au fost multe impedimente: reutilizarea elementelor deja dezvoltate, schimbarea gândirii oamenilor, costuri reduse etc. . O altă provocare a fost aducerea echipelor la un loc, deoarece personalul se afla în trei țări: România, Austria și Germania.
Aplicația a migrat și s-a extins. Era o aplicație software în domeniul sănătății care avea nevoie de mentenanță pe termen lung. Vechiul proces de mentenanță nu s-a potrivit cu Agile-Scrum deoarece bugurile și problemele nu puteau fi împărțite pe sprinturi. De asemenea, efortul necesar pentru rezolvarea bugurilor este dificil de estimat deoarece trebuie mai întâi să se identifice problemele pentru a putea fi reparate. Deoarece tichetele de mentenanță au trebuit prioritizate și era nevoie de menținerea evidenței lor, s-au folosit anumite elemente ale abordării Kanban.
Programatorii din echipele Scrum au următoarea părere despre experiența prin care au trecut: "Din punctul de vedere al dezvoltării, Scrum s-a potrivit cel mai bine. În majoritatea cazurilor, funcționailtățiile "user stories" se bazau pe specificații vechi de 10 ani, care în unele cazuri erau supuse modificărilor de dezvoltare curente.
Deoarece Scrum era nou pentru toată lumea, chiar și pentru Scrum Master, în primele șase luni am ajustat procesul în fiecare retrospectivă de sprint. La final am convenit să avem un sprint de patru săptămâni cu o săptămână rezervată pentru revizii, planificare și retrospectivă, cu ședințe de "stand up" marțea și joia. A trebuit să învățăm să ne calibrăm activitățile , velocitatea și rafinarea funcționalităților , astfel încât orice programator din echipă să poată începe să muncească la ele. Pe scurt, a luat echipei aproape un an pentru a-și atinge velocitatea potențială, dar a oferit programatorilor posibilitatea de a se specializa pe anumite părți ale proiectului. Cel mai util instrument de lucru a fost Product Canvas introdus după primul release. Acesta a fost o schiță a următorului release ce permitea vizualizarea activității ("task") din timp, permițând și vizualizarea țintei pentru release. După primul release, echipa noastră a simțit nevoia unei vederi de ansamblu a următorului release. Am luat o pagină din 'Waterfall' și am realizat o schiță la nivel înalt cu una-două zile înainte de planul de release." (Peter Tako)
Proiectul este mare și va continua să crească; conține multe schimbări și modificări, având nevoie de implicarea constantă a clientului. Metodologia Agile-Scrum se folosește și în prezent, deși trebuie recunoscut că avantajele Waterfall lipsesc uneori. Din fericire, Scrum permite ajustarea procesului, dacă echipa consideră acest aspect util. Astfel, metodologia de dezvoltare, evoluează împreună cu proiectul. Această abordare este o îmbunătățire majoră adusă modelului rigid Waterfall care limitează creativitatea echipelor de dezvoltare. Totuși, Agile-Scrum trebuie îmbunătățit, deoarece proiectele mari, precum cel descris, dovedesc că nicio metodologie nu este perfectă, deși așa pare la început.
de Diana Costa
de Claudia Jelea , Mihai Jelea
de Ovidiu Mățan
