MP

Managementul Proiectelor
1

Elementele unui proiect
 Elementele de bază ale unui proiect
generic
 Scop
○ mărimea proiectului, sub-scopuri, cerinţe
 Resurse
○ oameni, echipament, materiale
 Timp
○ durata sarcinilor, sincronizarea lor
 Fonduri
○ costuri, urgenţe, profit
2

Triunghiul managementului de
proiect
 Modificarea unei
laturi le afectează și
Scop
pe celelalte
 Cele trei
constrângeri
concurează între ele
 Variantă: financiar,
timp, resurse umane
Cost Timp
3

Fazele unui proiect
 Inițiere
 Analiza tehnică și financiară
 Analiza cerințelor
 Planificare și design
 Prototip
 Testare și verificare contra cerințe
 Producție sau execuție
 Executarea planului
 Coordonarea resurselor
 Realizarea produsului final
 Monitorizare și control
 Măsurarea activităților contra plan
 Corecții, dacă este cazul
 Mentenanța proiectului
 Încheiere
 Finalizarea activităților
 Arhivarea documentelor și discutarea lecțiilor învățate
 Încheierea contractului
4

Fazele unui proiect
Planificare și
Inițiere
design
Producție Monitorizare
Încheiere
sau execuție și control
5

Pregătirea proiectului
1. Definirea scopului
 Ce trebuie realizat
 Ce nu trebuie realizat
2. Inventarierea resurselor disponibile
 Oameni, echipamente, fonduri
 “Matrix management” - raport la şef operațional şi şef funcţional
3. Verificarea timpului la dispoziție
 Termene limită
 Ore suplimentare versus buget
4. Alcătuirea echipei
 Adunarea experților
 Pornirea dialogului
5. Stabilirea pașilor principali
 Recomandat în ordine cronologică
 Se discută cu echipa
6

Pregătirea proiectului (cont.)
6. Stabilirea pașilor detaliați
 Recomandat în ordine cronologică
 Adâncimea depinde de complexitatea şi mărimea proiectului
7. Dezvoltarea unui plan preliminar
 Primul pas
 Următorul pas
 Care pași pot merge în paralel, cu resurse diferite
 Cine rezolvă care pas
 Cât va dura
8. Crearea planului principal
 Obținerea reacției despre planul preliminar
 Ajustarea planului preliminar până la o variantă mulțumitoare şi
realistă
9. Cererea ajustărilor pentru proiect
 Timpul, fondurile, oamenii sunt totdeauna insuficienți
 Trebuie cerute modificări acum, nu la sfârșit
7

Pregătirea proiectului (cont.)
10. Respectarea planului şi modificarea lui
 Echilibru între respectarea planului si modificarea lui
 Se ţine cont de scop şi resursele disponibile
11. Monitorizarea progresului
 La început, progresul este lent, dar merită monitorizat tot ce fac toți
 Rentabil, deoarece va prinde problemele mici, înainte să devină mari
12. Documentarea detaliilor
 Orice schimbare a planului se documentează: ce s-a schimbat şi de ce
 La cerințe noi: de unde a venit şi cum a afectat termenele şi bugetul
 Va fi util la auditul de la sfârșit şi va fi util pentru proiectele viitoare
13. Informarea tuturor
 Informarea beneficiarului despre progres (completarea pașilor şi
problemele întâmpinate)
 Informarea echipei (schimbări anunțate din timp; fiecare știe ce face
celălalt)
8

Metode de management ale
proiectelor
 Tradițională
 Calea critică (Critical Chain Project Management CCPM)
 Axată pe resurse
 Extremă (Extreme Project Management)
 Agile
 Extreme Programming XP
 SCRUM
 Lanțul evenimentelor (Event chain methodology)
 Axată pe evenimentele care pot afecta planul
 PRINCE2
 Bazat pe procese (Process-based management)
 CMMI
 SPICE
 Rational Unified Process RUP
 Dezvoltat de Rational Software / IBM
9

Unelte
 Unelte pentru managementul proiectelor
 Primavera
 Microsoft Project Professional
 Open Workbench
 dotProject
 OpenProj
 altele
 Unelte generale pentru colaborare
 Microsoft Exchange şi Outlook
 Google Docs şi Google Calendar
 altele
10

Managementul proiectelor
software
 Stiluri de programare
 Procedurală/modulară (Pascal, C)
 Obiectuală (C++, Java)
 Cu componente (Java Beans)
 Unelte pentru gestiunea versiunilor
software
 Microsoft Visual SourceSafe
 Microsoft Visual Studio Team Edition
 CVS
 SubVersion
11

Crearea documentației software
 JavaDoc
 PHPDocumentor
 DoxyGen
 DocBook
 Adobe PDF
 altele
12

Managementul proiectelor
1

Metoda tradițională
 Inițiere
 Analiza tehnică şi financiară
 Analiza cerinţelor
 Planificare sau design
 Prototip
 Testare şi verificare contra cerinţe
 Producție sau execuție
 Executarea planului
 Coordonarea resurselor
 Realizarea produsului final
 Monitorizare şi control
 Măsurarea activităților contra plan
 Corecții, dacă este cazul
 Mentenanța proiectului
 Încheiere
 Finalizarea activităților
 Arhivarea documentelor şi discutarea lecțiilor învățate
 Încheierea contractului
2

Metoda cascadă
 Variantă a metodei tradiționale
 O serie de pași succesivi, în secvență
liniară
 Tipic în arhitectură
 Foarte bun pentru proiecte bine definite
 Pașii tipici pentru rezolvare de probleme:
definirea problemei, identificarea
problemei, analiza opțiunilor, alegerea unei
căi, implementare și evaluare
3

Metoda căii critice
 “Critical Chain Project Management” - CCPM
 Axată pe resursele necesare execuției sarcinilor
 Scopul este creșterea ratei de completare a
proiectelor în organizație
 Se recomandă normalizarea resurselor (Resource
Leveling)
 Analiza utilizării inegale a resurselor
 Rezolvarea conflictelor de alocare a resurselor
 În cazul mai multor proiecte paralele, se recomandă
normalizarea globală a resurselor
 Calea critică este cel mai lung șir de sarcini cu
constrângeri de resurse
4

Metoda căii critice (cont.)
 Bazata pe teoria constrângerilor (Theory of Constraints),
pentru proiecte
 Eliminarea constrângerii poate fluidiza tot procesul
 Cei cinci pași de focalizare:
1. Identificarea constrângerii
2. Decizia exploatării constrângerii
3. Subordonarea tuturor proceselor, deciziei anterioare
4. Elevarea constrângerii
5. Dacă a apărut altă constrângere, reluare
 În CCPM, o resursă este aleasă constrângerea principală
 Sarcinile de pe calea critică primesc prioritate maximă
 Proiectele sunt gestionate astfel, încât sarcinile critice să
pornească de îndată ce resursele le sunt disponibile
 De obicei, este suficient să se aleagă o resursă (constrângere)
comună a proiectelor
5

Managementul proiectelor
1

Metoda extremă
 “Extreme Project Management”
 Metodele tradiționale sunt pentru
proiecte unice
 Proiectele de azi sunt dinamice, nu sunt
rentabile modele complexe pentru
proiect
 Se recomandă metode Agile (Extreme
Programming sau Scrum)
2

Metode Agile
 “Agile software development”
 Pentru dezvoltare software, dar nu
numai
 Încurajează verificări și adaptări
frecvente, lucrul în echipă
 Pași mici, planificare pe perioade scurte
 Ciclurile sunt tipic una-patru săptămâni
 Fiecare ciclu rezultă în produs (mai mult
sau mai puțin utilizabil)
3

Metode Agile (cont.)
 Se preferă comunicarea personală, nu cea
scrisă
 Fiecare echipă “agile” conține un membru
din partea clientului
 Agile Manifesto (2001), preferă:
 Persoane și interacțiuni, nu procese și unelte
 Software funcțional, nu documentație detaliată
 Colaborare cu clientul, nu negocierea
contractului
 Adaptare la schimbări, nu respectarea planului
4

Metode Agile (cont.)
 Metode adaptive
 Flexibile față de schimbările proiectului
 Plan detaliat pe o săptămână, facilități
planificate pe o lună, scopul principal pe un an
 Metode predictive
 Planifică viitorul în detaliu
 Facilități și pași planificați pe toată durata
proiectului
 Schimbarea este dificilă, poate cauza
renunțarea la părți completate ale proiectului
 Necesară comisie de control a schimbărilor
5

Metode Agile (cont.)
 Comparație cu metoda cascadă
 Metodele agile sunt adaptive, față de cele predictive
 Metoda cascadă este inflexibilă față de schimbări ale
cerințelor
 O parcurgere a pașilor cascadei este scumpă
 Agile produc rezultate testate, deși doar parțiale, la
fiecare câteva săptămâni
 Agile dau rezultate imediat prezentabile clientului
 Agile sunt greu de adaptat bugetelor și termenelor
impuse proiectului global
 Agile pot folosi metoda cascadă, la fiecare ciclu
parțial
6

Metode Agile (cont.)
 Comparatie cu “Cowboy Coding”
 “Cowboy Coding” este dezvoltare ad-hoc
 Metodele agile sunt flexibile, dar urmează
pași bine definiți
 Dacă metodele agile nu sunt urmărite strict,
poate rezulta “cowboy coding”
7

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
8

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
9

Agile Unified Process (AUP)
 Versiune simplificată al IBM Rational
Unified Process
 Discipline:
 Model
 Implementare
 Test
 Instalare
 Gestiunea versiunilor
 Gestiunea proiectului
 Mediul
10

Agile Unified Process (cont.)
 Filozofii:
 Echipa știe ce face
 Simplitate
 Agilitate
 Accent pe activitățile valoroase
 Independență de unelte
 Adaptarea metodei, propriilor necesități
 Două feluri de rezultate
 Rezultat de dezvoltare, pentru verificarea
calității sau demo
 Rezultat de producție, pentru Producție
11

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
12

Agile Data (AD)
 Axat pe date, în special baze de date
 Filozofii:
 Date
 Probleme ale organizației
 Grupuri ale organizației
 Unicitate
 Lucrul în echipă
 Găsirea echilibrului
13

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
14

Dynamic Systems Development
Method (DSDM)
 Dezvoltat in 1990 în UK
 Axat pe sisteme informatice
 Tratează cele mai importante motive de eșec:
 Buget
 Termene limită
 Lipsa de implicare a clientului
 Lipsa de interes a conducerii
 Faze:
 Pre-proiect
 Ciclul de viată al proiectului
1. Studiu de fezabilitate
2. Studiu de afaceri
3. Subfaza modelului funcțional
4. Subfaza de design și dezvoltare
5. Implementare
 Post-proiect
15

Dynamic Systems Development
Method (cont.)
 Principii:
 Implicarea clientului
 Echipa poate decide
 Predare frecventă
 Versiunile predate satisfac cerințe critice de
funcționalitate
 Dezvoltarea depinde de reacția clientului
 Toate schimbările de dezvoltare sunt reversibile
 Scopul principal și cerințele trebuie să fie clar
specificate de la început
 Testarea se face pe tot parcursul ciclului de viată al
proiectului
 Comunicare eficientă între părțile implicate
16

Dynamic Systems Development
Method (cont.)
 Presupuneri adiționale:
 Prima versiune niciodată nu este perfectă
○ regula 80/20 (Pareto) - 80% din beneficii vin din 20%
din cerințe
○ se începe cu implementarea acestor 20% de cerințe de
bază
○ dacă implementăm cele 20% cerințe importante, am
făcut 80% din proiect
 Predarea trebuie să fie la timp, în limita bugetului și
de calitate bună
 Fiecare pas de dezvoltare trebuie completat cât să
poată începe următorul
 Se integrează metode de gestiune proiecte și
dezvoltare
17

Dynamic Systems Development
Method (cont.)
 Presupuneri adiționale (cont.):
 DSDM se poate aplica proiectelor noi sau în
derulare
 Evaluarea riscului trebuie să se axeze pe
funcționalitatea cerută, nu dezvoltare sau
documentație
 Conducerea recompensează predarea, nu
completarea sarcinilor
 Estimarea se bazează pe funcționalitatea
cerută, nu cantitatea de cod sursă
18

Dynamic Systems Development
Method (cont.)
 Tehnici de bază:
 “Timeboxing”
 “MoSCoW”: Must, Should, Could, Would
 Prototipuri
 Testarea
 Discuții cu clientul
 Modelare
 Gestiunea configurației
19

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
20

Essential Unified Process
(EssUP)
 Îmbunătățire a metodei Rational Unified
Process
 S-a născut din observația că oamenii nu
citesc documentația detaliată a procesului
 Încurajează crearea unor informații
esențiale minime, despre proces, urmând
ca utilizatorul să citească și să învețe mai
multe, pe parcurs
 Identifică practici pe care le separă,
urmând să se aplice cele care sunt
adecvate procesului în discuție
21

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
22

Extreme Programming (XP)
 Dezvoltat în 1996-1999
 Adaptabilitate dusă la extrem
 Scop principal: reducerea costurilor schimbării
 Adaptarea la schimbări în cerințe este mai
bună decât fixarea cerințelor la început
 Dezvoltat pentru Chrysler Comprehensive
Compensation System (C3)
 Motivații
 reducerea ciclului de viată al produselor
 programarea obiectuală înlocuiește programarea
procedurală
23

Extreme Programming (cont.)
 Extreme Programming este
 O încercare de reconciliere între umanitate
și productivitate
 Un mecanism pentru schimbare socială
 O cale pentru îmbunătățire
 Un stil de dezvoltare
 O disciplină de dezvoltare software
24

Activitati XP
1. Scrierea codului
 Produsul principal al dezvoltării este codul
(diagrame UML care rezulta în executabil,
scripturi, cod sursă etc.)
 Teoretic, trebuie “codate” toate variantele și
aleasă soluția cea mai bună
 Pentru programatori, codul este mai clar
decât documentația
25

Activitati XP (cont.)
2. Testarea
 Nimic nu e sigur, dacă nu e testat
 Testarea nu este o necesitate primară pentru client;
multe aplicații sunt livrate fără testare suficientă
 Nu e sigur că ce ai scris în cod este ce ai vrut
○ Se folosește testare pe unități (“Unit Tests”) pentru a
verifica codul
○ Unitate - cea mai mică parte testabilă a aplicației
○ În programarea OO, cea mai mică unitate este metoda
 Nu e sigur că ce ai vrut e ceea ce trebuia să vrei
○ Teste de acceptare, eventual cu beneficiarul, începând
cu “smoke testing”
26

Activitati XP (cont.)
3. “Ascultarea”
○ Dezvoltatorii trebuie să înțeleagă cerințele
beneficiarului
○ Dezvoltatorii trebuie să-I ajute pe beneficiar să
înțeleagă ce vrea
4. Design-ul
○ Se poate crea soft și doar cu activitățile anterioare
○ La aplicații complexe, legăturile dintre module
devin neclare
○ O structură bună de design organizează logica din
sistem și elimină dependențele dintre module
27

Valori XP
 Comunicare
 Diseminarea rapidă a informațiilor în echipa de dezvoltare
 Desene simple, colaborare utilizatori-programatori, comunicație
verbala frecventă
 Simplitate
 Se pornește cu cea mai simplă soluție
 Ulterior, se adaugă funcții
 Se scrie cod pentru cerințele din prezent, nu viitor
 Dezavantaj: rescrieri, din cauza schimbărilor în cerințe
 Avantaj: nu se risipesc resurse pe cerințe viitoare variabile
 Reacție
 De la sistem, prin testare pe unități
 De la beneficiar, prin teste de acceptare
 De la echipă, la schimbări în cerințe
 “Optimismul este un hazard ocupațional al programării, reacția
este tratamentul.“ (Kent Beck)
28

Valori XP (cont.)
 Curaj
 Dezvoltarea pe termen scurt și reconstruirea
pentru cerințe schimbate
 Aruncarea codului inutil sau vechi
 Persistență în rezolvarea unei probleme în
programare
 Respect
 Față de colegi: nu modificări care fac codul
necompilabil sau să eșueze la testele unitare
 Față de produs: dezvoltarea unui produs de
calitate
29

Jocul de planificare
 “Planning Game”
 Odată per iterație, de obicei săptămânal
 Doi pași
 1. Planificarea versiunii
○ Care cerințe vor fi incluse în care versiuni parțiale
și când vor fi predate
○ Participă atât dezvoltatorii, cât și beneficiarul
○ Trei faze
 Explorare - se stabilesc cerințele critice, de obicei
câteva “user story” de 1-2 propoziții
 Angajament - funcționalitatea și data următoarei
versiuni
 Conducere - ajustarea planului și a cerințelor
30

Jocul de planificare (cont.)
 2. Planificarea iterației
○ Activitățile dezvoltatorilor
○ Beneficiarul nu participă
○ Trei faze
 Explorare - cerințele se traduc în sarcini
 Angajament - programatorii primesc sarcinile și se
estimează timpii necesari
 Conducere - sarcinile sunt îndeplinite și rezultatul se
compară cu cerințele critice stabilite la planificarea
versiunii
31

Probleme XP
 Cerințe instabile
 Conflicte cu și între utilizatori
 Cerințe exprimate ca teste de trecut, nu documente de
specificații
 Cerințele sunt exprimate incremental, nu în avans; costul
rescrierii codului poate fi mai mare decât avantajele libertății
 Un reprezentant al beneficiarului este atașat proiectului; poate
deveni o sursă de stres sau management incompetent
 Programatorii lucrează în perechi
 Unul e axat pe scrierea codului
 Celălalt gândește în ansamblu asupra problemei și verifică ce a scris
colegul
 Cei doi schimbă rolurile periodic
 Scalabilitate - XP merge bine pe echipe de 12 oameni sau mai
puțini
 XP nu e potrivit pentru orice proiect
32

Metode Agile (cont.)
 Metode dezvoltare software agile
 Agile Modeling
 Agile Unified Process (AUP)
 Agile Data Method
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Getting Real
 Open Unified Process (OpenUP)
 Scrum
33

Metoda Scrum
 Dezvoltat în ‘86 si ’91
 “scrum” - grămada de repornire din rugby
 Problema nu poate fi înțeleasă sau definită pe deplin
 Bazat pe practici și roluri predefinite
 “Sprint” - 2-4 săptămâni
 Rolurile “porc și găină”
 Porc
○ Proprietarul produsului
○ Managerul Scrum (“ScrumMaster”) sau Facilitator
○ Echipa
 Găina
○ Utilizatori
○ Acționari
○ Manageri
34

Ședințe Scrum
 Zilnică
 Întârzierea se pedepsește
 Doar “porcii” pot vorbi
 Maxim 20 minute
 În picioare
 În același loc și oră
 Membrii echipei răspund la:
○ Ce ai făcut ieri?
○ Ce vei face azi?
○ Ce probleme te opresc?
 Planificare sprint
 La începutul sprint-ului (fiecare 15-30 zile)
 Ce lucrări trebuie efectuate
 Maxim 8 ore
35

Ședințe Scrum (cont.)
 Examinare sprint (“review”)
 La sfârșitul sprint-ului
 Examinare lucrări efectuate sau nu
 Demo pentru acționari
 Lucrările incomplete nu se demonstrează
 Retrospectiva sprint
 La sfârșitul sprint-ului
 Toți membrii echipei reflectă asupra sprint-ului terminat
 Îmbunătățirea procesului
 Întrebări:
○ Ce a mers bine în sprint?
○ Ce se poate îmbunătăți în următorul sprint?
○ Maxim 3 ore
36

Produse secundare Scrum
 Jurnal produs
 Lista elementelor
 Ordonat în funcție de valoarea comercială a elementelor
 Este proprietatea Proprietarului de Produs
 Valoare în funcție de ROI (“Return Of Investment”)
 Jurnal sprint
 Detalierea metodelor de implementare
 Lista de sarcini (câte 4-16h)
 Sarcinile nu se dau; și le iau membrii echipei
 Este proprietatea Echipei
 Diagrama de progres
 Arată lucrul rămas de făcut
 Împrospătată zilnic
 Publică
37

Practici generale Scrum
 Clienții devin parte din echipa de
dezvoltare
 Predări frecvente de produs funcțional
 Gestiunea riscului rezolvată de echipa de
dezvoltare
 Transparență în planificare și dezvoltare
 Ședințe frecvente cu acționarii
 Mecanism de avertizare din timp
 Raportarea problemelor nu se penalizează
 Locul de munca și orele de lucru trebuie să
fie energice
38

Managementul proiectelor
1

Metoda PRINCE2
 “PRojects IN Controlled Environments”
 Dezvoltat în ‘96, in UK
 Proiectul este împărțit în faze mai mici
 Scalabil
 Procese PRINCE2
 Pornirea proiectului
 Planificare
 Inițializare
 Conducere
 Controlarea unei faze
 Gestiunea predării unui produs
 Gestiunea limitelor unei faze
 Închiderea proiectului
2

Managementul proiectelor
1

Metoda CMMI
 “Capability Maturity Model Integration”
 Folosit în special în ingineria software și
dezvoltare organizațională
 Scop: îmbunătățirea proceselor
 Dezvoltat la Carnegie-Mellon
 Două reprezentări
 Continuă: focalizare pe procesele cele mai
importante
 În trepte: șir standard de îmbunătățiri, pentru
comparație cu alte proiecte sau organizații
2

Concepte CMMI
 Un model CMMI conține mai multe Arii
de Proces (Process Areas - PA)
 Un PA conține 1-4 scopuri
 Un scop conține practici
 Scopurile și practicile pot fi specifice sau
generice
3

Modele CMMI
 Dezvoltare
 v1.2, august 2006
 Procese de dezvoltare produse și servicii
 Achiziții
 v1.2, noiembrie 2007
 Gestiunea furnizorilor, achiziție și
subcontractare
 Servicii
 v1.2, februarie 2009
 Gestiunea serviciilor în organizație și pentru
externi
4

Evaluare CMMI
 Motive
 Compararea proceselor organizației cu “CMMI best
practices” și cum se pot îmbunătăți
 Informarea clienților și furnizorilor despre procesele
organizației față de “CMMI best practices”
 Îndeplinirea cerințelor contractuale cu unul sau mai mulți
clienți
 Rezultat
 Indicator al nivelului de maturitate
 Profil de realizare al nivelului de capabilitate
 În trepte: cinci nivele de maturitate
 Continuă: șase nivele de capabilitate
 Cerințe evaluare: “Appraisal Requirements for
CMMI” (ARC)
5

Evaluare CMMI (cont.)
 Clase evaluare: A, B, C
 SCAMPI
 “Standard CMMI Appraisal Method for Process
Improvement”
 Conform ARC
 Clase SCAMPI: A, B, C
 “A” este formală și singura care poate rezulta în
indicator de nivel de maturitate
 Compatibil cu ISO/IEC 15504 (“Software
Process Improvement and Capability
Determination” - SPICE)
6

Conformitate CMMI
 Se formează Grupul de Inginerie Proces
(“Engineering Process Group” - EPG) și
Echipele de Acțiune Proces (“Process
Action Teams” - PATs)
 Membrii EPG și PAT cunosc CMMI
 Evaluare relaxată (SCAMPI C)
 Arii de proces prioritizate pentru
îmbunătățire
7

Aplicații CMMI
 Statistică îmbunătățiri
 +14% satisfacție clienți
 +62% productivitate
 CMMI tratează care procese trebuie
îmbunătățite, nu cum
 Recomandat pentru organizații mari
8

Comparație cu alte metode
 CMMI și metodele agile diferite, dar
optime pentru diferite faze ale unui
proiect
 CMMI și SCRUM sunt mai bune
combinate
 XP, cu comunicarea orală, nu este
conformă CMMI
9

Managementul proiectelor
1

Sistemul de producție Toyota
 “Toyota Production System” - TPS
 Nume original: “Just In Time Production”
 Bazat pe ideile lui of W. Edwards Deming și
Henry Ford
 Delegația Toyota neimpresionată de fabrica
Ford
 Impresionată de stocul mic de la magazinul
Piggly Wiggly
 Scopuri principale
 Eliminarea supraîncărcării
 Eliminarea inconsistenței
 Eliminarea risipei
2

Principiile Căii Toyota
 14 principii
 I Filozofie pe termen lung
 1. Filozofia pe termen lung mai importantă decât profitul
pe termen scurt
 II Procesul potrivit va aduce rezultatele potrivite
 2. Flux continuu de proces, pentru evidențierea
problemelor
○ Modificarea proceselor, pentru eliminarea risipei
 1. Supraproducție
 2. Așteptare
 3. Transport inutil
 4. Supraprocesare sau procesare incorectă
 5. Stoc în exces
 6. Mișcare inutilă
 7. Defecte
 8. Creativitate nefolosită a angajaților
3

Principiile Căii Toyota (cont.)
 3. Sisteme cu cerere, pentru evitarea
supraproducţiei
○ Un proces semnalizează celui anterior că are
nevoie de material
○ Se evita supraproducţia
 4. Echilibru în muncă
○ “A se lucra ca țestoasa, nu ca iepurele”
○ Minimizează risipa
○ Nu supraîncarcă oamenii sau echipamentul
○ Evită nivelele inegale de producție
4

Principiile Căii Toyota (cont.)
 5. Cultura de oprire pentru repararea
problemelor, pentru calitate la prima
încercare
○ Calitatea, înainte de toate
○ Oricare angajat poate opri procesul ca să
semnalizeze o problemă de calitate
 6. Sarcini și procese standardizate, pentru
îmbunătățire continuă și împuternicirea
angajaților
○ Angajații sunt utili în creșterea și
îmbunătățirea organizației
5

Principiile Căii Toyota (cont.)
 7. Control vizual pentru eliminarea problemelor
ascunse
○ Spațiu de lucru mai eficient și mai productiv
○ Oamenii partajează spațiul de lucru
○ Timp redus pentru căutarea uneltelor
○ Îmbunătățirea mediului de lucru
○ Programul de 5S
 “Sort” (ordonare) - eliminarea elementelor inutile
 “Straighten” (îndreptare) - totul are un loc
 “Shine” (luciu) - tine locul curat
 “Standardize” (standardizare) - reguli și proceduri
standard de operare
 “Sustain” (susținere) - menținerea sistemului și
îmbunătățirea sa continuă
6

Principiile Căii Toyota (cont.)
 8. Doar tehnologii fiabile, bine testate, care ajută
oamenii și procesele organizației
○ Tehnologia cerută de producție, nu forțată
producției
 III Îmbunătățirea oamenilor adaugă valoare
organizației
 9. Conducători care înțeleg bine munca, trăiesc
filozofia și o predau și altora
○ Fără atenție constantă, principiile vor fi uitate
○ Principiile trebuie să devină modul de gândire
○ Angajații trebuie educați și antrenați
○ Organizația trebuie să fie una de învățare
7

Principiile Căii Toyota (cont.)
 10. Dezvoltă oameni excepționali și echipe care
urmează filozofia organizației
○ Echipă de 4-5 oameni
○ Multe legături cu management-ul
○ Succesul depinde de echipă, nu individ
 11. Respect pentru rețeaua de parteneri și
furnizori
○ “Provocarea” și asistarea lor pentru îmbunătățire
○ Tratarea furnizorilor ca pe angajați
○ Echipe multidisciplinare pentru descoperirea și
rezolvarea problemelor
8

Principiile Căii Toyota (cont.)
 IV Rezolvarea continuă a problemelor de bază motivează
învățarea organizațională
 12. “Du-te și vezi singur” pentru înțelegerea deplină a situației
○ Fără verificare personală la fața locului, manager-ul nu va putea
îmbunătăți situația
○ Zece principii de management de la Toyota Technical Center
(TCC)
1. Totdeauna amintește-ți de scopul final
2. Alocă sarcini clare ție și celorlalți
3. Gândește și vorbește pe baza informațiilor verificate și dovedite
4. Folosește-te de înțelepciunea și experiența celorlalți pentru trimiterea,
adunarea sau discutarea informației
5. Partajează informația cu ceilalți în timp util
6. Totdeauna raportează, informează și consultă în timp util
7. Analizează și înțelege lipsurile în abilitățile tale, în mod cuantificabil
8. Continuă activități de îmbunătățire
9. Gândește neconvențional, dincolo de obișnuință și reguli
10. Totdeauna protejează-ți siguranța și sănătatea
9

Principiile Căii Toyota (cont.)
 13. Decizii lente, prin consens, considerând, în detaliu, toate
opțiunile; implementare rapidă a deciziilor
○ Parametri decizie
1. Află ce se întâmplă, în realitate (du-te și vezi)
2. Determină cauza
3. Consideră o varietate de alternative
4. Construiește consens pentru soluție
5. Folosește unelte eficiente pentru comunicare
 14. Organizație ce învață, prin reflecție strictă și îmbunătățire
continuă
○ Critică tot ce se face
○ Găsirea cauzei unei probleme
1. Perceperea inițială a problemei
2. Clarificarea problemei
3. Localizarea zonei/punctului cu cauza
4. Investigarea cauzei principale (“Root Cause Analysis” - RCA și “5 de ce”)
5. Măsuri reparatoare
6. Evaluare
7. Standardizare
10

Globalizarea Toyota
 Producție globală
 Gândirea Toyota înrădăcinată în Japonia
 Gândire diferită în SUA și alte țări
 Rezolvarea comună a problemelor?
 Rezolvarea problemelor la sursă, nu birou?
 Îmbunătățire continuă?
 Fabrici, muncitori și manageri non-japonezi
 Creștere a problemelor de calitate
 Soluție: cursuri specializate pentru angajații
străini
11

Managementul proiectelor
1

Generalități WBS
 “Work Breakdown Structure”
 Unealtă de descompunere a proiectului în sarcini simple
 Beneficii
 Structura vizuală a lucrărilor
 Monitorizarea progresului
 Estimarea corectă a costurilor și termenelor
 Crearea echipelor
 Structură arborescentă, pe nivele
 Dezvoltare
 Pornire cu scopul final
 Împărțire succesivă în bucăți realizabile
 Organizat în jurul rezultatelor, nu al lucrului necesar
 Planificarea după rezultate duce la control bun al
costurilor
2

Regula de 100%
 WBS include 100% din lucrul și rezultatele
proiectului
 Suma lucrului din “copii” egală cu lucrul din
“părinte”
 WBS nu include lucru suplimentar față de
cel necesar în proiect
 Exclusivitate mutuală: scopurile din două
elemente WBS nu se suprapun
 Eliminarea muncii redundante
 Eliminarea conflictelor de autoritate
 Eliminarea ambiguității în responsabilitate
3

Rezultate, nu acțiuni
 Dacă s-ar include acțiuni, poate se
includ sub sau peste 100% din acțiunile
părintelui
 Includerea rezultatelor în locul acțiunilor
permite creativitate mai bună
 Pentru software: descompunere bazată
pe funcțiile planificate
4

Gradul de detaliere
 Regula celor 80 de ore
 Un singur rezultat să nu necesite
activitate/grup de activități mai lungi de 80
ore de lucru
 Nici o activitate/grup de activități mai
lung de un ciclu de raportare
 Reguli de “bun simț”
5

Gradul de detaliere (cont.)
 Sarcina de lucru definită corect
 Se poate estima corect și realist
 Nu are sens, practic, să mai fie descompus
 Se poate efectua conform regulilor de mai
sus
 Produce un rezultat cuantificabil
 Este o sarcină “rotundă”, ce poate fi preluată
și de un dezvoltator extern
6

WBS
 Codificare elemente: cifre arabe,
separate cu punct (1.2.3, 8.2.4 etc.)
 Structura arborescenta se pretează la
afișarea prin “mind maps”
 WBS nu este
 Listă detaliată de lucru
 Plan temporal al desfășurării proiectului
 Structura organizației
 Prezentare de strategie
7

O reprezentare greșită WBS
• Trebuie rezultatele scontate, nu acțiunile sau componentele
8

Managementul proiectelor
1

Estimarea
 Prezicerea viitorului
 Termene
 Costuri
 Bazele unei estimări bune
 Clarificarea cerințelor
 Estimare bazată pe fapte, nu pe ghicite
 Formule și metode => știință
2

Estimarea (cont.)
 Proiect unic => greu de estimat
 Proiect standard => ușor de estimat
 Factori unici sau imprevizibili
 Membri necunoscuți în echipă
 Tehnologie nouă
 Desincronizarea costă
○ Furnizorii sau muncitorii stau
3

Greșeli frecvente
 Promisiuni optimiste, ad-hoc, la cererea
conducerii
 Soluții
○ Invocarea lipsei temporare de informații
○ Cererea clarificării cerințelor
○ Refuz de a estima
○ Umflarea estimării
○ Estimare optimă, pe baza informațiilor la dispoziție
 Estimare fără analiza specificațiilor
 Estimarea costurilor ≠ estimarea prețului
 Umflarea estimării
 Proiectul va apărea prea scump
 Proiectul va lua resurse de la alte proiecte
4

Reguli pentru estimare bună
 Estimare făcută de oamenii potriviți
 Experiență în domeniu
 Implicați in proiect
 Cunosc cum și de ce estimează
○ Estimări ce se vor materializa
○ Nu preziceri optimiste
 Estimare bazată pe experiență
 Experiența personală
 Statistici și indicatori
○ Furnizați de organizație
 Nu estimarea, ci triunghiul se schimbă
 Schimbarea doar a costului, scopului sau timpului
modifică estimarea
 Schimbarea estimării modifică rezultatul sau resursele
5

Precizia estimării
 Estimarea costă, deci trebuie făcută doar cât trebuie
 Trei nivele
 Evaluarea ideii
○ De evitat
○ Singurul scop: e nevoie de estimare mai exactă?
 Selecția proiectului / scara proiectului
○ Câteva ore
○ Comparație cu proiecte similare
○ Decizia pornirii proiectului
 Estimare detaliată
○ Bazată pe specificații
○ Planificarea proiectului
○ Termene, resurse
○ Această estimare va fi baza gestiunii și evaluării
proiectului
6

Metode de estimare
 În faze
 Incertitudinea scade cu timpul
 Sus-jos (“top-down”)
 Se începe de sus
 Se alocă procente fiecărei faze și sarcini
○ Va fi corectă doar dacă estimarea de sus este
corectă
7

Metode de estimare (cont.)
 Parametrică
 Se ia o unitate de sarcină
 Se multiplică unitatea, în funcție de greutatea sarcinii
 Se consideră și “parametrii”: factori ce influențează
îndeplinirea sarcinilor
 Nevoie de specificații detaliate
 Indicat să se înceapă cu estimarea de jos
 Jos-sus (“bottom-up”)
 Grea, dar precisă
 Se estimează sarcinile, apoi se combină
 Folosit mai rar, deoarece la început, nu sunt destule
informații
8

Estimarea bugetului
 Surse de informații
 Manopera
○ Baza: salariul mediu
○ A nu se omite personalul administrativ
 Echipamente interne
○ Mono- sau multi-proiect
 Manopera și echipamente externe
 Materiale
 Cât și când se cheltuie fonduri e la fel de
important
9

Managementul Proiectelor
1

6 pași de planificare
1. Definirea activităților planificate
 Descompunere WBS
 Stabilirea activităților pentru fiecare rezultat scontat
2. Ordonarea activităților
3. Estimarea resurselor pentru fiecare activitate
4. Estimarea duratei fiecărei activități
 Sfaturi de la cineva cu experiență
 “Sus-jos”, bazată pe asemănări cu proiecte similare
 Parametrică
 “În trei puncte”: (pesimistă + 4 x așteptată + optimistă) / 6
5. Dezvoltarea planului
 Secvențe de activități
 Resurse necesare activităților
 Durata fiecărei activități
6. Monitorizarea și controlarea planului
 Continuă
Sursa: http://www.projectsmart.co.uk/6-steps-to-successful-
schedules.php
2

Managementul Proiectelor
1

Șase aspecte, pentru succes
 1. Preocuparea cu oamenii
 Probleme
○ Ore suplimentare
○ Lipsă timp pentru dezvoltare personală
○ Lipsă motivație
○ Manager ocupat cu proiectul, neglijează echipa
 Soluții
○ Membri echipă: îmbunătățire cunoștințe
 Tehnice
 Management
 Cunoașterea standardelor
 Comunicare și etichetă
○ Manager: grijă față de echipă
 Ascultarea opiniilor și plângerilor
 Rezolvarea problemelor de echipă și personale ale membrilor
 Motivarea membrilor la îmbunătățire
 Rotația sarcinilor membrilor
 Sărbătorirea succeselor echipei
2

Șase aspecte, pentru succes
(cont.)
 2. Păstrarea metodelor bune
 Probleme
○ Prea multe proiecte și
○ Termene limită apropiate =>
 Analiza deficientă a rezultatelor
 Informări scurte, incomplete
 Ședințe grăbite
 Învățare și adaptare reduse
 Estimări inexacte, bazate pe rezultate vechi
 Soluții
○ Aplicarea metodelor care au dus la rezultate bune, în trecut
○ Analiza proiectelor anterioare și crearea de:
 Șabloane
 Reguli
 Învățături
 Proceduri
○ Acordarea de timp suficient pentru:
 Informare
 Analiza rezultatelor
 Testare
 Discuții
 Învățare
3

Șase aspecte, pentru succes
(cont.)
 3. Implicarea managementului superior
 Probleme
○ Rolul echipei, nedefinit exact
○ Legături neclare cu celelalte echipe
 Responsabilități ambigue ale echipelor
 Nepunerea la punct a metodelor de comunicare între echipe
○ Legături neclare cu furnizori/contractori externi
 Cum se realocă resursele
 Ce responsabilități/beneficii au
 Cum se comunică cu ei
 Cum se integrează rezultatele lor în rezultatele organizației
 Soluții, din partea managementului superior
○ Stabilirea viziunii și scopului organizației
○ Analiza periodică a performanțelor organizației
○ Clarificarea rolului furnizorilor/contractorilor externi
○ Stabilirea rolurilor și responsabilităților pentru echipe
○ Stabilirea modurilor de comunicare dintre echipe
4

Șase aspecte, pentru succes
(cont.)
 4. Comunicarea eficientă
 Probleme
○ Apar proiecte diverse și
○ Apar proiecte tot mai complexe =>
 Probleme
○ Termene limită apropiate și
○ Proiecte tot mai complexe =>
 Metodele de comunicare devin ineficiente
- Cine comunică cu cine
- Cât de des
- În ce fel
 Comunicarea internă/externă cu
- Beneficiarii
- Furnizorii
- Acționarii
- Șefii
- Membrii echipei
 Soluții
○ Adaptarea metodelor de comunicare, în funcție de proiect
○ Scalarea colectării reacțiilor și a analizei progresului
○ Modernizarea metodelor de comunicare
○ Pentru informații sensibile, securizarea lor
○ Arhivare, pentru analiza statistică și clarificarea responsabilităților
5

Șase aspecte, pentru succes
(cont.)
 5. Monitorizare și control
 Probleme
○ Proiecte mai complexe și
○ Mai mulți oameni și
○ Mai mulți externi și
○ Mai multe resurse implicate =>
 Metode neoptimizate
 Estimări greșite
 Evaluare proastă a performanțelor
 Evaluare inconsistentă a calității, timpului, riscurilor, costurilor
 “Lecții neînvățate”
 Soluții
○ Proceduri clare și stricte de monitorizare și control
○ Adaptarea procedurilor la proiecte
○ Impunerea unor verificări periodice
○ Implementarea deciziilor de la ședințe
6

Șase aspecte, pentru succes
(cont.)
 6. “Lecții învățate” și “best practices”
 Probleme
○ Proiecte mai complexe și/sau
○ Mai multe resurse implicate =>
 Concluzii inexacte, după predare
 Estimări greșite, pentru proiecte viitoare
 Risipă de resurse, în proiectele viitoare
 Soluții
○ Alocare de timp pentru stabilirea concluziilor
○ Documentarea piedicilor și a soluțiilor găsite
○ Coroborarea periodică a concluziilor mai multor proiecte
○ Utilizarea concluziilor în estimările următoare
○ Adaptarea documentării, la caracteristicile proiectului
Sursa: http://www.projectsmart.co.uk/why-are-my-
projects-struggling.php
7

Managementul Proiectelor
1

10 căi
1. Scopuri realiste
2. Recunoaște meritele
3. Fii pozitivist
 Vezi posibilitățile și oportunitățile în orice provocare
4. Folosește talentele fiecărei persoane
5. Elimină obstacolele din calea echipei
6. Scapă de leneși
7. Pune mâna și tu
8. Recunoaște meritele des
 Săptămânal
9. Fii exemplu de responsabilitate
10. Comunică și raportează progresul
 Săptămânal
Sursa: http://www.projectsmart.co.uk/10-ways-to-inspire-your-
team.php
2

Managementul Proiectelor
1

10 calități de top
1. Inspiră viziunea
2. Bun la comunicare
3. Integritate
4. Transmite entuziasm
5. Înțelege angajații
6. Competent
7. Delegă sarcinile
8. Relaxat, sub stres
9. Bun conducător de echipă
10. Știe să rezolve problemele
Sursa: http://www.projectsmart.co.uk/top-10-qualities-
project-manager.php
2

MP

duminică, 8 februarie 2015

MP Text Version

MP Grila