Ir al contenido principal

Entradas

Mostrando entradas de junio, 2015

Proyectos con Scrum grandes y distribuidos

Scrum funciona de mejor manera cuando es aplicado por un equipo en una sola localidad, pero en la realidad es muy común que un solo equipo no pueda completar un gran proyecto o que los recursos estén repartidos en diferentes localidades y como consecuencia de ello los equipos deben ser aumentados o bien distribuidos. Las razones por ejemplo pueden ser técnicas, que no existan expertos en algún tema, relacionadas con el tamaño del proyecto, que este sea muy grande, o relacionadas con el negocio, aprovechando diferentes zonas horarias para mantener la productividad. La comunicación es parte importante del marco Scrum, y en especial se debe tener un especial cuidado con esta cuando se trata del reto de trabajar con proyectos en ambientes distribuidos y todos los miembros deberían tener acceso a las apropiadas herramientas de comunicación  como videoconferencia o web cams. Para romper las mas comunes barreras de comunicación. Es importante asegurarse que el numero de equipos Scrum no

Sprint Retrospective Meeting

Después del Sprint Review Meeting el Scrum Team y el Scrum Master se reúnen para hacer una retrospección del Sprint en esta se reflexiona sobre el pasado Sprint y se verifican tres cosas . 1. Que se hizo bien durante el Sprint 2. Que no se hizo bien. 3. Que puede mejorar El tiempo es limitado por ejemplo tres horas. La Sprint retrospective es parte del proceso de inspección y adaptación del proceso , sin esta reunión el equipo no será capaz de mejorar sus procesos y enfocarse en la mejora continua, al final de la reunión se tendrán sugerencias prácticas para mejorar.

Sprint Review Meeting

Al final de cada Sprint se tiene una Sprint Review Meeting, durante esta se exponen los elementos de la Scrum Product Backlog fueron completados a corde a la definición de listo durante  el Sprint y puede realizarse un demo de la funcionalidad. Se debe agregar que los items de la Scrum Product Backlog no se consideran completos si no se han demostrado, si existen inconvenientes en la demostración los ítems deben ser abordados en la siguiente iteración. Esta reunión puede mantenerse informal no se precisan diapositivas power point y el tiempo de preparación para la misma es limitado, durante esta reunión el product owner inspecciona las entradas del backlog y las acepta o agrega nuevas historias de usuario para adaptar la funcionalidad. Los participantes típicamente son el Scrum Owner, Scrum Master, el Scrum Team y adicionalmente stakeholders, gerentes, desarrolladores de otros proyectos.

Daily Scrum Meeting

Es una corta reunión diaria, idealmente realizada al inicio del día de trabajo. Cada miembro que trabaja hacia el completar el actual sprint debe participar. Durante esta reunión se da respuesta a las siguientes preguntas: 1. ¿Que se ha completado desde la reunión anterior? 2. ¿Que se completara hasta la siguiente reunión? 3. ¿Que impedimentos existen para concluir las tareas? Todos los miembros del equipo deberían estar y soportar la reunión. La reunión no debería durar mas de quince minutos. Los problemas y preocupaciones surgidos durante la reunión deben ser apuntados y atendidos por el Scrum master luego de la reunión.

Sprint burndown report / chart

El reporte Sprint burndown muestra el progreso del sprint hacia el logro de la meta. Provee transparencia sobre el rendimiento actual (tasa de avance). Permite una fácil estimación si el Sprint se logrará en tiempo  o si se deben encontrar medidas adicionales, para acelerar el completar las actividades remanentes. El Sprint Backlog inicial define el punto de inicio de los esfuerzos. El esfuerzo remanente  de todas las actividades son recolectadas a diario y añadidos a la gráfica. Al inicio el rendimiento no es tan bueno como  se predijo debido a estimaciones incorrectas o impedimentos que deben ser removidos antes de lograr el máximo de velocidad.

Definición de Listo (DoD)

La definición de listo es utilizada, para decidir cuando una entrada en la Product Backlog esta completa, la definición de listo no es mas que un listado comprensible de actividades que aseguran que solamente las características realmente completada sean lanzadas, no solo en términos de funcionalidad sino también en términos de calidad. La definición de listo puede variar de un equipo Scrum a otro pero en un solo equipo debe ser consiste en un mismo equipo. Existen distintos niveles para la DoD 1.  Para un ítem en la Scrum Product Backlog 2.  Para un Sprint 3.  Para un lanzamiento

SCRUM BURNDOWN CHART

Es una herramienta visual de medida que muestra el trabajo completado por día, en contra de la estimación proyectada para completar el siguiente lanzamiento.  Su propósito es comprobar que el proyecto va en camino de entregar la solución esperada en las actividades programadas. La medida de progreso en Scrum es llamada Velocidad. y es expresada por ejemplo en puntos de esfuerzo completados por iteración. Un punto importante al calcular la velocidad es que solo se deben incluir historias de usuario completadas. Historias parcialmente completadas parcialmente no se incluyen. Después de unas pocas iteraciones la velocidad del equipo es predecible y se pueden realizar estimaciones mas precisas para completar una entrada en la product backlog. En la realidad los ítems en la Product Backlog son cambiantes, algunos son actualizados otros son añadidos y otros eliminados en la Burdown Down Chart normal esto no se refleja pero para ello existe otro diagrama que puede ser utilizado V

Que es un Sprint?

En SCRUM, todas las actividades necesarias para la implementación de alguna entrada en product backlog son realizadas mediante Sprints o también llamadas iteraciones. Los Sprint duran de 2-4 semanas. Los Sprint en general siguen el siguiente proceso. Los Sprint, inician con dos sesiones, la sesión del Que? y la sesión del  Como?  la combinación de ambas sesiones se conoce como la Sprint Planning Meeting, en la sesión del Que? el equipo elige las entradas del Product Backlog que se implementaran durante el Sprint. En la sesion del Como? el equipo parte las historias de usuario en pequeñas y especificas tareas, entonces se puede iniciar con el Sprint. Al finaliza el Sprint se realiza la Sprint Review Meeting, la cual es una reunión conducida hecha por el Product Owner, en esta reunión se define si los items de la product backlog fueron implementados completamente y de forma correcta. Adicionalmente el Scrum Master hace y conduce la Sprint Retrospective Meeting en la cual se revis

Estimación de esfuerzo

Todas las entradas en el Scrum Product Backlog deben estar estimadas para permitir al Product Owner priorizarlas y crear el plan de lanzamiento.  Esto significa que el Product Owner necesita una valoración honesta de cuan dificil puede resultar el trabajo. Es recomendado que el Product Owner no asista a la estimación de esfuerzo para quitar presión en el Scrum Team. La metodología SCRUM no defina una especifica forma de medir el trabajo pero usualmente se realiza en forma de esfuerzo, este esfuerzo suele representarse en distintas formas como elementos del 1 al 10, tallas de playeras S, M, L, XL, XXL. o la serie de fibonacci. Es importante que todos los miembros del equipo tengan un entendimiento generalizado de las métricas y que todos se sientan cómodos con el. Scrum Planning Poker El método mas utilizado para la estimación de esfuerzo es el planning poker con este la influencia entre participantes es minimizada y se mejora la precision de la estimación. para realizar el plan

SCRUM User stories

Los ítems en el scrum product backlog usualmente se escriben en forma de historias de usuario. Una historia de usuario es una pequeña historia de como un usuario utiliza el producto. Contiene un nombre una narrativa, criterio de aceptación y condiciones para que la historia este completa. La ventaja de utilizar historias de usuario es que se centra en lo que exactamente el usuario necesita o quiere sin entrar en detalle de su implementación. Existen diferentes recomendaciones acerca de como definirlas. Una plantilla puede ser la siguiente Como quiero para   Actor: el dueño de la historia de usuario; usualmente se coloca usuario pero se recomienda ser mas especifico. por ejemplo, administrador de sistema, supervisor, etc. Con esto se logra entender mejor la historia en su contexto. Descripción Narrativa: lo que el actor quiere hacer Meta: lo que el actor desea lograr realizando la accion