Filozofia dezvoltării web agile

Comparativ cu ingineria software tradițională, dezvoltarea agilă se adresează în principal la sistemelor complexe și proiectelor cu caracteristici dinamice, nedeterministe și non-lineare, unde estimările exacte, planurile stabile și previziunile sunt de multe ori greu de obţinut în stadii incipiente, si marile proiecte şi aranjamente prestabilite pot provoca, probabil, o mulțime de pierderi, nefiind economice. Aceste argumente de bază și experiențele prețioase din industrie învățate în ani de succese și eșecuri au ajutat la favoarizarea modelului agil de adaptare, iterativ și dezvoltare evolutivă.

Adaptiv vs. predictiv

Metodele de dezvoltare se găsesc într-un continuum de la adaptiv la predictiv. Metodele agile se află pe partea adaptivă a acestui continuum. O idee de metodă de dezvoltare adaptivă este abordarea de tip „Rolling Wave” în planificarea programului, care identifică repere, dar lasă flexibilitatea căilor de a le atinge, și, de asemenea, permite chiar schimbarea etapelor. Metodele adaptive se concentrează pe adaptarea rapidă la realitățile în schimbare. În cazul în care este nevoie de modificarea proiectului, o echipă de adaptare îl schimbă. O echipă de adaptare va avea dificultati în a descrie exact ce se va întâmpla în viitor. Cu cât este mai îndepărtat termenul, cu atât mai vagă va fi metoda de adaptare va fi cu privire la ce se va întâmpla la acea dată. O echipă de adaptare nu se poate raporta exact la ce sarcini se vor îndeplini săptămâna viitoare, ci doar ceea ce se intenţionează pentru luna viitoare. Când e întrebată despre o lansare de peste șase luni de acum încolo, o echipă de adaptare ar putea să vorbească doar despre angajamentul de lansare, sau privind valoarea așteptată față de cost.

Metoda predictivă, în schimb, se concentrează pe analiza și planificarea viitorului în detaliu și luarea în considerare a riscurilor cunoscute. La extreme, o echipă de predicție poate raporta exact ce opţiuni și sarcini sunt planificate pentru întreaga durată a procesului de dezvoltare. Metodele predictive se bazează pe o analiză eficientă a fazei incipiente și, dacă acest lucru merge foarte rău, proiectul ar putea avea dificultăți în schimbarea direcției. Echipele de predicție vor institui de multe ori un panou de control cu schimbările pentru a se asigura că numai modificările cele mai valoroase sunt luate în considerare.

Analiza de risc pot fi folosită pentru a alege între metodele adaptive (agile sau bazate pe valori) și predictive (bazate pe planificare). Barry Boehm și Richard Turner sugerează că fiecare parte a continuumului are propriul teren, după cum urmează:

Zone adecvate pentru diferite metode de dezvoltare:

• Metode agile
  • Metode planificate
  • Metode formale
• Criticitate redusă
  • Criticitate mare
  • Criticitate extremă
• Dezvoltatori seniori
  • Dezvoltatori juniori (?)
  • Dezvoltatori seniori
• Cerințele se schimbă des
  • Cerintele nu se schimbă des
  • Cerințe limitate, opţiuni limitate
• Număr mic de dezvoltatori
  • Număr mare de dezvoltatori
  • Cerințe care pot fi modelate
• Cultură care răspunde la schimbare
  • Cultură care necesită ordine
  • Calitate extremă

Iterativ vs cascadă

Una dintre diferențele dintre agil și cascadă este că testarea software este realizată la diferite stadii ale ciclului de viață de dezvoltare a software. În modelul cascadă, există întotdeauna o fază de testare separată, aproape de finalizarea unei faze de implementare. Cu toate acestea, în metoda agilă și mai ales în programarea extremă, testarea se face de obicei în același timp cu codarea, sau, cel puțin activitatea de testare începe în primele etape ale iteraţiei.

Pentru că faza de testare se face la fiecare mică iterație – care dezvoltă o mică bucată de software – utilizatorii pot folosi frecvent aceste piese noi de software și a valida valoarea.

După ce utilizatorii cunosc valoarea reală a piesei actualizate de software, ei pot lua decizii mai bune cu privire la viitorul software. Cu o retrospectivă a valorii și sesiunii de re-planificare software la fiecare iterație – modelul Scrum are maximum o lună ca durată de iteraţie, – va ajuta astfel echipa să adapteze continuu planurile sale astfel încât să maximizeze valoarea pe care o oferă.

Această practică iterativă introduce, de asemenea, o „mentalitatea de produs”, mai mult decât „mentalitatea de proiect” de tip cascadă. Software poate fi văzut ca un organism viu, care se schimbă în mod activ ca urmare a schimbărilor de mediu. Atâta timp cât software este utilizat, în special atunci când are concurenţi, iterațiile în dezvoltarea de software agilă va conduce schimbarea.

Din cauza stilului scurt de iteraţie în dezvoltarea de software agilă, există de asemenea, legături puternice cu conceptul de „lean startup”.

Cod vs. documentație

Într-o scrisoare către IEEE Computer, Steven Rakitin și-a exprimat cinismul cu privire la dezvoltarea agilă, numind un articol care sprijină dezvoltarea software agilă „încă o încercare de a submina disciplina de inginerie software” și a tradus: „software de lucru înaintea documentației cuprinzătoare” ca „Vrem să petrem tot timpul codificând. Ţineţi minte, programatorii reali nu scrie documentație.”

Acest lucru este contestat de către susținătorii dezvoltării de software agilă, care afirmă că dezvoltatorii ar trebui să scrie documentație în cazul în care acesta este cel mai bun mod de a îndeplini obiectivele în cauză, dar că există modalități de multe ori mai bune de a atinge aceste obiective decât scrierea documentației statice. Scott Ambler afirmă că documentația ar trebui să fie „doar destul de bună”, că documentație prea multă sau completă ar provoca, de obicei, pierderi, iar dezvoltatorii rareori au încredere în documentația detaliată, pentru că este, de obicei, desincronizată cu codurile, în timp ce documentația prea puțină poate provoca, de asemenea, probleme de întreținere , comunicare, învățare și schimb de cunoștințe. Alistair Cockburn a scris despre metoda Crystal Clear:

Cristal consideră dezvoltarea a fi o serie de jocuri cooperatiste, iar furnizarea de documentare este destinată să fie suficientă pentru a ajuta la următorul câștig din jocul următor. Produsele de lucru pentru Crystal includ cazuri de utilizare, lista cu riscurile, planul de iteraţie, modele de domeniu de bază, și note de proiectare pentru informare cu privire la alegeri … cu toate acestea, nu există template-uri pentru aceste documente, și descrierile sunt în mod necesar vagi, dar obiectivul este clar, doar suficientă documentație pentru urmatorul joc. Întotdeauna tind să descriu aceasta echipei mele ca: ceea ce ai vrea să știi dacă ai intra în echipă mâine.

– Alistair Cockburn

PDF: https://www.telework.ro/ro/e-books/dezvoltarea-agila-de-software/