Ce inseamna Agile Software Development?
Nu vreau link-uri, carti, articole. Si nici insistat pe exprimari prea tehnice ( Despre TDD & Agile, pe îndelete ). Prefer cuvintele voastre, din experienta voastra. Cum trateaza Agile un proiect, task-uri fara documentatie buna, nehotarari ale clientilor, mod si etape de lucru?
@Adi: poate apari tu in discutie 
TLDR din ce am inteles eu e ca in loc sa ai proiect de juma de an si dupa aia sa te duci cu el la client, il imparti in mai multe sprinturi mici dupa care reevaluezi, reestimezi, reprioritizezi. Cel mai adesea treaba asta se face intern, dar in unele cazuri e implicat si clientul.
Teoretic e mai eficient. Practic conteaza mult timpul de proiect, companie, organigrama, client.
Am lucrat cu mai multe echipe care lucrau ‘Agile’, cu toate ca aparent aplicau aceleasi teorii, in practica modul de lucru era influentat de soft-ul pe care-l foloseau.
Ce a functionat destul de bine, in opinia mea, stabilirea obiectivelor in cadrul companiei (Google OKRs metodology) si apoi implementarea unui sistem similar Scrum, in care cineva, in functie de proiect prelua responsabilitatea de planning, iar intalnirile se tineau doar pt. preluarea task-urilor, ca fiecare sa fie cat de cat impact cu volumul de lucru si cerinte.
Stiu companii care au angajat project manager pt. planificari, distribuirea task-urilor, supraveghere; dar nu fac si development. Personal n-as face asta in compania mea, mai ales daca se lucreaza la mai multe proiecte in paralel.
Daca proiectul e mare si cu multi oameni, iti trebuie om dedicat pt planning. Stii tu, masoara de 2 ori si taie o data.
Din câte am observat, suntem Agile, facem așa este folosit de mulți pentru a zice, de fapt „eu sunt șeful, așa zic, așa facem”.
Când am auzit prima dată de Agile și am citit cam despre ce este vorba, am ajuns la concluzia că sunt Agile încă dinainte ca termenul să devină mainstream: clientul vede tot timpul progresul (de multe ori în real time), poate cere schimbări din mers șamd.
Iar acum concret, aplicat:
Fie un task, care sa zicem ca presupune o interogare db, un cache management si o trimitere de mail. Cache management-ul si mail-ul vor fi folosite si in alte task-uri. Agile presupune sa folosesti amanarea? Amani cache si mail cand lucrezi la task-ul X, pentru ca miezul task-ului e acea interogare, si revii mai tarziu, pentru ca, oricum, in development cache-ul te-ar incurca?
Agile ar presupune amanare si revenire continua asupra task-urilor? In loc sa te ocupi de cache si mail acum, la task-ul X, o sa le lasi pe mai tarziu, dupa ce faci toate task-urile (sau mai multe dintre ele) care au nevoie de ele?
Nu stiu daca am fost prea coerent, dar vedem.
Mie mi se pare că task-ul ăsta constă, de fapt, în trei task-uri distincte.
pai sunt 3 takuri distincte.
@msd, nu nu consta in revenirea asupra taskurilor. taskurile se fac si gata, revii doar daca ai bug-uri.
Deci iti faci planul incat sa acopere intreg task-ul.
A ajuns sa imi provoace scarba cuvantul Agile si supra utilizarea lui in orice mediu si de catre oricine a citit un articol pe wikipedia despre scrum sau xp.
In opinia mea e clar ca in realizarea unui obiectiv avem nevoie de planning, estimari si bineinteles, munca. Nu imi trebuie o metodologie anume. Imi trebuie o metodologie si punct.
@Catalin_Banu Uite ca am aparut si eu in discutie, intr-un tarziu 
Ideea de baza in Agile este sa reusesti sa iei deciziile potrivite in functie de context. De aceea Agile Manifesto spune in principiu ca trebuie sa te adaptezi situatiei si sa gandesti de fiecare data cum e mai bine sa faci. In filozofia Agile ar trebui sa nu fim rigizi prin a avea o metodologie stricta, ci mai curand sa reusim sa ne adaptam pentru un sigur scop: sa aducem valoare adaugata clientului cat mai rapid.
Astfel exista niste practici care sunt corelate cu dorinta de a ne concentra pe valoarea adusa clientului:
Pentru a raspunde acum punctual intrebarii, in filozofia Agile nu vrem sa avem o documentatie completa la inceputul proiectului. Vrem doar sa avem cerinte foarte clare pentru urmatoarea perioada (3-6 saptamani). Aceste cerinte foarte clare trebuie sa fie exact nucleul valorii adaugate a produsului creat. De ce? Pentru ca vrem sa il lansam cat mai rapid catre utilizatori si sa ii intrebam daca ii ajuta de fapt si daca pot sa monetizez cat mai repede produsul. Aproape de fiecare data trebuie sa fac ajustari, mai mici sau mai mari, pentru ca utilizatorii sa fie cu adevarat multumiti. Asta inseamna ca am un prin increment care este utilizat, care aduce valoare clientului si profit producatorului.
Dar trebuie sa am niste filtre care sunt utilizate pentru a fi sigur ca cerintele sunt clare atunci cand incep sa lucrez. In Scrum acesta se numeste Definition of Ready. Este practic o lista de criterii pe care cerintele trebuie sa le respecte (cerintele sunt clare, au definite criterii de acceptanta, exista mock-up grafic, poate sa fie implementat in maxim 3 zile, etc). Echipa poate si trebuie sa refuze orice cerinte care nu sunt clare, pentru ca altfel nu facem nimic altceva decat sa pierdem timp si bani pe cerinte neclare.
Un alt filtru este Definition of Done, care arata cum cerintele sunt finalizate de catre echipa. Si aceasta este o lista simpla (analizat, codat, testat dev, scris teste automate cu coverage 80%, nu exista buguri, etc)
Practic daca orice cerinta este implementata in maxim 3 zile, asta inseamna ca clientul poate sa vada in maxim 3 zile noi dezvoltari si sa isi spuna parerea daca asta este ce vrea. Daca mai vrea ajustari, le formalizeaza in asa fel incat sa respecte Definition of Ready si echipa le va realiza in functie de prioritatea cu care le vrea clientul. Singurul lucru pe care nu l-as face aici ar fi sa opresc echipa din a dezvolta ceva pentru a face shimbari, decat in cazuri rare si foarte speciale.
Un dialog constant cu clientul ii da increderea ca ceea ce se dezvolta este ceea ce vrea, iar micile sau marile ajustari vin repede astfel incat sa avem incremente de aplicatie care pot sa fie livrate cat mai repede.
Am lucrat si cu clientul langa noi, in echipa si pot sa spun ca a fost cea mai buna experienta. In orice moment puteam sa intrebam orice si eram siguri ca dezvoltam exact ce trebuie.
Pentru a concluziona, nu cred ca poti sa dezvolti software fara a avea cerinte clare si bine documentate. Orice filozofie si metodologie ai alege, iti trebuie claritate maxima cand incepi sa lucrezi. Traim intr-o lume dinamica unde pentru a putea sa ne ajutam clientii la maxim trebuie sa fim capabili sa acceptam si sa le rezolvam “nehotararile” cat mai repede si fara a crea technical debt.
@Adi, multumesc pentru raspuns! Poate exista unii norocosi care au cerinte clare sau care se pot clarifica usor atunci cand e nevoie. Insa atunci cand clientul pune intrebarea “Ce-i aia?”, privind ceva ce el a cerut, se cam duce dracu toata “agilitatea”.
toata ideea e sa intrebe din timp 
daca clientul intreaba “ce-i aia” inseamna ca ai lucrat cam de capul tau
@msd In cazul in care nu ai cerinte clare, nu te ajuta niciun fel de metodologie. Acolo ai alta problema, iti trebuie o persoana care sa faca legatura intre clienti nehotarati si echipa de dezvoltare. Aceasta persoana trebuie sa aiba in tolba foarte multa indemanare de comunicare si convingere pentru a scoate cerinte clare de la clienti. In general este o slujba full-time, pentru ca e foarte mult de munca cu clienti dificili sau nehotarati. Dar partea buna e ca in momentul in care vad ca au rezultate mai bune si mai repede in momentul cand dau cerinte clare, incep sa isi schimbe comportamentul si sunt mai atenti.
@AdrianBasalic, da, intrebi din timp, dar unele aspectat nefiind discutat si nici macar mentionate, nu le cunosti, si te bati de ele uneori putin cam tarziu.
@alescx, un exemplu ar fi o coloana dintr-o tabela. A fost ceruta de client, iar la demo a intrebat ce reprezinta.
@Adi, ce faci cand efectiv cu clientul nu se poate, ca e mare si vechi proiectul, dezorganizat din orice punct de vedere. Eu, ca angajat, nu pot sa decid renuntarea la proiect. Ce faci in cazul asta, cum te organizezi cat mai bine?
astea-s cazuri mai rare. si o coloana intr-o tabela nu intra in categoria “chestii importante”. probabil i s-a parut ca ar fi ok acolo, ti-a spus si dupa aia a uitat.
ps, de obicei exista un system care tine toate cerintele…povestile clientului, cine si la ce lucreza, ce urmeaza sa se lucreze, etc. nu merge pe baza de skype
Era doar un exemplu. Situatia e extinsa. De obicei exista, dar uneori nu prea. Un excel online care e modificat fara sa fii anuntat, doar de trezesti candva ca e modificat. Si asta e nedumerirea mea, cum procedezi in cazurile astea de dezorganizare grava. Din ce povestiti voi, aveti cazuri aproape de ideal, insa eu sunt in cealalta extrema.
