Ir al contenido principal

Entradas

Relación entre el modelo CANVAS y SCRUM

El día 24 de junio de 2015, durante el desarrollo del curso libre: Gestión de proyectos con SCRUM, surgió la duda de que relación (o como podemos relacionarlos) tiene el modelo CANVAS con SCRUM. A continuación tratare de responder luego de documentarme acerca del contenido. 1. Al inicio del curso definimos que un proyecto es finito, tiene un inicio y un fin, mientras que la administración de la empresa  es por decirlo así infinita, de modo que tendrá una interrupción solamente si se tiene que finalizar las operaciones del negocio. 2. El modelo CANVAS, es una metodología que nos proporciona una plantilla para desarrollar el modelo de negocios de la empresa o documentar el modelo de negocio de una empresa existente (se relaciona con la operación completa de la empresa) 3. SCRUM es una metodología de gestión de proyectos 4. Entonces como se relaciona CANVAS con SCRUM     ¿Puedo crear mi modelo CANVAS con SCRUM?       ...

Planificación de lanzamientos

En términos generales, se trata de una guía de Sprints necesarios para completar el proyecto y como serán lanzados es creada durante la planificación de lanzamientos y nos muestra una expectativa de de que y cuando serán completados requerimientos. También nos sirve para monitorear el progreso de avance ya que por medio de esta se puede crear la linea base. Los lanzamientos pueden ser entregables a mitad del proyecto o un entregable final. Para crear el plan de lanzamientos se deben tener disponibles: 1. Una backlog priorizada 2. La velocidad del equipo (estimada) 3. Condiciones de satisfacción Dependiendo del tipo de proyecto, si es por característica o por fecha se puede realizar el plan de dos maneras distintas. Si el proyecto es por característica se puede dividir los puntos de esfuerzo de todas las caracteristicas necesitadas entre la velocidad estimada del equipo para obtener el numero de Sprints necesarios para completar la funcionalidad. Si el proyecto es conduc...

Planeación y Coordinación de equipos multiples

Para coordinar diferentes equipos Scrum se utilizan las reuniones "Scrum de Scrum". La cual es muy similar a la Scrum Daily Meeting pero esta con un enfoque en multinivel. La reunión tiene lugar todos los días y no debe durar mas de 15 minutos por ejemplo. En esta cada equipo envía un representante el cual debe responder a las preguntas. 1. Qué ha completado el equipo desde la ultima reunión? 2. Que completara hasta la siguiente reunión? 3. Que impedimentos tiene para lograrlo? Las respuestas deberían estar enfocadas en elementos que impacten a otros equipos. El Product Owner jefe es quien modera la reunión, en general no solo debería ser el Scrum Master quien  participe en las reuniones sino alguien diferente del equipo podría ir cambiando diariamente. Sprint Review Común Podrían también realizarse pequeñas Sprint Review multiequipos en la cual se muestre a todos que se realizó durante el Sprint y cual es el status general del proyecto. Sprint Retrospective Co...

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 Scru...

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.