miercuri, decembrie 14, 2011

Unelte mici si utile

Cateva unelte mici si interesante pentru testare securitare, teste de performanta si testarea compatibilitatii cu diverse browsere:


  • TCPMon - pentru monitorizarea traficului HTTP
  • SoapUI - pentru testat WS (SOAP)
  • JMeter - pentru teste de load
  • Zed Attack Proxy - pentru identificarea problemelor de securitate
  • WebScarab - pentru testarea problemelor de securitate
  • IETester - verificarea compatibilitatii cu diverse versiuni de IE
  • Rest Client - client pentru REST WS
  • Slenium IDE - inregistrare si rulare teste functionale

marți, iunie 07, 2011

De ce agile?

Dupa toti acesti ani de programare, Agile tinde sa fie pentru mine abordarea cea mai naturala pentru dezvoltarea de software. Unul din principiile agile nescrise ma incanta cel mai mult: echipe care se organizeaza singure (ofera-le mediul de lucru si suportul de care au nevoie, si ai incredere ca-si vor face treaba). Asemanarea cu echipele sportive mi se pare foarte potrivita. Acolo pe teren toti membrii comunica si joaca - intradevar este o anumita organizare dar nimeni nu-i poate aseja intr-un plan prestabilit - nici nu s-ar putea din cauza dinamicii jocului. Exista intradevar un leader care este capitanul dar antrenorul ramane pe banca. Sau mai demult era si antrenor jucator. Aceasta pozitie de leader seamna in Scrum cu cea de Scrum master. O introducere in Scrum facuta chiar de JEFF SUTHERLAND:



Una din metodologiile primare de dezvoltare (vechiul stil) este waterfall (cascada). Modelul de dezvoltare waterfall bate in cuie fazele prin care trece proiectul (ca apa care cade intr-o cascada la vale si nu se mai poate intoarce): analiza, design, implementare, testare, instalare, mentenanta. Considera ca fiecare dintre aceste etape este ireversbila: se considera ca in faza de design e imposibil sa intervina greseli sau ca o cerinta de functionalitate nu se poate modifica. Totul este coordonat de un plan initial. Trebuie tinut cont de asemenea ca intreg acest ciclu de viata ireversibil tine la ordin de luni (poate chiar ani) pana cand se va face o prima livrare. Aceasta abordare este falsa deoarece practica demonstreaza ca greseli se fac oricand si ele trebuie sa apara cat mai devreme la suprafata (in saptamani si nu luni - ani).

Solutia pentru problemele din waterfall sunt metodologiile iterative (si incrementale pentru ca functionalitatile implementate intr-o iteratie sunt facute end to end - IID) care incearca sa livreze software functional (eventual doar intern si nu extern) cu o anumita cadenta de timp (fixa sau variabila). In aceasta categorie intra UP (RUP) dar si metodologiile agile (Scrum, XP). Ce apropie UP (RUP) de waterfall este ceremonia necesara in procesul de dezvoltare: un set de documente care trebuiesc scrise (centrare pe documente), plan initial facut in faza de inception, cerinte functionale nemodificabile dupa iteratiile in care se face analiza (sau mai grav fiecare faza (R)UP poate deveni un mic waterfall de cateva luni din cauza intarzierilor generate de neatingerea scopului propus). Pentru detalii fazele RUP sunt urmatoarele:
  1. Inception phase: Scope the project, define the business case.
  2. Elaboration phase: Refine the requirements, establish an architecture, mitigate the most technical risk.
  3. Construction phase: Complete the system up to a point where it can be deployed in limited context ("beta version").
  4. Transition phase: Finish the product and reach product final release.
O practica proasta in metodologiile neagile (includem si UP si RUP in aceasta categorie) este constituirea de echipe pe componente (subsiteme) care lucreaza in paralel asteptand sa se integreze printr-o interfata comuna negociata in prealabil (exista ownership pe cod si deci codul nu este partajat). Sau mai complicat cazul in care se lucreaza in paralel in diferite layere ale aplicatiei asteptandu-se o integrare finala. Faza finala de integrare a componentelor se poate dovedi mai costisitoare decat dezvoltarea componentei in sine. Dezvoltarea in paralel duce la WIP (in Lean = work in progress) pentru ca partile se vor dovedi folositoare doar la final, dupa procesul de integrare. Pana atunci sunt WIP deci nefolositoare si nu pot aduce nici un beneficiu (existand mereu riscul de a fi rescrise pentru a fi posibila integrarea).

Impartirea pe componente induce si alte probleme: aparitia de noi roluri in echipa (de fapt constituirea de noi echipe specializate). In acest sens firmele aleg sa-si formeze departamente specializate: DEV, QA, etc (visul oricarei companii este sa aiba un proces prin care sa livreze in masa software pe banda rulanta - proiecte multe = multe incasari). Vor aparea business analisti pentru analiza functionalitatilor, arhitecti pentru definirea interfetelor intre componente, release managers - cel care trebuie sa aiba grija de release-ul feature-lor. De asemenea o echipa de testare care asteapta inevitabil ca echipa de dezvoltare sa predea produsul in testare.

Apare si rolul de project manager care trebuie sa gestioneze toate celelalte roluri si artefactele pe care acestea le produc. Trebuie sa faca un plan inital (care practica va demonstra ca se va schimba saptamanal) si sa incerce sa puna presiune pe toti ceilati oameni - mai mult sa-i tina ocupati decat sa-i faca productivi sau produsul mai bun. Acest lucru pentru ca alocarea de task-uri si estimarile initiale nu vor fi niciodata conforme cu realitatea iar viteza cu care se dezvolta componentele este imprevizibila. Se creaza un ciclu de viata pentru proiect iar rolul managerului este acela de a avea grija de livrabile si de procesul de hands off/hands on, un proces dificil (si considerat ireversibil de waterfall). Cel mai complicat rol cu project managerul este ca ei cred ca adevarul se poate ascunde dupa rapoarte si numere (exista in Lean un principiu numit Go See care scoate pe manager din birou sil trimite in linia intai a luptei).

Iata o parere foarte interesanta despre rolul de project manager:
We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.

Orice rol in plus implica complexitate din perspectiva responsabilitatilor (nu toti sunt la fel de responsabili) + creste complexitatea comunicarii. De asemenea poate aparea problema unei teoretizari accentuate din partea unor roluri (PM, etc) - mai ales a celor care nu participa efectiv in dezvoltarea de zi cu zi a proiectului in partea lui cea mai vie care este codul. Toate aceste roluri si echipe dintr-un proiect pleaca de la idea falsa ca un om nu e capabil sa dezvolte end to end ci doar pe o mica bucatica de cod: adica componenta pe care o implementeza. Dar experienta arata ca exista oameni care pot sa faca singuri functionalitati end to end fara nici o problema - in fapt sunt oameni care fac de zeci de ani programare zi de zi. Cu toate ca nu se pune problema ca ei sa faca tot produsul - ei pot acoperi zone largi din proiect (intr-o echipa de fodbal nu e doar un singur jucator care alearga pe tot terenul).

Solutia ar fi crearea unei echipe totale (asa cum sunt echipele agile - Scrum de exemplu) - care sa stie sa implementeze orice functionalitate a apliactiei end to end si nu in izolare. Echipa trebuie sa colaboreze si sa se integreze zi de zi (exista toate unelte pentru integrare continua - VCS, CI server). Echipa trebuie sa comunice in fiecare zi: stand up meetings. Toate skil-urile enuntate mai sus ar trebui sa se regaseasca in aceasta noua echipa capabila sa implementeze colaborand o intreaga functionalitate end to end (de la cerinte, design, implementare si pana la testare). Poate ca echipa seamana in acest caz cu o grupa de lupta din armata in care pe langa cei care manuiesc pusca exista si un lunetist si un aruncator de grenade si un mitralior (in fapt puterea de lupta a grupei sta in cooperarea tuturor armelor; de fapt se poate zice ca in programare se duce o lupta cu complexitatea).

Exista si o solutie extrema (si neagila) pe care am observat-o la unele companii, aceea de echipe de soft chirurgicale in care exista doar un rol important si anume cel de chirurg. Pe langa el stau cei care ii pregatesc instrumentele (de obicei juniori fara experienta), dar el este singurul care stie sa opereze - stie sa lucreze end to end. Au fost astfel de echipe in experienta mea - cu siguranta am ramas impresionat de chirurg, dar nu de echipa in sine - practic fara aceata persoana de baza echipa nu e nimic. Partea negativa in aceasta abordare este imposibilitatea refolosirii unei echipe si in alte proiecte (fara chirurg) - si mentalitatea gresita care impiedica o colaborare adevarata intre membrii echipei (cu toate ca se poate respecta si in acest caz principiul: intregul este mai mare decat suma partilor).

Dar cei care programeaza de ani de zile (si nu au ales sa faca management dupa 2-3 ani de programare - un flagel al companiilor de soft de pe la noi) cred ca simt ca sansele de a pierde bataliile cu metodologii neagile (waterfall, UP, RUP) sunt foarte mari. Cred ca toata zarva din jurul dezvoltarii agile (XP, Scrum) si lean (Kanban) are un sens. E o misare in randul dezvoltatorilor si nu a managerilor - mai mult un simtamant al celor care fac programare zi cu zi. Iarasi nu e o miscare impotriva project managementului clasic, e doar o constatare ca acesta este neproductiv si trebuie cautate alte cai alternative.
  • XP (agile) pare a fi mai preocupata de cod si unelte pentru productivitate
  • Scrum (agile) pare a fi mai interesata de dezvoltare in echipa
  • Kanban (lean) pare a fi orientata mai mult pe produsul final

marți, aprilie 05, 2011

Fabrica de soft

Chiar daca nu are legatura cu programarea (sau poate ca da - sa ne gandim ca am construi o fabrica de soft) o sa sumarizez cateva impresii pastrate in niste notite dintr-o vizita facuta intr-o fabrica de masini (undeva in anii trecuti cand lucram pe un poiect din industria da constructii masini):

  • in primul rand este impresia de integrator pe care mi-a dat-o firma care producea masini: componentele sunt produse de diversi (chiar si in Romania chiar daca fabrica nu era in tara); de asemenea robotii si celelalte unelte sunt produsi de diversi; firma producatoare de masini pune in schimb sigla ei pe masini pentru ca ea le poduce si are know-how-ul sa faca asta
  • aproape toata partea initiala este robotizata si robotii de acolo sunt in totalitate: KUKA (de pe kuka.com poti cumpara si tu un robot care sa-ti automatizeze un proces); fiecare robot poate face un set de operatii; sunt programati sa lucreze intr-un anumit fel, un acelasi robot putand sa faca mai multe lucruri daca este programat corespunzator si i se aplica o unealta corespunzatoare (poate sa sudeza dar si sa vopseasca spre exemplu)
  • caroseria si partea de motor cu axul masinii se fac separat (in paralel) si se unesc la un anumit momet care se vede foarte clar pe bada de lucru - rezulta viteza de executie
  • robotii nu sunt fixati in pamant - e o suprafata plana pe care se aseaza robotii fixati in niste stative; probabil in felul asta fabrica se poate muta foarte usor in alta parte
  • banda de asamblare finala (partea manuala) se poate accelera sau nu pentru a accelera sau nu ritmul de productie
  • masinile sunt deja comandate si asamblarea optiunilor cerute se face conform cerintelor pe parcursul fabricarii
  • deabia de la un moment dat masina capata identitate prin inscrierea numarului pe sasiu - probabil clientul primeste o confirmare efectiva (daca e o problema cu masina in procesul de productie dupa scrierea numarului de sasiu - masina este practic aruncata)
  • o masina se fabrica de la 0 in 4 zile
  • cladirile fabricii sunt legate prin coridoare pentru transport rapid - eventual benzi de transport
  • partea initiala de fabricare a masinii este aproape total automatizata; partea finala este aproape total manuala (pe banda care ruleaza, muncitorul ''blue worker' se urca in masina si excuta un set de operatii; cand masina ajunge la un anumit marcaj, muncitorul iese pentru a permite altuia sa intre si sa faca alt set de operatii; muncitorii se rotesc intre ei pentru a nu face doar un set de operatii)