Delimitări conceptuale [303312]

Introducere

Delimitări conceptuale

1.1 Introducere Agile

De-a [anonimizat] a planifica structura și procesul de dezvolare a [anonimizat]. [anonimizat] o [anonimizat] o [anonimizat], sau privitoare la echipa ce se ocupă de respectivul proiect.

Dezvoltarea de software agilă este denumirea unui grup de metodologii de dezvoltare software ce sunt bazate pe principii comune. [anonimizat] (ce trebuie incurajată de liderul acesteia), auto-[anonimizat] a [anonimizat]. [anonimizat], colaborare și adaptabilitate pe întreg parcusul de evoluție al proiectului.

În 2001, 17 persoane cu contribuții în acest domeniu s-au întâlnit pestru a discuta modalități de a [anonimizat], rapid, centrat în jurul omului. Astfel au conceput Manifestul Agile ce cuprinde următoarele valori:

Indivizii si interacțiunea mai important decât procesele și instrumentele

Software funcționabil mai important decât o documentație foarte amplă

Colaborarea cu clientul mai important decât negocierea contractului

Receptivitate la schimbare mai important decât urmărirea unui plan

Caracteristicile metodologiei Agile :

Este iterativă: o iterație are între 1-4 saptămîni,la finalul fiecarei iteratii sunt livrate anumite funcționalități ale proiectului.

Este bazată pe timp:durata iterației e fixă și nu poate fi modificată pe parcursul proiectului. În acest fel există întotdeauna un rezultat productiv la finalul iterației.

Deschisă către client:la finalul fiecărei iterații există un rezultat care poate fi prezentat clientului.

Bazată pe livrarea de versiuni intermediare ale produsului: fiecare iterație va implementa complet toate “task-urile” cuprinse în acea iterație.

1.2 Ciclul de viață al elaborării produsului program

Ciclul de viață a unui produs program – O secvența de etape în existența produsului soft. Sunt incluse toate activitățile necesare pentru dezvoltarea produsului și relațiile temporale dintre ele.

Fiecare etapă din ciclul de viața este caracterizată prin activități specifice și produsele rezultate din activitățile respective.

Există patru faze fundamentale ale metodologiilor ingineriei programării:

analiza (ce dorim să construim);

proiectarea (cum vom construi);

implementarea ([anonimizat]);

testarea (asigurarea calității).

[anonimizat] „naștere” până la „moarte”: lansare, întreținere, ieșire din uz.

[anonimizat]. Aici se definește problema pe care clientul dorește să o rezolve. [anonimizat].

Documentul încearcă să redea cerințele din perspectiva clientului, definind scopurile și interacțiunile la un nivel descriptiv înalt, independent de detaliile de implementare, cum ar fi, de exemplu: formularea problemei, așteptările clientului sau criteriile pe care trebuie să le îndeplinească produsul.

Faza de analiză poate fi văzută ca o rafinare a detaliilor. Distincția dintre detaliile de nivel înalt și cele de nivel scăzut sunt puse mai bine în evidență de abordările top-down (unde se merge către detaliile de nivel scăzut) și bottom-up (care tind către detaliile de nivel înalt).

Documentul cerințelor poate fi realizat într-o manieră formală, bazată pe logică matematică, sau poate fi exprimat în limbaj natural. În mod tradițional, el descrie obiectele din sistem și acțiunile care pot fi realizate cu ajutorul obiectelor. Aici noțiunea de „obiect” nu trebuie confundată cu obiectul din programarea orientată obiect. Descrierea obiectelor și acțiunilor trebuie să fie generală și să nu depindă de o anumită tehnologie. Desigur, într-o abordare POO, descrierile vor lua forma obiectelor și metodelor, însă în alte abordări, obiectele pot fi de exemplu servicii care accesează baze de date.

Faza de proiectare

Pe baza cerințelor din faza de analiză, acum se stabilește arhitectura sistemului: componentele sistemului, interfețele și modul lor de comportare:

Componentele sunt blocurile de construcție ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o bibliotecă de componente. Componentele rafinează și capturează semnificația detaliilor din documentul cerințelor;

Interfețele ajută la îmbinarea componentelor. O interfață reprezintă granița dintre două componente, utilizată pentru comunicarea dintre acestea. Prin intermediul interfeței, componentele pot interacționa;

Comportamentul, determinat de interfață, reprezintă răspunsul unei componente la stimulii acțiunilor altor componente.

Documentul de proiectare descrie planul de implementare a cerințelor. Se identifică detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma, algoritmii, structurile de date, definițiile de tip globale, interfețele, etc.

3. Faza de implementare

În această fază, sistemul este construit, ori plecând de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui să știe exact ce trebuie să construiască, chiar dacă rămâne loc pentru inovații și flexibilitate. De exemplu, o componentă poate fi proiectată mai restrâns, special pentru un anumit sistem, sau mai general, pentru a satisface o direcție de reutilizare.

Echipa trebuie să gestioneze problemele legate de calitate, performanță, biblioteci și debug. Scopul este producerea sistemului propriu-zis. O problemă importantă este îndepărtarea erorilor critice. Într-un sistem există trei tipuri de erori:

Erori critice: Împiedică sistemul să satisfacă în mod complet scenariile de utilizare. Aceste erori trebuie corectate înainte ca sistemul să fie predat clientului și chiar înainte ca procesul de dezvoltare ulterioară a produsului să poată continua;

Erori necritice: Sunt cunoscute, dar prezența lor nu afectează în mod semnificativ calitatea observată a sistemului. De obicei aceste erori sunt listate în notele de lansare și au modalități de ocolire bine cunoscute;

Erori necunoscute: Există întotdeauna o probabilitate mare ca sistemul să conțină un număr de erori nedescoperite încă. Efectele acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi rezolvate cu patch-uri sau eliminate în versiuni ulterioare.

Faza de testare

Calitatea produsului software este foarte importantă. Multe companii nu au învățat însă acest lucru și produc sisteme cu funcționalitate extinsă, dar cu o calitate scăzută. E mai simplu să-i explici clientului de ce lipsește o anumită funcție decât să-i explici de ce produsul nu este performant. Un client satisfăcut de calitatea produsului va rămâne loial firmei și va aștepta noile funcții în versiunile următoare.

În multe metodologii ale ingineriei programării, faza de testare este o fază separată, realizată de o echipă diferită după ce implementarea s-a terminat. Motivul este faptul că un programator nu-și poate descoperi foarte ușor propriile greșeli. O persoană nouă care privește codul poate descoperi greșeli evidente care scapă celui care citește și recitește materialul de multe ori. Din păcate, această practică poate determina o atitudine indiferentă față de calitate în echipa de implementare.

Tehnicile de testare sunt abordate preponderent din perspectiva producătorului sistemului. În mod ideal, și clientul trebuie să joace un rol important în această fază.

Ciclul de viață diferă în funcție de:

Experiența, abilitățile și cunoștințele membrilor echipei de dezvoltare;

Gradul de cunoaștere și experiența în afacerea vizată de sistem;

Tipul domeniului aplicației;

Schimbările de mediul afacerii;

Schimbările din interiorul afacerii;

Dimensiunea proiectului.

1.3 Prezentare succintă a metodelor Agile

De-a lungul timpului au apărut diverse metode care au la baza unele dintre aceste valori și principii. Ele au fost denumite metodologii agile, iar printre ele se numără:

Programarea extremă (XP)

Scrum

Proces unificat agil (AUP)

Modelare agilă

Proces unificat esențial (EssUP)

Proces unificat deschis (OpenUP)

Metoda de dezvoltare dinamică a sistemelor (DSDM)

Dezvoltare bazată pe caracteristici (FDD)

Crystal

Programarea Extremă

Această metodologie a fost creată pentru a îmbunătăți calitatea produsului software și adaptarea la schimbările nevoilor clientului. Fiind un tip de metodologie Agile, susține frecvente “eliberări” în ciclurile de dezvoltare scurte, pentru a îmbunătăți productivitatea și pentru a introduce puncte de control la care pot fi adaptate noile nevoi ale clienților. Modelarea Extremă este descrisă că o discplina de dezvoltare software care organizează oamenii pentru a fi mai productivi în realizarea software-ului de înalta calitate. Această cuprinde 4 activități de baza care sunt folosite în procesul de dezolvate software și anume: programarea, testarea, ascultarea și partea de design. Valorile pe care le cuprinde sunt următoarele: comunicarea , simplitatea( încurajează începerea cu cea mai simplă soluție iar celelate funcționalități pot fi adăugate pe parcurs), feedback-ul (feedback de la sistem, feedback de la client și feedback de la echipa de lucru), curajul , respectul.

Proces Unificat Agil

Versiune simplificată a Procesului Rațional Unificat. Acest proces descrie o abordare ușor de înțeles, simplă a dezvoltării de aplicații software folosind tehnologii agile. Procesul Unificat Agil aplică tehnologii agile cum ar fi: modelarea agilă, schimbarea agilă a managementului , dezvoltarea test-driven pentru a îmbunătăți productivitatea. Metodologia procesului unificat agil cuprinde șapte discipline: Model, Implementare (transformarea modelului în cod executabil), Testarea (evaluare obiectivă pentru a asigura calitatea) , Livrarea, Managementul de configurare, Managementul de proiect, Mediul. Alături de cele șapte discipline, acest proces se bazează pe următoarele principii:Simplitate (totul este descris concis, folosind un număr cât mai mic de pagini), Agilitate, Concentrare pe activitățile de importantă mai mare, Independența Tool-urilor (poți folosi orice instrument dorești, cu precizarea că acel instrument trebuie să fie cel mai bun în realizarea produsului final) , Echipa știe ce trebuie să facă (această metodologie oferă legături la cele mai multe dintre detaliile despre proiect).

Modelarea agilă (AM)

Modelarea agilă reprezintă o metodologie pentru modelare și documentare a sistemelor software baza pe cele mai bune practici. Această este o colecție de valori și princpii care pot fi aplicate la un proiect de dezvoltare software. Metodologia este mult mai flexibilă decât metodele de modelare tradiționale, potrivindu-se mai bine într-un mediu care se află într-o contiua schimbare. Modelarea agilă este un supliment pentru celelalte metodologii agile cum ar fi Scrum, Programarea extremă și Procesul Rațional Unificat.

Procesul Unificat Esential (EssUp)

Acest proces a fost inventat de Ivăr Jacobson că o îmbunătățire a Procesului Rațional Unificat. Procesul identifica practicile: cazuri de utilizare, dezvoltarea iterativă, practici de echipa, practici de procese, care sunt împrumutate de la dezolvarea agilă. Ideea este că poți alege acele practici care se pot aplică pentru situația ta și că le poți combină în procesul tău de dezvoltare. EssUp este prezentat sub formă unor cărți de joc, fiecare carte descrie o practică. Ivăr Jacobson a ales aces mod de prezentare pentru că el crede că oamenii îi cumpără cărțile dar puțini dintre ei le și citesc. Este anunțat că EssUp este sprijinit de IBM Rațional, Eclipse și Microsoft Visual Studio.

Procesul Unificat Deschis (OpenUp)

Procesul Unificat deschis face parte din procesul Eclipse Framework (EPF), un proces cadru open source dezvoltat de Fundația Eclipse. Scopul acestui proces este de a face mult mai simplă adoptarea Procesului Rațional Unificat. Acest proces păstrează caracteristicile esențiale alea Procesului Rațional Unificat, care incluse dezvoltarea iterativă, cazuri de utilizare și dezvoltarea scenariilor. Majoritatea părților opționale din RUP au fost excluse și multe elemente au fost fuzionate. Rezultatul este un proces mult mai simplu care se bazează pe principiile RUP. Procesul Unificat Deschis țintește echipele mici interesate de dezvoltarea agilă și iterativă. Proiectele mai mici au echipe formate din 3 până la 6 oameni și implică o muncă de la 3 până la 6 luni.

Feature driven development (FDD)

Fdd este un proces iterativ de dezvoltare software. Acest proces combină o serie de practici bune din industrie într-un tot coeziv. Scopul principal este de a livra software funcțional într-un timp util. Fdd a fost creat pentru un proiect de dezvoltare software de 15 luni, la care lucrau 50 de persoane, la o banca mare din Singapore. Acesta cuprindea un set de 5 procese : modelul total, listarea, planificarea, design și construirea de funcții noi. Datorită folosirii cu succes în acest proiect, Fdd a avut numeroase implementări de-a lungul timpului.

Estimarea în Agile

Estimarea este una dintre problemele cele mai dificile cu care se confruntă toate părțile implicate într-un proiect software. Pornind de la calcule simple și până la algoritmi complecși, estimările pot fi foarte dificil de realizat în industria IT, datorită lipsei constantelor din tehnologia actuală. Spre deosebire de alte industrii, nu se poate calcula cu precizie cât va dura un task, deoarece există prea mulți factori de luat în considerare, factori care includ tehnologiile folosite, experiența pe proiect, resursele fizice pe care va rula proiectul etc.

În Agile există două tipuri de estimări care se folosesc în mod frecvent, și anume estimarea bazată pe puncte (story point) și estimarea bazată pe zile de dezvoltare (ideal developer days). Deși în trecut estimarea pe zile a fost mai des folosită, metodologiile tradiționale având nevoie de estimări stricte pe perioade lungi de timp, odată cu apariția Agile a inceput să prindă contur estimarea bazată pe puncte .

În ambele cazuri, estimarea are loc în 4 pași standard, care se pot vedea în figura de mai jos:

Clientul descrie user-story-urile

Dezvoltatorii estimează individual

Are loc o discuție pe baza estimărilor, ăn care se aduc argumente de ce s-a estimat astfel

Dezvoltatorii estimează din nou individual

Dacă este nevoie, ultimii 2 pași se pot repeta până când se ajunge la un consens.

Fig.1.1. Pașii în estimarea Agile

1.4.1 Estimarea pe zile

Acest tip de estimare are o istorie lungă, fiind folosit de foarte multă vreme si continuă să fie folosit frecvent. Întreaga echipă se reunește în sedința de Sprint planning, se decide ce se va livra în cadrul sprintului (acel Sprint backlog, alcătuit din user-storyuri), apoi fiecarui user-story i se va atașa un număr de zile în care trebuie să fie terminat. Aceste zile reprezintă de fapt numărul de zile în care va putea fi rezolvat de către un singur dezvoltator. Este o estimare simplă și nu necesită găsirea de legături între userstory-urile dintr-un sprint.

Uneori se folosește în acest caz estimarea în 3 puncte, care se realizează precum urmează:

se decide cam cât ar dura realizarea taskului;

se decide cât va dura în cel mai bun caz și în cel mai rău caz;

se face media celor 3 estimări, rezultând estimarea finală;

1.4.2 Estimarea folosind puncte

Acest tip de estimare presupune compararea user-story-urilor între ele. Se începe prin a se alege cel mai simplu user-story (cel a cărui durată se presupune a fi cea mai mică) și i se asignează un punctaj de 1. Apoi toate celelalte user-story-uri vor fi comparate cu primul și apoi între ele, asignându-li-se numere din șirul lui Fibonacci (1, 2, 3, 5, 8 etc.). Apoi user-story-urilor cele mai simple li se va asigna un număr de ore sau zile (manhours, man-days), iar celorlalte li se vor asigna estimări egale cu estimarea celei mai simple înmulțită cu numărul din șirul lui Fibonacci aferent.

Astfel se pot lua în calcul și eventualele întârzieri (similar cu un worst-case-scenario), spre deosebire de estimarea simplă pe zile. O variantă a estimării folosind puncte este planificarea poker, denumită astfel deoarece se folosesc cărți de joc sau cartonașe conținând numerele din șirul lui Fibonacci. Fiecare membru al echipei primește un set de astfel de cartonașe și estimează, pe rând, câte un user-story. Important este la acest tip de estimare ca toți membrii echipei să arate cartonașele pentru același user-story în același timp, pentru a nu fi influențati între ei. Se presupune că toți vor da aceeași estimare sau foarte asemănătoare. Dacă se întâmplă totuși să fie diferențe foarte mari, cei care au estimarea diferită de medie vor trebui să explice de ce au ales această soluție și apoi se va vota din nou. Detalii în figura următoare.

Fig.1.2. Cărți specifice estimării poker

Metodologia SCRUM

Unul dintre principiile cheie care stau la baza metodologiei Scrum este înțelegerea faptului că pe parcursul dezvoltării unui produs software, clientul se poate răzgândi în legătură cu ceea ce vrea, legătură cu ce are nevoie.Aceste provocări imprevizibile nu pot fi rezolvate cu ușurință folosind metodologiile tradiționale de planificare și astfel metodologia Scrum adopta o abordare emipirca : acceptă faptul că problema nu poate fi înțeleasă și definită complet, concentrându-se pe a maximiza abilitatea echipei de programatori de la livra produsul rapid și dea a răspunde la cererile ce apar pe parcursul dezvoltării.

Astfel, metodologia Scrum este definită că o strategie de dezvoltare flexibilă și holistică în care echipa de dezvoltare lucrează împreună pentru a atinge un obiectiv comun, spre deosebire de abordarea tradițională, secvențială.

Numele metodologiei este preluat din sportul de echipa Rugby. În acest sport, denumirea Scrum se referă la o grupare de jucători care stau unul lângă celălat, foarte apropiați cu capul în jos și încearcă obțină posesia balonului, așa cum și în cazul dezvoltării de produse software echipa trebuie să fie foarte unită și să lucreze împreună pentru țelul comun.

Scrum este o metodă de dezvoltare Agile si management de proiect bazată pe flexibilitate la schimbări si planificare inițială minimală. Procesul Scrum se realizează în scurte iterații numite sprinturi, care durează până la patru săptămâni. Fiecare sprint începe cu o sedință scurtă de planificare și se finalizează cu un review. Ideea principală este de a lăsa dezvoltatorilor posibilitatea de a se auto planifica, întrucât ei sunt cei mai in măsură să estimeze si să realizeze corect livrarea și de asemenea de a rezolva problemele pe măsură ce acestea apar. În momentul de față este cea mai des folosită metodă din categoria Agile, de sine stătătoare sau în combinație cu altele.

Roluri în cadrul metodologiei Scrum

În cadrul metodologiei Scrum există trei roluri principale și mai multe roluxi auxiliare. Cele trei roluri principale sunt: Product owner, Scrum master și echipa de dezvoltare.

Product owner-ul reprezintă vocea clientului, și este în cele mai multe cazuri coordonatorul echipei clientului. El este cel care definește și stabilește funcționalitățile prioritare și alege dată și conținutul fiecărui sprint(vom prezența termenul ulterior) pe baza volumelor de lucru comunicate de către echipa.

Comunicarea este principala funcție a product owner-ului. Abilitatea de a transmite prioritățile și de a empatiza cu membrii echipei de dezvoltare și clientul sunt vitale pentru a duce proiectul pe direcția cea bună. Product owner-ul face astfel legătură între echipa și client, cum putem vedea și în figura:Fig.2.1. Reprezentarea grafică între Product Owner și echipă

Ca reprezentantul echipei în fața clientului, printre sarcinile de comunicare ale product owner-ului către client sunt :

anunța lansările produsului

comunică starea echipei

organizează rezumate ale punctelor cheie

explică clientului procesul de dezvoltare

negociază prioritățile, scopul , fondurile și programul

se asigură că restanțele proiectului sunt vizibile, transparente și clare

Empatia este atributul cheie necesar unui product owner, abilitatea de a se pune în pielea celuilalt. Un product owner va discuta cu diferiți reprezentați ai clientului, fiecare dintre ei având cunoștințe mai vaste sau mai puțin vaste privind procesul de dezvoltare software și este foarte important ca product owner-ul să poată vedea lucrurile din punctul lor de vedere.

Echipa de dezvoltare este responsabilă cu livrarea produsului în diverse stagii după fiecare Sprint. O echipă este alcătuită din 3-9 persoane și adună la un loc specialiștii necesari în cadrul unui proiect și anume : arhitectul, designerul, programatorul, testerul , etc. Echipele de Dezvoltare au următoarele caracteristici:

Ele se auto-organizează. Nimeni (nici măcar Scrum Master-ul) nu spune Echipei de Dezvoltare cum să transforme elementele din Product Backlog în potențiale Incrementuri ale funcționalității ce pot fi lansate pe piață;

Echipele de Dezvoltare sunt inter-funcționale și au toate competențele necesare ca echipă pentru a crea un Increment al produsului;

Scrum nu recunoaște nici un titlu pentru membrii Echipei de Dezvoltare altul decât Dezvoltator, indiferent de munca care a fost efectuată de persoana respectivă; nu există excepții de la această regulă;

Scrum nu recunoaște sub-echipe ale Echipei de Dezvoltare, indiferent de anumite domenii particulare cum ar fi testarea sau analiza afacerii; nu există excepții de la această regulă; și,

Diferiți membri ai Echipei de Dezvoltare pot avea competențe specializate și zone de focalizare, dar responsabilitatea aparține Echipei de Dezvoltare ca un întreg.

Scrum Master-ul facilitează buna desfășurare a proiectului, are grijă ca fiecare membru să poată lucra la capacitate maximă eliminând impedimentele și protejând echipa de perturbările exterioare. De asemenea, acordă o atenție specială respectării diferitelor faze Scrum.

Printre responsabilitățile de bază ale unui Scrum Master se număra :

să îl ajute pe Product Owner să mențină restantele proiectului în așa fel încât proiectul să fie bine definit și echipă să poată avansa încontinuu

să determine definiția de finalizat pentru un proiect cu ajutorul informațiilor de la întreaga echipă Scrum

să antreneze echipa de dezvoltare în gândirea Scrum pentru a finaliza proiectul

să promoveze auto-organizarea în interiorul echipei de dezvoltare

să elimine toate impedimentele ce stau în calea echipei de dezvoltare, atât cele interne cât și cele externe

să faciliteze întâlnirile de echipă pentru a asigura progresul continuu

În figura următoare putem observa mai bine rolurile în cadrul metodologiei Scrum : 

Fig.2.2. Rolurile în cadrul Metodologiei Scrum

Evenimentele Scrum

Evenimentele prestabilite în mod regulat din Scrum sunt utilizate pentru a minimiza necesitatea unor reuniuni ocazionale. Toate evenimentele sunt limitate ca timp, în așa fel încât fiecare are o durată maximă. Odată ce Sprint-ul începe, durata lui este fixă și nu poate fi micșorată sau mărită. Celelalte evenimente se pot termina atunci când scopul evenimentului a fost atins, asigurându-se ca se petrece suficient timp, fără a permite pierderi în procesul de planificare.

În afara Sprint-ului propriu-zis, care este un container pentru toate celelalte evenimente, fiecare eveniment în Scrum reprezintă o oportunitate formală de a inspecta și a adapta ceva. Aceste evenimente sunt concepute special pentru a permite o transparență decisivă și inspecție. Omiterea includerii oricăruia dintre aceste evenimente duce la o transparență redusă și de asemenea este o ocazie pierdută de a inspecta și a adapta.

Sprint-ul

Un sprint(numit și iterație) este principala unitate de dezvoltare în cadrul metodologiei Scrum. Un sprint are o durată fixă stabilită în prealabil ce poate lua valori între 7 și 30 de zile, deși cel mai des sunt utilizate sprint-urile de 15 zile ( două săptămâni).

Fiecare sprint începe cu o ședința de planificare ce are ca scop definirea sarcinilor ce trebuiesc realizate în cadrul sprint-ului. Aceste task-uri sunt organizate în sprint backlog și pentru fiecare task sunt estimate durata acestuia în ore de muncă și sunt stabilite persoanele care vor lucra la acest task. Fiecare sprint va avea la sfârșit o ședința de retrospectivă în care se discută despre progresul realizat în timpul sprint-ului și produsul realizat în cadrul sprint-ului poate fi prezentat clientului.O Echipa Scrum se organizează astfel încât să producă o nouă unitate funționabila a produsului la sfărșitul unui sprint. Cu ajutorul acestora, sistemul se adaptează mai ușor la schimbări.

În timpul Sprint-ului:

Nu se aduc modificări care ar putea afecta obiectivul Sprint-ului;

Obiectivele de calitate nu scad;

Scopul poate fi clarificat și re-negociate între Product Owner și Echipa de Dezvoltare pe măsură ce mai multe informații devin disponibile.

Tipuri de sedințe: 
1. Sedințele de planificare a sprint-ului

Așa cum am menționat și mai sus, la începutul fiecărui sprint sunt organizate ședințe de planificare a acestuia. În cadrul acestor ședințe se :

selectează sarcinile ce trebuie rezolvate în cadrul sprint-ului

estimează timpul necesar finalizării fiecărei sarcini

estimează totalitatea efortului depus de către echipă în cadrul acestui sprint

se atribuie fiecare sarcină unuia sau mai multor oameni din echipă Scrum

2. Ședințele zilnice

În timpul unui sprint se organizează în fiecare zi o ședința cu întreagă echipă Scrum în care se discută stadiul la care se află fiecare sarcină din sprint backlog. Fiecare membru explică sarcinile la care a lucrat în ziua precedentă și sarcinile la care va lucra în ziua în curs împreună cu problemele întâlnite în cazul în care acestea există.

Ședințele zilnice au următoarele caracteristici:

toți membri echipei ar trebui să participe la ședința

ședință va începe mereu la o oră fixă stabilită apriori chiar dacă unii membri ai echipei lipsesc

durată ședinței este fixă și stabilită inițial, de obicei această durează 15-30 de minute

ședința ar trebui să aibă loc în fiecare zi în aceeași locație 

3. Întâlnirea de evaluare a unui sprint

La finalul unui sprint se țin două ședințe: O ședința de analiză a sprint-ului ( Sprint Review Meeting) și o ședința de retrospectivă a sprint-ului (Sprint Retrospective)

În cadrul ședinței de analiză :

sunt revizuite sarcinile finalizate dar și sarcinile plănuite dar nefinalizate

este prezentat produsul finit clientului

are o durată maximă de 4 ore

În cadrul unei ședințe de retrospectivă :

fiecare membru reflectă la sprint-ul finalizat

se pun două întrebări principale: "Ce a mers bine în cadrul sprint-ului? " și " Ce ar putea fi îmbunătăți în cadrul următorului sprint?

O diagrama a modului în care se îmbină evenimentele metodologiei Scrum putem observa în imaginea următoare :

Fig.2.3. Reprezentarea graficî a evenimentelor metodologiei Scrum

Procesul Scrum

Procesul Scrum include 3 faze : pre-joc, dezvoltare (sau joc), post-joc.

Pre-jocul – include două sub-faze:

Planificare: presupune definirea sistemului ce se dorește a fi construit. Este creat un produs nerezolvat ce conține cerințele cunoscute la momentul actual. Cerințelor li se asociată priorități și este evaluat efortul necersar pentru implementarea acestora. Tot acum se stabilește și echipa ce va lucra la proiect, intrumentele și resursele necesare, ariile în care este nevoie de training.

Arhitectura / Design la nivel înalt – aici are loc design-ul de nivel înalt al sistemului; dacă sistemul deja există se discută schimbările necesare pentru implementarea cerințelor, precum și problemele pe care le ridică aceste schimbări.

Jocul – reprezintă partea agilă a abordării Scrum. Această fază este tratată ca o cutie neagră unde unele elemente sunt imprevizibile. Variabilele identificate ce țin de mediul de devoltare, care se pot schimba de-a lungul timpului, sunt observate și controlate prin diverse practici Scrum. Scrum ia în considerare aceste variabile nu doar la început (în faza de pre-joc), ci pe tot parcursul procesului de dezvoltare pentru a se putea adapta ușor la schimbări. În această fază proiectul este realizat prin intermediul sprint-urilor.

Post-jocul – este faza de finalizare a proiectului; toate cerințele stabilite au fost îndeplinite. În acest stadiu nu mai sunt elemente sau probleme (în produsul nerezolvat) ce trebuie adresate și nici nu se mai pot găsi altele noi. Produsul este gata pentru a fi livrat și se pregătește această acțiune (prin integrare, testare, documentare).

O schema a procesului Scrum putem observa in imaginea urmatoare :

Fig.2.4. Procesul Scrum

2.4 Avantajele și limitările Scrum 
Avantaje

Scrum se diferențiază de alte metode de dezvoltare prin avantajele sale care fac ca acest procedeu să fie un răspuns pragmatic la exigențele cu care se confruntă în prezent responsabilii de produs:

Metodă iterativă și incrementală: aceasta permite evitarea „efectului de tunel", adică obținerea rezultatul abia la livrarea finală și de a nu întrezări nimic sau aproape nimic concret pe durata întregii faze de dezvoltare, situație frecvent întâlnită în cadrul proiectelor bazate pe ciclul în V.

Adaptabilitate maximă pentru realizarea de produse și aplicații: compunerea secvențială a conținutului sprinturilor permite efectuarea unei modificări sau adăugarea unei funcționalități care nu era prevăzută inițial. Acesta este principalul aspect care face ca această metodă să fie „agilă".

Metodă participativă: fiecare membru al echipei este invitat să își exprime părerea și poate contribui la toate deciziile luate în cadrul proiectului, fiind deci mai implicat și mai motivat.

Facilitarea comunicării: lucrând în aceeași sală de dezvoltare sau fiind conectată prin intermediul diferitelor mijloace de comunicare, echipa poate comunica în mod facil și poate schimba informații despre impedimentele întâlnite în scopul eliminării cât mai rapide a acestora.

Ameliorarea cooperării: comunicarea zilnică dintre client și echipa face posibilă o colaborare mai strânsă între cele două părți.

Creșterea productivității: prin eliminarea anumitor „exigențe" specifice metodelor clasice, precum documentația sau formalizarea excesivă, mtedologia Scrum facilitează creșterea productivității echipei. În plus, fiecare modul poate fi supus evaluării, ceea ce permite efectuarea de estimări în cifre. Astfel, fiecare membru își poate evalua performanța în raport cu productivitatea medie a echipei. 
Limitari

Modologia Scrum nu reprezintă un răspuns miraculos la toate problemele specifice dezvoltării de aplicații software, observam astfel o serie de limitari ale metodologiei :

Dimensiunea echipei: fiind de regulă limitată la 7 sau 10 persoane, dimensiunea echipei se poate transforma într-un obstacol dacă se depășește numărul de membri recomandat. În acest caz, organizarea de ședințe devine imposibilă, iar bazele înseși ale metodelor sunt afectate.

Cereri multiple: cererile pot proveni din mai multe surse în cadrul unui proiect și pot uneori să fie dificil de gestionat datorită aspectului lor contradictoriu. În ceea ce privește validarea livrărilor, aceste contradicții pot duce la încetinirea procesului de validare.

Calitatea produsului realizat: cu cât numărul echipelor este mai mare, cu atât calitatea este mai greu de controlat. Această regulă este cu atât mai valabilă cu cât proiectul este împărțit pe mai multe centre. Riscurile sunt legate în special de calitatea codului și de numărul defectelor sesizate în momentul integrării.

Managementul proiectului de dezvoltare a PP

3.1 Instrumente de proiectare a PP

În ziua de astăzi există numeroase aplicații independente sau de tip plug-in la diverse medii de dezvoltare care au ca scop principal managementul proiectelor, mai precis al diverselor etape în procesul de dezvoltare software. Aplicațiile sunt capabile să ajute utilizatorii să aibă o evidență cat mai clara a taskurilor, a membrilor echipei care se ocupă de aceste taskuri, precum și raportele zilnice referitoare la aplicație (fiecare mebru al echipei la ce a lucrat și in ce stadiu este fiecare task al proiectului). Unele dintre aceste aplicații de management au fost îmbunătățite și pot oferi soluții de management în dezvoltarea de tip Agile permițând, de exemplu, evidența ședințelor din Scrum etc.

Printre aceste aplicații se numără:

Jira, VersionOne – aplicații independente, de sine stătătoare

Visual Studio Scrum – pentru Visual Studio

Agile for Oracle – pentru Oracle

Gantt – open source

Aceste aplicații au foarte multe întrebuințări și sunt folosite la scară largă în industria software. Ele pot avea use-case-uri de tipul:

un dezvoltator poate vedea taskurile care i-au fost atribuite, le poate sorta în funcție de prioritate, de modulul afectat, de gravitate etc.

un dezvoltator își poate loga orele lucrate la diverse sarcini;

un utilizator (team leader, project manager) poate estima diverse taskuri și le poate atribui priorități, le poate atribui dezvoltatorilor etc;

un tester poate realiza aceleași acțiuni pe un test plan ca și dezvoltatorii pe taskuri;

un project manager poate observa planificările, poate schimba diverse informații la nivel de proiect;

un project manager poate crea rapoarte despre taskurile terminate, în lucru sau neîncepute, și poate avea o imagine de ansamblu a muncii fiecărui membru al echipei de dezvoltatori sau testeri.

3.2 Ce reprezinta Gantter

Se pune mare  accent, în ultima vreme, pe managementul proiectelor. Și este normal așa ținând cont de complexitatea acțiunilor/activităților pe care un management complet și competent o presupune în condițiile economice, tehnologice, legale și social-umane actuale.

Gantter este un serviciu gratuit de programare pe bază de web care este pe deplin integrat cu Google Drive. Sistemul vine cu un set extins de funcții de gestionare a proiectelor și programare, precum și de capacități de planificare și colaborare. Gantter le permite utilizatorilor să deschidă și să importe fișiere Microsoft Project existente în sistem.

Gantter este utilizat pe scară largă de multe tipuri de utilizatori și companii. Pentru unul, este un serviciu gratuit de programare a unui proiect care oferă o mulțime de caracteristici utile care simplifică managementul de proiect, programarea și colaborarea în cloud. Integrarea sa cu Google Drive este, de asemenea, un plus imens. O mulțime de oameni sunt foarte familiarizați cu Google Drive, în primul rând datorită ușurinței în utilizare și faptului evident că mulți utilizatori folosesc Google Drive pentru muncă.

Dar, probabil, beneficiul evident pe care mulți îl văd în Gantter este că acesta imită Microsoft Project, un software de management de proiect de vârf. Este ca și versiunea web a Microsoft Project fără taxa de licență. Gantter sprijină instrumentul esențial de programare necesar pentru a dezvolta și gestiona un program de programare. Pentru multele persoane care folosesc sau cunosc software-ul actual Microsoft Project, experiența Gantter nu este departe de a fi o aplicație simplă și ușor de folosit.

Sistemul permite utilizatorilor să definească roluri și costuri, orare pentru fiecare membru al echipei. Sărbătorile și concediile fără serviciu pot fi configurate prin vizualizarea Calendar. Ori de câte ori un proiect se apropie de termenul limită, Gantter trimite automat notificări și afișează un indicator de avertizare în cazul depășirii termenului limită.

Deoarece Gantter este bazat pe web, toți membrii echipei pot vizualiza cu ușurință proiectele și progresele lor în timp real, fără a fi nevoiți să reîmprospătească sau să aștepte următoarea întâlnire a echipei. Colaborarea este pe deplin suportată prin editarea la nivel de fișier a sistemului cu un magazin web Gantter nativ sau prin integrarea sa cu Google Drive.

Pentru construirea diagramei Gantt se recomandă parcurgerea următoarelor etape:

definirea activităților necesare pentru implementarea proiectului;

estimarea duratei fiecărei activități;

ordonarea activităților într-o succesiune logică;

marcarea grafică a succesiunii activităților cu ajutorul unor linii orizontale (aceste linii arată momentul începerii și terminării fiecărei activități).

Prin urmare, diagrama sau graficul Gantt, ca unealtă de programare, are următoarele avantaje însemnate:

este ușor de realizat/ trasat, urmărit și interpretat;

ilustrează limpede stadiul în care te afli la un moment dat;

poate fi facil adaptată la o varietate largă de cerințe de planificare și modificată pentru a ilustra actualitatea datelor;

ajută esențialmente la rezolvarea temporală a sarcinilor și la organizarea în timp; a trecut testul timpului și folosului.

Revenind la utilitatea întocmirii tabelurilor Grantt ca unealtă de planificare a afacerilor noastre, dupa explicațiile precedente, rostul ei este clar.

Avem de-a face cu un instrument calendaristic aproape clasic, o interfață accesibilă care permite oricui să estimeze durata, resursele și ordinea sarcinilor/activităților, pașilor ce trebuie urmariți, supraveghează progresul făcut și ajută în luarea deciziilor de intervenție/schimbare atunci când nu ne încadrăm în parametrii prevăzuți, atrage permanent atenția către etapele ce necesită, în continuare, execuție, realizare și ne avertizează la o observare și o analiză mai atente a datelor la care au fost operate modificări în desfășurarea activităților.

Fără previziune nu există rezultat, iar o planificare riguroasă aduce semnificativ rezultatul dorit mai aproape.Graficul Gantt este unul dintre cele mai simple, valoroase și larg utilizate unelte pentru planificare.

3.3 Structura/Componentele Ganttter

Când începe un nou proiect, unul dintre primii pași trebuie să luăm este planificarea acesteia, adică divizarea proiectului într-o serie de etape. Unul dintre aspectele cele mai interesante ale lui Gantter este că acesta este în cloud, adică nu aveți nevoie să instalați nimic și aveți nevoie doar de o conexiune la internet și un browser web. Un alt punct de reținut este faptul că este gratuit și este în limbi diferite. Pentru a accesa un Gantter șablon mai întâi trebuie să aveți un cont de e-mail.

Fig.3.1. Panoul de înregistrare Gantt

Pentru a începe utilizarea acestei aplicații apăsăm butonul “Start Now”.

Începeți cu un planificator nou / necompletat. Setați Proprietățile Proiectului făcând clic pe numele proiectului (numit Untitled în mod implicit). De aici puteți seta sau regla:

Numele proiectului

Setări de timp și calendar (faceți clic pe diferite file pentru setări)

Industrie și locație

Proprietățile timpului (ore, zile)

Informații despre monedă

Resurse

Note

Legături

Fig.3.2. Formularu de creare Proiect Gantt

Fig.3.3. Reprezentarea tabelară a Gant.

Meniuri:

Proiect – Salvați, imprimați și exportați

Editați – Undo, redo, cut & etc

Vizualizare – Activați sau dezactivați diferite coloane

Acțiuni – Funcții pentru lucrul cu activități

Baseline – Creați linii de bază aici

Extensii – Încărcați și executați extensii de la dezvoltatori terță parte (utilizați pe propriul risc)

Ajutor – Diverse resurse de ajutor

Salvare automată – activați sau dezactivați această opțiune (salvați întotdeauna manual, chiar dacă ați activat această opțiune)

Bara de instrumente

O colecție de comenzi utilizate în mod curent (copiere, imprimare, salvare …)

Când lucrați într-una din celulele de activitate (cu informații deja adăugate) veți fi

capabil să:

Introduceți (o nouă activitate) de mai sus, inserați mai jos sau ștergeți acea activitate

Indentați sau deselectați o activitate

Deplasați activitatea în sus sau în jos

Dacă selectați 2 sau mai multe activități (selectați un număr de activitate și țineți apăsată tasta de control pentru a adăuga mai mult la selecția dvs.

Măriți sau micșorați

Proprietăți – ajustați detaliile acelei sarcini.

Următorul pas pentru crearea unui proiect este crearea de sarcini. Pentru a genera o nouă sarcină, este necesar să fie localizată în pictograma de activitate. Faceți clic pe o celulă goală și scrieți în el numele sarcinii.

Fig.3.4. Reprezentarea tabelului pentru înscrierea sarcinilor

Pentru a crea sarcinile, faceți clic pe o casetă "Nume" și dați sarcina un nume. Putem da fiecărei sarcini o durată sau o dată de începere și de încheiere, dar acest lucru va varia în funcție de nevoile noastre. În "Predecesoras" putem stabili ce sarcini trebuie îndeplinite pentru ca ea să aibă loc. În "Resurse" vă oferim resursele necesare pentru finalizarea sarcinii. Aceste resurse trebuie să fie introduse în fila "Resurse" din partea stângă a ecranului.

Administrarea resurselor

Al treilea pas în construirea unui proiect este legat de resursele necesare să dezvolte sarcinile. Prin resursă se înțeleg toate persoanele, echipamentul sau orice altceva care facilitează dezvoltarea unei sarcini. Gantter prezintă două tipuri de resurse: muncă (persoane) sau materiale (articole sau echipamente). În exemplul proiectului de cercetare, munca de resurse se referă la un cercetător, un monitor sau un student și resursele materiale, se referă la servere, documente scrise, baze de date etc.

Fig.3.4. Reprezentarea tabelului pentru înscrierea resurselor utilizate

Calendar

Faceți clic pe pictograma de calendar (partea stângă a spațiului de lucru) pentru a regla orele de lucru într-un a zi. În mod implicit, Gantter utilizează calendarul "None" cu setările pe care le-am setat (sau acceptat) în proiect atunci când am creat documentul.

Modificați setările pentru calendar în panoul " Task Properties" din fila Advanced.

Puteți selecta datele individuale dintr-un calendar pentru a vă ajusta pentru sărbătorile și alte evenimente care ar putea să apară afecta orele de lucru.

Puteți crea calendare noi dacă este necesar; pentru cazarea de lucrări cu fracțiune de normă, de exemplu.

Dacă cunoașteți data de terminare a proiectului, îl puteți seta în proprietățile proiectului. Faceți clic pe numele fișierului și modificați setarea "Plan de la" la "Data finalizării". Gantter va ajusta programul dvs. pentru a începe cât mai târziu posibil pentru a respecta termenul limită al proiectului.

Fig.3.5. Reprezentarea tabelului pentru programarea calendarului

Registrul riscului

"Gestionarea riscurilor" vă permite să identificați și să atribuiți riscurile sau posibilele amenințări pe care le fac vulnerabile la fiecare sarcină, pentru a lua măsuri pentru a le reduce. Pe Gantter, alocarea riscurilor poate fi făcută în pictograma de risc sau la nivelul sarcinilor proiectului.Pentru a adăuga un nou risc, este necesar să localizați pictograma de risc. Faceți clic pe ea goală și scrieți numele riscului.

Fig.3.6. Reprezentarea tabelului pentru înscrierea riscurilor

3.4. Dezvoltarea proiectului în Gantt

Domeniul de Dezvoltare: IT

Denumire: Sait de prezentare a companiei CreateWeb+

Proiectul este divizat în trei sprinturi, fiecare Sprint are o lista de sarcini care trebuiesc finalizate în intervalul stabilit la începutul Sprintului.

La început am definit care vor fi persoanele care vor lucra în proiect, în compartimentul Resources.

Fig.3.7. Reprezentarea resurselor pentru proiectul Creare Site Web

Sursă: Date proprii

Sprint 1

Fig.3.8. Reprezentarea tabelului cu sarcini pentru Sprint 1

Sursă: Date proprii

Fig.3.9. Reprezentarea grafică a sarcinilor pentru Sprint 1

Sursă: Date proprii

Fig.3.10. Reprezentarea tabelului cu sarcini și grafică pentru Sprint 1

Sprint 2

Fig.3.11. Reprezentarea tabelului cu sarcini pentru Sprint 2

Sursă: Date proprii

Fig.3.12. Reprezentarea grafică a sarcinilor pentru Sprint 2

Sursă: Date proprii

Sprint 3

Fig.3.13. Reprezentarea tabelară și grafică pentru Sprint 3

Studiu de Caz: Sait de prezentare a companiei CreateWeb+

CreateWeb+ este o companie care are ca domeniu de activitatea crearea saiturilor web. Serviciile pe care le oferă sunt:

Crearea saiturilor de prezentare/One page,

Crearea saiturilor de destinație/Landing Page,

Optimizare SEO,

Web design,

Administrarea și întreținerea saiturilor web.

Aplicând Metodologia Agile-Scrum, bazată pe Sprinturi, prezind dezvoltarea saitului pentru compania CreateWeb+.

4.1 Sprint I

Elaborez designului aplicației CreateWeb+ în photoshop

Ca instrument de lucru sa folosit Photoshop, Visual Studio, Xampp.

Machetarea HTML5, CSS3, Framework Bootstrap (Anexa)

Elaborarea siteului responsiv

Pentru Galaxy S5 pagina principal va arata în felul următor:

Pentru iPhone6/7/8Plus pagina principal va arata în felul următor:

Pentru iPad Pro pagina principal va arata în felul următor:

Proiectarea bazei de date

Creare butonului “Comandă acum”

Crearea subsolului siteului

4.2 Sprint II

Creare barei de căutare “Find”

Crearea și implimentarea Logoului

Crearea butonului de Traducere “EN”, “RO”

Crearea formularului de înregistrare pentru blocul “Contactează-ne ”

Crearea butonului “Trimite mesaj” în blocul “Contactează-ne ”

Adăugarea conținuturilor pentru fiecare bloc.

Adăugarea conținuturilor pentru Blocul Portofoliu.

4.3 Sprint III

Creăm autentificarea, inregistrarea si logarea securizata pentru panoul de administrare

Crearea meniurilor

Concluzii:

Bibliografie:

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … & Kern, J. (2001), Manifesto for agile software development, http://www.agilemanifesto.org

Rubin, K. S. (2012), Essential Scrum: a practical guide to the most popular agile process, Addison-Wesley

Beck, K. (2000), Extreme programming explained: embrace change, Addison-Wesley professional

Anderson, D. J. (2013), Kanban, Blue Hole Press Inc

Dikert, K., Paasivaara, M., & Lassenius, C. (2016)., Challenges and Success Factors for Large-Scale Agile Transformations: A Systematic Literature Review, Journal of Systems and Software

Budacu, E. N., Bodea, C. N., Stancu, S. (2015), Agility in the IT Services Sector: A Study for Romania, Proceedings of the IE 2015 International Conference

Agile Manifesto – http://agilemanifesto.org/

[2] Agile Alliance – http://www.agilealliance.org/

[4] Mikolouk, Kasia – Agile Vs. Waterfall: Evaluating The Pros And Cons (2013)

[5] Fowler, Martin – The New Methodology (2005)

[6] Forsyth, Aaron – Waterfall vs Agile Models in Software Development (2013)

[7] Boehm, Barry – A Spiral Model of Software Development and Enhancement (1986)

[8] Scrum and Agile Training and Consulting – http://www.mountaingoatsoftware.com

[9] Sims, Chris – Scrum: A Breathtakingly Brief and Agile Introduction

[10] Mar, Kane; Schwaber, Ken – Scrum with XP (2010)

[11] Zuiderveld, Nicholas – eXtreme Programming and Scrum: A comparison of Agile methods

[12] http://www.kanbanblog.com/

[13] http://www.learnaccessvba.com/application_development/waterfall_method.htm

[14] http://ultimatesdlc.com/spiral-model/ [15]http://www.codeproject.com/Articles/320791/Developing-Factorial-ApplicationUsing-Test-Driven

[16] Cohn, Michael – Agile Estimation and Planning

http://agilemanifesto.org/iso/ro/

http://en.wikipedia.org/wiki/Scrum_(software_development)

http://profs.info.uaic.ro/~alaiba/mw/index.php?title=Procesul_SCRUM_de_dezvoltare_agil%C4%83_a_produselor_software

http://www.pentalog.ro/abordare/metodologia-agile-scrum.htm

Agile Modeling Home

Gantter Versión 3.0. (2014). Gantter. Recuperado el Abril de 2014, de

http://www.gantter.com/help/

Tamayo y Tamayo, M. (2001). El proceso de la investigación científica. México D.F: Editorial

Limusa.

Tutorial para la planeación de un… (PDF Download Available). Available from: https://www.researchgate.net/publication/310605119_Tutorial_para_la_planeacion_de_un_proyecto_de_investigacion_en_Gantter [accessed Apr 03 2018].

Anexe