Sunteți pe pagina 1din 12

 1.

Presentación Marta Padilla


 2. Scrum Master en una multinacional
europea
 3. Scrum Master: Análisis de pros y
contras
 4. Scrum Master: Trucos del oficio
 5. Scrum Master: Factores críticos
 6. Preguntas
 Background
› Ingeniera superior en informática
› Project Manager con base técnica
› Experiencia internacional
› Contractor a través de empresa propia (FastZink)
 SCRUM Master en un entorno de desarrollo de
software en GB
› Involucrada en la definición y implantación de la
metodología SCRUM
› Definición
 Miembro del steering group para definir la implantación
concreta en varios equipos de desarrollo
› Implantación
 Doble rol: SCRUM Master / Project Manager
 Coach para la posterior implantación en otros equipos
 Cultura corporativa
› Entorno multi-cultural (European
Headquarters)
› Equipos de desarrollo off-shore
› Departamento IT como proveedor de
soluciones al negocio (core business)
 Location (GB)
› Fuerte implantación de metodologías de
desarrollo Agile
 Agile Alliance
 Implantación concreta
› Equipo de desarrolladores sénior
› Presencia de equipos de test (QA)
› Dirección de proyecto dual: Project
Manager / Technical Lead
› Gran presencia de contractors / freelance
› Implantación Bottom-up
 SCRUM Pilot Team SCRUM of SCRUMs
› Buy-in a nivel de departamento
› Receptividad a alto nivel (CIO)
 Pros
› Creación de software que responde más a
las necesidades reales
 Usuarios “reciben” un producto en cada
iteración
 Más capacidad de maniobra / reacción
 Time to market
› Menos bugs
 SCRUM significa un cambio en la forma de
desarrollar / testear
 Unit test / Test Driven Development
 Pros
› Flexibilidad / Modelo empírico
 Adaptación a unas circunstancias concretas
con éxito
› Equipos más independientes
 Compromiso - El equipo “owns the schedule”
› Mejores estimaciones
 Creación de métricas de velocidad
› Más visibilidad
 Sprint burn down chart
 Contras
› Miembros del equipo “difíciles” (SCRUM
aboga por el self management)
 Mitigación: Importancia de tener un equipo
sénior o, en su defecto, buena formación y
comunicación
› La importancia puesta en la comunicación
puede ser contraproducente con equipos
remotos
 Mitigación: Imaginación / Flexibilidad
› Bugs
 Definición de “Done” : Unit testing /
Acceptance Testing, resolución durante el
mismo Sprint
 “Weekly triage” con el Product Owner
 Control del Product Backlog
 Introducción de “buckets” de resolución de
bugs para balancear bugs / features
› Capacidad y velocidad
 Capacidad al 80% cuando no se conoce la
velocidad
› User stories en entornos complejos
 Herramientas alternativas
› Reuniones
 Controlar el tiempo
 Cerdos y gallinas
› Miembros del equipo en remoto
 Video conferencias
 “Virtual” task board
 “Virtual” burn down chart
› “Release Sprints”
› Product Owner debe de estar involucrado /
disponible
 Formación apropiada
 Si es necesario, “push” por parte del SCRUM
Master (involucrar stakeholders, etc)
› Desarrollo
 Continuous integration
 Test Driven Development
 Equipo de Test adecuado
 Involucración desde Sprint kick off
› “Coaching” por parte del SCRUM Master
 Project Manager o Technical Lead
 Comunicación
 No sólo de los cambios en el proceso, sino de las
razones / mejoras que aportarán
 Reuniones
› Sesiones de retrospective
 Modelos Star fish, start/stop/continue, etc…

S-ar putea să vă placă și