printf(" SaltwaterC ");

Vineri și sâmbătă subsemnatul și Ciprian și-au mișcat fundurile pătrățoase până la Cluj pentru o întâlnire informală anunțată de către AgileWorks Romania, ca urmare a efortului curent de a ne ‘agiliza’. Deși inițial s-ar fi anunțat mai multă lume, prezența clujeană a fost destul de restrânsă – ceea ce într-un fel a fost trist, din moment ce au apărut și speak-eri de talie mondială ce în mod normal ar veni pe finanțe dese la o conferință. Noi i-am prins pe ‘moca’. Cei ce au ajuns totuși, în ordinea în care au stat la masă și s-au prezentat:

- Mihai Brehar

- Maria Diaconu

- Aici ar trebui să am un nume, dar am un lapsus în schimb

- Ovidiu Negrean

- Ciprian Stăvar

- Ștefan Rusu (adică subsemnatu’)

- Alex Bolboacă

- Paul Nagy

- Jurgen Appelo

În fine, timpul a fost scurt, au fost ceva probleme cu locația, s-au propus mai multe teme, s-a vorbit în mare parte despre estimări. Am trecut repede la fapte, cu berea în față (am specificat: cadru informal) dar cu atenția spre Agile. Paul în special și restul au oferit câteva informații valoroase:

- estimările se pot face pe task-uri ce nu depind de alte task-uri. Un dezvoltator pricepe mai bine care-i treaba cu dependința.

- este mai ușor să măsori în unități relative comparat cu unități bine stabilite. Exercițiul a constat în faptul că l-a pus pe Mihai Brehar să estimeze distanța dintre ei. Răspuns: 1,5m. Următoarea chestie a fost: pune degetul unde crezi tu că este jumătatea distanței dintre noi. Ochiometric a fost bine, iar dacă treceam la măsurători precise, a doua estimare ar fi mai bună – de unde și povestea cu velocity points. Pe de altă parte acele velocity points sunt valabile pentru o echipă. Schimbi oameni din echipă – ai altă echipă. Ajungem la filosofia Agile – oameni, nu unelte, dar despre asta era vorba în primul rând, nu?

- pentru cei ce vor să estimeze task-urile în timp, Paul a fost ferm: ‘am o veste proastă pentru dezvoltatori – nu puteți’. Se leagă de povestea de mai sus.

-  au fost prezentate mai multe metode de estimare, pe lângă clasicele numere incrementate sau luate ca valori din șirul lui Fibonacci, Alex a prezentat un tabel ceva mai complicat (nu îl pot reproduce, am reținut doar chestia cu numerele la tricouri ), iar Paul a vorbit despre metoda cărților de poker.

- ca idee, este nevoie de date suficiente pentru a face calcule. Ideea este luată oarecum din teoria numerelor mari din statistică. Numerele mici dau statisticile peste cap cu variații mari când ai date puține … dar când ai date multe, situația se schimbă.

- încă o reprezentare grafică a fost o chestie ce arăta partea de ‘known’ și partea de ‘unknown’ ce înconjoară acea zonă. Se leagă de chestiile de mai sus. Scopul este de a trece mai repede de la ‘unknown’ la ‘known’ prin învățare – cu cât înveți mai repede, cu atât mai repede se produce tranziția – și prin feedback.

Pentru că discuția a rămas începută, am schimbat locația datorită micilor probleme pomenite mai sus. Mai multă bere (beer is priceless!) și discuții mai aprinse. Ca niște concluzii: Agile este o filosofie (nimic nou sub Soare aici) ca răspuns celor ce debitează pe această temă. Paul (din nou) a venit cu o completare la idee prin ‘Scrum este un framework’. Ba mai mult, este un framework minimal – dacă scoți din el, se duce naibii totul, dar mai departe pe el se poate construi și personaliza metodologia de lucru. De altfel, cred că Jurgen a spus aceasta, sper să nu atribui greșit citatul/adaptarea, cei ce ‘fac Scrum’ au tot atâtea șanse de a ‘face Scrum’ câte șanse are un programator de a instanția o clasă abstractă. Lucru ce vine în completarea ideii despre Scrum ca framework.

Altă discuție interesantă la bere ce merită menționată a fost motivul pentru care managerii nu trebuie să pună presiune pe dezvoltatori. Din nou Paul la balon – da a fost vedeta serii. Cercul vicios sună/arată cam așa: presiune de la manager catre dezvoltator -> grabă + hack -> cod prost -> maitenance -> mai puțini oameni activi. Ultimele 3 duc la frustrare, buguri care mai departe duc la și la mai multă presiune, iar frustrarea adaugă încă o doză de cod prost și bug-uri.

A doua zi a fost dedicată Code retreat-ului, deși a apărut prin zonă doar Mihai Brehar și mai târziu Ovidiu Negrean. Deși mă simțeam ca după o bătaie cu parul (motiv necunoscut), am luat parte la toate cele trei iterații ce s-au făcut pe problema jocului de poker, problemă pentru care am apelat la PHP ca limbaj și Kohana ca framework pentru simplitatea de a încărca automat clase și a face rapid un prototip. Primele două au fost alături de Mihai unde am exersat varii tehnici (TDD, pair programming), ultima a fost cu Alex. Ultimele două iterații au fost bazate pe TDD. Ca rezumat:

- prima iterație = FAIL. Cică era de așteptat. După 45 minute de pair programming, codul a fost rulat o singură dată și a returnat un simplu 0 – ceea ce nu rezolva prima mână. S-a văzut importanța testelor și ca o paranteză la implementare – folosirea limbajului de business cerut de client (black și white pentru jucători, nu hand1 și hand2).

- a doua iterație, TDD based, nu doar că a fost cu succes, dar am avut și timp de refactoring plus 5 minute de relaxare. Alex a fost prin zonă cu o mână de ajutor deoarece nimeni nu știa cum să facă TDD.

- a treia iterație a mers tot pe mâna TDD, am folosit o abordare diferită a problemei (altă echipă). Inițial ne-am propus să rezolvăm problema full house, iar în final am rezolvat și careul deoarece soluțiile erau înrudite în contextul respectiv. De data aceasta am fost creativ și am folosit o metodă matematică ce nu presupune parcurgerea mâinilor, ci calcule. Problema s-a redus la una de rezolvare a unui sistem de clasa a VI-a:

{ 2X + 3Y = 4X + Y

{ 2X + 3Y = X+ 4Y

ce rapid ajunge la X = Y  pe ambele ecuații (două drepte suprapuse, ca reprezentare în plan x0y) de unde și concluzia că soluția este funcțională pentru cele două cazuri (full + careu), deoarece X = Y presupune ‘five of a kind’ cum erau la acele jocuri obosite de poker ce se găseau prin varii baruri. E bună și matematica aceasta la ceva în programare și mi-am adus aminte de ce sunt bune unele modele: dacă sunt demonstrate corect și implementate corect, sunt ‘bug free’ din punct de vedere logic. Excludem erorile de limbaj/runtime.

Pentru că puțini pricep cum se face TDD, iau ca exemplu un feature ce trebuie să returneze -1, 0 sau 1 – folosit și în tratarea cazurilor la jocul de poker (black, tie, white).

- se scrie primul test (am folosit assert($obj->method() == -1);, nu am apelat la PHPUnit)

- se implementează un mock în method (return -1;)

- se rulează testul => OK

- se scriu celelalte teste (assert($obj->method() == 0); și assert($obj->method() == 1);), se rulează și evident, eșuează

- se implementează codul funcțional propriu zis

- se rulează iar testele, iar dacă totul e OK, refactor și teste

Chiar aveam într-o metodă o eroare de logică, TDD a arătat rapid sursa problemei, iar debug-ul a durat 10 secunde. Avantajele sunt clare. Ca idee: TDD se potrivește doar pentru core functionality, nu pentru interfețe. Nu poți testa un capcha sau un CSS pe IE 6 prin TDD. Pentru aplicații ce folosesc baze de date, este nevoie de un mock. În rest, metoda își arată utilitatea. Noapte bună!