21 iunie 2015

Management si metodologii de dezvoltare software

Scrierea de programe software este una din meseriile cele mai nereglementate. Cu ajutorul unui limbaj de programare, o problema se poate rezolva prin mai multe modalitati, folosind mai multe abordari. Uneltele pentru dezvoltatori ofera o libertate foarte mare pentru a putea rezolva orice tip de problema. Framework-urile vin sa ajute dar nu sunt acolo pentru a impune modul in care sa muncesti, nu ajuta la stabilirea calitatii codului sau la crearea de solutii scalabile.

S-ar putea crede ca un dezvoltator experimentat este mana ceareasca intr-o companie. Insa experienta nu dovedeste decat lovirea de multe probleme tehnice iar valoarea unui senior este masurata in productivitate, nimeni nu se asteapta ca un senior sa se alinieze automat la obiectivele interne ale companiei.

Am compilat cateva metodologii de rezolvare a problemelor folosind limbaje de programare care ar trebui sa ajute compania pentru cresterea productivitatii, a eficientei, a scalabilitatii, a indeplinirii obiectivelor, a managementului schimbarilor, a minimizarii riscurilor, a cresterii calitatii produselor.

1. Orice efort de dezvoltare trebuie sa porneasca de la taskuri simple spre cele complexe
Dezvoltatorii primesc sarcini in batch-uri, adica in liste de task-uri pe care trebuie uneori sa le estimeze, dar intodeauna sa le rezolve. In majoritatea cazurilor pe nimeni nu intereseaza cum isi organizeaza dezvoltatorul munca, toti sunt interesati de output-ul final si de alinierea lui cu specificatiile. Insa ordinea in care tratezi task-urile are un impact asupra obiectivelor companiei mai mult decat se poate crede. Dezvoltatorii se autostimuleaza sa rezolve mai intai task-urile grele, pentru ca ele sunt cele mai incitante si ofera cea mai mare recompensa prin satisfactie. Astfel task-urile simple sunt rezolvate ultimele cand interesul pentru ele este scazut, si cand timpul necesar aproape nu mai este suficient deoarece task-urile interesante au tendinta de a fi prelungite pentru a putea fi savurate in totalitate. Rezolvand task-urile mici la inceput:
- se pastreaza bucata interesanta pentru final, motivand creierul sa rezolve problemele simple pentru a trece cat mai repede la cele interesante
- dezvoltatorul este introdus treptat in atmosfera proiectului care poate n-a mai fost vizitat o lunga perioada, astfel se face o pregatirea pentru task-urile importante

2. Limbajele au fost create pentru a dezvolta mai intai cadrul-structura si apoi pentru a rezolva probleme
Dezvoltatorii folosesc intotdeauna direct sintaxa limbajelor pentru a rezolva probleme. Acest mod de abordare duce cu timpul la cod greu de inteles, nestructurat, care dupa o perioada nu poate fi inteles nici macar de autor. Putini stiu ca limbajele exista pentru a transpune logica problemelor in structuri tip pseudocod, in metode numite corespunzator, in entitati separate structurate corect. Lucrand astfel:
- codul va putea fi citit si inteles dintr-o singura privire
- schimbarile ulterioare de functionalitate vor forta dezvoltatorul sa incadreze noile cerinte pentru a se armoniza cu structura cadru, rezultand o solutie mentenabila si nu una dezorganizata
- structurile cadru vor evolua de la particular spre general odata cu marimea solutiei, rezultatul fiind scalabilitatea acestora, modularitatea lor

3. Faza de proiect presupune etapele initiere, dezvoltare si la final testare
Procesul de dezvoltare software trebuie sa parcurga anumite etape fara de care se va dezvolta haotic si se vor introduce erori in produsul final datorita managementului defectuos. Cele mai frecvente erori sunt cele legate de nerespectarea procesului de dezvoltare. Dezvoltatorii primesc date, informatii, specificatii brute, cazuri netratate la nivel superior, toate acestea in timp real pe toata durata etapei de dezvoltare software. Acest lucru duce la crearea de produse de proasta calitate deoarece este sarita etapa de initiere care presupune: existenta unui business case, comunicarea scopului si a beneficiilor finale urmarite tuturor celor implicati in proiect, analiza de business cu use case-uri, analiza tehnica, arhitectura, si in final specificatii care sunt input pentru etapa de dezvoltare. Sunt frecvente cazurile cand etapa de testare este sarita sau este efectuata tot de echipa de dezvoltare care nu are nici interesul nici competentele necesare.

Sunt mult mai multe de spus pe aceasta tema insa daca se vor respecta cele trei indicatii de mai sus ca prima faza de reproiectare a procesului de dezvoltare software, compania va avea un avantaj competitiv fata de multi competitori din piata. Eficientizarea dezvoltarii software nu este usoara si presupune accesul la cunostinte atat tehnice cat si de management general de organizatie.

Niciun comentariu:

Trimiteți un comentariu

Comentariu

Postări populare