Nicolas Molina
César Augusto Patiño González
Julian Osorio
César Augusto Patiño González
Edwar Enrique Vilchez Serrano
Emerson Cedeño
Victor Manuel Segura Garrido
Belen Ceballos
Jonathan Jose Silva Ramos
Diego Miramontes
Team Presla
Belen Ceballos
Ada Parra
Kath Sánchez
Yeraldine Martinez
Ricardo Mesa Gallego
Juan Francisco Esperanza Contreras
Belen Ceballos
Edgardo T
Manuel Alejandro Sánchez Palomino
Victor Manuel Segura Garrido
Alejandro Romero
Belen Ceballos
Nicolas Molina
Ricardo Azpeitia P.
Manuel Alejandro Sánchez Palomino
Jasan Azael Hernández Bautista
William Alfonso Vigoya Nieto
Juan Manuel Pérez Altamirano
XSales® Mobility
Jose Aguilar
Henry Cova
Omar Crespo
Javier Altmann
Diego Forero
¿No seria mejor que la Tarea “Crear Mockups” esta divida ya que es 21pt es mucho? Por ejemplo divididrla en:
“Crear Mockup de Home” => 4pt
"Crear Mockup de Catalogo" => 6pt
"Crear Mockup de Contact" => 4pt
… etc etc
Así se puede tener una puntación no tan alto y mejor control… no?
¿cómo se puede hacer la estimación de todos los sprints? si es requerido para una planeación genereal y completa de todo un proyecto.
En Scrum al inicio del proyecto se tienen Historias de usuario épicas las cuales son historias muy robustas que tienen muchas funcionalidades y que pueden ser divididas, estas están así porque determinan el proceso de lo que se va a construir, con estas historias lo que se puede hacer es una estimación a alto nivel de parte de todo el equipo, Product Owner y Stackeholders para determinar mas o menos cuanto se puede llevar en Sprints el proyecto, pero hay que tener en cuenta que bajo este marco de trabajo se trabaja con la triple restricción de costo fijo, tiempo fijo y el alcance es lo único que es variable o cambia, entonces cuando se hace la estimación a alto nivel no se tiene fijo ese alcance porque sprint tras sprint puede ir cambiando a medida que se hagan los refinamientos de historias de usuario del backlog o pila de funcionalidades; Esto es lo que lo diferencia de los proyectos tradicionales los cuales si tienen un alcance fijo.
que buen aporte, me ha quedado más claro el conpecto. muchas gracias…
Las Historias de Usuarios sustituyen a los Casos de Uso de nuestro querido UML. Porque podemos en ellas describir lo que el usuario final o funcional aspira con cada una de las funcionalidades que serán liberadas por el equipo. Es muy importante saber como redactarlas, clasificarlas, estimarlas pero sobretodo desarrollarlas
no lo había visto así, qué buen aporte! 👍
Busque varias definiciones de muckup y wireframes, y por lo que veo, van primero los wireframes y luego los mockups, ya que los muckups son mas detallados que los wireframes y mas cercanos al prototipo
Escribí un artículo sobre el tema, quizás te interese 😃 https://platzi.com/blog/wireframes-prototipos-mockups-que-son/
Algo que no me queda claro es una vez calculada la capacidad del equipo y asignar puntos a cada historia de usuario, ¿Cómo hago la relación entre las horas y los puntos? para saber la cantidad de historias que puedo meter en el sprint
En el sprint el equipo decide que historias realizará, tomando los puntos en consideración. No hay una relación directa, es un estimado y por eso al final del sprint se debe revisar cuánto se logró de lo estimado para ajustar la capacidad del equipo. Si sabes que pueden producir X (basado en lo que han hecho en otros sprints) y realizaron menos, toca averiguar que sucedió. ¿Se estimó mal el sprint? ¿Hubo algún problema? etc.
En el minuto 8:40 mencionan que la serie de fibonachi no representa una unidad de tiempo porque se basa en la relación de la capacidad del equipo y en la velocidad. De que forma? porque es incremental? No entiendo a que se refieren. Muy decepcionado de la explicación.
El profe se refiere a que la forma en que se mide la importancia de cada tarea, no se basa en el tiempo que toma cada una, sino en la complejidad e importancia para mayor cantidad de miembros del equipo. Cuánto más importancia/relevancia tiene, va incrementando, pero no necesariamente esto implica que lleve más tiempo.
Por ejemplo, la entrega de un Wireframe podría ser de importancia 1 si lo medimos por el tiempo que lleva construirlo, pero si de ese Wireframe dependen el equipo de Desarrollo y el de Diseño para iterar el proyecto y entregar mejoras una semana antes, ese Wireframe quizás tiene una importancia de 5 para el equipo, por la capacidad que tienen (cantidad de diseñadores) y lo que repercute esta tarea para el resto del equipo.
Tiene sentido? Te resulta más claro así?
Cuéntame si te quedan dudas hasta que quede claro como el agua 😃
Tengo una duda: Un punto de estimación es el valor que se le da a cada tarea para ser realizada?, estos puntos se miden en horas trabajadas?
No necesariamente son para estimar las horas trabajadas, más bien estima la prioridad y dificultad de una tarea.
La escala de valoración de las tareas, para determinar su complejidad, debe ir en algún rango específico? O eso queda a criterio de cada equipo de trabajo?
Es totalmente a criterio del team, por ejemplo he estado en equipos donde 1 punto de historia equivale a aproximadamente 1 dia de trabajo de un solo miembro del equipo trabajandole a la historia. en otros equipos 1,2,3 “Facil” 5,8 “Medio”, 13+“Complejo”. Ya es como el equipo se sienta bien punteando historias. Lo importante es que todo el equipo defina bien la escala y se sienta a gusto con ella, si no no hay problema en el siguiente sprint intentan otra escala hasta que se sientan bien.
En que momento de la planeaciòn o cada que tiempo se debe de realizar el plainningpoker si es la forma que estableciò para estimar tiempo
Lo ideal es que el momento de planeación se de un poco antes del comienzo del sprint, en mi caso en general lo hacíamos una o dos semanas antes de iniciar un proyecto.
Sin embargo, a veces, independientemente de la metodología que usemos, podemos fallar en la estimación (por ejemplo, si nos encontramos con un problema más difícil de resolver de lo estimado). En esos casos, sirve volver a recalcular la estimación inicial una vez que hayamos entendido el problema y podamos estimar la tarea de manera más realista.
Servidor B: Video con partes repetidas, muchas veces. Confunde un poco.
lo más probable es que sea tu conexión a internet
a mi tambien me pasa, se repiten partes y no creo que sea mi internet, solo me pasa con los videos de este curso
Tengo un detalle con este video en la tablet, no lo puedo ver, por lo tanto no lo puedo descargar para ver Offline. Alguien puede hacer algo?, gracias, saludos
Hola Jesus, pudiste solucionar este tema?
Los puntos son horas? osea 4pt => 4 horas?
Los puntos son puntos, no necesariamente se trasladan a horas si no mas a la complejidad de la tarea.
no necesariamente, los puntos son unidades de medida que pueden significar X cantidad de horas
Estimaciones
Vamos a definir cual va hacer la razón de tiempo y esfuerzo que vamos a dedicar en cada una de las historias para poder entregar a tiempo en cada estimación.
¿Que estamos estimando?
Vamos a estimar esa cantidad necesaria de esfuerzo y solo lo necesario para poder entregar siempre a tiempo en cada iteración así nosotros vamos a evitar delete o retrasos de una o dos semanas que nosotros llamamos carry Overs pero un carry over siempre va a representar como un afecto al presupuesto, al costo y por supuesto a nuestro negocio.
Vamos a estimar las historias de usuario y los defectos considerando que las historias de usuario es la unidad básica de funcionalidad, es decir solamente aquellas tareas mas simples que se van a realizar, nosotros vamos a estimar en base a puntuación que es una relación que se convierte a tiempo en base a la capacidad del equipo y la velocidad del equipo. La capacidad del equipo son esas horas disponibles que tiene el Team para trabajar en una tarea muy especifica. Y La velocidad del equipo es el numero de historias, defectos o issues que se hicieron en la iteración pasada, quiere decir que si mi equipo trabajo en 5 historias de usuario y las completaron correctamente la velocidad del equipo es de 5 historias de usuario por Sprint.
Capacidad ideal, capacidad real y capacidad esperada.
la capacidad ideal es esa sumatoria de todas la horas que tienen todos los miembros de equipo suponiendo que tenemos 5 miembros de de equipo y se trabaja un Sprint de 2 semanas lo cual son 10 días hábiles, cada semana tiene 40 horas entonces serian 80 horas.
Vamos a multiplicar el numero de miembros del equipo por esas 80 horas para tener un total de 400 horas ideales en las que se espera que vamos a trabajar.
Pero no vamos a trabajar las 400 horas por los 5 miembros del equipo pues siempre hay un delete hora de trabajo o alguien que llega tarde y momentos en el día que nosotros estamos ocupados en otras cosas. Entonces se crea una capacidad real que un lugar de tomarse 8 horas al día se toman 5 lo cual nos da 50 horas por las dos semanas , multiplicadas por los 5 miembros del equipo nos da 250h que es una capacidad un poquito mas real y a fin a lo que nosotros podemos trabajar y podemos entregar, pero aquí hay una tercer métrica que siempre es importante incluir ya que siempre hay una capacidad esperada que tal vez tenemos una capacidad de 250 horas real, pero podemos hacer el esfuerzo de trabajar un poco mas para a completar las 300 horas que no es lo mismo que la capacidad ideal pero se acerca un poco mas al trabajo y podemos cubrir mas historias de usuario y mas defectos.
¿Pero como vamos a estimar esta puntuación?
Hay muchas formas de hacerlo hay formas de presentar las historias de usuario a un rol expertos técnicos los cuales nos van a dar una puntuación un poquito mas real a lo que en verdad se va atrabajar, pero nosotros como equipo tenemos la obligación y el derecho a elegir la forma en la que estamos estimando nuestras tareas. Una forma muy divertida y un poco mas amigable de hacer es un Póker planning, es tener un juego de cartas de poker con números de secuencia fibonacci. La secuencia fibonacci es muy utilizada en estimación de agile porque tenemos en cuenta de que los valores nunca van a ser iguales y siempre son incrementales, esto quiere decir que la capacidad va ir aumentando según el número y según el número también de los miembros del equipo.
Esta es una técnica muy fácil de usar y podemos conseguir las tarjetas en Internet o podemos invertir un poco en esto para que el juego de estimaciones sea un poco mas divertido y que todos tengamos las discusiones propias de porque se estima de esa manera, de una forma mas comunicativa y sin temor a llegar a conflictos especiales.
es complejo definir una estimación de tiempos si no se tiene claro el core de lo que se pretende hacer o solucionar.
No reproduce el video
Alguien mas presento problemas para ver este modulo? (el 14)
El bug no sería algo que sucede inesperadamente o también se debe planear como se hizo en el vídeo, desde el principio los posibles errores.
¿En las estimaciones de las tareas se toma encuenta el esfuerzo del QA cuando este es externo a la celula o interno ?
Los puntos son eso, puntuaciones con las cuales medir las historias de usuario, en mi caso las usare en base a dificultad, transcendencia y un poco cuantas horas tomara realizarla.
No entendí como funciona el sistema de puntajes:
¿Entre el grupo de trabajo se decide cuántos son la cantidad de puntos máximos que entran en un sprint? Y esto se lo toma teniendo en cuenta la capacidad del equipo?
Si, ya que tu equipo es el que mejor conoce su trabajo y puede decir cuanto tiempo le toma desarrollar una tarea especifica.
