Când am decis să mă învăț cum să codez acum aproape patru ani, nu auzisem niciodată, să nu mai vorbim despre ciclul de viață al dezvoltării software-ului.

În calitate de dezvoltator nou-nouț, m-am concentrat pe învățarea tehnologiilor care mă vor ajuta să ajung la acel poftă pentru primul loc de muncă pentru dezvoltatori, nu nuanțele modului în care acționau acele echipe.

Când am aflat de ele, am crezut că vor fi inutile pentru mine, pentru că mă consideram dezvoltator web, nu dezvoltator de software.

De atunci am aflat că acest lucru nu poate fi mai departe de adevăr și că aceste principii / practici joacă un rol important în activitățile mele de zi cu zi (indiferent dacă îmi dau seama sau nu).

Sunt destul de norocos să văd cum codul pe care îl scriu, caracteristicile pe care le construiesc și erorile pe care le introduc în mod accidental (mai mult decât îmi place să recunosc) afectează utilizatorul final și experiența acestuia. Această experiență a ajutat la modelarea modului în care gândesc despre procesul de construire a produselor și rezolvarea problemelor pentru utilizatorii mei.

Am avut ceva timp să mă gândesc la diferențele (și asemănările) pe care le oferă fiecare dintre aceste abordări. În centrul lor, fiecare este axat pe furnizarea de software de înaltă calitate cât mai eficient și cât mai rentabil posibil.

Profesional, am folosit doar una sau două dintre aceste metodologii. Dar găsesc încă valoare în cel puțin o înțelegere de bază a tuturor.

Toate aceste metodologii urmează o serie de faze similare acestei diagrame:

Ghid SDLC Faze si metodologii ale ciclului de viata
Analiza cerințelor -> Proiectare -> Implementare -> Testare -> Evoluție

Deci, iată metodele ciclului de viață al dezvoltării software-ului (fără o ordine specială):

Să cercetăm diferențele și asemănările fiecărei metode.

Conţinut

A se sprijini

Metodologia Lean se bazează în mare măsură și cuprinde șapte principii.

În nici o ordine specifică acestea sunt:

  1. Eliminați deșeurile
  2. Amplificați învățarea
  3. Decideți cât mai târziu posibil
  4. Livrați cât mai repede posibil
  5. Împuterniciți echipa
  6. Construiți integritate
  7. Vedeți / Optimizați întregul

Fiecare principiu are un scop specific, cu beneficii care se complimentează reciproc.

Eliminarea deșeurilor (funcții suplimentare, muncă incompletă, angajamente manageriale etc.) creează mai multă valoare pentru client, ceea ce, la rândul său, sporește satisfacția.

Amplificarea învățării permite echipelor să reinvestească în capacitatea lor de a livra produse clienților.

Decidând cât mai târziu posibil se referă la toate deciziile majore, oferind echipelor o opțiune sau o abordare bazată pe set. Acest lucru permite echipelor să adune fapte mai degrabă decât opinii pentru a ajuta la influențarea deciziilor atunci când sunt luate.

Livrare cât mai rapidă posibil se explică de la sine – construiți produsul cât mai repede posibil pentru a-l livra clienților pentru evaluare / iterație.

Într-un scenariu tipic, managerii au repartizat sarcini / lucrări dezvoltatorilor. În metodologia Lean, dezvoltatorii „învață” managerii cum să asculte „oamenii din tranșee” influențând astfel deciziile / alegerile managementului.

Acest lucru ajută echipele să se simtă mai mult împuternicit să vorbim despre idei și soluții.

Făcând integritate o regulă în locul unei excepții înseamnă că clientul este încrezător în sistemul construit. Clientul știe că sistemul este construit pentru a rezista cantității adecvate de creștere și „întindere”, dacă este necesar.

Îmi place să mă gândesc la partea de integritate pe aceeași linie cu a sta pe un scaun. Când vă așezați pe scaun, credeți că a fost construit cu cel mai bun material care vă va ține sus de fiecare dată când stați în el pentru viața scaunului. Clientul are nevoie de aceeași încredere în produsul construit.

În cele din urmă, văzând și optimizând întregul se referă la întregul sistem construit. Prin optimizarea pentru ansamblu, ne uităm la software-ul nu ca o sumă de mai multe componente, ci ca o entitate mare care este optimizată pentru eficiență.

Acest lucru înseamnă că, în timpul dezvoltării, produsul este împărțit în bucăți ușor de gestionat și că erorile accidentale nu sunt doar descoperite, ci rezolvate rapid.

Agil

Aceasta este abordarea „eșuează rapid” pentru a construi software.

Se pune accent pe versiuni mici, incrementale, cu cicluri de lansare continue. Cu fiecare iterație, echipele se străduiesc să identifice și să rezolve problemele mici înainte de a deveni mari probleme.

Acest lucru înseamnă, de asemenea, că echipele trebuie să angajeze părțile interesate (persoane / organizații pe care codul le poate afecta în cele din urmă, cum ar fi manageri, clienți tehnici, CTO și clienți) pentru a obține feedback-ul lor.

Dacă sunteți independent, părțile interesate ar fi clienții dvs. – în cele din urmă, trebuie să le asigurați satisfacția cu munca înainte de a continua.

Agile reprezintă un punct de vedere tehnic al metodologiei Lean, cu unele diferențe notabile – în principal, acordă prioritate satisfacției clienților încă de la început și permite echipelor să răspundă rapid la feedback-ul clienților.

Deși este dincolo de sfera de aplicare a acestui articol, există un alt cadru mai complex în cadrul Agile care se numește SCRUM. Această metodologie este utilizată pentru proiecte mari, extrem de complexe și a fost folosită chiar și în afara dezvoltării de software.

Cascadă

Metodologia cascadei este, după majoritatea conturilor, cea mai veche din listă. Nu a fost niciodată menit să fie un model pentru dezvoltarea de software și și-a început startul în lumea construcțiilor și a producției.

Această abordare este simplă în structura sa – finalizați toate părțile unei faze înainte de a trece la faza următoare, cu o mai mare impulsiune spre finalizarea proiectului pe măsură ce etapele sunt finalizate. Începutul și finalizarea fiecărei etape (cu excepția primei) și finalizarea este condiționat de finalizarea / transferul de informații din etapa anterioară.

Sub abordarea cascadei, fiecare etapă are propriul său plan de proiect rigid, care se încheie cu testarea lucrărilor finalizate anterior. Trebuie remarcat faptul că această abordare nu este recomandată pentru proiectele mai mari / mai durabile din cauza rigidității menționate anterior.

Gândiți-vă la geneza acestei metodologii și o veți înțelege mai mult. A venit din lumea construcțiilor / producției, unde este obișnuit să se finalizeze câte o fază. În timpul construcției unei case nu ați începe să puneți instalațiile sanitare înainte ca rama să fie pusă.

Nu acesta este modul în care funcționează în general dezvoltarea de software. După cum știm cu toții, uneori devine necesară revizuirea unei faze despre care se credea că a fost terminată anterior.

Iterativă

Aceasta este cunoscută sub denumirea de „abordare repetitivă” sau „îmbunătățirea următoarei abordări” datorită diferitelor oportunități pe care le oferă pentru a îmbunătăți produsul cu fiecare iterație de ciclu.

Sunt părtinitor (așa cum suntem cu toții: D), dar se întâmplă să fie ciclul meu de viață preferat pentru dezvoltare. Cred că funcționează cel mai bine pentru situația mea actuală, atât în ​​freelance, cât și în carieră, deoarece îmi permite să „avansez în mod constant în timp ce îmbunătățesc lucrurile”.

Cu abordarea iterativă, echipele implementează o soluție, testează acea soluție, îi evaluează eficacitatea / randamentul și apoi identifică alte domenii de îmbunătățire. Acest lucru se întâmplă pentru fiecare ciclu (iterație) al procesului de dezvoltare.

Cu fiecare versiune lansată vine o altă iterație până când produsul final este finalizat și gata de lansare pentru utilizatori.

Una dintre marile caracteristici ale abordării iterative este că dvs. și echipa dvs. obțineți o versiune de lucru a software-ului încă de la începutul procesului de dezvoltare. Acest lucru poate fi util mai ales pentru a le arăta părților interesate să evalueze răspunsul / feedback-ul lor.

Unul dintre cele mai mari dezavantaje ale acestei abordări este că poate consuma o cantitate mare de resurse foarte repede. Imaginați-vă toți oamenii, orele, remedierile de erori și salariile care intră în fiecare iterație a ciclului de dezvoltare și veți obține o imagine bună a utilizării resurselor.

În cadrul acestei abordări se află un subset de principii dezvoltat de Rational Software Corporation (cumpărat de IBM) numit Proces unificat rațional (RUP) care constă din 4 faze:

  • Inceput
  • Elaborare
  • Constructie
  • Tranziție (lansarea produsului)

Acest set de principii este menit să fie flexibil și adaptat la nevoile fiecărei echipe care îl utilizează.

Spirală

Metodologia spirală este probabil cea mai flexibilă dintre cele șase. Este o metodologie bazată pe riscuri – identificarea și negarea acestora. Riscul (identificarea și aversiunea) determină fiecare decizie din acest model. Este împărțit în patru subfaze:

  • Planificare (obiective)
  • Analiza riscurilor (identificați posibilele blocaje)
  • Dezvoltare și testare (versiunea curentă și următoare)
  • Evaluare (revizuirea fazei curente și planul pentru faza următoare)

Fiecare iterație a fiecărei faze începe cu planificarea fazei următoare. În acest fel, riscurile potențiale sunt identificate înainte de a fi întâlnite. Acest lucru permite, de asemenea, un plan de acțiune atunci când apar riscurile menționate.

Pe parcursul fazelor, echipele lucrează, de asemenea, pentru a atenua aceste riscuri și impactul acestora asupra iterațiilor viitoare ale dezvoltării spiralei.

Pe măsură ce procesul de dezvoltare continuă, fiecare dintre aceste patru subfaze se repetă în spirală. Acest lucru permite mai multe runde de rafinare pentru fiecare subfază până la finalizare.

Dev Ops

Dacă faceți o căutare rapidă, nu veți găsi lipsă de informații despre această metodă a ciclului de viață al dezvoltării. Este noul copil din bloc care aduce echipele de dezvoltare software și operațiuni în tehnologia informației în aceeași cutie.

Aceste echipe lucrează împreună pentru a oferi actualizări mici, dar impactante, pentru produsele care vin într-un ritm frecvent. La rândul său, acest lucru creează un feedback continuu și o buclă de îmbunătățire care determină dezvoltarea.

Această metodologie specială este cunoscută și pentru automatizarea părților manuale ale dezvoltării (gândiți-vă la implementare).

Scopul general al acestei metodologii este, la fel ca majoritatea altora, de a scurta ciclul de viață al dezvoltării și de a oferi produse de calitate.

Unul dintre dezavantajele acestei metodologii este modificările semnificative ale mentalității și culturii în cadrul unei organizații. Echipele care s-ar putea să fi fost obișnuite să lucreze la multe lucruri își găsesc sarcinile restrânse doar la una sau două.

De exemplu, un dezvoltator cu scop general poate constata că sunt acum însărcinați doar cu porțiunea de testare sau cu experiența utilizatorului final.

Aducând totul acasă

un bec pe o carte
Fotografie de Vizuale inteligente pe Unsplash

Sper că acum puteți vedea importanța și beneficiile fiecăreia dintre aceste metodologii. Fiecare dintre acestea posedă propriile puncte forte și puncte slabe.

Ele sunt, la nivelul lor de bază, un set de linii directoare și principii care urmăresc să ofere o muncă de înaltă calitate și eficientă părților interesate.

Când am început să învăț să codez nu aveam un mentor. Împărtășind ceea ce am învățat, sper să-i ajut pe cei care învață să codeze când / unde pot.

Vreau să împărtășesc cât mai multe informații și experiență posibil altor dezvoltatori. Dacă vă învățați să codificați sau dacă sunteți un dezvoltator experimentat, sper că acest articol vă va ajuta, chiar dacă într-un mod mic.

Verifică-mi blog unde postez frecvent articole despre dezvoltarea web.

În timp ce sunteți acolo, de ce nu vă înscrieți la newsletter-ul meu? Puteți face acest lucru în partea dreaptă sus a paginii principale a blogului. Îmi place să trimit din când în când articole interesante (ale mele și altele), resurse și instrumente pentru dezvoltatori.

Dacă aveți întrebări despre acest articol sau, în general, DM-urile mele sunt deschise – veniți să salutați Stare de nervozitate sau oricare dintre celelalte conturi de pe rețelele mele sociale pe care le puteți găsi sub newsletter, înscrieți-vă pe pagina principală sau pe profilul meu aici 🙂

Ai o zi minunată și o codificare fericită, prietene!