case study how eliminate flaws waterfall
Model híbrid de cascada àgil
El model Waterfall ha estat l'elecció ideal per al desenvolupament de programari. En aquest model, una idea es converteix en programari utilitzable en un procés seqüencial que passa en cascada a través de les etapes d’iniciació, anàlisi, implementació, proves i manteniment.
Però el model Waterfall té alguns desavantatges.
El desenvolupament àgil de programari va evolucionar per eliminar els problemes que té el model Waterfall. Té un marc completament nou. Tot i que el model Waterfall té un disseny seqüencial, el model Agile va seguir un enfocament incremental.
Quan els clients que solien seguir el model Waterfall van canviar a Agile, la transició va comportar molts problemes. La raó és la inadaptació a un enfocament diferent del desenvolupament de programari. El producte final va resultar ser un desastre.
Així, ha evolucionat una nova metodologia, que es pot anomenar 'híbrida', per garantir un producte final robust seleccionant els avantatges dels models Agile i Waterfall.
Primer coneixem els models de desenvolupament Waterfall i Agile i, a continuació, passem al 'Model híbrid de Waterfall Waterfall' amb els pros i els contres de cadascun.
Què aprendreu:
- Model de cascada
- Model Àgil
- Model col·laboratiu (híbrid)
- Model híbrid de cascades àgils: aprengui per exemple: un cas pràctic
- Com eliminar els defectes de la cascada i els processos de desenvolupament àgil mitjançant un model híbrid:
- Conclusió:
- Lectura recomanada
Model de cascada
El model Waterfall és un enfocament per al desenvolupament de programari que divideix un projecte en fases finites. S'hauria de passar a la següent fase només quan es revisi i verifiqui la seva fase anterior.
En el model de cascada, les fases no se superposen.
=> Llegiu més sobre el model de cascada aquí.
La figura 1 mostra el model de cascada:
Avantatges del model de cascada:
- Senzill i fàcil d'entendre i utilitzar.
- Model rígid: cada fase té lliuraments específics i processos de revisió.
- Documentació i artefactes minuciosament mantinguts.
- Apte per a projectes on s’entenen bé els requisits.
Desavantatges del model Waterfall:
- No és adequat per a projectes on els requisits corren el risc de canviar.
- El cost de solucionar els defectes és molt elevat quan es detecta en una etapa posterior.
- No és un bon model per a projectes complexos i llargs.
- No es produeix cap programari de treball fins tard durant el cicle de vida.
Model Àgil
Wikipedia defineix el model Agile com 'un grup de mètodes de desenvolupament de programari basats en un desenvolupament iteratiu i incremental, on els requisits i les solucions evolucionen mitjançant la col·laboració entre equips autoorganitzatius i multifuncionals'.
El model té els seus propis principis que tendeixen a portar els processos al seient posterior.
=> Llegiu més articles sobre la metodologia Agile aquí.
(Feu clic a la imatge per veure la imatge ampliada)
Avantatges del model Agile:
- Implicació del client en el procés.
- El ROI elevat com a programari de treball es lliura amb freqüència.
- Fins i tot els canvis tardans en els requisits es poden adaptar fàcilment.
- Millora contínua tant del producte com del procés.
Desavantatges del model Agile:
- Falta d’èmfasi en el disseny i la documentació.
- L’equip ha de ser estable i hàbil.
Model col·laboratiu (híbrid)
El model col·laboratiu té com a objectiu combinar els models: cascada i àgil. L’aprofitament de l’enfocament Waterfall i Agile garanteix l’èxit del projecte. Elimina els desavantatges dels dos models; alhora que reuneix els avantatges d’ambdós.
el millor netejador de PC gratuït de Windows 7
El model col·laboratiu es pot implementar en un projecte executant:
Per tant, el model col·laboratiu es pot representar esquemàticament de la manera següent:
Avantatges del model híbrid
- Combina els avantatges dels processos Agile i Waterfall.
- El disseny d’alt nivell està preparat per aplicar principis de cascada.
- La codificació i la prova es fan mitjançant una metodologia àgil.
Model híbrid de cascades àgils - Apreneu per exemple -Un cas pràctic
La firma de programari 'ABC Software Service' proporciona serveis a un client, una universitat anomenada 'XYZ University' per desenvolupar, provar i mantenir el seu programari (suport de producció en directe).
Les principals característiques del compte són:
- Els serveis de programari ABC han d’actualitzar les aplicacions de la Universitat XYZ. La base de dades s’ha d’actualitzar i totes les aplicacions han de tornar a desenvolupar-se fins a l’última tecnologia disponible al mercat.
- Fins ara, tots els projectes gestionats per ABC Software s’executaven en el model Waterfall.
- Ara estava previst que es tornessin a desenvolupar dues de les aplicacions de trànsit intens i d’alta prioritat. El primer és 'Inscripcions en línia', el segon és 'Exàmens en línia'.
- El client XYZ University volia que aquestes aplicacions es treballessin mitjançant el model Agile de desenvolupament de programari.
El primer projecte d’un model Agile per a ABC Software va ser el registre en línia. Després de l'execució d'aquest projecte, es va adonar en una sèrie de retrospectives que hi havia molts defectes en els processos seguits.
Aquests defectes van ser atesos durant l'execució del segon projecte 'exàmens en línia' i, per tant, es va executar en un model híbrid.
Com eliminar els defectes de la cascada i els processos de desenvolupament àgil mitjançant un model híbrid:
Analitzem-los detalladament un per un.
# 1. Sense documentació:
Un dels principis àgils del manifest àgil afirma que: Àgil dóna més valor a 'Working Software over Comprehensive Documentation'. La metodologia Agile creu que la documentació hauria de ser 'gairebé prou bona' i es posa més èmfasi en enviar un programari de treball. No es fa gaire esforç en documentació, però per a comptes com la Universitat XYZ, amb un equip de suport dedicat a treballar en defectes trobats en projectes en viu, aquest hàbit pot resultar un obstacle si l’analitzem a llarg termini.
Al llarg dels anys, quan els projectes es van executar segons el model Waterfall, es van mantenir i actualitzar els documents perquè l’equip de suport entengués i treballés en conseqüència. El disseny de solucions, el disseny tècnic, els documents detallats, etc. van ser alguns dels documents preparats. Un cop finalitzat el projecte, es va passar el mateix a l'equip de suport.
Però, en el cas del projecte «registres en línia», no es van preparar aquests documents i això va resultar costós. Quan el projecte es va publicar, els usuaris finals van obtenir moltes entrades i l’equip de suport no tenia ni idea de com treballar-hi. L’equip no tenia cap document per fer referència.
Aquesta va ser una lliçó important apresa i per al següent projecte es van redactar documents i es van fer transicions efectives dels «exàmens en línia».
=> Llegiu més aquí per què és important la documentació.
# 2. No hi ha proves UAT / End-to-End:
En el mode Agile de desenvolupament de programari, els provadors obtenen les versions per provar de forma incremental. Aquestes versions es continuen integrant fins que es construeix completament la versió final. Els provadors comproven els requisits coberts en cada sprint i continuen fent proves de regressió de la versió que continua sumant-se.
Però un cop finalitzats tots els sprints i la versió final preparada i integrada, el comprovador hauria de provar el sistema complet i realitzar proves de punta a punta. Això s’hauria de fer en un entorn completament nou.
=> Proves d’extrem a extrem en un projecte en directe.
Això té els seus propis avantatges:
- El sistema complet es desplega en un entorn nou i el provador prova el flux complet.
- Construeix confiança perquè, en última instància, la implementació s’ha de desplegar en conjunt en un entorn viu.
Quan es va provar el projecte de registres en línia, es va fer a l’entorn de proves. Després de provar i tornar a provar tots els defectes del sistema, es va declarar com a signatura. Idealment, no es va promoure a un altre entorn per fer un altre cicle de proves del sistema. (Idealment, UAT passa després de les proves del sistema , però en aquest cas, els membres de l'equip de la UAT van participar en el primer cicle de proves, de manera que no es va programar cap segon cicle)
Quan es va iniciar el projecte d’exàmens en línia, es va fer SIT (System Integration Testing) i es va promoure el codi a un entorn UAT on es va fer el segon cicle de proves. Resultat: tots els defectes d'alta prioritat van ser capturats i resolts. La compilació era estable abans del llançament en directe.
# 3. Sense Scrum Master:
El Scrum Master és responsable d’assegurar-se que un equip compleixi els valors i les pràctiques de Scrum. El Scrum Master es considera un entrenador de l’equip ajudant l’equip a fer el millor treball possible. El Scrum Master també es pot considerar com un propietari del procés per a l’equip.
L’equip de registre en línia es va formar sense un Scrum Master. La importància de tenir un Scrum Master dedicat no es va considerar important. Això va provocar que molts problemes no es resolguessin a temps i, al seu torn, el temps per acabar el projecte sovint creuava el termini.
No obstant això, un Scrum Master dedicat va participar en el projecte Exàmens en línia. El Scrum Master es va ocupar dels problemes i reptes del projecte. Es van preparar els informes del projecte / sprint i l’equip va poder veure el seu progrés.
A més, es van realitzar reunions de planificació de sprint adequades i reunions retrospectives de sprint per a cada sprint que milloraven el rendiment de l'equip. L’equip només es va concentrar en el seu treball i va completar les tasques assignades per a aquest sprint. Tot el servei de neteja addicional va ser gestionat per Scrum Master.
# 4. Conversió de documents de projecte a la cartera de productes:
Els documents inicials del projecte que es preparen en un model de cascada són l’especificació de requisits empresarials (BRS), el disseny d’alt nivell, el disseny funcional, etc. en mode àgil. Aquest és un pas molt important.
El retard de productes és el punt de partida d’un projecte àgil. El registre de productes és una llista prioritzada de requisits que es manté per a un producte. Consta de funcions, correcció d'errors, requisits no funcionals, etc. És un document en creixement que es fa més gran i millor basat en els comentaris dels clients, els requisits canviants, etc.
Com que és el primer artefacte de qualsevol projecte, és molt important enumerar els requisits i assignar-los prioritats. La conversió de documents del projecte de cascada a acumulació de productes és una gran tasca en si mateixa i requereix una pluja d’idees de tot l’equip juntament amb el client / l’interès.
Una vegada que tots els requisits s’enumeren i s’acorden pel client, la següent tasca és prioritzar-los per recollir-los en sprints.
# 5. Matriu de traçabilitat:
Un altre artefacte important que se sol mantenir en el model de cascada és la matriu de traçabilitat. Per tal de garantir que no es perdin cap requisit; també s'hauria de dissenyar i mantenir una matriu de traçabilitat . Normalment, en àgils no es dissenya aquesta matriu.
Aquesta és una pràctica recomanada per a qualsevol projecte. S'hauria de preparar una matriu de traçabilitat en paral·lel a l'endarreriment del producte. I s'hauria de comparar amb els casos de prova executats durant les proves d'acceptació de l'usuari / proves de extrem a extrem (aquesta etapa s'explica al meu següent punt). Fins i tot si es perd qualsevol requisit, es pot incorporar fàcilment fins i tot en les darreres etapes del desenvolupament, ja que l'àgil proporciona una flexibilitat i adaptabilitat addicionals.
Després de la posada en marxa del projecte d’inscripcions en línia, els usuaris finals (estudiants que volien registrar-se) van accedir a l’aplicació. Es van enfrontar a molts problemes a l'aplicació. Això va donar lloc a un munt de bitllets recaptats per a l'equip de suport a la producció. Les entrades obtingudes es poden classificar com a incidents, problemes o canvis. Es van resoldre molts problemes, anticipant que l'aplicació es mantindrà estable. Però, fins i tot aleshores, es van planejar més d’una dotzena de sol·licituds de canvi / millores en les versions posteriors. Aquestes millores pretenien estabilitzar l'aplicació i millorar l'experiència de l'usuari final.
Així, en última instància, el cost del projecte va augmentar en molts plecs. Per tant, si un projecte no es transita adequadament a l’àgil, pot fer que el pressupost es superi. Això és molt necessari per planificar una transició completa d’un projecte cap a Agile. A més, la planificació s'ha de fer en la mesura que el projecte necessiti per poder executar-se en mode àgil. Cal dissenyar models híbrids adequats per a un projecte concret.
Abans d’iniciar el projecte d’entrada a l’examen, aquest aspecte era ben cuidat. Es va pensar en un model híbrid i es va decidir que la fase d’anàlisi de requisits i la fase de disseny d’alt nivell s’haurien d’executar en el model de cascada i la resta d’etapes en un model àgil.
El model híbrid adoptat es pot representar pictòricament a continuació:
Conclusió:
És evident que tant el model Waterfall com el model Agile tenen els seus propis desavantatges. Per tant, és bastant realista optar per un model híbrid, que és una aproximació aprofitant el millor dels dos mons.
L’aspecte més important de l’inici de qualsevol projecte és decidir el model que l’equip adoptarà. Això requereix una planificació extensa. En adoptar un model de programari, s'han de tenir en compte factors com el pressupost, el temps, la utilització dels recursos, la complexitat dels requisits, etc.
El model híbrid es troba encara en una fase incipient. A mesura que més i més empreses l’adoptaran, aprendrem més sobre aquest concepte.
El manifest Agile ens demana que valorem:
- Individus i interaccions sobre processos i eines
- Programari de treball sobre documentació completa
- Col·laboració del client sobre la negociació de contractes
- Respondre al canvi Seguir un pla
Mentre que, el model híbrid no s’adhereix al 100%. Suggereix que tots els aspectes tenen la mateixa importància. Correspon als clients / gestors de projectes decidir quins aspectes valoren més i quins aspectes no tenen valor.
Sobre l'autor: Aquest és un article de Harshpal Singh. Té més de 7 anys d’experiència en proves manuals, bases de dades, automatització i rendiment i actualment treballa com a líder d’un equip en una multinacional líder. Ha treballat en molts projectes de control de qualitat seguint els models de desenvolupament Waterfall, Agile i híbrid.
Té alguna experiència treballant en aquest model de desenvolupament i proves híbrides? Parlem en comentaris.
Lectura recomanada
- Agile Vs Waterfall: Quina és la millor metodologia per al vostre projecte?
- Què és el model de cascada SDLC?
- Revisió de l'eina de gestió de proves de l'empresa Zephyr: com s'utilitzen els recursos del model de cascada a l'eina Agile
- Model en espiral: què és el model en espiral SDLC?
- 4 passos cap al desenvolupament de la mentalitat de proves àgils per a la transició amb èxit al procés àgil
- Tutorial JIRA Agile: Com utilitzar JIRA eficaçment per gestionar projectes Agile
- Fases, metodologies, processos i models de SDLC (cicle de vida de desenvolupament de programari)
- Manifest àgil: comprensió de valors i principis àgils