Menú

Metodologia àgil: una guia per a principiants sobre mètode àgil i Scrum

agile methodology beginner s guide agile method

Proveu El Nostre Instrument Per Eliminar Problemes

Una guia completa de metodologia àgil: (més de 20 tutorials detallats sobre metodologia Agile Scrum)

Aquesta és la guia per als desenvolupadors i provadors de programari per entendre i començar a treballar en el famós Metodologia Agile SCRUM per al desenvolupament i proves de programari . Apreneu les terminologies bàsiques però importants que s’utilitzen en el procés Agile Scrum juntament amb un exemple real del procés complet.

Per a la vostra comoditat, hem detallat tots els tutorials àgils d’aquesta sèrie. Espero que us siguin d’immensa ajuda.

Temes tractats: Què és Agile, Què és Scrum, Metodologia Agile en desenvolupament i proves de programari, Proves Agile, Procés Scrum Agile, Metodologia Scrum amb Scrum Team i Scrum Master.

introducció al desenvolupament àgil

Què aprendreu:

Llista de tutorials de metodologia àgil

Tutorial # 1: Metodologies Agrum Scrum (Aquest tutorial)
Tutorial # 2: Manifest Àgil
Tutorial # 3: L’equip Scrum i els seus rols i responsabilitats
Tutorial # 4: Artefactes Scrum
Tutorial # 5: Esdeveniments Scrum
Tutorial # 6: Triage de defectes a Scrum
Tutorial # 7: Equips Scrum autosuficients
Tutorial # 8: Three Amic Principle
Tutorial # 9: SAFe: marc àgil a escala
Tutorial # 10: Preguntes sobre Scrum Agile

MÉS Tutorials Agile Scrum recomanats:

Tutorial # 11: Principals tècniques d’estimació àgil
Tutorial # 12: Model híbrid de cascada àgil
Tutorial # 13: Kanban vs Scrum vs Agile
Tutorial # 14: JIRA Agile Tutorial
Tutorial # 15: Trobades retrospectives àgils
Tutorial # 16: Paper dels analistes de negocis a SCRUM
Tutorial # 17: El paper de QA a Scrum

Eines i preguntes d’entrevistes:

Tutorial # 18: Eines de prova àgil
Tutorial # 19: Les millors eines de gestió de projectes àgils
Tutorial # 20: Preguntes principals sobre les entrevistes àgils
Tutorial # 21: Preguntes més freqüents sobre l'entrevista Scrum

Comencem pel primer tutorial de la sèrie: Introducció Agile Scrum.

Introducció al desenvolupament àgil

Àgil en desenvolupament de programari:

Agile és un dels marcs de desenvolupament de programari més utilitzat i reconegut del món.

La majoria de les organitzacions l’han adoptat d’una manera o altra, però encara queda molt per recórrer en la maduresa dels seus programes d’adopció. L'únic objectiu d'aquesta sèrie de tutorials és incorporar professionals de la tecnologia i no tecnològics al món àgil.

Us portarem a través del viatge àgil pas a pas fins que comprengueu la filosofia que hi ha darrere d’utilitzar Agile, els seus avantatges i com practicar-lo. Aquesta sèrie pretén equipar i permetre als lectors aplicar l'aprenentatge Agile i Scrum al seu treball.

Aquest tutorial en particular està dedicat a explicar-vos per què calia Agile i com es va crear. El fonamental aquí és fer-vos entendre el concepte d’adopció àgil a les indústries de desenvolupament de programari.

Història de l’Àgil

Agile va néixer quan un bon dia, quan 17 persones amb antecedents de metodologies de desenvolupament diferents es van reunir per fer pluja d’idees si hi havia una possible solució alternativa al desenvolupament de programari que pogués conduir a un temps de desenvolupament més ràpid i amb menys documentació.

En aquella època, el desenvolupament de programari solia succeir tant de temps que quan els projectes estaven a punt per lliurar-se, el negoci havia avançat i els requisits havien canviat. Per tant, un projecte no va ser capaç de satisfer les necessitats empresarials, fins i tot si va ser capaç de complir els seus objectius definits.

Així, aquests defensors de les diferents tècniques d’enginyeria de programari es van reunir i el resultat final de la seva reunió va ser el que van anomenar el “manifest àgil” del que parlarem detalladament al proper tutorial d’aquesta sèrie.

Però l’àgil que va néixer aquell dia no és el que veiem avui a les organitzacions. La metodologia que van acordar els experts es va descriure com a 'lleugera' i ràpida. Però la principal victòria d’aquesta reunió va ser la idea que el lliurament més ràpid d’un producte i la retroalimentació constant eren les claus per assolir l’èxit en el desenvolupament de programari.

Les tècniques de cascada existents eren massa feixugues i no tenien previsió de retroalimentació fins que el producte final estigués a punt per ser lliurat. Això significava que no hi havia marge per a la correcció del curs i que el client no tenia cap visió del progrés fins que tot el producte estigués llest. I això era el que volien evitar aquests experts.

Volien una solució que tingués marge de retroalimentació constant per evitar el cost de la reelaboració en una etapa posterior.

Desafiaments àgils

Les tècniques de cascada existents en aquell moment eren massa feixugues i no tenien previsió de retroalimentació fins que el producte final estigués a punt per ser lliurat. Es va anomenar un model de desenvolupament en cascada perquè els equips van acabar un pas completament i només després van passar al següent pas.

Això significava que no hi havia marge per a la correcció del curs i que el client no tenia cap visió del progrés fins que tot el producte estigués llest. I això era el que volien evitar aquests experts. Volien una solució que tingués marge de retroalimentació constant per evitar el cost de la reelaboració en una etapa posterior.

Per això, l’àgil també consisteix en ser una millora contínua i adaptativa, tant com en la retroalimentació constant i la velocitat de lliurament.

Què són les promeses àgils?

Promeses àgils

Agile no només consisteix a aplicar les pràctiques establertes en el desenvolupament de programari. També comporta un canvi en la mentalitat de l’equip que els condueix a construir un millor programari, a treballar junts i, finalment, a convertir-los en un client feliç.

Els valors i principis àgils permeten a l’equip canviar el seu enfocament i canviar el seu procés de pensament per construir un millor programari.

Què és exactament Àgil?

Àgil no és un conjunt de regles. Àgil no és un conjunt de pautes. Àgil no és ni una metodologia. Més aviat, Agile és un conjunt de principis que afavoreixen la flexibilitat, l’adaptabilitat, la comunicació i el programari de treball sobre plans i processos. És capturat molt succintament en el que s’anomena manifest àgil.

El desenvolupament àgil de programari permet a l’equip treballar junts de manera més eficaç i eficaç en el desenvolupament de projectes complexos. Consisteix en pràctiques que exerceixen tècniques iteratives i incrementals que s’adopten fàcilment i mostren excel·lents resultats.

En aplicar Agile en acció, tenim diversos mètodes i metodologies basats en Agile. Aquests mètodes i metodologies satisfan totes les necessitats d'una indústria de desenvolupament de programari, des del disseny i l'arquitectura de programari, desenvolupament i proves fins a la gestió de projectes i lliuraments.

No només això, els mètodes i metodologies Agile també obren un marge de millora de processos com a part integral de cada lliurament.

Agile és un enfocament de desenvolupament de programari en què un equip autosuficient i multifuncional treballa en la realització de lliuraments continus mitjançant iteracions i evoluciona al llarg del procés recopilant comentaris dels usuaris finals.

Com practicar àgil?

Hi ha diverses metodologies àgils que estan a la pràctica en diverses indústries diversificades.

metodologies àgils

No obstant això, les metodologies més populars entre totes són:

  • Scrum
  • Kanban
  • Programació extrema

Totes aquestes metodologies se centren en el desenvolupament de programari lean i ajuden a construir millor programari de manera eficaç i eficient.

Tot això amb Agile Introduction. La part està estructurada per ajudar-vos a comprendre els valors i principis bàsics que s’han d’adoptar perquè un equip treballi en un mode i mentalitat àgils.

Àgil Metodologia

Introducció als models àgils:

Metodologia àgil

què és el desencadenament de ports vs el reenviament de ports

Com tots sabem, Agile és una metodologia de desenvolupament de programari.

També hem conegut els valors i principis que els fundadors d’àgils van esmentar al manifest àgil. En les nostres discussions inicials, també vam vorejar les diferències entre els models de cascades àgils i els tradicionals.

En aquest tutorial, coneixerem els avantatges i desavantatges de la metodologia àgil.

Veurem què és scrum? i en què es diferencia de l’àgil. A continuació, comprendreem les diverses metodologies àgils que estan utilitzant diferents organitzacions i com podem implementar-les amb àgil.

També podreu apreciar la diferència i els avantatges / desavantatges d’aquestes metodologies.

Avantatges de la metodologia àgil

A continuació es detallen els diversos avantatges de la metodologia àgil:

  • Els clients veuen contínuament el progrés del projecte al final de cada iteració / sprint.
  • Cada sprint proporciona al client un programari de treball que compleix les seves expectatives segons la definició del fet proporcionat per ells.
  • Els equips de desenvolupament responen bastant als requisits canviants i poden adaptar-se als canvis fins i tot en les fases avançades de desenvolupament.
  • Hi ha una comunicació bidireccional constant que manté els clients implicats, de manera que totes les parts interessades, tant empresarials com tècniques, tenen una clara visibilitat del progrés del projecte.
  • El disseny del producte és eficient i compleix els requisits empresarials.

Inconvenients de la metodologia àgil

Tot i que hi ha diversos avantatges de la metodologia Agile, també hi ha alguns desavantatges.

Ells són:

# 1) No es prefereix una documentació completa que pugui fer que els equips àgils interpretin incorrectament aquesta informació, ja que l'àgil no necessita documentació. Per tant, el rigor es perd amb la documentació. Cal evitar-ho preguntant-vos contínuament si aquesta informació és suficient per continuar o no.

# 2) De vegades, al començament dels projectes, els requisits no són clars. Els equips podrien procedir i trobar que la visió dels clients es realineava i, en aquestes situacions, els equips han d’incorporar molts canvis i és difícil avaluar també el resultat final.

Tipus de metodologies àgils

Hi ha diverses metodologies àgils a la pràctica a tot el món. Aprendrem més en detall sobre quatre de les més populars.

Tipus de metodologies àgils

# 1) Scrum

Scrum es pot considerar fàcilment el marc àgil més popular. La majoria dels practicants consideren que el terme «scrum» és sinònim de «àgil». Però això és un equívoc. Scrum és només un dels marcs mitjançant els quals podeu implementar àgilment.

La paraula scrum prové del rugbi esportiu. On els jugadors s’ajunten en una posició de bloqueig empenyent contra els oponents. Cada jugador té un paper definit en la seva posició i pot jugar tant ofensiu com defensiu segons la demanda de la situació.

De la mateixa manera, el scrum en TI creu en equips de desenvolupament autogestionats amb tres funcions específiques i clarament definides. Aquests rols inclouen: Product Owner (PO), Scrum Master (SM) i l’equip de desenvolupament format per programadors i provadors . Treballen junts en una durada iterativa de durada anomenada sprints.

El primer pas és la creació del backlog de productes per part de l’OP. És una llista de tasques que l'equip de scrum ha de fer. A continuació, l'equip de scrum selecciona els elements de màxima prioritat i intenta acabar-los dins del quadre de temps anomenat sprint.

Una manera més fàcil de recordar tot això és memoritzar el marc 3-3-5. Vol dir que un projecte scrum té 3 funcions, 3 artefactes i 5 esdeveniments.

Aquests són -

Funcions: PO, Scrum master i equip de desenvolupament.

Artefactes: Producte acumulat, Sprint backlogiIncrement de producte.

Esdeveniments: Sprint, planificació Sprint, Daily Scrum, revisió Sprint i retrospectiva Sprint.

Marc 3-3-5

Coneixerem més detalladament cadascun d’aquests en els nostres tutorials posteriors.

# 2) Kanban

Kanban és un terme japonès que significa una targeta. Aquestes targetes contenen detalls del treball que cal fer amb el programari. La finalitat és la visualització. Tots els membres de l’equip són conscients de la feina a realitzar mitjançant aquests ajuts visuals.

Els equips utilitzen aquestes targetes Kanban per a un lliurament continu. Igual que Scrum, Kanban també serveix per ajudar els equips a treballar eficaçment i promou equips autogestionats i col·laboratius.

Però també hi ha diferències entre aquests dos: com durant un sprint de scrum, els elements que treballa un equip són fixos i no podem afegir-hi elements, mentre que, a Kanban, podem afegir-hi articles si hi ha capacitat disponible. Això és particularment útil quan els requisits canvien sovint.

De la mateixa manera, una altra diferència és que, tot i que el scrum té rols definits de PO, scrum master i equips de desenvolupament, no hi ha rols predefinits a Kanban.

Una altra diferència és que, tot i que el scrum suggereix una priorització de les acumulacions de productes, Kanban no té aquest requisit i és totalment opcional. Per tant, Kanban requereix menys organització i evita activitats sense valor afegit i és adequat per als processos que requereixen capacitat de resposta davant els canvis.

# 3) Lean

Lean és una filosofia centrada en la reducció de residus. Com ho fa?

A lean, dividiu un procés en activitats amb valor afegit, activitats sense valor afegit i activitats essencials sense valor afegit. Qualsevol activitat que es pugui classificar com una activitat sense valor afegit suposa un malbaratament i hauríem d’intentar eliminar aquest malbaratament en el procés per fer-lo més prim.

Un procés més reduït significa un lliurament més ràpid i menys esforç perdut en tasques que no ajuden a assolir els objectius de l’equip. Això ajuda a optimitzar cada pas del cicle de desenvolupament de programari. Per això, els principis lean es van adaptar des de la fabricació lean al desenvolupament de programari.

El desenvolupament de programari Lean es pot utilitzar en qualsevol projecte de TI aplicant els set principis lean que es mostren a continuació:

set principis prims

Aquests s’expliquen per si mateixos, tal com suggereixen els seus noms. L’eliminació del malbaratament és el primer i més important principi prim i hem vist com fer-ho, només classifiquem les activitats com a valor afegit i sense valor afegit.

Una activitat sense valor afegit pot ser qualsevol part del codi que el pugui fer menys robust, augmentar l’esforç que suposa i ocupar molt de temps sense afegir valor empresarial justificat. També poden ser històries d'usuaris vagues o proves incorrectes o afegir funcions que no són necessàries a la imatge general.

El segon principi que amplifica l’aprenentatge torna a ser fàcil d’entendre, ja que l’equip necessita diverses habilitats per oferir productes en un entorn que canvia ràpidament i que les noves tecnologies apareixen en una durada ràpida.

Prendre decisions tardanes pot ser gratificant en circumstàncies en què es redueix la reelaboració, com si hi hagués algun canvi esperat, millor endarrerir-lo perquè l'equip no hagi de refer la feina ja que canvien les necessitats de l'empresa.

Però sempre hi ha una compensació, ja que els equips han d’equilibrar-ho amb el quart principi d’entregar més ràpidament. El retard de les decisions no ha d’afectar el lliurament global ni ha de reduir el ritme de treball. Un sol ull ha d’estar sempre en la imatge completa.

Disposar d’equips apoderats també és molt comú en l’actualitat i això fins i tot és suggerible. Els equips capacitats són més responsables i poden prendre decisions més ràpidament. El sentit de propietat en un equip capacitat condueix a millors resultats. Per empoderar un equip, se’ls ha de permetre organitzar-se i prendre decisions pel seu compte.

Per tant, veiem que els àgils i els àgils tenen molt en comú amb una forta diferència; mentre que els equips lleugers poden ajudar a refinar un producte, els equips àgils són els que realment fabriquen el producte.

# 4) Programació extrema (XP)

La programació extrema és una altra de les tècniques àgils més populars. Segons extremeprogramming.org, el primer projecte XP es va iniciar el 6 de març de 1996. També esmenten que XP afecta el desenvolupament de projectes de programari de 5 maneres diferents: comunicació, senzillesa, retroalimentació, respecte i coratge. S’anomenen valors d’XP.

D’aquests, tot comença amb la comunicació. Els equips XP col·laboren regularment amb equips empresarials i altres programadors i comencen a crear codi des del primer dia. El focus aquí es centra en la comunicació cara a cara, en la mesura del possible, amb l'ajut de la resta d'ajuts visuals.

Els programadors extrems també construeixen un codi senzill i comencen a rebre comentaris sobre ell des del primer dia. L’objectiu és no excedir-se ni predir requisits que no s’han compartit. Això fa que el disseny sigui senzill i produeixi el producte mínim que compleixi els requisits.

Els comentaris ajuden l’equip a millorar i produir una millor qualitat de treball. Això els ajuda a generar respecte els uns als altres mentre aprenen els uns dels altres i aprenen a compartir les seves opinions.

Això també els dóna coratge, ja que saben que han reunit les millors idees de tothom i han produït un bon producte amb comentaris d’altres. Per tant, tampoc no tenen por d'incloure canvis o rebre més comentaris sobre el seu treball.

Això és particularment útil en projectes on els requisits canviaran sovint. La retroalimentació constant ajudarà els equips a incloure aquests canvis amb coratge.

Així, hem vist les diferents metodologies àgils com Scrum, XP, Kanban i Lean juntament amb els seus respectius avantatges i desavantatges.

Ara, podem diferenciar-los fàcilment i apreciar les diferències més subtils entre ells. També vam aprendre els fonaments de cadascuna d’aquestes metodologies i vam veure com aplicar-les en els nostres projectes quan i quan fos necessari.

A la següent part, entenem-ho tot sobre Scrum.

Metodologia Scrum

SCRUM és un procés en metodologia àgil que és una combinació del model iteratiu i el model incremental.

Un dels principals handicaps del tradicional Model de cascada va ser que - fins que no es completa la primera fase, l'aplicació no passa a l'altra fase. I, per casualitat, si hi ha alguns canvis en la fase posterior del cicle, es fa molt difícil aplicar aquests canvis, ja que implicaria revisar les fases anteriors i refer-los.

Prova de scrum àgil

Algunes de les característiques clau de SCRUM inclouen:

  • Equip autoorganitzat i centrat.
  • No hi ha requisits immensos, sinó que tenen una història molt precisa i precisa.
  • Els equips multifuncionals treballen junts com una sola unitat.
  • Comunicació estreta amb el representant de l'usuari per entendre les funcions.
  • Té una cronologia definida de màxim un mes.
  • En lloc de fer tota la 'cosa' alhora, Scrum fa una mica de tot en un interval determinat.
  • Es té en compte la capacitat i la disponibilitat dels recursos abans de fer res.

Per entendre bé aquesta metodologia, és important entendre les terminologies clau de SCRUM.

Llegiu també => Com oferir funcions de programari d’alt valor en un període curt de temps mitjançant el procés Agrum Scrum

Terminologies importants de SCRUM

1) Equip Scrum

L’equip scrum és un equip format per 7 membres amb + o - dos membres. Aquests membres són una barreja de competències i inclouen desenvolupadors, provadors, persones de bases de dades, persones de suport, etc. juntament amb el propietari del producte i un mestre de scrum.

Tots aquests membres treballen junts en estreta col·laboració per a un interval recursiu i definit, per desenvolupar i implementar aquestes funcions. L’arranjament per seure en equip de SCRUM juga un paper molt important en la seva interacció, mai no seuen a cabines o cabines, sinó a una taula enorme.

Equip Scrum

2) Sprint

Sprint és un interval o període de temps predefinit en què s’ha de completar el treball i preparar-lo per a la revisió o per al desplegament de producció. Aquest quadre horari sol estar entre dues setmanes i un mes.

identificació intel·ligent en qtp amb exemple

En el nostre dia a dia, quan diem que seguim un cicle de Sprint d’un mes, significa simplement que treballem durant un mes en les tasques i que estem preparats per a la seva revisió a finals d’aquest mes.

3) Propietari del producte

El propietari del producte és l’interessat clau o l’usuari principal de l’aplicació a desenvolupar. El propietari del producte és la persona que representa el costat del client. Té l'autoritat final i sempre ha d'estar disponible per a l'equip.

Ha de ser accessible quan algú tingui dubtes que necessitin aclariments. És important que el propietari del producte entengui i no assigni cap requisit nou a la meitat del sprint o quan el sprint ja hagi començat.

4) Scrum Master

Scrum Master és el facilitador de l’equip scrum. S'assegura que l'equip de scrum sigui productiu i progressiu. En cas d’algun impediment, el mestre de scrum fa un seguiment i els resol per a l’equip. SCRUM Master és el mediador entre l’OP i l’equip.

Manté informat el PO sobre el progrés del Sprint. Si hi ha algun obstacle o preocupació per a l’equip, debat amb l’OP i els resol. Igual que el Daily Standup de l’equip, cada dia es fa una stand-up del SCRUM Master amb el PO.

Lectura recomanada => Com ser un bon mentor d'equip, entrenador i un veritable defensor d'equips en un món de proves àgils?

5) Analista de negocis (BA)

Un analista de negocis té un paper molt important a SCRUM. Aquesta persona és responsable de finalitzar i redactar el requisit als documents de requisits (en funció dels quals es creen les històries dels usuaris).

Si hi ha alguna ambigüitat en els criteris d’acceptació de les històries d’usuari, ell / ella és qui és abordat per l’equip tècnic (SCRUM) i, a continuació, el porta a la PO o, si és possible, es resol sol. En els projectes a gran escala, pot haver-hi més de 1 BA, però en els projectes a petita escala, el mestre SCRUM també pot actuar com a BA.

Sempre és una bona pràctica tenir un BA quan comença el tret de sortida del projecte.

6) Història de l'usuari

Les històries dels usuaris no són més que els requisits o la funció que cal implementar.

Al scrum, no tenim aquests documents de requisits enormes, sinó que els requisits es defineixen en un sol paràgraf, que solen tenir el format com:

Com un
vull
Aconseguir

Per exemple :

Com a administrador, vull tenir un bloqueig de contrasenya en cas que l'usuari introdueixi una contrasenya incorrecta durant tres vegades consecutives per restringir l'accés no autoritzat.

Hi ha algunes característiques de les històries dels usuaris que s’han d’adherir. Les històries dels usuaris han de ser breus, realistes, estimables, completes, negociables i comprovables. Una història d'usuari mai no s'altera ni es modifica a la meitat del Sprint.

És responsabilitat del mestre SCRUM i del BA (si s’escau) assegurar-se que l’OP ha redactat correctament les històries dels usuaris amb un conjunt adequat dels criteris d’acceptació ”. Si s’ha de fer algun canvi que afecti la versió del sprint, aquestes històries s’extreuen del sprint o es fan segons les hores disponibles.

Cada història d’usuari té un criteri d’acceptació que l’equip ha de definir i entendre bé.

Els criteris d’acceptació detallen la història de l’usuari que proporciona els documents justificatius. Ajuda a perfeccionar encara més la història de l'usuari. Qualsevol membre de l’equip pot anotar els criteris d’acceptació. L’equip de proves basa els seus casos / condicions de prova en aquests criteris d’acceptació.

7) Epopeies

Les epopeies són històries d'usuaris equívocs o podem dir que són històries d'usuaris que no estan definides i es conserven per a futurs sprints.

Simplement intenteu relacionar-ho amb la vida, imagineu-vos que aneu de vacances. Com que anireu la setmana vinent, teniu tot al vostre lloc, com ara reserves d’hotels, visites turístiques, xecs de viatgers, etc. Però, i el vostre pla de vacances per a l’any vinent? Només teniu una vaga idea que podeu anar al lloc XYZ, però no teniu cap pla detallat.

Una èpica és igual que el pla de vacances de l’any vinent, on només sabeu que és possible que vulgueu anar, però on, quan, amb qui, tots aquests detalls no teniu ni idea en aquest moment.

De manera similar, hi ha funcions que cal implementar en el futur, les dades de les quals encara no es coneixen. Majoritàriament, una característica comença amb una Epic i després es divideix en històries que es podrien implementar.

8) Retard de producte

El registre de producte és una mena de dipòsit o font on es guarden totes les històries dels usuaris. El propietari del producte ho manté. El registre de productes es pot imaginar com una llista de desitjos del propietari del producte que el prioritza segons les necessitats empresarials.

Durant la reunió de planificació (vegeu la secció següent), s’extreu una història de l’usuari de la cartera de productes, l’equip fa la pluja d’idees, l’entén i la perfecciona i decideix col·lectivament quines històries de l’usuari adoptar, amb la intervenció del propietari del producte.

9) Sprint Backlog

Basant-se en la prioritat, les històries dels usuaris s’extreuen del Product Backlog de forma simultània. L’equip Scrum fa una pluja d’idees per determinar la viabilitat i decideix les històries per treballar en un esprint concret. La llista col·lectiva de totes les històries d’usuaris que l’equip de scrum treballa en un sprint concret es coneix com a Sprint backlog.

Sprint Backlog

10) Punts de la història

Els punts de la història són una indicació quantitativa de la complexitat d'una història de l'usuari. Segons el punt de la història, es determina l’estimació i els esforços per a una història.

Una història és relativa i no absoluta. Per assegurar-nos que la nostra estimació i els nostres esforços siguin correctes, és important comprovar que les històries dels usuaris no siguin grans. Com més precisa i petita sigui la història de l'usuari, més precisa serà l'estimació.

Cada història de l'usuari s'assigna a un punt de la història basat en la sèrie de Fibonacci (1, 2, 3, 5, 8, 13 i 21). Com més gran és el nombre, el complex és la història.

Per ser precisos

  • Si doneu 1/2/3 punt de la història, vol dir que la història és petita i de baixa complexitat.
  • Si doneu punts com a 5/8, és un complex mitjà i
  • 13 i 21 són molt complexes.

Aquí la complexitat consisteix tant en un desenvolupament com en un esforç de proves.

Per decidir un punt de la història, la pluja d’idees passa a l’equip de scrum i l’equip decideix col·lectivament un punt de la història.

Pot succeir que l’equip de desenvolupament doni un punt de la història de 3 a una història en particular, perquè per a ells poden ser 3 línies de canvi de codi, però l’equip de proves dóna 8 punts de la història perquè consideren que aquest canvi de codi afectarà mòduls més grans de manera que l'esforç de prova seria més gran. Qualsevol que sigui el punt de la història que estigueu donant, ho heu de justificar.

Així, en aquesta situació, es produeix una pluja d’idees i l’equip col·lectivament accepta un punt de la història.

Sempre que decidiu un punt sobre la història, tingueu en compte els següents factors:

  • La dependència de la història amb una altra aplicació / mòdul.
  • El conjunt d’habilitats del recurs.
  • La complexitat de la història.
  • Aprenentatge històric.
  • Criteris d'acceptació de la història de l'usuari.

Si no coneixeu una història en concret, no la midau.

Sempre que una història té = o> 8 punts, es divideix en 2 o més històries.

11) Cremar el gràfic

El gràfic Burn Burn és un gràfic que mostra l'esforç real estimat en v / s de les tasques de scrum.

És un mecanisme de seguiment mitjançant el qual per a un esprint concret es realitzen un seguiment de les tasques del dia a dia per comprovar si les històries avancen cap a la finalització dels punts de la història compromesa o no.

Exemple : Per entendre-ho, consulteu la figura següent:

Taula Burn Burn 1

He assumit:

  • 2 setmanes de sprint (10 dies)
  • 2 recursos reals treballant al sprint.

'Història' -> Aquesta columna mostra les històries dels usuaris preses per al sprint.

'Tasca' -> Aquesta columna mostra la llista de la tasca associada a la història de l'usuari.

'Esforç' -> Aquesta columna mostra l'esforç. Ara, aquesta mesura és l'esforç total per completar la tasca. No representa l'esforç realitzat per cap individu concret.

'Dia 1 - Dia 10' -> Aquesta columna mostra les hores que falten per completar la història. Tingueu en compte que l’hora NO és l’hora que ja s’ha fet, PERUT les hores que encara queden.

'Esforç estimat' -> És el total de l'esforç. Per al 'Inici' és simplement la suma de tota la tasca individual: SUM (C5: C15)

El nombre total d’esforços que s’hauran de realitzar en un dia és de 70/10 = 7. Per tant, al final del primer dia, l’esforç s’ha de reduir a 70 - 7 = 63. De manera similar, es calcula per a tots els dies fins al dia 10, quan l'esforç estimat hauria de ser 0 (fila 16)

'Esforç real esquerre' -> Com el seu nom indica, és l'esforç realment deixat per completar la història. També pot passar que els esforços reals augmentin o disminueixin respecte a l'estimat.

Podeu fer servir les funcions incorporades i el gràfic a Excel per crear aquest gràfic de recuperació.

Els passos del quadre de gravació serien:

  1. Introduïu totes les històries (columna A5 - A15).
  2. Introduïu totes les tasques (columna B5 - B15).
  3. Introduïu els dies (dia 1 - dia 10).
  4. Introduïu els esforços inicials (Sumeu les tasques C5 - C15).
  5. Apliqueu la fórmula per calcular els 'esforços estimats' de cada dia (del dia 1 al dia 10). Introduïu la fórmula a D15 (C16- $ C $ 16/10) i arrossegueu-la durant tots els dies.
  6. Introduïu els esforços reals per a cada dia. Introduïu la fórmula a D17 (SUM (D5: D15)) per resumir els esforços reals que queden i arrossegueu-la durant la resta de dies.
  7. Seleccioneu-lo i creeu el gràfic de la següent manera:

Taula Burn Burn 2

12) Velocitat

El nombre total de punts de la història que un equip de scrum arxiva en un sprint es diu Velocity. L’equip Scrum és jutjat o referenciat per la seva velocitat. Dit això, s’ha de tenir en compte que l’objectiu aquí no és assolir el màxim de punts de la història, sinó tenir un lliurament de qualitat, respectant el nivell de comoditat de l’equip de scrum.

Per exemple : Per a un sprint concret: el nombre total d'històries d'usuaris és de 8 amb punts d'història, tal com es mostra a continuació.

Velocitat Scrum

Per tant, aquí la velocitat serà la suma dels punts de la història = 30

Definició de Fet:

Un Sprint es marca com a Fet quan es completen totes les històries, totes les tasques de desenvolupament, investigació i control de qualitat estan marcades com a 'Completades', tots els errors estan tancats o corregits, sinó els que es poden fer més endavant (com ara que no estiguin completament relacionats o siguin menys importants) s’extreuen i s’afegeixen a l’endarreriment, es completa la revisió del codi i les proves d’unitats, les hores estimades han complert les hores reals de les tasques i, sobretot, s’ha donat una demostració amb èxit a l’OP i als grups d'interès.

Activitats realitzades en metodologia SCRUM

# 1) Reunió de planificació

Una reunió de planificació és el punt de partida de Sprint. És la reunió on es reuneix tot l’equip de scrum, el mestre SCRUM selecciona una història d’usuari en funció de la prioritat del backlog del producte i l’equip de pluja d’idees.

Basat en la discussió, l’equip de scrum decideix la complexitat de la història i la dimensiona segons la sèrie de Fibonacci. L'equip identifica les tasques juntament amb els esforços (en hores) que es realitzarien per completar la implementació de la història de l'usuari.

Moltes vegades, la reunió de planificació va precedida d’una “reunió prèvia a la planificació”. És com els deures que fa l'equip de scrum abans de seure a la reunió formal de planificació. L’equip intenta anotar les dependències o altres factors que els agradaria discutir a la reunió de planificació.

# 2) Execució de tasques Sprint

Com el seu nom indica, es tracta del treball realitzat per l'equip de scrum per complir la seva tasca i portar la història de l'usuari a l'estat 'Fet'.

# 3) Standup diari

Durant el cicle d’esprint, cada dia l’equip de scrum es reuneix durant no més de 15 minuts (pot ser una trucada stand-up, recomanable tenir-lo durant el començament del dia) i consta 3 punts:

  1. Què va fer ahir el membre de l’equip?
  2. Què pensava fer el membre de l'equip avui?
  3. Algun impediment (bloquejos)?

És el mestre Scrum qui facilita aquesta reunió. Per si algun membre de l’equip s’enfronta a qualsevol tipus de dificultat, el mestre de scrum en fa un seguiment per resoldre-ho. A Stand up, també es revisa el tauler i mostra per si mateix el progrés de l'equip.

# 4) Reunió de revisió

Al final de cada cicle de velocitat, l'equip de SCRUM es reuneix de nou i demostra les històries d'usuari implementades al propietari del producte. El propietari del producte pot verificar les històries segons els seus criteris d'acceptació. Torna a ser responsabilitat del mestre Scrum presidir aquesta reunió.

També a l'eina SCRUM, el Sprint es tanca i es marquen les tasques com a fetes.

# 5) Reunió retrospectiva

La reunió retrospectiva té lloc després de la reunió de revisió.

L'equip SCRUM reuneix, debat i documenta els punts següents:

  • Què va funcionar bé durant el Sprint (Bones pràctiques)?
  • Què no va anar bé al Sprint?
  • Lliçons apreses
  • Elements d'acció.

L’equip de Scrum hauria de seguir seguint les millors pràctiques, ignorant les “no millors pràctiques” i implementar les lliçons apreses durant els sprints consegüents. La reunió retrospectiva ajuda a implementar la millora contínua del procés SCRUM.

Com es fa el procés? Un exemple!

Després d’haver llegit sobre les jerges tècniques de SCRUM. deixeu-me provar de demostrar tot el procés amb un exemple.

Exemple:

Pas 1 : Comptem amb un equip SCRUM de nou persones format per 1 propietari de producte, 1 Scrum master, 2 provadors, 4 desenvolupadors i 1 DBA.

Pas 2 : Es decideix que el Sprint segueixi un cicle de 4 setmanes. Així doncs, tenim un Sprint d’un mes a partir del 5 al 4 de junythde juliol.

Pas 3 : El propietari del producte té la llista prioritzada d’històries d’usuaris al registre de productes.

Pas 4: L’equip decideix reunir-se el 4thJuny per a la reunió “Preplanificació”.

  • El propietari del producte agafa una història de la cartera de productes, la descriu i la deixa a l’equip per fer-hi una pluja d’idees.
  • Tot l’equip discuteix i es comunica directament amb el propietari del producte per entendre clarament la història de l’usuari.
  • De manera similar, es prenen diverses altres històries dels usuaris. Si és possible, l’equip també pot continuar i dimensionar les històries.

Després de tota la discussió, els membres de l'equip individual tornen a les seves estacions de treball i

  • Identifiqueu les seves tasques individuals per a cada història.
  • Calculeu el nombre exacte d’hores en què treballaran. Comprovem com conclou el membre aquestes hores.

Nombre total d'hores de treball = 9
Menys 1 hora per un descans, menys 1 hora per a reunions, menys 1 hora per a correus electrònics, discussions, resolució de problemes, etc.
Per tant, les hores de treball reals = 6.
Nombre total de dies laborables durant el Sprint = 21 dies.
Nombre total d’hores disponibles = 21 * 6 = 126.
El membre està de permís durant 2 dies = 12 hores (pot variar per a cada membre, alguns es poden acomiadar i d'altres no).
Nombre d'hores reals = 126 - 12 = 114 hores.

Això significa que el membre estarà disponible durant 114 hores durant aquest sprint. Així, desglossarà la seva tasca de velocitat individual de manera que s’arribi a un total de 114 hores.

Pas 5 : Al 5thde juny es reuneix tot l’equip Scrum per a la “reunió de planificació”.

  • El veredicte final de la història de l'usuari a partir del registre de producte s'ha acabat i la història es trasllada al Sprint Backlog.
  • Per a cada història, cada membre de l'equip declara les seves tasques identificades, si és necessari, pot discutir sobre aquestes tasques, pot dimensionar-la o redimensionar-la (recordeu la sèrie de Fibonacci !!).
  • El mestre Scrum o l’equip introdueixen les seves tasques individuals juntament amb les hores per a cada història en una eina.
  • Després de completar totes les històries, Scrum master assenyala la Velocity inicial i inicia formalment el Sprint.

Pas 6 : Un cop iniciat el Sprint, en funció de les tasques assignades, cada membre de l'equip comença a treballar en aquestes tasques.

Pas 7 : L'equip es reuneix diàriament durant 15 minuts i discuteix tres coses:

  • Què van fer ahir?
  • Què pensen fer avui?
  • Algun impediment (bloquejos)?

Pas 8 : El mestre de scrum fa un seguiment del progrés diàriament amb l'ajut de 'Burn down chart'.

Pas 9 : En cas d'algun impediment, el mestre Scrum fa un seguiment per resoldre'ls.

Pas 10 : El 4thAl juliol, l’equip es torna a reunir per a la reunió de revisió. Un membre demostra la història de l'usuari implementada al propietari del producte.

Pas 11 : El 5thAl juliol, l’equip es torna a reunir per a la retrospectiva, on debaten

  • Què va sortir bé?
  • Què no va anar bé?
  • Elements d'acció.

Pas 12 : El 6thAl juliol, l’equip es torna a reunir per a la reunió prèvia a la planificació del proper sprint i el cicle continua.

procés de metodologia àgil scrum

Eines d'activitat SCRUM

Hi ha diverses eines que es poden utilitzar àmpliament per al seguiment de les activitats de scrum.

Alguns d’ells inclouen:

En el proper tutorial, donaríem llum al Manifest Agile, que és una noció que impulsa els equips Agile eficaços.

Pròxim tutorial

Quant als autors: Aquesta sèrie està escrita pels següents membres de l'equip de STH: Shruti Shrivastava: un professional Scrum Master amb 9 anys d'experiència en dominis BFSI, comerç electrònic i B2B. Shruti és un expert en proves d'automatització i en equips líder de scrum.

Anshul Kumar Srivastava: professional de la gestió de productes orientat als resultats i professional agil amb 7 anys d’experiència en els sectors BFSI i Telecom.

Lectura recomanada

^