scrum básico
DESCRIPTION
introducción el proceso de SCRUMTRANSCRIPT
¿qué es scrum?
“Es un marco de trabajo ágil por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente”.
Scrum es:
• Ligero• Fácil de entender• Extremadamente difícil de llegar a dominar
¿Qué es scrum?
• Scrum se basa en la teoría de control de procesos empírica o empirismo.
• Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
Roles en scrum
Cerdos Gallinas¿Quién?• Product Owner• Scrum Master• Equipo de Desarrollo
Comprometido en:• El proyecto y el proceso Scrum.• Construir software de manera
regular y frecuente.• Tiene el “tocino en el sartén”.
¿Quién?• Usuarios • Stakeholders• Expertos
Cualquiera que esté involucrado e interesado en el proyecto.
No son parte del proceso Scrum.Sus ideas, deseos y necesidades son tomadas en cuenta, pero no en un sentido en que puedan afectar o distorsionar el projecto Scrum.
El equipo de desarrolloDeberes
• El equipo debe ser auto-organizado. Los propios miembros del equipo establecerán la forma de hacer su trabajo.
• Tiene que ser multifuncional.• Todos los miembros deben trabajar con sus habilidades para cumplir el sprint goal.• Los equipos de desarrollo deben ser pequeños, de 3 -7 personas.• Junto con el Scrum Master, se encargan de establecer los ítems del Sprint Backlog, de planificar
el sprint.• Estimar las historias de usuario y tareas.• Hacer la demo.• Implementar pruebas de aceptación y pruebas unitarias.• Trabajo de calidad y mejora continua de la calidad (refactorización, por ejemplo)• Participar en los Daily meeting, Sprint Planning Meeting, Sprint Review y Sprint Retrospective.• Estar motivados.• Saber buenas prácticas de programación: pair programming, TDD, integración continua,
refactorización, malos olores, patrones de diseño, etc.• Identificar posibles obstáculos y comunicárselos al Scrum Master.• Actualizar el trabajo en progreso (burndown chart) (es responsabilidad tanto del equipo de
desarrollo como del Scrum Master)
El equipo de desarrollo
Derechos
• La organización tiene que animar al equipo a auto-organizarse, sin entrometerse en su forma de trabajar.
• A que sólo bajo contadas y controladas circunstancias, las tareas del sprint sean modificadas una vez que este ha comenzado.
Scrum developer
• Actitud mosquetero
• Todo el equipo es responsable de la construcción del producto
• Habilidades “T”
Product backlog
• Lista priorizada y secuencial de características o “historias de usuario”.
• Basada en la visión de producto del PO.
• Responsabilidad del PO.
• Siempre el trabajo más valioso va primero, y va más detallado.
Sprint backlog
• Lista prevista de desarrollo o ejecución para un (1) Sprint.
• Items primeros en el PB, con estimación acorde al Sprint.
• Desagregado de los items del PB en tareas específicas y asignadas en el DT.
• Items susceptibles de ser afrontados con KANBAN.
Producto potencialmente entregable• Una parte o sección de
producto construida o “hecha”.
• Parte o sección dispuesta a ser liberada.
• La liberación es una decisión de negocio, no es imperativo.
Sprint planning
• Reunión de revisión de PB para llegar a acuerdos (PO, SM, DT).• Selección de común acuerdo de X cantidad de items del PB al
SB.• Estimación de items (generalmente horas)• Item > Tareas > Llenar la capacidad
Daily scrum
• Revisión de inspección y adaptación. - SM, DT, PO (pasivo)• “Daily stand-up”• Generalmente:
- ¿Qué logré desde el último Daily?- ¿Cuál es mi plan para el siguiente Daily?- ¿Qué obstáculos enfrento?
• Gallinas y cerdos
Tres maneras de fracasar en un proyecto ágil1 – El contrato, el cliente y el modelo de negocio.
• Decía el manifiesto ágil que aquello de que la agilidad requería de “Colaboración con el cliente sobre negociación contractual”. Pero claro, si tu cliente es de los que te entrega al principio del proyecto un documento enorme lleno de requisitos, clausulas y posibles penalizaciones y no vuelves a verlo hasta el último día de proyecto… olvídate de la agilidad, en serio, no va a funcionar.
• La agilidad pretende obtener software que cumpla lo que los usuarios necesitan no que cumpla lo que pone en un documento de requisitos.
2 – La calidad software.• Antes de ser ágil, hazte las siguientes preguntas…• ¿Tenemos un robusto control de versiones? ¿programamos con
calidad? ¿hacemos código espagueti? ¿copy paste? ¿complejidad ciclomática disparada? ¿pruebas unitarias? ¿diseño mantenible? ¿refactorizas? etc., etc., etc. Supongo que saber por dónde voy, no es cuestión de seguir con la lista.
• Los anteriores son tan necesarios en un proyecto ágil, como en cualquier proyecto software, pero en uno ágil, por lo cortas que son las iteraciones… tiene el doble de impacto…si no las tienes a la perfección… dudo que la agilidad te dure más de 5 iteraciones.
• Como decía Fowler, “If you’re afraid to change something it is clearly poorly designed”.
3 – La documentación
• Volviendo al manifiesto ágil… “Software funcionando sobre negociación extensiva”. Lo que no es lo mismo que “Software funcionando Y NO documentación comprensiva”.
• Que en agilidad la documentación es menor, cierto. Que ocupa otro rol, cierto. Que se crea de otra manera, también. Pero no que no hay documentación.
• Recuerda aquello de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad.