Próxima reunión del Agile User Group
23 views
Skip to first unread message
agilenature
May 16, 2011, 1:42:17 PM5/16/11
to cragile
Jueves 19 de Mayo. 7:30 am. Auditorio Universidad Latina, Campus San
Pedro.
Estimación Ágil con "Story Points".
Por David Alfaro
"Ágil" es un evoque para el desarrollo y entrega de software que:
Anima un alto nivel de involucramiento del cliente a lo largo del
proceso de desarrollo de software y tolera, y hasta promueve, cambios
a los requirimientos durante ese proceso.
Entrega software vía una serie de iteraciones cortas (de una a
tres semanas) cuyo resultado se centra en entregar software que esté
funcionando.
Es ejecutado por equipos de desarrollo altamente auto-organizados.
El enfoque Ágil es ampliamente utilizado por todo el mundo en forma de
efectivas metodologías y métodos de desarrollo de software Ágil y
entrega.
La forma en que un proyecto Ágil es ejecutado puede diferir
significativamente de un desarrollo de software tradicional o de una
entrega tradicional de proyecto. En muchos casos, por lo tanto, las
técnicas tradicionales de estimación para proyectos de software no son
las más apropiadas o las más efectivas para pronosticar y manejar el
cronograma y presupuesto de un proyecto Ágil.
Esta presentación introduce un forma de estimación para Proyectos
Ágiles usando "Story Points" en contraposición a horas o días
"hombre". Temas a cubrir:
Introducción: Estimado un Proyecto Ágil
La escala de Story Points
Calibrando la escala usando proyectos pasados
Asignando Story Points a User Stories
Estimando el cronograma y presupuesto del proyecto al inicio
Asignando User Stories a Iteraciones
Comparando Story Points con Function Points
Pedro.
Estimación Ágil con "Story Points".
Por David Alfaro
"Ágil" es un evoque para el desarrollo y entrega de software que:
Anima un alto nivel de involucramiento del cliente a lo largo del
proceso de desarrollo de software y tolera, y hasta promueve, cambios
a los requirimientos durante ese proceso.
Entrega software vía una serie de iteraciones cortas (de una a
tres semanas) cuyo resultado se centra en entregar software que esté
funcionando.
Es ejecutado por equipos de desarrollo altamente auto-organizados.
El enfoque Ágil es ampliamente utilizado por todo el mundo en forma de
efectivas metodologías y métodos de desarrollo de software Ágil y
entrega.
La forma en que un proyecto Ágil es ejecutado puede diferir
significativamente de un desarrollo de software tradicional o de una
entrega tradicional de proyecto. En muchos casos, por lo tanto, las
técnicas tradicionales de estimación para proyectos de software no son
las más apropiadas o las más efectivas para pronosticar y manejar el
cronograma y presupuesto de un proyecto Ágil.
Esta presentación introduce un forma de estimación para Proyectos
Ágiles usando "Story Points" en contraposición a horas o días
"hombre". Temas a cubrir:
Introducción: Estimado un Proyecto Ágil
La escala de Story Points
Calibrando la escala usando proyectos pasados
Asignando Story Points a User Stories
Estimando el cronograma y presupuesto del proyecto al inicio
Asignando User Stories a Iteraciones
Comparando Story Points con Function Points
Erick Salas Araya
May 17, 2011, 12:08:49 PM5/17/11
to cra...@googlegroups.com
Solo se llega y listo?
--
You received this message because you are subscribed to the Google Groups "cragile" group.
To post to this group, send email to cra...@googlegroups.com.
To unsubscribe from this group, send email to cragile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cragile?hl=en.
David Alfaro
May 17, 2011, 3:12:00 PM5/17/11
to cra...@googlegroups.com, cra...@googlegroups.com
Sí señor!!
Sent from my iPhone
Sent from my iPhone
Mauricio Arroyo
May 17, 2011, 9:13:08 PM5/17/11
to cra...@googlegroups.com
David Alfaro
May 17, 2011, 9:34:57 PM5/17/11
to cra...@googlegroups.com
Rene Zuleta Arango
May 18, 2011, 12:27:35 AM5/18/11
to cra...@googlegroups.com
Hola David
Hay planes de repetir esta charla a otra hora? Que tal una videoconferencia? Yo tengo a un pool de unas 6 personas interesadas
saludos,
-r
--
René Zuleta A.
Hay planes de repetir esta charla a otra hora? Que tal una videoconferencia? Yo tengo a un pool de unas 6 personas interesadas
saludos,
-r
2011/5/16 agilenature <alfaro...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "cragile" group.
To post to this group, send email to cra...@googlegroups.com.
To unsubscribe from this group, send email to cragile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cragile?hl=en.
--
René Zuleta A.
David Alfaro
May 18, 2011, 1:01:43 AM5/18/11
to cra...@googlegroups.com
Hola René!!
Se me ocurre dos opciones:
Ahora bien, espero que al proveer estas opciones, no desanime la asistencia el jueves para los varios que ya me confirmaron asistencia.
La riqueza de interacción durante el evento es muy valiosa, y realmente queremos darle fuerza a CRAgile.
Nos vemos!!!
David Alfaro
Scrum Consultan, Coach and Trainer
Se me ocurre dos opciones:
- Grabarla y hacerla disponible
- Repetirla en el Prontitud AgileFest 2011 [fecha y amigables precios :-) pronto a anunciarse]
Ahora bien, espero que al proveer estas opciones, no desanime la asistencia el jueves para los varios que ya me confirmaron asistencia.
La riqueza de interacción durante el evento es muy valiosa, y realmente queremos darle fuerza a CRAgile.
Nos vemos!!!
David Alfaro
Scrum Consultan, Coach and Trainer
2011/5/17 Rene Zuleta Arango <in...@renezuleta.com>
Rene Zuleta Arango
May 18, 2011, 1:07:24 AM5/18/11
to cra...@googlegroups.com
Gracias David
Quedo a la espera de noticias.
Saludos,
- r
--
René Zuleta A.
Quedo a la espera de noticias.
Saludos,
- r
2011/5/17 David Alfaro <alfaro...@gmail.com>
--
René Zuleta A.
David Alfaro
May 18, 2011, 1:09:14 AM5/18/11
to cra...@googlegroups.com
Con gusto!
David Alfaro
Scrum Consultant, Coach and Trainer
David Alfaro
Scrum Consultant, Coach and Trainer
Gabriela Salazar
May 23, 2011, 11:02:46 AM5/23/11
to cra...@googlegroups.com
Hola David:
Viera que yo tenía mucho interés en asistir a la charla pero se me hizo imposible. Por favor si la grabó me la podría enviar. Quisiera aplicar esas técnicas de estimación en mi curso de Ingeniería de Software.
Le agradezco mucho todo el apoyo que siempre me ha brindado!
Gabriela
Viera que yo tenía mucho interés en asistir a la charla pero se me hizo imposible. Por favor si la grabó me la podría enviar. Quisiera aplicar esas técnicas de estimación en mi curso de Ingeniería de Software.
Le agradezco mucho todo el apoyo que siempre me ha brindado!
Gabriela
David Alfaro
May 23, 2011, 11:34:56 AM5/23/11
to cra...@googlegroups.com
Hola Gabriela!
Precisamente ayer publiqué el un artículo detallado con el contenido de la charla que espero le sirva: http://prontitud.com/2011/05/22/estimacion-agil-story-points/
Saludos muy cordiales,
David Alfaro
Scrum Coach and Trainer
Precisamente ayer publiqué el un artículo detallado con el contenido de la charla que espero le sirva: http://prontitud.com/2011/05/22/estimacion-agil-story-points/
Saludos muy cordiales,
David Alfaro
Scrum Coach and Trainer
2011/5/23 Gabriela Salazar <gabriel...@gmail.com>
Erick Salas Araya
May 24, 2011, 10:41:24 AM5/24/11
to cra...@googlegroups.com
Que bueno.. yo estaba por preguntar lo mismo.
Gracias
Gracias
Erick Salas Araya
May 26, 2011, 5:39:27 PM5/26/11
to cra...@googlegroups.com
He estado pensando en realizar una reunión para tratar el tema de los Story Points y tratar de estandarizar un poco los pesos de los futuros sprint’s, en tareas que son recurrentes en cada sprint.
Se que para cada sprint existen tareas como documentación técnica, de código, de usuario, pruebas de regresión, de desarrollo y de QA, entre otro montón de cosas son muy repetitivas y que también son muy relativas según la UserStory y su complejidad.
Existe la posibilidad de tratar de estandarizar un poco el peso de esas tareas?
y que tan conveniente puede ser?
David Alfaro
May 26, 2011, 7:38:58 PM5/26/11
to cra...@googlegroups.com
Erick,
Primero, es de felicitar que el criterio de "done" se esté revisando constante. Eso forma de la cultura de "continuous improvement" y "quality assurance" del equipo Scrum.
Esto también forma parte de la naturaleza autoorganizativa del equipo.
De esa reunión pueden salir dos posibles cosas a tratar.
Pero antes de seguir, recuerda que cualquier decisión que se tome debe estar bajo la cultura de "continuous improvement". Lo que significa que aunque la decisión tomada se ejecute con rigor, no está escrita en priedra, por lo que el equipo acepta que es libre para ser revisada y cuestionada.
Motivación:
El motivo de esta reunión es que el criterio de done no se está aplicando consistentemente en las tareas, ya sea por olvido o negligencia. La discusión sobre estandarización debe girar alrededor de refinar el criterio de done, y sobre cuánta estandarizacion es adecuada.
Decisión 1: El equipo opina que el workflow de "To Do" -> "In Progress" -> "Done" no ayuda a forzar trabajo común a todas las tareas. Por ello decide decide agregar una columna extra antes de "Done" llamada "Development Complete", que engloba a todos los chequeos y tareas comunes que deben hacerse antes de pasarse a done. El ejemplo del equipo Vodafone Web Team en Dinamarca es genial al respecto http://ultimatewallboard.com/entries#89095
Precauciones: Tratar de no crecer el workflow a más de cuatro estados, es muy raro que todas tareas/user stories requieran tantos estados, en mi experiencia, complicar el worflow resulta en desuso. Aunque tenga más estados, recordar que la única medida válida de progreso sigue siendo la cantidad de tareas/User Stories que estén en Done.
Decisión 2: El equipo opina que un estado más en el workflow no es necesario, que simplemente se necesitan recordar agregar las tareas comunes durante el Sprint Planning. Al respecto recomiendo este artículo que escribí varios años atras sobre esto: http://agilenature.com/2008/01/03/the-task-board-shows-what-and-how-we-are-doing-during-a-sprint/ que básicamente anima a usar postits de diferente color para diferente tipo de tarea: un color para code review, otro para testing, otro para documentacion...
En cualquiera de las dos decisiones, sugiero hacer muy visible qué son esas tareas comunes. Un poster pegado a la par del TaskBoard explicando qué significa "Development Complete", o qué significa cada color.
Durante la reunión donde discuten este tema, el ScrumMaster debe probar ser un buen facilitador. Te recomiendo el libro "Collaboration Explained" de Jean Tabaka http://amzn.to/lWAvsK que tiene técnicas específicas de facilitación de discusiones y tambien la técnica de Integrative Decision Making de Holacracy One http://bit.ly/m8iDEE
Primero, es de felicitar que el criterio de "done" se esté revisando constante. Eso forma de la cultura de "continuous improvement" y "quality assurance" del equipo Scrum.
Esto también forma parte de la naturaleza autoorganizativa del equipo.
De esa reunión pueden salir dos posibles cosas a tratar.
Pero antes de seguir, recuerda que cualquier decisión que se tome debe estar bajo la cultura de "continuous improvement". Lo que significa que aunque la decisión tomada se ejecute con rigor, no está escrita en priedra, por lo que el equipo acepta que es libre para ser revisada y cuestionada.
Motivación:
El motivo de esta reunión es que el criterio de done no se está aplicando consistentemente en las tareas, ya sea por olvido o negligencia. La discusión sobre estandarización debe girar alrededor de refinar el criterio de done, y sobre cuánta estandarizacion es adecuada.
Decisión 1: El equipo opina que el workflow de "To Do" -> "In Progress" -> "Done" no ayuda a forzar trabajo común a todas las tareas. Por ello decide decide agregar una columna extra antes de "Done" llamada "Development Complete", que engloba a todos los chequeos y tareas comunes que deben hacerse antes de pasarse a done. El ejemplo del equipo Vodafone Web Team en Dinamarca es genial al respecto http://ultimatewallboard.com/entries#89095
Precauciones: Tratar de no crecer el workflow a más de cuatro estados, es muy raro que todas tareas/user stories requieran tantos estados, en mi experiencia, complicar el worflow resulta en desuso. Aunque tenga más estados, recordar que la única medida válida de progreso sigue siendo la cantidad de tareas/User Stories que estén en Done.
Decisión 2: El equipo opina que un estado más en el workflow no es necesario, que simplemente se necesitan recordar agregar las tareas comunes durante el Sprint Planning. Al respecto recomiendo este artículo que escribí varios años atras sobre esto: http://agilenature.com/2008/01/03/the-task-board-shows-what-and-how-we-are-doing-during-a-sprint/ que básicamente anima a usar postits de diferente color para diferente tipo de tarea: un color para code review, otro para testing, otro para documentacion...
En cualquiera de las dos decisiones, sugiero hacer muy visible qué son esas tareas comunes. Un poster pegado a la par del TaskBoard explicando qué significa "Development Complete", o qué significa cada color.
Durante la reunión donde discuten este tema, el ScrumMaster debe probar ser un buen facilitador. Te recomiendo el libro "Collaboration Explained" de Jean Tabaka http://amzn.to/lWAvsK que tiene técnicas específicas de facilitación de discusiones y tambien la técnica de Integrative Decision Making de Holacracy One http://bit.ly/m8iDEE
2011/5/26 Erick Salas Araya <eksa...@gmail.com>
Reply all
Reply to author
Forward
0 new messages