ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 65
Abonament PDF

De la Waterfall la Agile în SAP

Oana-Maria Bocârnea
Senior SAP ABAP Consultant @ Siemens



PROGRAMARE

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.

Universul SAP: descrierea lumii în care trăim

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.

Abordările Waterfall și Agile

Modelul Waterfall

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:

Modelul Agile

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.

Referințe:

Imagini

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects