of 12/12
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

Curs_dezvoltarea Rapida a Aplicatiilor Software

  • View
    9

  • Download
    0

Embed Size (px)

Text of Curs_dezvoltarea Rapida a Aplicatiilor Software

  • 1

    Managementul proiectelor

    Dezvoltarea rapid a aplicaiilor software

    1. INTRODUCERE

    2. STRATEGIA DEZVOLTRII RAPIDE

    2.1. Strategia general

    2.2. Cele patru dimensiuni ale dezvoltrii rapide

    2.2.1.1. Oamenii

    2.2.1.2. Procesul

    2.2.1.3. Produsul

    2.2.1.4. Tehnologia

    3. GREELI CLASICE

    3.1. Efectul greelilor asupra programrii dezvoltrii

    3.2. Enumerarea greelolor 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 artat c

    aproape dou treimi dintre proiecte depesc substanial estimrile (Lederer & Prasad 1992,

    Gibbs 1994, Standish Group 1994). Data planificat a livrrii este depit cu 25 - 50 % i

    mrimea alunecrii programului planificat crete cu mrimea proiectului (Jones 1994). An

    dup an, sursele vitezei de dezvoltare au aprut n fruntea listei celor mai critice probleme

    puse n faa comunitii dezvoltatorilor de software (Symons 1991).

    Dei problema dezvoltrii lente a proiectelor este presant, unele organizaii se dezvolt rapid.

    Cercettorii au descoperit diferene de 10 la 1 n productivitate ntre companii din cadrul

    acelorai industrii, iar unii cercettori au gsit variaii 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) informaiile necesare pentru a se apropia

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

    furnizeze o funcionalitate sporit ntr-un timp de dezvoltatre mai sczut.

    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 vei avea probleme n implementarea lor. Alte exemple sunt orientate mai mult spre

    management, care este de fapt i titlul cursului. Presupunem c suntei (sau vei deveni n

    scurt timp) manageri pe partea tehnic, deci oameni capabili s mnuiasc att problemele

  • 2

    tehnice, ct i pe cele manageriale. Naiva dihotomia tehnic-managerial nu este tocmai

    potrivit, responsabilii din sectorul tehnic fiind adesea chemai s fac recomandri upper-

    management-ului n legtur cu problemele de management orientate tehnic.

    Programatorii individuali

    Multe proiecte software sunt derulate de ctre programatori individuali sau de ctre "self-

    managed teams", punnd participanii din zona tehnic individual n roluri de responsabili

    tehnici.

    Manageri

    Managerii consider adeseori c dezvoltarea rapid a unui software este n primul rnd o

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

    dezvoltatorii pentru a mbunti viteza dezvoltrii proiectului. Acest curs va descrie i

    exemple de dezvoltare rapid la nivelul managementului.

    Cursul pune accentul pe problemele legate de dezvoltarea de software, innd cont de faptul

    c acest domeniu este ntr-o explozie fantastic pe scar global, dar i naional i local,

    reprezentnd unul dintre puinele sectoare viabile i de mare perspectiv ale rii noastre.

    Muli dintre voi sunt antrenai n mod direct sau indirect n activiti de dezvoltare de

    software, iar ceilali suntei cu siguran n zone adiacente, n care problemele legate de

    aplicarea i mentenaa software-ului sunt stringente.

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

    urmtoarele scopuri: rata de defectare cea mai sczut, viteza de execuie cea mai mare,

    gradul de acceptan de ctre utilizator cel mai ridicat, mentenabilitatea cea mai bun, costul

    cel mai sczut sau timpul de dezvoltare cel mai scurt. O abordare inginereasc ne conduce

    ctre buna cntrire a problemelor: poi optimiza timpul de dezvoltare tind de la calitate?

    Tind de la capacitatea de folosin? Cernd dezvoltatorilor s lucreze peste program? Cnd

    "momentul adevrului" se apropie, cte reduceri n planificare poi opera? Sunt cteva dintre

    ntrebri la care vom rspunde mpreun de-a lungul acestui curs.

    Putem s vorbim despre o criz a softitilor relativ la problema dezvoltrii lente a softurilor?

    n occident da. Iar la noi ncepe s apar. Clienii i managerii rspund acestei probleme n

    primul rnd prin creterea presiunii planificrii i prin suprancrcarea dezvoltatorilor.

    Presiunea excesiv a planificrii 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 resimit este n cretere (Glass 1994). Media

    dezvoltatorilor n SUA lucreaz ntre 48 i 50 de ore pe sptmn (Krantz 1995). Muli

    muncesc considerabil mai mult. Nu este deci surprinztor c satisfacia general a muncii din

    acest domeniu a sczut semnificativ n ultimii ani (Zawacki 1993). O reconsiderare a

    managementului proiectelor software poate aduce mbuntiri substaniale i din acest punct

    de vedere.

  • 3

    Dezvoltarea rapid - ce este i ce vrea ea?

    Managerul de producie mi-a spus c dorete s construiasc un produs potrivit pentru o

    schimbare. El dorete s fim ateni la calitate, s prevenim neconformitatea, s inem sub

    control planificarea i s putem furniza o dat predictibil a lansrii.

    Cnd 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. Performana? Nu

    putem atepta. Mentenabilitatea? La urmtorul proiect. Testarea? Utilizatorii notri doresc

    produsul acum. S li-l oferim acum.

    Acest manager de producie nu conduce numai proiectul unui produs. i el se poate identifica

    cu aproape orice manager de producie. Timpul de dezvoltare a devenit o prioritate att de

    important, nct i-a "furat" pe oameni de la alte consideraii semnificative, chiar de la acelea

    care influeneaz n ultim instan i timpul de dezvoltare.

    Ce este dezvoltarea rapid ?

    Depinde de cine se gndete 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 combinaie ntre uneltele CASE, implicarea intensiv a

    utilizatorului i "timeboxes" foarte strnse. Pentru programatorul tip "vertical-market" -

    elaborarea cu rapiditate a unui prototip utiliznd ultima versiune de Visual Basic sau Delphi.

    Pentru managerul disperat care dorete s scurteze termenele - orice chestiune practic

    desprins din cele mai recente numere ale revistelor de afaceri.

    Oricare dintre aceste unelte i metode este bun atta timp ct "merge" i fiecare poate

    contribui la creterea vitezei de dezvoltare. Dar pentru a furniza un beneficiu maxim, trebuie

    ca fiecare s fie orchestrat ca parte a unei strategii cuprinztoare. Niciuna dintre ele nu se

    poate aplica n toate cazurile. i niciuna dintre ele nu se poate msura cu anumite alte

    practici care nu sunt gndite n mod obinuit ca practici pentru dezvoltare rapid, dar care au

    oricum profunde implicaii asupra dezvoltrii 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

    acelai 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 potrivete unei sumedenii de

    proiecte.

  • 4

    2. STRATEGIA DEZVOLTRII RAPIDE

    2.1 Strategia general

    Putei realiza o dezvoltare rapid urmrind o strategie cu patru linii directoare:

    Evitai greelile clasice.

    Aplicai bazele dezvoltrii.

    Conducei riscurile pentru a evita ntoarcerile catastrofale.

    Aplicaii practicile orientate spre planificare (vitez, risc planificat, vizibilitate):

    o Care mbuntesc viteza dezvoltrii, permindu-v s livrai produsul mai

    repede.

    o Care reduc riscul planificat, permindu-v s evitai depiri uriae ale

    planificrii.

    o Care fac vizibil progresul, permindu-v s nlturai aparent unei dezvoltri

    ncete.

    Figura 2.1 Cei patru piloni ai dezvoltrii rapide

    Pilonii din figur ilustreaz cteva aspecte importante:

    Sprijinul optim pentru cea mai bun planificare posibil este cnd avem toi pilonii i cnd i

    facem pe toi ct mai puternici posibil. Fr sprijinul primilor trei, abilitatea voastr n

    planificare va fi n primejdie putei s folosii cele mai solide practici orientate pe planificare,

    dar dac facei greeala clasic de a scurta timpul destinat calitii produsului n faza timpurie

    a proiectului, vei pierde timp corectnd defecte atunci cnd este cel mai scump. Proiectul va

    ntrzia.

    Dac srii peste principiul de dezvoltare de a crea un proiect bun nainte de a lucra efectiv,

    produsul va avea de suferit cnd concepia lui se va schimba n unele pri prin dezvoltare i

    proiectul va ntrzia. i dac nu conducei riscurile, putei afla chiar nainte de data lansrii c

    un subcontractor-cheie este n urm cu trei luni fa de planificare. i vei ntrzia iari.

    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 fii capabili s realizai o planificare optim fr practici orientate pe

    planificare.

    Putei realiza ns cea mai bun planificare prin concentrarea numai pe practici orientate pe

    planificare? Este un act foarte dificil de echilibrat i v vei priva de sprijinul n general

    necesar.

    2.2. Cele patru dimensiuni ale dezvoltrii rapide

    n timp ce ncercai s evitai greeli i s navigai 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, organizaiile tind s vad dimensiunile pe care nu sunt axate ca fiind fixe.

    Organizaiile cele mai eficiente n realizarea dezvoltrii rapide optimizeaz toate cele patru

    dimensiuni simultan.

    Odat ce realizai c fiecare dintre cele patru dimensiuni poate furniza prghii consistente n

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

    capabil de a satisface toate prile implicate.

    2.2.1 Oamenii

    Cercetrile n aceast problem s-au coagulat cu precdere n ultimii 15-20 de ani. Este acum

    posibil s pim printre concluziile multor studii individuale i s sintetizm cteva concluzii

    generale vis--vis de tendinele cercetrilor.

    Prima concluzie este c acest aspect are cel mai mare impact asupra productivitii i calitii

    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

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

    1989).

    De asemeni, studiile au gsit variaii n performana intregii echipe de 3, 4 sau 5 la 1.

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

    cercettorii de la NASA's Software Egineering Laboratory au concluzionat c nu tehnologia

    este rspunsul; cele mai eficiente practici sunt acelea care influeneaz potenialul uman al

    dezvoltatorilor lor (Basili 1995).

    Este ct se poate de clar c orice organizaie care este serioas n ceea ce privete

    mbuntirea productivitii trebuie s priveasc mai nti spre problematica uman a

    motivaiei, lucrului n echip, seleciei personalului i pregtirii. Luate mpreun, acestea

    conteaz mai mult dect procesul, productivitatea i tehnologia. Lor trebuie s v adresai

    dac dorii s reuii.

  • 6

    Cursul se va ocupa de cteva ci prin care putei maximiza potenialul uman n scopul

    reducerii factorului timp.

    Selecia personalului pentru echipele proiectelor

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

    principii ale seleciei personalului (Boehm 1981):

    Talent de vrf Utilizai mai degrab oameni mai buni i mai puini.

    Corespondea cu job-ul Completai sarcinile n corelaie cu aptitudinile i motivaia

    personalului disponibil.

    Progresia carierei Ajutai oamenii mai degrab s se perfecioneze dect s-i forai s

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

    Echilibrul echipei Selectai oamenii care se completeaz i armonizeaz reciproc.

    Eliminarea oamenilor nepotrivii Eliminai i nlocuii membrii-problem ai echipei ct

    mai repede posibil.

    Organizarea echipei

    Felul n care sunt organizai oamenii are un efect semnificativ asupra eficienei muncii lor.

    Shop-urile de software pot beneficia de croirea echipelor lor dup mrimea proiectului,

    caracteristicile produsului i scopurile programate. Un proiect software specific poate

    beneficia de asemenea de specializarea corespunztoare.

    Motivaia

    Este puin probabil ca o persoan creia i lipsete motivaia s lucreze din greu; este mai

    probabil ca aceasta s lucreze la limit. Motivaia este aliatul potenial cel mai puternic pe

    care l avei pentru dezvoltarea rapid a proiectelor.

    2.2.2 Procesul

    Procesul include att metodologiile de managementul, ct i cele tehnice. Efectul pe care l

    are asupra planificrii dezvoltrii proiectului este mai uor de evaluat dect cel al oamenilor i

    a fost reflectat printr-o munc intens de ctre diverse organizaii. Hughes Aircraft, Lockheed,

    Motorola, NASA, Raytheon i XEROX, care s-au axat explicit pe mbuntirea proceselor de

    dezvoltare proprii, au redus la jumtate, de-a lungul ctorva ani, timpii de acces la pia a

    produsului, iar costul i defectele le-au redus de 3 pn la 10 ori (Pietrasanta 1991, Myers

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

    Unii oameni consider c atenia spre proces este sufocant i c nu exist nici un dubiu

    asupra faptului c unele procese sunt peste msur de rigide sau birocratice. Unele persoane

    au creat standarde pentru procese n primul rnd cu scopul de a se simi ei nii puternici. Dar

    aceasta reprezint un abuz de putere i faptul c se poate abuza de direcionarea unui proces

    nu ar trebui s permit defimarea beneficiilor pe care le poate oferi focusarea pe process.

    Forma cea mai comun a abuzrii de process este neglijena i efectul ecesteia este c

    dezvoltatorii inteligeni i contiincioi se gsesc pe ei nii lucrnd inefficient i la

    intersecia scopurilor cnd nu este nevoie ca ei s lucreze n acest fel. O atenie axat pe

    process poate fi de ajutor.

  • 7

    Evitarea dublrii muncii

    Dac cerinele se schimb n etapele finale ale proiectului, trebuie s-l reproiectai, rescriei i

    retestai. Dac rezult, de exemplu, probleme n faza de testare, putei fi pui n situaia de a

    renuna la elemente pe care le-ai elaborat n detaliu i de a o lua de la nceput. Una dintre cele

    mai importante ci de a salva timpul ntr-un proiect este de a orienta procesul astfel nct s

    evitai s facei acelai lucru de dou ori.

    Raytheon a ctigat IEEE Computer Societys Software Process Achievement Award n anul

    1995 pentru reducerea costurilor pentru rework de la 41% la mai puin de 10%, triplndu-i

    simultan productivitatea (Raytheon 1995). Relaia dintre cele dou elemente este una de

    substan, nu o coinciden.

    Asigurarea calitii

    Asigurarea calitii are dou scopuri principale. Primul este acela de a se asigura faptul c

    produsul lansat are un nivel acceptabil al calitii (Dei important, nu este printre scopurile

    acestui curs). Al doilea este de a detecta erori n etape n care coreciile sunt mai puin

    consumatoare de timp (i la costuri mai mici), la momente ct mai apropiate de acela n care

    au fost introduse n sistem. Asigurarea calitii este astfel o parte indispensabil a oricrui

    program de dezvoltare rapid.

    Bazele dezvoltrii

    Dei practicile standard de analiz, proiectare, construcie, integrare i testare nu produc

    planificri strlucitoare prin ele nsele, pot preveni rsucirea proiectelor spre zone

    necontrolabile. Jumtate dintre provocrile dezvoltrii 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 rmnei blocai cu dou

    sptmni 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 direcionate greit i utilizate ineficient. ntr-un proiect de dezvolatre

    rapid, este mai important dect n mod obinuit ca s obinei maximum de impact pentru

    banii planificai. Practicile cele mai bune, cum sunt birouri de productivitate, planificare

    corespunztoare i timp de lucru suplimentar voluntary, ajut pentru a fi siguri c obinei

    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. Fr un model al ntregului ciclu de via,

    putei lua decizii care sunt axate individual pe int, dar direcionate colectiv n mod greit.Un

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

    exemplu, dac avei un proiect riscant, un model de ciclu de via oriectat pe risc va fi

  • 8

    potrivit; i dac avei cerine vagi, un model de ciclu de via incremental va putea funciona

    cel mai bine.

    Orientarea spre client

    Unul dintre salturile cele mai semnificative ntre dezvoltarea tradiional de software tip

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

    nevoile i dorinele clientului. Dezvoltatorii au nvat c producerea de software conform cu

    specificaiile este numai jumtate din munc. Cealalt jumtate 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 tradional bazat pe specificaii scrise pe hrtie. S v punei de

    aceeai parte cu clientul este cea mai bun cale de a evita dublrile masive ale muncii cauzate

    de decizia clientului potrivit creia produsul pentru acre tocmai ai consumat 12 luni nu este

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

    evoluie i negociere principial v pot conferi un control rezonabil.

    2.2.3 Produsul

    Produsul este cea mai tangibil dintre cele patru dimensiuni n discuie. Dac poi reduce setul

    de caracteristici ale produsului, poi reduce timpii n cadrul planificrii produsului.

    Mrimea produsului

    Este cel mai important element singular care contribuie la planificarea dezvoltrii.

    Caracteristici suplimentare cer specificaii, proiectare, construcie, testare i integrare

    suplimentare. Reducerea la jumtate a mrimii unui program de dimensiuni medii va reduce

    efortul cerut cu aproape dou treimi.

    2.2.4 Tehnologia

    Schimbrile din unelte mai pin eficiente n unelte mai eficiente pot fi de asemenea o cale

    rapid de a mbunti 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 dezvoltrii software-ului.

  • 9

    1. GREELI CLASICE

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

    multe oportuniti de a nva din greeli.

    1.1. Efectul greelilor asupra programrii dezvoltrii

    Michael Jackson spunea ntr-unul din cntecele sale c "One bad apple don't spoil the whole

    bunch, baby". Aceasta poate fi adevrat pentru mere, dar pentru software n nici un caz. Un

    mr ru poate strica ntregul proiect.

    Un grup de cercettori de la ITT a trecut n revist 44 de proiecte n 9 tri pentru a examina

    impactul a 13 factori de productivitate asupra acesteia (Vosburgh 1984). Aceti factori

    includeau utilizarea practicilor de programare moderne, dificultatea codului, cerinele de

    performan, nivelul de participare a clientului n specificaiile cerute, experiena personalului

    i alte cteva. Ei au mprit fiecare dintre aceti factori n categorii care te-ai atepta s fie

    asociate cu o performa sczut, medie sau ridicat. De exemplu, ei au mprit factorul

    "practici moderne de programare" n utilizare sczut, medie i ridicat (figura 2.1.).

    Rezultatele desprinse sunt interesante. Modelul general artat este reprezentativ pentru fiecare

    dintre factorii de productivitate studiai. Cercettorii de la ITT au gsit c proiecte din

    categorii de la care se ateptau s aib o productivitate sczut au avut ntr-adevr

    productivitate sczut, cum este cazul irului ngust de la categoria "Sczut". Dar

    productivitatea din categoriile performanei nalte a variat foarte mult, cum este artat n irul

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

    sczut la excelent.

    Legend

    Maximum

    75 %

    Media

    25%

    Mimimum

    Procentul

    productivitii

    nominale

    + 200

    + 100

    Sczut Mediu Ridicat

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

    Fig. 2.1. Utilizarea practicilor programrii moderne

    (procente din sistemul total)

  • 10

    Faptul c acele proiecte de la care s-a ateptat s aib o productivitate sczut 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 sczut, aceasta poate constitui o surpriz. Ceea ce relev

    graficul este c utilizarea oricror practici specifice bune este necesar dar nu suficient

    pentru a atinge maximum de vitez de dezvoltare. Chiar dac facei unele lucruri bine, cum ar

    fi utilizarea la o capacitate ridicat a practicilor moderne de programare, putei face nc a

    greeal care anuleaz ctigurile pe care le-ai realizat n productivitate.

    2.1. Enumerarea greelilor clasice

    Unele practici de dezvoltare ineficient sunt alese att de des, de att de mult lume, cu

    rezultate proaste att de predictibile, nct merit s fie numite "greeli clasice". Multe dintre

    greeli au o atracie seductoare. Vrei s salvai un proiect care este n urma planificrii?

    Adugai mai muli oameni! Vrei s reducei termenele planificate? Planificai mai agresiv!

    Unul dintre contributorii cheie afecteaz negativ restul echipei? Ateptai pn la sfritul

    proiectului pentru a-l da afar! Avei de completat un proiect presant ca termen? Luai-v

    orici dezvoltatori sunt disponibili acum i ncepei ct mai repede posibil.

    Greelile enumerate n continuare au un numitor comun: nu vei accede n mod necesar la o

    dezvoltare rapid dac vei evita aceste greeli, dar n mod sigur vei ntrzia dezvoltarea dac

    nu le vei evita. Odat ce le vei nelege efectele asupra vitezei de dezvoltare, vei putea

    utiliza lista lor n ajutorul planificrii proiectului i managementului riscului.

    Pentru uurina referirii, lista greelilor a fost mprit pe cele patru dimensiuni ale vitezei de

    dezvoltare: oamenii, procesul, produsul i tehnologia.

    Oamenii

    Iat cteve dintre greelile clasice legate de oameni:

    1: Motivaie subminat. Un studiu dup altul relev faptul c motivaia are probabil efectul

    cel mai mare asupra productivitii i calitii (Boehm 1981). Tragei concluziile i din Studiul

    de caz 2.1., fcut la laborator.

    2: Personal slab. Dup motivaie, att capacitile individuale ale membrilor echipei, ct i

    relaia dintre ei care determin comportarea ca echip, au cea mai mare influen asupra

    productivitii (Boehm 1981, Lakhanpal 1993). Tragei concluziile i din Studiul de caz 2.1.

    3: Angajai cu probleme necontrolabile. Este o problem obinuit i bine neleas de

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

    Eecul n a lua atitudine fa de angajatul-problem este cea mai obinuit plngere a

    memebrilor echipei vis--vis de eful lor. (Larson 1989). Tragei concluziile i din Studiul de

    caz 2.1.

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

    fac mai mult ru dect bine. Vedei i Studiul de caz 2.1. Un accent pus pe eroism ncurajeaz

    asumarea riscurilor i descurajeaz cooperarea ntre numeroii stakeholder-i implicai n

  • 11

    procesul de dezvoltare software. Unii manageri ncurajeaz comportamentul eroic cnd se

    bazeaz prea mult pe atitudinea excesiv se poate, afectnd capacitatea de a se lua aciuni

    corective. Atitudinea se poate produce micii pai ctre adevratele dezastre. (DeMarco 1995).

    5: Adugare de personal la un proiect ntrziat. Aceasta este probabil cea mai clasic

    dintre greelile clasice. Cnd un proiect este n ntrziere, suplimentarea de personal poate lua

    mai mult productivitate de la membrii echipaei existente dect adaug noii membrii. Unii

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

    6: Birouri nghesuite, zgomotoase. Cei mai muli dezvoltatori consider condiiile de lucru

    drept nesatisfctoare. Aproximativ 60% raporteaz c nu au ori suficient linite, ori

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

    dezvoltrii.

    7: Friciuni ntre dezvoltatori i clieni. Se pot produce n mai multe feluri. Clienii pot s

    simt c dezvoltatorii nu sunt cooperani atunci cnd refuz s semneze programarea

    dezvoltrii dorit de clieni sau cnd nu pot s furnizeze ceea ce au promis. Dezvoltatorii pot

    s simt ca clienii nu sunt rezonabili, insistnd pe programri nerealiste sau schmbri ale

    specificaiilor dup ce acestea au fost fundamentate. Pot fi i simple conflicte personale dintre

    cele dou grupuri.

    Principalul efect al friciunilor este slaba comunicare, iar efectele secundare ale slabei

    comunicri includ slaba nelegere a cerinelor, slaba proiectare a interfeei-utilizator i, n

    cazul cel mai ru, refuzul clenilor de a accepta produsul completat. n medie, friciunile

    dintre clieni i dezvoltatori devin att de severe nct ambele pri iau n considerare

    abandonarea proiectului (Jones 1994). Aceste friciuni sunt consumatoare de timp i distrag

    ambele pri de la munc real din cadrul proiectului.

    8: Ateptri nerealiste. Reprezint una dintre cauzele cele mai obinuite ale friciunilor dinre

    clieni i dezvoltatori. Vedei i Studiul de caz 2.1. De asemeni, unii manageri pot intra n

    ncurctur alocnd fonduri bazndu-se pe o estimare prea optimist.

    Dei asteptrile nerealiste nu lungesc prin ele nsele programarea dezvoltrii, totui ele

    contribuie la percepia c aceasta este prea lung, iar asta poate fi aproape la fel de ru. Un

    studiu al Standish Group a plasat ateptrile 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 dezvoltrii rapide, incluznd planificarea realist, controlul

    schimbrii i introducerea noilor practici de dezvoltatre. Fr un sprijin eficiant n conducerea

    executiv, alte persoane de la nivelul conducerii organizaiei voastre v poate fora s

    acceptai termene nerealiste sau s facei schimbri care v submineaz proiectul. Lipsa unui

    sponsor executiv eficient garanteaz virtual eecul proiectului (Thomsett 1995).

    10: Lipsa convergenei stakeholder-ilor. Toi actorii majori din cadrul proiectului trebuie s-

    i uneasc eforturile. Aceasta include sponsorul executiv, conductorul echipei, membrii

    echipei, echipa de marketing, utilizatorii finali, clienii i oricine altcineva care are un interes

  • 12

    n sprijinirea proiectului, factori ai cror convergen conduce la o coordonare precis a

    proiectului.

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

    numrul 1 al succesului proiectelor este implicarea utilizatorilor (Standish Group 1994).

    Proiectele fr implicarea timpurie a utilizatorului final risc nelegerea greit a cerinelor

    proiectului i sunt vulnerabile n ceea ce privete consumul de timp ulterior n proiect.

    12: Politica plasat deasupra substanei. Iat rezultatul unui studiu efectuat pe patru echipe

    cu orientri diferite (Constantine 1995). "Politicienii" - concentrai pe relaia cu managerii lor.

    "Cercettorii" - concentrai pe cutarea i strngerea informaiei. "Izolaionitii" - retrai n ei

    nii, crend granie ale proiectului fa de non-membrii proiectului. Generalitii" - fcnd

    cte puin din toate: relaia cu managerii, cercetare, coordonare cu alte echipe pe calea

    fluxurilor normale de lucru. Iniial, "politicienii" i "generalitii" au fost deopotriv bine

    vzui de top-management. Dar dup un an i jumtate, echipa "politicienilor" a fost

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

    dezvoltarea orientat pe vitez.