1

Managementul proiectelor

Dezvoltarea rapidă a aplicaţiilor software

1. INTRODUCERE

2. STRATEGIA DEZVOLTĂRII RAPIDE

2.1. Strategia generală

2.2. Cele patru dimensiuni ale dezvoltării rapide

2.2.1.1. Oamenii

2.2.1.2. Procesul

2.2.1.3. Produsul

2.2.1.4. Tehnologia

3. GREŞELI CLASICE

3.1. Efectul greşelilor asupra programării dezvoltării

3.2. Enumerarea greşelolor clasice

1

4

4

5

5

6

8

8

9

9

10

1. INTRODUCERE

Problema timpului de dezvoltare este insidioasă şi omniprezentă. Diferite studii au arătat că

aproape două treimi dintre proiecte depăşesc substanţial estimările (Lederer & Prasad 1992,

Gibbs 1994, Standish Group 1994). Data planificată a livrării este depăşită cu 25 - 50 % şi

mărimea alunecării programului planificat creşte cu mărimea proiectului (Jones 1994). An

după an, sursele vitezei de dezvoltare au apărut în fruntea listei celor mai critice probleme

puse în faţa comunităţii dezvoltatorilor de software (Symons 1991).

Deşi problema dezvoltării lente a proiectelor este presantă, unele organizaţii se dezvoltă rapid.

Cercetătorii au descoperit diferenţe de 10 la 1 în productivitate între companii din cadrul

aceloraşi industrii, iar unii cercetători au găsit variaţii chiar mai mari (Jones 1994).

Unul dintre scopurile cursului este de a furniza grupurilor care sunt în mod curent mai

aproape de "1" (în cadrul acestui raport de 1 la 10) informaţiile necesare pentru a se apropia

de "10". Cursul îşi propune să vă ajute în aducerea sub control a proiectelor voastre, care să

furnizeze o funcţionalitate sporită într-un timp de dezvoltatre mai scăzut.

Care sunt segmente ţintă ale cursului ?

• Responsabilii în partea tehnică

Unele exemple practice care vă vor fi prezentate sunt tehnice. Ca responsabili în acest sector,

nu veţi avea probleme în implementarea lor. Alte exemple sunt orientate mai mult spre

management, care este de fapt şi titlul cursului. Presupunem că sunteţi (sau veţi deveni în

scurt timp) manageri pe partea tehnică, deci oameni capabili să mânuiască atât problemele

2

tehnice, cât şi pe cele manageriale. Naiva dihotomia tehnic-managerial nu este tocmai

potrivită, responsabilii din sectorul tehnic fiind adesea chemaţi să facă recomandări upper-

management-ului în legătură cu problemele de management orientate tehnic.

• Programatorii individuali

Multe proiecte software sunt derulate de către programatori individuali sau de către "self-

managed teams", punând participanţii din zona tehnică individuală în roluri de responsabili

tehnici.

• Manageri

Managerii consideră adeseori că dezvoltarea rapidă a unui software este în primul rând o

problemă tehnică. Cu toate acestea, un manager poate face în mod normal la fel de mult ca şi

dezvoltatorii pentru a îmbunătăţi viteza dezvoltării proiectului. Acest curs va descrie şi

exemple de dezvoltare rapidă la nivelul managementului.

Cursul pune accentul pe problemele legate de dezvoltarea de software, ţinând cont de faptul

că acest domeniu este într-o explozie fantastică pe scară globală, dar şi naţională şi locală,

reprezentând unul dintre puţinele sectoare viabile şi de mare perspectivă ale ţării noastre.

Mulţi dintre voi sunt antrenaţi în mod direct sau indirect în activităţi de dezvoltare de

software, iar ceilalţi sunteţi cu siguranţă în zone adiacente, în care problemele legate de

aplicarea şi mentenaţa software-ului sunt stringente.

În acest context, putem considera că proiectele software pot fi optimizate pentru oricare dintre

următoarele scopuri: rata de defectare cea mai scăzută, viteza de execuţie cea mai mare,

gradul de acceptanţă de către utilizator cel mai ridicat, mentenabilitatea cea mai bună, costul

cel mai scăzut sau timpul de dezvoltare cel mai scurt. O abordare inginerească ne conduce

către buna cântărire a problemelor: poţi optimiza timpul de dezvoltare tăind de la calitate?

Tăind de la capacitatea de folosinţă? Cerând dezvoltatorilor să lucreze peste program? Când

"momentul adevărului" se apropie, câte reduceri în planificare poţi opera? Sunt câteva dintre

întrebări la care vom răspunde împreună de-a lungul acestui curs.

Putem să vorbim despre o criză a softiştilor relativ la problema dezvoltării lente a softurilor?

În occident da. Iar la noi începe să apară. Clienţii şi managerii răspund acestei probleme în

primul rând prin creşterea presiunii planificării şi prin supraîncârcarea dezvoltatorilor.

Presiunea excesivă a planificării se produce în aproximativ 75 % dintre proiectele mari şi în

aproximativ 100 % dintre proiectele foarte mari (Jones 1994). Aproape 60 % dintre

dezvoltatori spun că nivelul de stres resimţit este în creştere (Glass 1994). Media

dezvoltatorilor în SUA lucrează între 48 şi 50 de ore pe săptămână (Krantz 1995). Mulţi

muncesc considerabil mai mult. Nu este deci surprinzător că satisfacţia generală a muncii din

acest domeniu a scăzut semnificativ în ultimii ani (Zawacki 1993). O reconsiderare a

managementului proiectelor software poate aduce îmbunătăţiri substanţiale şi din acest punct

de vedere.

3

Dezvoltarea rapidă - ce este şi ce vrea ea?

Managerul de producţie mi-a spus că doreşte să construiască un produs potrivit pentru o

schimbare. El doreşte să fim atenţi la calitate, să prevenim neconformitatea, să ţinem sub

control planificarea şi să putem furniza o dată predictibilă a lansării.

Când a sosit timpul de a face efectiv proiectul, a devenit clar că lansarea cu rapiditate a

produsului a fost singura prioritate reală. Utilizabilitatea? Nu avem timp. Performanţa? Nu

putem aştepta. Mentenabilitatea? La următorul proiect. Testarea? Utilizatorii noştri doresc

produsul acum. Să li-l oferim acum.

Acest manager de producţie nu conduce numai proiectul unui produs. Şi el se poate identifica

cu aproape orice manager de producţie. Timpul de dezvoltare a devenit o prioritate atât de

importantă, încât i-a "furat" pe oameni de la alte consideraţii semnificative, chiar de la acelea

care influenţează în ultimă instanţă şi timpul de dezvoltare.

Ce este dezvoltarea rapidă ?

Depinde de cine se gândeşte la asta. Pentru unii oameni, aplicarea unei singure unelte sau a

unei singure metode. Pentru un hacker - 36 de ore pentru un scop. Pentru inginerul din IT -

RAD (Rapid Development), o combinaţie între uneltele CASE, implicarea intensivă a

utilizatorului şi "timeboxes" foarte strânse. Pentru programatorul tip "vertical-market" -

elaborarea cu rapiditate a unui prototip utilizând ultima versiune de Visual Basic sau Delphi.

Pentru managerul disperat care doreşte să scurteze termenele - orice chestiune practică

desprinsă din cele mai recente numere ale revistelor de afaceri.

Oricare dintre aceste unelte şi metode este bună atâta timp cât "merge" şi fiecare poate

contribui la creşterea vitezei de dezvoltare. Dar pentru a furniza un beneficiu maxim, trebuie

ca fiecare să fie orchestrată ca parte a unei strategii cuprinzătoare. Niciuna dintre ele nu se

poate aplica în toate cazurile. Şi niciuna dintre ele nu se poate “măsura” cu anumite alte

practici care nu sunt gândite în mod obişnuit ca practici pentru dezvoltare rapidă, dar care au

oricum profunde implicaţii asupra dezvoltării rapide.

În cadrul acestui curs, termenul de "dezvoltare rapidă" este mai degrabă o sintagmă

descriptivă, care contrastează cu "dezvoltare lentă şi tipică". Un termen generic care înseamnă

acelaşi lucru ca şi "scurtarea termenelor".

Atunci, un "proiect dezvoltat rapid" este orice proiect care trebuie să sublinieze viteza de

dezvoltare. In climatul zilelor noastre, această descriere se potriveşte unei sumedenii de

proiecte.

4

2. STRATEGIA DEZVOLTĂRII RAPIDE

2.1 Strategia generală

Puteţi realiza o dezvoltare rapidă urmărind o strategie cu patru linii directoare:

Evitaţi greşelile clasice.

Aplicaţi bazele dezvoltării.

Conduceţi riscurile pentru a evita întoarcerile catastrofale.

Aplicaţii practicile orientate spre planificare (viteză, risc planificat, vizibilitate):

o Care îmbunătăţesc viteza dezvoltării, permiţându-vă să livraţi produsul mai

repede.

o Care reduc riscul planificat, permiţându-vă să evitaţi depăşiri uriaşe ale

planificării.

o Care fac vizibil progresul, permiţându-vă să înlăturaţi aparentă unei dezvoltări

încete.

Figura 2.1 – Cei patru piloni ai dezvoltării rapide

Pilonii din figură ilustrează căteva aspecte importante:

Sprijinul optim pentru cea mai bună planificare posibilă este când avem toţi pilonii şi când îi

facem pe toţi cât mai puternici posibil. Fără sprijinul primilor trei, abilitatea voastră în

planificare va fi în primejdie puteţi să folosiţi cele mai solide practici orientate pe planificare,

dar dacă faceţi greşeala clasică de a scurta timpul destinat calităţii produsului în faza timpurie

a proiectului, veţi pierde timp corectând defecte atunci când este cel mai scump. Proiectul va

întârzia.

Dacă săriţi peste principiul de dezvoltare de a crea un proiect bun înainte de a lucra efectiv,

produsul va avea de suferit când concepţia lui se va schimba în unele părţi prin dezvoltare şi

proiectul va întârzia. Şi dacă nu conduceţi riscurile, puteţi afla chiar înainte de data lansării că

un subcontractor-cheie este în urmă cu trei luni faţă de planificare. Şi veţi întârzia iarăşi.

Figura sugerează de asemenea că primii trei piloni furnizează cel mai mare sprijin necesar

pentru cea mai bună planificare. Poate că nu un sprijin ideal, dar cea mai mare parte din

Cea mai buna planificare

posibilă

5

necesar. Este posibil să fiţi capabili să realizaţi o planificare optimă fără practici orientate pe

planificare.

Puteţi realiza însă cea mai bună planificare prin concentrarea numai pe practici orientate pe

planificare? Este un act foarte dificil de echilibrat şi vă veţi priva de sprijinul în general

necesar.

2.2. Cele patru dimensiuni ale dezvoltării rapide

În timp ce încercaţi să evitaţi greşeli şi să navigaţi la viteză maximă cu cele mai eficiente

practici orientate pe planificare, proiectul vostru operează de-a lungul a patru dimensiuni

importante:

Oamenii

Procesul

Produsul

Tehnologia

În general, organizaţiile tind să vadă dimensiunile pe care nu sunt axate ca fiind fixe.

Organizaţiile cele mai eficiente în realizarea dezvoltării rapide optimizează toate cele patru

dimensiuni simultan.

Odată ce realizaţi că fiecare dintre cele patru dimensiuni poate furniza pârghii consistente în

planificare, aceasta din urmă poate deveni mai completă, mai creativă, mai eficace şi mai

capabilă de a satisface toate părţile implicate.

2.2.1 Oamenii

Cercetările în această problemă s-au coagulat cu precădere în ultimii 15-20 de ani. Este acum

posibil să păşim printre concluziile multor studii individuale şi să sintetizăm câteva concluzii

generale vis-à-vis de tendinţele cercetărilor.

Prima concluzie este că acest aspect are cel mai mare impact asupra productivităţii şi calităţii

software-ului. Din ultima parte a anilor '60, studiile au relevat că productivitatea

programatorilor individuali cu niveluri similare de experienţă variază după un factor de cel

puţin 10 la 1 (Sackman 1968, Curtis 1981, Mills 1983, DeMarco 1985, Card 1987, Valett

1989).

De asemeni, studiile au găsit variaţii în performanţa intregii echipe de 3, 4 sau 5 la 1.

(Weinberg 1974, Boehm 1981, Mills 1983, Boehm 1984). După 20 de ani de experimente,

cercetătorii de la NASA's Software Egineering Laboratory au concluzionat că nu tehnologia

este răspunsul; cele mai eficiente practici sunt acelea care influenţează potenţialul uman al

dezvoltatorilor lor (Basili 1995).

Este cât se poate de clar că orice organizaţie care este serioasă în ceea ce priveşte

îmbunătăţirea productivităţii trebuie să privească mai întâi spre problematica umană a

motivaţiei, lucrului în echipă, selecţiei personalului şi pregătirii. Luate împreună, acestea

contează mai mult decât procesul, productivitatea şi tehnologia. Lor trebuie să vă adresaţi

dacă doriţi să reuşiţi.

6

Cursul se va ocupa de câteva căi prin care puteţi maximiza potenţialul uman în scopul

reducerii factorului timp.

Selecţia personalului pentru echipele proiectelor

În cartea sa de referinţă, Software Engineering Economics, Barry Boehm prezintă cinci

principii ale selecţiei personalului (Boehm 1981):

Talent de vârf – Utilizaţi mai degrabă oameni mai buni şi mai puţini.

Corespondeţa cu job-ul – Completaţi sarcinile în corelaţie cu aptitudinile şi motivaţia

personalului disponibil.

Progresia carierei – Ajutaţi oamenii mai degrabă să se perfecţioneze decât să-i forţaţi să

lucreze acolo unde au mai multă experienţă sau unde sunt mai necesari.

Echilibrul echipei – Selectaţi oamenii care se completează şi armonizează reciproc.

Eliminarea oamenilor nepotriviţi – Eliminaţi şi înlocuiţi membrii-problemă ai echipei cât

mai repede posibil.

Organizarea echipei

Felul în care sunt organizaţi oamenii are un efect semnificativ asupra eficienţei muncii lor.

Shop-urile de software pot beneficia de “croirea” echipelor lor după mărimea proiectului,

caracteristicile produsului şi scopurile programate. Un proiect software specific poate

beneficia de asemenea de specializarea corespunzătoare.

Motivaţia

Este puţin probabil ca o persoană căreia îi lipseşte motivaţia să lucreze “din greu”; este mai

probabil ca aceasta să lucreze “la limită”. Motivaţia este aliatul potenţial cel mai puternic pe

care îl aveţi pentru dezvoltarea rapidă a proiectelor.

2.2.2 Procesul

Procesul include atât metodologiile de managementul, cât şi cele tehnice. Efectul pe care îl

are asupra planificării dezvoltării proiectului este mai uşor de evaluat decât cel al oamenilor şi

a fost reflectat printr-o muncă intensă de către diverse organizaţii. Hughes Aircraft, Lockheed,

Motorola, NASA, Raytheon şi XEROX, care s-au axat explicit pe îmbunătăţirea proceselor de

dezvoltare proprii, au redus la jumătate, de-a lungul câtorva ani, timpii de acces la piaţă a

produsului, iar costul şi defectele le-au redus de 3 până la 10 ori (Pietrasanta 1991, Myers

1992, Putnam 1992, Bibbs 1994, Basili 1995, Saiedian 1995).

Unii oameni consideră că atenţia spre proces este sufocantă şi că nu există nici un dubiu

asupra faptului că unele procese sunt peste măsură de rigide sau birocratice. Unele persoane

au creat standarde pentru procese în primul rând cu scopul de a se simţi ei înşişi puternici. Dar

aceasta reprezintă un abuz de putere şi faptul că se poate abuza de direcţionarea unui proces

nu ar trebui să permită defăimarea beneficiilor pe care le poate oferi focusarea pe process.

Forma cea mai comună a abuzării de process este neglijenţa şi efectul ecesteia este că

dezvoltatorii inteligenţi şi conştiincioşi se găsesc pe ei înşişi lucrănd inefficient şi la

intersecţia scopurilor când nu este nevoie ca ei să lucreze în acest fel. O atenţie axată pe

process poate fi de ajutor.

7

Evitarea dublării muncii

Dacă cerinţele se schimbă în etapele finale ale proiectului, trebuie să-l reproiectaţi, rescrieţi şi

retestaţi. Dacă rezultă, de exemplu, probleme în faza de testare, puteţi fi puşi în situaţia de a

renunţa la elemente pe care le-aţi elaborat în detaliu şi de a o lua de la început. Una dintre cele

mai importante căi de a salva timpul într-un proiect este de a orienta procesul astfel încât să

evitaţi să faceţi acelaşi lucru de două ori.

Raytheon a câştigat IEEE Computer Society’s Software Process Achievement Award în anul

1995 pentru reducerea costurilor pentru rework de la 41% la mai puţin de 10%, triplându-şi

simultan productivitatea (Raytheon 1995). Relaţia dintre cele două elemente este una de

substanţă, nu o coincidenţă.

Asigurarea calităţii

Asigurarea calităţii are două scopuri principale. Primul este acela de a se asigura faptul că

produsul lansat are un nivel acceptabil al calităţii (Deşi important, nu este printre scopurile

acestui curs). Al doilea este de a detecta erori în etape în care corecţiile sunt mai puţin

consumatoare de timp (şi la costuri mai mici), la momente cât mai apropiate de acela în care

au fost introduse în sistem. Asigurarea calităţii este astfel o parte indispensabilă a oricârui

program de dezvoltare rapidă.

Bazele dezvoltării

Deşi practicile standard de analiză, proiectare, construcţie, integrare şi testare nu produc

planificări strălucitoare prin ele însele, pot preveni răsucirea proiectelor spre zone

necontrolabile. Jumătate dintre provocările dezvoltării rapide sunt de a evita dezastrele, şi

aceasta este o zonă în care principiile ingineriei software standard excelează.

Managementul riscului

Una dintre practicile specifice care este focusată pe evitarea dezastrelor este managementul

riscului. Dezvoltarea rapidă nu este sufficient de bună dacă rămâneţi blocaţi cu două

sâptămâni înainte de termenul de lansare a produsului.

Ţintirea resurselor

Resursele pot fi avute în vedere în mod eficient (caz în care contribuie la productivittea

generală), sau pot fi direcţionate greşit şi utilizate ineficient. Într-un proiect de dezvolatre

rapidă, este mai important decât în mod obişnuit ca să obţineţi maximum de impact pentru

banii planificaţi. Practicile cele mai bune, cum sunt birouri de productivitate, planificare

corespunzătoare şi timp de lucru suplimentar voluntary, ajută pentru a fi siguri că obţineţi

maximum de muncă efectuată zilnic.

Planificarea ciclului de viaţă

Una dintre cheile ţintirii eficiente a resurselor este de a le aplica în cadrul unui ciclu de viaţă

care să aibă sens pentru proiectul vostru concret. Fără un model al întregului ciclu de viaţă,

puteţi lua decizii care sunt axate individual pe ţintă, dar direcţionate colectiv în mod greşit.Un

model al ciclului de viaţă este util pentru că descrie un plan de management de bază. De

exemplu, dacă aveţi un proiect riscant, un model de ciclu de viaţă oriectat pe risc va fi

8

potrivit; şi dacă aveţi cerinţe vagi, un model de ciclu de viaţă incremental va putea funcţiona

cel mai bine.

Orientarea spre client

Unul dintre salturile cele mai semnificative între dezvoltarea tradiţională de software tip

mainframe şi stilurile de dezvoltare mai moderne a fost acela spre un puternic accent pe

nevoile şi dorinţele clientului. Dezvoltatorii au învăţat că producerea de software conform cu

specificaţiile este numai jumătate din muncă. Cealaltă jumătate este ajutarea clientului pentru

a-şi da seama de cea ce produsul trebuie să fie şi de cele mai multe ori aceata solicită o

abordare diferită de cea tradiţonală bazată pe specificaţii scrise pe hârtie. Să vă puneţi de

aceeaşi parte cu clientul este cea mai bună cale de a evita dublările masive ale muncii cauzate

de decizia clientului potrivit căreia produsul pentru acre tocmai aţi consumat 12 luni nu este

cel corect de fapt. Practicile cele mai bune de lansare în etape, livrare şi prototipuri bazate pe

evoluţie şi negociere principială vă pot conferi un control rezonabil.

2.2.3 Produsul

Produsul este cea mai tangibilă dintre cele patru dimensiuni în discuţie. Dacă poţi reduce setul

de caracteristici ale produsului, poţi reduce timpii în cadrul planificării produsului.

Mărimea produsului

Este cel mai important element singular care contribuie la planificarea dezvoltării.

Caracteristici suplimentare cer specificaţii, proiectare, construcţie, testare şi integrare

suplimentare. Reducerea la jumătate a mărimii unui program de dimensiuni medii va reduce

efortul cerut cu aproape două treimi.

2.2.4 Tehnologia

Schimbările din unelte mai pţin eficiente în unelte mai eficiente pot fi de asemenea o cale

rapidă de a îmbunătăţi viteza de dezvoltare. Schimbarea din limbaje de nivel jos (limbaje de

asamblare) în limbaje de nivel înalt (C, Pascal) a fost una dintre cele mai importante din

istoria dezvoltării software-ului.

9

1. GREŞELI CLASICE

Dezvoltarea de software este o activitate complexă. Un proiect software tipic poate prezenta

multe oportunităţi de a învăţa din greşeli.

1.1. Efectul greşelilor asupra programării dezvoltării

Michael Jackson spunea într-unul din cântecele sale că "One bad apple don't spoil the whole

bunch, baby". Aceasta poate fi adevărat pentru mere, dar pentru software în nici un caz. Un

măr rău poate strica întregul proiect.

Un grup de cercetători de la ITT a trecut în revistă 44 de proiecte în 9 tări pentru a examina

impactul a 13 factori de productivitate asupra acesteia (Vosburgh 1984). Aceşti factori

includeau utilizarea practicilor de programare moderne, dificultatea codului, cerinţele de

performanţă, nivelul de participare a clientului în specificaţiile cerute, experienţa personalului

şi alte câteva. Ei au împărţit fiecare dintre aceşti factori în categorii care te-ai aştepta să fie

asociate cu o performaţă scăzută, medie sau ridicată. De exemplu, ei au împărţit factorul

"practici moderne de programare" în utilizare scăzută, medie şi ridicată (figura 2.1.).

Rezultatele desprinse sunt interesante. Modelul general arătat este reprezentativ pentru fiecare

dintre factorii de productivitate studiaţi. Cercetătorii de la ITT au găsit că proiecte din

categorii de la care se aşteptau să aibă o productivitate scăzută au avut într-adevăr

productivitate scăzută, cum este cazul şirului îngust de la categoria "Scăzut". Dar

productivitatea din categoriile performanţei înalte a variat foarte mult, cum este arătat în şirul

larg de la categoria "Ridicat". Productivitatea proiectele din această categorie a variat de la

scăzut la excelent.

Legendă

Maximum

75 %

Media

25%

Mimimum

Procentul

productivităţii

nominale

+ 200

+ 100

Scăzut Mediu Ridicat

(0-25%) (26-75%) (76-100%)

Fig. 2.1. Utilizarea practicilor programării moderne

(procente din sistemul total)

10

Faptul că acele proiecte de la care s-a aşteptat să aibă o productivitate scăzută au confirmat

aceasta nu trebuie să surprindă. Dar că multe proiecte de la care se astepta o productivitate

foarte bună au avut de fapt una scăzută, aceasta poate constitui o surpriză. Ceea ce relevă

graficul este că utilizarea oricăror practici specifice bune este necesară dar nu suficientă

pentru a atinge maximum de viteză de dezvoltare. Chiar dacă faceţi unele lucruri bine, cum ar

fi utilizarea la o capacitate ridicată a practicilor moderne de programare, puteţi face încă a

greşeală care anulează căştigurile pe care le-aţi realizat în productivitate.

2.1. Enumerarea greşelilor clasice

Unele practici de dezvoltare ineficientă sunt alese atât de des, de atât de multă lume, cu

rezultate proaste atât de predictibile, încât merită să fie numite "greşeli clasice". Multe dintre

greşeli au o atracţie seducătoare. Vreţi să salvaţi un proiect care este în urma planificării?

Adăugaţi mai mulţi oameni! Vreţi să reduceţi termenele planificate? Planificaţi mai agresiv!

Unul dintre contributorii cheie afectează negativ restul echipei? Aşteptaţi până la sfârşitul

proiectului pentru a-l da afară! Aveţi de completat un proiect presant ca termen? Luaţi-vă

oricâţi dezvoltatori sunt disponibili acum şi începeţi cât mai repede posibil.

Greşelile enumerate în continuare au un numitor comun: nu veţi accede în mod necesar la o

dezvoltare rapidă dacă veţi evita aceste greşeli, dar în mod sigur veţi întârzia dezvoltarea dacă

nu le veţi evita. Odată ce le veţi înţelege efectele asupra vitezei de dezvoltare, veţi putea

utiliza lista lor în ajutorul planificării proiectului şi managementului riscului.

Pentru uşurinţa referirii, lista greşelilor a fost împărţită pe cele patru dimensiuni ale vitezei de

dezvoltare: oamenii, procesul, produsul şi tehnologia.

Oamenii

Iată căteve dintre greşelile clasice legate de oameni:

1: Motivaţie subminată. Un studiu după altul relevă faptul că motivaţia are probabil efectul

cel mai mare asupra productivităţii şi calităţii (Boehm 1981). Trageţi concluziile şi din Studiul

de caz 2.1., făcut la laborator.

2: Personal slab. După motivaţie, atât capacităţile individuale ale membrilor echipei, cât şi

relaţia dintre ei care determină comportarea ca echipă, au cea mai mare influenţă asupra

productivităţii (Boehm 1981, Lakhanpal 1993). Trageţi concluziile şi din Studiul de caz 2.1.

3: Angajaţi cu probleme necontrolabile. Este o problemă obişnuită şi bine înţeleasă de

vreme ce Gerald Weingerg a publicat Psychology of Computer Programming în anul 1971.

Eşecul în a lua atitudine faţă de angajatul-problemă este cea mai obişnuită plângere a

memebrilor echipei vis-à-vis de şeful lor. (Larson 1989). Trageţi concluziile şi din Studiul de

caz 2.1.

4: Eroism. Unii dezvoltatori software accentuează pe eroismul proiectelor (Bach 1995). Dar

fac mai mult rău decăt bine. Vedeţi şi Studiul de caz 2.1. Un accent pus pe eroism încurajează

asumarea riscurilor şi descurajează cooperarea între numeroşii stakeholder-i implicaţi în

11

procesul de dezvoltare software. Unii manageri încurajează comportamentul eroic când se

bazează prea mult pe atitudinea excesivă se poate, afectând capacitatea de a se lua acţiuni

corective. Atitudinea se poate produce micii paşi către adevăratele dezastre. (DeMarco 1995).

5: Adăugare de personal la un proiect întârziat. Aceasta este probabil cea mai clasică

dintre greşelile clasice. Când un proiect este în întârziere, suplimentarea de personal poate lua

mai multă productivitate de la membrii echipaei existente decât adaugă noii membrii. Unii

autori compară aceasta cu punerea gazului pe foc (Brooks 1975).

6: Birouri înghesuite, zgomotoase. Cei mai mulţi dezvoltatori consideră condiţiile de lucru

drept nesatisfăcătoare. Aproximativ 60% raportează că nu au ori suficientă linişte, ori

suficientă intimitate (DeMarco 1987). Mediile zgomotoase, populate, lungesc durata

dezvoltării.

7: Fricţiuni între dezvoltatori şi clienţi. Se pot produce în mai multe feluri. Clienţii pot să

simtă că dezvoltatorii nu sunt cooperanţi atunci când refuză să semneze programarea

dezvoltării dorită de clienţi sau când nu pot să furnizeze ceea ce au promis. Dezvoltatorii pot

să simtă ca clienţii nu sunt rezonabili, insistând pe programări nerealiste sau schmbări ale

specificaţiilor după ce acestea au fost fundamentate. Pot fi şi simple conflicte personale dintre

cele două grupuri.

Principalul efect al fricţiunilor este slaba comunicare, iar efectele secundare ale slabei

comunicări includ slaba înţelegere a cerinţelor, slaba proiectare a interfeţei-utilizator şi, în

cazul cel mai rău, refuzul clenţilor de a accepta produsul completat. În medie, fricţiunile

dintre clienţi şi dezvoltatori devin atât de severe încât ambele părţi iau în considerare

abandonarea proiectului (Jones 1994). Aceste fricţiuni sunt consumatoare de timp şi distrag

ambele părţi de la muncă reală din cadrul proiectului.

8: Aşteptări nerealiste. Reprezintă una dintre cauzele cele mai obişnuite ale fricţiunilor dinre

clienţi şi dezvoltatori. Vedeţi şi Studiul de caz 2.1. De asemeni, unii manageri pot intra în

încurcătură alocând fonduri bazându-se pe o estimare prea optimistă.

Deşi asteptările nerealiste nu lungesc prin ele însele programarea dezvoltării, totuşi ele

contribuie la percepţia că aceasta este prea lungă, iar asta poate fi aproape la fel de rău. Un

studiu al Standish Group a plasat aşteptările realiste în topul 5 al factorilor necesari pentru

asigurarea succesului unui proiect (Standish Group 1994).

9: Lipsa unui sprijin eficient al proiectului. Sprijinirea proiectului la nivel înalt este

necesară în multe aspacte ale dezvoltării rapide, incluzând planificarea realistă, controlul

schimbării şi introducerea noilor practici de dezvoltatre. Fără un sprijin eficiant în conducerea

executivă, alte persoane de la nivelul conducerii organizaţiei voastre vă poate forţa să

acceptaţi termene nerealiste sau să faceţi schimbări care vă subminează proiectul. Lipsa unui

sponsor executiv eficient garantează virtual eşecul proiectului (Thomsett 1995).

10: Lipsa convergenţei stakeholder-ilor. Toţi actorii majori din cadrul proiectului trebuie să-

şi unească eforturile. Aceasta include sponsorul executiv, conducătorul echipei, membrii

echipei, echipa de marketing, utilizatorii finali, clienţii şi oricine altcineva care are un interes

12

în sprijinirea proiectului, factori ai căror convergenţă conduce la o coordonare precisă a

proiectului.

11: Neimplicarea utilizatorului. Studiul efectuat de Standish Group relevă faptul că motivul

numărul 1 al succesului proiectelor este implicarea utilizatorilor (Standish Group 1994).

Proiectele fără implicarea timpurie a utilizatorului final riscă înţelegerea greşită a cerinţelor

proiectului şi sunt vulnerabile în ceea ce priveşte consumul de timp ulterior în proiect.

12: Politica plasată deasupra substanţei. Iată rezultatul unui studiu efectuat pe patru echipe

cu orientări diferite (Constantine 1995). "Politicienii" - concentraţi pe relaţia cu managerii lor.

"Cercetătorii" - concentraţi pe căutarea şi străngerea informaţiei. "Izolaţioniştii" - retraşi în ei

înşişi, creând graniţe ale proiectului faţă de non-membrii proiectului. Generaliştii" - fâcând

câte puţin din toate: relaţia cu managerii, cercetare, coordonare cu alte echipe pe calea

fluxurilor normale de lucru. Iniţial, "politicienii" şi "generaliştii" au fost deopotrivă bine

văzuţi de top-management. Dar după un an şi jumătate, echipa "politicienilor" a fost

înregistrată ultima ca rezultate. Punerea politicii deasupra rezultatelor este fatală pentru

dezvoltarea orientată pe viteză.