Optimizarea managementului de proiect in industria Automotive (Project management optimization in the Automotive Industry) Notatii – Abrevieri OIP… [309075]
UNIVERSITATEA “TIBISCUS”
DIN TIMIȘOARA
FACULTATEA DE CALCULATOARE ȘI INFORMATICĂ APLICATĂ
LUCRARE DE LICENȚĂ
CONDUCĂTOR ȘTIINȚIFIC:
Lect. Dr. Olivia Vale
CANDIDAT: [anonimizat]
2017
Mandrut Andana Ramona
Optimizarea managementului de proiect in industria Automotive
(Project management optimization in the Automotive Industry)
Notatii – Abrevieri
OIP
SYT
SwT
PO
CR
PR
CCB Comitet de control al modificărilor
PL
CoC
DOR
DOD
SPO Scope project owner
SWPL
QE
SE inginer de sistem
SI
PI
WIP
CSR
QMS
QMP
SDLC
Introducerea
Actualitatea problematicii abordate în teza de față rezidă din faptul că metodele și tehnicile generate de modelul de dezvoltare în V [anonimizat]-se în mod continuu capacitatea scăzută a tuturor tipurilor de resurse utilizate în astfel de proiecte. Efectul asupra renumelui companiilor producătoare de noi tehnologii au determinat necesitatea cercetării de noi metode de dezvoltare a [anonimizat].
[anonimizat] „pietrelor de hotar” au dus într-o [anonimizat]. [anonimizat], autorul a [anonimizat]. [anonimizat].
Conceperea unui model de dezvoltare pentru managementul proiectelor de tip
automotive nu ar avea nici o valoare dacă acesta nu ar putea fi validat pe cele două axe, a timpului și cea financiară. În acest scop a fost prezentată în lucrare comparația între modelele consacrate de dezvoltare din domeniul automotive și noul model de dezvoltare conceput. [anonimizat].
[anonimizat]:
• Definirea complexă a [anonimizat];
• Analiza avantajelor și dezavantajelor utilizării ciclurilor de viață tradiționale și a metodologiilor AGILE în proiecte;
• Analiza impactului utilizării teoriei constrângerii dezvoltata de E.M. Goldratt aplicată în proiectele automotive;
• Analiza impactului utilizării teoriei hazardului (HAZOP) în proiectele automotive;
• Validarea modelului conceput Agile prin analiza comparativă a modelului tradițional cu noul model implementat în dezvoltarea proiectelor automotive.
[anonimizat]:
• Atingerea obiectivelor proiectelor presupune cunoașterea detaliată a fazelor, [anonimizat] a ordinii în care aceștia trebuie să se desfășoare, precum și a factorilor critici specifici tipului de proiect;
• Înțelegerea importanței factorilor critici stă la baza succesului proiectului, în domeniul
automotive acest lucru fiind posibil având în vedere faptul că literatura de specialitate
abordează profund aceste aspecte;
• Standardizarea proceselor utilizate în proiectele automotive, sub forma proceselor
Spice, ajută coordonatorii de proiect în organizarea și luarea deciziilor pentru
metodele de control și comandă a acestor tipuri de proiecte;
• Ciclurile de viață tradiționale, utilizate în managementul proiectelor software nu diferă
în esență, acestea deosebindu-se doar în detaliu;
• Cel mai des utilizat model în proiectele de tip automotive este modelul în „V”, acesta
fiind o abordare superioară a altui model tradițional, denumit „în cascadă”;
• Utilizarea metodelor de dezvoltare tradiționale în proiectele automotive este
determinată de motive istorice, mai concret, se pleacă de la faptul că producția în acest domeniu este dezvoltată conform modelului în „V”, proiectele preluând de la sine aceeași configurație de cicluri;
• Utilizarea metodelor de dezvoltare tradiționale în producție, metode care stau și la baza dezvoltării proiectelor software automotive au la bază modele, care nu permit modificarea semnificativă a cerințelor de-a lungul dezvoltării proiectelor;
• Inflexibilitatea modelelor tradiționale de dezvoltare în cadrul proiectelor de dezvoltare
software au condus la integrarea metodologiilor AGILE;
• Metodologiilor AGILE reușesc să elimine slăbiciuni ale metodelor tradiționale prin accentul pus pe comunicarea și armonizarea echipelor ori de câte ori apare o
perturbație în proiect, introducând-se astfel o reală flexibilitate în abordarea
schimbărilor;
• Modificarea sau schimbarea cerințelor, în orice fază a ciclului de dezvoltare a
proiectului reprezintă deja o certitudine în proiectele de dezvoltare software din
industria automotive;
• Metodele moderne ca de ex. „Teoria Constrângerilor” dezvoltată de E.M. Goldratt oferă explicații si soluții asupra neajunsurilor proceselor tradiționale în dezvoltarea software, oferind soluții care să facă față strategiilor de viteză însă, nu poate rezolva în totalitate integrarea schimbărilor survenite pe parcursul ciclului de viață al proiectului;
• Explicația asupra neajunsurilor proceselor tradiționale în dezvoltarea software poate fi nuanțată prin sinteza factorilor de risc și decizionali care duc la implementarea unei cerințe noi sau modificate cu scopul propunerii unei soluții astfel încât calendarul proiectului să nu fie influențat;
• Din cauza structurii proiectelor automotive în care se va folosi modelul Agile, acesta
nu va aduce economii de timp, ci posibilitatea de implementare a unei cantități mai mare de cerințe actualizate, fără ca proiectul inițial să fie întârziat;
• Din punct de vedere financiar utilizarea modelului Agile va aduce economii companiilor pe termen mediu, datorită facilitării respectării duratei de finalizare a proiectelor în cazul apariției cerințelor de actualizare.
Fiecare capitol descrie treptat aspectele ce tin de modelele de dezvolatre, capitolul final prezentând în sinteză concluziile lucrării, soluțiile și contribuțiile originale. În sinteză, lucrarea este organizată în felul următor:
Lucrarea de licenta este structurată în 4 capitole, în care autorul își propune să trateze in mod detaliat obiectivele intermediare, care împreuna, conduc la soluționarea obiectivului general al lucrarii.
Capitolul 1 cuprinde 4 părți si sistematizează managementul de proiect,
particularizând aspecte specifice managementului proiectelor automotive de radio-navigație.
Din analiza critică asupra managementului de proiect în general și a managementului de proiect a sistemelor de radio-navigație în particular, au rezultat următoarele aspecte importante care stau la baza desăvârșirii lucrarii actuale de licenta:
• atingerea obiectivelor proiectelor presupune cunoașterea detaliată a fazelor, pașilor
proiectelor, și a ordinii în care aceștia trebuie să se desfășoare, precum și a factorilor
critici specifici tipului de proiect, sinteză realizată în prima parte a capitolului;
• prin cercetarea literaturii de specialitate care abordează profund aspectele
managementului de proiect a rezultat importanța factorilor critici stau la baza
succesului proiectului. În domeniul automotive acest lucru este posibil, având în
vedere faptul că literatura de specialitate abordează profund aceste aspecte;
• standardizarea proceselor utilizate în proiectele automotive, sub forma proceselor
Spice, ajută coordonatorii de proiect în organizarea și luarea deciziilor pentru metodele
de control și comandă a acestor tipuri de proiecte- aspect prezentat in ultima parte a
capitolului;
Capitolul 2 prezintă caracteristicile generale ale ciclurilor de viață ale proiectelor de dezvoltare software. Capitolul debutează cu descrierea modelului tradițional de dezvoltare în „V”, specific proiectelor de dezvoltare software.
Modelul în „V” reprezintă o abordare superioară a altui model de dezvoltare tradițional numit „în cascadă”. Cicluri de viață tradiționale, utilizate în managementul proiectelor software nu diferă în esență, acestea deosebindu-se doar în detaliu.
Inflexibilitatea modelelor tradiționale de dezvoltare în cadrul proiectelor de dezvoltare software au condus la dezvoltarea metodologiilor AGILE.În cea dea doua parte a capitolului sunt analizate principalele metodologii AGILE, SCRUM si Lean Development . Analiza critică realizată asupra acestor modele de dezvoltare a scos în evidență faptul că metodologiile AGILE reușesc să elimine slăbiciuni ale metodelor tradiționale, prin accentul pus pe comunicarea și armonizarea echipelor ori de câte ori apare o perturbație în proiect, introducând-se astfel o reală flexibilitate în abordarea schimbărilor.
Capitolul se finalizează prin concretizarea obiectivului principal al acestuia, mai concret, acela de scoatere în evidentă în mod detaliat a aspectelor particulare ale modelelor de dezvoltare a proiectelor automotive cât și efectele asupra calendarului proiectului în cazul implementării modificării cerințelor în diferitele faze ale proiectului.
Capitolul 3 evidentiaza in mod direct pasii unui proiect in industria automotive prezentat sub forma de Gates atat din punct de vedere al management-ului cat si cel al calitatii.Acest capitol pune accent pe adaptarea modelului de dezvoltare Agile si cum este acest model in realitate implementat intr-o corporatie care trebuie sa faca fata mereu la cerinte ce se schimba pe decursul proiectului si termene instabile.
Capitolul 4 prezinta noi propuneri de abordare a proiectelor cat si un standard care trebuie impus atat din punct de vedere Agile cat si al calitatii pentru a elimina din problemele existente in modul de dezvoltare software existent. Stabilirea unei directii este necesara iar intarirea principalelor principii trebuie realizata treptat cu suportul management-ului pentru a ajunge la un stadiu de dezvoltare ideal. Sunt de asemenea enunțate direcțiile viitoare de cercetare ale temei, utilizând modelul de dezvoltare propus în această lucrare.
Concluziile menționează că nu exista un model perfect pentru a creste productivitatea si calitatea. Ideologia Agile este una dintre solutiile optime, care poate aduce schimbari majore in cadrul unei intreprinderi iar prin elaborarea de modele noi în managementul calității proiectului și aplicarea conceptelor noi în dezvoltarea de proiecte din cadrul unei companii din industria automotive se pot elimina treptat factorii critici.
Bibliografia citată în cadrul lucrării cuprinde ……. titluri.
Se consideră astfel că obiectivul principal al lucrariii, de a îmbunătăți calitatea proiectelor de dezvoltare de produs, și obiectivele secundare, de îmbunătățirea metodelor folosite in diferite faze ale proiectului, eficientizarea și îmbunătățirea analizei cerințelor de calitate, îmbunătățirea analizei riscurilor în faza de concept a produsului, respectiv îmbunătățirea acțiunilor corective în cazul reclamațiilor de calitate, au fost îndeplinite.
Managementul de proiecte in industria Automotive
Aspecte generale
Un proiect este definit ca fiind un efort temporar depus pentru a crea, cu resurse limitate, un produs unic sau un serviciu unic. Un proiect este compus dintr-un ansamblu de activități, care se derulează potrivit unui plan pentru a atinge un anumit set de obiective într-o perioadă de timp definită. Imediat ce proiectul s-a realizat, acesta își încheie existența. Proiectele au două caracteristici esențiale:
1. Orice proiect are o dată de început și o dată de sfârșit. Data de început a proiectului poate fi de multe ori mai putin clară, pe măsură ce o idee evoluează într-un proiect. Data de sfârșit este bine definită.
2. Orice proiect are ca rezultat un produs unic. Rezultatul poate fi tangibil ca de exemplu un produs software, un echipament hardware, sau poate fi intangibil ca de exemplu crearea unui nou departament în cadrul unei organizații.
Managementul proiectelor în industria automotive constă în aplicarea cunoștințelor, capabilităților, instrumentelor și tehnicilor specifice acestei ramuri, pentru activitățile unui proiect, care au obiective, scopuri și cerințe definite, referitoare la timp, costuri, calitate și parametri de performanță, activități considerate ca importante și adecvate pentru finanțare respectiv atingerea obiectivelor propuse. Timpul, costul, calitatea și performanțele sunt constrângeri pentru proiect.
Factorii de succes în managementul de proiect Succesul unui proiect depinde de mulți factori. Plecând de la definiția noțiunii de management de proiect putem identifica trei constrângeri care influențează succesul unui proiect: scop, cost și timp.
Constrângerea de timp se referă la timpul disponibil pentru realizarea proiectului. Costul se referă la bugetul disponibil. Scopul reprezintă ceea ce trebuie să se realizeze în cadrul proiectului pentru ca acesta sa poată fi considerat realizat (obiectivele).
Figura1.1 Variabilele ce influenteaza succesul unui proiect.
Aceste trei constrângeri sunt interdependente. De exemplu dacă scopul proiectului este extins (sunt definite noi obiective) aceasta va implica costuri mai mari și o durată mai mare de execuție. Dacă se dorește reducerea timpului de realizare a unui proiect atunci fie costurile trebuiesc crescute, fie obiectivele trebuiesc reduse. Obținerea unui echilibru între cei trei factori reprezintă cheia pentru realizarea unui proiect de succes. Disciplina managementului de proiect oferă instrumentele și tehnicile prin care echipa de proiect își poate organiza activitatea în așa fel încât cele trei constrângeri să fie îndeplinite.
Folosirea corectă a tehnicilor de management a proiectelor va asigura atingerea criteriilor esențiale de succes ale proiectului pentruca ca acesta să fie relevant, fezabil și sustenabil.
Relevanța: Un proiect trebuie să fie orientat către satisfacerea unor nevoi reale ale beneficiarilor. Cu alte cuvinte, rezultatul final al unui proiect trebuie să fie neapărat reprezentat de o schimbare pozitivă. Pentru atingerea acestui obiectiv, este necesar ca beneficiarii să fie implicați în procesul de planificare încă din fazele inițiale ale programării. Planificarea este efectuată printr-un proces de analiză a problemei și definire clară a obiectivelor în termenii beneficiilor aduse grupurilor țintă.
Fezabilitatea: Obiectivele trebuie să fie realiste. Pentru a se asigura acest lucru, contextul proiectului trebuie analizat îndeaproape, fiind luați în considerare factorii de natură economică, financiară și culturală. Presupunerile și riscurile relevante pentru implementarea proiectului trebuie definite. Un proiect poate fi derulat doar dacă mediul este considerat a fi adecvat. Presupunerile și riscurile trebuie supuse unei permanente monitorizări pe întreaga durată a ciclului proiectului. Dacă mediul în care este derulat proiectul se shimbă, acțiunile sale trebuie replanificate, reorientate și – în cel mai rău caz – proiectul trebuie oprit.
Sustenabilitatea: Proiectele trebuie să poată fi sustenabile. Cu alte cuvinte, impactul nu trebuie să se limiteze la momentul terminării proiectului. De exemplu, trebuie garantat faptul că persoanele instruite în cadrul unui proiect de training pot folosi abilitățile dobândite în practică, atingând astfel rezultate mai bune în muncă, sau că un manual de proceduri terminat în timpul proiectului poate fi folosit activ și după încheierea acestuia.
Definiția proiectului și fazele acestuia
Figura 1.2 Principale în cadrul managementului de proiect
Indiferent de dimensiunea unui proiect sau de complexitatea acestuia, îndeplinirea obiectivelor acestuia înseamnă atingerea standardelor de calitate propuse, în limitele de timp și de buget stabilite. În cadrul activității de management de proiect putem distinge 5 faze ilustrate în Figura 1.2.
Faza de inițializare: se inițiază o propunere de proiect ca rezultat a unor nevoi. Pe baza unei analize inițiale se decide acceptarea sau nu a proiectului.
Faza de planificare: obiectivele sunt definite și rafinate. Se decide planul de acțiune necesar pentru a realiza obiectivele propuse.
Faza de execuție: oamenii și resursele sunt coordonate în conformitate cu planul proiectului.
Faza de control: se monitorizează evoluția proiectului, sunt identificate eventualele deviații de la planul inițial, se decid acțiunile necesare pentru a menține proiectul în parametrii definiți inițial.
Calitatea
Calitatea reprezintă o latură esentială a produselor și serviciilor. Conform standardului ISO 8402 din 1995, calitatea este definită astfel: ”Calitatea reprezintă ansamblul caracteristicilor unei entități, care îi conferă acesteia aptitudinea de a satisface necesități exprimate și implicite”. In ultima ediție a acestui standard SR EN ISO 9000/2008 calitatea este definită și mai concis ”măsura în care un ansamblu de caracteristici intrinseci îndeplinește cerințele”(unde intrinsec, ca opus termenului atribuit semnifică prezența permanenta a unei caracteristici într-o entitate, iar cerința este o nevoie sau așteptare care este declarată , în general implicită sau obligatorie; ”in general implicit” inseamna că aceasta reprezintă o practică internă sau o obișnuința pentru organizație, iar “cerința declarată “ inseamnă prezența acesteia intr-un document).
Prin urmare calitatea unui produs sau serviciu nu este determinată numai de caracteristicile și proprietațile pe care le are ci și de măsura în care satisface necesitațile exprimate de către utilizator sau beneficiar, precum și alte necesitați care nu sunt stipulate dar trebuiesc îndeplinite.
Figura 1.3 Calitatea
Se constată astfel că definiția calității încorporează ambele laturi sau aspecte ale calității. Prin caracteristica de calitate se întelege orice funcție sau proprietate a unui produs sau serviciu care este indispensabilă pentru a satisface necesitațile clientului sau care îi conferă aptitudinea de a fi util.
Sistemul de management
Managementul calității aplicațiilor software câștigă tot mai mult în importanță în toate domeniile economiei, datorită următorilor factori (Kneuper, R., Sollmann,F., 1995):
pe de o parte, calitatea aplicațiilor software reprezintă un factor exponențial în domeniul concurenței, determinat de conștientizarea tot mai mare pe ramură calitativă a beneficiarilor;
pe de altă parte, corecția de erori software s-a dovedit a fi foarte costisitoare; aceste costuri pot fi însă evitate prin introducerea și folosirea din timp a unui sistem de management al calității.
În mod tradițional managementul calității (atât pentru software cât și pentru produse de orice natură) se bazează pe faptul că un produs finit trebuie verificat/testat sau examinat, astfel încât să îndeplinească toate necesitățile/cerințele, iar în cazul defectelor identificate să le înlăture (ISO 9000). Această abordare s-a dovedit însă a fi insuficientă datorită costurilor ridicate pentru testarea unui produs și pentru procedeul de eliminare a neconformităților apărute la produsul finit. Din aceste motive, se preconizează o calitate a aplicațiilor software în mod indirect, prin îmbunătățirea calității proceselor de obținere a aplicațiilor software. Ipoteza care stă la baza acestei abordări, este că printr-un proces cu un înalt nivel de calitate, se pot obține în mod predictibil produse foarte calitative.
Este real însă și faptul că și cu procese nestructurate se pot obține produse de înaltă calitate, dar rezultatele acestor procese variază foarte des între produse bune și produse slabe calitativ. Ca urmare a acestei abordări, se pot diferenția două categorii de norme:
norme de proces și norme de sistem ale managementului calității;
norme de produs.
Automotive Spice
Proiecte complexe de dezvoltare software sunt parte integrală din industria auto de astăzi. Aceste proiecte, însă, necesită un grad ridicat de planificare și în special de control al procesului. Ca standard specific industriei auto pentru evaluarea și îmbunătățirea a astfel de proiecte și procese s-a manifestat ISO-ul / IEC 15504-5 resp. Automotive SPICE (Software Process Improvement and Capability Determination). Tot mai mulți clienți au cerut în ultima vreme instruiri Automotive SPICE pentru angajații lor în domeniile managementului de calitate cât și ale managementului de proiect.Automotive Spice este un standard utilizat ca un cadru pentru evaluarea si imbunatatirea proceselor.Se focuseaza pe partea de software si sistem a produsului.
Figura 1.4 Best Practices Automotive Spice
Pe langa faptul ca este o unealta pentru determinarea statusului cat si a riscului unui proiect, Automotive SPICE poate de asemenea sa joace un rol important in a ajuta o organizatie spre a-si indeplini telurile, ajutand-o sa rezolve trei intrebari critice:
Figura 1.5 Scop Automotive Spice
In acest context Automotive SPICE poate doar sa faca parte dintr-o solutie integrata ce include metode de dezvoltare corespunzatoare si o cultura organizationala ce incurajeaza initiativa, comunicarea si decentralizarea deciziilor.
Figura 1.6 Cost defecte
Costul problemelor de calitate creste pe masura ce dezvoltarea produsului progreseaza astfel ca calitatea asigurata din timp reduce pierderile acumulate astfel incat Automotive Spice are un grad mare de importanta.
Factori critici
În octombrie 2013, un grup de 22 de producători de echipamente auto și furnizori de automobile s-au întâlnit pentru un grup de acțiune pentru industria automobilelor. Având în vedere reținerea comună în feedbackul acestor lideri – "Calitatea este cea mai bună pe care a existat-o vreodată, dar …" – în curând a fost evident că în timp ce starea actuală era bună, au existat domenii specifice în care s-au dorit și s-au obținut chiar și mai bune eficiențe . Rezultatele sondajelor relevă faptul că producătorii de echipamente originale și furnizorii clasifică Rezoluția problemelor și cerințele specifice clienților (CSR) ca fiind cele mai importante probleme care afectează calitatea. Sistemul de Management al Calității (QMS), Dezvoltarea Produsului și Pierderea experientei completează primele cinci aspecte, clasate de toți participantii.
Tehnologii specifice ciclului de viata in dezvoltarea software– SDLC
Modele de dezvoltare
Modelul cascadă (waterfall)
Modelul V
Modelul incremental
Modelul RAD (Rapid Application Development)
Modelul agil
Modelul iterativ
Modelul spirală
Aspecte generale
Procese sau metodologii diverse, selectate pentru dezvoltarea unui proiect în funcție de obiectivele acestuia;
Mediu care descrie activitățile realizate în cadrul fiecărei etape a procesului de dezvoltare software
Plan detaliat, care descrie modul în care se va realiza dezvoltarea, întreținerea și înlocuirea software-ului specific (proces de dezvoltare software)
Standardul internațional SDLC – ISO/IEC 12207
Figura 2.1 SDLC
Analiza și planificarea cerințelor
este etapa fundamentală, cea mai importantă din SDLC
este efectuată de către membrii seniori ai echipei pe baza intrărilor de la client, de la departamentul de vânzări, pe baza studiilor de piața și experților din domeniul proiectului
Implică planificarea cerințelor de asigurare a calității și identificare a riscurilor asociate proiectului
rezultatul studiului de fezabilitate tehnică constă în definirea diverselor abordări tehnice care pot fi urmate pentru a implementa proiectul cu riscuri minime
Definirea cerințelor
presupune definirea clară și documentarea cerințelor produsului
obținerea aprobării clientului sau a analiștilor de piață prin intermediul SRS (Software Requirement Specification)
SRS cuprinde toate cerințele produsului care vor fi proiectate și dezvoltate
Proiectarea arhitecturii produsului
SRS este referința de bază
este propusă o abordare de proiectare a arhitecturii produsului, documentată într-un DDS (Design Document Specification)
definește în mod clar toate modulele arhitecturale ale produsului
proiectarea internă a tuturor modulelor din arhitectura propusă trebuie să fie clar definită și detaliată în DDS
Implementarea și dezvoltarea
începe efectiv dezvoltarea și se realizează produsul
se generează codul sursă de programare
se folosesc instrumente de programare: compilatoare, interpretoare, depanatoare etc.
limbaje de programare de nivel înalt, cum ar fi C, C++, Pascal, Java, PHP
Testarea produsului
este, de obicei, un subset al tuturor etapelor din modelele SDLC moderne
se referă doar la etapa de testare în situația în care sunt raportate, urmărite, fixate și reanalizate defecte ale produsului până când produsul ajunge la standardele de calitate definite în SRS
Operare și întreținere
poate fi lansat într-un segment limitat și testat în mediul de afaceri real
pe baza feedback-ului, produsul poate fi lansat nemodificat sau cu îmbunătățirile sugerate
întreținerea acestuia se face pentru baza de clienți existentă
Modelul cascadă (waterfall)
Definit de W. W. Royce în 1970
Modelul ciclului de viață liniar-secvențial
Etapele nu se suprapun
La sfârșitul fiecărei etape are loc o revizuire
Avantaje
documentația și proiectarea structurii reprezintă un avantaj atunci când apar noi membri în echipă;
este un model ușor de utilizat și simplu;
este ușor de coordonat, datorită rigidității modelului – fiecare etapă are un rezultat așteptat și un proces de evaluare;
etapele sunt implementate individual, pe rând;
este recomandat pentru proiectele mici, în care cerințele sunt foarte bine înțelese.
Dezavantaje
cerințele pot fi adăugate și după finalul etapei de “culegere a cerințelor”, fapt ce influențează în mod negativ dezvoltarea produsului;
problemele din cadrul unei etape nu sunt niciodată rezolvate complet în cadrul aceleiași etape;
partiționarea în etape a proiectului nu este flexibilă;
adăugarea de cerințe noi de către client, conduce la costuri suplimentare, deoarece acestea nu pot fi implementate în aceeași ediție a produsului;
estimarea corectă a timpului și costului alocat pentru fiecare etapă sunt dificil de realizat;
nu sunt realizate prototipuri până la finalizarea ciclului de viață;
odată ce aplicația este în etapa de testare, este foarte dificil să se revină la etapa de concepție în cazul în care există probleme;
există un risc și o incertitudine mari;
nu este recomandat pentru proiectele complexe și orientate obiect;
este considerat un model slab pentru proiectele lungi și în curs de desfășurare;
nu este potrivit pentru proiectele în care cerințele prezintă un grad de schimbare de la moderat spre ridicat.
Figura 2.2 Modelul cascada
Modelul cascadă – se recomandă când:
cerințele sunt foarte bine cunoscute, clare și fixe;
definirea produsului este stabilă;
tehnologia este înțeleasă;
nu există cerințe ambigue;
resursele care necesită expertiză sunt disponibile gratis;
proiectul este scurt.
Modelul V (Verificare și Validare)
Este o extensie a modelului cascadă;
Este criticat de adepții Agile (“este prea simplu pentru a reflecta cu exactitate procesul de dezvoltare software și poate duce managerii într-un fals sentiment de securitate”);
Ciclul de viață este o cale secvențială de executare a proceselor;
Testarea produsului este planificată în paralel cu faza de dezvoltare corespunzătoare.
Avantaje
simplu și ușor de utilizat;
testarea activității (cum ar fi planificarea) – proiectarea testării se realizează înainte de codificare, salvând timp și crescând rata de succes față de modelul cascadă;
are loc o urmărire proactivă a defectelor – defectele sunt găsite în stadiu incipient;
evită fluxul descendent de defecte;
funcționează bine pentru proiecte mici, în cazul în care cerințele sunt ușor de înțeles;
este ușor de coordonat, datorită rigidității modelului – fiecare etapă are un rezultat așteptat și un proces de evaluare.
Figura 2.3 V-Cycle
Dezavantaje
este rigid și puțin flexibil;
software-ul este dezvoltat în etapa de implementare, prin urmare nu sunt realizate prototipuri ale software-ului;
dacă apar modificări pe parcurs, atunci documentele de testare, împreună cu documentele de cerințe trebuie să fie actualizate;
există risc ridicat și incertitudine;
nu este un model bun pentru proiecte complexe și orientate-obiect;
este un model slab pentru proiecte lungi și în curs de desfășurare;
nu este potrivit pentru proiecte în care cerințele prezintă risc de schimbare moderat până la ridicat;
odată ce aplicația este în faza de testare, întoarcerea și schimbarea funcționalității sunt dificile.
Modelul V – se recomandă în următoarele cazuri:
pentru proiecte de dimensiuni mici până la medii și în care cerințele sunt clar definite și fixe;
atunci când resursele tehnice ample sunt disponibile împreună cu expertiza tehnică necesară.
Metodologiile Agile
Agile Software Development este o familie de metodologii de project management în ingineria software, bazată pe dezvoltarea incrementală și care îmbrățișează și promovează schimbările ce evoluează de-a lungul întregului ciclu de viață al unui proiect. Aceste metodologii se caracterizează prin divizarea problemei în subprobleme mici și planificarea lor pe durate scurte. Se evită planificarea în detaliu pe termen lung, deoarece inerent în dezvoltarea de software apar întârzieri frecvente din cauza schimbărilor și detalierii cerințelor clientului. Scopul principal este ca, la terminarea fiecărui ciclu de dezvoltare (denumit iterație, și a cărui durată este de obicei ordinul câtorva săptămâni) să existe o versiune cât de cât funcțională (deși incompletă) a software-ului dezvoltat (cu număr minim de buguri).
Figura 2.4 Structura iteratie
O altă caracteristică importantă este comunicarea frecventă între membrii echipei, care, în multe cazuri, se întâlnesc într-o scurtă ședință zilnică, denumită stand-up sau scrum (pronunțat /scrʌm/) în care fiecare prezintă pe scurt progresul său în ultima zi de lucru și problemele cu care s-a confruntat. Acestora li se alătură și un reprezentant al clientului, care trebuie să fie informat de aspectele dezvoltării, pentru a ști ce modificări este realist să ceară și cât de mult ar putea costa ele. Astfel, toată lumea are cunoștințe despre fiecare aspect al dezvoltării aplicației și poate prelua munca altuia sau ajuta pe altcineva.
De-a lungul timpului au apărut diverse metode la baza cărora stau unele dintre aceste valori și principii. Ele au fost denumite metode agile, iar printre ele se numără:
Programarea extremă (XP)
Scrum
Proces unificat agil (AUP)
Modelare agilă
Proces unificat esențial (EssUP)
Proces unificat deschis (OpenUP)
Metoda de dezvoltare dinamică a sistemelor (DSDM)
Dezvoltare bazată pe caracteristici (FDD)
Crystal
Dezvoltarea Agile folosește feedback-ul pentru efectuarea într-o manieră colaborativă a unor ajustări periodice ale procesului de producție. Aceasta înseamnă să nu amânăm procesul de testare a aplicației pentru finalul proiectului, s-au să integrăm schimbările din codul aplicației doar la sfârșitul fiecărei luni, sau sa ne oprim din obținerea noilor cerințe imediat ce începem procesul de producție. Din contra, aceste activități se vor efectua pe tot ciclul de viața al proiectului. Cum un proiect software nu poate fi considerat ca și „finalizat”, atât timp cât mai sunt persoane care îl folosesc, se impune un feedback continuu de la utilizatori precum și o dezvoltare continua a produsului. Nu e nevoie sa aștepți șase luni ca sa-ți dai seama ca ceva merge prost, care e relativ simplu de reparat, îl repari imediat. Ideea de dezvoltare continuă este preponderenta in toate metodele agile. Aceasta se aplica la ciclul de producție în sine dar și asimilarea noilor tehnologii, obținerea cerințelor, deployment-ul aplicației precum și antrenamentul utilizatorilor. Principiul este valabil pentru toate fazele de dezvoltare ale unui proiect deoarece elaborarea unei aplicații software reprezintă o activitate foarte complexă. Orice detaliu substanțial amânat va fi implementat mai târziu prost, sau deloc , sau va evolua în ceva foarte dificil de controlat.
Exista mai multe metode de „dezvoltare agila” , toate acestea fiind expuse de o companie non-profit cunoscuta sub numele de „Agile Alliance”. Pentru orice proiect software exista o serie de factori de risc care pot periclita finalizarea cu succes a proiectului, cum ar fi: factori de experienta ( conducatorului de proiect, a echipei), factori de planificare, factori tehnologici, factori externi (modificarea cerintelor, modificarea interfetelor externe).
Cele mai multe metode de dezvoltare agila incearca sa minimizeze riscul dezvoltand software-ul in intervale scurte de timp, numite “timeboxes”, constand din 1-4 saptamani. Data de sfarsit a unui “timebox” nu poate fi modificata. Daca echipa depaseste data, iteratia este anulata si replanificata.
Fiecare iteratie este un proiect software in miniatura si include toate activitatile necesare livrarii mini-incrementului unei noi functionalitati: planificare, analiza cerintelor, proiectare, codificare, testare, documentare.
Fiecare noua iteratie trebuie sa livreze un nou produs. La sfarsitul fiecarei iteratii echipa re-evalueaza prioritatile proiectului.
Timebox-urile sunt utilizate in metodele de dezvoltare rapida ca o forma de management al riscului in dezvoltarea unui soft.
Metodele “agile” pun in evidenta comunicarea directa intre participantii la elaborarea unei iteratii, in locul documentelor scrise. Acestia lucreaza in aceeasi locatie, intre ei fiind cel putin programatorii si “clientii” lor (cei care definesc produsul). Echipa poate include testori, proiectanti de interactiune, echipe de documentare tehnica si manageri. Principala masura a progresului este considerata software-ul functional. Se produce foarte putina documentatie, motiv pentru care metodele sunt criticate.
Agile Manifesto
Dezvoltarea de software agilă este denumirea unui grup de metodologii de dezvoltare software ce sunt bazate pe principii comune. Astfel de metodologii propun un anumit stil al procesului de management al proiectelor ce pune accent pe inspecție frecventă si adaptare, muncă de echipă (ce trebuie incurajată de liderul acesteia), auto-organizare și responsabilitate, favorizând astfel dezvoltarea rapidă a unui produs software de mare calitate, precum și coordonarea procesului de dezvoltare cu cererile clientului și obiectivele companiei. Cele mai multe metode agile propun dezvoltarea iterată (o iterație produce unul sau mai multe pachete complete ce împlinesc o funcție precisă în cadrul proiectului, iar totalitatea iterațiilor oferă produsul final), muncă în echipă, colaborare și adaptabilitate pe întreg parcusul de evoluție al proiectului In februarie 2001, un grup de programatori care împărțeau aceleași probleme legate de procesul greoi de dezvoltare software s-a reunit în Utah, SUA pentru a discuta tehnicile noi numite procese ușoare.
În urma acestor discuții s-a adoptat termenul agile, ce desemna o noua abordare, presupunând revizuirea metodologiilor tradiționale de dezvoltare software prin prioritizarea activităților, concentrarea asupra oamenilor, mediului colaborativ, scopurilor concrete, precum și asupra elaborării unor aplicații care sunt cu adevărat utile. Toate aceste idei au fost încadrate în Agile Manifesto 1, care sta la baza noțiunii din industria software cunoscuta sub numele de Tehnici Agile de dezvoltare software.
Principiile Agile
Satisfacția clientului prin livrarea rapidă și continuă de soluții software utile.
Sunt lansate frecvent versiuni funcționale ale aplicației (săptămâni mai degrabă decât luni)
Unitatea de măsura a progresului este dată de către funcționalitatea aplicației.
Chiar si schimbările târzii ale cerințelor aplicației sunt binevenite.
Colaborarea strânsă dintre dezvoltatori si clienți, pe bază zilnică.
Convorbirile fața în față sunt cea mai buna modalitate de comunicare.
Proiectele sunt construite de către indivizi motivați, care merită încredere.
O atenție deosebită asupra arhitecturii aplicației și asupra perfecționării tehnicilor de programare.
Simplitatea
Echipe dinamice bine organizate.
Adaptarea periodica la circumstanțele noi.
Manifestul Agile cuprinde si urmatoarele valori si concepte:
Indivizii si interacțiunea mai important decât procesele și instrumentele
Software funcționabil mai important decât o documentație foarte amplă
Colaborarea cu clientul mai important decât negocierea contractului
Receptivitate la schimbare mai important decât urmărirea unui plan
Indiferent de poziția ocupata in cadrul unui proiect software, fiecare poate aplica aceste practici personal, sau împreună cu toata echipa începând sa producă aplicații stabile ușor de realizat într-un ritm dinamic. Ron Jeffrey’s : Nu iei nici un premiu dacă ești agile, adevăratul beneficiu este alegerea corecta a combinației de metodologii care te vor duce la succes. Trebuie sa ne concentram asupra rezultatelor, in loc sa urmam orbește metodologiile fie ele și agile.
SCRUM
Scrum este o metodă Agile de management a proiectelor IT. În plus SCRUM este un proces iterativ și incremental pentru dezvoltarea software acolo unde cerințele se schimbă rapid. La sfîrșitul fiecărei iterații, echipa de proiect produce un produs software cu un set partial de functionalități, dar care se poate livra la client.
Figura 2.5 Metodologia Scrum
Scrum este o abordare care stabilește principii simple de management de proiect. Se folosește de obicei cu practicile de Extreme Programming. Scrum este un proces care imbuntățeste comunicarea și cooperarea în echipă.
Această metodologie a fost prima dată descrisă în 1986 de Hirotaka Takeuchi și Ikujiro Nonaka, ca o metodă flexibilă și rapidă pentru dezvoltare de soft. Principiul acestei metodologii, este împărțirea proiectului în etape de lucru (sprint-uri), în urma carora se finalizează un set de functionalități care intră în exploatare. Această metodologie presupune ca oamenii implicați sa fie buni organizatori ai propriului timp.
Organizare:
Ședinte dedicate planificării sprinturilor (în functie de anvergura proiectului, un sprint poate varia între 5 si 30 de zile). Scopul acestor ședinte este prioritizarea taskurilor și stabilirea celor incluse în urmatorul sprint. Din momentul stabilirii, funcționalitățile se “ingheață”
Sedințe zilnice (cu o durată de max. 15 minute). Scopul acestor ședinte este identificarea taskurilor îndeplinite în ziua precedentă, a taskurilor planificate pentru ziua în curs și a problemelor aparute. Această ședință are un caracter mult mai informal
Roluri
Stakeholderi
Product Owner – reprezintă interesul stakeholderilor, asigură finantarea proiectului și dezvoltă lista de cerințe. Acesta se concentrează pe ROI și gestionează Product Backlog-ul.
Scrum Master – acest rol poate fi asociat managerului de proiect, care are drept scop împărțirea și prioritizarea sarcinilor.
Echipa – dezvoltă și implementează funcționalitățile.
Figura 2.6 Scrum Commitment
Porcii sunt acele persoane dedicate proiectului și implicate în mod direct în sarcinile sale. Porcii, conform cadrului Scrum sunt:
1. Maestrul Scrum – El este cel care acționează ca un intermediar între proprietar și echipă. Maestrul protejează echipa, are grijă ca toate sarcinile din perioada fulger să fie îndeplnite la timp și stabilește regurile proiectului.
2. Echipa – Aceasta este implicată în mod direct în procesul de analiză, design, implemnetare și testare și toate sarcinile trebuie duse la capat corect de către membrii săi.
3. Proprietarul – El este cel care stabilește cerințele proiectului și participă la întâlnirile organizate la finalul fiecăror perioade fulger. Din cauza faptului că implicarea proprietarului nu este constantă el poate face parte și din grupul găinilor.
Găinile sunt acele persoane care nu sunt implicate în mod direct în procesul Scrum, dar care au rol decizional. Aceste persoane sunt de fapt beneficiarii proiectului. Găinile sunt de fapt managerii companiei client, vendorii și compania client în sine. (fotografie si explicatie preluata de pe enterprise-concept.com)
Modelul Scrum sugerează că proiectele progresează printr-o serie de sprinturi. În conformitate cu o metodologia agilă, sprintarea este încadrată într-un timp (time-boxed) de nu mai mult de o lună, cel mai frecvent de două săptămâni.
Metodologia Scrum pledează pentru o întâlnire de planificare la începutul unui sprint, unde membrii echipei își dau seama la cât de multe elemente care pot angaja, și apoi creează un backlog – o listă a sarcinilor care urmează a fi efectuate în timpul sprintului.
În timpul unei sprint agil Scrum, echipa Scrum preia un mic set de caracteristici și îl trece de la idee la funcționalitate codificată și testată. La sfârșit, aceste caracteristici sunt efectuate, adică codate, testate și integrate în produsul sau sistemul deevoluție.
În fiecare zi de sprint, toți membrii echipei trebuie să participe la o întâlnire Scrum, inclusiv ScrumMaster-ul și proprietarul produsului . Această întâlnire este time-boxed la nu mai mult de 15 de minute. În acest timp , membrii echipei împărtășeasc ceea ce au lucrat în ziua anterioară, stabilesc ce se va lucra în acea zi, și identifică orice obstacole care stau în calea progresului.
Figura 2.7 Ceremonii Scrum
Modelul Scrum vede scrum-urile de zi cu zi ca o modalitate de a sincroniza munca membrilor echipei în timp ce discută despre activitatea de sprint.La sfârșitul unui sprint, echipa efectuează o revizuire a sprint-ului în care echipa arată noua funcționalitate la PO sau la orice stakeholder care dorește să ofere feedback-ul, care ar putea influența sprinturile următoare.Această buclă de feedback în dezvoltarea de software Scrum poate duce la modificări ale funcționalității proaspat livrate, dar poate duce la fel de probabil la revizuirea sau adăugarea de elemente la backlog-ul de produsului.O altă activitate în managementul de proiect Scrum este retrospectiva sprint de la sfârșitul fiecărui sprint. Întreaga echipă participă la această reuniune, inclusiv ScrumMaster și PO. Reuniunea este o oportunitate de a reflecta asupra sprint-ului care s-a încheiat, și de a identifica oportunități de îmbunătățire.
Figura 2.8 Rolurile principale
În procesul Scrum, un ScrumMaster diferă de un manager de proiect tradițional, în multe feluri, inclusiv prin faptul că acest rol nu oferă direcții de zi cu zi echipei și nu atribuie sarcini indivizilor.
Un ScrumMaster bun adapostește echipa de distracții exterioare, fapt care permite membrilor echipei să se concentreze maxim în timpul sprint-ului pe obiectivul care le-au ales .În timp ce ScrumMaster-ul se concentrează pe a ajuta echipa să fie în cea mai bună stare, proprietarul produsului conduce echipa la obiectivul corect. Proprietarul produsului face acest lucru prin crearea unei viziuni convingătoare a produsulu , iar apoi transmite această viziune a echipei prin backlog-ul produsului.
Proprietarul produsului este responsabil pentru prioritizarea backlog-ului în timpul dezvoltării Scrum, se asigură că tot ceea ce mai este învățat despre sistemul va ficonstruit , responsabil pentru utilizatorii săi, echipa și așa mai departe .
Al treilea și ultimul rol în managementul de proiect Scrum este echipa Scrum în sine. Deși indivizii se pot alătura echipei cu diverse titluri de muncă , în Scrum, aceste titluri sunt nesemnificative. Metodologia Scrum prevede că fiecare persoană contribuie în orice fel posibil pentru a finaliza lucrările de fiecare sprint.
Aceasta nu înseamnă că un tester va fi de pus să re – proiecteze sistemul; persoanele vor petrece cea mai mare ( și , uneori, tot ) din timpul lor de lucru în orice disciplină în care au lucrat înainte de a adopta modelul agile Scrum. Dar cu Scrum, individualitățile sunt de așteptat să lucreze dincolo de disciplinele lor preferate ori de câte ori acest lucru ar fi pentru binele echipei .
Un mod de a privi aceste trei roluri în metodologia agilă este o mașină de curse.
Echipa Scrum este mașina în sine, gata pentru a accelera în orice direcție indicată. Proprietarul produsului este șoferul, asigurându-se că mașina merge întotdeauna în direcția cea bună, iar ScrumMaster-ul este mecanicul șef, păstrând mașina bine reglată și performanțele cele mai bune.
Lean Developmnet
Lean definește valoarea ca „ceea ce clientul este dispus să plătească”. De aceea, procesele interne trebuie analizate din punctul de vedere al valorii adăugate și al pierderilor – respectiv al acelor acțiuni și decizii care fie adaugă valoare pentru client, fie mărește costul de producție. Iar consecința logică este că îmbunătățirea performanțelor vine fie din maximizarea efectelor proceselor care adaugă valoare, fie din minimizarea celor ale proceselor care determină pierderi, fie prin acțiunea concomitentă a ambelor categorii de procese.
Pierderile au fost grupate inițial în 7 categorii:
1. Supraproducția: fabricația de produse înainte de a fi cerute de client (pe stoc) sau procesarea de informații care nu sînt necesare (de ex. produse și formulare sau date care nu au fost cerute sau nu sînt analizate de nimeni);
2. Timp pierdut pentru a aștepta ceva: lipsa unor scule, materiale, informații la momentul necesare sau așteptarea pentru prelucrarea unui lot mare din care clientul cere doar două produse;
3. Transport inutil: mutări / transferări inutile ale produsului, persoanei sau a informației în sau din magazii sau între procese, pe distanțe prea lungi;
4. Procesare inutilă: a produce un anumit nivel de calitate cu mai multe operații decît sînt necesare pentru a îndeplini cerințele clientului, utilizarea de echipamente sau scule sofisticate cînd cele simple ar fi fost suficiente, a prelucra informații într-un mod mai complicat decât cel uzual, a avea ședințe mai lungi cu personalul decât durata programată;
5. Stocuri inutile: menținerea stocurilor materiale, producție neterminată sau produse finite la un nivel în exces, pentru a compensa greșelile de execuție sau alte pierderi din timpul proceselor; neutilizarea întregii capacității productive a personalului, creativitatea și puterea de gândire;
6. Mișcări inutile: apar cînd nu există preocupări pentru ergonomie – mișcări suplimentare pentru a pune / lua un obiect în / din spațiul de lucru (banc sau birou de lucru) sau neglijență în realizarea succesiunii de mișcări pentru realizarea unei operații;
7. Defecte, Corecții, Reparații sau Reprelucrare: Orice activitate de corectare a greșelilor de proiectare sau execuție detectate după producerea lor.
Pedepsirea vinovatului nu este modalitatea de rezolvare a pierderilor recomandată de Lean Manufacturing. Odată observate, pierderile sunt un potențial de îmbunătățire! Iar analiza cauzelor poate atrage personalul organizației pentru a furniza mai multă ‘valoare pentru client’!
Abordarea Lean Manufacturing, așa cum a fost descrisă de James P. Womack și Daniel T. Jones pentru a ghida managerii în demersul lor de introducere a principiilor Lean în producție, în “Lean Thinking: Banish Waste and Create Wealth in Your Corporation”, carte apărută în SUA în 2003, înseamnă un proces de gândire și acțiune în 5 pași, respectiv:
1. Specificarea valorii pentru fiecare familie de produse, din punctul de vedere al clientului final
2. Identificarea tuturor activităților componente în cadrul fluxului de valoarepentru fiecare familie de produse, eliminând pe cât posibil acele activități generatoare de pierderi
3. Ordonarea activităților creatoare de valoare într-o succesiune (flux) de pași clar identificați, astfel încât produsul să ajungă la clientul final parcurgând unflux cât mai continuu, fără multe întreruperi, opriri și așteptări intermediare
4. O dată ce fluxul de valoare a fost stabilit și introdus, orice client intern sau extern poate aplica sistemul de tip „pull” pentru „a trage” produsul din amonte, pe fluxul de producție
5. După ce valoarea a fost specificată, activitățile creatoare de valoare identificate, cele generatoare de pierderi eliminate, fluxul de valoare stabilit și introdus, se poate trece la operaționalizarea procesului și laperfecționarea lui, până când se atinge un nivel optim, în care valoarea adăugată este maximă și majoritatea pierderilor eliminate.
Figura 2.9 Principiile Lean
Comparatie cu alte metode
Considerand ca metodele de dezvoltare pot fi plasate pe o scara continua de la cele adaptive la cele predictice, metodele agile se situeaza la extremitatea celor adaptive.
<–Agile–> <–Iterative/Incrementale–> <–Cascada–>
<––––-|––––––––––––|–––––-|->
Adaptive Predictive
Metodele adaptive sunt focalizate pe adaptarea rapida la schimbari. Nu se au in vedere cu exactitate ce se va intampla in viitor. O echipa adaptiva poate raporta exact ce sarcini vor fi realizate saptamana urmatoare si ce este planificat pentru luna urmatoare.
Metodele predictive sunt focalizate pe planificarea in detaliu a activitatilor, in timp. O echipa predictiva poate raporta exact ce este planificat pentru intreagul proces de dezvoltare. Echipa predictiva are dificultati in schimbarea directiei. Planul este optimizat pentru desinatia originala iar schimbarea directiei poate necesita renuntarea la rezultatele curente si replanificarea activitatilor. Numai schimbarile considerate importante sunt luate in considerare.
In comparatie cu metodele incrementale:
Deosebiri:
– perioadele de timp sunt masurate in saptamani si nu luni
-perioadele de timp sunt stricte (time-box-uri)
-in metodele incrementale procesul este ghidat de analiza si masurare a caracteristicilor produsului. Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului
Figura 2.10 Modul de dezvoltare Agile
Asemanari:
– creaza produse livrabil in perioade de timp scurte
In comparatie cu modelul cascada dezvoltarea agila are foarte putine in comun cu dezvoltarea cascada. Modelul cascada are si in prezent o utilizare larga.. Modelul cascada este cel mai predictiv, activitatile sunt pre-planificate intr-o secventa. Progresul este masurat prin produse intermediare (specificatii, doc de proiectare, planuri de testare, revizii ale codului, etc). Efortul de integrare si testare poate fi foarte mare (cateva luni – cativa anii), fiind una dintre cauzele de esec ale unei dezvoltari cascada. Prin dezv agila se produc produse executabile intervale de cateva saptamani sau luni. Se pune accentul pe obtinerea de executabile cat mai repede apoi imbunatatirea lor continua!Extreme Programming, este o metoda de dezvoltare agila care a crescut popularitatea metodelor agile. Extreme Programming (XP) este un model incremental bazat pe iteratii scurte, testare intensiva si simplitate. Este adecvata pentru echipe mici si proiecte caracterizate prin schimbari rapide ale cerintelor.
Avantaje
obținerea satisfacției clienților prin livrarea rapidă și continuă a software-ului;
oamenii și interacțiunile sunt mai accentuate în cadrul modelului decât procesele și instrumentele – clienții, dezvoltatorii și testării interacționează constant;
versiuni de lucru sunt livrate frecvent (mai degrabă săptămâni decât luni);
conversația față-în-față este cea mai bună formă de comunicare;
cooperare strânsă, de zi cu zi între oamenii de afaceri și dezvoltatorii produsului;
atenție continuă către excelență tehnică și proiectare bună;
adaptare regulată la circumstanțele de schimbare;
chiar și schimbările târzii în cerințe sunt binevenite;
este o abordare realistă pentru dezvoltarea de software;
promovează munca în echipă;
poate fi dezvoltat rapid;
necesarul de resurse este minim;
oferă versiuni de lucru parțiale anticipate;
este un model bun pentru mediile care se schimbă în mod constant;
există reguli minime;
permite o dezvoltare simultană și livrare într-un context general planificat;
este ușor de gestionat;
oferă flexibilitate pentru dezvoltatori.
Dezavantaje
în cazul unor livrabile software, în special mari, evaluarea efortului necesar pe întreg parcursul ciclului de dezvoltare software este dificilă de realizat;
nu se pune accent prea mare pe proiectare și pe documentația necesară;
necesită dezvoltatori cu experiență;
nu este potrivit pentru manipularea dependențelor complexe;
există risc mai mare la durabilitate, mentenabilitate și extensibilitate;
depinde foarte mult de interacțiunea cu clienții, astfel încât, în cazul în care clientul nu este clar, echipa poate fi condusă într-o direcția greșită;
există dependență individuală foarte mare, deoarece există documentație minimă generată;
transferul de tehnologie către noi membri ai echipei poate fi destul de dificil din cauza lipsei de documentație.
Agil vs. Tradițional
Modele agile –> metode de dezvoltare software adaptive
Modele tradiționale -> abordare predictivă
Metodelor predictive depind în totalitate de analiza cerințelor și de planificarea realizată la începutul ciclului
Modelul agil utilizează abordarea adaptivă – nu există o planificare detaliată, dar există claritate cu privire la sarcinile viitoare în ceea ce privește caracteristicile care trebuie să fie dezvoltate
Echipa se adaptează la schimbările dinamice ale cerințelor produsului
Produsul este testat foarte frecvent, minimizând riscul unor defecțiuni majore în viitor
Interacțiunea cu clienții este punctul forte al metodologiei agile
Comunicarea deschisă și documentația minimă sunt caracteristicile tipice ale mediului de dezvoltare agilă
Echipele lucrează în strânsă colaborare și sunt de cele mai multe ori localizate în același spațiu geografic
SDLC agil este mult mai potrivit pentru dezvoltarea de proiecte mici-mijlocii
la proiecte la scară largă este încă mai bine să se adopte SDLC tradițional
criterii pe care echipa de dezvoltare le-ar putea folosi pentru a identifica SDLC-ul dorit:
mărimea echipei;
poziția geografică;
dimensiunea și complexitatea software-ului;
tipul de proiect;
strategia de afacere;
capacitatea de proiectare etc.
In concluzie, filosofie Agile a ajutat la o colaborare mai buna cu clientii/utilizatorii fiind o parghie intre procesele invatate si cele aplicate.
Alegere Agile Alegere traditional
Figura 2.11 Criteriu decisiv pentru a alege Agile
Implementarea proiectelor de tip automotive
Ciclul de viata a unui produs in industria auto
Managerii de proiect sau organizatia poate imparti proiectele in faze pentru a avea un control mai bun asupra proiectului.Fazele ca tot unitar alcatuiesc ciclu de viata a unui proiect.
Figura 3.1 Etape proiect (Gates)
Elemente de intrare:
Cerintele corporatiei
Cerintele de departament
Cerintele de grup
Standardele ISO
Automotive SPICE
Regulile guvernamentale
Cerintele de client
Standardele industriei
Experienta anterioara-Lessons Learned
8d-uri
Cerintele actionarilor
Ciclul de viata a unui proiect in general se defineste prin urmatoarele:
Ce munca tehnica trebuie facuta in fiecare faza
Cand vor fi generate livrabile pentru fiecare faza si cum vor fi acestea is revazute, verificate si validate
Cine e implicat in fiecare faza
Cum se controleaza si se aproba fazele
Ciclul de viata a unui produs
Includeri incepand de la idee/concept, la Dezvoltarea produsului, la operatii continue de mentenanta/service pana la finalizarea produsului
Ciclul de viata a proiectului
Poate fi pentru o portiune a ciclului de viata a produsului precum faza de dezvoltare
Elementele ce alcatuiesc ciclul de viata:
Ciclul de viata a unui proiect in corporatia Continental:
Figura 3.2 Life Cycle IIC
G-Gates
Tabelul 3.1 Descriere Project Gates
Portile de calitate – Q-Gates
Calitatea corporatiei Continental a definit elemente obligatorii pentru toate departamentele in ciclul de viata. Elementele obligatorii fac parte dintr-o lista de calitate care se verifica in timpul review-ului de poarta.
Elementele Q Gate sunt incluse ca foaie de lucru in lista de verificare la review-ul de poarta a departamentului. Exista 14 elemente obligatorii in lista (Quality Hurdle Checklist ) care sunt verificate la porti:
1 Analiza cerintelor
2 Planul de proiect (pentru aplicarea proiectului de client)
3 Conceptul de siguranta
4 Analiza aleatorie
5 Conceptul de industrializare
6 Sistemul FMEA
7 Design FMEA
8 Lista potentialilor furnizori
9 Intelegerea de sursa
10 Validarea resultatelor de teste a design-ului
11 Procesul FMEA
12 Furnizorul PSW
13 Raportul de validare a produsului
14 Crearea raportului pentru poarta de calitate
Ciclul de viata incremental
Figura 3.3 Ciclul V pentru toate produsele
Tabelul 3.2 Scopul Portilor de dezvoltare inscrementala
Idei cheie de dezvoltare incrementală introduse în PLC
Abordare flexibilă
În comparație cu versiunile PLC anterioare, nu mai există nici o limitare a procesului la un prototip B și unul în ciclul C
Numărul și tipul ciclurilor V pot fi alese în mod liber, conform cerințelor proiectului
Deschis la modificări
Modificările sunt acceptate ca parte a procesului (o abordare cu o singură lovitură nu se potrivește cu cerințele în schimbare)
Transmiteți consecințele schimbărilor în mod transparent și implementați-le într-o manieră sistematică
Fiecare increment implică o (re-) prioritizare a caracteristicilor
Dezvoltarea cu funcții avansate
Toate disciplinele de dezvoltare se concentrează pe caracteristici sau funcționalități (arhitectură, organizare etc.)
Caracteristicile sunt elementul de planificare și control (Managementul lansării prin lansarea de specificatii a conținutului)
Time Boxing
Time Box definește datele de livrare convenite cât mai mult posibil
Prin urmare, în caz de probleme, de obicei, data livrării nu va fi modificată, dar poate fi discutată conținutul și eventual cantitatea de resurse utilizate
Deoarece dependențele de planificare a rezultatelor rămân mai stabile pentru majoritatea clienților / proiectelor, iar în caz de probleme numai unii ustomers / proiecte pot fi influențate de un conținut lipsă
Inspectați și adaptați abordarea
După elaborarea unui set definit de caracteristici, starea actuală este inspectată prin utilizarea reală (de exemplu, produsul de referință, produsul clientului)
Dacă modul a fost (parțial) greșit, efortul necesar pentru reparații este limitat (incrementări mici)
Agile in dezvoltarea Software
Lucrările actuale de dezvoltare se realizează la nivel de echipă. Prin urmare, mai multe echipe de dezvoltare sunt stabilite în CoC-urile care folosesc Scrum sau Kanban. Echipele se autoorganizează și fiecare echipă își planifică personal activitățile în cadrul unui sprint sau cadență și livrează în mod regulat.Gestionarea proiectelor la nivel de proiect este realizată pentru a alinia activitatea tuturor echipelor în cadrul OIP într-o direcție comună și pentru a se asigura că dependențele dintre echipe sunt considerate astfel încât lucrările să fie finalizate conform planificării. Planificarea și urmărirea la nivel de proiect se face în 3 cicluri diferite: pe termen scurt (lunar), pe termen mediu (trimestrial) și pe termen lung (6-9 luni). Reprezentanții CoC-urilor (cel puțin proprietarii de produse) și din managementul proiectelor sunt responsabili să facă planificarea la nivel de proiect.
Relatia cu PLC-ul
Figura 3.4 PLC IIC
Faza iterativă dintre etapele G40 și G60 este descrisă și adaptată pentru nevoile proiectului platformei OIP în cadrul acestui document al procedurii de dezvoltare. Platforma OIP ca platformă SW nu respectă reperele PLC (Gx), deoarece dezvoltă în permanență noi caracteristici ale foii de parcurs și conținut în timp. Prin urmare, ciclul de viață al OIP este definit prin iterații continue pe o bază lunară. Misiunea și viziunea OIP sunt definite mai detaliat în planul proiectului OIP. Prin aplicarea procesului Agile, totuși toate porțile sunt relevante și aplicabile.
Interfata la nivel de proiect
Toate echipele cu OIP lucrează cu OIP Backlog comun. OIP Backlog este o listă a tuturor lucrurilor care ar putea fi necesare pentru OIP. Este singura sursă de cerințe pentru orice modificări care trebuie aduse la OIP. OIP Backlog listează toate caracteristicile, funcțiile, îmbunătățirile și corecțiile care constituie modificările care trebuie făcute în OIP în viitoarele versiuni.Granularitatea elementelor restante poate varia, depinzând de momentul în care elementul de backlog va fi implementat. Momentul în timp este determinat de ordinea elementelor din restante. Elementele de backlog în partea de sus a restanțelor sunt candidații care vor fi implementați în viitorul apropiat. Acestea vor fi fine granulare, astfel încât acestea pot fi implementate în termen de 1 sprint / cadență (2 săptămâni). Elementele de backlog care vor fi implementate la o dată ulterioară vor avea o granularitate brută. Articolele din backlog sunt împărțite în bucăți mai mici atunci când se apropie de implementare. Prin urmare, sunt organizate întâlniri de îngrijire(grooming).
Figura 3.5 Granularitatea unui Backlog
Nivelul de detaliu din cadrul backlog-ului corespunde granularității planificării pentru diferitele cicluri. Dacă granularitatea CR este prea mare, mai multe CR pot fi combinate cu 1 pachet de CR care au o dată comună de livrare și o alocare CoC. Acest lucru reduce complexitatea în timpul planificării, deoarece doar câteva elemente mai mari trebuie luate în considerare în locul multor mici. În cadrul reuniunii de definire a scopului pentru iterația lunară va fi selectat un subset de OIP Backlog care va fi implementat în timpul următoarei iterații lunare.Retrageri la nivel de proiect sunt menținute în CS Synergy. Manipularea solicitărilor de schimbare (CR) în CS Synergy este prezentată mai jos:
Figura 3.6 Manipulare CR in CS
Manipularea Rapoartelor de Probleme (PR) în CS Synergy este prezentată mai jos. Figura 3.7 Manipulare PR in CS
În cazul unor cerințe sau arhitecturi modificate (aplicabile pentru CR și PR), trebuie făcută o analiză a acestora. În cazul în care SystemTest este implicat în Testarea ("a fi testat de"), SyT trebuie să facă parte din revizuire.
Backlog-ul OIP este ordonată. Ordonarea elementelor din backlog se face printr-o abordare pe două nivele: PO-ul principal al proiectului definește o prioritate de nivel înalt pentru următoarea iterație. La nivel de echipă, echipele utilizează această prioritate la nivel înalt în cadrul întâlnirii de definire a scopului pentru a le ordona elementele de backlog ca listă ordonată de elemente.Mărimea (efortul) articolelor OIP în așteptare este estimată în ore în care starea unui CR este "revizuită" sau mai mare.
Schimbarea bordului de control
Atunci când se creează solicitări de modificare, acestea sunt evaluate de un Comitet de control al modificărilor (CCB). Modificările pot fi adăugate la Backlog-ul OIP dacă sunt acceptate de CCB. Pentru solicitările de modificare a clientului trebuie efectuate sarcini suplimentare de analiză cu o durată specificată. Sarcinile de analiză sunt transmise uneia dintre echipe.
Există o întâlnire regulată a CCB în fiecare săptămână. În caz de solicitare de schimbare urgentă, PL poate invita la o întâlnire suplimentară.
În timpul întâlnirii CCB se evaluează cererile de schimbare noi sau analizate și se iau decizii de implementare a CR. Aceasta se face pentru solicitarea de modificare care are relevanță pentru proiectul OIP (de exemplu CR-urile clientului). Există o interogare în CS Synergy pentru a filtra acest tip de CR-uri (doar pentru CR-uri – CR-uri suplimentare trebuie adăugate la filtru).
Pentru a se asigura că activitățile de analiză sunt finalizate în timp, se urmărește starea tuturor cererilor de analiză deschise. Acest lucru reduce riscul ca sarcina de analiză întârziată să ducă la o livrare întârziată către client.
Niveluri de planificare
Tabelul 3.3 Planificarea la nivel de proiect OIP
Activitățile de planificare la nivel de proiect sunt realizate de către conducerea proiectului OIP împreună cu reprezentanți CoC. De asemenea, reprezentanții clientului pot fi invitați la întâlnirile de planificare.Planificarea granularității pentru diferitele niveluri de planificare este, de asemenea, diferită.
Elementele care vor fi implementate în viitorul apropiat (de exemplu, repetarea lunară următoare) vor fi planificate în detaliu. Elementele trebuie să fie atât de detaliate încât echipele să înceapă cu implementarea în scurt timp. Fiecare element trebuie să fie atribuit unei singure echipe – dacă sunt implicate mai multe echipe, trebuie să existe un element pentru fiecare echipă și trebuie sa fie folosit pentru planificare.
Elementele care vor fi implementate în intervalul de timp de 2-3 luni sunt mai mari, dar trebuie să se încadreze într-o perioadă de 3 luni. Fiecare element trebuie atribuit unui singur CoC – dacă este implicat mai mult de un CoC, trebuie să existe un element pentru fiecare CoC și este folosit pentru planificare.
Elementele care vor fi implementate în intervalul de timp de 6-9 luni nu au restricții pentru mărime. Acestea pot fi de dimensiuni mari și pot fi puse în aplicare de diferite CoC-uri. Este o activitate obișnuită de a face grooming pe la backlog (adăugare de informații lipsă, împărțire articolele mari în cele mai mici), astfel încât elementele din backlog să fie adecvate pentru întâlnirile de planificare.
Figura 3.8 Planificarea granularitatii
Politicile procesului de planificare și dezvoltare a OIP
Este utilizată o abordare strictă în timp
Momentele de desfășurare a platformei nu vor fi modificate datorită unui proiect client
Conținutul iterațiilor va fi definite cu puțin timp înainte de începerea procesului
cu respectarea priorităților / programelor diferitelor clienți.
Nicio schimbare a priorităților în cadrul ciclului de dezvoltare (excepție: Showstoppers)
Controlul și raportarea iterației lunare vor fi efectuate la sfârșitul iterației (în timpul revizuirii domeniului)
Manipularea modificărilor de domeniu în timpul iterației lunare: Trebuie să fie negociate modificări ale "riscurilor ridicate ale domeniului angajat" cu OIP PO
CoC-urile pot face eforturi suplimentare deasupra, atâta timp cât nu riscă sfera angajată
Cererile de schimbare sunt acceptate numai dacă sunt înțelese și în conformitate cu definiția Ready (DoR)
Cererile de modificare sunt aprobate numai dacă sunt conforme cu definiția făcută (DoD)
Urmărirea și raportarea costurilor au fost efectuate trimestrial
În cazul în care se adaugă noi subiecte în domeniul de aplicare în timpul iterației lunare, alte elemente din domeniul de aplicare ar putea fi eliminate
Planificarea pe termen scurt
Scopul planificării pe termen scurt este de a alinia echipele la un obiectiv comun și de a se angaja în munca pe care fiecare echipă o va face în timpul următoarei iterații lunare. Informațiile de planificare sunt, de asemenea, comunicate clienților. Dependențele dintre activitățile echipelor trebuie să fie cunoscute, transparente pentru toți și înțelese de reprezentanții echipelor. Dependențele trebuie să fie transparente în timpul definiției de domeniu. Lucrările comise vor fi rezolvate până la sfârșitul iterației și ar trebui modificate numai în cazuri rare. La sfârșitul fiecărei iterații trebuie să fie disponibilă o soluție posibila de expediere, așa cum le-a comis echipele. Elementele de întârziere utilizate în timpul planificării pe termen scurt trebuie să fie suficient de mici pentru a putea fi utilizate pentru planificarea sprintului / cadenței.
Elementele planificate sunt de tipul Change Request (CR). Pentru rapoartele de probleme (PR), este planificat doar numărul de PR-uri care vor fi rezolvate în timpul iterației. Toate CR-urile care vor fi implementate în cadrul iterației lunare trebuie să intre în întâlnirea de planificare – chiar dacă acestea sunt mici.Observație: Caracteristicile sunt, de asemenea, reprezentate de CRs.
Definirea scopului
Scopul definit este o întâlnire în care se adună liderii PO, SPO (SWPL) și QE pentru a-și furniza elementele în termeni de PR / CS care vor fi livrate în luna următoare.Fiecare proprietar de produs (SPO) trebuie să pregătească pentru definiția "Scope" următoarele:
marcați câmpul "Domeniul de livrare CS", pentru CR-urile angajate în următoarea iterație lunară, luând în considerare definiția gata și prioritizarea oferită de conducătorul PO
numărul estimat de PR-uri rezolvate la sfârșitul iterației
Toate CR-urile cu Domeniul de livrare marcat pentru definiția actuală a scopului sunt evaluate / verificate în funcție de definiția Ready de SE (echipa de ingineri de sistem) și QE (ingineria calității) înainte de întâlnirea Definition Scope.
Obiectiv: PO conduce analiza cu fiecare SPO a contribuției furnizate, pentru a determina dependențele și a se angaja asupra lucrărilor ce trebuie îndeplinite în caseta de timp următoare
Ieșire: Document de definire a obiectului -> OIP_ScopeDefinition_yymm.xlsx
Validarea clientului
Conducătorul PO informează clienții cu privire la angajamentul asumat și trebuie analizate adaptările solicitate de client în cazul în care ar trebui să ia parte la definirea scopului pentru perioada de timp următoare.
Orice schimbări sau activități care apar în timpul iterației lunare și care ar putea avea un impact asupra domeniului de acțiune pe care l-ați angajat trebuie negociate cu PO Lead.
Atâta timp cât domeniul de activitate implicat nu este în pericol, echipele agile au libertatea de a adăuga sau de a elimina elemente din backlog-urile lor.
Revizuirea scopului
Intalnirea de revizuire (review) are loc la sfârșitul fiecărei iterații lunare.Ca pregătire a revizuirii domeniului:
QA efectuează controale de asigurare a calității împotriva DoD
Echipa de integrare a Sistemului oferă un raport de testare cu rezultatele articolelor comise. Întâlnirea de examinare a domeniului trebuie păstrată foarte informal. Nu trebuie folosite diapozitive Power Point și timpul pentru pregătirea și desfășurarea întâlnirii trebuie sa fie limitat. În timpul întâlnirii, PO-ul principal inspectează elementele livrate și acceptă sau respinge elementele folosind verificările de QA cu regulile DOD și raportul de testare furnizat de SI cu rezultatele articolelor angajate.
Rezultatul revizuirii Domeniul de aplicare sunt 2 fișiere aflate pe punctul de partajare
OIP_Scope_Review_yymm.xlsx
OIP_Scope_Review_Report_yymm.ppt
Retrospectiva
Intalnirea de Retrospectiva este o întâlnire în care echipa de proprietari de produse și QA discută despre repetarea lunară încheiată și determină ce s-ar putea schimba, ceea ce ar putea face ca iterația următoare să fie mai productivă.
Pe parcursul retrospectivelor sunt descoperite soluții reale care pot fi implementate imediat. Rezultatul fiecărei retrospective este un raport cu aspectele pozitive, negative și elementele de acțiune identificate și urmărite.
Urmărirea
În timpul unei întâlniri săptămânale de urmărire, sunt urmărite statusurile CR și PR. Prin urmare, fiecare echipă trebuie să aibă o listă a CR-urilor și a PR-urilor și statutul lor (starea de finalizare și orele rămase).La nivel de proiect, informațiile sunt agregate într-un tabel pentru a urmări progresul în timpul iterației. Ca un prim pas agregarea se face manual cu Excel. În viitor, poate fi implementat un proces automatizat (de exemplu, ca un plug-in Jira care colectează informații).
Figura 3.9 Urmarirea progresului cu iteratii lunare
Valorile pentru coloana "Capacitatea echipei" și "Total ore" sunt utilizate în întâlnirea de definire a domeniului. Raportul este calculat din orele rămase, repartizate pe capacitatea echipei. Codurile culorilor în raportul coloanelor sunt folosite pentru a vizualiza dacă echipa este peste sau sub rata calculată a ratei de lucru (de exemplu, după săptămâna 1 orele rămase ar trebui să fie egale sau mai mici de ¾ din capacitatea echipei).
În cazul în care punerea în aplicare a CR-ului este un impact întârziat asupra dependentelor de CR și datele de livrare trebuie analizate și trebuie definite măsuri adecvate pentru a reduce riscul livrărilor întârziate și a reveni pe drumul cel bun.
În plus, diagrama de maturitate pentru funcțiile CoC, așa cum este utilizată pentru urmărirea procesului în cadrul CoC-urilor.
Observație: În plus față de urmărirea orelor rămase, echipele ar trebui să fie urmărite și la terminarea CR unde fiecare CR este în lucru (0% = nu este încă făcut) sau făcut (100% corespunzător DoD). Acest lucru impune echipei să completeze CR-urile deschise unul câte unul în loc să facă o mulțime de activități paralele. Pentru proiect, acest lucru reduce riscul ca la sfârșitul perioadei de repetare lunară, multe CR-uri să fie in lucru, dar încă să nu fie finalizate (pentru a evita situațiile în care toate CR-urile sunt completate doar cu 99%).
Raportarea
La finalul iterației lunare, următoarele date cheie de performanță trebuie furnizate într-un raport în format Powerpoint:
CRA: Acuratețea angajamentului de schimbare a solicitării
CRP: Modificarea previzibilității cererii
PRA: Acuratețea raportării problemelor
PV: Proiectul Velocity
În plus, fiecare echipă Scrum are o diagramă de burndown (pe baza orelor rămase) pentru iterația lunară și orele rămase (până la sfârșitul iterației lunare).
Planificarea pe termen mediu
Planificarea pe termen mediu se realizează trimestrial și se utilizează pentru a planifica conținutul pentru dezvoltarea trimestrului următor pentru OIP. Aceasta oferă tuturor părților interesate o perspectivă despre cum va fi dezvoltată în următorul trimestru și modul în care fiecare CoC va contribui la rezultate.Planificarea pe termen mediu începe cu 6 săptămâni înainte de trimestrul următor. Întâlnirile sunt programate de către organizația de conducere suficient de timpuriu pentru ca toate părțile interesate să se poată pregăti în mod corespunzător.
Pregatirea
Ca un prim pas, fiecare CoC planifică pe cont propriu și selectează elementele restante pe care intenționează să le implementeze în trimestrul următor. CoC este responsabil pentru planificarea elementelor restante la care sunt proprietari. CR-urile trebuie să fie suficient de mici pentru a se încadra în intervalul de timp de 1 trimestru. CR mai mari trebuie împărțite pe cele mai mici.
Trebuie pregătite următoarele elemente:
Toate CR disponibile la OIP pentru> = 15 zile lucrătoare trebuie să fi ajuns la DoR (CS Status> = review)
CR-uri cu un efort estimat total> 80h care urmează să fie planificate în MS-Project în plus
Dependențele trebuie să fie înțelese și clarificate
De asemenea, pentru a fi planificate:dependențe si reperele importante ale clientului
Aceste planuri conțin, de asemenea, dependențe interne (în cadrul CoC) și dependențe față de celelalte CoC-uri. Dacă există dependențe față de alte CoC-uri, proprietarul este responsabil să contacteze CoC-ul dependent și să se sincronizeze cu acesta.
Când se planifică, CoC trebuie să considere că PR trebuie rezolvate în plus față de implementarea CR. Prin urmare, capacitatea trebuie redusă prin efortul planificat pentru activitățile de PR.Elementele de backlog cu prioritate maximă sunt selectate de CoC. Acest pas se repetă până la atingerea capacității echipelor. De asemenea, trebuie identificate toate dependențele față de alte CoC, astfel încât acestea să fie transparente în cadrul întâlnirii de planificare.
Informațiile de planificare vor fi furnizate ofițerului principal înainte de desfășurarea ședinței de planificare pe termen mediu. Articolele cu întârziere care vor intra în planificarea pe termen mediu sunt acceptate numai dacă îndeplinesc DoR la nivel de proiect (de ex. Trebuie estimate aproximativ).
Intalnirea de planificare
O întâlnire de planificare este programată prin intermediul instrumentelor de conferință telefonică și de partajare a ecranului, astfel încât participanții la alte site-uri de dezvoltare să poată participa la distanță. Reprezentanții fiecărui CoC (SPO) ar trebui să participe la reuniune. În plus, reprezentanții clienților pot fi invitați și pot participa la întâlnire.
Scopul acestei întâlniri este
– să aibă transparență pentru toți participanții la ce va lucra OIP
– să alinieze activitățile de dezvoltare pentru toate CoC și să se asigure că conflictele sunt soluționate din timp
– asigurarea faptului că elementele restante care sunt mai mari sau au dependențe sunt începute suficient de devreme pentru a fi finalizate în timp
– pentru a verifica dacă personalul este suficient
La începutul întâlnirii, managementul prezintă contextul de afaceri, viziunea și obiectivele, precum și schimbările arhitecturale (dacă există) pentru perioada de planificare.
După aceea, fiecare CoC prezintă elementele restante pe care le-au planificat și explică în scurt timp ceea ce doresc să obțină. Alți participanți pot pune întrebări adăugând informații lipsă.
Ca o a doua etapă, planificarea informațiilor este combinată cu o planificare completă prin adăugarea fiecărei planificări CoC ca o înotătoare pe un consiliu de planificare. Dacă există dependențe față de alte CoC, trebuie să fie creat un element pe swimlane-ul acelui CoC, iar dependența trebuie creată printr-o conexiune între cele două elemente. Cel de-al doilea pas este repetat pentru fiecare dintre CoC până când toate CoC sunt reflectate pe board-ul de planificare. Eventualele conflicte trebuie rezolvate în timpul creării conținutului consiliului de planificare de către acea discuție. Grupul de conducere acționează ca moderator în cadrul discuției.
Figura 3.10 Exemplu pentru Backlog pe termen mediu
Riscurile și impedimentele care ar putea afecta capacitatea lor de a-și atinge obiectivele sunt identificate în timpul întâlnirii de planificare trebuie să fie documentate. Înainte de închiderea întâlnirii pentru fiecare risc, trebuie să decidă cum să se ocupe de ea. La sfârșitul întâlnirii de planificare se face un vot de încredere al CoC implicat. Doar dacă toate CoC-urile sunt încrezătoare în realizarea planului, întâlnirea de planificare poate fi închisă. În caz contrar, planificarea trebuie ajustată până la atingerea încrederii. La sfârșitul întâlnirii de planificare există un plan comun care are toate elementele planificate de restante cu dependențele lor. Planul este armonizat între toate părțile interesate, iar CoC-ul are convingerea că planul poate fi executat în consecință.Reprezentanții CoC-urilor sunt responsabili să transmită aceste informații înapoi membrilor CoC.
Urmarirea
Informațiile de urmărire care sunt adunate în timpul urmăririi iterației lunare sunt folosite pentru a face și urmărirea la mijlocul perioadei. În următoarele cazuri, planificarea pe termen mediu trebuie să fie ajustată:
Estimarea CR-urilor mari (cele implementate în mai mult de 1 iterație lunară) se modifică sau implementarea este întârziată
Se creează noi solicitări de modificare care trebuie implementate în perioada intermediară
Modificările existente sunt modificate (de exemplu, estimare, data de livrare)
Munca comisă a iterației lunare este întârziatăUrmărirea planificării la jumătatea perioadei se face imediat după urmărirea iterației lunare, iar planificarea pe termen mediu trebuie ajustată în consecință. Dacă datele de livrare ale clienților sunt în pericol, o întâlnire suplimentară de planificare pentru a actualiza planificarea pe termen mediu trebuie să fie programată.
Raportarea
Rapoartele pe termen mediu au următoarele informații:
– livrările planificate și starea (roșu / galben / verde)
– Modificarea planificării și efectul acesteia asupra datelor de livrare
Retrospectiva
O retrospectivă se desfășoară la finalul iterației trimestriale și înainte de începerea următoarei iterații trimestriale. Programul este elaborat în avans și data și ora sunt comunicate tuturor celor interesați, astfel încât aceștia să vină pregătiți cu unele date. Participanții la o retrospectivă de predare sunt conducătorii, proprietarii de produse, maeștrii agili, persoanele cheie implicate în lansarea și planificarea strategică. Rezultatul fiecărei retrospective este un raport cu aspectele pozitive, negative și elementele de acțiune identificate și urmărite.
Planificarea pe termen lung
Manipularea unui CR mai mare – Structura in CS
Atunci când se creează un CR, CCB (biletul în starea de previzualizare) atribuie biletul la SE în mod implicit.Notă: CR-urile clientului nu pot fi atribuite direct domeniilor / CoC-urilor!Pe baza analizei SE:
dacă nu este nevoie de impact asupra cerințelor sistemului, arhitecturii și nu este necesară o contribuție transversală (mai multe CoC trebuie să furnizeze conținut pentru a satisface CR), clientul CR poate fi alocat în continuare software-ului.
În toate celelalte cazuri (necesitatea sistemului – / impactul arhitecturii sistemului sau contribuțiile multiple), CR-urile dedicate pentru copii trebuie să fie create.Fiecare Responsabil CR trebuie să urmeze activitățile standard de analiză CR și de planificare pentru Cerințele de Inginerie și Plan (identificarea de noi caracteristici / variante, crearea și reutilizarea cerințelor de corespondență).
Nota:
O caracteristică nouă în DOORS are legătura cu un CR și trebuie creată doar pe baza unui CR.
Bilete cu caracteristici în piste CS / reprezintă nivelul de maturitate al unei caracteristici, specificat în DOORS. Biletul de funcții este creat de DOORS.
Pentru a finaliza faza de cotare (previzualizare pentru revizuire) a CR-urilor, trebuie să se realizeze "Definiția pregătirii" (verificarea impactului asupra arhitecturii și design-ului software, studiul de fezabilitate la nivelul software-ului, identificarea și organizarea contribuției ulterioare estimarea efortului brut.După ce biletele CR sunt în decizia de revizuire pentru CR-urile care urmează să fie implementate este marcată de stabilirea CS [Review Progress] cu "Request Implementation".În acest moment CR-urile se importă automat într-un proiect Jira, pe baza criteriilor definite de echipă împreună cu P & T. Aceasta înseamnă că biletul este acum mutat de la nivelul proiectului la nivelul echipei.Echipa de dezvoltare Agile va lucra pe întârzierile lor pentru a-și descompune problemele.Există criterii pentru crearea unui nou element (CS / Jira) la nivel de echipă, care sunt următoarele:
Acțiunile CS implicate:
Numărul de livrări (de la nivel de echipă la nivel de proiect) pentru un elemento
Crearea unui nou copil CR în CS
Problema nouă este identificată în timpul integrării / testării CRo
Biletul CS este setat la "SMVF"
Creați Subtask dacă problema Jira CR este încă activă
Deplasați problema CR in Jira la backlog-ul echipei, dacă problema Jira corespunzătoare CR este încă inactivă (Rezoluție: fixă)
Creaza PR in toate celelate cazuri
Este nevoie de contribuția altor echipe
Creați Child Child CR dacă este implicat alt CoC / Domeniu
Creati subtipuri / alt tip / poveste în Jira, dacă pot fi gestionate în același proiect JIRA.
Este necesară o nouă echipă (de exemplu CS: responsabilul CCB sau numele echipei Jira este schimbat)
Crearea automată a unui ticket problema in Jira (prin instrumente)
În cazul în care este vorba de o echipă a altui CoC / Domeniu, crearea este posibilă numai pentru CR (și PR)
În cazul în care este vorba despre o altă echipă din cadrul aceluiași CoC / Domeniu, crearea este posibilă pentru CR-uri (și PR-uri), sub-sarcini și acțiuni (altele)
Se identifică lucrări noi / suplimentare
Creați CR noi în CS dacă lucrați în programare cu o livrare dedicate
Creați subtascuri în JIRA dacă nu este necesară o livrare dedicată
Activitățile JIRA implicate:
Numărul de rezolvatori
Creați un nou Subtask în Jira
Efortul unui element este prea mare pentru Cadence Sprint / Kanban
Creați sub-sarcini în Jira (foarte des întâlniți în Kanban)o
Creați un copil PR / CR dacă munca disponibilă are sens să fie inclusă într-un produs
OBS: Nu vă recomandăm să utilizați Story deoarece conexiunea cu PR / CR parentală este pierdută și nu veți putea vedea progresul articolului complet în JIRA.
Efort mai mare decât de ex. 24h pentru o persoană (valoarea poate fi definită de fiecare echipă separat)
Creați un nou Subtask în Jira
Numărul de acțiuni (opțional)
Creați un nou Subtask în Jira
Următoarea diagramă arată un exemplu despre modul în care CR-urile mai mari ar trebui gestionate și descompuse în mai multe echipe:
Figura 3.11 Descompunere Tichete Proiect – Echipa
Intr-o echipa:
Figura 3.12 Descompunere CR Proiect – Echipa
Interfata la nivel de echipa
Descriere generala
Dezvoltarea software-ului pe agile este caracterizată în primul rând printr-o procedură iterativă cu faze alternative de planificare și dezvoltare. Avantajul pe care îl oferă este că anumite părți ale sistemului sunt dezvoltate din timp și pot fi testate înainte de implementarea altor părți. Acest lucru reduce riscul ca dezvoltatorii de proiecte să se îndrepte în direcția greșită. Mai degrabă, răspunzând rapid și flexibil modificărilor cerințelor, componentele unui sistem pot fi redefinite pentru a satisface cel mai bine nevoile reale ale unui client.
Scrum
Scrum ajută la construirea unui produs într-o serie de iterații cu lungime fixă numite sprinte care oferă echipelor un cadru pentru software-ul de expediere pe o cadență obișnuită. Momentele – adică sfârșitul unui sprint – vin frecvent, aducând cu ele un sentiment de progres tangibil cu fiecare ciclu care focalizează și energizează pe toată lumea. ("Inspirație continuă" pentru câștig!).
Scurte iterații de iterație de 2 săptămâni – 1 lună consolidează importanța unei estimări bune și a unui feedback rapid din teste.
Scrum si adaptarea sa vorbește despre:
cinci ceremonii (aranjare(grooming), planificare sprint, stand-up zilnic, revizuire sprint, retrospectivă sprint)
trei roluri (deținătorul proiectului, Agile Master (ScrumMaster), echipa de dezvoltare)
cinci artefacte (Project Backlog, Sprint review, diagramă Burndown, DOD, DOR)
La începutul fiecărui Sprint, are loc întâlnirea de planificare Sprint. Proprietarul de produse și echipa de dezvoltare/Scrum (cu facilitare din partea AgileMaster) analizează Product Backlog, discută despre obiectivele și contextul elementelor, iar echipa Scrum / Development selectează elementele din Project Backlog pentru a se angaja să finalizeze până la sfârșitul Sprint, începând din partea de sus a Product Backlog-ului. Fiecare element selectat din Product Backlog trebuie să respecte Definiția Ready și este împărțit la un set de sarcini individuale. Lista sarcinilor este înregistrată într-un document numit Sprint Backlog.
Odată ce Sprint-ul a început, echipa Scrum se angajează într-o altă practică Scrum-cheie: Întâlnirea zilnică de stand-up. Acesta este o scurta (15 minute – 1-2 minute per membru al echipei) întâlnire care se întâmplă în fiecare zi de lucru la un moment dat. Toți cei din echipă participă. La această întâlnire sunt prezentate informațiile necesare pentru a inspecta progresul. Aceste informații pot duce la replanificare și discuții ulterioare imediat după Daily Scrum.
După terminarea Sprint-ului, există Sprint Review, în care echipa Scrum / Development și părțile interesate inspectează ceea ce s-a făcut în timpul Sprint-ului vs. Definition of Done, se discuta si se afla ce trebuie facut în continuare. Prezent la aceasta intalnire sunt Proprietarul de Produs, Membrii echipei si AgileMaster, plus clienti, stakeholderi, experti, directori si oricine altcineva interesat.
Elementele care nu respectă Definiția făcută sunt respinse și în baza priorității sunt completate în următoarele Sprint-uri.
În urma revizuirii de Sprint, echipa se reunește pentru Retrospectiva Sprint, care reprezintă o oportunitate pentru echipa de a discuta despre ce funcționează și ce nu funcționează și că este de acord cu schimbările pe care le încearca.
Întâlnirea Groomming, cunoscută sub numele de reuniune de rafinare a proiectului, este ținută aproape de sfârșitul unui sprint pentru a asigura că lista din backlog este pregatita pentru următorul sprint.
Intenția unei întâlniri de "îngrijire" este aceea de a se asigura că restanțele rămân populate cu elemente relevante, detaliate și estimate într-o măsură adecvată cu prioritatea lor și în conformitate cu înțelegerea actuală a proiectului sau a produsului și a obiectivelor acestuia.În timpul întâlnirii, se verifică definiția DOR pentru articolele relevante pentru următorul sprint.
Nu toate povestile despre utilizatori trebuie să fi fost impartite la un nivel de granulație fină la începutul proiectului sau să fie date estimări detaliate; dar este important ca, în orice moment, un număr suficient de "povesti" să fie pregătit pentru programare în următoarele iterații.
În timpul unui sprint, artefactele cum ar fi board-urile Scrum și graficele de Burndown, vizibile echipei, sunt factori puternici. Ei conduc un spirit de "facem asta!" Având ocazia de a arăta noi lucrări la demo-ul din sprint este la fel de motivant și feedback-ul consistent, incremental pe care echipa îl primește de la părțile interesate la fiecare demo, creează o modalitate puternică de a dezvolta produse.
Kanban
Kanban este o tehnică de gestionare a unui proces de dezvoltare software într-un mod foarte eficient.Metoda Kanban nu are nevoie să schimbe procesul actual al echipei, vrea să contribuie la îmbunătățirea, evoluția procesului actual. Adoptarea Kanban implică următoarele 5 pași:
1. Vizualizați fluxul de lucru
2. Limitați PIB
3. Gestionați fluxul
4. Faceți politici explicite pentru proces
5. Îmbunătățirea colaborativă (folosind modelele și metoda științifică)
Numărul membrilor echipei dintr-un proiect Kanban poate varia.Fiecare echipă care adoptă Kanban trebuie să aibă un mecanism de vizualizare a fluxului de lucru. Pe baza membrilor echipei se poate folosi o placă fizică sau o placă electronică. Pentru echipele care au membri distribuite în diferite locații, o placă electronică se potrivește mai bine. Punerea în aplicare a consiliului Kanban oferă posibilitatea ca fiecare membru al echipei să vadă toate activitățile necesare (de exemplu: CR / PR-uri, orice alte activități care nu sunt legate de CS), prioritizarea acestora, activitățile curente care se desfășoară în prezent, activități. Organizarea consiliului de administrație de la Kanban este de competența echipei și poate fi adaptată la timp.
Pentru a reduce multitasking-ul și pentru a elimina blocajele, este important să aveți o limitare pentru activitatea în desfășurare (limitarea WIP). Este aplicat fiecărui membru al echipei și oferă posibilitatea de a se schimba de la împingere la tragere, ceea ce acționează ca o motivație mai bună pentru echipă. Termenul WIP se configurează pe baza datelor primite de la membrii echipei și poate fi adaptat în timp ce proiectul evoluează. Limitarea WIP este setată individual pentru fiecare activitate de la bordul Kanban (de exemplu: în cazul în care există 2 activități diferite în fluxul kanban, fiecare poate are un set limită WIP diferit).
Ca mecanism pentru gestionarea fluxului și urmărirea activităților, sunt utilizate întâlniri zilnice (standup). Pe baza locației membrilor echipei și a tipului de bord, reuniunile zilnice pot fi ținute în fața consiliului Kanban prin telefon, în cazul plăcilor electronice. Scopul acestei întâlniri este de a discuta toate problemele din flux și, pentru aceasta, fiecare membru al echipei trebuie să participe și să dea informații despre lucrul făcut, despre lucrurile ce urmează a fi făcute, despre sprijinul necesar și despre existența unor elemente blocate. De obicei, această întâlnire trebuie să fie cât mai scurtă posibil (1-2 minute pe membru al echipei). Moderatorul acestei întâlniri este Maestrul Kanban. Această activitate poate fi luată de toți membrii echipei prin rotație, astfel încât toți ar putea avea șansa să o facă. Masterul Kanban trebuie să fie în contact permanent cu proprietarul produsului, astfel încât să știe toate problemele și prioritățile. În timpul acestei întâlniri, Masterul Kanban trebuie să aibă grijă de definiția făcută și de definirea gata pregătită. Pentru a elimina impedimentele care urmează în timpul standurilor zilnice, este necesară implicarea Masterului Kanban.
Un alt mecanism care ajută la gestionarea fluxului este prin utilizarea diagramelor de flux cumulativ.Metoda Kanban nu prescrie ce trebuie făcut, este de datoria echipei să definească ce trebuie făcut pentru a obține rezultatele așteptate.
Deoarece există întotdeauna nevoie și dorință de îmbunătățire, echipele utilizează alte mecanisme ca întâlniri retrospective. Frecvența acestora este stabilită de echipă (se recomandă o dată pe lună). Aici, întreaga echipă se reunește la întâlnirea retrospectivă unde folosesc diferite metode (jocuri, activități scurte) identifică problemele întâlnite în ultima cadență și încearcă să găsească soluții pentru rezolvarea lor și motivarea membrilor echipei. De asemenea, un pas important pentru aceste întâlniri este de a afla "indicele de fericire" pentru toți membrii echipei pentru care trebuie să completeze un formular. Ca ieșire trebuie să fie creată o listă de elemente de acțiune și rezultatul să fie afișat pe o placă, astfel încât acestea să poată fi vizibile pentru fiecare membru al echipei. Facilitatorul acestei întâlniri este din nou Maestrul Kanban.
Interfata dintre nivelul de proiect si nivelul de echipa
Comunicarea între echipa și nivelul proiectului este în principal stabilită prin planificarea, urmărirea și revizuirea reuniunilor iterației lunare. În timpul acestor întâlniri este planificată, monitorizată și revizuită dependența dintre echipe, precum și între echipe și proiect.
Temele legate de arhitectură sunt discutate și luate în considerare în cadrul comunității de arhitectură, împreună cu echipa Agile Architecture System.
Subiectele legate de integrare sunt discutate și hotărâte în cadrul comunității de integrare împreună cu echipa de integrare de sistem Agile.
Figura 3.13 Organizarea la nivel de proiect și de echipă
Din punct de vedere tehnic, interfața este stabilită prin sincronizarea datelor între CS Synergy (pentru elementele de la nivelul proiectului) și Jira (pentru elementele de pe echipă). Solicitările de schimbare și rapoartele de probleme sunt sincronizate între cele două instrumente. Datele care sunt utilizate numai la nivel de echipă (de exemplu sub sarcini) nu sunt transferate înapoi la CS Synergy.
Figura 3.14 Sistemul CR/PR in Jira
Optimizarea lantului de productie
Adoptarea unei proceduri Agile specifice modului de dezvoltare
Creare unei proceduri la nivel de echipa cu un proces bine definit si general valabil pentru toate echipele implicate este un factor important in crearea unei fundatii solide bazata pe principiile Agile.
Pe baza capacității Agile Release Train (trenul este compus din echipele Agile), intrările vor veni ca Features in Backlog-ul din cadrul nivelului de program. Planificarea, care este organizata la nivel de program, va decide din backlog-ul principal conținutul pentru următorul Program Increment.Acesta va acoperi o cadență de 8-10 săptămâni.
Rezultatul întâlnirii de planificare a creșterii programului este obiectivul PI la nivel de echipă, bazat pe capacitatea și angajamentul echipei. Fiecare echipă creează Team Backlog care conține toate elementele necesare pentru a atinge obiectivul PI. Echipa va executa iterații de 2 săptămâni după cum este descris în Figura de mai jos.
Metodologia Agile la scara larga
Figura 4.1 Agile scalat la nivel de proiect
Figura 4.2 Iteratia Agile la nivel de echipa
După 4 iterații, ultima iterație este diferită, se numește Iterație de inovare și planificare. Activitățile care sunt greu de încadrat într-o livrare continuă, incrementală se fac în cadrul acestei iterații. Iterația include:
Inovație și explorare
Timp de pregătire pentru demonstrația sistemului PI
Timp dedicat pentru Inspect și Adapt (retrospectiva cu program comun)
Pregătirea pentru planificarea PI și perfecționarea restanțelor
Integrare finală față de soluție
Lucrul pe infrastructura tehnică și instrumentarea
Raportarea cu privire la eficiența generală, viteza și satisfacția profesională
Echipa poate lucra la activitățile care reflectă misiunea companiei și își demonstrează munca altora la sfârșitul cadenței.
Scrum si Kanban
Echipele integrează cele mai bune practici ale lui Scrum și Kanban pentru a facilita fluxul de lucru prin iterații.Fiecare echipă face parte din Train Agile Release, toate echipele planifică împreună (în Planificarea PI), integrează și demo împreună, învață împreună, având un "program de responsabilitate comună".
Scrum
Scrum este un cadru de management al proiectelor bazat pe echipa, folosit în cea mai mare parte de echipele Agile. Aceasta susține avansarea rapidă și iterativă a soluției și facilitează îmbunătățirea continuă în sprijinul creșterii productivității și a rezultatelor de calitate. Este destinat echipelor inter-funcționale, auto-organizate, care să funcționeze în limitele conținutului Train Agile Release și Iteration. Scrumurile scrum necesare sunt: Proprietarul de produs, membrii echipei Scrum Master și Agile Team. Proprietarul produsului este responsabil pentru ceea ce se construiește, el este proprietarul restantei echipei. Scrum Master este liderul slujitorului agil, ajutând echipa să înțeleagă și să aplice regulile lui Scrum și să înlăture impedimentele care lucrează cu lumea exterioară.
Echipa este prezentată cu scopul Iterației și este singura responsabilă pentru determinarea cantității de domeniu în care se poate angaja și a modului de a construi creșterea valorii. Echipa are rolurile și abilitățile necesare pentru a furniza o creștere.
Tabloul echipei de povestiri vizualizează poveștile și progresele înregistrate pe parcursul repetării. Fluxul de lucru pentru tabloul de poveste este:
Nou ->
Pregatit (după planificarea PI) ->
Lucrul ->
Verificare ->
Terminat ->
Livrat (implementat în sistem) ->
Aprobat (Demonstrația sistemului a trecut)
De asemenea, poate fi aplicată o limită a lucrărilor în curs de desfășurare la câțiva pași. Procesul Scrum este centrat în jurul iterației (interval de timp de două săptămâni) în care echipa definește, construiește, testează și analizează rezultatele.
Ceremoniile din cadrul programului Scrum sunt: planificarea iterației, stand-urile zilnice, demonstrația echipei, retrospectiva iterației. Echipele Agile funcționează în cadrul trenului de lansare Agile care oferă un mediu de colaborare și aliniere, în care echipele pot coopera cu alte echipe pentru a construi capabilitățile soluției larga.
Kanban
Kanban este o metodă de vizualizare și gestionare a muncii. Se aplică echipelor de sistem, echipelor de dezvoltare și echipelor de întreținere. Mediul în care se desfășoară aceste echipe se schimbă rapid, timpul scurt de răspuns și natura focului rapid sunt o caracteristică definită a muncii lor.
Sistemul Kanban se bazează pe sistemul "trage", este construit din state de flux de lucru, statele au limite de lucru în curs (WIP) (un element de lucru poate fi tras la o stare numai atunci când numărul de articole la acea stare este mai mică decât limita WIP). Prima și ultima stare nu sunt limitate la WIP. WIP sunt definite și pot fi ajustate de către echipă. Kanban se aplică în sincronizarea cu planificarea agilă de planificare – aliniere, gestionarea dependenței, cicluri rapide de învățare.
Sistemul de dezvoltare Kanban este format din:
• Stări definite care lucrează prin (de la stânga la dreapta)
• Lucrul este vizualizat și progresul este urmărit
• Limitele WIP pentru fiecare stat sunt agreate de echipă și ajustate pentru a îmbunătăți fluxul
• Politicile specifice vor acoperi modul în care este gestionată munca
• Debitul este măsurat: timpul de execuție (cât timp durează un element în medie pentru a trece prin sistem de la intrare până când acesta părăsește sistemul Kanban)
• Prioritizarea se face de către proprietarul produsului
Fluxul de lucru trebuie să corespundă stărilor curente:
Nou ->
Pregatit (după planificarea PI) ->
Lucrul ->
Verificare ->
Efectuat ->
Livrat (implementat în sistem) ->
Aprobat.
Limitele vor fi impuse statelor de lucru și livrate. Dacă livrarea se va face automat prin intermediul Jenkins, atunci starea livrată va pierde și limita WIP.
Board-ul Kanban ar trebui să evolueze pe baza blocajelor analizate care vor apărea.Pentru a-și îmbunătăți fluxul, echipele Kanban ar trebui să le măsoare, inclusiv timpul mediu de plumb, WIP și cantitatea de trecere (numărul de povești realizate pe o perioadă de timp). Jira va oferi Diagramă cumulativă pentru acest lucru.Echipa Kanban operează pe cadență de iterare, va fi măsurată cantitatea de materiale în iterații pe iterație.
Pentru a participa la planificarea PI, echipa Kanban ar trebui să-și calculeze capacitatea de iterație. Acest lucru se poate face astfel pentru primele iterații: (WIP / timpul mediu de plumb în zile) * Durata iterării Durata, Durata de iterație este de 14 zile. După primele iterații, echipa va avea "viteza derivată" înmulțind pătratul cu o dimensiune medie a povestii (în mod normal 3 – 5 puncte).
Kanban utilizează, de asemenea, mecanismul de grupare a elementelor în clase de servicii, în scopul de a diferenția itemurile restante pe baza costului de întârziere:
Standard: majoritatea elementelor din restanțe sunt aici, nu sunt dependente de data sau sunt necesare, costul întârzierii este liniar, valoarea poate fi obținută numai atunci când este livrată.
Data fixă: elementele de dată fixă reprezintă etapele și dependențele cu o dată predeterminată; costul întârzierii este neliniar; elementele sunt trase în dezvoltare pentru a fi terminate la timp; analiza suplimentară pentru rafinare va oferi timpul de plumb așteptat; dacă echipa poate cădea în spatele programului, elementele din această clasă se pot transforma în "expediere"
Expediere: această categorie de articole necesită o atenție imediată, are un cost inacceptabil de întârziere; acesta poate fi tras peste constrângerile WIP. În mod normal, în sistem poate exista un singur element "expedit" și echipa va lucra pentru a accelera procesul prin sistem.
Echipa Kanban face parte din trenul de eliberare Agile și trebuie să respecte aceleași reguli: să planifice împreună, să integreze și să demoleze împreună și să învețe împreună.
Echipa Kanban se uită la munca necesară, împarte elementele mai mari acolo unde este necesar și conduce poveștile rezultate până la finalizare, fără prea multă îngrijorare cu privire la dimensiunea lor. Cu toate acestea, trebuie să evalueze în funcție de capacitatea de planificare PI, fiecare echipă trebuie să aibă viteza lor într-o manieră consecventă pentru a putea prognoza.
Pentru a estima lucruri mai mari, deoarece dezvoltarea unui tren de lansare Agile are nevoie de cunoștințe de estimare, echipele Kanban sparge o inițiativă mai mare în povestiri pentru estimare, la fel ca și Scrum. Povestirile sunt apoi estimate în puncte de poveste. În acest mod, programul poate agrega estimări din diferite echipe..
Informatii de process
Metrici
Valorile la nivel de echipă pot fi vizibile ca imagine completă din formatul de lansare în cadrul măsurătorilor programelor (raportul progresului caracteristic, programul board-ului de Kanban, măsura de predictibilitate a programului etc.).În cadrul acestei secțiuni vom discuta despre Diagrama PI Burn-down, Diagrama cumulativă a fluxului, Metricile de iterare, Raportul de performanță al echipei PI, Autoevaluarea echipei)
Diagrama PI Burn-down
Această diagramă arată progresul spre caseta de timp a incrementului programului. Acesta este folosit pentru a urmări lucrările planificate pentru un PI împotriva lucrărilor care au fost acceptate. Graficul conține următoarele informații: axa orizontală – iterații în interiorul PI, axa verticală – cantitatea de lucru (în punctele de poveste) rămasă la începutul fiecărei iterații.
Figura 4.3 Diagrama PI Burn-down
Figura 4.4 Diagrama fluxului cumulativ
Această diagramă este realizată dintr-o serie de linii care reprezintă cantitatea de lucru în diferite stări. Diagrama poate fi făcută utilizând starea zilnică sau așa cum se vede mai jos în intervalul de 2 săptămâni. Dacă la nivel de program există un plan pentru punctele de poveste livrate, poate fi vizibilă diferența reală față de planificată.
Metrici de iterare
La sfârșitul fiecărei iterații, fiecare echipă Agile colectează metricile de iterare pe care le-au convenit. Aceasta se întâmplă în partea cantitativă a retrospectivei.
Figura 4.5 Diagrama de viteza a echipei (Velocity)
Viteza echipei arată valoarea cumulata (suma punctelor pentru toate poveștile realizate) livrata în fiecare iterație. Este util în timpul planificării iterației să ajute echipele să decidă câte povestiri se pot angaja. O altă cifră care poate fi retrasă aici este procentul de povești acceptate: numărul de puncte de poveste planificate / numărul de puncte acceptate. Viteza poate fi utilizată pentru a estima cât timp este nevoie pentru a furniza epopee mai mari, caracteristici, capabilități și facilitatori care sunt estimate în punctele de poveste.
Diagrama Burndown
Figura 4.6 Diagrama Burndown
Graficul Burndown este o reprezentare grafică care arată valoarea reală și estimată a muncii care trebuie făcută într-o iterație. Axa X indică timpul, axa y indică lucrul în punctele de poveste. Linia de linii directoare / trend este o linie descendentă distribuită uniform, în timp ce linia roșie indică tendința echipei față de obiectivul iterației, valoarea rămasă va scădea odată ce poveștile vor fi mutate.
Raportul PI de performanta al echipei
În timpul demonstrației sistemului PI, proprietarii de afaceri, clienții, echipele Agile și părțile interesate cheie evaluează valoarea reală a afacerilor realizată pentru obiectivul PI al fiecărei echipe.Totalul planificat nu include obiectivele de întindere pentru a ajuta la fiabilitatea trenului, în timp ce Totalul real include obiectivele de întindere.Procentajul de realizare este calculat Total efectiv / Total planificat. Efortul necesar pentru obiectivele de întindere este inclus în planul de iterare (adică nu este considerat muncă de week-end ca obiective de întindere).
Figura 4.7 Story points
Planificat total în exemplul de mai sus este de 32 de puncte, totalul real este de 38,5 puncte ("*" marchează elementele adăugate în Iteration Backlog după începerea iterării). Procentajul de realizare este de 120%.
Auto evaluarea echipei
Figura 4.8 Schema evaluare
Pentru a autoevalua și a îmbunătăți procesul, echipa completează o foaie de lucru care abordează următoarele subiecte: disponibilitatea planificării, evenimentul de planificare a lansării, execuția PI, rezultatele PI, implicarea părților interesate. Pe baza punctajului, echipa poate identifica punctele tari și punctele slabe în care este posibilă o îmbunătățire. Ieșirea este o diagramă a radarului ca în exemplul de mai jos.
Roluri
Proprietarul de produse este membru al echipei Agile, care acționează ca proxy client și lucrează cu Managementul produselor și alte părți interesate pentru a defini și prioritiza Poveștile din Team Backlog pentru a respecta prioritățile programelor (Features / Enablers). În mod ideal, Proprietarul de Produse este colocat cu restul echipei.
Scrum Master este un rol special care petrece mult timp ajutând alți membri ai echipei să comunice, să coordoneze și să coopereze, ajută echipa să-și îndeplinească obiectivele de livrare.
Scrum Master este un lider servitor care ajută echipele să se autoreglează, să se autogestioneze și să realizeze prin practici Agile. Poate fi un rol cu normă întreagă sau cu normă întreagă, în funcție de dimensiunea echipei, context și responsabilități. Acesta poate fi asumat de către un membru al echipei Agile, manager de proiect, lider de echipă sau alt individ. Scrum Master Scrum se bazează în mare măsură pe standardul Scrum, cele mai multe echipe Agile – de asemenea, cele bazate pe flux (aplicația Kanban) utilizează acest rol pentru a ajuta echipa să-și atingă obiectivele și să coordoneze activitățile cu alte echipe.
Agile Team este un grup inter-funcțional, care are abilitatea și autoritatea de a defini, construi și testa valorile soluției într-un timp scurt de timp pentru iterație. Echipa include indivizii necesari pentru a furniza cu succes valoarea, susținută de specialiști la nivel de program sau nivel de valoare, acolo unde este cazul. Echipa nu este o unitate autonomă, ci este integrată în trenul de livrare Agile, unde are responsabilitatea de a oferi o valoare mai mare. Nici un tren nu există fără echipele sale. Echipele și trenurile sunt inseparabile. Echipele dezvoltă software, hardware, firmware și o combinație generală, putem observa că echipa reprezintă o colaborare de disciplină necesară pentru a furniza funcții. Echipa determină ce și cum să-și construiască caracteristicile și componentele.
Fiecare membru al echipei este dedicat în totalitate unei singure echipe. Relația în cadrul echipei se bazează pe încredere, iar încrederea este facilitată de misiunea comună, obiectivele iteraționale comune și obiectivele echipei PI.
Echipele Agile pot să-și regleze procesul de la un continuum de metode, prin alegerea celor mai bune practici de la Scrum, Kanban, XP și multe altele. Cele mai multe echipe aplică Scrum ca un cadru de bază de management al proiectelor și de livrare. Atunci când elementele de planificare și de angajament ale Scrum nu se pot aplica la fel de eficient pentru activitate și unde prioritățile se schimbă mai frecvent, echipa Agile va aplica Kanban ca practică de bază.
Tabelul 4.1 Responsabilitatile rolurilor Agile
Tabelul 4.2 Artefacte Agile
Tabelul 4.3 Detalii ceremonii Agile
Tabelul 4.4 Tool-uri utilizate
Accentuarea factorului de Calitate in cadrul procesului
Calitatea începe la nivel de cod și componente si se realizeaza de cei care creează soluții. Mai târziu este dificil sau imposibil să se asigure calitatea, deoarece soluția se integrează și se scaldează la sistem și soluție.Pentru a asigura calitatea în cod și componente, practicile de inginerie și de calitate sunt:
Tabelul 4.5 Practici necesare de calitate
Nivel Proiect
Definition of Ready (DoR)
Definition of Ready definește criteriile de intrare pentru o regula de domeniu. Dacă unul dintre criteriile DoR nu este îndeplinit, atunci elementul asociat nu va fi luat în considerare la repetarea lunară următoare.
Figura 4.9 Schema DoR
Tabelul 4.6 Definition of ready la nivel de proiect
Definition of Done (DoD)
Definition of "Done" definește criteriile de acceptare pentru o revizuire a domeniului. Dacă unul dintre criteriile DoD nu este îndeplinit, atunci elementul asociat nu este acceptat. În acest caz, elementul este raportat ca nefiind în regulă și este nevoie de reprocesare.
Figura 4.10 Schema DoD
Este important să adăugăm și CR-urile care au fost adăugate în cadrul unui ciclu de dezvoltare în implementare și livrate.Este esențial ca acest lucru să nu se limiteze la domeniul de aplicare definit inițial, ci la tot ceea ce este oferit.
Tabelul 4.6 Definition of done la nivel de proiect
Nivel de echipa
Definition of Ready
Definiția Ready (FoR) reprezintă toate condițiile necesare pentru:
poveste a utilizatorului care trebuie dezvoltată în actuala sprint -> Metode Scrum
un articol de lucru care va fi introdus în Team Backlog -> metoda Kanban
Aceste condiții din DOR sunt definite prin discuții între echipă, proprietarul produsului (PO) și AgileMaster.
Definition of ready (DoR)
ar trebui să aibă o cotă în care toată echipa să aibă acces
ar trebui să fie integrate în politica echipei
ar trebui să fie revizuite de către PO / Agile Master și QA
Pentru fiecare tip de emisiune trebuie să fie descrisă o definiție clară a gata (FoR).
Tabelul 4.8 Definition of ready la nivel de echipa
Definition of Done
Definiția Done (DoD) constă în lista criteriilor care trebuie îndeplinite înainte produsul sa creasca, CR / PR sau orice alte activități care nu sunt legate de CS să fie considerate "realizate". Criteriile din DoD sunt definite de echipa împreună cu proprietarul produsului (PO), inginer de calitate (QA).Definiția "Done" este folosit pentru a accepta sau a respinge rezultatele obtinute la nivel de echipă în timpul creșterii produsului.
Definiția Done (DoD)
ar trebui să fie pe un loc unde toți membrii echipei au acces.
ar trebui să fie integrate în politica echipei
ar trebui să fie revizuite de către PO / Agile Master și QA
Tabelul 4.8 Definition of done la nivel de echipa
Stabilirea unei directii de control al modelului de dezvoltare
Probleme identificate
Gandirea si cunostinte Agile
Maestrii Agile:
fără a participa la o formare Agile
lipsa de cunoștințe privind abilitățile de facilitare
lipsa experienței de a vedea oameni experimentați care lucrează în acest rol
lipsa alocării pentru acest rol și necunoastera limitelor acestui rol
Interacțiunea cu alte roluri din poziția unui Maestru Agil
Proprietari de produse:
care nu au experiență / cursuri specifice pentru rol
provocat în manipularea lumii tradiționale și a noului mod de lucru (schimbarea priorităților, noi subiecte introduse în sprint)
stil de conducere și de control încă prezent
Echipa
modul în care putem organiza să facem mai bine, să obținem rezultate mai bune- au dorința de îmbunătățire nu au curajul de a acționa și de a rupe barierele
Managementul:
nu participă la un curs de formare agil
Metode si tool-uri Agile
Metoda / practicile agile utilizate nu alternează pe cele corecte cu contextul proiectului
Metoda Agile (de exemplu, Scrum) suferă prea multă adaptare. Experiența creată este pentru un proces adaptat. O cultura falsa a ceea ce este metoda si ce implica poate fi creata.
De exemplu, domeniul nu este stabil, prin urmare planificarea Sprint nu sa făcut în conformitate cu principiul Scrum, Sprint Review nu a fost în vigoare, diagrama Sprint Burndown și viteza echipei nu au date fiabile.
DoD si DoR dispărută, nu mai este clară. Fiecare membru al echipei știe acest lucru, dar poate că există înțelegeri diferite.
Definiția "Done" nu trebuie să conțină numai criterii de calitate.
Standup-ul zilnic în care oamenii vin rapid, împărtășesc informațiile și părăsesc.
Măsurătorile agile nu sunt înțelese și nu analizează suficient în căutarea și identificarea pentru probleme și îmbunătățiri
2 instrumente folosite pentru urmărire și vizualizare (JIRA & CS) – munca dubla și reticență ca trebuie folosite
Nu există posibilitatea de a comuta între SCRUM și Kanban rapid fără a implica suportul instrumentelor și disponibilitatea acestora
Cererea de echipă privind crearea unui proiect JIRA durează foarte mult
Rezolvarea / solicitarea problemelor nu se face întotdeauna la timp.
Pentru echipe distribuite, infrastructura nu suportă individualitatea și interacțiunea așa cum ar trebui.
Recomandari
Procese
Asigurați conformitatea metodelor de dezvoltare Agile cu SPICE pentru automobile
Integrați metodele de dezvoltare agilă în Landscape Process Continental și implicați organizarea procesului Continental
Lant de unelte
Optimizarea instrumentului JIRA sau suportul instrumentului pentru a fi mai eficient și în timp
Decizie pentru un singur instrument (Jira) – decizie luată pentru OIP 2.0
Simplificați configurația JIRA pentru echipele existente, definiți reguli pentru echipe noi
Integrați mai bine instrumentele pentru a sprijini mai bine agilitatea (de exemplu, automatizarea procesului de revizuire, managementul proiectelor în JIRA (inclusiv add-on-urile JIRA), în special la nivel de proiect.
Persoane și managementul abilităților
Incurajare a mentalitati Agile, echipa, proiectul, segmentele, managementul (de exemplu, trageți în loc de Push, autoorganizare)
Continuați instruirea și coaching-ul al Agile Master-ului, proprietarii de produse, Managementul
Implementați comunitatea de practici / Scrum de Scrums pentru schimbul de cunoștințe
Instalați antrenorii Agile pentru fiecare locație, nominalizați un coordonator Agile
Lucrați pe conceptul pentru echipele Agile cum să vă gândiți să creșteți abilitățile tehnice, în special pentru noii oameni atunci când crește organizația
Lipseste o persoană pentru a media atunci când Lumea Agile și lumea tradițională nu se potrivește
Introduceți agilitatea la nivel de proiect
Îmbunătățirea metodelor Agile (Scrum, Kanban) la nivel de echipă
Îmbunătățirea estimarii elementelor (de exemplu, eliminați tampoanele), creați un mediu pentru a utiliza predictibilitatea
Acceptați metoda de prioritizare a backlog-ului (de exemplu, valoarea și dimensiunea afacerii)
Îmbunătățirea rafinării backlog-ului (grooming): descompunerea, estimarea și prioritizarea elementelor – împreună cu echipa
Incurajarea experimentelor (bazate pe rezultate retrospective) pentru a obține rezultate mai bune ca echipa si proiect
Împuterniciți echipele și creați o cultură a încrederii (comanda și controlul este stilul de conducere cel mai dominant folosit)
Etape de urmat
Figura 4.11 Plan dezvoltare Agile 2017-2018
Program de evaluare Agile
Scop: Periodic la 6 luni, un program de Evaluare Agile trebuie condus de Agile
Coaches / Trainer / QA în toate BU-urile pentru a vizualiza si incuraja transformarea procesului într-un mod de lucru cat mai agil. Obiectivele acestui program pentru evaluator vor fi:
să evalueze implementarea efectivă a ceremoniilor Agile
identificarea abaterilor de la implementarea planificată și de la practicile Agile
identificarea modalităților de îmbunătățire a eficienței modului de lucru
Evaluarea și feedback-ul sunt date pe baza observațiilor prin:
participarea la standup zilnic (cel puțin de 2 ori)
interviu cu maestrul Agile (durata 1 h)
interviu cu proprietarul produsului (durata 1h)
participarea la întâlnirile de grooming, planificarea de Sprint, review si retrospectivă.
Beneficiile programului de evaluare Agile pentru echipele și proiectele agile va consta în:
identificarea factorilor critici de succes, oportunități de îmbunătățire
recomandari privind agilitatea echipei și metoda implementată Agile
identificarea elementelor necesare susținerii migrației echipei către agilitate
să identifice barierele și riscurile care ar putea avea impact și să încetinească echipele și proiectul și ce practici Agile ar putea să le evite
Fiecare echipă va primi un raport complet/ feedback cu informațiile/ recomandările pentru a spori agilitatea echipei. Acest program va fi urmarit si coordonat astfel incat sa ne apropieam de un stadiu ideal de dezvoltare Agile.
Figura 4.12 Stadiul actual si stadiul ideal al Metodologiei Agile
Figura 4.13 Framework Agile Ideal
Obiectiv pentru viitor: Scopul acestui program este acela ca toate echipele sa poata realiza o planificare impreuna (in Planificarea PI), sa integreze, sa faca demo, sa invate impreuna si sa aibe un program cu implicare comuna intr-un proiect de sine statator si bine stabilit, in care valoarea sta in indivizi si modul lor de organizare proprie.
Concluzii
Datorita filozofiei sale, tehnicile agile se muleaza perfect pe companiile mici. Marea provocare o reprezeinta aplicarea sa la nivelul unei companii mari. Statisticile spun ca aproximativ 2000 de companii ca si IBM folosesc cu succes metoda agila. Datorita scalabilitatii proiectelor, companiile mari nu isi permit luxul de a folosi practici dezordonate. De altfel, implementarea metodelor agile tin foarte mult de specificul companiei, si de timpul alocat etapelor de dezvoltare, cum ar fi documentarea. O alta problema majora pentru pentru multinationale devine dificil sa organizeze intalniri si conferinte asa cum specifica Agile Manifesto.
In anumite situatii, se ajung la compromisuri si astfel se formeaza o metoda hibrida, care pastreaza in mare ideologia agila. Chiar daca dimensiunea proiectelor difera foarte mult de la IMM-uri la corporatii, fapt ce impiedica lucrul in echipa de dimensiuni reduse, Agile porneste de obicei in jurul proiectelor mari, cu o sponsorizare mare din partea clientului solicitant. Probleme exista de partea ambelor tabere, dar solutia companiilor mari a fost scalarea recomandarilor agile dupa propriile nevoie. Astfel, exista echipe cu mai mult de 10 persoane, aflate chiar in locatii diferite.
Conform unui studiu realizate s-a constatat ca doar 26% din intervievati folosesc exclusivi metode agile, 14% utilizeaza asa-zisele hibride. De asemenea, 27% au sustinut ca tehnicile agile intervin doar in proiectele in care este posbila sau este necesara implementarea lor. Astfel, se poate trage o concluzie ca aceste principii nu reprezinta o ideologica generala a unei companii, ci doar un mod de lucru si colaborare in anumite circumstante.
Companiile mare agreeaza conceptele agile de viteza si aliniere cu afacerea, dar exista si cazul aplicatiilor critice care au specificatii unice. Astfel, modificarile din mers nu pot fi efectuate fara un studiu in prealabil deoarece exista un plan care trebuie urmat cu strictete. De altfell, nu toate departamentele trebuie sa 100% agile, existant zone unde nu pot fi implementate concepte de auto-organizare.
Curtis Hibbs, inginer sef la Boeing Defense, Space & Security, unde exista cei mai multi dezvoltatori software de la Boeing declara : "Unele programe sunt destul de mari și scalarea intră în joc în aceste cazuri. Dar avem de a face mai ales cu punerea în aplicare de echipe Agile individuale sau doar scalarea la o mână de echipe." In cazul IBM, 70-80 % din dezvoltare este agila, in special in randul proiectelor mici sau la cele nou incepute. Pentru proiectele vechi, unde exista deja o baza mare de clienti inca se foloseste dezvoltarea iterativa. Motivul principal pentru aceasta problema este numarul foarte mare de utilizatori si implicit perioada de validare a produsului care intarzie ciclul de dezvoltare.
Nu este un set de cele mai bune practici agile care se potriveste tuturor echipelor de dezvoltare. In practica s-au definit trei cazuri de utilizare care dicteaza trei metode diferite priorități și metode. Echipele de dezvoltare a cazut in trei categorii:
"Major Release Developers" lucreaza pe client-server și produse instalate la nivel local, cu release-uri la fiecare trei sau până la șase luni
"Cloud Application Developers" construiesc aplicații web-based, care sunt actualizate frecvent, chiar si de mai multe ori pe zi.
"Multi-Project Developers" lucreaza la mai multe proiecte concurente pentru mai multi clienții
Exista unui numar mare de locatii, uneori chiar si pe continente diferite a reprezentat a pus la indoiala utilizarea regulilor agile. In urma aceluias sondaj mentionat anterior s-a constatat ca marile companii din industria IT au o raspandire foarte mare: Numărul de companii cu personal de dezvoltare în:
7 + locații: 27%
3-5 locuri: 55%
1 Locul de amplasare: 18%
Aproape toate aceste companii, de asemenea, au angajați care lucrează la domiciliu, persoane fizice, și partenerii de afaceri virtuale de la mai multe locații. Aici principiul interactiunii in detrimentul tehnologiei nu poate fi aplicat cu succes, iar folosirea post-it-urilor nu poate fi realizata in varianta reala. De asemenea, numărul companiilor care folosesc SCRUM este:
55%: tehnici de "scrumish" exclusiv Scrum sau
Scrum și Kanban sau tehnicile Lean: 36%
Exclusiv Kanban sau tehnicile Lean: 9%
Companiile încorporează conceptele Lean în procesele lor de Scrum. Aceasta lasa loc în planul de sprint de sarcini noi in ultimul minut. Aceste practici reduc o parte din inflexibilitatea pur Scrum, păstrând în același timp avantaje, cum ar fi ce comunicate definit la intervale regulate.
Poate că cea mai mare provocare în extinderea proiectelor agile este coordonarea echipelor și gestionarea dependențelor dintre echipe. Ca proiectele să crească, grupurile de dezvoltare recurg la runde din ce în ce mai complicate și consumatoare de timp, de întâlniri și apeluri. Acest lucru este în mod clar un subiect care necesita noi solutii si idei de inspiratie noua.
Avantaje
Satisfacerea clientilor prin livrare rapida, continua de produse software. Clienti sunt incurajati sa semnaleze probleme si sa ofere noi idei ce urmeaza a fi implementate de echipele de dezvoltare. Acest lucru devine un avantaj si mai important in cazul proiectelor by-request, atunci cand clientul care sponsorizeaza doreste sa vada un progresul rapid al cerintelor sale.
Oamenii si interactiunile, inaintea proceselor si instrumentelor. In acest mod, dezvoltatori, clientii si testeri interactioneaza constant, comunicarea fiind esentiala in gasirea de solutii optime la probleme.
Este adaptiv. Cum a fost mentionat in subcapitolul anterior, metodele agile pot fi utilizate atat de companii mici, cat si de firme mari, iar in ambele cazuri rezultatele au fost pozitive. Un alt lucru bun al acestui aspect tine de dezvoltarea produsului, astfel schimbarile aparute din cauza unor greseli de proiectare, sau mai mult, solutii noi, optime in detrimentul planului pot aduce schimbari in cursul dezvoltarii fara a creea mari probleme.
Pune in legatura directa dezvoltatorii si oamenii de afaceri. Pe langa beneficiile directe aduse in dezvoltarea produsului, aceasta cooperare aduce avantaje si pe termen lung, fiind un schimb important de experienta. Astfel programatorii se acomodeaza cu cerintele si modul de lucru din mediul de afaceri, in schimb oamenii de afaceri primesc o educatie tehnica din care nu au decat de castigat pe termen lung.
Dezavantaje
In cazul proiectelor da mari dimensiuni este aproape imposibil sa definesti efortul necesar pentru task-urile din initierea proiectului, faza in care sunt necasare foarte multe aspecte de implementate si nu exista o forma clara prin care sa se poate defineasca timpul necesar executiei unui anumit task.
Nu se pune accentul pe proiectare si documentare. Acest lucru poate fi un impediment pentru proiectele de scara mare, dar si pentru cele dedicate unui anumit domeniu de activitate, necunoscut in precedent echipei de dezvoltare. Astfel se pot pierde multe aspecte esentiale, iar implementarea poate avea de suferit. Adaptivitatea si stransa legatura persoanele interesate de produs pot veni in compensarea acestui punct slab.
Produsul poate iesi usor din parametrii initial daca reprezentantul clientilor nu specifica foarte clar care trebuie sa fie forma finala a produsului, sau daca este slab pregatita si nu cunoaste exact specificatiile pe care le asteapta de la produsul software comandat.
Doar programatorii seniori sunt capabili sa ia decizii majore in timpul procesului de dezvoltare. Acesta reprezinta si unul dintre motivele limitarii numarului de persoane intr-o echipa, cum majoritatea companiilor prefera sa aiba angajati din toate nivelele de experienta, este greu ca un junior sa poata avea acelasi randament ca un senior si aceeasi luciditate in momentele in care trebuie luata o decizie majora.
Nu exista un model perfect pentru a creste productivitatea si calitatea. Ideologia Agile este una dintre solutiile optime, care poate aduce schimbari majore in cadrul unei intreprinderi.
Este recomandat sa fie aplicat in urmatoarele cazuri :
Atunci când sunt necesare noi modificări pentru a fi puse în aplicare. Este foarte importanta libertatea oferita de a schimba. Modificările noi pot fi implementate la costuri foarte mici, din cauza frecvenței mare cu care versiunile sunt lansate.
Pentru a putea modifica o facilitate, dezvoltatori sunt fortati sa renunta doar la munca desfasurata in ultimele zile, maxim saptamani pentru a putea reveni la un punct unde sa poate implementa noua solutie.
Spre deosebire de modelul waterfall, în model de Agile este nevoie de o planificare foarte limitata pentru a începe cu proiectul. Agile presupune că nevoile utilizatorilor sunt în continuă schimbare, într-o afacere dinamică din lumea IT. Modificările pot fi discutate și facilitatile pot fi imbunatatite sau eliminate în funcție de feedback-ul primit de la utilizatori. Acest lucru ofera clientului sistemul finit de care are nevoie.
Atât dezvoltatorii și actionarii, descopera faptul ca au mai multă libertate de timp și opțiuni decât în cazul în care software-ul a fost dezvoltat într-un mod secvențial mai rigid. Opțiunile le oferă posibilitatea de a lăsa deciziile importante până sunt sunt suficiente date sau chiar programe întregi de hosting, ceea ce înseamnă că proiectul poate continua să avanseze, fără teama de a ajunge la un impas brusc.
Rezumat
Mobilitatea persoanelor, precum și deținerea și răspândirea informațiilor au devenit elementele esențiale în evoluția societății. În consecință, dezvoltarea sistemelor de radio-navigație a devenit o necesitate, fiind un mediu care reușește să îmbine latura mobilă cu cea a informațiilor. Ultimele evoluții ale sistemelor de radio-navigație au prezentat elementele integrative și de conectivitate cu
sisteme externe automobilului, mai concret telefoanele inteligente sau componente IT.
Modificarea cerințelor în proiectele automotive precum și constrângerile de timp ale integrării acestora pe parcursul derulării proiectului au definit tema actuală de cercetare.
Lucrarea este structurata in 4 capitole care au ca scopul principal identificarea soluțiile practice pentru problemele de organizare și desfășurare ale proiectelor din domeniul automotive. Utilizarea modelelor tradiționale de dezvoltare nu permit implementarea ulterioară a specificațiilor. Prima măsură luată de coordonatorii de proiect pentru atingerea obiectivelor proiectului este reducerea conținutului acestuia. Chiar dacă în prima fază această măsură face ca obiectivele imediat următoare să poată fi atinse, aceasta generează costuri suplimentare companiilor prin necesitatea continuării sau creării de noi proiecte care să „completeze” vechile proiecte cu cerințele încă neimplementate. Aceste argumente au dus la definirea obiectivului principal al lucrariii, și anume, prezentarea modalităților de exploatare corectă a resursei de timp, obiectiv concretizat prin crearea unui nou model de dezvoltare, care să fie flexibil la schimbări și care să corespundă cererilor industriei automotive.
Contextul actual de dezvoltare al produselor impune obiective foarte precise: termene de lansare scurte, costuri de dezvoltare și producție reduse și asigurarea unui nivel ridicat al calității, siguranței și securității produselor. Odată cu trecerea timpului, proiectele au devenit din ce în e mai complexe, datorită strategiei constructorilor de automobile de a reduce numărul de arhitecturi și de a crește numărul de modele și opțiuni.
Ca rezultat la această tendință, componentele realizate de furnizori sunt comune, ușor de configurat și adaptat la diversele cerințe ale clienților, permițând o producție de masă personalizată (mass customization/individualization). Aceasta duce însă la creșterea conținutului de componente electronice și software în automobile, ceea ce face ca proiectele să fie mai complicate și mai complexe în procesul de dezvoltare și producție.
Obiectivul principal al lucrarii de licenta îl constituie analiza și rezolvarea unor probleme actuale și extrem de sensibile legate de calitatea unui proiect de dezvoltare de produs, în vederea îmbunătățirii acesteia.
Obiectivele secundare, care derivă din acest obiectiv principal, sunt:
eficientizarea și îmbunătățirea analizei cerințelor de calitate;
îmbunătățirea analizei riscurilor în faza de concept a produsului;
îmbunătățirea acțiunilor corective în cazul reclamațiilor de calitate.
Concluziile menționează că cercetarea s-a finalizat prin elaborarea de modele noi în managementul calității proiectului și aplicarea conceptelor noi în dezvoltarea de proiecte din cadrul unei companii din industria automotive.
Se consideră astfel că obiectivul principal al cercetării, de a îmbunătăți calitatea proiectelor de dezvoltare de produs, și obiectivele secundare, de îmbunătățirea metodelor folosite in diferite faze ale proiectului, eficientizarea și îmbunătățirea analizei cerințelor de calitate, îmbunătățirea analizei riscurilor în faza de concept a produsului, respectiv îmbunătățirea acțiunilor corective în cazul reclamațiilor de calitate, au fost îndeplinite.
SUMMARY
The mobility of people, as well as the possession and dissemination of information have become the essential elements in the evolution of society. Consequently, the development of radio navigation systems has become a necessity, being an environment that manages to combine the mobile side with that of information. Latest developments of radio navigation systems have shown integrative and connectivity elements with car exterior systems, more specifically smart phones or IT components.Changing requirements in automotive projects as well as the time constraints of their integration during the course of the project have defined the current research theme.
The paper is structured in 4 chapters which aim to identify the practical solutions for the organizational and development problems of the automotive projects. The use of traditional development models does not allow subsequent implementation of specifications. The first measure taken by project coordinators to achieve project goals is to reduce the content of the project. Even if in the first phase this measure ensures the immediate objectives to be achieved, it generates additional costs for companies by the need to continue or to create new projects to "complete" the old projects with the still unimplemented requirements. These arguments have led to the definition of the main objective of the paper, namely the presentation of the correct way of exploiting the time resource, the objective of which is to create a new development model that is flexible to change and which meets the demands of the automotive industry.
The current product development context requires very precise objectives: short delivery times, low development and production costs, and a high level of product quality, safety and security. With the passage of time, projects have become more and more complex due to the strategy of car manufacturers to reduce the number of architectures and increase the number of models and options.
As a result of this trend, the components made by suppliers are common, easy to configure and adapted to different customer requirements, allowing for mass customization / individualization. This, however, increases the content of electronic components and software in cars, which makes the projects more complicated and complex in the development and production process.
The main objective of the license is to analyze and solve current and extremely sensitive issues related to the quality of a product development project in order to improve it.
The secondary objectives, which derive from this main objective, are:
streamlining and improving the analysis of quality requirements;
Improving risk analysis in the product concept phase;
improving corrective actions in case of quality complaints.
The findings conclude that the research was completed by developing new models in project quality management and application of new concepts in the development of projects within an automotive industry.
It is considered that the main objective of the research, to improve the quality of product development projects, and the secondary objectives, to improve the methods used in different phases of the project, to improve the analysis of quality requirements, to improve the risk analysis in the product concept phase , respectively improving the corrective actions in the case of quality complaints, all have been fulfilled.
Contribuțiile personale ale autorului
Sinteza fazelor reprezentative proiectelor în general, cu particularizări în proiectele automotive;
Participarea activa la propunerea de dezvoltare Agile in cadrul corporatiei Continental;
Aport la definirea criteriilor importante din punct de vedere al Automotive Spice si metodologiei Agile.
Stabilirea critetiilor importante pentru un DOD si DOR la nivel de echipa resectiv de proiect;
Implicarea la crearea pogramului de mentinere si dezvoltare a metodelor Agile din cadrul departamentului de radio-navigatie.
Sinteza factorilor critici reprezentativi proiectelor, pe baza unei analize comparative din literatura de specialitate;
Descrierea factorilor critici reprezentativi proiectele automotive, precum și prezentarea factorilor critici specifici proiectelor automotive.
Identificarea unui nou factor critic reprezentativ proiectelor automotive, mai concret acela al produsului inovativ, care începe să aibă o pondere prioritară față de cei clasici, considerați până acum ca reper absolut: timp, cost și calitate.
Analizarea caracteristicilor principale ale metodelor tradiționale de dezvoltare a proiectelor.
Analiza principalelor metodologii AGILE care vin să elimine slăbiciuni ale metodelor tradiționale.
Justificarea utilizării modelelor de dezvoltare în V în proiectele software din domeniul automotive.
Analiza și sinteza comparativă între procesele de dezvoltare tradiționale vs. metodologiile AGILE.
Analiza și sinteza comparativă între efectele modificării cerințelor în funcție de stadiul de dezvoltare a proiectului.
Prezentarea impactului modificărilor asupra calendarului proiectului.
Identificarea necesității dezvoltării unui nou model de dezvoltare specific proiectelor de tip automotive de mari dimensiuni.
Analiza și descrierea concluziilor literaturii de specialitate legate de stabilitatea cerințelor în proiectele software.
Conceperea unei metode de decizie bazată pe implementarea cerințelor noi sau modificate în dezvoltarea proiectelor de tip automotive;
Analiza proceselor de dezvoltare automotive și influența proceselor de producție asupra acestora;
Analiza și elaborarea factorilor care determină implementarea cerințelor noi;
Configurarea unui nou model de dezvoltare, flexibil la schimbări, cu scopul de atenuare a efectului schimbării cerințelor în dezvoltarea proiectelor de tip automotive;
Sinteza criteriilor pe care trebuie să le îndeplinească un model de dezvoltare software.
Culegerea informațiilor și datelor necesare derulării proiectelor software de radio-navigație din firma A, respectiv firma V;
Analiza comparativă a modelelor tradiționale de dezvoltare și a modelului Agile din punct de vedere financiar și temporal;
Utilizarea modelului Agile va aduce economii companiilor pe termen mediu, datorită facilitării respectării duratei de finalizare a proiectelor în cazul apariției cerințelor de actualizare;
Prezentarea modului de distribuție a costurilor de dezvoltare a proiectelor;
Bibliografie
Goldratt, E. M., 2004, The Goal, the North River Press Publishing Corporation, Great Barrington.
Lawley, H.G., Operability studies and hazard analysis, Chemical Engineering Progress 70 (4), 1974
http://en.wikipedia.org/wiki/Agile_software_development#Philosophy
Scrum in Action Agile Software Project Management and Development – Pham – Course Tech (2012).pdf
http://agilemanifesto.org/
http://www.it-smc.com/Articles/Agile_Philosophy.pdf
www.wikipedia.com
www.extremeprogramming.org/
www.scrummethodology.com/
www.agilemanifesto.org
www.agilealliance.org
Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature)
enterprise-concept.com
Beck, Kent – Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Beck, Kent – (2001). "Manifesto for Agile Software Development". Agile Alliance
Peter Lappo; Henry C.T. Andrew. "Assessing Agility"
Implementing lean and AgIle Software development in industry, Kai Peterseon
Agile/Lean Product Development and Delivery – Mastering the Art of Change
www.agilemodeling.com
www.wikipedia.com
ww.computerweekly.com/
Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature)
OIP Project Plan
Agile in System Software
OIP_CR_PR_Management_Plan
KPI on project Level
FML process guideline
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Optimizarea managementului de proiect in industria Automotive (Project management optimization in the Automotive Industry) Notatii – Abrevieri OIP… [309075] (ID: 309075)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.