Experimentos que han funcionado en mis últimos 7 años jugando con Scrum en equipos Agile.
La presentación cubre 4 pilares de Scrum:
- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Introducción básica a Scrum, la metodología de desarrollo de software ágil. Usamos esta presentación como primer paso para inducir a nuevos miembros del equipo a nuestra manera de trabajar.
Presentación de la capacitación cátedra SCRUM en la UMNG (@lamilitar). Con recomendaciones a herramientas tecnológicas de metodologías ágiles y startups.
Introducción básica a Scrum, la metodología de desarrollo de software ágil. Usamos esta presentación como primer paso para inducir a nuevos miembros del equipo a nuestra manera de trabajar.
Presentación de la capacitación cátedra SCRUM en la UMNG (@lamilitar). Con recomendaciones a herramientas tecnológicas de metodologías ágiles y startups.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Trabajo de Ingeniería del Software en el que se introduce el ciclo de vida Scrum y se exploran tres herramientas para implementarlo: Trello, Taiga y Jira
Ponencia de Scrum del evento "PMBOK vs Scrum" dada en UNMSM el 9 de noviembre del 2016, abordando historia de scrum y metodologías ágiles con un ejemplo practica de la facilidad que puede implementarse.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Trabajo de Ingeniería del Software en el que se introduce el ciclo de vida Scrum y se exploran tres herramientas para implementarlo: Trello, Taiga y Jira
Ponencia de Scrum del evento "PMBOK vs Scrum" dada en UNMSM el 9 de noviembre del 2016, abordando historia de scrum y metodologías ágiles con un ejemplo practica de la facilidad que puede implementarse.
Esta presentación incluye una introducción de Scrum en Proyectos que hemos realizado en tecnología Microsoft. Usando herramientas que nos permite llevar todo el ciclo de vida del proyecto con la metodología ágil como SCRUM. Herramientas como Visual Studio Team Services (VSTS) permiten facilitar el trabajo del equipo desde la planeación del sprint hasta la entrega del producto.
Agenda:
1. Manifiesto Ágil
2. Scrum
3. Valores Scrum
4. Roles Scrum
5. Actividades Scrum
6. Logros Scrum en iTS y proximos pasos
Webinar: Integrar la analítica en Metodologías ÁgilesIEBSchool
Alberto Ambrosio nos explica cómo integrar la analítica en metodologías ágiles en este nuevo webinar de IEBS.
Las nuevas tecnologías nos permiten analizar y obtener resultados en un periodo de tiempo reducido. Las organizaciones tienden a modelos en los que se mejora la productividad de forma rápida y a métodos de gestión que permiten una mayor flexibilidad, tales como metodologías de gestión de proyectos ágiles.
La analítica debe ser nuestro pilar fundamental para la toma de decisiones, de forma que ayude a mejorar nuestro impacto en el negocio, cliente y mercado. Es importante integrar la cultura analítica dentro de los procesos internos de la compañía y basarnos en datos cuantitativos que nos permitan dirigir nuestras decisiones directamente a ámbitos que mejoren el negocio.
Scrum es un framework que permite entregar el máximo valor, mediante iteraciones cortas y de gran colaboración. Scrum permite adaptar los equipos a las condiciones complejas de la construcción de productos y del entorno.
En este meetup revisamos lo que SCRUM consiste como marco de trabajo, sumado a nuestra experiencia en el desarrollo de proyectos de software y el por qué consideramos es tan importante hoy en día en el mercado
Guía para hacer un Plan de Negocio para tu emprendimiento.pdfpppilarparedespampin
Esta Guía te ayudará a hacer un Plan de Negocio para tu emprendimiento. Con todo lo necesario para estructurar tu proyecto: desde Marketing hasta Finanzas, lo imprescindible para presentar tu idea. Con esta guía te será muy fácil convencer a tus inversores y lograr la financiación que necesitas.
Anna Lucia Alfaro Dardón, Harvard MPA/ID. The international successful Case Study of Banco de Desarrollo Rural S.A. in Guatemala - a mixed capital bank with a multicultural and multisectoral governance structure, and one of the largest and most profitable banks in the Central American region.
INCAE Business Review, 2010.
Anna Lucía Alfaro Dardón
Dr. Ivan Alfaro
Dr. Luis Noel Alfaro Gramajo
3. Lo que viene a continuación ha funcionado con los
equipos con los que he trabajado en el pasado.
Con otros equipos puede que funcione, o no.
Lo mejor es probar.
Si funciona, se queda.
Si no, se descarta y se prueban otras cosas.
5. Product Owner
• Product Backlog
• Resolver dudas
Scrum Master
• Ayudar con Scrum
• Ayudar con
impedimentos
Development Team
• Gestionar tareas
sprint
• Realizar tareas sprint
Roles
6. • En equipos pequeños, creo que tiene sentido que el SM sea alguien del dev team,
por la carga de trabajo que conlleva una vez el equipo es maduro.
• El SM tiene menos capacidad en el sprint (10%-15%).
• En algunos equipos hemos incluido la figura del Firefighter:
• Es un rol temporal y rotatorio por sprints.
• Bugs urgentes, soporte urgente a otros dptos., etc. durante el sprint.
• Para que el resto del equipo se pueda centrar en las tareas del sprint.
• El firefighter tiene menos capacidad en el sprint (10%-15%).
• Según la teoría, la historia de usuario debería empezarse y terminarse en el
mismo sprint. Normalmente, si hay diseño e implementación, eso es complicado.
En el pasado, la estrategia que mejor ha funcionado es que diseño vaya un sprint
por delante.
Roles:: Adaptaciones
8. • En vez de lunes, he visto que funciona mejor en martes / jueves.
• Mi esquema con mejores resultados:
Fase I: Revisión de historias
candidatas
• PO + Dev team
• Revisar de historias
candidatas para el sprint
• Resolver dudas del Dev Team
• Unos 15-30 min.
Fase II: Desmenuzar y
estimar
• Dev Team
• Analizar
• Obtener dependencias
• Descomponer en tareas
• Estimar (puntos de historia)
• Unas 3h (sprint de 2
semanas)
Fase III: Cerrar sprint
• PO + Dev team
• Cerrar el sprint backlog con
HU priorizadas
• Definir el goal del Sprint
• Unos 30 min.
Reuniones:: Sprint Planning
9. • 15 minutos.
• Las típicas 3 preguntas (Ayer, Hoy, Impedimentos).
• Sólo cosas relevantes.
• No me vale “Ayer estuve en la reunión de planificación”.
• Sí me vale “Nada relevante” (Aunque no todos los días!).
• Todos prestamos atención.
• Nos pasamos un token.
• Orden aleatorio, pero no vale pasar al compañero adyacente.
• Se actualiza el gráfico del sprint burn-down/burn-up.
Reuniones:: Daily Scrum
10. • No es una reunión “oficial” de Scrum, pero creo que es muy útil.
• PO + algún Dev (como el Lead).
• Un par de días laborables antes del sprint Planning.
• PO y Dev revisan las historias candidatas para asegurarse de que no hay
“agujeros”. Si los hay, el PO tiene tiempo de revisarlo con los stakeholders.
• La idea es que el Dev Team tengan todo lo que necesitan para estimar las
tareas durante el sprint planning.
• No debería durar más de 1h.
Reuniones:: Grooming / Refinement
11. • Sólo se hace demo de historias 100% hechas (según la Definition of Done).
• Las tareas 100% técnicas que pueden sonar a chino a los stakeholders nos
las podemos ahorrar.
• La demo se prepara previamente, no se improvisa con los stakeholders
delante. Si no sale bien, se mina la credibilidad del Dev team.
• Al cierre del sprint, se envía el listado de historias para la Demo a los
stakeholers, para que sepan qué se va a revisar.
• No debería durar más de 1,5h (para sprints de 2 semanas).
Reuniones:: Demo
12. • Después de la Demo.
• Asiste todo el equipo Scrum (PO+SM+Dev Team).
• Se revisan los compromisos de la retro anterior.
• Se resumen los highlights del sprint en 2 categorías:
• Qué ha ido bien
• Qué se puede mejorar
También puede hacerse con | More of | Less of | Keep doing | Start doing | Stop doing |
Idealmente, la información se recopila durante el sprint y se lleva ya preparado.
• Se acuerdan compromisos de mejora para el siguiente sprint (con personas asignadas!).
• Debería durar unas 2h (para un sprint de 2 semanas).
Reuniones:: Retrospectiva
14. 1. Product Backlog
2. Historias de usuario
3. Nivel de cariño
4. Definition of Done (DoD)
5. Sprint Backlog
6. Sprint Dashboard
7. Evaluación de estimaciones
8. Informes
Herramientas
15. • Sólo lo actualiza el Product Owner.
• Aunque las estimaciones únicamente las proporciona el Dev Team.
• Contiene todo en lo que se va a trabajar en futuros sprints.
• Historias de usuario, bugs, tickets, etc.
• Las historias han de ser entendibles para una audiencia no técnica.
• Sólo hay 1 product backlog por producto, aunque haya varios equipos Scrum.
• Es un listado priorizado, con un nivel de detalle decreciente. Idealmente, la cima está casi
detallada al 100%.
• En Excel, Google Docs, Trello, Jira u otra herramienta, pero idealmente disponible para
stakeholders y el resto de la organización.
Herramientas:: Product Backlog
16. • Título: Título descriptivo-
• Descripción: Siguiendo el formato Como… Quiero…Para…
• El Como… es desde el punto de vista del usuario final, no del reporter.
• Due date (opcional): Para cuándo tiene que estar listo (si aplica).
• Criterios de aceptación: Aquello que se va a comprobar para decidir si está lista para subir.
• Nivel de cariño: Indica qué nivel de detalle hay que incluir dependiendo de si es algo que se va a
quedar, si es un test o un parche temporal.
• Épica: Grupo de funcionalidades a la que pertenece la historia.
• Reporter: Quién lo ha solicitado, por si hay dudas en el futuro.
• Estimación inicial: Estimación de alto nivel del Dev Team.
Herramientas:: Partes de mis historias de usuario
17. Herramientas:: Nivel de cariño
Nivel de
cariño
Calidad
de código
Explicación Ejemplo (Amazon)
Rollete de
una noche
Baja
Bajo riesgo, tráfico medio, conocimiento sin
validar, con posibilidades de que cambie
Experimento en una landing
informativa
Rollo de
verano
Media
Riesgo medio-alto, tráfico bajo, conocimiento sin
validar, con posibilidades de que cambie
Experimento en el funnel de
compra
Novieta Alta
Riesgo bajo, tráfico bajo-medio, conocimiento
validado, poco probable que cambie
Cambios en el perfil del usuario
Novia formal Muy alta
Crítico, tráfico medio-alto, alto impacto en
usuarios, validado, poco probable que cambie
Integración de una nueva
plataforma de pago
Boda Extrema
Crítico para el funcionamiento del producto,
validado y poco probable que cambie
Tramitación de compra y envío
18. • Definición global de qué significa que algo está hecho.
• Una historia no está terminada si no se satisfacen todas las
condiciones de la DoD.
• Lo definen Dev Team + PO.
Algunos aspectos a considerar:
• ¿Quién tiene que dar el OK? (QA, PO, PO + Stakeholders)
• ¿En qué entorno tiene que estar? (Development, Pre, Staging, Prod)
• ¿Con/Sin unit test?
Herramientas:: Definition of Done (DoD)
19. • Historias/ítems del Product Backlog que se harán en el sprint.
• Se cierra al final del sprint planning.
• Todas las historias están estimadas y divididas en tareas más
pequeñas (también estimadas).
• Queda reflejado en el Sprint dashboard.
• Sólo se pueden añadir tareas “haciendo hueco” (quitando otras).
• El Dev Team se compromete a terminar todo lo que deciden que
entra.
Herramientas:: Sprint Backlog
20. • Refleja el estado de todas las historias/tareas/bugs del sprint.
• Permite ver si hay algún “problema” en función de la distribución de las tareas.
• Idealmente, se trabaja con versión online y física.
• El online se actualiza al momento, en cuanto hay cambios en la tarea.
• El físico se puede actualizar durante el Daily Scrum.
• Los encargados de mantenerlo son el Dev Team.
• Se pueden usar post-it de varios colores para identificar distintos tipos de ítems
(Historias, Tareas, Bugs, Tickets, etc.)
• Se puede usar una sección para imprevistos con | Fuegos | Must | ASAP|
Herramientas:: Sprint Dashboard
21. Herramientas:: Ejemplo de Dashboard
ToDo InProgress Buffer
Peer
Review
Testing
Pre
Ready to
upload
Testing
Prod
Done Blocked
Fuego
Must
ASAP
SPRINT BOARD
FIREFIGHTER BOARD
22. • Tabla junto al dashboard con todas las tareas y sus estimaciones
iniciales.
• Cuando una tarea se pasa a Done, se añade el esfuerzo real invertido.
• Si hay diferencia con la estimación inicial, se anota el motivo.
• Sirve para identificar desviaciones en las estimaciones para aprender
de cara a futuras estimaciones.
• Puede discutirse durante la Retro.
Herramientas:: Evaluación de estimaciones
23. Para mejorar la visibilidad del avance del producto podemos usar:
• Sprint Burn-up/Burn-down: Gráfico que monitoriza el progreso del sprint
con los puntos de historia “quemados”. Se actualiza al final del Daily Scrum.
• Informe de cierre/inicio de sprint: Se envía a todos los stakeholders a final
de sprint e inicio del siguiente con detalles de cómo ha terminado el sprint
y qué se ha planificado para el siguiente.
• Informe de producto: Se envía a todos los stakeholders con detalles sobre
el progreso del producto.
Informes
25. • Título del sprint:
• Número de Sprint. Ej. Sprint 1.
• Semanas cubiertas por el sprint. Ej. Sprint 15-16.
• Otros nombres: Ej. Planetas de Star Wars, Personajes de los Simpson, etc.
• Objetivo del sprint: Acordado durante el sprint planning.
• Capacidad del sprint: Suma de la capacidad de cada Dev.
• Sprint backlog: Listado de las historias/tareas a realizar durante el sprint.
• Total planificado: Total de puntos de historia planificados .
• Capacidad del sprint: Total de puntos de historia disponibles durante el sprint.
• Buffer disponible: Puntos no planificados de la capacidad.
Informes:: Inicio de sprint
27. • Tareas planificadas y terminadas: Tareas inicialmente planificadas
para el sprint que se consideran Done (según la DoD).
• Tareas planificadas y no terminadas: Tareas inicialmente planificadas
para el sprint que no se consideran Done.
• Tareas no planificadas y terminadas: Tareas que no se incluyeron en
la planificación inicial pero que se han terminado en el sprint.
• Resumen: Resumen de la capacidad, los puntos de historia
planificados, los terminados y los no planificados.
Informes:: Cierre de sprint
29. • Resumen de épicas/funcionalidades: Resumen del estado de todas
las épicas/nuevas funcionalidades planeadas (normalmente por
trimestre).
• Evolución del equipo de Scrum: Evolución del rendimiento del equipo
Scrum en cuanto a cumplimiento de puntos de historia.
Informes:: Producto
31. Guías de Scrum
Guía oficial de Scrum
• Ken Schwaber & Jeff Sutherland. Creadores de Scrum
• Link: http://www.scrumguides.org/
The Scrum Master Training Manual
• Nader K. Rad, Frank Turley. Management Plaza
• Link: http://mplaza.pm/product/scrum-master-training-manual/
32. Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
¡Gracias!
Para dudas, comentarios, preguntas y/o feedback: