Waterfall vs Agile, quina metodologia triar per al meu projecte?

En començar un nou projecte de software, l’equip tècnic i l’organització han de prendre una decisió important, com enfocar el desenvolupament, és a dir, triar quina metodologia pot ser la més adequada. Avui, coneixerem les dues metodologies més utilitzades en el Software Development Life Cycle (SDLC), Waterfall y Agile. Escollir la més apropiada pot ser un repte, ja que cada opció segueix un procés diferent per assolir l’èxit.

Waterfall o tècnica en cascada

La més tradicional a l’hora de desenvolupar software, i sha demostrat que és una tècnica àmpliament beneficiosa. S’hi recullen els interessos del client i es dissenya un pla seqüencial per adequar-s’hi. És un enfocament seqüencial que divideix l’SDLC en cinc fases:

• Requisits: Es llisten les necessitats que té el nostre client (per exemple, la interfície que necessiten) per planificar les fases següents.
• Disseny
• Implementació: On els programadors realitzen la càrrega de treball real.
• Verificació: Servirà per comprovar la qualitat de la nostra feina i apreciar els errors que hi puguin haver. Actualment, es fan servir eines d’Insights.
• Manteniment: El nostre equip s’encarregarà de respondre i actualitzar el programari per satisfer el client.

Cada fase només pot continuar si la fase anterior ha estat completada amb èxit. Entre les diferents fases, se n’espera un lliurable o que es signi un document.

Les fases es passen només una vegada, per tant, tots els requisits es recopilen al principi per tenir tota la informació necessària per crear la planificació, el pressupost i els recursos requerits.

Avantatges i desavantatges de Waterfall

Avantatges de Waterfall

• Recollir les idees des del principi facilita la planificació i el disseny.
• Abast del projecte ben definit.
• Pressupost més fàcil de calcular.
• El client no necessita dedicar temps al projecte.
• Els equips estan més organitzats per treballar en paral·lel.
• El progrés es mesura amb metes clares i marcades.

Desavantatges de Waterfall

• Estructura menys flexible davant de possibles canvis.
• No hi ha marge per error.
• Pot ser una mala estratègia davant els canvis en les preferències del client.
• Els projectes grans no són ideals: massa temps d’espera.
• No hi ha proves de la solució fins a les fases finals.

Agile o mètode àgil

El desenvolupament àgil segueix un enfoc basat en la satisfacció del client. Amb ell busquem el lliurament ràpid de funcionalitats completes d’una aplicació.

En aquesta metodologia es defineix una fase de temps limitat anomenada sprint amb una durada normalment establerta de dues setmanes.

• Al començament de cada sprint, s’elabora una llista de funcionalitats a lliurar en el termini de lliurament previst a partir de les peticions i prioritats acordades amb el client.
• Al final de l’sprint, els desenvolupadors i el client revisen i avaluen el treball realitzat i es prenen notes a tenir en compte per a futurs sprints.

Avantatges i desavantatges d’Agile

Avantatges d’Agile

• SDLC més ràpid.
• Definició dun calendari de sprints.
• Enfocament centrat en el client, cosa que resulta en una satisfacció més gran ja que se sent part de l’equip.
• Flexible en l’acceptació de canvis: el client pot veure la feina feta, prendre decisions i sol·licitar canvis.
• Empodera els equips per gestionar projectes.
• Ideal per a projectes amb finançament no fixa.
• Possibilitat de posar en marxa una versió bàsica del producte que es completarà amb iteracions posteriors.

Desavantatges d’Agile

• Requereix un alt grau de participació del client i no tots els clients se senten còmodes amb aquest rol.
• La participació dels clients pot portar a noves sol·licituds realitzades al llarg del projecte, que allargaran el temps i augmentaran el cost del desenvolupament.
• Assumeix que cada membre de l’equip està completament dedicat al projecte.
• Un enfocament de temps limitat pot no ser suficient per acomodar els lliuraments i, si els terminis de lliurament no es corresponen amb la realitat, augmenten el cost del projecte.

La meva experiència personal

Fa més de vint anys que em vaig adonar que m’agradava més documentar que codificar. Per això vaig passar de ser programador a analista funcional.

Les xerrades amb la presa de requisits, l’elaboració de documents funcionals amb propostes en prototips i la presentació al client. Aquesta és l’etapa del desenvolupament que més podia gaudir.

Etapa Waterfall

Els primers quinze dels vint anys van ser amb metodologia Waterfall 100%. A la meva salsa… generació de lliurables molt detallats, esquemes, diagrames, fins a propostes de model de dades a partir de la identificació de les entitats i les seves relacions.

Amb això, exposicions i discussions amb el client, retocs i, quan tot és clar, el desenvolupament.

Etapa Agile

Més tard i per un canvi de feina, va arribar Agile.

“No, no, aquí no hi ha documents funcionals, es creen històries d’usuari al JIRA”

Una història dusuari és una explicació informal duna petita funcionalitat del programari, documentada de forma independent a la resta. Se solen documentar com a tasques en aplicacions de ticketing, com JIRA.

M’acabava de quedar sense el que m’agradava més: Elaborar documentació detallada per tenir una vista prèvia del producte i comentar-la amb el client abans d’iniciar el desenvolupament.

Però, i la visió global? Quina documentació podia consultar per conèixer un projecte en desenvolupament?

“Has de buscar els tiquets de les històries a JIRA i consultar-los allà”

Des del meu punt de vista, una bogeria. És a dir, es podia dir que no hi havia res i per conèixer el producte en desenvolupament. Només quedava preguntar i jugar a prova i error en entorns de test.

Crec que aquesta moda del no documentar res porta a que quan el sistema vagi creixent es perdi el control, que tal part la va fer tal desenvolupador o una empresa externa i no se sap com ho va fer o perquè ho va fer així.

Un pas intermig: el model híbrid

Després de molt desenvolupament, va arribar el dia en què vaig decidir sortir-me del guió. Vaig començar a fer documents funcionals sobre el producte, documents que podien abastar diversos sprints i estructurats de manera que es poguessin trossejar per apartats, podent limitar les funcionalitats a implementar en una iteració.

I aleshores, va arribar la sorpresa. Els clients estaven encantats de poder veure un document que pràcticament era una vista prèvia del que podria ser un manual d’usuari, i els desenvolupadors també, ja que podien conèixer més sobre el producte a nivell de concepte i les necessitats de negoci per a les que estava pensat el desenvolupament.

En aquell moment, els tiquets amb les històries van passar a tenir simplement un link a l’apartat concret d’un document, que acotava i detallava la funcionalitat a implementar, un document que definia totalment el que era el sistema o part d’ell, si era un projecte de gran envergadura.

Model híbrid centrat en el prototipat

Amb aquesta nova versió “híbrida” de la metodologia podia incorporar l’ús de prototips perquè el client veiés una idea del que seria el producte acabat a l’inici del cicle de desenvolupament. Moltes vegades, és més fàcil detectar un error de plantejament amb una imatge de les “pantalles” que en un text extens.

De nou, per un canvi de feina, ja a Itequia, vaig tenir la sort de trobar-me amb una novetat a la metodologia a aplicar: donar importància al prototipat.

Una de les nostres maneres de suavitzar el volum de documentació generada inicialment és focalitzar la fase de presa de requeriments en la generació del prototip del que podria ser el producte final.

Es tracta d’involucrar a l’equip de UX/UI gairebé des de l’inici, que sigui present a les reunions de requisits per poder tenir a curt termini les primeres propostes a validar amb el client.

La presentació d’un prototip amb el look final que tindrà el producte i interactiu per simular les funcionalitats, dóna al client més facilitat per detectar canvis necessaris respecte al que havia pogut plantejar inicialment i, a més, li dóna la sensació d’avenç al projecte.

El prototip també s’utilitzarà per fer una introducció a l’equip de desenvolupament de manera que vegin el tema, el tipus i l’abast de la implementació a realitzar durant el projecte.

Però… i la meva part preferida? Què passa amb la documentació?

Realitzar el prototipat previ no substitueix la documentació necessària per detallar un desenvolupament, però sí que ajuda a tenir una visió prèvia, que ens ajuda a no haver de fer moltes versions dels lliurables (i les seves lectures respectives) mentre no s’aprovi la versió final.

En resum, tant Waterfall com Agile s’han convertit en els estàndards metodològics perquè cadascú abasta una àmplia varietat de projectes i compleixen molts dels requisits de la indústria. Això no vol dir que siguin els únics existents o necessitin canvis depenent de l’empresa. Explora cada tècnica amb el teu equip, tria’n una com a base i realitza els canvis necessaris mentre treballeu en una aplicació o programa.

És la millor manera de garantir l’èxit no només el teu, sinó del teu client.

Francesc Juventeny Corbero – Product Owner at Itequia