Reteta de facut software

Posted by rdumitru on martie 22, 2011
Filed Under Echipa, Recrutare | 10 Comments

Ca sa te apuci sa faci software ai nevoie de o lista lunga de ingrediente si de o reteta bine pusa la punct. Asta daca vrei ca la final sa ai clienti fericiti si un cont in banca cu execedent. Pe la inceputuri reteta de baza era: Eu nu cred in minuni, eu ma bazez pe ele. Acum am mai crescut si am invatat sa-mi pastrez norocul pentru altceva decat sucessul produselor la care lucrez. Asa ca am inceput sa caut reteta, care sa scoata minunile din ecuatie. Si pentru ca sigur sunt oameni mai destepti ca mine in lumea asta am luat ideeile altora si le-am aplicat. Incet dar sigur am ajuns la o reteta care merge bine cu echipele in care am lucrat.

Se incepe cu una bucata echipa cat mai inchegata si elastica. Apoi, ca si cu orice baza trebuie sa investeti in ea, mai exact sa te asiguri ca echipa asta intelege ce inseamna sa fii Agile, si sa faci Scrum. In tot timpul asta se adauga cateva cani pline ochi de review-uri de cod, design si test cases. Si odata ce toate lucrurile astea devin o a doua natura, incepi sa amesteci usor si unit teste, teste de integrare, automatizarea testelor de regresie si tot asa. Dupa ceva timp o sa te trezesti ca vorbesti de TFP sau TDD si ca nici macar nu ai fost tu cel care a venit cu ideea. Echipa a facut-o singura, pentru ca a ajuns sa fie self-organizing. Bugurile critice devin amintiri urate, nu e un bug e un feature ramane in cartea de istorie si NPS-ul e racheta. Daca tot ce am zis mai sus o sa reuseasca, atunci in limbajul tau de zi cu zi or sa intre cuvinte ca daily scrum, velocity, sprint, burndown chart, code coverage, team capacity si maine poimaine te trezesti ca echipa ta face totul atat de bine incat tu nu mai ai aproape nimic de facut…

De saptamana asta am inceput un proiect nou nout numit Brainstorm, un tool care sa ajute echipele din Adobe sa fie Agile. Cu alte cuvinte sa-i ajute sa-si gaseasca propria reteta de facut software. Daca esti pasionat de software, daca stii (sau vrei sa inveti) ce inseamna Agile si vrei sa fii parte din echipa ce o sa foloseasca Java si Flex atunci aplica pentru una din pozitiile de mai jos:

Software Quality Engineer
Flex Developer
Java Developer

Share

Comments

10 Responses to “Reteta de facut software”

  1. Adinel on martie 22nd, 2011 18:22

    Whoa! Si ii ziceti Brainstorm!? La devops deja o sa aveti ceva Ἄτλαςsomethinsomething…
    Acum iar trebuie sa imi imbunatatesc vocabularul cu cuvintele boldate de mai sus :|

  2. tudor on martie 23rd, 2011 14:30

    Sa nu exageram cu proiectul nou nout :) cine stie si l-a folosit ii stie si vechimea in firma si ca e deja utilizat

  3. rdumitru on martie 23rd, 2011 14:38

    Ai dreptate Tudor, produsul exista din 2009 insa proiectul a ajuns in Romania acum. Cu o echipa noua si un roadmap nou pentru mine se califica la proiecte nou noute :)

  4. Valentin on martie 23rd, 2011 16:48

    Mai bine scriai articolul in engleza sau puteai sa pui definitiile la sfarsit. I know Google is my friend but so’s the x button !

  5. x on martie 26th, 2011 00:46

    si apoi vin francezii(sau americanii in cazu’ vostru) si zic, azi la 18.00 vreau buildu’ ( si e 17.40). si project managera urla la toti … ca trebe facut acu. si oricum e un un hasellbug…
    viata..

    si apoi ajungi acasa, deschizi Calculatorul (Care e oricum mai bun, ca ala de la munca…..) si incepi sa Gandesti.

    so…nu..nu va trimit cv-ul..
    o sa va trimit app-ul ;) odata..
    in rest…sanatate

  6. Adrian on martie 26th, 2011 01:08

    Te rog: este “heisenbug” nu “hasellbug”. Am stiut eu ca bug-urile astea nu apar pe Calculatoarele mai Puternice de Acasă și ma simt împlinit acum că mi-a confirmat cineva.

  7. Ionel on aprilie 8th, 2011 16:15

    Iar prin SCRUM si Agile evident intelegeti metoda perfecta prin care se pot justifica unele job-uri total inutile altfel. Nu mai exista bug-uri, he he.. Desigur. E surprinzator cum, definitia veche, aceea conform careia daca vrei sa faci soft bun, angajezi programatori buni, nu mai functioneaza. Acum angajezi SCRUM Masteri care iti explica in fiecare dimineata ce si cum, la sedintele zdrobitoare pentru intelect. Stiu, stiu, SCRUM is allmighty. Asta evident, pana ce va prindeti ca de fapt Kanban e mai bun, si evident pana se prind si aia de mai sus ca de fapt nu e nevoie decat de 5% din programatorii existenti, si doar cei mai buni vor ramane. Lucrand la fel ca dintotdeauna, inteligent!

  8. rdumitru on aprilie 8th, 2011 17:03

    @Ionel: ne place sa lucram inteligent si sa angajam cei mai buni oameni pentru toate pozitiile pe care le avem deschise, nu doar cele de programatori. Uneori cat de repede si cat de bine reusim sa facem software nu depinde exclusiv de competentele programatorilor. Si aici vine rolul unei metodologii de dezvoltare , sa-ti ofere suportul necesar pentru a crea software mai bun intr-un timp mai scurt. SCRUM si TDD te ajuta sa razpunzi mai repede clientilor tai si sa le oferi o calitate mai buna.

    Iar daca in daily scrum-urile la care ai participat tu Scrum Master-ul iti explica ce si cum, inseamna ca lucrurile nu erau chiar corecte. Rolul lui este sa asculte si sa ajute echipa sa depaseasca impedimentele nu sa le explice in timpul sedintei ce au de facut. De exemplu in echipele in care am lucrat Scum Master-ul era deobieci un membru al echipei fie el programator sau QE.

  9. Ionel on aprilie 8th, 2011 17:31

    De fapt, acolo intervine rolul coordonatorului de proiect (in sensul de product owner, nu project manager). Persoana respectiva asigura fluxul necesar de informatie, agregare de idei, ajustat traiectorii, etc.

    La sedintele de SCRUM la care am participat pana acum, in general master-ul era un membru al echipei, dar se intampla sa fie si o persoana din alta echipa. Total inutile sedintele respective, la fel ca si sprint planningul si toata pleiada agila (vorbesc doar de nuantele SCRUM/Kanban). In fapt, era nevoie doar de un Requirements Engineer, care sa se ocupe initial de stabilirea viziunii globale, ulterior de ajustare dinamica (combinat cu PO-ul) – de fapt asta inseamna a lucra agil.

    Ca toata tevatura in jurul SCRUM e inutila, va descoperi toata lumea in cativa ani (adu-ti aminte si revino la comentariile de azi mai tarziu).

    In final, o poveste scurta. Am fost contactat de o companie X (ceva mai mare decat adobe) cu vreo cateva luni in urma. Postul era de Agile Team Lead (o rocada de cuvinte din zona respectiva) si in practica vroiau pe cineva sa ii ajute sa implementeze metodologii SCRUM, pe plan global, in cadrul firmei. Le-am explicat detaliat ce am incercat sa explic pe scurt aici, intr-un interviu telefonic. A doua zi am fost sunat pentru o noua pozitie, team lead pentru o echipa care se ocupa de inovatii, totul bazat pe interviul precedent. Nu aplicasem la nici unul din joburi si am refuzat oricum. Dar ideea se mentine. SCRUM inca mai merge la behemonti sau firme medii care nu stiu sa-si dozeze bugetele. Totusi, in fiecare firma mare exista echipe care fac soft cu adevarat, unde ideea de SCRUM nici nu exista. Din pacate intuiesc retinerea Adobe-ului de a avea o astfel de echipa in RO. Cam la fel au patit si cei de la Amazon din Iasi. S-au dus anii de inovare, acum au sediu nou, mai multi oameni, si evident fac mai putin soft ;) .

  10. Daniel on aprilie 21st, 2011 12:18

    @Ionel: interesant comentariul tau.
    Am mai auzit critici adresate Scrum-ului si metodelor Agile in general, dar e prima data cand vad pe cineva spunand ca daily stand-up meeting-ul e inutil.
    Din experienta mea, cei care nu reusesc sa puna in valoare avantajele agilitatii fac de fapt lucrurile incorect si apoi folosesc metodologia ca si scuza. Daca vrei sa intelegi mai bine despre ce e vorba si si sa evoluezi impreuna cu industria software, iti recomand lectura din autori consacrati in materie(Schwaber, Beck, Cockburn si multi altii). Vei vedea ca lucrurile nu sunt doar albe sau negre si e mai mult in spatele agilitatii decat o serie de reguli. Te asteptam apoi pe la noi – ne plac dezbaterile, mai ales daca sunt legate de software ;) .

Leave a Reply