PixMe WeBLog

Daca esti programator si te-ai decis sa faci pasul catre management de proiect atunci va trebui sa ai cateva notiuni de baza in legatura cu procesele si activitatile de implementare, metodologii de dezvoltare etc.

Cele mai simple intrebari care ti se vor pune la interviuri sunt cele generale, in care ti se cere spre exemplu sa numesti etapele prin care trece un proiect, si care sunt atributiunile tale ca manager de la inceput pana la sfarsit.

Raspunsul minimal ar fi: primirea specificatiilor intr-un format formal, validarea specificatiilor, estimarea timpului necesar dezvoltarii, dezvoltarea in sine (care e specifica proiectului), testare/QA, livrare, feedback de la client.

In tot acest proces va trebui sa asiguri un “document repository” si o modalitate de tracking a evolutiei taskurilor. Pentru asta exista mai multe tooluri, pe unele dintre ele o sa le enumar mai jos:
- XWiki - poate fi folosit ca document repository, content manager sau knowledge base… oricum un tool util in procesul de dezvoltare.
- Pentru gestiunea evolutiei taskurilor exista un milion de softuri. Eu sunt nevoit sa folosesc Rational Portofolio Manager care din pacate e un mare bullshit. Se poate folosi spre exemplu T3S de la Sourceforge.
- Bugzilla - pentru managementul procesului de testare, sau TestLog.

Prima etapa in dezvoltarea unui proiect este faza de validare a specificatiilor in care responsabilitatea Team Leaderului este aceea de a se asigura ca a inteles cerintele clientului si ca documentatia este clara.

In ce priveste validarea documentatie de proiect lucrurile sunt specifice dar Team Leaderul trebuie sa se asigure ca deadline-ul agreat poate fi indeplinit in la timp si la calitatea ceruta de client. Asadar apar doua obiective fundamentale: timp si calitate.

Urmeaza partea de alocare a resurselor. Pentru asta este de recomandat ca in echipa sa existe un document “skills matrix” care sa specifice nivelul de cunostinte al fiecarui membru. Aici e de vorbit o saptamana, pentru ca intervin concediile, riscurile, worloadul, productivitatea, overlapingul unor taskuri etc. Sunt calcule complexe si nu voi insista acum.

Dezvoltarea propriu-zisa este specifica fiecarui proiect in parte, Team Leaderul trebuie sa asigure o alocare cat mai eficienta a taskurilor. Pentru aceasta trebuie sa identifice acele activitati care pot fi executate in paralel si sa le aloce in consecinta.

De alftel exista mai multe metodologii de implementare a codului. Le voi enumera pe cele mai cunoscute:
- Cascada – etapele procesului sunt parcurse secvential (validare specificatii, estimari, dezvoltare, test etc.).
- Dezvoltarea Rapida – fara reguli. Fiecare face ce poate cat poate cand poate. Se folosesc mult brainstorming-urile, workshopurile etc.
- Prototipul – se creaza o functionalitate minimala dupa care se pune cod peste pentru crearea unui prototip din ce in ce mai complicat pana rezulta cel final.
- Spirala – cascada plus prototip.
- Sincronizare si stabilizare – taskurile sunt executate in paralel si puse cap la cap periodic.

Fazele de testare sunt urmatoarele: teste de unitate, testare functionala, integrare, sistem, user acceptance. Fiecare proiect are “specificitatile” sale asadar trebuie agreat inca de la inceput care parte de testare este obligatorie. In general testele de unitate sunt executate de programatori, deci sunt obligatorii. Testarea functionala poate fi executata fie de programatori fie de testeri asadar incepe sa fie discutabil. In cazul in care echipa dispune de testeri va executa atat testele functionale cat si pe cele de integrare. In ce priveste testele de sistem lucrurile devin iarasi discutabile. Testele de acceptanta sunt executate de client.

Conceptul de Quality Assurance mai contine pe langa partea de testare propriu-zisa partea de Quality Engineering si partea de testare a performantei. Conceptul Quality Engineering consta in gasirea unor solutii mai bune de business logic, application logic sau chiar de implementare. Un approach interesant pe care l-am si exerimentat a fost atunci cand pe un anumit proiect QE-ul era cel care “traducea” specificatiile venite de la client creand specificatiile functionale.

Urmeaza partea de livrare, in care trebuie specificate deliverables-urile, versiuni si documente. Iar in final urmeaza partea de feedback din partea clientului care este foarte importanta pentru o faza ulterioara dezvoltarii si anume cea a mentenantei.

Acestea ar informatiile minimale de care ai nevoie la inceput in ce priveste managementul proiectelor software. Bineinteles mai exista si altele dar cam de aici se pleaca.

Voi reveni cu cateva consideratii despre leadership.

Pe aceeasi tema:

1. Ghidul unui IT-ist
2. Interviuri IT
3. Tipuri de motivare
4. Intre-o mie de cuvinte doua labe se separa
5. Ce se mai cauta pe net
6. Intrebari si raspunsuri pentru interviuri Java (2)
7. Calitatea aurului

3 Raspunsuri la “Etapele implementarii unui proiect IT”