Descargado 10 veces
Subido por233 Grados de TI
Viaje de bomberos a developers
El documento describe la transformación de un equipo de bomberos a desarrolladores de software mediante la adopción del marco ágil Scrum, enfocándose en el cliente, el producto, el equipo y cambiando la forma de trabajar para enfocarse en lo que hay que hacer y quien lo hará en lugar de cómo, con sprints, planificación, demostraciones y reuniones de retrospectiva para adaptar Scrum al proyecto.
Viaje de bomberos a developers
- 1. Viaje de transformaciónde bomberos a developers por Raquel Pérez Bartolomé
- 2.
- 4.
- 10.
- 11.
- 12.
- 13.
- 14. CAMBIO DE RUMBO Scrum
- 15.
- 18.
- 19.
- 21. ADAPTAR EL MARCOAL PROYECTO
- 22. FOCO EN ELQUÉ Y EL QUIÉN DEJANDO DE LADO EL CÓMO FOCO EN LA DIRECCIÓN FOCO EN LAS REUNIONES
- 23. Retos que asustan ¡Factible!
- 24.
- 25.
- 28.
- 29.
- 32.
Notas del editor
- #4 TRABAJAMOS “Al día”
- #12 cumplíamos a medias expectativas de tiempo y forma Requisitos incompletos q daban lugar a funcionalidades que no cumplían los requisitos
- #13 Código que se quedaba “muerto” y nunca se volvía a usar Bugs en el código
- #14 equipo cansado de urgencias, de falta de planificación, ¿qué voy a hacer hoy? Hablar el mismo idioma que el cliente Llamadas de clientes en fin de semana
- #16 Un único punto de referencia de funcionalidads / bug /deuda técnica
- #17 Clarificar las prioridades, tan pronto algo se pedía o preguntaba no hay que integrarlo Urgencia vs importancia
- #18 Definición de user stories antes de empezar a desarrollar eran parte de un acuerdo entre todos
- #19 Fomentó el diálogo entre el equipo, po, clientes…stakeholders
- #20 Retrospectivas RETROS – grandes mejoras DEL equipo PARA el equipo y para el producto Gestión de ramas Branding Bugs recurrentes Planificación de releases
- #23 En la definición de funcionalidades En la dirección, dejamos de ser bomberos Fijar OBJETIVOS de las REUNIONES y plan de acción posterior – buscamos dar valor al producto y al proceso
- #24 Menos es más, divide y vencerás evitar “guerras” eternas de funcionalidades OBJETIVOS, por qué algo es importante ahora? Objetivos a medio plazo Definición completa de user stories q no están en el tope de pila, no es URGENTE, si no se realizan los requisitos cambian
- #25 Criterios de aceptación, incompletos dan lugar a bloqueos y a user stories interminables que al final se las coge “manía”
- #26 Tomamos las deciiones como equipo y como equipo las cumplimos
- #27 Evitar ser carreteras saturadas Dejar espacio para la creatividad y salirsel del camino
- #28 Team buildingExperimentar y analizar, no tener miedo a decisiones “equivocadas”, antes de probarlo, ¡no lo sabes!
- #30 Integrar a la comunidad en el equipo nuevas herramientas