agile vs waterfall which is best methodology
com obrir el fitxer amb java
Obteniu més informació sobre les metodologies Agile i Waterfall, els diferents tipus de models SDLC i les diferències entre els models de desenvolupament Waterfall i Agile, així com les proves:
Llegiu aquest article informatiu per decidir quin és el model més adequat per al vostre projecte en funció dels avantatges i desavantatges de cadascun.
El model de cascada i el model àgil són els tipus de cicle de vida de desenvolupament de programari (SDLC). Aquests són el procés utilitzat per la indústria del programari per dissenyar, desenvolupar i provar el programari.
Seguint el SDLC, podem assolir les expectatives dels clients, completar el projecte en uns terminis determinats i estimar el cost.
Què aprendreu:
- Fluxos de treball de cascada i model àgil
- Model de cascada
- Flux de treball àgil
- Diferència entre els models Agile Vs Waterfall
- Diferències entre proves àgils i proves de cascades
- Conclusió
Fluxos de treball de cascada i model àgil
En anglès senzill, Agile significa ‘capaç de moure’s ràpidament i fàcilment’ i, per tant, això és el que significa quan es tracta de Metodologia de desenvolupament àgil .
Àgil és un mètode de gestió de projectes que es representa dividint les tasques en segments de treball més curts amb revisions freqüents i adaptació de plans.
De la mateixa manera, la paraula cascada denota un flux vertical d’aigua o el flux d’aigua a través d’una sèrie de fortes gotes. El model de cascada és un model seqüencial lineal en què el progrés flueix majoritàriament en una direcció cap avall a través de les fases de recollida de requisits, anàlisi, disseny, desenvolupament, proves, desplegament i manteniment.
Aquesta mateixa il·lustració s'aplica al concepte de gestió de projectes quan es tracta de model de cascada . És un mètode de gestió de projectes que es representa mitjançant etapes en sèrie i un pla de treball fix.
[imatge font ]
Abans de discutir el flux de treball Waterfall i Agile, vegem la definició del cicle de vida del desenvolupament de programari i els seus requisits.
Què és el cicle de vida del desenvolupament de programari?
És un procediment pas a pas per desenvolupar el programari sistemàticament. Per a això, seleccionem entre diferents tipus de cicles de vida de desenvolupament de programari en diferents empreses. En funció del requisit, es selecciona un cicle de vida adequat.
El model de cascada és un dels tipus SDLC i és un procés antic de desenvolupament de programari. El model àgil és l’últim i avançat. Agile es deriva d'altres cicles de vida del desenvolupament de programari.
Altres SDLC inclouen el model en espiral, el model V i V, el model Prototype. Basant-nos en la necessitat i la compatibilitat del requisit empresarial, triarem el millor model per desenvolupar l’aplicació de programari.
[imatge font ]
Per què es requereix el cicle de vida del desenvolupament de programari?
Es requereix SDLC per gestionar el projecte de manera estructurada. Proporciona un cert nivell de control i defineix les funcions i responsabilitats dels membres de l’equip. Proporciona l'abast i el termini per a cada fase en SDLC.
És una mica com una guia d’usuari per als membres de l’equip per seguir tots els passos per desenvolupar i lliurar el producte de qualitat. Ajuda la direcció d’equips a definir i avaluar els objectius i els requisits. També ajuda a programar i estimar les tasques. Crea la línia de comunicació entre el client i l’equip de desenvolupament i crea els rols i les responsabilitats de cadascun d’ells.
Tipus de cicle de vida de desenvolupament de programari
Vegem una breu introducció als tipus de SDLC utilitzats en el procés de desenvolupament de programari.
# 1) Model de cascada
Com es va comentar anteriorment, el model de cascada és el primer cicle de vida de desenvolupament de programari introduït. És la forma seqüencial de desenvolupar programari. Molt poques empreses segueixen aquest enfocament. Quan el projecte sigui molt senzill i no hi hagi més canvis en els requisits, seguirem aquest enfocament.
En aquest tutorial parlarem més sobre el model de cascada.
# 2) Model àgil
Un flux de treball àgil és un enfocament avançat del procés de desenvolupament de programari, que s’utilitza a la majoria de les empreses. Agile es defineix com el cicle de vida del desenvolupament de programari basat en sprint.
A les properes seccions, podem parlar més sobre el flux de treball Agile.
# 3) Model en espiral
És la forma de construir i provar el programari dividint i afegint el requisit per ordre incremental. Aquest model ajudarà en projectes on els requisits continuen canviant. Aquest model en espiral és la combinació del procés de desenvolupament iteratiu i el procés de desenvolupament lineal seqüencial.
Aquest enfocament ens permetrà llançaments incrementals del producte. Aquí, no cal esperar a la finalització de tots els mòduls del programari per a la versió.
El model seqüencial lineal significa que és un enfocament seqüencial sistemàtic del desenvolupament de programari que comença a nivell del sistema i progressa mitjançant l'anàlisi, el disseny, la codificació, les proves i el suport.
El model iteratiu significa que és una implementació particular d’un cicle de vida del desenvolupament de programari que se centra en una implementació inicial simplificada, que progressivament guanya més complexitat i s’estableix una característica més àmplia fins que es completa el sistema final.
# 4) Model de prototipus
Aquest model inclou el procés de construcció i prova del programari de manera que, primer desenvolupem el model fictici i, si és factible i compleix tots els requisits del negoci, implementem el model de treball real.
En primer lloc, hem construït i provat el prototip i després hem construït el model real amb les especificacions exactes del sistema. El prototipatge de programari és l’activitat de creació de prototips d’aplicacions de programari.
# 5) Model V i V
És el model de verificació i validació. Aquí, mentre desenvolupàvem el programari, vam utilitzar per verificar i validar tot el que hi havia en cada fase del SDLC. El model V es considera una extensió del model de cascada.
Per tant, tots els tipus SDLC tenen les seves característiques i característiques. Basant-nos en els requisits del projecte, les necessitats, la viabilitat i la durada del temps, podem triar el cicle de vida del desenvolupament de programari concret per desenvolupar l’aplicació de programari.
Ara, analitzarem en detall els cicles de vida del desenvolupament de programari Waterfall i Agile.
Model de cascada
En el model de cascada, cada fase s'hauria de completar abans d'iniciar una altra fase. No podem operar diverses fases al mateix temps. Aquest va ser introduït el 1970 per Winston Royce. El model de cascada es divideix en diferents fases.
[imatge font ]
El model de cascada inclou les fases següents:
- Recollida de requisits
- Estudi de viabilitat
- Disseny
- Codificació
- Proves
- Manteniment
# 1) Anàlisi de requisits
Aquí, l’analista de negoci obtindrà l’especificació de requisits. El requisit estarà en el format CRS (Customer Requirement Specification). CRS explica com ha d’anar el flux de negoci i com ha de funcionar l’aplicació segons el requisit especificat. Els analistes empresarials convertiran CRS en SRS (Software Requirement Specification).
A continuació, l’analista de negoci analitza detalladament les especificacions de requisits amb l’equip de desenvolupament i proves i entén el requisit des del punt de vista de desenvolupament i proves. Aquesta és la fase per discutir i analitzar els requisits per construir el programari d'aplicació en funció dels requisits reals.
Aquí, tot s’ha de documentar al document d’especificació de requisits de programari. Al model de cascada, el lliurament / resultat / sortida de cada fase és la font d’entrada per a les fases següents.
En una indústria basada en serveis, un analista de negocis pot aportar el requisit.
En una empresa basada en productes, l’analista de productes aporta el requisit.
# 2) Estudi de viabilitat
L’equip directiu farà l’estudi de viabilitat. És a dir, l’equip analitzarà paràmetres com, si aquest requisit / aplicació es pot desenvolupar al nostre entorn o no, el recurs disponible és suficient o no, el cost i molts altres factors són factibles o no i per comprovar-ne som capaços de cobrir tots els fluxos de negoci o no.
En aquesta reunió / anàlisi, el cap de projecte, analista de negocis, gerent de finances, recursos humans, cap de projecte formarà part del debat.
# 3) Disseny del sistema
Aquí, l’arquitecte del projecte prepararà el disseny del sistema. Especificarà el maquinari, els requisits del sistema i dissenyarà l'arquitectura de l'aplicació. Hi ha 2 parts en el disseny del sistema: disseny d’alt nivell i disseny de baix nivell. En el disseny d’alt nivell, dissenyem els diferents blocs de l’aplicació. En el disseny de baix nivell, escrivim el pseudocodi.
# 4) Codificació
Aquí, els desenvolupadors inicien la codificació exacta de cada funció i interfície d’usuari de l’aplicació mitjançant diferents mètodes i diferents lògiques. Poden utilitzar qualsevol llenguatge de programació com Java, Python o qualsevol altre llenguatge per construir l'aplicació.
Un cop s'hagi completat la codificació de cada funcionalitat del mòdul concret de l'aplicació, el desenvolupador realitzarà la prova d'unitat. Si el codi funciona bé, el desenvolupador desplegarà el codi a l’entorn de prova i cedirà la versió al provador perquè el provi.
# 5) Proves
A partir d’aquí comença l’activitat de proves. Fins a aquesta fase, no tindrem cap tasca en el model de cascada. En aquesta fase, fem tot tipus de proves. Aquests tipus de proves inclouen proves de fum, proves funcionals, proves d’integració, proves de sistemes, proves d’acceptació, proves de regressió, proves ad-hoc, proves exploratòries i proves entre navegadors.
Començarem a provar l'aplicació un cop obtinguem la compilació. En primer lloc, començarem amb les proves de fum. Si no s’observen problemes de bloqueig, continuarem amb les proves detallades.
En les proves funcionals, començarem a provar cada component de l'aplicació. Aquí comprovem els diferents components com ara camps de text, botons, enllaços, botons d’opció, botons de càrrega, desplegables i enllaços de navegació.
A continuació, comprovarem la interfície d’usuari, el seu aspecte i les proves d’entrada positives i negatives.
Després començarem amb les proves d’integració. Aquí comprovarem la integració de dades. Verificarem si les mateixes dades es reflecteixen en diferents pàgines respectives o no, verificarem la navegació per enllaç de correu electrònic a les pàgines respectives. Comprovarem la integració de dades amb aplicacions de tercers i comprovarem els canvis de la base de dades a l’aplicació.
A continuació, farem proves de sistema. Revisarem tota l'aplicació com una sola unitat. Comprovarem la funcionalitat, la integració de les pàgines, les validacions de camp, els missatges d'error, els missatges de confirmació i molts més.
Mentre provem l'aplicació, registrarem els problemes a l'eina de seguiment d'errors. Donarem prioritat a l’error en funció dels problemes. Després de crear l'error, l'assignarem al desenvolupador corresponent per solucionar el problema. Verificarem els errors un cop els desenvolupadors els hagin assignat als provadors després de solucionar-los. Si funciona bé, el provador tancarà l'error, en cas contrari, els verificadors assignaran de nou al desenvolupador per solucionar el problema. Així continua el cicle de vida dels errors.
Després passem a la prova d’acceptació. Aquí provem l'aplicació en diferents entorns, com ara la prova temporal i UAT (User Acceptance Test). Aquesta és la fase més important per provar l'aplicació a fons abans de passar el codi a l'entorn de producció.
Un cop realitzades les proves d'acceptació sense errors, el client planejarà desplegar el codi al servidor de producció i planejarà la versió.
# 6) Manteniment
Un cop hàgim desplegat el codi de l'aplicació al servidor de producció, hauríem de proporcionar assistència / manteniment a l'aplicació client. Aquesta fase de manteniment consisteix a observar i solucionar els problemes de producció en temps real, comprovar els problemes de memòria, millorar l'aplicació i desenvolupar els nous canvis de requisits.
En quins casos podem optar pel model de cascada?
- Quan no hi hagi canvis necessaris.
- Quan el projecte és petit i senzill.
- Quan no hi ha complexitat en la tecnologia.
- Quan hi hagi més recursos disponibles.
Pros de la cascada:
- Endavant i enrere la planificació i implementació és fàcil .
- El model de cascada és senzill d’utilitzar i fàcil d’entendre. No requereix cap formació especial per a gestors de projectes o empleats. Té un corba d'aprenentatge fàcil .
- Com que és de naturalesa rígida, ho és fàcil de gestionar el cicle de les cascades. Cada fase té lliuraments fixos i un procés de revisió.
- Menys complexitat ja que les fases no se superposen. Les fases se segueixen una darrere l’altra. Utilitza una estructura clara en comparació amb les altres metodologies de desenvolupament de programari. El projecte passa per passos seqüencials fixos a partir de la recopilació de requisits i, finalment, arriba al manteniment.
- A causa del desenvolupament per fases, s’aplica la disciplina , i les escales de temps es poden mantenir fàcilment.
- Obres bé per a petits projectes on tenim requisits fixos i clars.
- Els processos i els resultats són ben documentat .
- Organitzar tasques és fàcil.
- És fàcil mesurar el progrés ja que els punts inicials i finals de cada fase estan predeterminats.
- Gairebé no hi ha canvis en els requisits al llarg del projecte, per tant, el les tasques es mantenen estables per als desenvolupadors. A més, és fàcil per a qualsevol desenvolupador nou per aprendre ràpidament i començar la feina.
- N’hi ha sense sorpreses econòmiques . Un cop fixats els requisits, es pot calcular el cost final abans d’iniciar el desenvolupament.
- Serveix per a model de finançament seqüencial .
- Seu disseny detallat fa que el resultat esperat final sigui molt clar per a tothom.
- L'especificació de requisits funcionals documentada a la fase de recollida de requisits proporciona prou detalls als verificadors per dissenyar escenaris de prova i casos de prova. Per tant, el el procés de prova es fa fàcil en el model de cascada.
Contres de la cascada:
- Com que tots els requisits s’han de conèixer clarament abans d’iniciar el desenvolupament, s’han de complir retarda el projecte .
- Requereix una àmplia investigació a les necessitats de l'usuari.
- A la fase inicial del projecte, és difícil per al client definir i conceptualitzar clarament els seus requisits en forma d’especificacions funcionals. Per tant, hi ha una gran possibilitat que canviïn d'opinió després de veure el producte final. Aquest canvi també es pot produir a causa d'un pla de negoci o influència del mercat. La baixa flexibilitat d’aquest model ho fa és difícil adaptar-se a aquests canvis , especialment quan cal reformular el producte en gran mesura.
- Cap model de treball es produeix fins al més tard etapa durant el cicle de vida de la cascada.
- Terminis de lliurament lents . El client no podrà veure el producte fins que no estigui completat.
- El client no té cap oportunitat de familiaritzar-se amb el sistema per endavant. El model de cascada és més aviat un procés intern i manté exclòs l'usuari final .
- El el client no està informat bé sobre la salut del projecte.
- Es poden perdre els terminis si no es manté una gestió estricta i un seguiment regular.
- Hi ha no hi ha marge per als canvis fins i tot si és visible durant el desenvolupament, ja que el producte no satisfà les necessitats del mercat.
- Retarda la prova fins després de finalitzar-la. A més, les grans revisions són molt costoses en aquest moment.
- Alt risc i incertesa participen en el model de cascada, ja que hi ha massa marge perquè els problemes passin desapercebuts fins que el projecte s’acosti.
- No és un model adequat per a projectes llargs, complexos i en curs.
- És difícil mesurar el progrés dins de cada fase.
- Els provadors es quedaran inactius durant les moltes etapes del projecte.
Flux de treball àgil
Ara veurem el cicle de vida del desenvolupament del programari Agile. Àgil és el procés de fer feina de forma ràpida i senzilla amb més precisió.
Aquest model està relacionat amb un mètode de gestió de projectes, utilitzat especialment per al desenvolupament de programari. Es caracteritza per la divisió de tasques en fases curtes de treball i freqüent reavaluació i adaptació de plans. Cada membre de l'equip ha de tenir la idea dels fluxos bàsics de negoci.
[imatge font ]
A Agile, els desenvolupadors i verificadors treballen paral·lelament per desenvolupar i provar el programari de l’aplicació. El desenvolupament es fa en mode iteratiu. Cada història de l'usuari de la iteració requereix l'anàlisi, el disseny, la codificació i la prova.
Provem el requisit de manera detallada per verificar si el requisit no conté errors i es pot implementar o no. Canvieu a la següent iteració després de finalitzar cada iteració i seguim el mateix procés fins als nous / altres requisits.
Per tant, aquest procés de desenvolupament i prova del bloc de programari es realitza en un curt període de temps amb més precisió i flexibilitat. Per tant, més indústries segueixen i adopten aquest procés.
En primer lloc, el propietari del producte afegirà tots els requisits al registre de productes. El registre de producte conté totes les històries dels usuaris. Diguem que entre 100 i 150 històries d'usuaris estan relacionades amb el projecte complet. Ara afegiu les històries d’usuaris concretes al backlog de sprint que hem d’implementar. A continuació, tots els desenvolupadors, QA, BA treballaran en els articles sprint. Així funciona el flux Agile.
Terminologies clau utilitzades en Agile
Què és el backlog de sprint?
creeu una matriu de cadenes a Java
És la llista d’històries d’usuaris que hem d’implementar en la iteració o sprint actual.
Per exemple, hi ha de 20 a 30 històries d'usuaris al backlog de sprint. A continuació, aquestes són les històries d’usuaris que hem d’implementar en el sprint actual.
[imatge font ]
Què és un Sprint?
Sprint és la petita durada en què hem d’implementar les històries d’usuari seleccionades en una durada determinada. La durada del sprint serà d’unes 2 a 3 setmanes. La seva durada varia d’empresa a empresa.
En aquesta durada del sprint, l’equip ha d’analitzar els requisits, dissenyar-los, realitzar codificacions, proves, solucionar el problema, tornar a provar, proves de regressió, demostració i moltes altres activitats.
Reunió diària Stand Up Scrum
L’analista de negocis, el desenvolupador, el verificador i el gestor de projectes formen part de les reunions diàries de stand up scrum. Es fa diàriament. No hauria d’allargar-se més de 15 a 30 minuts.
Aquí tots els membres de l'equip compartiran l'estat de treball diari. Les coses principals que comentem aquí són: quines són les coses acabades ahir, el pla per al treball d’avui i els reptes o dependències que s’enfrontin al projecte.
Si algun membre de l’equip s’enfronta a reptes o obstacles durant el projecte, la persona interessada hi treballarà per aconseguir-ho.
Gràfic Burndown
És una representació gràfica pictòrica del temps i del treball. L'eix x representa el treball restant, l'eix y representa el temps de sprint sobrant. L’equip ha de crear les tasques de treball relacionades amb el temps disponible al sprint concret. L’equip cremarà diàriament les hores de tasca en funció del treball que hagin realitzat i realitzat.
[imatge font ]
Gràfic Kanban
És un gràfic / eina de gestió de projectes. Amb això, podem gestionar les tasques de tot el projecte. Podem comprovar l’estat de progrés del projecte i l’estat de treball de les persones. Mostra la representació digital pictòrica d’elements de progrés, ítems pendents, ítems acabats.
[imatge font ]
exemple per a la interfície abstracta a Java
Planificació de l'activitat de pòquer
És un joc entre els membres de l’equip de sprint per estimar les històries dels usuaris. Aquí tot l’equip jugarà a l’activitat de pòquer. Cada membre de l'equip dóna l'estimació en funció del punt de la història de l'usuari. Basant-se en la majoria dels vots estimats, l’equip decidirà i assignarà la franja horària.
Per exemple , un membre de l'equip de la història de l'usuari donarà una estimació com 3, 5, 8, 3, 1, 3. Després, l'equip escollirà 3 com a estimació. La targeta d'activitat de pòquer conté 0, 1, 3, 5, 8, 13, 20, 100, descans, dubtes? targetes. Basat en aquest equip, els membres suggeriran qualsevol targeta d’estimació. Així, estimarem totes les històries dels usuaris relacionades amb el sprint concret.
[imatge font ]
- El número de pòquer 0 representa: no hi ha cap tasca en aquest article / història de l'usuari
- 1, 3 nombres representen: la tasca és menor
- 5, 8 nombres representen: tasques de nivell mitjà
- El número 13, 20 representa: tasques de gran nivell
- El número 100 representa: tasques molt grans
- Infinity representa: La tasca és enorme, cal dividir-la en diverses tasques i històries dels usuaris
- El descans representa: necessito un descans
- ? Representa: Dubtes
Scrum Master
És la persona que ajuda l'equip a seguir el procés àgil i complir els requisits del projecte. Conduirà la reunió sempre que sigui necessari i ajudi a debatre sobre la necessitat del projecte.
Scrum master actua com un pont per a tots els membres de l’equip per resoldre els reptes i les dependències que es presenten al projecte. Farà un seguiment del progrés del projecte en cada sprint.
Participa en la reunió stand-up, la reunió retrospectiva, la inspecció, la revisió i la demostració. Ell és qui dirigeix les reunions diàries de stand up i actualitza els membres de l’equip.
Propietari del producte
És la persona que impulsa i supervisa el producte / projecte des del punt de vista empresarial. Segueix veient com el producte es desenvolupa segons el requisit empresarial o no. És ell qui dóna prioritat a les històries dels usuaris i ha traslladat els requisits del backlog de producte al backlog de sprint. Estimarà els terminis del projecte.
Sempre mira el producte des del punt de vista de l’usuari. El propietari del producte té un coneixement complet sobre com ha de funcionar l’aplicació.
User Story
És un bloc de requisits. Conté el conjunt de casos / requisits d’ús relacionats amb el mateix mòdul. Aquí definim com ha de funcionar cada component d'una aplicació i com ha de ser la interfície d'usuari. L'abast de cada component es defineix a la història de l'usuari.
Tasques
Els membres de l'equip crearan la tasca per a la història de l'usuari que se'ls assigna. Han de crear la tasca en funció de les diferents tasques com ara tasca de desenvolupament, tasca de prova i tasca d’anàlisi de la història de l’usuari. La durada de la tasca hauria de dependre dels punts de la història de l'usuari.
Com a provador, crearem les tasques d'anàlisi de la història de l'usuari, preparació de casos, execució, proves de regressió i moltes més.
Neteja de retards
Aquesta part consisteix en la gestió d’elements pendents. Les activitats que fem aquí són: prioritzar els elements de retard, dividir-los en elements més petits, crear la tasca i actualitzar els criteris d’acceptació.
Iteració
La iteració és el desenvolupament i proves d'alguns mòduls / parts de l'aplicació de programari. Cada iteració consisteix en l'anàlisi del producte, el disseny del producte, el desenvolupament del producte, la prova del producte i la demostració del producte.
Factors clau per adoptar la metodologia àgil
- Observació: Reviseu el treball i el producte regularment i planifiqueu les activitats en conseqüència. Per tant, el procés de desenvolupament del producte i la qualitat del producte seran bons.
- Canvis de benvinguda: Els canvis es gestionen amb molta facilitat. No afecta gaire el producte perquè els mòduls del programari es desenvolupen per separat i s’integren més endavant. Per tant, no hi haurà cap reelaboració si el requisit es canviés en el futur.
- Període de temps: Se'ns dóna el termini de cada unitat de l'aplicació. Per tant, l'estimació serà exacta en relació amb les estimacions de temps del projecte.
- La satisfacció del client: La satisfacció del client és més perquè interactuem amb el client i l'accionista durant tot el projecte i donarem una demostració sobre cada nivell de desenvolupament de producte. D'aquesta manera, rebem els comentaris dels clients / clients periòdicament sobre els fluxos de negoci i el progrés del treball. Així, el treball i el desenvolupament de l'aplicació es realitzen en conseqüència.
Tipus de metodologies àgils
- Metodologia Agrum Scrum
- Desenvolupament de programari Lean
- Kanban
- Programació extrema (XP)
- Cristall
- Mètode de desenvolupament de sistemes dinàmics (DSDM)
- Desenvolupament basat en funcions (FDD)
Pros àgils:
- Un dels majors avantatges del model àgil és el seu gran adaptabilitat . L’adaptabilitat significa ‘respondre al canvi’. Agile és molt flexible a l’hora d’afrontar els canvis en les necessitats i prioritats dels clients.
- Permet perfeccioneu i prioritzeu constantment l’endarreriment global del producte sense afectar la iteració actual en què l’equip se centra a lliurar el MVP. Els canvis es poden planificar per a la següent iteració, oferint així l’oportunitat d’incorporar-los només en poques setmanes.
- La metodologia àgil ofereix un gran grau de compromís de les parts interessades . El client i l’equip del projecte es reuneixen abans, durant i després de cada sprint. Com que el client participa constantment durant tot el projecte, l’equip té més oportunitats per entendre clarament la seva visió.
- El programari de treball es lliura amb antelació i freqüència. Això augmenta el la confiança de les parts interessades a l’equip i l’anima a fer-ho romandre altament compromès al projecte.
- Aquest model dóna transparència . Tant les parts interessades com l’equip coneixen bé el que està passant. El client pot veure el treball en curs.
- S'han corregit els sprints de programació d'una a quatre setmanes lliurament anticipat i previsible . Les noves funcions es publiquen amb rapidesa i freqüència de manera horitzontal.
- Àgil és centrat en el client . No només proporciona la funcionalitat, sinó que també se centra a oferir la funció que té un cert valor per a l'usuari. Cada història de l'usuari té un criteri d'acceptació enfocat a l'empresa.
- Valorable comentaris dels clients es guanya aviat al projecte i es poden fer canvis al producte segons sigui necessari.
- El focus es posa en el valor empresarial . Primer ofereix el que és més important per al client.
- Millora la qualitat dels lliuraments . A diferència de la cascada, les proves es realitzen de forma contínua i freqüent en un projecte Agile i això, al seu torn, ajuda a detectar i solucionar els problemes aviat.
- Àgil admet l'enfocament TDD (Test Driven Development) que proporciona prou temps per crear proves unitàries de les funcions que es llançaran a través de MVP.
- També, produint construccions freqüents , qualsevol desalineació amb els requisits del client també es pot detectar i solucionar amb antelació.
- Com ho aconseguim comentaris immediats dels usuaris després de cada versió de MVP, el fitxer el risc de fracàs del projecte és baix, quan es treballa d’una manera àgil.
- Àgil promou el treball en equip . Hi ha una gran col·laboració, interacció, harmonia i entusiasme entre els membres de l'equip Agile.
- Les estimacions de costos i horaris de cada sprint es comuniquen al client abans de l'inici del sprint. Això millora la presa de decisions ja que l'usuari pot entendre el cost de cada funció i donar-hi prioritat en conseqüència.
- En un projecte àgil, hi ha lloc millora contínua . Les lliçons apreses dels sprints passats es poden aplicar als propers sprints.
- Se centra en la tasca particular en totes les etapes del projecte.
Contres àgils:
- Sovint es veu que els equips Agile tenen un tendència a descuidar la documentació . Això es deu al fet que el manifest Agile se centra més en el programari de treball que en la documentació completa. No obstant això, els equips haurien de mantenir l’equilibri adequat entre el codi i la documentació.
- Com que requereix un alt grau d’implicació del client, pot de vegades és problemàtic per als clients que no tenen gaire temps i interès per participar en el projecte.
- No funciona bé si a l’equip li falta compromís i dedicació. La cascada requereix implicació, però, Agile requereix compromís.
- Si l'arquitectura i el disseny inicials són febles, llavors refactorització freqüent es requereix.
- En comparació amb la cascada, Agile ho és difícil de practicar . Els membres de l’equip han de tenir un bon coneixement dels conceptes Agile. Es requereix molta disciplina i compromís per practicar Agile.
- A causa de la re-priorització, sí menys previsible del que es lliurarà al final de l'esprint.
- A causa del lliurament en temps limitat i de les prioritzacions freqüents, hi ha possibilitats que algunes funcions no es lliurin a la cronologia assignada. Això pot conduir a sprints addicionals i costos addicionals . Això també pot conduir al problema de línies de temps nebuloses .
- Manca d’estructura en comparació amb la cascada exigeix equips autodisciplinats, altament competents i capacitats . Sense això, el projecte pot ser realment un repte.
- La disponibilitat és menys un pla del lliurament final .
- De vegades el les parts interessades externes no poden resistir-se a seguir l’enfocament Agile . En aquests casos, es requereix formació i educació sobre Agile per a un públic ampli.
- Cal que tots els membres de l’equip participin en la gestió del projecte.
- La documentació és menys detallada.
Diferència entre els models Agile Vs Waterfall
A continuació es detallen les diferències entre els cicles de vida del desenvolupament de programes Waterfall i Agile.
Cascada | Àgil |
---|---|
El procés es tracta com un sol projecte que es divideix en diferents fases. | El procés es divideix en múltiples projectes i cada projecte té una iteració de diferents etapes. |
La metodologia de les cascades és un model en què cada etapa del cicle de vida del producte es produeix en una seqüència. El progrés del projecte flueix gradualment cap avall a través d’aquestes fases semblant a una cascada. | La metodologia àgil és un model que segueix un enfocament iteratiu. |
Aquest model creu en un lliurament massiu únic. El producte es lliura al final del SDLC. | Aquest model creu en múltiples petits trossos d’entrega a intervals de temps definits. Al final de cada esprint es lliura un MVP (Producte Viable Mínim). |
És un enfocament tradicional i passat de moda. | És un enfocament nou i modern. |
Un sol cicle i un sol llançament. | Nombre repetitiu d'iteracions i versions múltiples. |
Divideix el cicle de vida del desenvolupament de programari en diferents fases. | Divideix el cicle de vida del desenvolupament de programari en sprints. |
Model estructurat i rígid. És difícil alterar la descripció, les especificacions i el disseny del projecte. | Aquest model és conegut per la seva flexibilitat. Podem fer canvis en qualsevol fase del projecte en qualsevol moment. |
Escala de planificació a llarg termini. | Escala de planificació a curt termini. |
Hi ha una llarga distància entre el client i el desenvolupador. | Hi ha una distància curta entre el client i el desenvolupador. |
Molt temps entre l'especificació i la implementació. L'analista empresarial recopila i prepara el requisit abans del començament del projecte. | Poc temps entre l'especificació i la implementació. El propietari del producte prepara els requisits i les actualitzacions de l’equip en cada sprint. |
Triga molt a descobrir problemes. | Els problemes es descobreixen ràpidament. |
Alt risc de programació del projecte. | Baix risc de programació del projecte. |
Menys capacitat per respondre ràpidament als canvis. | Alta capacitat de resposta ràpida als canvis. |
La fase de proves només es produeix després de la finalització de la fase de desenvolupament. | Les proves es realitzen generalment en paral·lel al desenvolupament per garantir la qualitat contínuament. |
El client només participa a la fase de recollida de requisits i després no hi ha cap implicació del client. Surt a la imatge només en el moment del lliurament del producte. | El client participa durant tot el projecte i, de tant en tant, se’n retorna la retroalimentació per garantir la satisfacció del client. |
Apte per a projectes amb requisits clarament definits i aquells que no esperen canvis. | Apte per a projectes que han d’evolucionar i per a aquells que impliquen canvis en els requisits. |
Procés estrictament seqüencial. | El procés de desenvolupament de programari altament col·laboratiu comporta millors esforços en equip i resolució ràpida de problemes. |
Mostra una mentalitat del projecte. | Introdueix una mentalitat de producte i, per tant, se centra més en el client. Les demandes i els canvis formen part del procés |
Formal i jeràrquica. El responsable del projecte és el que pren les decisions. | És informal. Tot l’equip és responsable de la presa de decisions. |
Aquest model preveu que no hi haurà canvis en els requisits al llarg del projecte. | Aquest model es basa en l’adaptació i abasta els canvis. |
Necessitat de crear documents manuals per verificar l'estat del treball i del progrés de l'individu. | Segueix el gràfic Kanban i el gràfic Burn Down per verificar el progrés del projecte i l'estat de treball de l'individu. |
Vam tenir prou discussió sobre les diferències entre les metodologies Agile & Waterfall i els beneficis i reptes de cadascuna. Explorem ara les diferències entre proves àgils i proves de cascades.
Diferències entre proves àgils i proves de cascades
Des de la perspectiva de les proves de programari, és important que tinguem una bona idea sobre com les proves Agile són diferents de les proves Waterfall.
Proves de cascades | Proves àgils |
---|---|
Els equips de prova i els equips de desenvolupament estan separats per un límit clar i hi ha una comunicació estricta i formal entre ells. | L’equip de proves i els equips de desenvolupament s’integren com un sol equip i hi ha un flux lliure de comunicació entre ells. |
Les proves comencen després de finalitzar el desenvolupament i construeixen fases. | Les proves comencen simultàniament amb la fase de desenvolupament. |
La planificació es fa només una vegada abans de la fase de proves. | La planificació es fa abans que comenci el projecte i sovint es fa durant el projecte. |
El pla de proves poques vegades es revisa durant el projecte. | El pla de proves es revisa després de cada sprint. |
És un desafiament tranquil per a l'equip de proves proposar qualsevol canvi en els requisits. | L’equip de proves participa activament en el procés de recollida de requisits i canvi. |
Els casos de prova es creen una vegada per a totes les funcionalitats. | Els casos de prova es creen sprint per sprint per a les funcionalitats que cal alliberar a cada sprint. |
El client realitza les proves d’acceptació una vegada després del llançament. | Les proves d’acceptació es poden fer després de cada iteració i abans del lliurament per part d’un analista de negoci o de l’equip de proves. Més tard, el client ho fa després de cada llançament. |
Documentació de proves detallada i extensa. | La documentació de la prova només es fa tant com sigui necessari. |
Les estimacions i assignacions de les proves sovint són responsabilitat del gestor de proves. | Les estimacions i les tasques de les proves són responsabilitat compartida de l’equip i dels enginyers de proves que participen a l’hora de proporcionar les estimacions i escollir les seves tasques. |
Les proves de regressió poques vegades es fan i impliquen l'execució de tots els casos de prova. | Les proves de regressió es realitzen després de cada iteració i només inclouen els casos de prova necessaris. |
Conclusió
En aquest article, hem après les diferències exactes entre l'enfocament Agile modern i el mètode tradicional de cascada de desenvolupament i prova de programari amb una taula de comparació que cobreix els pros i els contres de cada model.
Si considerem tots els factors que s’enumeren en aquest article, podem seleccionar el model de cicle de vida de desenvolupament de programari correcte per desenvolupar l’aplicació de programari. No hi ha dubte en dir que es prefereixen les metodologies àgils per sobre del model de cascada. El 90% de les empreses prefereixen i segueixen el flux de treball Agile per desenvolupar l'aplicació de programari.
La metodologia àgil és bona per a tot tipus de projectes. Molt poques empreses segueixen la metodologia de les cascades. Aquesta metodologia només és adequada si l’aplicació és petita, senzilla i no hi ha canvis en el requisit.
En alguns casos, també optem per altres enfocaments anomenats Espiral, V i V i Prototip, en funció de les necessitats.
Espero que aquesta informació us sigui útil per decidir quin és el millor model per al vostre projecte. També podeu anar pel model híbrid que elimina els inconvenients de cada mètode - aquí es parla.
Lectura recomanada
- Estudi de cas: Com eliminar els defectes de les cascades i els processos de desenvolupament àgil mitjançant un model híbrid
- Què és el model de cascada SDLC?
- Revisió de l'eina de gestió de proves empresarials de Zephyr: com s'utilitzen els recursos del model de cascada a l'eina Agile
- Tutorial de VersionOne: Guia d'eines de gestió de projectes Agile tot-en-un
- Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in for JIRA (Review)
- TOP 10 de les millors eines de gestió de projectes àgils el 2021
- Tècniques d’estimació àgil: una estimació real en un projecte àgil
- 4 passos cap al desenvolupament de la mentalitat de proves àgils per a la transició amb èxit al procés àgil