La indústria informàtica està plena de llenguatge ambigu, argot dur i idees complexes que són difícils d'entendre i poden enviar la vostra ment a un frenesí d'amortització computacional.
Cascada? Scrum? Àgil?
Si aquestes frases et resulten completament estranyes, no et preocupis; El vostre equip útil de geeks tecnològics de HashDork està aquí per ajudar-vos a entendre les distincions entre aquestes etapes crucials del procés de desenvolupament perquè pugueu tenir coneixements.
Les tècniques àgils, scrum i cascada es tractaran en aquesta publicació del bloc, juntament amb com cadascuna pot ajudar al vostre equip en conjunt.
Comencem per l'àgil, i ens encarreguem de la resta.
Què és Agile?
El desenvolupament de programari àgil segueix un enfocament iteratiu i incremental. En lloc d'una preparació extensa a l'inici d'un projecte, les tècniques àgils són flexibles per adaptar-se a les necessitats canviants al llarg del temps i promouen la retroalimentació continuada dels usuaris finals.
Els equips multifuncionals treballen en iteracions de productes al llarg del temps, i aquest treball es classifica en un backlog i es prioritza en funció del valor empresarial o del client. El propòsit de cada iteració és crear un producte utilitzable.
El lideratge promou la cooperació, la responsabilitat i la comunicació cara a cara en metodologies àgils.
Les parts interessades del negoci i els desenvolupadors han de col·laborar per garantir que el producte compleix les demandes del consumidor i els objectius de l'empresa.
La frase "desenvolupament àgil" es refereix a una varietat de mètodes i marcs que es basen en els ideals i principis descrits a la Manifest àgil.
Els experts aconsellen adherir-se a principis i valors àgils i utilitzar-los com a guia per decidir les accions adequades a prendre en un entorn concret mentre s'apropa al desenvolupament de programari.
L'equip col·laboratiu i autoorganitzat són les principals àrees d'atenció per a la comunitat de desenvolupament de programari àgil.
Els equips poden decidir de manera autònoma com abordaran un projecte concret, però això no vol dir que els supervisors siguin inexistents. Per tant, els equips àgils són transversals.
En un paradigma àgil, els directius encara són necessaris. Asseguren que cada membre de l'equip té o adquireix les habilitats necessàries per al projecte.
Els directius en un marc àgil operen fomentant un ambient que treu el millor de l'equip. Però en lloc de prendre el lideratge, sovint passen a un segon pla i deixen que l'equip decideixi com oferiran les coses.
Els directius només s'impliquen quan els equips intenten resoldre problemes repetidament sense èxit.
Cicle de desenvolupament àgil
A continuació s'enumeren les etapes del cicle de desenvolupament àgil. És fonamental recordar que aquestes fases no s'han de fer en ordre perquè són flexibles i canvien constantment. Moltes d'aquestes etapes tenen lloc simultàniament.
- Planificació: Després que un equip del projecte hagi decidit que una idea és pràctica i viable, comencen a buscar funcions. Aquesta fase té com a objectiu prioritzar cada característica i assignar-la a una iteració després de dividir la idea en peces de treball més petites (les característiques).
- Anàlisi de requisits: Per determinar els requisits empresarials, aquest pas implica diverses discussions amb gestors, grups d'interès i usuaris. Qui utilitzarà el producte i com el farà servir es troben entre els detalls que l'equip ha de recollir. Aquestes normes han de ser específiques, aplicables i quantitatives.
- disseny: Els requisits trobats en l'etapa anterior s'utilitzen per preparar el disseny del sistema i del programari. L'equip ha de tenir en compte l'aspecte del producte o solució. L'equip de prova també desenvolupa una estratègia o pla per a la prova.
- Implementació, codificació o desenvolupament: L'enfocament d'aquesta etapa és construir i avaluar les característiques i planificar el desplegament d'iteracions (seguint l'enfocament de desenvolupament iteratiu i incremental [IID]). Com que no es proporcionen funcions, comença la iteració 0 del període de desenvolupament. En completar activitats com la contractació, la configuració i el finançament, aquesta iteració proporciona les bases per al creixement futur.
- Proves: Un cop creat el codi, es prova amb els requisits per garantir que el producte realment satisfà les demandes dels usuaris i compleixi els objectius comercials. En aquesta fase es realitzen proves d'unitat, integració, sistema i acceptabilitat.
- Desplegament: Després de les proves, el producte s'envia als clients perquè puguin utilitzar-lo. Tanmateix, el projecte no s'ha acabat després del desplegament. Els clients poden trobar problemes addicionals després de començar a utilitzar el producte, que necessitaran que l'equip del projecte trobi una solució.
avantatges
- Lliurament més ràpid i de millor qualitat: En dividir el projecte en iteracions (unitats gestionables), l'equip es pot concentrar en la col·laboració, el desenvolupament i les proves de més qualitat. Quan es fa la prova amb cada iteració, els problemes es troben i es solucionen més ràpidament. A més, amb revisions constants i posteriors, aquest programari d'alta qualitat es pot subministrar més ràpidament.
- El canvi és benvingut: Tot i que els cicles de planificació són més curts, és senzill acceptar i acomodar els canvis en qualsevol moment del projecte. L'endarreriment sempre es pot millorar i reprioritzar, permetent als equips fer canvis al projecte en un parell de setmanes.
- Pot ser que no es conegui l'objectiu final: Agile és excel·lent per a projectes quan l'objectiu final no està clarament definit. A mesura que el projecte avanci, els objectius es faran clars i el desenvolupament podrà adaptar-se fàcilment a aquestes necessitats canviants.
- Millora contínua: Els programes àgils promouen l'entrada d'usuaris i equips en totes les etapes del projecte, permetent l'aplicació del que s'aprèn per millorar la següent iteració.
- Es valoren les opinions dels clients: Hi ha diverses oportunitats perquè els clients puguin veure com s'està acabant el treball, oferir comentaris i afectar realment el resultat final. En interactuar tan íntimament amb l'equip del projecte, podrien desenvolupar un sentit de propietat.
- Fort treball en equip: Àgil emfatitza la importància de la comunicació regular i les trobades en persona. Les persones poden assumir responsabilitats i ser propietaris de determinats components del projecte quan treballen en equip.
Desavantatges
- Els membres de l'equip han de tenir coneixementse: Els equips àgils solen ser petits. Per tant, els membres de l'equip han de tenir una àmplia gamma d'habilitats. A més, han d'entendre i sentir-se a gust amb la tècnica Agile seleccionada.
- La planificació podria ser menys precisa: De vegades pot ser difícil determinar una data de lliurament exacta. L'àgil es basa en el lliurament a temps, i els gestors de projectes sovint reorganitzen les prioritats de les tasques. Per tant, és probable que alguns dels lliuraments que s'havien programat inicialment per al lliurament no s'acabin a temps. A més, es poden afegir més sprints en qualsevol moment del projecte, allargant tot el calendari.
- Es pot ignorar la documentació: Alguns membres de l'equip podrien creure que concentrar-se en la documentació és menys crucial, ja que el Manifest àgil afavoreix el funcionament del programari per sobre de la documentació exhaustiva. Els equips àgils haurien d'aconseguir l'equilibri ideal entre documentació i diàleg, tot i que una documentació exhaustiva no pot garantir l'èxit del projecte per si sola.
- La sortida final pot ser molt diferent: Pot ser que no hi hagi hagut una estratègia clara per al projecte Agile inicial i, per tant, el resultat final pot variar molt del que s'havia previst inicialment. Una sortida final substancialment diferent pot resultar d'afegir noves iteracions basades en el canvi d'entrada del client, ja que Agile és molt adaptable.
- Compromís de temps dels desenvolupadors: L'equip de desenvolupament ha d'estar plenament compromès amb el projecte perquè agile sigui eficaç. El mètode Agile, que triga més temps que un enfocament convencional, requereix una participació i cooperació activa constant. A més, implica que els desenvolupadors s'han de comprometre amb la durada completa del projecte.
Què és la cascada?
La iteració més popular del cicle de vida de desenvolupament del sistema (SDLC) per a projectes d'enginyeria de programari i TI es coneix com a "enfocament en cascada", que segueix un procediment seqüencial i lineal.
Un diagrama de Gantt, una forma de diagrama de barres que mostra les dates d'inici i finalització de cada treball, s'utilitza ocasionalment per planificar-lo.
L'equip de desenvolupament avança al nivell següent després d'haver acabat una de les vuit fases. L'equip no pot tornar a una fase anterior sense haver de reiniciar tot el procediment.
A més, és possible que el client hagi d'avaluar i acceptar els requisits abans que l'equip pugui passar al següent nivell.
El model de cascada es va desenvolupar en els entorns altament organitzats dels sectors de la fabricació i la construcció, on els ajustos podrien ser prohibitius o fins i tot impossibles.
La tècnica de la cascada s'anomena així perquè està pensada per fluir en una sola direcció, cap avall, com una cascada. Les seves fases inclouen anàlisi, inici, proves, disseny, construcció, desplegament, manteniment i proves.
La tècnica de la cascada té diversos avantatges, com qualsevol altra estratègia. Una és que les fases de planificació i disseny del projecte estan més ben establertes.
Els clients i l'equip de desenvolupament estan més alineats quan es tracta de lliuraments del projecte mentre utilitzen el desenvolupament de programari en cascada. Com que coneixeu l'abast del projecte des del principi, el desenvolupament de la cascada també facilita el seguiment del progrés.
El procés de cascada utilitza especialistes, desenvolupadors, analistes i provadors per concentrar-se en la seva feina al projecte en lloc de fer que tot l'equip emfatitzi un pas.
Etapes de la Cascada
Els sis passos de la cascada s'han de produir un darrere l'altre:
- Requisits de recollida i emmagatzematge: Hauríeu d'acumular un coneixement exhaustiu sobre què demana aquest projecte en aquest moment. Hi ha diverses tècniques per recollir aquestes dades, com ara entrevistes, enquestes i pluja d'idees col·laborativa. Les necessitats del projecte haurien de ser evidents quan finalitzi aquesta fase i el vostre equip hauria d'haver rebut una còpia del document de requisits.
- Disseny d'un sistema: el sistema està dissenyat pel vostre equip utilitzant especificacions predeterminades. Durant aquesta etapa, no es fa cap codificació, però l'equip estableix requisits per al maquinari o el llenguatge de programació.
- Implementació: Aquesta etapa implica la codificació. Els programadors utilitzen les dades de l'etapa anterior per crear un producte utilitzable. El codi sovint s'implementa en petits fragments que es combinen al final d'una fase o al començament d'una altra.
- Proves: el producte es pot començar a provar un cop completat el codi. Qualsevol problema es troba meticulosament i es reporta pels provadors. És possible que el vostre projecte hagi de tornar a la fase XNUMX per a una reavaluació si apareixen problemes importants.
- Lliurament/desplegament: el producte s'ha acabat en aquest moment i el vostre equip envia els lliuraments per al desplegament o el llançament.
- manteniment: El client ha rebut el producte i l'està utilitzant. És possible que el vostre equip hagi de desenvolupar solucions i actualitzacions quan apareguin problemes per solucionar-los. De nou, problemes importants poden requerir un retorn al primer pas.
avantatges
- Fàcil d'operar i gestionar: L'enfocament Waterfall és senzill d'utilitzar i comprendre, ja que cada projecte es gestiona de la mateixa manera seqüencial. Abans de començar un projecte Waterfall, l'equip no ha de tenir cap experiència ni formació prèvia. L'enfocament de la cascada és molt estricte; cada etapa té un conjunt de resultats i una revisió, cosa que fa que sigui fàcil d'administrar i mantenir.
- Es requereix una metodologia ben documentada: La documentació que requereix la metodologia de la cascada ajuda a aclarir el raonament de les proves i el codi. A més, crea un rastre en paper en cas que les parts interessades vulguin informació addicional sobre una fase determinada o per a qualsevol iniciativa futura.
- Compliment de la disciplina: Cada pas d'un projecte de cascada té un inici i un final, de manera que és senzill comunicar el progrés a les parts interessades i als clients. L'equip pot reduir la possibilitat de perdre una data límit posant primer els requisits i el disseny abans de produir codi.
Desavantatges
- Pot ser difícil reunir requisits precisos: Parlar amb consumidors i parts interessades per determinar les seves necessitats és una de les etapes inicials d'un projecte Waterfall. En aquesta fase inicial del projecte, pot ser difícil determinar els seus requisits particulars. Els clients sovint aprenen sobre els seus requisits a mesura que es desenvolupa el projecte en lloc d'expressar-los per endavant.
- Els canvis són difícils d'acomodar: La tripulació no pot reprendre el treball després d'acabar una fase. És molt difícil i costós tornar enrere i reparar-lo si s'assabenten durant la fase de prova que faltava funcionalitat durant el procés de requisits.
- El programari es proporciona després de la seva data de venciment: S'han d'acabar de dues a quatre fases del projecte abans de començar la codificació real. Com a resultat, les parts interessades no veuran programari funcional fins al final del cicle de vida.
Què és Scrum?
Un dels marcs de procés més populars per posar en pràctica Agile és Scrum, que és un subconjunt d'Agile.
És un paradigma iteratiu per gestionar la creació de programari i productes complexos. Els sprints, que són iteracions de durada fixa que s'executen d'una a dues setmanes, permeten a l'equip llançar programari amb una programació regular.
Les parts interessades i els membres de l'equip es reuneixen per discutir els següents passos després de cada sprint. Els rols, les responsabilitats i les reunions a Scrum es mantenen constants.
Per exemple, Scrum especifica la planificació de l'esprint, el stand-up diari, la demostració de l'esprint i la retrospectiva de l'esprint com els quatre rituals que proporcionen cada estructura d'esprint.
L'equip utilitzarà artefactes visuals com taulers de tasques o gràfics d'explosió durant cada sprint per demostrar el progrés i obtenir comentaris incrementals.
En scrum, l'equip i el propietari del producte treballen estretament junts per identificar i prioritzar la funcionalitat del sistema. Ho aconsegueixen creant un backlog de productes, que conté totes les tasques necessàries per produir programari que funcioni segons el previst.
Els pedaços d'error, els requisits no funcionals i les funcions s'han d'incloure a la cua. Els equips multifuncionals han d'estimar i registrar-se per oferir increments de programari durant Sprints continus, que normalment duren 30 dies, un cop s'han establert els objectius.
Només l'equip pot afegir funcionalitat a l'Sprint després de comprometre l'endarreriment d'aquest sprint.
El següent lliurament de l'Sprint, s'avalua la cartera de productes i, si cal, es prioritza de nou i s'escull el següent conjunt de lliuraments per formar part de l'esprint següent.
Procés Scrum
- Cartera de productes: Per demanar els articles del producte backlog, es reuneixen el Product Owner i l'equip Scrum (el treball del producte backlog prové de les històries i els requisits dels usuaris). El backlog del producte és una llista de totes les funcions desitjades per al producte en lloc d'una llista de tasques que s'han de completar. Després d'això, l'equip de desenvolupament selecciona les tasques de la cartera de productes per executar-les al llarg de cada sprint.
- Planificació de l'esprint: Abans de cada sprint, el propietari del producte lliura a l'equip els elements principals de la cartera en una reunió de planificació de l'esprint. Aleshores, el grup selecciona elements de la cartera de productes que poden acabar durant l'esprint i els trasllada a la llista de tasques de l'esprint (que és una llista de tasques per completar a l'esprint).
- Refinament/preparació de l'endarreriment: Per tal d'assegurar-se que el backlog estigui preparat per al següent sprint, l'equip i el propietari del producte es reuneixen al final d'un sprint. L'equip pot descartar històries d'usuari que ja no són pertinents, afegir-ne de noves, revisar l'ordre en què s'han de tractar o dividir les històries d'usuari en tasques més petites. Durant aquesta trobada de “grooming”, s'assegurarà que l'endarreriment només inclogui coses pertinents, profundes i d'acord amb els objectius del projecte.
- Reunions Scrum cada dia: En una reunió stand-up de 15 minuts anomenada Daily Scrum, cada membre de l'equip discuteix els seus objectius i qualsevol problema que hagi sorgit. Cada dia durant tot l'sprint, l'equip participa en el Daily Scrum, que manté a tothom en la tasca.
- Reunió per valorar l'esprint: L'equip presenta el seu treball en una reunió de revisió de l'esprint al final de cada sprint. En lloc d'un informe o una presentació en PowerPoint, aquesta reunió hauria d'incloure una demostració real.
- Trobada retrospectiva de sprint: L'equip discuteix qualsevol modificació que calgui fer en el següent sprint, així com el bé que Scrum està funcionant per a ells al final de cada sprint. L'equip pot discutir els aspectes positius, negatius i les àrees de millora de l'esprint.
avantatges
- Més responsabilitat per part de l'equip: No hi ha cap cap de projecte que instrueixi l'equip scrum sobre què fer i quan. El treball que es pot acabar en cada sprint és decidit pel conjunt de l'equip. Tots cooperen i s'ajuden els uns als altres, millorant el treball en equip i fomentant la individualitat de cada membre de l'equip.
- Millora de la visibilitat i transparència del projecte: Hi ha menys malentesos i incerteses, ja que tots els membres de l'equip són conscients de les seves responsabilitats gràcies a les freqüents reunions de suport. L'equip pot fer front als problemes abans que es descontrolin, ja que els problemes es detecten amb antelació.
- Reducció de costos millorada: La comunicació constant manté l'equip informat de qualsevol problema o canvi tan aviat com es produeix, la qual cosa ajuda a estalviar costos i millorar la qualitat. Els fragments de funcions més petits proporcionen retroalimentació contínua i permeten la correcció d'errors primerenca abans que els errors més grans siguin massa cars per solucionar-los.
- Fàcil d'adaptar als canvis: és més senzill d'afrontar i adaptar-se als canvis quan hi ha bucles de retroalimentació freqüents i sprints curts. A tall d'il·lustració, si l'equip es troba amb una història d'usuari completament nova durant un sprint, poden afegir ràpidament aquesta funció a l'sprint següent a la reunió de perfeccionament de l'endarreriment.
Desavantatges
- Perill de fluïdesa d'abast: a causa de la manca d'una data de finalització fixa, alguns projectes de Scrum poden tenir una variació de l'abast. Les parts interessades es podrien atreure a continuar exigint més funcions si no hi ha un termini per a la finalització.
- Un mal Scrum Master pot descarrilar-ho tot: Un gestor de projectes no és el mateix que un Scrum Master. El Scrum Master ha de confiar en l'equip que està supervisant i mai donar-los instruccions. El Scrum Master no té poder sobre l'equip. El projecte fracassarà si el scrum master intenta gestionar l'equip.
- Els problemes de precisió poden derivar de tasques mal formulades: Si les tasques no s'especifiquen clarament, les despeses i els horaris del projecte no seran precisos. La planificació es torna difícil i els sprints poden trigar més del previst si no es defineixen els objectius inicials.
- L'experiència i la dedicació són necessàries per a un equip: Perquè l'equip tingui èxit, els rols i els deures s'han de definir clarament. L'equip Scrum requereix membres de l'equip amb habilitats tècniques perquè no hi ha rols clarament definits (tothom ho fa de tot). L'equip també s'ha de comprometre a participar en les sessions diàries de Scrum i a mantenir-se unit durant la vida del projecte.
Àgil vs Scrum
Tot i que Agile i Scrum utilitzen la mateixa metodologia, hi ha algunes variacions entre els dos. El Manifest àgil exposa un conjunt de principis per crear programari mitjançant el desenvolupament iteratiu.
Scrum, d'altra banda, és un conjunt de directrius que s'han de complir mentre es fa el desenvolupament de programari àgil. Agile és un concepte, mentre que Scrum és una tècnica per posar-lo en pràctica.
Scrum és un mètode per implementar Agile, per tant tots dos tenen moltes coses en comú. Tots dos enfocaments són iteratius, prioritzen el lliurament de programari precoç i freqüent i accepten el canvi. També donen suport a l'obertura i al desenvolupament continu.
Àgil Vs Cascada
Rigid vs. flexible descriu millor les distincions entre el procés Waterfall i Agile. Tot i que Agile és fluid i canvia constantment, Waterfall és una metodologia molt més ajustada i rígida.
Aquestes distincions addicionals entre ells són les següents:
- Àgil no requereix un enfocament lineal, mentre que Waterfall és seqüencial.
- Tot i que les necessitats solen estar predefinides als projectes Waterfall, es preveu que s'alterin i s'adaptin a les iniciatives àgils.
- A diferència d'Agile, els projectes Waterfall no permeten fer modificacions a les obres que es van completar en una fase prèvia.
- La cascada és un procediment organitzat en el qual cal acabar cada pas abans de passar al següent. Tanmateix, Agile és una metodologia flexible que us permet continuar amb el projecte al vostre ritme.
Àgil Vs Cascada Vs Scrum
- La cascada augmenta la confiança en el que es proporcionarà molt aviat després que estigui previst. Agile es basa en les millors pràctiques d'un entorn de desenvolupament. Aquí, una sèrie de riscos del projecte es poden gestionar bé, ja que els resultats s'avaluen contínuament.
- Waterfall no preveu que l'equip i el projecte estiguin basats al mateix lloc. Mentre que Scrum i Agile necessiten la coubicació dels empleats.
- Agile se centra a reduir la reelaboració del projecte i fomenta que els canvis s'incorporin molt abans. A diferència de la cascada, que respon de manera diferent, scrum també permet el descobriment precoç dels canvis.
- Un model més compacte per al producte final és proporcionat per agile i scrum. Això crea un problema amb les promeses fetes al comprador. En canvi, el gràfic de cascada ofereix als clients i desenvolupadors una millor impressió del resultat final.
- Cadascuna d'aquestes tècniques té un conjunt d'eines per organitzar i simular les tasques que implica la seva creació.
Conclusió
Si heu seguit fins ara i confieu en el vostre coneixement de les distincions entre els processos Waterfall, Agile i Scrum, ja hauríeu de saber quina estratègia funcionarà millor per a vosaltres i el vostre equip.
La tècnica Waterfall, que és per a projectes amb un abast, un termini i un pressupost definits, pot ser la vostra millor opció si us agraden les regles i els procediments durs i trobeu que aporten claredat.
D'altra banda, si la llibertat i l'adaptabilitat que ofereix Agile t'inspiren, podria ser on hauries de posar la teva atenció.
Scrum és el camí a seguir, però, si voleu una mica de disciplina dins d'un marc flexible.
Tanmateix, heu de tenir en compte aquests enfocaments a la llum del projecte en què esteu treballant i del vostre resultat final.
Deixa un comentari