Poate pentru mulți procesul de dezvoltare software pare unul destul de direct și ușor de înțeles.
Până la urmă, un produs software nu e altceva decât un set de fișiere de cod și eventual ceva fișiere de configurare, puse la un loc.
Și atunci, procesul prin care obținem acest produs e prin scrierea codului necesar. Cu cât mai repede, cu atât mai bine.
Asta e valabil poate pentru proiecte mai mici sau mai simple, dar în companiile mari lucrurile stau complet diferit.
Tipuri de produse software
Există foarte multe tipuri, categorii și subcategorii de produse software, dar la nivel înalt sunt două categorii mari și late atunci când vorbim de companii:
- Software pentru derularea operațiunilor interne
- Software pentru vânzarea către clienți
Din cauza complexității proceselor interne, sau nevoia de a avea integritatea datelor sau trasabilitatea datelor în companie, e foarte obișnuit ca marile companii să dezvolte software care să fie folosit strict intern, de către angajații proprii.
Această categorie de software nu produce companiei venituri în mod direct, pentru că nu e vândut nimănui, dar produce venituri indirect prin creșterea productivității angajaților.
Aș spune, din experiența mea, că această categorie de software e mult mai răspândită decât cealaltă, dar de multe ori și produsele sunt mult mai puțin complexe și mai predispuse la erori.
A doua categorie, software ce este vândut direct către clienți, cuprinde toate produsele de tipul “SaaS” sau Software as a Service (servicii sub forma unui software). Adică cele pentru care clienți (persoane fizice sau companii) plătesc pentru a le folosi.
Gândește-te la orice fel de platformă de servicii, precum:
- Servicii de închirieri: Booking sau AirBnB
- Servicii de plată: Stripe sau Paypal
- Servicii de design grafic: Canva sau suita Adobe
Cred că ai prins ideea, orice fel de produs software care este expus, fie publicului larg, fie companiilor pentru a produce bani.
Procesul de dezvoltare software în trecut
Până în urmă cu, să zicem, 10-15 ani, procesul de dezvoltare software arăta complet diferit.
Pe scurt, se desfășura ca o succesiune de etape secvențiale, fiecare etapă fiind acoperită de o echipă (sau individ) cu funcție diferită.
Problema cu acest tip de abordare era că fiecare echipă, sau fiecare rol din proces, aștepta după toți cei care lucrau în etapele anterioare.
Echipa de testare aștepta după cea de development, cea de development după cei care făceau analiza și design-ul și tot așa.
Procesul era unul laborios, îndelungat și totodată periculos, pentru că se investeau sume mari de bani și efort foarte mare obținând în final un produs care să nu fie neapărat conform cu așteptările sau ideile celor care au inițiat sau finanțat proiectul.
Pentru că tot procesul e bazat pe o serie de etape bătute în cuie, ceea ce însemna că la fiecare etapă totul trebuia să decurcă perfect, altfel proiectul ar fi deraiat complet de la planul inițial.
Abordarea asta a fost denumită ulterior “Waterfall” (cascadă), din cauza modului secvențial în care sunt executate etapele, cumva în cascadă, și a fost modul prin care oamenii au dezvoltat software în primele decenii ale erei digitale.
Dezvoltarea software în era modernă
Schimbarea a venit la momentul la care oamenii au început să realizeze că procesul de dezvoltare are anumite probleme și că se punea accent mult prea mare pe planificare și documentare și mai puțin pe obținerea produsului dorit.
Acesta a fost un moment de cotitură în urma căruia a fost definit ceea ce purta numele de Agile Manifesto, documentul care punea bazele unui proces de software development mult mai deschis comunicării și colaborării între toate părțile implicate, menit să ducă la obținerea de produse software mult mai apropiate de ideea inițială și nevoile reale ale potențialilor clienți.
În schimb, etapele procesului de dezvoltare nu s-au schimbat foarte mult, ele au rămas în esență aceleași, ce s-a schimbat a fost viteza și modul de parcurgere al etapelor.
De exemplu, în loc să se facă planificarea și analiza ca faze inițiale pentru întregul proiect, s-a trecut la planificarea și analiza unei singure componente, care era trecută prin toate fazele de dezvoltare.
Astfel, produsele au fost segmentate în bucăți mici sau foarte mici, care erau trecute prin întregul ciclu de dezvoltare, de la analiză și planificare, până la dezvoltare, testare, instalare în mediul de producție și, în final, feedback din partea unei persoane care înțelege îndeaproape nevoile clienților.
Acest mod de abordare al ciclului de dezvoltare se numește metodologia Agile (Agile Methodology).
Implementări ale metodologiei Agile
În sine, metodologia Agila, prin documentul denumit “Agile Manifesto” nu spune foarte multe despre cum ar trebui să se desfășoare ciclul de dezvoltare, nici despre numărul și denumirea etapelor sau rolurile celor implicați. Vorbește doar despre un mod de abordare al lucrurilor și anume cu accent pe partea de comunicare și colaborare între cei implicați.
În funcție de nevoile fiecărei companii, implementarea acestor principii e făcută diferit, sub forma unor “frameworks” de agile.
Câteva frameworks din cele mai cunoscute sunt:
- Kanban
- Scrum
- SAFe (Scaled Agile Framework)
Între cele enumerate diferă mai degrabă rolurile implicate și etapele dintr-un ciclu de dezvoltare, păstrând în același timp aceleași principii bazate pe strânsă colaborare și comunicare definite de Agile Manifesto.
Nu vreau să intrăm și mai mult în detalii despre implementările acestor frameworks, pentru că ele pot diferi de la companie la companie, în funcție de nevoile și contextul fiecăreia.
Concluzie
Ceea ce îți povestesc aici este valabil desigur, așa cum am zis și inițial, pentru companii mari și foarte mari, stabile, mai puțin pentru start-up-uri, unde lucrurile stau complet diferit, pentru că echipele sunt mult mai mici, iar lucrurile se desfășoară mult mai alert, punându-se accent și pe alte lucruri decât procesul de dezvoltare software. Precum validarea ideii în piață, marketing, stabilirea modelului de business și intrarea cât mai rapidă pe piață.
E un context și un “mindset”, dacă vrei, complet diferit față de ceea ce ți-am descris anterior.
Atât pentru azi, pe data viitoare.