Implementarea Agile Management la S.c. Tradeads Interactiv S.r.l

CAPITOLUL I MANAGEMENTUL DE PROIECTE

Apariția conceptului de management

Dezvoltarea în timp a ceea ce numim astăzi „management” își are rădăcinile în secolele XV-XVI, dar marea majoritate a specialiștilor din domeniu situează individualizarea managementului în jurul anului 1900. Astfel, la începutul secolului XX, două personalități de seamă, una de origine franceză – Henry Fayol și cealaltă de origine americană –Frederick Taylor, recunoscut ca părintele managementului științific, au pus bazele managementului. Prin inițierea unor studii de amploare în întreprinderile industriale, cei doi au propus noi metode/principii de organizarea și administrarea unei afaceri, criticând în același timp metodele tradiționale de organizare a producției industriale.

Pentru prima dată în 1911, odată cu publicarea „The Principles of Scientific Management” a lui Taylor și „Administration Industrielle et Generale” a lui Fayol în 1915 apare acea explozie a interesului pentru managementul ca practică, ca activitate. Această dată este considerată punctul de început în recunoașterea managementului ca domeniu de informare și instruire școlastică.

Inițierea managementului științific la începutul secolului XX a constituit un eveniment revoluționar care a contribuit la raționalizarea muncii și reducerea pierderilor.

Considerat de marea majoritate a specialiștilor drept părintele managementului științific, Frederick Taylor și-a bazat întreaga concepție pe ideea că munca oamenilor se poate raționaliza. Această concepție a „maximei prosperități” este privită, mai ales, din punctul de vedere al întreprinzătorului și este ridicată de Taylor la rangul de principal obiectiv al managementului.

Taylorismul apare astfel ca o concepție organizațional-tehnicistă, în care locul principal este ocupat de o serie de idei, cum ar fi: imaginea clară despre fiecare element, crearea unui fundament științific care să înlocuiască metodele vechi de muncă, studierea științifică a fiecărui element, alegerea celor mai potriviți muncitori pentru fiecare operație, dezvoltarea colaborării între administrație și muncitori, folosirea specialiștilor etc, în vreme ce elementul uman este plasat pe un loc secundar.

Un pas înainte în dezvoltarea și fundamentarea managementului științific l-a făcut Henri Fayol realizând saltul de la nivelul locului de muncă la nivelul întreprinderii în ansamblul ei, reușind astfel să lărgească conținutul și sfera conceptului de management. Abordarea și definirea funcțiilor întreprinderii și a managementului ei, precum și considerarea întreprinderii ca organism de sine stătător, dar aflat în legătură cu alte organisme asemănătoare, îi conferă concepției lui Fayol un fundament științific și meritul cel mai mare.

Taylor și Fayol au jalonat trăsăturile de bază ale conceptului de management științific, acordând o atenție mai mare elementului tehnic și organizatoric, în vreme ce factorul om este complet neglijat.

De multe ori, managementul clasic a fost criticat pentru tratarea simplistă și unilaterală a ființei umane angajată în organizații. Unii specialiști consideră că soluțiile date managementului de către Taylor și Fayol au fost valabile pentru condițiile de la începutul secolului și n-ar mai corespunde organizațiilor de astăzi. Alți specialiști sunt convinși că opera lui Taylor este insuficient înțeleasă și criticată pe nedrept, el căutând să ușureze munca oamenilor, îmbunătățind condițiile de muncă, reducând oboseala, reproiectând mașinile spre a le adapta mai bine la om.

Atât managementul științific, inițiat de Taylor, cât și teoria clasică a organizării de ansamblu a firmelor, creată de Fayol, au avut succesori. Astfel, managementul științific s-a bucurat de contribuțiile remarcabile ale soților Frank Gilbreth (1868-1924) și Lillian Gilbreth (1878-1972) și a lui Henry L. Gantt (1861-1919). Henry L.

Gantt a fost un inginer ca și Taylor, colaborând cu acesta din urmă, care și-a propus să îmbunătățească eficiența muncii prin cercetare științifică. A dezvoltat sistemul de salarizare în acord, propus de Taylor, printr-un sistem mai stimulativ care combina așa-numitul salariu zilnic garantat (un salariu zilnic minim) cu bonificații pentru depășirile de normă, pentru a putea efectua măsurători asupra gradului îndeplinirii sarcinilor, a inițiat introducerea în practica de atelier a graficelor liniare de activitate, prin care se pot reda atât sarcina programată conform normelor, cât și gradul de realizare efectivă (graficele Gantt).

În ceea ce privește managementul modern, acesta implică un mare număr de abilități și orientări, dintre care multe presupun abilități legate de statistică, utilizarea tehnologiei informației, contabilitate și matematică. De asemenea, managementul pune accent pe rezolvarea rațională a problemelor și pe gândirea logică, pe folosirea unor metode matematice moderne în procesul de conducere, pe utilizarea unor instrumente ce au revoluționat munca managerilor și orientarea companiilor în afaceri, cum ar fi computerul, internetul, inteligența artificială etc. Toate acestea îmbogățesc managementul științific și îl mențin în pas cu schimbările care se produc în viața întreprinderilor, ținând cont și de sarcinile pe care le impune progresul social si economic.

Știința și practica managementului au cunoscut și cunosc, în secolul XX și la începutul secolului XXI, o evoluție spectaculoasă cu un impact deosebit în viața tuturor tipurilor de organizații. Diversitatea abordărilor teoretice și pragmatice pun în evidență mișcarea de idei în acest domeniu, precum și stăruința specialiștilor de a concepe sisteme de conducere care să fie accesibile și eficiente.

Definirea și explicarea termenului de management a preocupat o multitudine de specialiști, astfel încât literatura de specialitate a încercat să-i clarifice conținutul. Conceptul de management are semnificații multiple și se folosește mult în teorie și în practică. Esențialul în analiza și tratarea acestui concept îl constituie determinarea conținutului, a elementelor și direcțiilor care-i stabilesc trăsăturile. Dat fiind caracterul complex al managementului, au apărut numeroase și variate definiții ale acestui concept, dar o definiție generală ar fi – „managementul reprezintă ansamblul activităților, disciplinelor, metodelor, tehnicilor care înglobează sarcinile conducerii, gestiunii, administrării și organizării companiei/organizației/instituției și vizează ca, prin adoptarea deciziilor optime în proiectarea și reglarea proceselor microeconomice să antreneze întregul personal pentru a întreprinde și a lucra cât mai profitabil, pentru a organiza schimbări capabile să asigure unității un viitor trainic și eficace pe plan economic și social”.

În final managementul poate fi definit ca procesul de atingere a obiectivelor unei colectivități umane organizate (întreprinderi economice, instituții publice, organizații non-profit) în condițiile utilizării optime și eficiente a resurselor materiale, umane și financiare.

Managementul contemporan

Proiectele contemporane se caracterizează prin viteză, schimbări majore, costuri mai mici, complexitate, incertitudine, precum și de o serie de alți factori. Aceasta reprezintă o provocare descurajantă pentru managerul de proiect așa cum este descris în paragrafele care urmează.

Cu cât produsele și serviciile ajung mai rapid pe piață cu atât mai mare va fi valoarea rezultată pentru afacere. Concurența urmărește și răspunde la oportunități nemaiîntâlnite și caută să profite de pe urma oricărei ocazii care ar putea să îi dea un avantaj sau o posibilitate de extindere pe piața. Orice slăbiciune sau întârziere a managerului în a răspunde poate da concurenței acest avantaj. Acest lucru se traduce printr-o nevoie în abordarea managementului de proiect de a nu pierde timp. Multe dintre abordările actuale sunt construite pe această premisă. Fereastra de oportunitate se îngustează și se deplasează în mod constant. Organizațiile care răspund rapid la aceste posibilități sunt organizațiile care au găsit o modalitate de a reduce timpii de lucru și au eliminat munca non-valoare cât mai mult posibil. Dacă lansarea sau remodelarea unui produs, de exemplu, ia prea mult timp atunci poate conduce la o oportunitate de afaceri ratată. Managerii de proiect trebuie să știe cum și când să introducă strategii de eliberare multiple și să comprime durata unui proiect, pentru a ajuta la satisfacerea cerințelor.

Chiar mai important, abordarea managementului de proiect trebuie să sprijine aceste orare agresive. Asta înseamnă că aceste procese trebuie să protejeze orarul prin eliminarea lucrările non-valoare. Managerii pur și simplu nu își pot permite să împovăreze etapele proiectului, cu o mulțime de activități care nu adaugă valoare la produsele finale sau care pot compromite eficacitatea lor în piețele pe care le vor servi.

Gestionarea eficientă a proiectului nu este produsul unui set rigid sau fix de etape și procese de urmat în fiecare proiect. Mai degrabă alegerea abordării proiectului se bazează pe ce e de făcut având în vedere specificul proiectului. Se alege o abordare care are sens.

Deseori clienții se răzgândesc cu privire la ceea ce-si doresc, când doresc sau cum doresc. De fapt, mediul este cauza schimbărilor majore, nu necunoștință din partea clientului.

Lumea afacerilor este foarte dinamică. Ea nu stă în loc doar pentru că un manager gestionează un proiect. Cea mai potrivită abordare de management de proiect trebuie să recunoască realitățile schimbărilor frecvente și să o integreze. Măsura în care schimbarea este de așteptat ea va afecta alegerea unui model PMLC(Project Management Life Cycle) potrivit.

Schimbarea este constantă. Schimbarea se petrece întotdeauna și pare să se întâmple într-un ritm în creștere. În fiecare zi apar atât noi provocări, dar și necesitatea de a îmbunătăți practicile de ieri. Pentru managerii de proiect cu experiență, precum și pentru novici, drumul spre performanță este pavat cu incertitudini și cu nevoia de a fi curajos, creativ și flexibil. Dacă pur și simplu proiectul se bazează pe o metodologie străină, atunci veți suferi pierderi pe piață. Nicăieri nu este mai multă nevoie de schimbare și adaptare decât în abordările pe care le luăm pentru gestionarea proiectelor.

Cu reducerea straturilor de management (o practică comună în multe organizații) personalul profesionist trebuie să găsească modalități de a lucra mai inteligent, nu mai greu. Managementul de proiect include o serie de instrumente și tehnici care ajută profesioniștii să gestioneze volumul de lucru crescut. Angajații/personalul trebuie sa dispună de mai mult spațiu pentru a-și face munca în cele mai productive moduri posibile. Aglomerarea acestora cu activități inutile este în mod sigur calea spre eșec.

Într-o lucrare reper scrisa acum 20 de ani, dar încă relevantă, Peter Drucker descrie manageri de mijloc „ca fiind ca cei care primesc informații de mai sus, le reinterpretează, și le transmit mai jos, iar cei care le primesc le interpretează din nou. Astfel se pierde din calitate din cauza deviațiilor personale și conotațiilor politice. Acești intermediari pot fi înlocuiți de către calculator care este perfect capabil să ofere aceste informații oricărui manager care are nevoie să le știe”. Având în vedere acești factori, plus politica și lupta pentru putere în joc, Drucker întreabă de ce se angajau manageri de mijloc. Cu cât tehnologia a avansat s-a văzut și subțierea straturilor de management de mijloc. Efectul asupra managerilor de proiecte este previzibil și semnificativ. Structurile ierarhice sunt înlocuite de organizații și de echipa de proiect care au o dependență mai mare pe proiecte, ceea ce determina mai multe cereri pe manageri de proiect.

Dacă toate problemele simple au fost rezolvate, atunci cele care au rămas sunt tot mai complexe cu fiecare zi ce trece. În același timp, cu cât problemele devin mai complexe, cu atât ele devin mai critice pentru întreprindere. Ele trebuie să fie rezolvate. Lipsa unei soluții pentru gestionarea unor astfel de proiecte nu este o scuză, acestea trebuie să fie gestionate, iar managerul trebuie să aibă un mod eficient de gestionare a lor.

Odată cu creșterea nivelului de complexitate crește și nivelul de incertitudine. Cele două sunt inseparabile. Adaptarea abordării managementului de proiect pentru a face față incertitudini înseamnă nu numai să integreze schimbarea, ci să o îmbrățișeze pentru a deveni mai eficientă. Schimbarea este cea care va conduce echipa și clientul la o stare de certitudine cu privire la o soluție viabilă pentru problemele lor complexe. Cu alte cuvinte, trebuie să avem abordări de management de proiect care așteaptă schimbare și de a beneficia de ea.

Mediul proiectelor contemporane prezintă managerului de proiect și clientului, numeroase provocări pentru gestionarea eficientă a unor astfel de proiecte. Utilizarea modelului PMLC( Project Management Life Cycle) cea mai potrivită se va ridica la aceste provocări și să va adapta în funcție de necesități.

Practicile managementului de proiect tradițional s-au definit și maturizat în lumea inginerilor. În acest tip de management echipa aștepta (și lua, sau așa credea) specificații clare din partea clienților cu privire la ceea ce vor, când vor, și cât de mult sunt dispuși să plătească pentru el. Toate acestea erau livrate managerului de proiect. După ce toate specificațiile au fost livrate toată lumea era mulțumită ce cererea a fost bine documentată și că rezultatele preconizate erau sigure pentru a fi livrate corespunzător. Echipa de proiect înțelegea în mod clar soluția așteptată și putea planifica în mod clar livrarea sa.

Acest model descrie lumea naivă a managementului de proiecte pană în anii 1950. Pe la mijlocul anilor 1950 computerul era pe cale de a deveni o resursă comercială viabilă.

Primul semn că schimbarea era aproape pentru managerul de proiecte a apărut la începutul anilor 1960. Utilizarea calculatoarelor pentru a rula afaceri a devenit o realitate, și au început să apară poziții, cum ar fi programator, programator/analist, analist de sistem, precum și tipuri primitive de arhitecți de baze de date în curs de dezvoltare. Acești profesioniști au fost într-adevăr ingineri deghizați, și într-un fel, se aștepta ca aceștia să interacționeze cu profesioniștii în afaceri și managerii. Scopul era de a proiecta și implementa sisteme de aplicații capabile să înlocuiască procesele manuale . Această schimbare a reprezentat o metamorfoză totală a lumii afacerilor și lumii proiectelor.

În fața acestei transformări într-o societate informațională, managementul tradițional TPM( Traditional Project Management) nu arăta nici un semn de schimbare. Pentru ingineri, fiecare problemă de management de proiect era privită ca un cui, și ei aveau ciocanul. Cu alte cuvinte, aveau o soluție, și trebuia să se potrivească fiecărei probleme. Una dintre problemele majore cu care se confrunta managementul traditional și încă se confruntă, este diferența dintre dorințe și nevoi. Ceea ce clientul dorește, probabil, nu este ceea ce are nevoie. În cazul în care managerul de proiect acceptă orbește ceea ce vor sau spun clienții și continuă proiectul pe aceste prerogative, atunci va avea parte de o surpriză neplăcută. De multe ori în procesul de construire a soluției, clientul învață că lucrul de care are nevoie nu este același cu cel solicitat. Nu e de mirare ca 70%+ dintre proiecte eșuează. Este nevoie de o abordare construită în jurul schimbării care îmbrățișează învățarea și descoperirea de-a lungul ciclului de viață a proiectului. Aceasta trebuie să aibă procese integrate pentru a se acomoda modificărilor rezultate.

Managerii de proiect vorbesc despre problema lipsei de claritate. Aceștia spun că ei livrează în conformitate cu cerințele inițiale ale clientului și apoi iterează pentru a îmbunătăți soluția de una sau de mai multe ori înainte de a satisface cerințele clientului. Dacă se știe că se va itera soluția inițială atunci întrebarea logică ar fi de ce nu se folosește o abordare care să aibă integrată această posibilitate. Cu apariția managementului de proiect agil această abordare a primit și un răspuns. Toate abordările agil și extrem de management în curs de dezvoltare sunt construite pe ipoteza că cerințele se vor schimba și că odată cu acestea clientul va beneficia de o privire de ansamblu mai complexă vis-a-vis de ceea ce are nevoie de fapt. Uneori aceste nevoi pot fi diferite de cele inițiale.

Internetul și o serie continuă de schimbări a noilor tehnologii au afectat în mod decisiv mediul de afaceri. Tehnologia a pus cele mai multe companii într-o stare de confuzie. Termenii actuali de e-commerce, e-business, și management al cunoștințelor au înlocuit B2B(Business to Business) și B2C(Business to Customer), iar mediul de afaceri pare să le fi asimilat rapid. Întrebarea ar fi: ce impact ar avea acest lucru asupra abordării managementului de proiect? Impactul major ar trebui să fie faptul că abordările de management de proiect trebuie să se alinieze cu activitatea întreprinderii. Managementul de proiect trebuie să-și găsească locul la masa oricărei organizații. Managerii de proiect trebuie să se alinieze în primul rând la nevoile organizației, înaintea departamentului propriu. Aceasta este un factor critic de care depinde succesul de azi.

Cei mai buni manageri de proiect înțeleg contextul de afaceri în care trebuie să fie definite rezultatele proiectului. Aceasta înseamnă nu numai o înțelegere a sistemelor interne, a interacțiunii lor, dar, și a mediului extern sisteme de furnizori și clienți în a căror medii livrabile trebuie să funcționeze. Analistul de sistem și analistul de afaceri sunt componente cheie în această înțelegere. Există un argument bun care poate fi oferit pentru metamorfoza dintre managerul de proiect și analistul de afaceri într-un profesionist care are competențele necesare.

Noțiunea de proiect

Un proiect este o secvență de activități unice, complexe și legate. Activitățile au un singur scop și anume ele trebuie să fie terminate la un anumit moment, în limitele bugetului, precum și în conformitate cu specificațiile.

Un proiect cuprinde o serie de activități, care trebuie realizate într-o anumită ordine, sau secvență. O activitate este definită ca o “bucată” de muncă.

O secvență a activităților se bazează pe cerințe tehnice, nu pe prerogative de conducere. Pentru a determina o secvența, este util să gândim în funcție de intrări și ieșiri. Întrebările pe care ni le punem în momentul în care planificăm o activitate sunt ce este necesar să intre pentru a se începe lucrul la această activitate? ce activități produc acele rezultate de ieșire necesare începerii altor activități? Prin urmare rezultatul unei activități sau a unui set de activități devine dată intrare pentru o altă activitate sau alt set de activități.

Specificarea secvențelor bazâdu-ne pe constrângeri de resurse sau declarații, cum ar fi X va lucra la activitatea B de îndată ce el termină de lucru la activitatea A '' ar trebui să fie evitate, deoarece stabilește o relație artificială între activități. Ce se întâmplă dacă X nu este disponibil pentru toate activitățile? Constrângerile de resurse nu trebuie ignorate atunci când se planifică activitățile.

Activitățile în cadrul unui proiect trebuie să fie unice. Un proiect nu s-a desfășurat exact în același fel anterior, și niciodată nu se va mai întâmpla în aceleași condiții. Ceva este întotdeauna diferite de fiecare dată când activitățile unui proiect se repetă. De obicei, variațiile sunt aleatoare în natură – de exemplu, o parte este întârziată, cineva este bolnav, sau o pană de curent apare. Acestea sunt evenimente aleatorii care se poate întâmpla, dar nu se știe niciodată când sau cum, și ce impact vor avea asupra calendarului. Aceste variații aleatorii sunt o provocare pentru managerul de proiect.

Activitățile care alcătuiesc proiectul nu sunt acte simple, repetitive, cum ar fi tunderea gazonului, spălarea mașinii, sau încărcarea vehiculului de livrare. Ele sunt complexe. De exemplu, proiectarea unei interfețe intuitive pentru un sistem este o activitate complexă.

Conectarea implică faptul că există o relație logică sau tehnică între perechile de activități. Există o ordine a secvențelor în care activitățile care alcătuiesc proiectul trebuie să fie finalizate. Ele sunt considerate conectate deoarece ieșirea de la o activitate este de fapt intrare pentru o altă activitate. De exemplu, trebuie să modelezi programul de calculator înainte de a începe dezvoltarea sa efectivă. Există și posibilitatea de a avea o listă de activități care nu au legătură, dar care trebuie să fie toate complete pentru a finaliza proiectul. De exemplu, luați în considerare vopsirea camerelor interioare ale unei case. Cu unele excepții, camerele pot fi vopsite în orice ordine. Interiorul unei case nu este complet vopsit până când toate camerele sale au fost pictate, dar ele pot fi vopsite în orice ordine. Vopsirea casei este o colecție de activități, dar nu este considerată un proiect în conformitate cu definiția.

Proiectele trebuie să aibă un singur scop – de exemplu, proiectarea unei platforme on-line de vânzare a unor produse electronice. Cu toate acestea, proiectele foarte mari sau complexe pot fi împărțite în mai multe subproiecte, fiecare dintre ele fiind un proiect în sine. Această divizare se face pentru un control managerial mai bun. De exemplu, subproiectele pot fi atribuite unui departament, unei divizii, sau chiar la nivel geografic. Această descompunere artificială a unui proiect complex în subproiecte simplifică adesea programarea resurselor și reduce nevoia de comunicații interdepartamentale în timp ce o activitate specifică este desfășurată. Dezavantajul este că proiectele sunt acum interdependente. Dar chiar dacă interdependență adaugă un alt strat de complexitate și comunicare, acesta poate fi manipulată.

Proiectele au o dată de finalizare specificată. Această dată poate fi auto-impusă de management sau extern specificată de o agenție client sau de guvern. Termenul este dincolo de controlul cuiva care lucrează la proiect. Proiectul este terminat la data de finalizare specificată fie că activitățile proiectului au fost sau nu finalizate.

Proiectele au, de asemenea, limite de resurse, cum ar fi o cantitate limitată de oameni, bani, sau mașini care sunt dedicate proiectului. Aceste resurse pot fi ajustate în sus sau în jos de conducere, dar acestea sunt considerate resurse stabilite de către managerul de proiect. De exemplu, să presupunem că o companie are un singur web designer în acest moment. Aceasta este resursa fixă care este disponibilă pentru managerul de proiect. Conducerea superioară poate modifica numărul de resurse, dar luxul acesta nu este disponibil managerului de proiect. În cazul în care web designerul este complet programat, atunci managerul de proiect are un conflict de resurse pe care nu îl poate rezolva.

Clientul sau destinatarul proiectului, se așteaptă la un anumit nivel de funcționalitate și de calitate a proiectului. Aceste așteptări pot fi auto-impuse, de management sau de client specificate.

Deși managerul de proiect tratează caietul de sarcini ca fix, realitatea este că pot exista un număr infinit de factori ce pot cauza schimbarea specificațiilor. De exemplu, clientul nu a definit cerințele complet, sau situația afacerii poate fi schimbată (ceea ce de multe ori se întâmplă în proiecte cu durate lungi). Este nerealist să ne așteptăm ca activitățile să rămână fixe pe toată durata de viață a proiectului. Specificațiile pot și vor fi schimbate, prezentând astfel provocări deosebite pentru managerul de proiect.

Înțelegerea fundamentelor managementului proiectelor

Managementul de proiecte datează istoric din anii 1950. Mai multe definiții au fost prezentate de diverși autori, iar cele mai multe dintre ele sunt variații pe tema de administrare a proiectelor, astfel încât acestea sa fie finalizate la timp, în buget, și în conformitate cu specificațiile clientului. Acestea sunt definiții bune, dar o definiție mai fundamentală este aceea că managementul de proiect este organizat în conformitate cu “bunul simț”. Multe metodologii împovărează managerul și echipa de proiect, fără nici un motiv bun. Există o mulțime de provocări de management, fără a fi nevoie să se adauge o așa numită muncă non-valoare. Multe dintre ideile vechi de management de proiect poartă această povară.

Oricum s-ar alege metodologia de management de proiect, toate metodologiile valide de management de proiect trebuie să răspundă la următoarele șase întrebări simple:

Ce situație de afaceri este abordată?

Ce trebuie să faci?

Ce vei face?

Cum vei face?

Cum vei ști că ai făcut?

Cât de bine ai făcut?

În cazul în care metodologia de management de proiect aleasă nu răspunde la aceste șase întrebări, este incompletă, ea trebuie regândită. Managementul de proiect se reduce la răspunderea acestor întrebări și nu este foarte dificil de stăpânit. Ceea ce trebuie făcut trebuie gândit și planificat cu răbdare și atenție înainte de a se alege o metodologie. De asemenea, politicile si procedurile ce fac parte din metodologia aleasă trebuie să lase loc posibilității de a lua decizii neplanificate de bun simț.

În plus față de necesitatea de a răspunde la cele șase întrebări, o metodologie validă de management de proiect, indiferent de modelul de ciclu de viață ales, trebuie să conțină următoarele grupuri de proces:

Grupul de proces de definire a domeniului

Grupul de proces de planificare

Grupul de proces de lansare

Grupul de proces de monitorizare și control

Grupul de proces de închidere

Aceste cinci grupuri de proces sunt pietrele de temelie ale oricărui ciclu de viață a managementului de proiect. În cel mai simplu caz, grupurile de proces vor fi finalizate fiecare o singură dată și în ordinea enumerată. În situații mai complexe, unele sau toate dintre ele ar putea fi repetate de mai multe ori.

Ciclurile de viață ale unui proiect de management(PMLC)

Un ciclu de viață de a unui proiect de management (PMLC- Project Management Life Cycle) este o secvență alcătuită din cinci grupe de procese definirea domeniului, planificarea, lansarea, monitorizarea-control și închidere) toate în scopul de a realiza obiectivul proiectului. Toate grupurile de procese trebuie să fie incluse cel puțin o dată în secvența, și oricare sau toate grupurile de procese pot fi repetate după cum este necesar.

Un model simplu și intuitiv a managementului de proiecte poate fi construit în jurul a două variabile: scop și soluție. Aceste două variabile pot lua fiecare două valori: clare și complete sau neclare și complete. Aceste două valori pentru fiecare variabilă poate genera o matricea cu patru cadrane ca în figura 1.

Tradițional Project Management (TPM) definește Cadranul 1;

Agile Project Management (APM) definește Cadranul 2;

Extreme Management de proiect (XPM) definește Cadranul 3; și

Emertxe Project Management (MPx) definește Cadranul 4.

Aceste valori sunt conceptuale nu cuantificabile. Un proiect dat poate prezenta diferite grade de claritate. Mesajul din acest peisaj este că tranziția de la cadran la cadran este continuă și fluidă.

Figura 1.1. Cele patru cadrane ale managementului de proiecte

De exemplu, să spunem că scopul proiectului este de a vindeca răceala. Are această afirmație scop clar și complet? Nu chiar. Cuvintele a vindeca sunt vinovate. A vindeca ar putea însemna oricare din următoarele: înainte de naștere, fătul este injectat cu un medicament ADN-ul i se va schimba și va împiedica obținerea unui răceli. Ca parte din dieta tuturor, se ia o doză zilnică de suc de la un copac care crește numai în anumite altitudini, în Himalaya. Acest suc acționează ca o bariera și previne apariția răcelii. Odată ce o persoană a contractat o răceală, ia o doză masivă de ceai făcut dintr-o rădăcină de copac rar găsit doar in centrul Chinei, iar răceala va fi vindecată în termen de 12 de ore.

Deci, cu adevărat ce înseamnă “a vindeca ”?

Ca un alt exemplu, se ia în considerare această parafrazare a unei declarații făcută de președintele John F. Kennedy în 1963: Până la sfârșitul deceniului, vom duce un om pe Lună și se va întoarce în siguranță pe pământ. Există vreo îndoială că această afirmație este clară și completă? Când proiectul s-a terminat, a existat vreo îndoială că acest obiectiv a fost sau nu a fost atins?

Fiecare proiect care a existat vreodată sau va exista se încadrează în una dintre aceste patru cadrane în orice moment. Acest cadran nu este afectat de schimbări de orice fel. Este un cadran care va rămâne în vigoare, indiferent de circumstanțe. Cadranul în care se află un proiect va fi un ghid inițial în a alege un model de PMLC (Project Management Life Cycle), precum și cea mai bună formă și adaptare a instrumentelor sale, șablon-urilor, și proceselor pentru proiectul specific.

Când un proiect este început scopul și soluția devin mai clare, iar cadranul proiectului se poate schimba, și, probabil, se va schimba și PMLC-ul de asemenea. Cu toate acestea, proiectul este mereu într-un cadran. Decizia de schimbare a PMLC-ului pentru un proiect deja in curs de desfășurare poate fi o mare schimbare și trebuie luată în considerare în mod serios. Există costuri, beneficii, avantaje, și dezavantaje asociate cu o schimbare în mijlocul proiectului.

Dincolo de claritatea și exhaustivitatea scopului și soluției, există mulți alți factori ce trebuie luați în considerare în alegerea PMLC-ului (Project Management Life Cycle). Cu titlu de exemplu, unul dintre acești factori este măsura în care clientul s-a angajat să se implice. În cazul în care cel mai bun model de PMLC necesită implicarea semnificativă a clientului, si cu cât se fac mai multe proiecte din cadranul 2 si 3 iar clientul nu se implică conform așteptărilor managementului cu atât este mai mare nevoie de a scădea la o abordare care nu are nevoie de implicarea clientului atât de mult. Alternativ, se poate realiza un program de întâlniri pentru a încuraja implicarea dorită de client.

Capitolul II METODOLOGIA SCRUM – AGILE MANAGEMENT

Agile Project Management (APM) abordări

Există diferite abordări iterative și adaptive în gestionarea proiectelor agile care pot fi utilizate în cazul în care obiectivul unui proiect este clar definit, dar metodele prin care se ajunge la acesta nu sunt. Imaginați-vă un continuum de proiecte care variază de la situațiile în care aproape toată soluția este clară și complet definită la situațiile în care foarte puțin din soluție este definită în mod clar și complet.

Există o serie de proiecte care ocupă cadranul APM. Dacă ne gândim la proiectele noastre, care se încadrează în acest cadran, putem considera că multe, dacă nu cea mai mare parte din ele sunt proiecte APM. În acest caz, este mai bine să avem în vedere folosirea unei abordări de gestionare care să răspundă caracteristicilor și soluțiilor proiectului, decât să forțăm o abordare, care a fost proiectată pentru un alt proiect cu caracteristici foarte diferite.

Proiectele Agile sunt în continuă creștere. Cel puțin 70 la sută din toate proiectele dezvoltate sunt proiecte APM, 20 la suta sunt proiecte TPM, iar 10 la sută rămas este împărțit între proiectele XPM(Extreme Project Management) și MPX(Emertxe Project Management). Din păcate, mulți manageri de proiect încerca să se aplice abordări tradiționale proiectelor agile și au foarte puțin succes. Rezultatele variază de la succes mediocru la eșec total. Proiectele agile prezintă un alt tip de provocare și au nevoie de o abordare diferită. Abordarea proiectului trebuie să fie condusă de caracteristicile proiectului, iar inversarea ordinii duce la dezastru.

Nu se poate să definim un proiect ca o experiența unică care nu s-a mai întâmplat înainte și nu se va întâmpla din nou sub același set de circumstanțe, dar nici nu se poate afirma că abordarea potrivită pentru aceste proiecte unice va fi, de asemenea, unică. Se poate spune că abordarea unui proiect este unică până la un punct. Unicitatea sa este constrânsă de faptul că trebuie să utilizeze un set de instrumente validate și certificate, șablonuri și procese. Dacă nu s-ar stabili o astfel de limită cu privire la modul în care se gestionează un proiect atunci ar fi haos.

Atât timp cât soluțiile evoluează de la cele care sunt specificate clar la cele care nu sunt, ne vom deplasa printr-o serie de situații care necesită o manipulare diferită.

De exemplu, să presupunem că doar unele aspecte minore ale soluției nu sunt cunoscute, să zicem fundalul și culoarea fontului pentru ecranele de autentificare. Cum ai proceda? O abordare oarecare pozează la fel de mult ca o soluției iar la momentul respectiv ar trebui să funcționeze destul de bine. Această abordare ar permite clientului să examineze, în sensul unui prototip de producție, ceea ce se presupune a fi soluție într-o încercare de a descoperi ceea ce nu este soluție. La extreme, atunci când se știe foarte puțin despre soluție, proiectele au risc mai mare decât cele în care o parte mai mare a soluției este cunoscută. Este nevoie de o soluție, și este important să fie găsită o soluție. Este necesară orice formă de abordare a proiectului pentru a învăța și a descoperi soluția. Cumva această abordare trebuie să înceapă cu ceea ce este cunoscut și de a se ajunge la ceea ce nu se cunoaște.

Există mai multe abordări pentru proiectele APM(Agile Project Management). Nu pentru toate abordările APM, se poate construi o WBS (Work Breakdown Structure) completă fără a “ghici”. Pentru că ghicitul este inacceptabil în buna planificare a unui proiect, trebuie aleasă o abordare pentru a lucra în absența totală WBS. Toate abordările APM sunt structurate astfel încât să putem învăța și descoperi părțile lipsă ale soluției. Când aceste piese lipsă sunt descoperite, ele sunt integrate în soluție.

Proiectele care folosesc corect o abordare APM au mai multe caracteristici definitorii identificate în paragrafele care urmează.

Există proiecte care trebuie făcute – nu ai de ales, dar care întâmpină o problemă critică pentru care nu există o soluție cunoscută. Deoarece nu există nici o soluție cunoscută, o abordare tradițională nu va funcționa. Singurele metode care au sens sunt cele care permit descoperirea unei soluție acceptabile de a face proiectul. Unele dintre funcțiile și caracteristicile soluției poate fi cunoscut, dar nu există suficientă valoare în afaceri pentru cunoașterea soluție parțiale pentru a fi pus în aplicare.

În cazul în care compania întâlnește o oportunitate de afaceri anterior neexploatată și nu profită de acest tip de proiect atunci va pierde o oportunitate de afaceri. Compania totuși trebuie să găsească o modalitate de a profita de aceasta printr-un nou sau reînnoit produs sau serviciu pe care să-l ofere.

Proiectele APM sunt critice pentru organizație. Trebuie conștientizat faptul că un proiect agile poate fi un risc foarte ridicat pentru companie. În cazul în care încercările anterioare de a rezolva problema nu au avut succes, înseamnă că problema este complexă și că nu există o soluție acceptabilă a problemei. Proiectele desfășurate pentru a găsi această soluție ar putea sa funcționeze mai bine evaziv în cazul în care sunt axate pe părți ale problemei sau dacă abordarea se face ca un proces de îmbunătățire.

In cadrul proiectelor agile implicarea clientului este esențială. Soluția va fi descoperită numai în cazul în care clientul și echipa de dezvoltare colaborează semnificativ într-un mediu deschis și onest. Pentru client, aceasta înseamnă deplina participare alături de echipa de proiect și oportunitatea de a învăța cum să fie un client într-o lume agile. Pentru echipa de dezvoltare, aceasta înseamnă o oportunitate de a afla mai multe despre afacerea clientului și a descoperi cum să comunice în aceeași limbă. Pentru managerul de proiect, aceasta înseamnă pregătirea, atât a echipei clientului cât si echipa de dezvoltare pentru a lucra împreună într-un mediu deschis și de colaborare. Aceasta înseamnă, de asemenea că managerul de proiect va trebui să împartă responsabilitatea și conducerea cu un manager de clienți.

Proiectele agile folosesc echipe de proiect mici, iar în cazul în care proiectul necesită o echipă de mai mult de 30 de profesioniști, managerul de proiect probabil ar trebui să partiționeze proiectului în mai multe proiecte mai mici, cu mai multe domenii limitate. Pentru a gestiona o echipa de proiect, aceasta se împarte în echipe mici, fiecare dintre aceste echipe fiind responsabilă pentru o parte a domeniului de aplicare. Este necesară configurarea unui program de întâlniri pentru a gestiona și coordona activitatea echipelor mici de proiect.

Prezentarea Scrum

Deși cadrul scrum poate fi folosit pentru a furniza orice tip de proiect, acesta este cel mai adesea utilizat pentru a gestiona proiecte de dezvoltare de software.

Este bine cunoscut faptul că multe astfel de proiecte folosesc pentru organizare și livrare ceea ce este cunoscut sub numele de modelul cascadă.

Modelul cascadă cuprinde următoarele etape: o etapă în care un analist va aduna specificațiile proiectului, o etapă de proiectare în care cerințele produsului sunt planificate și modelate, etapa de implementare în care se construiește produsul. Urmează o etapă de testare în care testerii se asigură că produsul îndeplinește cerințele pentru satisfacerea calității, iar în final produsul este pus la dispoziția publicului.

După ce produsul se lansează se desfășoară o etapă continuă de suport și întreținere în mediul real.

Modelul cascadă a fost văzut ca un proces standard industrial pentru derularea de proiecte software de zeci de ani și la prima vedere are sens. Cu toate acestea, există unele defecte fundamentale cu această metodă. În cazul în care condițiile se schimbă după faza de specificații, atunci acest lucru are un efect indirect asupra celorlalte faze. Prin urmare, data de lansare devine mai greu de atins.

În plus, cea mai mare parte a defectelor și problemelor nu sunt de obicei găsite până în faza de testare. Aceste probleme întârzie de multe ori lansarea produsului, deoarece este nevoie de mai mult timp pentru a remedia erorile. Nu se poate prognoza vreodată exact cât de multe defecte se vor găsi, așa că această situație conduce de obicei la ore suplimentare, moral scăzut și o aglomerare spre sfârșitul proiectului.

Când proiectul este întrerupt pentru a se adăuga noi specificații managementul nu este întotdeauna de acord cu aceste modificări, dar pe termen lung nu reprezintă o soluție amiabilă, deoarece schimbarea este de multe ori o reacție la condițiile de piață și este de multe ori un lucru bun.

Schimbarea specificațiilor poate crește randamentul afaceri și are de obicei efecte benefice pentru companie și angajați. În practică această situație este des întâlnită deoarece firmele vor avea ca scop să schimbe specificațiile și să-și facă griji cu probleme mai târziu. Cu toate acestea, nici una dintre situații nu este bună, iar în final toată lumea implicată în proiect dorește cel mai bun rezultat posibil.

După decenii de proiecte rulate folosind modelul cascadă, este clar că multe companii s-au confruntat cu aceste probleme și unele modificări au fost necesare pentru a gestiona schimbările pentru ca proiectele să ruleze fără probleme.

În scrum aceste aspecte sunt cunoscute ca impedimente sau blocaje. Împreună, aceste blocaje poate provoca haos în proiecte. Recunoscând aceste blocaje, un grup de lideri de opinie și-au unit forțele pentru a crea metode noi, iterative(agile) de lucru. O astfel de metodă este scrum.

Termenul "agil", este una care este adesea folosit necorespunzător în industria de dezvoltare software. Având în vedere că agil este atât de strâns legat de scrum, este necesar să fixez exact ce înseamnă agile și modul în care este relevant în contextul scrum.

Până la sfârșitul anilor 1990 a existat un consens larg al liderilor de opinie care au recunoscut scăderea performanțelor metodei cascadă în dezvoltarea de software. Astfel ei și-au fondat propriile metode noi iterative de dezvoltarea a produselor software. Dezvoltarea iterativă este fundamental diferită de cascadă. Spre deosebire de fazele inițiale cu o mulțime de specificații colectare în avans, metode scrum conține mini faze ale: specificațiilor, de proiectare, de implementare, de testare și de livrare într-un număr de săptămâni. Acest lucru permite afacerii să lanseze o parte din proiect și să încaseze astfel profit.

De asemenea, dezvoltatorul ajunge să descopere potențialele probleme în avans și să schimbe specificațiile proiectului mult mai de astfel încât produsul final să fie cel necesar clientului.

Multe dintre aceste metode iterative au fost accesptate ușor deoarece managerii cred că rezolvarea unor sarcini simple rezolvă mult mai repede orice problemă dată sau nou apărută.

În anul 2000, văzând răspândirea metodelor interative un grup de lideri de opinie numit Object Mentor Group a convocat o ședință la Snowbird SchiyResort în Utah și au pus bazele manifestului agile cu următorul cuprins:

Manifest pentru dezvoltare Agile Software

“We are uncovering better ways of developing software by doing it and helping others do it. Through thiswork we have come to value:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more.”

Noi scoatem la iveală modalități mai bune de dezvoltare de software prin experiență proprie și ajutându-i pe ceilalți.

Prin această activitate am ajuns să apreciem:

Indivizii și interacțiunea înaintea proceselor și uneltelor

Software funcțional înaintea documentației vaste

Colaborarea cu clientul înaintea negocierii contractuale

Receptivitatea la schimbare înaintea urmăririi unui plan

Cu alte cuvinte, deși există valoare în elementele din dreapta, le apreciem mai mult pe cele din stânga.

Acest manifest a fost însoțită de un set de principii, aprobat de toți.

Pe scurt, agil nu este o alternativă la scrum, dar un termen umbrelă pentru o serie de metodologii și cadre care împărtășesc un manifest și un set de principii.

Ken Schwaber și Jeff Sutherland (doi dintre fondatorii originali ai metodologiei scrum) descriu scrum ca am "un cadru pentru dezvoltarea și susținerea produselor complexe".

Scrum constă în auto-organizare, echipe de cofuncționale.

Simplu spus, acest lucru înseamnă că echipele constau din grupuri de oameni care au fiecare diferite domenii de expertiză, dar lucrează împreună pentru același rezultat.

Un manager de proiect nu îi controlează, deoarece expertiza lor îi împuternicește să ia decizii în mod colectiv. Echipele lucrează în iterații, care oferă afacerii flexibilitatea de a schimba specificațțile, dar care dă echipei de dezvoltare certitudinea de acare are nevoie pentru a oferi o versiune funcțională a produsului.

Acesta este un lucru esențial care face scrum puternic. Scrum își ia numele de la analogia cu rugby-ul în care o echipă lucrează împreună într-un mediu haotic pentru a păstra controlul unei mingi. Acest lucru poate fi comparat cu o echipă care lucrează împreună într-un mediu haotic pentru a păstra controlul asupra unui proiect.

Scrum oferă un set de reguli prin care oamenii pot adresa probleme complexe de adaptare, furnizând într-un mod productiv și creativ produse de cea mai înaltă valoare posibilă.

Scrum este:

Ușor

Simplu de înțeles

Dificil de stăpânit

Scrum este un cadru de proces utilizat pentru a gestiona dezvoltarea de produse complexe încă de la începutul anilor 1990. Scrum nu este un proces sau o tehnică de construire a produselor; mai degrabă este o bază de reguli prin care se pot încadra diferite procese și tehnici.

Scrum clarifică eficacitatea relativă a managementului de produs și practicile de dezvoltare astfel încât să poată fi îmbunătățit.

Cadrul Scrum

Metodologia scrum implică intervenția a trei protagoniști:

Product owner: În majoritatea proiectelor, responsabilul de produs (product owner) este coordonatorul echipei clientului. El este cel care definește și stabilește funcționalitățile prioritare și alege data și conținutul fiecărui sprint pe baza valorilor (volumelor de lucru) comunicate de echipă.

Scrum master: Acesta 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.

Echipa: fiind de regulă alcătuită din circa 5 ±2 persoane, echipa adună la un loc specialiștii necesari în cadrul unui proiect, și anume: arhitectul, designerul, programatorul, testerul etc.

Echipa se organizează singură și rămâne neschimbată pe toată durata sprintului.

Cadrul scrum este alcătuit din echipe scrum și din rolurile, evenimentele, artefactele și regulile asociate lor. Orice constituent din acest cadru servește unui anumit scop și este esențial în reușita și utilizarea scrum-ului. Regulile din scrum leagă împreună evenimentele, rolurile și artefactele, guvernând asupra relațiilor și interacțiunea dintre ele.

Scrum este fondat pe teoria empirică de control al procesului, sau empirismul. Empirismul declară că din experiență vin cunoștințele și luarea deciziilor se bazează pe ceea ce cunoaștem. Scrum angrenează o abordare iterativă, incrementală cu scopul de a optimiza predictibilitatea și controlarea riscurilor. Trei piloni susțin orice implementare a controlului procesului empiric: transparența, inspecția, și adaptarea.

Aspecte semnificative ale procesului trebuie să fie vizibile celor responsabili cu rezultatele. Transparența cere ca aceste aspecte să fie definite de un standard comun astfel încât observatorii să interpreteze în același fel ceea ce văd. De exemplu:

Un limbaj comun referitor la proces, care trebuie cunoscut de toți participanții; și, cei care efectuează munca și cei care acceptă produsul rezultat trebuie să înțeleagă la fel definiția stării de „Finalizat”.

Utilizatorii scrum trebuie să inspecteze în mod frecvent artefactele și progresul făcut în îndeplinirea obiectivului sprintului astfel încât să detecteze schimbările nedorite. Inspecția lor nu trebuie să fie atât de frecventă încât să împiedice munca. Inspecția este benefică mai ales atunci când este efectuată în mod sârguincios de către inspectori abili la locul de muncă.

Dacă un inspector determină că unul sau mai multe aspecte ale procesului deviază de la limitele acceptabile și că produsul rezultat va fi inacceptabil, procesul sau materialul care este prelucrat trebuie să fie ajustat. Scrum prestabilește patru momente formalizate de inspecție și adaptare:

Planificarea sprintului (Sprint planning)

Scrum-ul zilnic (Daily scrum)

Revizuirea sprintului (Sprint review)

Retrospectiva sprintului (Sprint retrospective)

Scrum este un cadru structurat în așa fel încât să suporte dezvoltarea produselor complexe. Scrum este alcătuit din echipele scrum și rolurile lor, evenimentele, artefactele și regulile asociate acestora. Fiecare componentă servește unui anumit scop și este esențială utilizării și reușitei scrum-ului.

Echipa scrum

Echipa scrum este alcătuită din product owner („deținătorul produsului”) , echipa de dezvoltare (development team), și un scrum master („maestrul scrum”). Echipele scrum se auto-organizează și sunt transversal-funcționale. Echipele auto-organizate își aleg mai degrabă cum să-și îndeplinească munca cel mai bine, decât să fie ghidați de alții din afara echipei. Echipele transversal-funcționale au toate abilitățile necesare să-și îndeplinească munca fără să depindă de alte persoane din afara echipei. Echipa model scrum este concepută să optimizeze flexibilitatea, creativitatea și productivitatea. Echipele scrum livrează produsele în mod iterativ și incremental, maximizând oportunitățile de obținere a feedbackului. Livrările incrementale ale produsului „finalizat” (Done), asigură că avem mereu o versiune potențial folositoare a produsului în lucru care este mereu disponibilă.

Product owner-ul (Deținătorul Produsului)

Product onwer-ul este responsabil cu maximizarea valorii produsului și a muncii echipei de dezvoltare. Modul în care maximizarea este implementată poate varia foarte mult în funcție de organizații, echipele scrum sau de indivizi. Product onwer-ul este singura persoană responsabilă cu gestiunea product backlog-ului. Managementul product backlog-ului include:

exprimarea precisă a elementelor din product backlog;

ordonarea elementelor din product backlog pentru a realiza cel mai bine obiectivele și misiunile;

optimizarea valorii muncii realizate de echipa de dezvoltare;

garantarea faptului că product backlog-ul este vizibil, transparent, și clar pentru toți, și arată pe ce anume va lucra echipa în continuare; și, garantarea faptului că echipa înțelege elementele din product backlog până la nivelul necesar.

Product owner-ul poate să facă activitățile de mai sus, sau să ceară echipei de dezvoltare să o facă. Totuși, product owner-ul rămâne responsabil. Product owner-ul este o persoană, nu un comitet. Product owner-ul poate să reprezinte dorințele unui comitet în product backlog, dar cei care doresc să modifice prioritatea unui element din product backlog trebuie să se adreseze product owner-ului. Pentru ca product owner-ul să reușească, întreaga organizație trebuie să-i respecte deciziile. Deciziile product owner-ului sunt vizibile în conținutul și ordonarea product backlog-ului. Nimeni nu are voie să ceară echipei de dezvoltare să lucreze dintr-un alt set de cerințe, și echipa de dezvoltare nu are voie să acționeze la ceea ce spune altcineva.

Echipa de dezvoltare (Development Team)

Echipa de dezvoltare este alcătuită din profesioniști care îndeplinesc sarcinile de livrare a incrementului (Increment) de produs potențial livrabil cu elemente „finalizate” (done) la finalul fiecărui sprint. Doar membrii echipei de dezvoltare creează incrementatul (the Increment). Echipele de dezvoltare sunt structurate și împuternicite de organizație să-și organizeze și să-și gestioneze munca. Sinergia rezultată optimizează eficacitatea și eficiența în ansamblul echipei de dezvoltare.

Echipele de dezvoltare au următoarele caracteristici:

Se auto-organizează. Nimeni (nici măcar scrum master-ul) nu spune echipei de dezvoltare cum să transforme product backlog-ul în incremente (Increments) ale funcționalității potențial livrabile;

Echipele de dezvoltare sunt transversal-funcționale, cu toate abilitățile necesare ca echipă să creeze un increment al produsului;

Scrum nu recunoaște niciun titlu pentru membrii echipei de dezvoltare în afară de dezvoltator, indiferent de munca realizată de respectiva persoană; nu există excepții de la această regulă;

Scrum nu recunoaște sub-echipe în echipa de dezvoltare, indiferent de domeniile particulare care trebuiesc adresate precum testarea sau analiza de business; nu există excepții de la această regulă; și,

Membrii individuali ai echipei de dezvoltare ar putea avea abilități specializate sau zone de interes, dar răspunderea aparține echipei de dezvoltare ca un întreg.

Dimensiunea echipei de dezvoltare

Mărimea echipei de dezvoltare optime este suficient de mică ca să rămână sprintenă și destul de mare încât să termine o muncă semnificativă în timpul sprintului. Mai puțin de trei membri ai echipei de dezvoltare va scădea interacțiunea rezultând în câștiguri mai mici de productivitate. Echipe de dezvoltare mai mici ar putea întâmpina constrângeri legate de competențe în timpul sprintului, făcând echipa de dezvoltare incapabilă să livreze un increment potențial livrabil. Necesitatea de coordonare este prea mare când sunt mai mult de nouă membri. echipele de dezvoltare mari generează prea multă complexitate pentru a fi gestionate de un proces empiric. Rolurile de product owner și scrum master nu sunt luate în calcul atâta timp cât ei nu execută munca din sprint backlog.

Scrum master-ul (Maestrul scrum)

Scrum master-ul este responsabil cu garantarea înțelegerii și adoptării scrum-ului. Scrum master-ii fac asta asigurându-se că echipa scrum aderă la teoria, practicile și regulile scrum. Scrum master-ul este un servitor-lider pentru echipa scrum. Scrum master-ul îi ajută pe cei din afara echipei scrum să înțeleagă care din interacțiunile lor cu echipa scrum sunt utile și care nu. Scrum master-ul ajută pe toată lumea să schimbe aceste interacțiuni ca să maximizeze valoarea creată de echipa scrum.

Serviciile scrum master-ului pentru product owner

Scrum master-ul își servește product owner-ul în câteva moduri, printre care:

Găsind tehnici de gestionare eficace a product backlog-ului;

Comunicând clar și concis viziunea, obiectivele, și elementele product backlog-ului către echipa de dezvoltare;

Ajutând echipa scrum să creeze să înțeleagă nevoia de elemente clare și concise în product backlog;

Înțelegând planificarea produsului pe termen lung într-un mediu empiric;

Asigurându-se că product owner-ul cunoaște cum să aranjeze product backlog-ul ca să maximizeze valoarea;

Înțelegând și practicând agilitatea; și,

Facilitând evenimentele scrum așa cum sunt cerute sau necesare

Serviciile scrum master-ului pentru echipa de dezvoltare

Scrum master-ul își servește echipa de dezvoltare-ul în câteva moduri, printre care:

Antrenând echipa de dezvoltare în auto-organizare și transveral-funcționare;

Ajutând echipa de dezvoltare să creeze produse cu valoare ridicată;

Eliminând obstacolele (impediments) din calea echipei de dezvoltare;

Facilitând evenimentele scrum așa cum sunt cerute sau necesare; și,

Antrenând echipa de dezvoltare în mediile organizaționale în care scrum-ul nu este încă adoptat sau înțeles.

Serviciul scrum master-ului pentru Organizație

Scrum master-ul își servește Organizația în mai multe moduri, printre care:

Îndrumând și antrenând Organizația în adoptarea scrum;

Planificând implementarea scrum-ului în cadrul organizației;

Ajutând angajații și persoanele implicate să înțeleagă și să adopte scrum și să înțeleagă dezvoltarea empirică de produse;

Cauzând schimbarea care crește productivitatea echipe de scrum; și

Lucrând cu alți scrum master-i să crească eficiența aplicării scrum-ului în organizație.

Evenimentele scrum

Evenimentele prestabilite sunt folosite în scrum să creeze regularitate și să minimizeze nevoia de ședințe nedefinite în scrum. Toate evenimentele sunt limitate în timp, astfel încât fiecare eveniment să aibă o durată maximă. Odată ce un sprint pornește, durata lui este fixă și nu poate fi micșorat sau mărit. Evenimentele rămase se pot termina oricând atunci când scopul lor este atins, asigurându-ne că timpul corespunzător este consumat fără să permitem irosirea lui în proces. În afara sprintului propriu-zis, care este containerul pentru toate celelalte evenimente, fiecare eveniment din scrum este o oportunitate formalizată de a inspecta și adapta ceva. Aceste evenimente sunt concepute special să permită transparența esențială și inspecția.

Eșecul de a include oricare dintre aceste evenimente conduce la o transparență redusă și este o oportunitate pierdută să inspectăm și să adaptăm.

Sprintul

Inima scrum-ului este un sprint, limitat la o lună sau mai puțin, în timpul căruia se creează incrementul produsului „finalizat” (done), utilizabil și potențial livrabil. Sprinturile cele mai bune au o durată consistentă de-a lungul efortului de dezvoltare. Un nou sprint începe imediat după concluzia sprintului anterior. Sprinturile conțin și sunt alcătuite din Planificarea sprintului (sprint planning), scrum-ul zilnic (daily scrum), muncă de dezvoltare, Revizuirea sprintului (sprint review) și Retrospectiva sprintului (sprint retrospective).

În timpul sprintului:

Nicio schimbare care să pună în pericol obiectivul sprintului (sprint goal) nu este făcută;

Obiectivele legate de calitate nu scad; și,

Scopul sprintului poate fi clarificat și renegociat între product owner și echipa de dezvoltare pe măsură ce învățăm.

Fiecare sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lună. Ca proiectele, scopul sprinturilor este să îndeplinească ceva. Fiecare sprint are o definiție despre ceea ce urmează să fie construit, un concept și un plan flexibil care va ghida echipa în construcția lui, munca și produsul de realizat. Sprinturile sunt limitate la o lună calendaristică.

Când orizontul unui sprint este prea lung definiția a ceea ce construim se poate schimba, iar complexitatea și riscurile pot crește. Sprinturile permit predictibilitate asigurând inspecția și adaptarea progresului către obiectivul sprintului măcar la fiecare lună calendaristică. De asemenea sprinturile limitează riscurile privind costurile la o lună calendaristică.

Anularea sprintului

Un sprint poate fi anulat înainte de data prevăzută inițial. Doar product owner-ul are autoritatea de a Anula sprintul, deși acesta poate acționa sub influența persoanelor implicate, echipei de dezvoltare sau a scrum master-ului. Un sprint poate fi anulat și în cazul în care ținta sprint-ului devine perimată. Asta s-ar putea întâmpla dacă compania schimbă direcția sau dacă condițiile pieței sau cele tehnologice se schimbă. În general, Un sprint ar trebui să fie anulat dacă nu mai are sens în circumstanțele date. Dar, din cauza duratei scurte a sprinturilor, anularea are rar sens. Când un sprint este anulat, toate elementele „Finalizate” (Done) ale product backlog-ului sunt revizuite. Dacă o parte din lucrurile realizate sunt potențial livrabile, de obicei product owner-ul le va accepta. Toate elementele incomplete ale product backlog-ului sunt reestimate și repuse în product backlog. Munca făcută pe aceste elemente se depreciază rapid și trebuie să le reestimăm în mod frecvent. Anularea sprintului consumă resurse, deoarece toată lumea trebuie să se regrupeze într-o altă ședință de Planificare a sprintului (sprint Planning) pentru a începe un alt sprint. Anulările sprinturilor sunt adesea traumatizante pentru echipa de scrum și sunt foarte rar întâlnite.

Planificarea sprintului (sprint planning meeting)

Muncă ce urmează a fi realizată în cadrul sprintului este planificată în ședința de Planificare a sprintului. Acest plan este creat prin munca colaborativă a întregii echipe de scrum. Planificarea sprintului este limitată în timp la un maxim de 8 ore pentru un sprint de o lună calendaristică. Pentru sprinturi mai scurte, evenimentul este de obicei mai scurt.

scrum master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum master-ul își învață echipa scrum să păstreze evenimentul limitat în timp.

Planificarea sprintului răspunde la următoarele:

Ce poate fi livrat în incrementul care rezultă din sprintul următor?

Cum va fi efectuată munca pentru ca acest increment să fie livrat?

Primul subiect: Ce poate fi făcut în acest sprint?

Echipa de dezvoltare lucrează să anticipeze funcționalitatea pe care o vor dezvolta în decursul sprintului. Product owner-ul discută obiectivele pe care sprintul trebuie să le întâlnească și elementele din product backlog care, dacă sunt completate în sprint, ar atinge Obiectivul sprintului. Datele de intrare la această întrunire sunt product backlog-ul, ultimul Increment al produsului, capacitatea estimată a echipei de dezvoltare pe parcursul sprintului și performanțele anterioare ale echipei de dezvoltare. Numărul de elemente selectate din product backlog pentru sprint este decis exclusiv de către echipa de dezvoltare. Numai echipa de dezvoltare poate evalua ce poate să realizeze pe parcursul sprintului următor. După ce echipa de dezvoltare prognozează elementele din product backlog pe care le va livra în decursul sprintului, întreaga echipă scrum definește Obiectivul sprintului. Obiectivul sprintului este o țintă care va fi atinsă în sprint prin implementarea product backlogului, și oferă îndrumări echipei de dezvoltare despre motivul construirii Incrementului.

Al doilea subiect: Cum se vor realiza activitățile selecționate?

Având ceea ce este de făcut în cadrul sprintului Obiectivul sprintului stabilit și elementele din product backlog selecționate, echipa de dezvoltare decide cum va construi această funcționalitate într-un Increment de produs „finalizat” (Done) pe parcursul sprintului.

Elementele selecționate pentru acest sprint plus planul cu livrarea lor este numit backlog-ul de sprint (sprint backlog). Echipa începe de obicei cu conceperea sistemului și a lucrului necesar conversiei product backlog-ului în incrementul de produs funcțional. Lucrul poate fi de diferite dimensiuni sau efort estimat. Cu toate acestea, în ședința de planificare a sprintului planificăm suficientă muncă, astfel încât echipa de dezvoltare să poată previziona ceea ce crede că poate realiza pe parcursul sprintului următor. Lucrul planificat pentru primele zile este descompus până la finalul întrunirii, de obicei în unități de o zi sau mai puțin, echipa de dezvoltare se auto-organizează pentru îndeplinirea lucrului din backlog-ul de sprint, atât în timpul Planificării sprintului cât și atunci când este nevoie pe parcursul sprintului. Product owner-ul poate ajuta ar putea fi prezent la clarificarea elementelor selecționate din product backlog și să facă compromisuri. Dacă echipa de dezvoltare determină că are prea mult de muncă sau prea puțin, ar putea renegocia elementele selectate din product backlog cu product owner-ul. Echipa de dezvoltare ar putea de asemenea să invite alți oameni să participe cu scopul de a furniza sfaturi tehnice sau legate de domeniul de business. Până la finalul Planificării sprintului, echipa de dezvoltare ar trebui să fie capabilă să explice product owner-ului și scrum master-ului cum intenționează să lucreze ca echipă auto-organizată în vederea realizării Obiectivului de sprint și să creeze Incrementul anticipat.

Obiectivul sprintului (sprint goal)

Obiectivul sprintului este o țintă setată pentru sprint, care poate fi atinsă prin implementarea product backlog-ului. Aduce îndrumări echipei de dezvoltare referitor la motivele implementării Incrementului. Este creat pe parcursul ședinței de Planificare a sprintului. Obiectivul sprintului oferă echipei de dezvoltare un anumit grad de flexibilitate în ceea ce privește funcționalitatea implementată în decursul sprintului. Elementele selectate din product backlog livrează o funcție coerentă, care poate fi obiectivul sprintului. Obiectivul sprintului poate fi orice coerență care determină echipa de dezvoltare să lucreze mai degrabă împreună decât pe inițiative separate. Pe măsură ce echipa de dezvoltare lucrează, păstrează obiectivul sprintului în minte. Pentru a realiza obiectivul sprintului, aceasta implementează funcționalitatea și tehnologia. Dacă munca se dovedește a fi diferită de ceea ce echipa de dezvoltare s-a așteptat, ei colaborează cu product owner-ul în vederea negocierii scopului sprint backlog-ului pe parcursul sprintului. Obiectivul sprint-ului poate fi un jalon în cadrul scopului mai mare al planului de produs.

Scrumul zilnic (Daily scrum)

Scrum-ul zilnic este un eveniment cu durata limitată la 15 minute cu scopul sincronizării activităților echipei de dezvoltare și creării unui plan pentru următoarele 24 de ore. Toate astea pot fi reușite prin inspectarea lucrului realizat de la scrum-ul zilnic anterior și prognozând lucrul pe care pot să-l realizeze până la următorul. Scrum-ul zilnic se desfășoară la aceeași oră și în același loc în fiecare zi pentru a reduce complexitatea. În timpul ședinței, membrii echipei de dezvoltare explică:

Ce am făcut ieri și a ajutat echipa de dezvoltare la îndeplinirea obiectivului de sprint?

Ce voi face astăzi ca să ajut echipa de dezvoltare să îndeplinească obiectivul sprintului?

Văd vreun obstacol care să mă împiedice pe mine sau pe echipa de dezvoltare să îndeplinească obiectivul sprintului?

Echipa de dezvoltare folosește scrum-ul zilnic ca să inspecteze progresul spre îndeplinirea obiectivului de sprint și totodată să inspecteze tendința progresului în finalizarea lucrului din backlog-ul de sprint. Scrum-ul zilnic optimizează probabilitatea ca echipa de dezvoltare să-și atingă obiectivul sprintului. În fiecare zi, echipa de dezvoltare ar trebui să înțeleagă cum intenționează să lucreze împreună, ca o echipă care se auto-organizează să îndeplinească Obiectivul sprintului și să creeze Incrementul anticipat până la finalul sprintului. Echipa de dezvoltare sau membrii echipei se întâlnesc deseori pentru discuții detaliate, ori să adapteze sau să replănuiască restul lucrului de realizat în sprint. Scrum master-ul se asigură că echipa de dezvoltare are o ședință, dar echipa de dezvoltare este responsabilă pentru dirijarea scrum-ului zilnic. Scrum master-ul instruiește echipa de dezvoltare să păstreze scrum-ul zilnic în limita celor 15 minute. Scrum master-ul împuternicește regula ca doar echipa de dezvoltare să participe la scrum-ul zilnic. scrum-urile zilnice îmbunătățesc comunicarea, elimină alte ședințe, identifică obstacolele pentru a fi scoase din calea dezvoltării, evidențiază și promovează luarea rapidă a deciziilor și îmbunătățește nivelul de cunoștințe al echipei de dezvoltare. Această întâlnire este un factor cheie de inspecție și adaptare.

Revizuirea sprintului (sprint review)

Ședința de Revizuirea a sprintului este ținută la finalul sprintului pentru a inspecta Incrementul și a adapta product backlog-ul dacă este necesar. Pe parcursul Revizuirii sprintului, echipa scrum și persoanele implicate colaborează cu privire la ceea ce a fost finalizat în sprint. Pornind de la aceasta și de la orice altă modificare adusă product backlog-ului în timpul sprintului, participanții colaborează legat de următoarele lucruri pe care le pot îndeplini ca să optimizeze valoarea. Este o ședință informală, nu de raportare, și prezentarea Incrementului este intenționată să smulgă feedbackul și să promoveze colaborarea. Durata Revizuirii sprintului este limitată la 4 ore pentru sprinturile de o lună. Pentru sprinturi mai mici, evenimentul durează de obicei mai puțin. Scrum master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum master-ul își învață echipa să nu depășească limita de timp definită. Revizuirea sprintului include următoarele elemente:

În lista participanților este inclusă echipa scrum și persoanele implicate cheie invitate de product owner;

Product owner-ul explică care elemente din product backlog au fost finalizate și ce nu a fost finalizat;

Echipa de dezvoltare, discută ce a funcționat bine în timpul sprintului, care au fost problemele de care s-au lovit, și cum au fost rezolvate aceste probleme;

Echipa de dezvoltare, demonstrează lucrul „finalizat” (Done) și răspunde întrebărilor legate de Increment;

Product owner-ul discută product backlog-ul așa cum se prezintă în momentul respectiv. El sau ea preconizează datele posibile de finalizare bazate pe progresul înregistrat până în prezent (dacă este necesar);

Întregul grup colaborează legat de ceea ce urmează să implementeze ulterior, astfel încât Revizuirea sprintului să furnizeze date de intrare de valoare pentru următoarea sesiune de Planificare a sprintului;

Se revizuiește cum piața de desfacere sau utilizarea potențială a produsului ar fi schimbat cel mai valoros lucru cu care să continuăm; și,

Revizuirea cronologiei proiectului, bugetului, capabilităților potențiale și a pieței de desfacere pentru următoarea livrare anticipată.

Rezultatul Revizuirii sprintului este un product backlog revizuit care definește elementele probabile din product backlog pentru următorul sprint. product backlog-ul poate fi ajustat în ansamblul lui pentru a răspunde unor oportunități noi.

Retrospectiva sprintului (sprint retrospective)

Retrospectiva sprintului reprezintă o oportunitate pentru echipa scrum să se inspecteze pe ea însăși și să creeze un plan cu ameliorări pe care să le adopte în sprintul următor. Retrospectiva sprintului are loc după Revizuirea sprintului și înaintea următoarei sesiuni de Planificarea sprintului. Această ședință are durata constrânsă la 3 ore pentru sprinturile de o lună. Pentru sprinturile mai mici, acest eveniment durează de obicei mai puțin. Scrum master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum master-ul își învață echipa să nu depășească limita de timp definită. Scrum master-ul participă la ședință ca un membru egal al echipei datorită responsabilității sale asupra procesului scrum.

Scopul retrospectivei sprintului este:

De a inspecta modul în care ultimul sprint a funcționat cu privire la oameni, relații, proces, și instrumente;

De a identifica și ordona elementele majore care au mers bine și îmbunătățirile potențiale; și

De a crea un plan pentru punerea în aplicare a îmbunătățirilor în modul în care echipa scrum își desfășoară activitatea.

Scrum master-ul își încurajează echipa de scrum să îmbunătățească, în cadrul contextului scrum, procesul de dezvoltare și practicile pentru ca dezvoltarea să devină mai eficace și plăcută pentru sprintul următor. Pe parcursul fiecărei Retrospective de sprint, echipa scrum planifică moduri de creștere a calității prin adaptarea definiției „Finalizat” (Done) atunci când este nevoie. Până la finalul Retrospectivei sprintului, echipa scrum ar trebui să fi identificat ameliorări pe care să le implementeze în sprintul următor. Implementarea acestora în sprintul următor este adaptarea la inspecția echipei scrum. Deși îmbunătățirile pot fi implementate în orice moment, Retrospectiva sprintului este o oportunitate formală de a se concentra pe inspecție și adaptare.

Artefactele scrum

Artefactele scrum reprezintă munca și valoarea cu scopul furnizării transparenței și a oportunităților pentru inspecție și adaptare. Artefactele definite de scrum sunt concepute special pentru a maximiza transparența informațiilor cheie, astfel încât fiecare să aibă același nivel de înțelegere asupra artefactelor.

Product backlog (backlog-ul de produs)

Product backlog-ul este o listă ordonată cu tot ce poate fi necesar în produs și este singura sursă de cerințe conținând toate schimbările care trebuie făcute produsului. Product owner-ul este responsabil de product backlog, incluzând conținutul său, disponibilitatea și ordinea sarcinilor. Product backlog-ul nu este niciodată complet. Cea mai timpurie dezvoltare a sa prezintă cerințele cunoscute inițial și cel mai bine înțelese. Product backlog-ul evoluează odată cu produsul și evoluția mediului în care acesta va fi folosit. Product backlog-ul este dinamic, se schimbă constant pentru a identifica de ce are nevoie produsul pentru a fi adecvat, competitiv și folositor. Atâta timp cât un produs există, va exista și product backlog-ul acestuia. Product backlog-ul listează toate caracteristicile, facilitățile, funcțiile, cerințele, îmbunătățirile și corecțiile care constituie schimbările necesare a fi făcute produsului în livrările viitoare. Elementele din product backlog au atributele: descriere, rang/ordinea în listă, estimare și valoare.

Product backlog-ul este adesea ordonat după valoare, risc, prioritate și necesitate. Elementele cu cea mai mare prioritate vor fi dezvoltate imediat. Cu cât mai mare este prioritatea, cu atât mai mult elementul din product backlog a fost analizat, și există mai mult consens în privința sa și a valorii sale. Pe măsură ce un produs este folosit și câștigă în valoare, și piața furnizează feedback, product backlog-ul devine o listă mai mare și mai cuprinzătoare. Cerințele nu încetează niciodată să se schimbe, astfel încât product backlog-ul este un artefact viu. Schimbările în cerințe de business, în condițiile pieței, sau în domeniul tehnologiei pot cauza schimbări în product backlog.

Echipe scrum multiple lucrează deseori împreună la același produs. Un product backlog este folosit să descrie șantierul următor despre produs. Un atribut care să regrupeze elementele din product backlog poate fi adăugat. Rafinarea (Refinement) product backlog-ului este actul de adăugare a detaliilor, estimărilor, și ordonarea elementelor din product backlog. Acesta este un proces continuu prin care product owner-ul și echipa de dezvoltare colaborează pe detaliile elementelor din product backlog. Pe parcursul rafinării product backlog-ului, elementele sunt revizuite și corectate. Echipa scrum decide cum și când are loc revizuirea. De obicei rafinarea nu consumă mai mult de 10% din capacitatea echipei de dezvoltare. Totuși, elementele product backlog-ului pot fi aduse la zi în orice moment de către product owner sau de cineva la discreția product owner-ului. Îngrijirea product backlog-ului este o activitate cu jumătate de normă pe parcursul sprintului împărțită între product owner și echipa de dezvoltare. Destul de des, echipa de dezvoltare are suficient de multe cunoștințe ale domeniului de activitate încât pot realiza această activitate și singuri. Elementele ordonate mai sus (cu rangul mai mare) în product backlog sunt de obicei mai clare și mai detaliate decât cele ordonate mai jos. Estimările mai precise sunt bazate pe claritate mai bună și detalii bogate; Cu cât rangul este mai mic cu atât nivelul de detalii este mai mic. Elementele din product backlog de care se va ocupa echipa de dezvoltare în sprintul care urmează sunt rafinate astfel încât oricare element să poată fi „finalizat” în mod rezonabil și în durata fixă alocată sprintului. Elementele din product backlog pe care echipa de dezvoltare le poate realiza într-un sprint sunt considerate „Pregătite” (Ready) pentru selectare lor în Planificarea sprintului. Elementele product backlog-ului, dobândesc de obicei acest grad de transparență prin intermediul activităților de rafinare descrise mai sus. Echipa de dezvoltare este responsabilă pentru toate estimările. Product owner-ul poate influența echipa de dezvoltare ajutând-o să înțeleagă și să facă compromisuri, dar doar oamenii care vor realiza lucrul fac estimarea finală.

Monitorizarea progresului către un obiectiv

În orice moment, lucrul total rămas de realizat pentru a atinge obiectivul poate fi însumat. Product owner-ul trasează acest volum total de lucru cel puțin la fiecare Revizuire de sprint. Product owner-ul compară această valoare cu munca rămasă de la celelalte Revizuiri de sprint pentru a evalua progresul față de finalizarea estimată în funcție de data dorită pentru atingerea obiectivului. Diverse practici de proiecție/vizualizare a tendinței au fost folosite pentru a prognoza progresul, precum graficele de tip burn-down, burn-up, sau flux cumulativ (cumulative flow). Acestea s-au dovedit utile. Totuși, acestea nu înlocuiesc importanța empirismului. În mediile complexe, ceea ce se va întâmpla ne este necunoscut. Doar ceea ce s-a întâmplat poate fi folosit în luarea deciziilor viitoare. Sprint backlog (backlog-ul de sprint) sprint backlog-ul este setul de elemente din product backlog pe care le-am selectat pentru sprint plus planul cu livrarea Incrementului produsului și cu realizarea Obiectivului sprintului. sprint backlog-ul este prognoza echipei de dezvoltare cu privire la funcționalitatea cuprinsă în Incrementul următor precum și prognoza muncii necesare livrării acesteia într-un Increment „finalizat”.

Sprint backlog-ul face vizibilă toată munca pe care echipa de dezvoltare o identifică ca necesară pentru a atinge Obiectivul sprintului. Sprint backlog-ul este un plan cu destule detalii astfel încât modificările care survin pe parcurs să fie înțelese în scrum-ul zilnic. Echipa de dezvoltare modifică sprint backlog-ul de-a lungul sprintului, și sprint backlog-ul emerge pe parcursul sprintului. Această emergență are loc pe măsură ce echipa de dezvoltare lucrează respectând planul și învață mai multe despre munca necesară atingerii obiectivului de sprint. Echipa de dezvoltare adaugă noul lucru identificat în sprint backlog. Pe măsură ce lucrul este realizat sau completat, timpul estimat rămas de lucru este adus la zi. Când elemente ale planului sunt apreciate ca fiind inutile, ele sunt scoase. Doar echipa de dezvoltare poate schimba sprint backlog-ul. Sprint backlog-ul este foarte vizibil, reprezintă o imagine în timp real asupra lucrului pe care echipa de dezvoltare intenționează să-l realizeze pe parcursul sprint-ului și aparține exclusiv echipei de dezvoltare.

Monitorizarea Progresului într-un sprint

La orice moment din sprint, lucrul total rămas de realizat în sprint backlog poate fi însumat. Echipa de dezvoltare urmărește lucrul rămas de realizat cel puțin o dată la fiecare scrum zilnic pentru a estima probabilitatea atingerii Obiectivului de sprint. Urmărind lucrul rămas de realizat de-a lungul sprintului, echipa de dezvoltare poate gestiona procesul său.

Incrementul (Increment)

Incrementul este suma tuturor elementelor din product backlog completate de-a lungul unui sprint și valoarea Incrementelor din sprinturile anterioare. La finalul unui sprint, noul Increment trebuie să fie „Finalizat” (Done), ceea ce înseamnă că trebuie să fie în condiții utilizabile și să îndeplinească definiția de „Finalizat” stabilită de echipa de dezvoltare. Trebuie să fie în condiții utilizabile indiferent dacă product owner-ul cere să livreze sau nu.

Transparența Artefactelor

Scrum-ul se bazează pe transparență. Deciziile de optimizare a valorii și controlul riscurilor sunt luate pe baza stării percepute a artefactelor. În măsura în care transparența este completă, aceste decizii au o bază solidă. În măsura în care transparența este incompletă, aceste decizii pot fi eronate, valoarea poate scădea și riscurile pot crește. Scrum master-ul trebuie să lucreze cu product owner-ul, echipa de dezvoltare, și alte părți implicate să înțeleagă dacă artefactele sunt complet transparente. Există practici de copiere cu transparență incompletă; scrum master-ul trebuie să ajute pe toată lumea în aplicarea practicilor cele mai adecvate în absența transparenței complete. Un scrum master poate detecta transparența incompletă inspectând artefactele, detectând șabloane, ascultând atent la ceea ce se spune și detectând diferențele dintre ceea ce este așteptat și rezultatele reale. Este de datoria scrum master-ului să lucreze cu echipa scrum și organizația pentru a crește transparența artefactelor. Această muncă implică de obicei învățarea, convingerea și schimbarea. Transparența nu are loc peste noapte, dar este o cale.

Definiția lui „Finalizat” (Definition of ”Done”)

Când un element al product backlog-ului este descris ca fiind „Finalizat” (Done), toată lumea trebuie să înțeleagă ce înseamnă „Finalizat”. Deși diferă semnificativ de la o echipa scrum la alta, membrii echipei trebuie să aibă o înțelegere comună legată de semnificația finalizării lucrului, pentru a asigura transparența. Aceasta este definiția lui „Finalizat” pentru o echipa scrum și este folosită pentru a evalua dacă lucrul este terminat pentru Incrementul produsului. Aceeași definiție ghidează echipa de dezvoltare în a ști câte elemente să selecteze din product backlog pe parcursul Planificării sprintului. Scopul fiecărui sprint este să livreze Incrementul funcționalității potențial livrabile care aderă la definiția curentă a lui „finalizat” echipele de dezvoltare livrează Incrementul funcționalității produsului în fiecare sprint. Acest Increment, este utilizabil, deci product owner-ul poate decide să îl livreze imediat. Dacă definiția lui „Finalizat” pentru un Increment este parte a convențiilor, standardelor sau indicațiilor de dezvoltare ale organizației, toate echipele scrum trebuie să le urmeze cu strictețe. Dacă „Finalizat” pentru un Increment nu este o convenție în cadrul organizației, echipa de dezvoltare din echipa scrum trebuie să-și creeze definiția lui „Finalizat” care să se plieze pe produsul în cauză. Dacă există mai multe echipe scrum care lucrează pe același sistem sau versiune de produs, echipele de dezvoltare din toate echipele scrum trebuie să agreeze mutual definiția lui „Finalizat”. Fiecare Increment se adaugă la toate Incrementele anterioare și este testat amănunțit, verificând că toate Incrementele din care este compus funcționează împreună.

Pe măsura ce echipele scrum se maturizează, este de așteptat ca definiția lui „Finalizat” să se extindă cu scopul includerii altor criterii stringente pentru o calitate superioară. Oricare produs sau sistem individual trebuie să aibă o definiție a lui „Finalizat” care să fie standardul pentru orice lucru realizat pe el.

Rolurile, artefactele, evenimentele, și regulile scrum sunt imuabile și deși implementarea doar a unor părți din scrum este posibilă, rezultatul nu este scrum. Scrum există numai în întregul său și funcționează bine ca un container pentru alte tehnici, metodologii și practici.

CAPITOLUL III PREZENTAREA GENERALĂ A

S.C. TRADEADS INTERACTIVE S.R.L.

3.1. Scurt istoric

TradeAds Interactive a apărut ca urmare a experienței avute cu Tradeville cel mai mare broker pe piața Bursei.

TradeAds Interactive este o companie de dezvoltare software, înființată în anul 2000, cu sediul în București. De la începutul activității, s-a focusat pe dezvoltarea unor aplicații web eficiente și inovatoare, care contribuie atât la dezvoltarea business-ului partenerilor lor, cât și la dezvoltarea industriei de publicitate online din România, per ansamblu.

În mai 2009, după câteva luni de muncă, primul produs marca TradeAds, Bursa de Reclamă, avea să fie în producție.

În contextul pieței de publicitate din 2009, când adserverele vindeau bannere la CPM (cost per mille) și la CPC (cost per click) având prețuri fixe și rigide, TradeAds Interactive a adus un concept îmbunătățit de adserver. Realizat pe tehnologia nouă Microsoft, Bursa de Reclamă a introdus principiul real time bidding în sistemul de implementare a campaniilor online.

Procesul de real time bidding se bazează pe concurența dintre prețuri cu câștigarea celui mai bun. În locul rezervării unui spațiu de reclamă, Advertiserii licitează pentru fiecare impresie livrată, astfel încât cel mai ofertant dintre Advertiseri să câștige licitația.

Procesul este asemănător bursei de valori: când acțiunile (în acest caz, zonele de reclamă) sunt de vânzare, brokerii (Advertiserii) licitează pentru acestea. Cine licitează mai mult primește și respectivul stoc (reclama livrată). Procesul funcționează la fel de fiecare dată așa cum se întâmplă și în cazul Bursei.

Orice adserver cunoaște doi actori principali: Advertiserul și Publisherul. Primii Publisheri cu care încă mai lucrează Bursa de Reclamă sunt cei din grupurile Active Soft și Machteam Soft. Pentru Advertiseri Bursa de Reclamă aduce destul de precoce conceptul de bid, în condițiile în care el era obișnuit să plătească pentru publicitatea online cu prețul pe CPM sau CPC, preluate dintr-un rate card.

Prin Bursa de Reclamă, TradeAds a introdus competiția pentru spațiile de reclamă ale Publisherilor. Timp de câteva luni de la lansare, am avut ca obiectiv educarea Advertiserilor cărora li se asigura, prin procesul de real time bidding, un preț mai bun pe publicitatea online.

Fructificăm în continuare o relație de fidelitate cu Advertiserii și Publisherii care s-au înscris în Bursa de Reclamă. Aceștia au contribuit prin observațiile și solicitările lor la îmbunătățirea mecanismului prin care funcționează astăzi adserverul, dovadă creșterea de la an la an a volumului de requesturi de la 10 milioane pe zi la 30 de milioane în prezent.

Un alt element de noutate îl reprezintă introducerea, prin Bursa de Reclamă, a monedei virtuale-euroNetul, care face referire și în prezent la campaniile de tipul Banner Exchange. Inițial campaniile derulate pe euroNet erau dedicate doar Publisherilor care erau de acord să participe cu cel puțin o zonă în sistemul Bursa de Reclamă, iar bannerele acceptate erau doar cele care făceau reclamă site-ului și erau servite exclusiv în sistem CPM. În prezent, euroNetul este o monedă tranzacționabilă (există o casă de schimb euro-euroNet) prin care se pot plăti atât campanii CPM cât și CPC, de către oricine.

Bursa de Reclamă livrează bannere: imagine, flash, flash expand, bannere text, fixed floating, companion, sticky, full page și banner în player video.

Modul de contorizare: CPM, CPC, CPL (CPA) și sponsorship (în permanență). Bursa de Reclamă, prin Departamentul de Design, poate realiza și creațiile, bannere flash și imagine pe baza specificațiilor acestora.

În august 2010, TradeAds și-a extins aria de expertiză prin înființarea departamentului de Cercetare. Echipa de statisticieni a companiei TradeAds Interactive pun în serviciul clienților calificarea înaltă și expertiza în domeniile Statisticii, Econometriei, Data Miningului și Inteligenței Artificiale.

În prezent acest departament coordonează proiecte interne, constituind un suport în furnizarea de informații în ceea ce privește comportamentul utilizatorului de Internet, dar și proiecte de cercetare pentru clienți externi.

Din 2011, TradeAds este Partener Certificat Google AdWords, iar o parte din angajații lor dețin Google Certified Individual. Astfel că operează cu campanii Google pentru o gamă variată de clienți.

Următoarea etapă în extinderea business-ului a presupus obținerea statutului de partener Certificat Microsoft, ceea ce a oferit în anul 2012 cadrul adecvat pentru a promova tehnologiile Microsoft, în România, în special produsul Microsoft Dynamics CRM.

Astfel consolidarea unei echipe de specialiști profesioniști, pasionați de soluțiile oferite de Microsoft, le-a permis să obținem statutul de partener Microsoft Silver CRM și partener Microsoft Silver, pentru dezvoltarea aplicațiilor.

TradeAdds Interactive pe piața reclamei:

800 de site-uri primesc bannere livrate de Bursa de Reclamă

30% din traficul românesc atinge lunar aproape 90% din utilizatori

23.797.539 – numărul maxim de impresii livrate de Bursa de Reclamă într-o singură zi

51.581 – numărul maxim de clickuri atins într-o singură zi

30 de milioane de requesturi sunt prelucrate zilnic de Bursa de Reclamă

3.2. Obiect de activitate

Conform codului CAEN 7490 firma are ca și obiect de activitate, activități profesionale, științifice si tehnice n.c.a. Aceasta clasa include o mare varietate de activități de servicii furnizate in general clienților comerciali.

Sunt incluse acele activități pentru care sunt necesare abilități mai avansate de competenta profesionala, științifica si tehnica si nu include activități de rutina, care sunt in general de scurta durata.

Aceasta clasa include:

activități de brokeraj pentru întreprinderi, adică aranjamente pentru cumpărarea si vânzarea de întreprinderi mici si mijlocii, inclusiv a experienței profesionale, dar neincluzând activitățile de brokeraj pentru bunuri imobiliare

activități de brokeraj pentru brevete (aranjamente pentru cumpărarea si vânzarea de brevete) -activități de evaluare, altele decât pentru bunuri imobiliare si asigurări (pentru antichități, bijuterii etc.)

auditarea facturilor si a rapoartelor privind mărfurile

activități de prognoza a vremii -consultanta in domeniul securitatii

consultanta in agronomie -consultanta in probleme de mediu

alte activitati de consultanta tehnica

activitati ale consultantilor, in alte domenii decat arhitectura, inginerie si management

activitati de citire a contoarelor (gaze, apa, electricitate)

Aceasta clasa include de asemenea: -activitati desfasurate de agenti si agentii, in numele unor indivizi, implicand de obicei obtinerea de angajamente in filme, productii teatrale sau alte spectacole de divertisment sau atractii sportive si plasarea de carti, piese de teatru, lucrari de arta, fotografii etc. la edituri, producatori etc.

Compania prin departamentul de cercetare în care sunt organizate 6 grupuri de lucru (adForecast, adLearning, adLanguage, adOptim, adCription și adStat) abordează teme de cercetare și aplicații în advertisingul online. La aceste activități participă echipa de cercetare și o parte din personalul departamentului de programare. Domeniile de interes includ Statistica și Econometria, Inteligența Artificială, Algoritmi și criptografie, Calcul numeric și teoria optimizării.

Modelare econometrică și previziune (adForecast)

Grupul de modelare econometrică și previziune adForecast explorează metodele econometrice de previziune și arii de aplicabilitate în publicitatea online. Inteligența sistemelor naturale constă în abilitatea de a previziona evenimente și de a evalua cantitativ și calitativ anumite procese. Întrebările fundamentale pe care le adresăm sunt: În ce măsură este previzibil comportamentul utilizatorului de Internet? Care sunt factorii care influențează decizia sa? Cum pot fi previzionate anumite fenomene care interacționează dinamic în timp?

Preocupările științifice ale grupului adForecast includ explorări ale modelelor de decizie discrete, econometria seriilor cronologice, econometrie semiparametrică și nonparametrică, econometria datelor de panel.

Sisteme inteligente de învățare automată și data mining (adLearning)

Tehnicile de Inteligență Artificială și Data Mining ocupă o poziție centrală în majoritatea aplicațiilor de optimizare pe care le dezvoltăm. Paradigmele pe care se bazează învățarea automată oferă azi oportunitatea dezvoltării unor modele de clasificare și previziune numerică mai eficiente, care aduc și avantajul relaxării unor restricții parametrice impuse de econometria clasică. Aceste modele neliniare și neparametrice sunt utilizate cu precădere în procesele de previziune specifice targetării demografice și comportamentale.

Începând cu anul 2007, membrii echipei au avut ca preocupări explorarea principiilor de calcul biologic (neuronal și imunologic) și aplicațiile lor în învățarea automată. Astfel, o parte din echipă este interesată de modelarea sistemelor imunologice artificiale pentru recunoașterea formelor și optimizare numerică. Recentele tehnici de clasificare supervizată bazate pe rețele baricentrice de citokine se dovedesc a fi clasificatori de top și reprezintă un avans în explorarea capacității de recunoaștere a sistemelor imunologice artificiale.

De asemenea, includerea conceptului de paralelism cuantic în modelarea rețelelor neuronale iterative, conduce la o putere superioară a previziunii seriilor temporale. În grupul adLearning sunt explorate de asemenea tehnicile de agregare (boosting, bagging, etc) prin care se folosesc mai mulți clasificatori pentru a obține previziuni cu o performanță îmbunătățită.

Data miningul, analiza și procesarea seturilor de date de volum foarte mare este o altă preocupare a cercetătorilor acestui grup. Metodele de filtrare, eșantionare și reducere a datelor sunt esențiale, dat fiind rolul lor în determinarea seturilor de date care vor fi folosite ulterior în procesele de previziune.

Lingvistica și inteligența limbajului (adLanguage)

Comunicarea este una din cele mai importante facilități pe care le oferă Internetul, ea fiind în primul rând expresia intenției. Înțelegerea intenției utilizatorului de Internet și detectarea sensului pe care îl are conținutul comunicării este de importanță majoră în publicitatea online. De acest grad de înțelegere depind multiple procese de optimizare a livrării ad-urilor. Grupul adLanguage pune în centrul atenției concepte de ultimă oră privind extragerea sensului unui text, sumarizarea automată a conținutului paginilor web, elaborarea metricilor semantice pentru determinarea gradului de apropiere dintre texte, traducere automată, precum și utilizarea metodelor statistice în prelucrarea automată a limbajului natural.

Integrarea acestor metode în aplicații soft aduce o nouă dimensiune livrării conținutului publicitar: bannerul va fi afișat utilizatorilor cu afinitatea cea mai mare pentru conținutul expus, respectiv bannerul va fi afișat în secțiunile site-urilor care au conținutul cel mai compatibil cu cel al bannerului.

Optimizare și calcul numeric (adOptim)

Grupul de lucru adOptim are ca obiectiv modelarea matematică a proceselor din publicitatea online și determinarea soluțiilor de optim sau de reducere a erorilor pentru diverse probleme. Aceste soluții de optim se determină prin tehnici complexe de căutare (prin direcții, pe regiuni, etc). Un exemplu de modelare o reprezintă retropropagarea erorii în rețele neuronale, unde problema de optim cere găsirea punctelor de minim ale funcției eroare într-un hiperplan n-dimensional.

De asemenea, preocupările grupului includ modelarea deciziei utilizând elemente de teoria grafurilor, problemele de optimizare liniară, analiza armonică.

Algoritmi și criptografie (adCription)

Criptografia modernă se bazează pe concepte matematice și programatice, având ca scop principal securitatea fluxului informațional. Utilitatea se regăsește în securizarea comerțului electronic, a informațiilor cu caracter personal și a canalelor de comunicare prin care acestea sunt transmise. Sunt urmărite direcțiile moderne ale criptografiei – criptosistemele axate pe curbe eliptice și criptografia cuantică.

Tehnologii și aplicații pentru analiza piețelor (adStat)

Grupul de analiză a piețelor, urmărește îndeaproape studiul unor populații statistice și dezvoltarea unor metode originale pentru explorările acestora. Publicitatea online se adresează unui material uman care este dificil de explorat și ale cărui nevoi și aspirații sunt într-o perpetuă dinamică. Cunoașterea interdisciplinară a acestui material uman este de o importanță vitală și aduce informații prețioase care sunt ulterior valorizate de celelalte grupuri de lucru ale departamentului de cercetare.

Pentru scopurile exploratorii, s-a dezvoltat soluția MiRaGe, analizor statistic care oferă facilități de ultimă oră privind procesarea și analiza datelor (tehnici complexe de eșantionare, testări de ipoteze statistice, ANOVA, analiza de corelație și regresie, modele predictive bazate pe rețele neuronale, analize factoriale, analize cluster, etc). Grupul oferă de asemenea, servicii de consultanță și analiză statistică clienților companiei TradeAds Interactive.

Primul lor produs, Bursa de Reclamă (www.bursadereclama.ro) a fost dezvoltat în mediul Microsoft ASP.NET, demonstrând o afinitate pentru suita de soluții de tehnologie proprii Microsoft.

3.3. Produsele și serviciile firmei

De-a lungul anilor de activitate compania a lansat numeroase produse și servicii de optimizare a campaniilor de publicitate online, dintre care cele mai semnificative sunt următoarele 5

Bursa de Reclamă

Bursa de Reclamă este o platformă online de intermediere între Publisheri (deținătorii de site-uri) și clienții de publicitate online (Advertiseri sau agenții). Concepută ca o bursă de publicitate, Bursa de Reclamă are rolul de a facilita fixarea prețului pe piața publicității online strict pe baza cererii și ofertei, prin intermediul unui sistem de licitație de tip Generalized Second Price.

Ca și publishers ai acces la cele mai importante agenții media din România și companii multinaționale. Algoritmii avansați îți asigură maximizarea veniturilor din publicitate online ținând cont de condițiile de pe piață. Dispui de statistici în timp real privind numărul de reclame afișate, numărul de clickuri și veniturile obținute. Nu se pierde timp cu negocieri, implementarea și monitorizarea campaniilor, semnarea contractelor și facturărilor.

Ca și advertisers prin Bursa de Reclamă puteți crea campanii de publicitate online pe cele mai mari site-uri din România. Ai acces la statistici în timp real despre performanța campaniilor și targetări complexe ale audienței. Algoritmii avansați folosiți de Bursa de Reclamă îți asigură cel mai bun preț pentru fiecare reclamă afișată. Îți stabilești singur bugetul campaniei de publicitate online și prețul maxim pe click sau mia de afișări pe care ești dispus să-l plătești.

Folosim algoritmi avansați pentru tranzacționarea fiecărui spațiu publicitar din rețea. Pentru fiecare banner afișat, luăm în calcul criterii precum specificul și calitatea campaniei de publicitate online, specificul și calitatea zonelor publicitare, astfel încât să asigurăm întâlnirea cererii cu oferta în cele mai bune condiții. Rezultatul: sistemul de tranzacționare de pe Bursa de Reclamă asigură maximizarea veniturilor pentru Publisheri și, în același timp, optimizarea costurilor de publicitate online pentru Advertiseri.

Prețurile pentru publicitatea online sunt stabilite prin licitații electronice, după principiile GSP (Generalised Second Price). Asta înseamnă că sistemul va afișa reclamele Advertiserilor care au ofertele cele mai mari la publicitatea online, însă la prețurile corecte, adică cele oferite de următorii clasați. Sistemul încurajează un comportament de fair-play din partea Advertiserilor, care vor fi stimulați să divulge prețul maxim pe care-s dispuși să-l ofere, însă vor plăti efectiv sume mai mici, în funcție de ofertele concurenților.

Bursa de Reclamă acceptă atât campanii de publicitate online cu plata la mia de afișări (CPM), cât și campanii cu plata la click (CPC). Acestea concureză între ele, pentru a asigura cea mai bună expunere Advertiserilor cu cele mai bune oferte, cât și venituri mari pentru Publisheri. Pentru a ajunge la cele mai bune rezultate, folosim criterii avansate de targetare: targetare geografică targetare demografică după vârstă și sex targetare contextualădupă specificul paginilor web.

Bursa de Reclamă acceptă cele mai populare formate de bannere, care respectă standardele de publicitate online ale IAB

Pătrățica

Pătrățica este un sistem simplu de monetizare și valorificare a spațiilor de reclamă de pe site-urile de conținut. Destinat în egală măsură Publisherilor și Advertiserilor, aceștia au posibilitatea de a gestiona eficiența campaniilor de publicitate online printr-un minim de efort. Ușor de recunoscut în site-uri, Pătrățica apare sub forma unui widget disponibil în diverse formate de reclamă.

Câștigi bani cu site-ul tău fără să implementezi și să programezi campanii de publicitate. Oferi vizitatorilor posibilitatea de a cumpăra anumite produse direct pe site-ul tău. Aprobi sau respingi reclamelele clienților printr-un simplu click.

Închiriezi spațiul de reclamă direct de pe site-ul dorit cunoscând costurile din start. Creezi bannerele pentru campanie pe loc, în formatele standard sau le încarci pe cele proprii. Introduci campanii de publicitate online cu bannere permanente cu plata pe ziua de afișare.

Pătrățica.ro se bazează pe un mecanism simplu de utilizare, plecând de la premisa că nu toți vizitatorii sunt familiarizați cu noțiuni precum CPM (cost per mille), CPC (cost per click) sau OTS (opportunities to see). Pașii de gestionare a unor campanii sunt la fel de simpli pentru orice tip de utilizator.

Publisherul își înscrie site-ul, blogul, forumul în sistemul Pătrățica și, după ce completează toate informațiile necesare activării contului, i se va genera un cod JavaScript pe care îl introduce în html-ul site-ului. În funcție de plasarea widgetului în site, un vizitator își poate manifesta interesul de a închiria acel spațiu de reclamă. Ulterior se va răspunde notificărilor privind aprobarea sau respingerea unei campanii de publicitate.

Advertiserul se numără printre vizitatorii site-ului care vor ca reclama lor să apară în zona comandată. Pentru crearea unei campanii se accesează contul din sistemul Pătrățica. Astfel Advertiserul va putea avea acces la statistici privind numărul de afișări și clickuri ale bannerelor din campanie. Cu doar câteva clikuri se fac setările campaniei dorite prin introducerea reclamei (imagine sau text), a linkului de reclamă, a duratei, a datelor de contact și efectuarea plății.

Prin intermediul Pătrățica.ro, Advertiserii știu exact cui i se adresează și cunosc impactul pe care îl vor avea asupra publicului vizat.

PRAgent

PRAgent este un serviciu de publicitate online sub forma de texte (articole, advertoriale, comunicate de presă), care sunt publicate pe site-urile de conținut din România. Obiectivul acestui serviciu este de a ne ajuta clienții să-și maximizeze rezultatele campaniilor și de a-i sfătui să se gândească întotdeauna din perspectiva publicului căruia i se adresează. Articolele, pe care PRAgent le furnizează, pun accent pe informații concrete și utile utilizatorilor de Internet.

Advertorialele furnizează informații mai detaliate decât cele dintr-un banner. Targetarea se face în funcție de caracteristicile produsului și relevanța audienței. Publicitatea editorială este o modalitate de expunere media la costuri competitive.

PRAgent este un serviciu adaptabil nevoilor pieței. Așa cum precizează și echipa TradeAds Research, crește nevoia de informare a utilizatorului de Internet, astfel că, în curând, și nevoile de informare vor fi total diferite. Echipa PRAgent vede în această dinamică o oportunitate pentru Publisheri și Advertiseri de a-și lărgi canalele prin care să-și fidelizeze vizitatorii, respectiv consumatorii.

Prin PRAgent, Advertiserii își pot promova serviciile și prin editoriale complete din punct de vedere informațional și în mod specific, adresându-se exact audienței vizate. Principalul avantaj pe care îl au Advertiserii este acela că, spre deosebire de reclamele clasice, care dispar la finalul campaniei, un articol informațional se va regăsi pe Internet un timp mai îndelungat, fiind în continuare accesibil celor care sunt interesați de tematica respectivă.

În contul de PRAgent, Advertiserul este cel care adaugă o campanie, iar Publisherul cel care o implementează. Trei pași sunt necesari introducerii unei noi campanii. După ce se introduc articolele spre publicare, echipa PRAgent analizează corectitudinea gramaticală a textelor, dar și tonul folosit. Advertiserul selectează apoi zonele unde dorește să fie publicate articolele în funcție de caracteristicile vizitatorului unui anumit site.

Publisherii, după ce primesc cererea din partea PRAgent, verifică încă o dată campania și decid dacă publică articolul. În ziua publicării se introduce articolul în baza de date pe care o folosiți de obicei pentru alimentarea site-ului de conținut. Fiecare Publisher care utilizează serviciile PRAgent dispune de un cod de contorizare care se va copia la sfârșitul articolului, neavând nicio influență asupra designului paginii, întrucât nu se va afișa în site. Linkul care trimite către articolul publicat se va insera în câmpul special din pagina „Detalii campanie”.

Cu PRAgent actorii implicați în crearea și distribuirea de publicitate online vor avea parte de un nou mijloc de promovare. Astfel mesajul Advertiserilor devine credibil prin oferirea de informații complete despre serviciile oferite, iar Publisherii vor fi conectați noilor medii de transmitere a publicității online mai puțin agresive și propice tematicii site-urilor.

Maximizare

Maximizare.ro este un agregat de adservere care ajută Publisherii să obțină cel mai bun preț pe zonele lor de reclamă online. Misiunea Maximizare.ro este de a oferi o platformă online Publisherilor Premium care vor să dețină controlul asupra vânzărilor de pe adservere, control asupra inventoriului de impresii, colecționarea datelor de la surse 3rd party, derularea automată a reclamelor,creșterea veniturilor prin real time bidding.

Maximizare.ro se adresează Publisherilor care își doresc un sistem propriu de optimizare a venitului. Scopul echipei Maximizare este ca Publisherii să-și sporească profitul obținut în urma spațiului de reclamă pus la dispoziția Advertiserilor. Mai mult decât atât, utilizatorii noștri au posibilitatea de a lucra cu o echipă de suport dedicată optimizării tehnologice, astfel încât să beneficieze de câștiguri constante.

Publisherii Premium sunt acei Publisheri care au mai mult de 1 milion de impresii pe lună. Avantajul acestora este că pot beneficia de instalarea aplicației Maximizare.ro pe serverul dedicat. Echipa noastră asigură procesul de instalare, trainingul și suportul tehnic pentru clienți.

Misiunea Maximizare.ro este de a le oferi Publisherilor o platformă online care să le acorde întregul control asupra campaniilor de publicitate online de pe adservere diferite.

Pentru Publisherii care au cont în Bursa de Reclamă, Maximizare.ro asigură un serviciu de inserare a zonelor și a site-urilor din Bursa de Reclamă în contul Maximizare.ro. Dacă ai conturi active pe alte adservere, Maximizare.ro reunește toate codurile generate de acestea și îți oferă posibilitatea de a le administra pe toate, prin intermediul unuia singur.

De exemplu, site-ul tău este înregistrat la Bursa de Reclamă și la Google AdWords. Pentru a obține cel mai bun eCPM pe una dintre aceste adservere, Maximizare.ro evaluează sursa cererii și o compară cu adserverele care sunt dispuse să plătească cel mai bun preț pe zona de reclamă.

Zonele din Maximizare.ro vor fi corelate pentru a obține un cod nou în locul celor din adserverele la care te-ai înscris. Cu acest ultim cod generat și datorită tehnologiei optimizate, Maximizare.ro livrează Publisherului cel mai bun preț pe banner. Publisherul poate consulta apoi un raport al numărului de impresii din zonele sale.

În acest fel se obține un proces automat de încărcare a bannerelor fără a mai pierde timp cu actualizarea campaniilor de publicitate online.

Adnaliser

Adnaliser este un instrument prin care Publisherii și Advertiserii pot măsura eficiența bannerelor online prin determinarea numărului exact de impresii livrate de acestea. Conceput în jurul unui nou sistem metric de măsurare a impresiilor, denumit vCPM, obiectivul Adnaliser este de a evalua condițiile în care un banner este vizibil pentru utilizatori.

Ai acces la statistici care te ajută să-ți vinzi zonele de reclamă. Stabilești oferta de vânzare a zonelor pe baza unor rapoarte adecvate. Câștigi încrederea Advertiserului cu o poziționare profitabilă a reclamei.

Frecvența expunerii campaniei de publicitate online. Măsurarea vizibilității reclamei și impactul asupra utilizatorului. Date cu privire la numărul impresiilor pentru reclamele vizibile.

Adnaliser evaluează gradul de vizibilitate al reclamei pe site, în secțiunile sau pe alte pagini ale site-ului. Metodologia pe care se bazează Adnaliser constă într-un cod JavaScript care urmărește bannerele dispuse în site. Prin intermediul acestui cod se livrează numărul de impresii către Adnaliser care evaluează mai departe performanța campaniei. La finalul timpului de livrare, se generează un raport specific precizând dacă utilizatorul a văzut reclamă și durata. Clienții Adnaliser vor putea consulta un raport cu informațiile referitoare la impactul campaniei. Informațiile colectate pentru fiecare zonă specifică poziția reclamei și perioada de timp cât utilizatorul a văzut bannerul. Astfel, se calculează poziția bannerului în site în funcție de timpul și suprafața vizibilă pentru vizitatorul site-ului.

Concentrându-ne asupra nevoilor Advertiserilor și Publisherilor, credem că Adnaliser va contribui la eficientizarea media buyingului și va stabili un echilibru al vânzărilor bazate pe cerere și ofertă.

Începe să folosești Adnaliser pentru optimizarea campaniei online și plătești pentru reclamele vizibile.

Servicii

Expertiza echipei de statisticieni acoperă domeniile statisticii, econometriei, data mining-ului și inteligenței artificiale. Serviciile performante în metode de explorare și previziune contribuie la elaborarea unei strategii de marketing eficiente. Serviciile pe care le punem la dispoziție și-au probat virtuțiile prin rezultatele pozitive pe care le-au înregistrat clienții noștri în activitatea lor.

1) Servicii cantitative în studiul de piață

Cercetarea de piață a devenit în ultimii ani un instrument indispensabil în înțelegerea consumatorilor, a nevoilor și factorilor care influențează deciziile acestora, a resurselor și tendințelor piețelor în general. Exploatând un panel impresionant de tehnici de modelare, studiile de piață reprezintă funcția care leagă specialistul de marketing de subiectul activității sale: clientul, consumatorul, publicul, cel spre care se îndreaptă activitatea instituției.

Online

a) Targetare eficientă

Orice consumator are un ansamblu de nevoi pe care și le ierarhizează în funcție de reprezentarea utilității lor. Obiectivul targetării eficiente constă în determinarea factorilor subiectivi și a criteriilor care îl determină pe consumator să cumpere un anumit produs. O importanță aparte în acest caz o are analiza curbelor de indiferență care definesc, din punctul de vedere al consumatorului, situațiile de consum, egale ca importanță.

Satisfacerea nevoilor consumatorului, prin aplicarea unei strategii de marketing diferențiat, conduce la o creștere semnificativă a vânzărilor și la fidelizarea clienților.

b) Testare de concept

Înainte de lansarea pe piață a unui serviciu, este extrem de utilă pretestarea acestuia. Astfel se estimează modul în care acesta va fi perceput și modul în care răspunde exigențelor celor spre care este îndreptat. În funcție de rezultatele studiului nostru, se pot aplica diverse metode de redresare, astfel încât experiența de utilizare a serviciului să fie optimă.

De asemenea, în cazul îmbunătățirii serviciului, analiza se realizează în funcție de tipul de populație căruia i se adresează.

c) Analiza percepției

Analizăm impactul deciziilor de marketing asupra imaginii unui brand folosind tehnici variate de data mining. Utilitatea acestor explorări se justifică atât în perioadele de testare/lansare a unor oferte, cât și în monitorizarea ulterioară a răspunsului la acestea.

Analiza oferă, de asemenea, informații importante privind ajustarea unor oferte, atunci când rata de răspuns la acestea scade și evidențează variația opiniilor consumatorilor în ceea ce privește poziția brandului.

d) Preferințele utilizatorilor de Internet

Anual organizăm studii prin care măsurăm evoluția comportamentului utilizatorilor de Internet. Cunoașterea cât mai profundă a profilului utilizatorului de Internet este, în viziunea echipei de cercetare, o etapă deosebit de importantă, întrucât aceasta conduce la îmbunătățirea serviciilor de publicitate corespunzătoare Publisherilor și Advertiserilor.

În acest context, cunoașterea și analiza prin metode statistice a unor detalii care privesc caracteristicile demografice, socio-economice, precum și preferințele și percepția utilizatorului de Internet asupra publicității online sunt esențiale.

Offline

a) Studii pentru managementul mărcii

Studiile de notorietate a mărcii măsoară gradul de popularitate al unui brand. Metricile asociate acestui tip de analiză sunt esențiale în marketing, deoarece reflectă impactul pe care anumite produse îl au asupra consumatorilor. De asemenea, rezultatele cercetărilor noastre oferă posibilitatea de a defini obiective care să conducă la o evoluție ascendentă a brandului pe piață. În cadrul analizelor noastre, operăm atât tehnici de recunoaștere asistată, cât și cele de tip „top of mind”.

Studiile de poziționare oferă o imagine fidelă a locului pe care marca îl ocupă în viziunea consumatorilor. Utilizăm tehnici de recunoaștere asistată și mind share pentru a evalua poziționarea mărcii în raport cu cele deja existente pe piață.

b) Studii de evaluare a comportamentului consumatorului

Explorăm opinia consumatorului și determinăm factorii care conduc la anumite decizii ale acestora. Toate aceste cercetări conduc la o mai bună cunoaștere a publicului-țintă și implicit la implementarea de strategii de marketing care să le satisfacă trebuințele și aspirațiile.

Satisfacția clientului este un factor vital pentru fidelizarea acestuia. De cele mai multe ori satisfacția este mijlocită de beneficiile pe care i le aduce produsul.

Analiza satisfacției contribuie la determinarea atributelor „must-be” ale produsului, astfel încât acesta să răspundă factorilor motivaționali ai consumatorului.

2) Servicii de consultanță

Departamentul de cercetare oferă consultanță în modelare econometrică și previziune, data mining, inteligență artificială și machine learning, teoria grafurilor și calcul numeric, prelucrarea limbajului natural și criptografie aplicată. Problemele abordate în cadrul departamentului sunt diverse și utilizează o varietate impresionantă de algoritmi și tehnici moderne. Proiectele realizate în cadrul departamentului dovedesc experiența în aceste domenii și aplicabilitatea cercetărilor noastre pe o varietate de subiecte specifice mediului online.

3.4. Structură organizatorică

CAPITOLUL IV Studiul de caz implementare agile management scrum la S.C. TradeAds Interactiv S.R.L.

Scopul aplicației

Dezvoltarea unui sistem de afiliere pentru Altex, magazin online ce comercializează produse electronice și electrocasnice.

Un sistem de afiliere/profit sharing este un sistem de promovare pentru magazinele online. Magazinele online pun la dispoziția site-urilor care se înscriu în sistem un set de instrumente de promovare a produselor, pe care proprietarii site-urilor le plasează în paginile web.

Utilizatorii dau click pe instrumentele de promovare plasate pe site, iar în browser-ul utilizatorului se setează un cookie pentru marcarea acestei acțiuni. Dacă acești utilizatori fac cumpărături online pe site-ul magazinului in decurs de 30 de zile (sau o altă perioadă pe care magazinul online o stabiliește), proprietarul site-ului de unde s-a dat click ultima dată pe unul din instrumentele de promovare va primi un anumit procent din valoarea fără taxe a produsului achiziționat de utilizator.

Actori implicați

Rețeaua de afiliere – este magazinul online care iși promovează produsele prin intermediul unor instrumente de promovare.

Afiliat – proprietarul de site-uri web care decide să își plaseze instrumentele de promovare ale magazinului online în paginile site-urilor deținute.

Utilizatorii de internet – sunt cei care navighează pe site-urile web, dau click pe instrumentele de promovare și apoi ajung să achiziționeze produse online de pe site-ul magazinului online.

Ce se dorește

Sistemul de afiliere pentru ALTEX trebuie să îndeplinească următoarele cerințe:

Să fie o aplicație independentă care să se instaleze separat pe un server de web care aparține clientului.

Infrastructura să nu fie complexă și licențele/sumele alocate pentru acest sistem să fie la o valoare acceptabilă.

Sistemul să poată interacționa cu unul sau mai multe AdServere externe. AdServer-ul cu care va interacționa la un moment dat sistemul de afiliere va fi responsabil cu definierea campaniilor de promovare, cu contorizarea afișărilor, a click-urilor și a lead-urilor (conversiilor) realizate de instrumentele de promovare.

AdServer-ul oferă instrumente de targetare avansată și de optimizare a livrării campaniilor de promovare.

Sistemul de afiliere trebuie să aibă două componente:

Site-ul pentru afiliați – este aplicația pe care deținătorii de site-uri web se înscriu în sistemul de afiliere

Site-ul pentru administrarea business-ului de afiliere – prin care ALTEX va putea administra afiliații, comenzile făcute prin sistemul de afiliere, cererile de plată făcute de către afiliați.

Infrastructura necesară și tehnologii folosite

Sistemul se va dezvolta folosind tehnologii Microsoft:

Aplicațiile web vor fi dezvoltate folosind ASP.NET MVC3

Server-ul de baze de date – SQL Server 2008 R2 Express (licență free).

IIS 7.0 Web server

Este necesară o mașină (Server-ul de aplicații) pe care se vor instala aplicațiile. Serverul va avea ca sistem de operare Windows Server 2008 Web Edition. Configurația serverului se va stabili utlerior. Licența pentru sistemul de operare depinde de modalitatea de achiziționare (impreună cu server-ul sau separat).

Este necesară achiziționarea unui certificat SSL pentru aplicațiile de afiliere.

Principalele componente ale sistemului

Sistemul de afiliere are ca și componente principale:

Aplicația de afiliere – site-ul pe care se înscriu deținătorii de site-uri web

Aplicația de administrare business – BackEnd

API sistem de afiliere – o aplicație prin care sistemul de afiliere va interacționa cu sistemele externe (aplicațiile Altex si AdServer-ul extern)

Sistem de livrare campanii de promovare – scripturi client (Javascript) pentru instrumentele de promovare care vor apare pe site-urile afiliaților; template-uri de fișiere Flash pentru prezentarea produselor sau alte modalități de expunere a produselor.

Extinderi ale sistemului Altex actual:

Pagina de finalizare a unei comenzi va trebui să conțină scriptul de contorizare lead, oferit de AdServer-ul extern folosit, și un apel către sistemul de afiliere pentru înregistrarea comenzii.

În aplicația de administrare a comenzilor va trebui implementat un apel către sistemul de afiliere pentru confirmarea/anularea unei comenzi.

AdServer-ul extern – este cel reponsabil cu definirea campaniilor de promovare, contorizarea afișărilor, click-urilor și a lead-urilor. Acesta trebuie sa aibă un API pentru realizarea principalelor funcționalități necesare sistemului de afiliere.

Schema bloc a sistemului de afiliere

Funcționalități pe componente ale sistemului de afiliere

Sistemul de afiliere

Site-ul de afiliere

Site prezentare

Home page – pagina de start a site-ului

Termeni și condiții

Help

FAQ

Contact și suport

Logare utilizatori

Creare cont și reamintire parolă

Site afiliați logați

Dashboard – prima pagină de după logarea utilizatorului afiliat – prezintă informații pertinente contului de afiliat

Detalii cont afiliat și administrarea datelor de contact și de plată precum și resetarea parolei

Administrare site-uri afiliat:

înscriere site în programul de afiliere

editarea unui site

scoaterea unui site din programul de afiliere

Administrare instrumente de promovare:

definire diferite modele de instrumente de promovare

editarea unui instrument de promovare

ștergerea/inactivarea unui instrument de promovare

previzualizarea unui instrument de promovare

Rapoarte – principalele rapoarte care se vor defini în aplicație :

grafic de performanță (afișări/click-uri/lead-uri)

raport de performanță instrumente de promovare

raport comisioane pe categorii de produse

Plăți și încasări

Cereri de plată în așteptare

Plăți finalizate

Inițiere cerere de plata

Site-ul de administrare business

Logare :

Logare

Delogare

Reamintire parolă

Schimbare parolă

Setări rețea afiliere

Administrare categorii de produse

Adăugare/editare categorie de produse

Import categorii de produse

Setare comision pe categorie de produse

Setare prag minim pentru inițializarea unei cereri de plată

Administrare afiliați

Vizualizare afiliați

Activare/inactivare afiliat

Vizualizare site-uri înscrise de către un afiliat

Instrumente de promovare folosite de un afiliat

Detalii identificare afiliat și detalii de plată; contract pentru persoane juridice

Comenzi înregistrate pentru un afiliat

Plați afiliat și cereri de plată

Cereri de plată

Administrare cereri de plată și confirmare/anulare plată

Vizualizare cereri de plată cu selecție pe afiliat/status

Comenzi

Vizualizare comenzi cu filtre după status/afiliat

Confirmare/anulare comandă (se va face pe flow-ul de bază direct din aplicatia Altex); acesta ar trebui să fie un alternate flow.

Administrare utilizatori

Vizualizare utilizatori BackEnd și activare/inactivare utilizator

Adăugare/editare utilizator BackEnd

Administrare campanii

Listă campanii active

Sincronizare campanii cu AdServer-ul extern

Rapoarte (se vor agreea forma si datele prezentate in fiecare raport)

Rapoarte de plăți pe perioade

Rapoarte de performanță instrumente de promovare

Rapoarte pe campanii de promovare

Rapoarte de performanță afiliați

API sistem de afiliere

Înregistrare comandă

Confirmare/anulare comandă

Creare fișier widget corespondent zonei din AdServer extern.

Mapare instrument promovare cu zona din AdServer extern.

Sistem „livrare” – scripturi instrumente de promovare

Scripturi client per instrument de promovare

Scripturi apel zonă AdServer extern

Scripturi management cookie sistem afiliere

Fișiere flash template care implementează prezentarea produselor dintr-o categorie

Fișiere flash template pentru bannere standard.

Aplicații Altex

Înregistrare comandă în aplicația Altex – marcarea acesteia ca fiind facută prin programul de afiliere

Apel API sistem afiliere pentru înregistrarea comenzii pe afiliat.

Pagină setare cookie pentru programul de afiliere pe site-ul Altex – va fi apelată la efectuarea unui click pe unul din instrumentele de promovare.

Confirmare/anulare comandă din aplicația de administrare comenzi ALTEX – se va face un apel către sistemul de afiliere pentru comenzile făcute prin sistemul de afiliere pentru a se schimba statusul comenzii .

Generarea fișierelor XML pentru categoriile de produse promovate și a fisierelor XML cu produsele per categorie.

AdServer- extern

Implementare/studiere implementare API

Funcționalități pe care trebuie sa le aibă AdServer-ul extern

Creare zonă

Returnare cod zonă nouă

Update detalii zonă

Raport per retea de afiliere (Advertiser)

Dezvoltarea aplicației este împărțită în 6 sprinturi cu durata de 1 săptămână. Înainte de începerea fiecărui sprint echipa de dezvoltare împreună cu scrum master-ul și project owner-ul hotărăsc ce task-uri vor fi rezolvate în sprint-ul următor. La sfârșitul fiecărui sprint project owner-ul primește un fișier DOC ce conține lista task-urilor rezolvate in sprintul terminat urmând ca acesta să testeze task-urile și să trimită un feedback.

Fiind vorba de o aplicație cu interfață WEB verificarea și testarea task-urilor de către project owner este relativ simplă. Astfel, versiunea curentă a aplicației este făcută disponibilă pe un server de teste la care acesta are acces. Project owner-ul parcurge fișierul si indică pentru fiecare task dacă este rezolvat sau sunt necesare modificări sau reparații.

Prezint în continuare căteva exemple de task-uri din fișierul primit de client.

După ce termină de parcurs fișierul project owner-ul îl trimite echipei. Eventualele task-uri rămase deschise sunt introduse automat în sprint-ul următor iar acestora li se alătură task-urile alese de echipă pentru a fi rezolvate.

După parcurgerea a două sprint-uri project owner-ul dorește să introducă in backlog modificări suplimentare. După o conferință cu scrum master-ul echipei în legătură cu aceste modificări acesta din urmă se întâlnește cu echipa de dezvoltare pentru a analiza cerințele noi și efectele acestora asupra backlog-ului.

Estimarea cerințelor

În urma analizei project owner-ul primește un document cu estimările cerințelor. Astfel, rezultă următoarele informații.

Ticketing suport afiliati

Instrumente de promovare

Implementare actuala:

Tipuri de instrumentele de promovare:

Banner de produse vertical – widget de produse care afiseaza produse in „casute” de anumite dimensiuni si pentru categoriile selectate de catre afiliat.

Banner de produse orizontal– widget de produse care afiseaza produse in „casute” de anumite dimensiuni si pentru categoriile selectate de catre afiliat.

Bannere grafice „oferte speciale” – sunt bannere pe formate standard, cu fisier de tip FLASH sau Imagine, care se definesc pentru campaniile setate in Bursa de Reclama.

Link generat – instrumentul de promovare prin care se genereaza link-uri de conversie pentru URL-uri valide de pe site-ul altex.ro

Caracteristici tipuri instrumente:

Bannerele de produse afiseaza unul sau mai multe produse in functie de dimensiuni. Fiecare produs se afiseaza intr-o „casuta de produs” cu elementele componente standard:

Denumire produs ( click)

Imagine produs (click)

Mesaj promo (no click)

Buton detalii (click)

Zona afisare pret (no click)

Pret vechi (daca exista)

Pret nou

Mesaj „livrare gratuita”

Landing page-ul pentru bannerele de produse contine link-uri de forma „click url tradeads” + „url pagina produs”

Bannerele grafice oferte speciale –afiseaza fisierul in forma care a fost urcat in campania definita in Bursa de Reclama. Landing page-ul este de aceeasi forma ca si la Bannere de produse.

Link generat – sunt folosite ca si link-uri generate de forma <a href=…>NumeLink</a> sau ca si link de conversie care se poate folosi ca si url pentru articole de continut sau pentru reclame text ca si landing page. URL-urile sunt de aceeasi forma ca si la celelalte tipuri de bannere.

După primirea estimărilor project owner-ul decide ce modificări vor fi adăugate în backlog.

În urma modificărilor backlog-ului se reunește echipa pentru a decide ce va fi dezvoltat in sprint-ul următor.

Această metodologie de management a proiectului permite un grad ridicat de maleabilitate și de dinamism a aplicației dezvoltate, permițând corelarea aplicației cu eventualele evenimente din piață.

Diagrama Gantt a sprinturilor