CUM LUCRĂM (pe înțelesul tuturor) ?
Structura organizatorică a unei echipe care lucrează la un proiect normal ca anvergură este:
- Coordonatorul de proiect (project manager)
- Arhitectul proiectului
- 4 programatori din care unul este șef peste ceilalți
- Technical writer
- 2 persoane QA (Quality Assurance)
- o persoană pentru business requirements
- Project builder
Project manager (PM)
De cele mai multe ori nu este programator. Mediază toate ședințele interne de lucru ale programatorilor care sunt la nivel de detaliu și stabilește reguli interne pentru programatori. PM este ca un fel de vătaf sau judecător, ascultă părerile tehnice ale tuturor și apoi hotărăște acea soluție care devine apoi literă de lege pentru toată lumea.
El urmarește ca programatorii să pună comentarii în surse, el trimite email-uri la programatori și îi urgentează, el defalcă munca la programatori și stabilește cine și cât lucrează, cu termene foarte precise, la nivel de zi. El are o diagramă mare, de obicei lucrează cu aplicații de tip Project, și pe baza specificațiilor tehnice zice: „Vrem să terminăm modulul de facturare într-o lună de zile”. Ce trebuie la asta ? 5 ecrane, o listă, o logică de prelucrare a datelor, o logică de salvare în baza de date, de listare, etc. El împarte munca pe submodule la nivel de ecran. El zice cine face ecranele 1,2,3 și în câte zile, cine lucrează la nivelul de printare și în cite zile trebuie terminată munca.
Face sedințele de lucru săptămânale cu programatorii din curtea lui și stabilește cu procent de „cât” la sută este terminat din „cutare” modul și dacă ne putem încadra în termene. Project managerul este cel care evaluează resursele și el spune că mai am nevoie , de exemplu, de un programator și de un QA. El hotărăște și trebuie să demonstreze că mai are nevoie de atâția programatori, el evaluează câte resurse are nevoie. Vede că într-o lună nu a terminat decât 6 ecrane din 60 și atunci trage un semnal de alarmă. PM este cel care stabilește calificative pentru angajați.
Șeful programatorilor
El este programatorul cu cea mai mare experiență. Poata sa fie cel mai bătrân, cel mai cumsecade, cel mai cu experiență, în orice caz nu cel mai impulsiv. Este o chestie onorifică, el trebuie să aibă relații bune cu QA-ul, cu toți programatorii. El trebuie să fie totuși ceva mai bun decât ceilalți. Dar el lucreaza cot la cot cu ceilalți fără nici o diferență. El este acel care are în grijă repartizarea bug-urilor raportate de QA pentru fiecare programator.
Arhitectul
Este o persoana care are cea mai mare experiență, vine cu o paletă de soluții, știe în ce lucrează programatorii și el alege cea mai bună cale de compromis între o soluție tehnică de virf sau una pe care o poate dezvolta cu oamenii pe care îi are în curte. El alege arhitectura de lucru, mediile de dezvoltare, editoarele, mediul de scriere și debugging, Uneori, arhitectul poate să fie prin cumul de funcții și șeful programatorilor dacă are și abilitățile de comunicare necesare.
Technical writer
Orice produs se livrează cu o specificație tehnică care este greu de scris în avans. Aceasta va descrie foarte precis, ecran cu ecran cum funcționează aplicația. Se ajunge la nivelul x. Se apasă butonul OK care face să se întâmple următorul lucru, etc, etc. E bine să se facă în timpul dezvoltării produsului și nu la final. Asta rezolvă și problema training-ului la beneficiar. Cei de la QA și de la furnizor și de la beneficiar stau în față cu documentația tehnică elaborată de el și verifică dacă într-adevar se petrece „cutare” lucru.
Project builder
Este cel care se ingrijește de procedura de deployment la client. El face RPM-urile sau kit-ul de instalare, make-urile, inițializările bazelor de date, scripturi pentru instalare și verificare. El este persoana care periodic (săptămânal) face migrarea aplicației din rețeaua programatorilor în rețeaua de QA. Tot el este și persoana care face deployment-ul aplicației în forma beta la beneficiar în vederea testării și controlului calității. Poate fi și unul dintre programatorii care au mai puține sarcini de făcut și care cunoaște mai bine și hardware-ul clientului și care are și cunoștințe mai bune despre sistemul de operare folosit. Arhitectul proiectului, daca nu are altceva de facut, poate fi prin cumul de funcții și project builder.
Cum lucreaza echipa de software ?
La furnizor există 2 rețele diferite (din punct de vedere logic):
- rețeaua de dezvoltare a programatorilor care lucreaza cu CVS și tot dichisul
- rețeaua de QA la care, săptămânal sau mai des, se creeaza tag-uri cu versiunile stabile (milestones) din CVS-ul de lucru al programatorilor și se varsă în rețeaua de QA, inclusiv cu tot cu bazele de date de test astfel încât QA lucrează cu niște versiuni bine definite și relativ stabile.
Trebuie să existe în mod obligatoriu un sistem de bug tracking cum ar fi Bugzilla cu care lucrează cei de la QA. Oamenii de la QA care nu este necesar să fie chiar programatori, stau in față cu documentația tehnică scrisă de technical writer și iau produsul la testat. Apasă altceva decit codul produsului și vede că nu i-a afișat denumirea și a sarit pe alt câmp decât ăla pe care trebuie. Imediat se duce și introduce acest bug în sistemul de bug-tracking. Îi dă o evaluare (critic, mediu, îmbunătățire) , scrie detaliat modului în care apare și cum se reproduce defectul și apoi trece mai departe.
QA participă și ei la ședințele săptămânale făcute de PM. Șeful programatorilor împarte săptămânal bug-urile din sistem și le asignează pentru rezolvare individual la fiecare programator, uneori chiar la cel care a facut modulul respectiv dar în funcție de acoperire și experiență la oricine altcineva. PM-ul verifică săptămânal lista de bug-uri nerezolvate, asignate, în curs de rezolvare, clasate și îl stresează pe programatorul șef să reducă numărul de bug-uri din aplicație. Rezolvarea bug-urilor nu intră în programul obișnuit de 8 ore, ele se rezolva de către programatori în timpul lor liber.