Lo que nadie te va a contar sobre Scrum
•Descargar como PPTX, PDF•
0 recomendaciones•24,848 vistas
Este documento presenta información sobre dos personas, Rodrigo Corral y Vicenç García, incluyendo sus direcciones de correo electrónico, blogs y cuentas de Twitter. Luego proporciona una breve descripción de Scrum, incluyendo roles como Scrum Master, Product Owner y el Equipo, así como eventos como la Reunión Diaria de Scrum, la Reunión de Planificación del Sprint y la Revisión e Retrospectiva del Sprint. Finalmente, menciona algunos desafíos comunes de Scrum.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
Similar a Lo que nadie te va a contar sobre Scrum
Similar a Lo que nadie te va a contar sobre Scrum (20)
Más de Vicenç García-Altés
Más de Vicenç García-Altés (15)
Lo que nadie te va a contar sobre Scrum
- 2. • Rodrigo Corral – rcorral@plainconcepts.com – http://geeks.ms/blogs/rcorral/ – @r_corral • Vicenç García – vigarcia@plainconcepts.com – geeks.ms/blogs/devnettips – @vgaltes
- 3. Scrum Scrum Master Daily Scrum Meeting Team Sprint Product Owner Sprint Review 1. 2. Sprint Planning Meeting 3. 4. Incremento de Sin cambios funcionalidad 5. (ni en duración, ni en alcance) 6. 7. 8. 9. 10. Sprint Retrospective Product Backlog
- 5. No hay Product Owners
- 7. La técnica es vital
- 8. La deuda técnica es un gran impedimento
- 9. No existe el Scrum de guerrilla
- 10. Liturgias: necesarias pero no suficientes
- 12. El ROI lo es todo
- 13. Las historias de usuario no son mágicas
- 14. ¿Preguntas?
- 15. ¡Gracias!
Notas del editor
- Cuantos utilizáis scrum?
- Ojo pq hay mucho detrás. Scrum es difícil. Lo vemos en los equiposComo esquiar. Esquiar es muy fácil cuando te lo explican. Te subes al telesilla y bajas.Como empecé yo. Errores que te puedes ahorrar con ayuda.Que dificultades nos encontramos más habitualmente.
- Sobre el papel el PO es muy fácil. Persona de negocia que define QUÉ hace. Pero no hay Pos. Scrum a veces parece muy centrado en el equipo de desarrollo.Acostumbra a ser el primer problema que nos encontramos en una implantación. La gente que lo puede hacer, no acustumbra a estar centrada en esto: ni priorización ni definición en histórias digeribles.Mucha toma de requisitos.La solución simple de pillar a los PM no suele funcionar. Hay que cambiar la cultura. Poner el foco de no hacer nada que no tenga un ROI claro.
- En las empresas rara vez hay equipos. Hay desarrolladores que hacen parte del producto y que colaboran cuando no hay más remedio.Formar un equipo lleva años. Necesitas establecer mecanismos de colaboración pero no funcionan del día a la mañana.En scrum parece trivial pero entraña muchas dificultades.Ejemplo de PANDA. La dificultad era saber qué equipos había, quien hace qué, que dejaran de trabajar por módulos y emperazan a trabajar por funcionalidades.AssholeDrivendevelopmentCoverYourAssEngineeringGet Me PromotedMethodology
- Scrum no entra en técnica. Pero pongo un hito que es que a final de producción tienes que tener algo potencialmente acabable. Esto exige pericia técnica, buen uso de técnicas de la ingeniería del SW, integración contínua, testeo unitario, automatización de deploys, etc.Te puedes quedar en un scrum de liturgia, que no entregues valor a final de sprint, que es lo que hace que scrum trascienda de verdad.
- Todo aquello que hace que el coste del cambio crezca más allá de lo razonable.Muy difícil de entregar valor a final de scrum si tienes deuda técnica.Anti-patrón montón de mierda: sobre un montón de basura solo puedes hacer más basura.Por eso scrum existen tres fases.Visibilidad: somos incapaces de entregar valor. Antes teníamos la falsa sensación de hacerlo.Inspección : Adaptación:Arquitectura orientada al curriculumCurva J
- Otro de los grandes mitos.Se habla mucho pero no existe. Tu puedes implementar muchas cosas desde dentro del equipo e incluso implementar muchas prácticas ágiles. Pero hasta que no empapa la organización, hasta que no se prioriza, se piensa en el cliente, se quita lo que es waste, no se implica a la gente de negocio tiene carencias.
- Son condición necesarias: si no tienes daily no tienes scrum (tendrás algo ágil, pero no scrum).No hacer liturgias por las liturgias. Hacer las liturgias no es significativo de hacer scrum. Hay que saber pq se hacen las liturgias: - daily: interactuar con el equipo. - review: exigir calidad, mirar donde está el nivel de calidad del cliente, FB rápidoLo importante es comprender qué objetivos tienen las liturgias.
- Todo está priorizado en función al retorno de la inversión. Lo que funciona para saber el ROI es estimar: estimar la complejidad y el valor.Cogemos la baraja de cartas que es mucho más fácil que en horas, etc. Y lo mismo para el valor. El ROI es tan simple como hallar el ratio entre estas dos estimaciones. Siempre haremos las características que mayor ROI tengan.Hay mucha diferencia entre estimar y no. Pero no son exactas.
- Es vital asumir que todo lo que hagamos tiene que tener un match claro con las expectativas del cliente.Si haces el análisis del ROI te vas a ahorrar hacer características que no aportan ROI.Cuantas cosas habéis hecho que no han llegado a producción? Cuantas horas invertidas en nada? Clip de office!! Cuanto costó? Importante no hacer clips de office en nuestro desarrollo de SW.Triángulo de hierro. Siempre vamos a ir justos de tiempo, justos de recursos. Siempre tenemos que jugar con el alcance. La mejor manera, sacar lo que no aporta valor.Office 2010 es la primera versión que tiene menos características que la versión anterior (por primera vez) -> nos ahorramos mucho trabajo
- La gente se tiene que acostumbrar a trabajar con esta herramienta:I ndependentN egotiableV aluableE stimablesS impleT estableEs donde mana todo.