Tècniques d’estimació àgil: una estimació real en un projecte àgil

agile estimation techniques

Estimacions vertaderes en un projecte àgil: una visió completa amb exemples sobre l'estimació àgil

És molt crucial fer una estimació àgil a diferents nivells. Això es fa per planificar, gestionar i estimar els esforços totals que farem servir per implementar, provar i lliurar el producte desitjat als clients en termes de temps dins dels terminis especificats.

Amb la manca d’estimacions al Projecte Agile, és possible que no hi hagi una planificació i una gestió adequades que puguin acabar amb l’entrega del producte no desitjat i, per tant, el client estigui insatisfet.

Les estimacions del punt de la història es fan en projectes Agile mitjançant diferents tècniques com Planning Poker, Bucket System, Affinity Mapping, etc. S'utilitzen diferents plantilles d'estimació a diferents nivells com ara Plantilla de pla de projecte Agile, Plantilla de pla de llançament, Plantilla de pla Sprint, Plantilla de mapa de ruta , Plantilla de User Story, etc.

Què aprendreu:

• Introducció
• Estimacions de punts d’història en àgil
• Eina recomanada
• Diferents tècniques d’estimació àgil
  • # 1) Planificació del pòquer
  • # 2) Mides de la samarreta
  • # 3) Votació puntual
  • # 4) El sistema Bucket
  • # 5) Gran / Incert / Petit
  • # 6) Cartografia d'afinitat
  • # 7) Mètode de comanda
• Càlcul del pressupost de forma àgil
• Plantilles d'estimació en el projecte de desenvolupament àgil
  • 1) Plantilla de pla de projecte Agile:
  • 2) Plantilla de pla de llançament àgil:
  • 3) Plantilla de registre de producte àgil:
  • 4) Plantilla de backlog Agile Sprint:
  • 5) Plantilla de pla de prova àgil:
  • 6) Plantilla de història d’usuari àgil:
  • 7) Plantilla de full de ruta àgil:
• Etapes d'estimació en el projecte Agile
  • # 1) Estimació del nivell de proposta o projecte
  • # 2) Estimació del nivell de llançament
  • # 3) Estimació del nivell d’esprint
• Conclusió
• Lectura recomanada

Introducció

A continuació es detallen els 3 nivells principals d’estimació àgil.

# 1) Nivell de projecte o proposta és el que utilitza l'anàlisi de punts de funció ràpida durant les fases inicials del desenvolupament del projecte.

# 2) Nivell de llançament inclou l'assignació dels punts de la història a les històries de l'usuari que poden ajudar a definir l'ordre de les històries de l'usuari en funció de la prioritat i també poden ajudar a decidir quines històries es poden agafar a la versió actual i quines es poden prendre més endavant.

# 3) Nivell Sprint és aquell en què les històries dels usuaris es divideixen en les tasques i les hores estimades s’assignen a les tasques segons la seva complexitat. Aquí també definim la persona responsable de la tasca juntament amb l’estat de les tasques.

Aquesta informació es pot utilitzar posteriorment per calcular el pressupost del projecte Agile. El càlcul del pressupost és crucial per assegurar-se que el projecte no superi el pressupost a causa de les tasques anteriors i posteriors a la iteració o per altres motius.

Estimacions de punts d’història en àgil

Les estimacions de Story Points són una anàlisi comparativa per estimar aproximadament els articles de la cartera de productes amb una mida relativa. Els membres de l’equip per estimar les històries dels usuaris inclouen: Product Owner, Scrum Master, Developers, Testers i Stake holders.

A continuació es detallen alguns passos per arribar a la decisió final de la mida relativa:

# 1) Analitzeu totes les històries dels usuaris i identifiqueu la història base o de referència. És important per fer mides relatives. Aquesta història es pot escollir entre la cartera de productes actual o la que hem fet anteriorment. Aquesta història s’ha d’escollir com a història de referència prèvia acord de tots els membres.

# 2) Trieu una altra història de la cartera de productes actual i els membres de l’equip poden discutir qualsevol dubte o dubte amb el propietari del producte, tot entenent els requisits de la història. El propietari del producte és l’encarregat d’aclarir totes les seves preguntes i dubtes.

# 3) Feu una llista de les coses a tenir en compte en implementar la història de l'usuari. Es poden fer escrivint notes a la secció de notes de l'eina o afegint punts a la targeta de la història. Això és realitzat principalment per Scrum Master.

# 4) A continuació s'indiquen algunes preguntes habituals entre els participants:

• Disseny: Quins són els coneixements previs i obligatoris que hauríem de tenir abans de començar a treballar-hi?
• Codificació: Quant es necessita la codificació per implementar aquesta història d'usuari. Ens hem trobat amb alguna història d'usuari similar anteriorment?
• Proves unitàries: Cal fer falsos objectes per fer proves d'unitats per a aquesta història d'usuari?
• Proves d'integració: Aquesta història afecta les altres funcionalitats del mateix mòdul i d'altres mòduls?
• Proves d'acceptació: Quins són els punts a tenir en compte per lliurar el producte desitjat tal com desitgen els clients?
• Expertesa: Alguns dels participants han fet alguna història similar abans i n’és expert?

# 5) Feu una mida relativa de la història seleccionada. Si requereix la mateixa quantitat de treball i esforç, assigneu-li el mateix no. de punts, assignats a la història de referència. Si requereix més esforç, assigneu-li un valor més alt. Si requereix menys esforç, assigneu-li un valor inferior.

# 6) Arribeu a un consens amb tots els participants per finalitzar la mida relativa de la història de l'usuari seleccionada segons la definició de fet.

com obrir el fitxer jar amb Java

# 7) Després de realitzar un dimensionament relatiu de tots els articles de la cartera de productes, assegureu-vos que si totes les històries dels usuaris tenen el mateix núm. dels punts assignats, requereixen el mateix esforç i mida per ser coherents.

Eina recomanada

# 1) Poker Agile

Agile Poker és una aplicació coneguda per a Jira per a una planificació i estimacions ràpides i còmodes tant per als equips remots com per als ubicats conjuntament.

Començar a utilitzar Agile Poker és senzill i senzill, ja que s’inspira en tres metodologies d’estimació estàndard de la indústria: Planning Poker®, Delphi de banda ampla i Magic Estimation (també conegut com Silent Grouping, Affinity Estimation, Swimlanes Sizing o Relative Estimations).

Diferents tècniques d’estimació àgil

Hi ha moltes tècniques per fer estimacions en un projecte Agile. Els principis principals per fer estimacions inclouen Estimació relativa, discussions per obtenir més informació sobre els ítems les estimacions dels quals cal fer i garantir el compromís de tot l’equip amb les tasques que se’ls assignen.

Hi ha principalment 7 tècniques d’estimació de projectes àgils:

# 1) Planificació del pòquer

• En aquesta tècnica d'estimació, totes les persones que se suposa que fan les estimacions, seuen en un cercle rodó per a la sessió de Planning Poker.
• Cada estimador té un conjunt de cartes de pòquer de planificació de valors: 0,1,2,3,5,8,13,20,40 i 100. Aquests valors representen punts de la història o mesura en què l'estimació de l'equip.
• Al començament de la sessió, el propietari del producte o el client llegeix la història de l'usuari, descrivint totes les seves característiques i requisits.
• Un cop llegida la història, es produeixen les discussions entre els estimadors i amb el propietari / client del producte. Els estimadors poden fer preguntes o aclarir els seus dubtes amb el propietari del producte.
• Després de les discussions, es demana a tots els estimadors que seleccionin una targeta per estimar una història de l'usuari. Si tots els estimadors donen el mateix valor, es converteix en l'estimació final.
• Si els valors són diferents, els estimadors que donen valors més alts i més baixos expliquen les seves opinions i per què han escollit aquest valor, fins que s’aconsegueix un consens.
• Una bona tècnica quan és petit no. dels articles s’ha d’estimar en un equip petit.

=> Més informació detallada sobre Planificació de la tècnica d’estimació del pòquer .

# 2) Mides de la samarreta

• Igual que en el cas de les samarretes, veiem mides: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Aquí es fa un enfocament similar, que s’estima en mides de samarreta.
• Aquesta és una tècnica perfecta per fer una estimació aproximada del gran pendent d’elements.
• Útil quan cal fer una estimació ràpida i aproximada. Més endavant, aquestes mides es poden convertir en no segons el requisit.
• Una mida relativa (majoritàriament mitjana) es decideix després de la discussió mútua i l’acord dels membres de l’equip o dels estimadors. A continuació, els no s’assignen als articles segons la mida relativa que s’assigna a Mida mitjana.
• Desavantatge: El que sembla algú L pot semblar XL per a algú.
• Tots els estimadors assignen la seva pròpia mida als ítems. Després de les discussions i la resolució dels desajustaments, s’arriba a un consens per obtenir l’estimació final.

# 3) Votació puntual

• Aquest és bàsicament un mètode de classificació per decidir l'ordre del Product Backlog des de les històries amb més prioritat fins a les històries amb menys prioritat. Això es fa per seleccionar les històries més importants que hauríem de tirar endavant.
• Per començar, publiqueu totes les històries dels usuaris juntament amb la seva descripció al mur o al tauler amb adhesius grocs o de manera que els distingeixi per rebre els vots.
• A totes les parts interessades se’ls dóna de 4 a 5 punts (la majoria en forma d’adhesius, bolígrafs o retoladors també es poden utilitzar per fer punt).
• Es demana a tots els grups d'interès que votin les històries dels usuaris que prefereixen.
• El propietari del producte ordena els articles de la cartera de productes des del més preferit (un amb més punts) fins al menys preferit (un amb un mínim de punts).
• Pot ser el cas, on poques parts interessades no estiguin satisfetes amb l’ordre decidit. En aquest cas, les històries dels usuaris es divideixen en 3 grups després de les discussions: prioritat alta, prioritat baixa i prioritat mitjana. Les històries d'usuaris d'alta prioritat es publiquen al mur per rebre els vots. Això es fa fins que s’aconsegueix l’ordre final amb l’acord de totes les parts interessades.

# 4) El sistema Bucket

• És una bona tècnica quan un gran no. d’elements s’estima per un gran nombre de participants. És més ràpid i raonable que Planning Poker.
• Es creen diferents cubs amb valors: 0,1,2,3,4,5,8,13,20,30,50,100, 200. Això es pot ampliar si cal. Aquests dipòsits no són altra cosa que cartes que representen valors disposats seqüencialment sobre una taula.
• Les històries s’han de situar dins d’aquestes on l’estimador les consideri adequades. Tots els ítems a calcular s’escriuen a les targetes.
• Trieu un element a l’atzar i poseu-lo al dipòsit 8. Això només s’utilitza com a referència. Tria una altra història a l’atzar, parla de totes les seves característiques i requisits amb el grup i, consensuat, posa-la al dipòsit adequat. De la mateixa manera, es tria un tercer element i es col·loca en una galleda adequada.
• La seqüència del dipòsit també es pot canviar, en cas que el grup consideri el primer element triat, hauria de pertànyer al dipòsit 1 en lloc del dipòsit 8.
• Es segueix l'enfocament Divide and Conquer. Tots els ítems restants es divideixen entre tots els participants. Tots els participants poden col·locar l'article sense l'aprovació d'altres participants.
• Els articles s’han de col·locar correctament. No es pot col·locar cap element entre els cubs.
• Si un participant no entén l’element del producte pendent o si els altres participants han acabat de col·locar les seves històries d’usuari, les històries d’usuari es poden transferir als altres participants.
• Per fi, tots els participants realitzen la comprovació de Sanity. Si algun participant troba un dipòsit equivocat assignat a un article, pot posar-lo en coneixement d'altres participants i discutir amb ells. Això es fa fins que s’aconsegueix un consens per a tota la cartera de productes.
• El facilitador hauria de comprovar que ningú mou els articles tret que es faci una comprovació del seny.
• Això també es fa per aconseguir l'ordre de prioritat dels articles de retard de producte.

# 5) Gran / Incert / Petit

• Aquesta és una versió aproximada i és la simplificació del sistema de cubetes, on només hi ha tres mides: gran, petita i incerta.
• Es demana als participants o estimadors que situin els ítems en una de les categories. En primer lloc, les històries d’usuaris senzilles s’escullen i es col·loquen a les categories grans i petites. A continuació, es prenen els elements complexos.
• És una bona tècnica quan hi ha articles comparables al Product Backlog.

# 6) Cartografia d'afinitat

• Una bona tècnica quan l’equip és petit i no. d’elements pendents de feina és menor.
• El primer pas és la mida relativa silenciosa: En una paret, es col·loca una targeta amb el text 'Més petit' al costat més esquerre i la targeta amb el text 'Més gran' al costat més dret. El propietari del producte proporciona un subconjunt dels articles a tots els participants. Es demana a tots els participants que dimensionin cada element en relació amb les mides de les cartes de la paret, tenint en compte l’esforç necessari per implementar-los. És la decisió del participant en solitari sense cap discussió amb els altres membres de l’equip. El propietari o l’interès del producte és present per aclarir els dubtes del participant. Els elements de la cartera de productes massa ambigus per ser entesos pels membres de l’equip per a la seva estimació es col·loquen per separat. Triga 5-20 minuts.
• Edició del mur: Els membres de l’equip poden canviar la ubicació dels elements a la paret. Poden discutir els requisits de disseny i implementació amb els altres membres de l'equip. Aquesta activitat es pot tancar quan hi ha pocs canvis a la paret. Es triga entre 20 i 60 minuts .
• Col·locació d’elements en ubicacions correctes: Després de les discussions, l’equip col·loca els articles de retard de producte a les seves posicions relatives i adequades. Aquí podem fer servir la mida de les samarretes, la sèrie de Fibonacci, etc. per estimar relativament la mida dels articles.
• Repte de propietari de producte: És possible que el propietari del producte trobi alguna discrepància en les estimacions realitzades per l’equip i hagi de discutir amb l’equip més funcions o els requisits d’un article. Després de les discussions, es fan estimacions finals.
• Exporta a l'eina de gestió de backlog de projectes: Per assegurar-vos que no es perdi la informació sobre les estimacions finals, exporteu-la a una eina de gestió de retard de producte.

# 7) Mètode de comanda

• Una bona tècnica quan és gran no. d'articles i petits núm. hi ha gent.
• Ofereix mides relatives precises per als articles de retard de producte.
• Es prepara una bàscula que va de baix a alt. Tots els elements es col·loquen aleatòriament. Es demana a cada participant que mogui qualsevol element de l’escala alhora. El moviment pot ser un cap amunt, un cap avall o passar el torn a un altre membre.
• Això continua fins que tots els participants estiguin satisfets i no vulguin moure cap element a l'escala.
• Això també dóna l'ordre de prioritat dels elements de Product Backlog.

Càlcul del pressupost de forma àgil

El càlcul dels pressupostos té un paper important en els projectes Agile. Això es fa per assegurar-se quin és el pressupost real proporcionat, quin pressupost més es requereix i com dividirem el pressupost per a diferents articles de la cartera de retard de productes.

Utilitza les dades recollides dels projectes anteriors i utilitza la fórmula matemàtica per obtenir el pressupost estimat per al projecte actual.

A continuació es mostra la seqüència de passos per calcular el pressupost d’un projecte Agile:

# 1) Enumereu tots els requisits del projecte i feu el estimacions per a ells amb Planning Poker, Bucket System, sèries Fibonacci, etc. Les estimacions es fan en funció de les funcions que s’han d’implementar en una història d’usuari.

# 2) Determineu la durada de les iteracions anomenades Sprints i elements de retard de producte que se li assignen. Sol durar de 2 a 3 setmanes. Les històries dels usuaris es trien en una seqüència que comença amb la història de l'usuari de màxima prioritat, passant a una prioritat inferior i amb la història de l'usuari amb menys prioritat al final. Això ajuda a decidir quines històries de l'usuari s'han de recollir al primer Sprint i quines històries es poden reprendre més endavant.

# 3) Prepareu un gràfic reduït per donar una imatge clara de la quantitat de treball que queda per fer en comparació del temps que queda per a la implementació. Bàsicament dóna la taxa de progrés d’un equip àgil. Dóna una imatge clara de com es comporta l’equip i de com s’espera que es comporti.

El progrés de l’equip es mesura en termes de tasques realitzades, esforç restant, descàrrega ideal i tasques restants, tal com es mostra a continuació:

# 4) Afegiu costos addicionals, com ara la compra d’equips, eines, suport a la infraestructura, obtenir llicències per a les eines de programari que s’utilitzaran, eines de gestió de projectes, instal·lació d’antivirus i actualitzacions.

# 5) Afegiu pressupostos d’iteració anteriors i posteriors. Se suposa que tots els membres àgils són multifuncionals, però hi ha límits. Tot el que faci un membre de l’equip fora de la seva experiència es considera un treball de pre iteració o de post iteració. Aquestes obres anteriors i posteriors a la iteració requereixen pressupost addicional per a la seva implementació.

# 6) Vetllar pels riscos ocults. Els riscos del projecte Agile inclouen: risc de superació del pressupost del projecte, absència de membres de l'equip, els membres no tenen un coneixement clar ni complet, els membres no tenen les habilitats requerides, s'han superat els terminis, etc.

Plantilles d'estimació en el projecte de desenvolupament àgil

Hi ha moltes plantilles d’estimació que es preparen a diferents nivells del projecte de desenvolupament Agile. L'únic propòsit és indicar clarament les estimacions necessàries per implementar un requisit o element i fer un seguiment del seu progrés.

Les plantilles principals són les següents:

1) Plantilla de pla de projecte Agile:

Ofereix una visió d’alt nivell sobre quant de temps es necessita per oferir les funcions dels requisits i quin és el seu estat. També esmenta el responsable d'una tasca específica.

(Nota: Feu clic a qualsevol imatge per obtenir una vista ampliada)

2) Plantilla de pla de llançament àgil:

Ofereix detalls de la versió de les tasques corresponents als requisits, juntament amb el seu estat i Sprint en què cal executar-los.

3) Plantilla de registre de producte àgil:

Descriu el registre de productes complet definit per al projecte. Ofereix detalls de les tasques dels Sprints juntament amb l’estat, la prioritat, els punts de la història i si s’assignen a un Sprint o si hi ha alguna tasca addicional com ara defectes, etc.

4) Plantilla de backlog Agile Sprint:

Ofereix una descripció de les històries d’usuaris esmentades a la tasca pendent d’un Sprint concret. Ofereix el total de punts de la història assignats a una història de l'usuari i com es divideixen en tasques diferents. També proporciona l’estat de les tasques corresponents i quin és el treball realitzat diàriament per a les tasques corresponents.

5) Plantilla de pla de prova àgil:

Es divideix tot l’escenari de prova en subescenaris. Ofereix detalls dels subescenaris com la data d’implementació, el resultat esperat, el resultat real, l’estat, etc.

També esmenta el nom del projecte, el navegador compatible, la versió de l’aplicació sotmesa a prova, l’identificador del cas de prova per a un escenari seleccionat, escrit per, provat per, descripció, etc.

6) Plantilla de història d’usuari àgil:

Ofereix els detalls específics de l’anàlisi de la història de l’usuari, com ara quins són els rols necessaris per provar una funcionalitat específica, quin és el requisit previ (configuració de l’entorn i enllaços habilitats) i quin és el resultat esperat?

7) Plantilla de full de ruta àgil:

Dóna una orientació al projecte a l’empresa, a curt i llarg termini. Ajuda a establir expectatives a l’empresa. I la visió general d’on es dirigeix ​​el projecte.

Etapes d'estimació en el projecte Agile

En un projecte Agile, les estimacions es fan a 3 nivells, tal com s’esmenta a continuació:

• Nivell de projecte / proposta: La mida funcional total de tota l’aplicació s’estima mitjançant el mètode QFPA (Quick Function Point Analysis) quan només hi ha requisits d’alt nivell disponibles.
• Nivell de llançament: Els punts de la història s’assignen a les històries de l’usuari que ajuden a determinar el núm. de versions previstes dins d’un projecte i el núm. d’històries d’usuaris que s’han de prendre en una versió i un sprint.
• Nivell Sprint: Les hores estimades s’assignen a les tasques de les històries dels usuaris dins d’un sprint. Això es fa per garantir el compromís del desenvolupament per oferir històries dels usuaris amb un sprint.

S1, S2, S3, S4, S5, S6 són sprints.

# 1) Estimació del nivell de proposta o projecte

És una estimació de molt alt nivell per al projecte. Se centra en el nombre total de requisits de l'element Product Backlog. Els punts de funció s’utilitzen per estimar la mida del programari / projecte abans de documentar una descripció detallada dels requisits funcionals.

Els punts de funció són la forma universalment acceptada de calcular la mida del programari. Se centra en les funcionalitats dels projectes de programari. Un punt de funció és una mètrica que converteix els requisits o les històries dels usuaris en un nombre.

la millor descàrrega de música mp3 per a Android

Durant les fases inicials del projecte, es recomana adoptar el mètode QFPA (Quick Function Point Analysis).

El mètode d’anàlisi de punts de funció ràpida és un enfocament únic per estimar FP quan només hi ha requisits d’alt nivell disponibles.

Com es calcula la mida funcional total?

• Coneixeu totes les funcionalitats d’una aplicació amb l’ajut d’experts en dominis.
• Identifiqueu i enumereu totes les funcionalitats possibles d’una aplicació.
• Les funcions d’emmagatzematge de dades es classifiquen en fitxers lògics interns (dades emmagatzemades internament a l’aplicació) i fitxers d’interfície externa (dades que s’utilitzen només amb finalitats de referència).
• Les funcions de transacció es classifiquen en entrades externes (dades que provenen de fonts externes a aplicacions), sortides externes (les dades derivades van de l'aplicació a l'exterior) i consultes externes (dades recuperades d'una o més entrades externes i sortides externes).
• Calculeu la mida de FP per a cada funció calculant la seva complexitat mitjana.
• Resumeix la mida FP de totes les funcions per obtenir la mida funcional total de l’aplicació.
• Almenys dues persones amb experiència en anàlisi de FP haurien de calcular de forma independent, igualar els resultats i resoldre les diferències.

Exemple per a l'estimació a nivell de projecte:

A continuació es mostra la llista de requisits per a un projecte, com a Product Backlog:

• Un usuari hauria de poder iniciar la sessió al lloc web proporcionant el nom d’usuari i la contrasenya.
• En cas d’inici de sessió correcte, s’hauria de dirigir a un usuari a la pàgina principal amb els panells dret i esquerre definits.
• L'usuari hauria de tenir l'opció de tancar la sessió de l'aplicació.
• Un usuari vàlid té l'opció de canviar la contrasenya proporcionant les credencials actuals.

L’equip utilitza una estimació ràpida de FP per estimar la mida del projecte.

A continuació es fa l’anàlisi realitzada:

• La funció d’emmagatzematge de dades aquí emmagatzema les credencials d’usuari per iniciar la sessió i canviar la contrasenya.
• Atès que les credencials s’emmagatzemen dins del límit de l’aplicació, s’emmagatzemen en fitxers lògics interns (ILF).
• Les funcions de transacció inclouen:
  • Inici de sessió d’usuari i visualització de la pàgina principal.
  • Sortida d’usuari i visualització de la pantalla de tancament de sessió.
  • Possibilitat de canviar la contrasenya.

A continuació es mostren els passos executats per estimar la mida del projecte mitjançant l’anàlisi del punt de funció ràpida:

PAS 1: enumereu totes les funcions de dades

UFP (Unadjusted Function Point) es pren de la taula Caper Jones.

PAS 2: enumereu totes les funcions de transacció

UFP (Unadjusted Function Point) es pren de la taula Caper Jones.

PAS 3: derivar la mida estimada del projecte en Punts de funció

UFP = FP de dades + FP de transacció

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (Suposant VFP (factor d'ajust del valor = 1)

Productivitat = 16 FP / mes (estàndard normal)

Esforç = FP / Productivitat = 22/16 mesos = 1,37 persones

# 2) Estimació del nivell de llançament

Les estimacions del nivell de llançament es fan durant la planificació de llançament. És la següent activitat després de l'estimació del nivell del projecte. Els requisits prioritzats s’extreuen del Product Backlog, que té la forma d’Histories d’usuaris.

Les històries dels usuaris s’estimen en termes de punts de la història durant la planificació de la versió, que se centra a estimar la mida del programari que es lliurarà per a aquesta versió. D'aquesta manera, no es planifica cap llançament i cap nombre total de punts de la història en cada llançament.

Un punt de la història representa bàsicament l’esforç relatiu necessari per implementar una característica o la funcionalitat, en comparació amb les altres funcions. Bàsicament serveix per dimensionar els elements del Product Backlog.

L’estimació del punt de la història es fa a partir de:

• La complexitat de la funció a implementar.
• Experiència i habilitats tècniques de tots els membres.

S1, S2, S3, S4, S5 són sprints.

Passos per assignar punts d'història a una història d'usuari:

• Tots els membres de l’equip es reuneixen al voltant d’una taula que repassa les històries dels usuaris presents al Sprint Backlog.
• Es decideix el significat d'un punt de la història i l'esforç corresponent.
• Un dels membres de l’equip llegeix una història d’usuari i després demana als membres de l’equip que assignin els punts relatius de la història.
• Si hi ha una diferència significativa entre els punts de la història assignats pels membres de l'equip, donen una explicació dels punts de la història que han assignat, aconseguint així un consens al final.
• El procés es repeteix 3-4 vegades fins que no hi hagi cap diferència important entre les estimacions donades pels membres de l'equip.
• La mida de les històries ajuda a determinar quantes històries es prendran en un sprint i es publicaran.

Exemple per a l'estimació del nivell de llançament:

Això implica crear una llista prioritzada d’Històries d’usuaris anomenada Product Backlog. El propietari del producte crea un Product Backlog i proporciona valor comercial per a cadascun dels elements que s'hi indiquen.

Podem utilitzar els mètodes següents per a les estimacions de punts d'història:

• Mida numèrica: De l'1 al 10
• Talla de la samarreta: Tots els requisits classificats com a Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
• Sèrie Fibonacci: Estimació feta mitjançant la seqüència de Fibonacci (1,2,3,5,8,13,21,34, ...)

Estimació de les històries dels usuaris anteriors a través de la seqüència de Fibonacci:

# 3) Estimació del nivell d’esprint

Les estimacions del nivell Sprint es fan durant la Planificació Sprint. Es prenen articles de retard de productes de màxima prioritat i es divideixen en diferents tasques com ara detallar, dissenyar, analitzar, desenvolupar, crear casos de prova, executar casos de prova, proves d’acceptació d’usuaris, etc.

Les tasques s’estimen en termes d’hores estimades, és a dir, el temps necessari per completar aquesta tasca per a una història d’usuari corresponent. L’enfocament ascendent s’utilitza per a les estimacions de tasques, on els requisits empresarials es divideixen en activitats de baix nivell i a cada activitat se li assignen hores estimades.

El propòsit de les estimacions és saber quantes històries d'usuaris, l'equip de desenvolupament pot comprometre's amb un Sprint. El desenvolupament ha de ser còmode amb el compromís i els propietaris de productes han d’estar segurs que l’equip complirà el compromís.

S indicacions per assignar les hores estimades a les tasques:

• Els membres de l’equip recullen les històries dels usuaris i, a continuació, se’ls demana que estimin l’esforç real, en termes d’hores o dies, per a les tasques corresponents a la història de l’usuari.
• Si hi ha un desacord en aquestes estimacions entre els membres de l’equip, el debaten i arriben a un consens.
• Si alguna tasca supera les sis hores, es divideix en tasques més petites.
• Si hi ha dues o més tasques amb hores estimades inferiors a dues, es combinen per formar una nova tasca.

Exemple per a l'estimació del nivell Sprint:

Hi ha dues parts de la reunió de Sprint Planning:

• Primera part: L’objectiu és clarificar els requisits per a les històries d’usuaris, seleccionades a la cartera de productes.
• Segona part: L’objectiu és dividir els requisits en tasques i estimar les hores necessàries per completar-los. S’han d’incloure totes les tasques necessàries per fer que l’element de Product Backlog sigui entregable. Les tasques haurien de ser petites. Idealment, un esforç de tasca no hauria de ser superior a sis hores.

Conclusió

Les estimacions del projecte Agile juguen un paper important per garantir una direcció, planificació i gestió adequades. Proporcionen passos sobre com assumir el projecte en el futur.

Les tècniques per estimar els punts de la història, com ara el pòquer de planificació, el sistema Bucket, etc. fan ús de cartes o punts amb valors o números impresos i, a continuació, assignen aquests números. a les històries dels usuaris per a una estimació de mida relativa.

L’únic propòsit és establir els articles en un ordre prioritzat de prioritat màxima a prioritat mínima. Les mides relatives estimades per als articles de cartera de producte ajuden a estimar o calcular el pressupost necessari per al projecte.

Espero que hagueu obtingut una gran visió de les estimacions de projectes àgils. No dubteu a expressar-vos els vostres comentaris sobre aquest tutorial a la secció de comentaris que hi ha a continuació.

Lectura recomanada

• Com fer un procés d’estimació àgil fàcil amb Planning Poker
• Agile Vs Waterfall: Quina és la millor metodologia per al vostre projecte?
• Tècniques d’estimació de proves de programari (Guia completa d’estimació de l’esforç de prova)
• 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
• Bases per a un viatge àgil amb èxit: com triar el mètode, les eines i les tècniques adequades
• 4 passos cap al desenvolupament de la mentalitat de proves àgils per a la transició amb èxit al procés àgil