Încă un articol despre cum puteți începe cu agile, care-i treaba cu iterația zero șamd.
https://printhelloworld.de/posts/iteration-zero-architecture/
“Don’t try to get it all right from the beginning” - This is how shitty, criminal software is made.
Poate functioneaza la API/business logic, la frontend va duce la cod care iti consuma 90% procesor in joc sau in browser sau iti mananca bateria pe mobil si nu stii de unde, ti se incarca ceva in 5 secunde cand ar trebui sa dureze 10ms. Sau ai o interfata de toata jena pe care nimeni n-ar vrea sa o foloseasca, dar nimeni nu vrea sa plateasca sa se refaca, ca nu poti reface un UI iterativ in majoritatea cazurilor, iti trebuie ‘the whole picture’ ca sa faci ceva chiar bun altfel invarti acelasi lucru cu aceeasi probleme. (se mai schimba putin cu componentele izolate in web, dar cam atat)
Pe scurt pe frontend duce mereu doar la un un beta-alpha care dupa ar trebui refacut sa fie stabil. Problema e ca trebuie sa faci ceva bun din start in majoritatea cazurilor ca cineva sa dea bani pentru a-l reface si mai bine.
La embedded conduce la cod criminal care omoara oameni si produce prejudicii materiale.
90% din programele pe care le folosim noi, fie Chrome, fie Firefox, fie Windows 10, fie Photoshop, Edge, Sketch, Autocad (la autocad deja se vede agile-ul, are bug-uri care nu se pot rezolva de zeci de ani) se bazeaza pe specificatii de zeci-sute de pagini pentru fiecare feature. Unde acestea lipsesc se vede de la 10km distanta. Probabil se folosesc toti de un fel de agile, dar daca intrerupi sprint-urile unul dupa altul fiindca specificatia la un feature dureaza 6 luni ce rost mai are ?
1 Like
Deci stai puțin, că nu înțeleg o chestie: să presupunem că mâine decizi că vrei să înveți vreun limbaj nou. Vei începe din start cu toate conceptele noi și vei face tot posibilul să le implementezi corect? Sau vei începe cu baby steps?
Nu faci software de productie unui client cu un limbaj pe care nu il cunoaste echipa ta daca nu vrei sa il storci doar de bani si sa ii dai ceva de care nimeni nu vrea sa se atinga.
Nu pui pe cineva care nu cunoaste cum functioneaza procesorul din calculatorul unui computer de bord sa iti scrie sistemul de control pentru franare si accelerare cu agile fiindca n-ai bani de cineva care a scris lucrari de sute de pagini si studii de caz pe acest subiect. Eventual pui pe cineva sa studieze problema oricum, dar atunci agile te obliga sa inveti, studiezi de mantuiala. In amandoua cazuri probabil ca o sa iti spuna cineva ca un sprint va lua 8-10 luni si ai 10 sprint-uri si te lasi de agile. Daca tii mortis sa fie facut totul in sprint-uri probabil ca o sa conduca la zeci-sute de oameni morti codul scris in acest mod.
Cel putin din punctul meu de vedere agile e o hotie pentru client, pentru noi functioneaza daca nu ne intereseaza calitatea muncii noastre sau daca nu avem responsabilitate, dar e de rau daca cineva il obliga la sange la un proiect complex si masoara succesul prin sprint-urile finalizate. Acestea niciodata nu sunt finalizate, doar ca nimeni n-a avut timp sa aiba grija de bug-urile care apar, nu ne blocam la detalii care sunt importante doar in anumite cazuri.
Agile functioneaza daca vrei sa faci un prototip, un beta, un alpha si clientul e de acord ca va trebui refacut pentru productie dupa un anumit timp.
Acum nu zic ca nu e nevoie de project management, dar nu e nevoie de sprint-uri, cel putin nu fara specificatii, code review-uri, grooming pe hartie. Daca nu poti face un complete requirements pentru un produs de la inceput, o sa fie probleme mari undeva cand trebuie ceva extins sau un bug reparat. Fiecare grooming, fiecare meeting practic te opreste sa lucrezi/inveti. Poti pierde zile intregi asa fiindca e obositor, la final trebuie terminat sprint-ul si pui ceva ce ar fi trebuit facut atent in 2-3 zile in 20 de minute.
Agile se bazeaza pe dezvoltare continua, care il face pe client sa se simta ca e in control. Nu cred ca exista un programator care ar zice ca e in control, doar ca incaseaza salariul. Adica eu practic trebuie sa ma incadrez in cea mai simpla solutie, care stiu ca va avea probleme, dar n-am ce face.
Este o diferență între „îl cunoaște” și „getting right”. Treaba e că până nu practici ceva nu poți să îl faci bine => intri într-un cerc vicios în interiorul căruia nu poți învăța nimic.
Tind să cred că ai avut parte de varianta nasoală de agile 
Ba da, spui „datorită integrității mele morale și profesionale nu voi impelmenta cutare lucru în cutare mod”.
Din nou, îmi lași impresia că tu lucrezi doar la aplicații super high-end și omiți (intenționat sau nu) faptul că nu toate aplicațiile au o toleranță atât de scăzută la erori sau greșeli.
PS: după ce primești un răspuns pe forum e cam aiurea să îți editezi mesajul anterior pentru a mai adăuga idei…
Nu lucrez la aplicatii high-end, dar nu poti cere nici bani pe ceva ce stii ca e stricat din start.
Puteai acum 10 ani, in ziua de azi te sinucizi, in special daca nu ai monopol si nu prea mai exista monopol.
Tolerantele sunt mici peste tot, nu vrei mai multe review-uri negative la o aplicatie decat pozitive.
Si eu tind sa cred ca ai intalnit Agile implementat prost. Nu zice nimeni ca dupa 2 sprinturi trebuie sa fii direct live, e f posibil sa nu ai destula functionalitate pt asta.
@isti37 iti recomand cu mare caldura workshopul din 21 iunie al lui Sebastian Bergmann (autorul phpunit) si colegii sai Arne si Stefan, pentru a vedea cum se poate face Agile vorect, pe DDD si cu event sourcing, producand cod testat. Vei avea ocazia sa dezbati argumentat cu oameni care au migrat multe legacy apps cu oamenii clientului ai au folost Agile pentru ca e singurul mod in care upper management poate obtine estimari corecte a ceea ce a mai ramas de facut.
Eu am invatat multe de la eu legat de cum se pune corect problema. Si pana la urma software-ul modern e 70% comunicare ai pozitionare, restul fiind cod efectiv. Mie mi-a luat cativa ani sa inteleg informatia din acest ultim paragraf.
5 Likes
Nu toate aplicațiile sau sistemele au aceleași constrângeri 'tho. De obicei agile produce rezultate bune când faze de deployment e simpla - aplicații web, dispozitive IoT/conectate etc. Sistemul de frana al unei mașini sau drivere pentru roboti in fabrica au deploy complicat. Așa că trebuie să “get it right” din start. Asta colorează mult cum abordezi problema, cum testezi etc.
Deși poți face agile in principiu indiferent de context. Outputul unui sprint nu trebuie sa fie doar cod sau un “feature”. Poate să fie un design doc, o analiză de date, o prezentare către colegi, cititu unui articol și o înțelegere mai buna a problemei. După un număr de sprinturi de planning, se poate trece la implementare. Oricum se scrie și cod - prototipuri, proof of concepts, acele mici bucăți de cod care trebuiesc scrise că îi blochează pe toți, dar care doar un singur om le poate scrie etc.
Asta nu înseamnă că aplicațiile web sunt “simple”. Din contra, comparate cu ceva embedded sunt enorm de complexe. Doar că beneficiază de distribuție ușoară.
3 Likes