Scrumyprincipiosgiles
Descargar como PPTX, PDF0 recomendaciones180 vistas
Este documento describe los principios y características de Scrum, un marco de trabajo ágil para el desarrollo de software. Scrum se basa en iteraciones cortas llamadas "sprints" de 2 a 4 semanas de duración, en las que equipos auto-organizados trabajan para crear incrementos de valor. Los roles clave son el Product Owner, que representa la visión del cliente; el Scrum Master, que ayuda al equipo a seguir Scrum; y el equipo de desarrollo. Los artefactos principales son el product backlog, una lista de requisitos priorizada
Scrumyprincipiosgiles
- 3. Un recorrido por la historia… Eliminar los desperdicios: •Todo aquello que no produce valor agregado en el proceso. Respetar a las personas: •Dejar que las personas piensen y decidan por su cuenta, ellos conocen como mejorar el proceso en el que trabajan. Postergar los compromisos: •Retardar las decisiones hasta que se disponga de mayor información ó no se pueda esperar más. Crear Conocimiento: •Mantener una cultura de mejora continua. Entregas rápidas: •Permitir que el cliente pueda aprovechar con anticipación los beneficios del proyecto. Desarrollar con calidad interna: •De manera que el producto pueda ir creciendo con una velocidad sostenida. Optimizar la totalidad del proceso: •Mejorar el proceso de creación del producto, desde la idea hasta su entrega. www.lemondata.com.ar
- 4. Un recorrido por la historia… Los inicios de Scrum: 1986: se publicó en el Hardvard Bussiness Review el artículo “The New New Product Development Game” (por Hirotaka Takeuchi y Ikujiro Nonaka). 1993: Jeff Sutherland, formó el primer equipo Scrum para el desarrollo de Software. 1995: Jeff Sutherland y Ken Schwaber presentaron formalmente el marco de trabajo Scrum, en OOPSLA 95. 2001: Ken Schwaber y Mike Beedle, presentaron el primer libro: “Agile Software development with Scrum” www.lemondata.com.ar
- 5. Un recorrido por la historia… Manifiesto para el Desarrollo Ágil de Software Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. http://agilemanifesto.org/ www.lemondata.com.ar
- 6. Características Propósito: • No es un proceso o una técnica para desarrollar o crear productos, sino que es un marco trabajo en el que se pueden emplear diversos procesos y técnicas. • Se basa en la teoría del control empírico de procesos, empleando un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. Atributos y valores: La Transparencia La Inspección La Adaptación www.lemondata.com.ar Compromiso Enfoque Respeto Coraje
- 7. Características TIME- BOX: •Ayuda a crear regularidad en las actividades: Sprint Planning Scrum Daily meeting Sprint Review Sprint Retrospective. Sprint SPRINT: • Son iteraciones de 2 a 4 semanas, los cuales se inician inmediatamente después del anterior. • Son de duración fija: terminan en una fecha específica, aunque no se haya terminado el trabajo, y nunca se alargan. • La duración debe ser constante Sprint a Sprint, para producir predictibilidad y un paso sostenido. www.lemondata.com.ar
- 8. Ciclo de trabajo de Scrum www.lemondata.com.ar
- 9. ROLES: Product Owner • Cliente o representante del mismo (con enfoque al Cliente). • Crea la visión de producto y es responsable de mantener actualizada y priorizada la lista de requerimientos (Product Backlog). • Sprint a Sprint reprioriza y refina el Product Backlog, de acuerdo al valor de negocio. • Acepta o rechaza los resultados del trabajo de un Sprint. • Decide fechas del release. • Puede cancelar un Sprint. Consejos: • Para que el PO tenga éxito, todos en la organización deben respetar sus decisiones. • El PO es una persona, no un comité. www.lemondata.com.ar • El PO nunca debe ser el Scrum Master.
- 10. ROLES: Scrum Master • Responsable de asegurar el cumplimiento de las reglas y prácticas de Scrum. • Facilitador, no Project Manager, es decir, no asignan tareas. • Elimina los impedimentos del Equipo. • Se asegura que el Equipo funcione correctamente, reafirmando los principios de Scrum (auto-organizados y funcionales). • Protege al Equipo, de nuevos requerimientos durante el Sprint. Consejos: • Puede ser un miembro del Equipo. Sin embargo, esto conduce frecuentemente a conflictos cuando el SM tiene que elegir entre eliminar obstáculos o realizar las tareas. • El SM nunca debe ser el PO. • NO CONFUNDIR: Scrum Master = Project Manager www.lemondata.com.ar
- 11. ROLES: Team • Típicamente 7±2 integrantes. • Responsables del desarrollo del producto. • Auto-organizados, sin lideres. • Deciden que pueden hacer en un Sprint, como lo harán y proveen la estimación de cada User Story. • Son multidisciplinarios. • Los miembros deberían ser fulltime para evitar demoras por multitasking. • Van tomando las tareas que deseen y las van cumpliendo. Consejos: • Ubicarse en el mismo espacio de trabajo, para una mayor sinergia. • Buscar actividades/técnicas para fomentar el espíritu de colaboración y/o la www.lemondata.com.ar del equipo. autonomía
- 12. ARTEFACTOS: Product Backlog • Es una lista requerimientos priorizada por el valor de negocio. • Compuesta por los items que se pretenden para elaborar el producto: - User Story (2 – 4 semanas) - Feature (3– 6 meses) - EPIC (1– 2 años) • Esta siempre visible a todos los interesados. • El PO, es el responsable de mantener su contenido y priorización. • El Product Backlog es dinámico, y evoluciona a medida que lo hace el producto y su entorno. www.lemondata.com.ar
- 13. ARTEFACTOS: Product Backlog PBI – Product Backlog Item: •Especifica el qué, no el cómo, de una funcionalidad centrada en el usuario. • Poseen criterio de aceptación (definición de hecho). • Escrita en términos del negocio. • Se suelen dividir en varias tareas. • El esfuerzo es estimado por el Equipo. • El valor de negocio es estimado por PO. www.lemondata.com.ar
- 14. ARTEFACTOS: Sprint ó Committed Backlog • Contiene los PBI que negociaron el Equipo y el PO, durante el Sprint Planning. • Los PBI del Product Backlog, se desglosan en tareas para el Sprint Backlog (de duraciones no menores a 4 horas ni mayores a 16 horas.) • Los PBI que se convertirán en un incremento de Producto. • Los PBI a realizar, deben ser los posibles a desarrollar en un Sprint. • Siempre visible para el Equipo. • Es actualizado Inmediatamente después del Daily Scrum. www.lemondata.com.ar
- 15. ARTEFACTOS: Burndown Chart • Gráfico que muestra por día, cuanto trabajo resta para finalizar las tareas del Sprint. • Muestra el progreso hacia el objetivo, en términos del esfuerzo pendiente y story points, más que el esfuerzo realizado. • Se actualiza día a día, luego de que cada miembro del Equipo estima cuanto tiempo resta para finalizar cada tarea en el Sprint Backlog. • Facilita la auto-organización del Equipo. • No es un reporte para la administración o gerencia del proyecto. www.lemondata.com.ar
- 16. CEREMONIAS: Sprint Planning CARACTERISTICAS DESCRIPCION Frecuencia Al comienzo de cada Sprint. Duración 4 hs, para un Sprint de 2 Semanas. 8 hs, para un Sprint de un mes. Objetivo Se obtiene el Sprint Backlog ó Sprint COMMITTED Backlog. Composición Primera parte: Se discute el Qué se hará durante el Sprint (hasta completar la velocidad del Equipo). Se definen el Objetivo del Sprint, y definiciones de hecho. Segunda parte: El Equipo determina el Cómo se va a convertir una funcionalidad en Producto potencialmente entregable. PARTICIPANTES www.lemondata.com.ar - PO - EQUIPO - SM Primera parte : - PO - EQUIPO - SM Segunda parte : -EQUIPO
- 17. CEREMONIAS: Daily Standup CARACTERISTICAS DESCRIPCION Frecuencia Una vez al día (a la misma hora y en el mismo lugar). Duración 15 minutos. Objetivo Comunicación y Sincronización: Observar el estado de avance de las tareas tomadas del Sprint Backlog, y los obstáculos existentes. PARTICIPANTES Composición www.lemondata.com.ar Se contesta tres preguntas: 1. ¿Qué hice desde la última reunión? 2. ¿Qué haré hasta la próxima reunión? 3. ¿Encontré obstáculos/impedimentos? No se puede llegar tarde. Los Interesados no pueden interrumpir. Se actualiza tareas del Sprint Backlog y gráficos de Burndown. - EQUIPO - SM - Interesados
- 18. CEREMONIAS: Sprint Review CARACTERISTICAS DESCRIPCION Frecuencia Una vez, al final el Sprint. Duración 1 a 4 hs. Objetivo Mostrar el incremento de producto que el Equipo se comprometió a trabajar durante el último Sprint. Composición El Equipo muestra el trabajo realizado. PARTICIPANTES El PO verifica la realización del Sprint Backlog según la “definición de hecho”, y puede aceptar o rechazar. Todo feedback se debe plasmar en el Product Backlog. Al final, se acuerda la fecha para la próxima reunión. www.lemondata.com.ar - EQUIPO - SM - PO - Interesados
- 19. CEREMONIAS: Sprint Retrospective CARACTERISTICAS DESCRIPCION Frecuencia Una vez, al final del Sprint Review. Duración 3 a 4 hs. Objetivo Se analiza como se trabajó durante el Sprint anterior y se revisa el Proceso. Composición Lo facilita el SM. Se centran en: ¿Qué se hizo bien? ¿Qué funcionó mal? ¿En qué se puede mejorar? Finalmente se identifican y priorizan las soluciones, para aplicar en el próximo Sprint. PARTICIPANTES www.lemondata.com.ar - EQUIPO - SM
- 21. ¿Cómo llevarlo acabo? Pequeñas Entregas: •El equipo entrega software funcionando (ó un incremento del mismo que agrega valor al negocio), al PO, al final de cada Sprint. Pruebas de Usuarios: •Pruebas de Aceptación: cada User Story necesita una o más Pruebas de Aceptación (Las cuales el Equipo debería automatizarlas). Estándares de Codificación: •Buscar que todo código en el sistema, pareciera que fue escrito por un único individuo. •Los estándares de codificación ayudan a la propiedad colectiva. www.lemondata.com.ar
- 22. ¿Cómo llevarlo acabo? Propiedad Colectiva: •No existe dueños de determinadas partes de código. •Cualquiera puede modificar cualquier parte, en cualquier momento. •Difundir el conocimiento entre el Equipo. “Esto se Respalda: por Pruebas Unitarias y /o Programación de a Pares” Integración Continua: •El sistema está integrado todo el tiempo. El sistema se compila varias veces por día. Repositorio único de código fuente. Automatizar el Build. Compilación Auto – Verificable (pruebas automatizadas) Commits diarios (es una manera de comunicar al resto y anticiparse de futuros conflictos) www.lemondata.com.ar
- 23. ¿Cómo llevarlo acabo? Diseño Simple: •Debe ser lo más sencillo posible. •Suficientes para cubrir los requerimientos actuales. •No hacer cosas “por las dudas”. “El diseño Ágil es evolutivo, no una actividad para realizar anticipadamente” Programación de a Pares: •Todo código productivo es revisado por alguien más, en tiempo real. Se produce un código de mayor calidad, cuando estamos codo a codo, que si programamos de forma aislada. - No es fácil programar de a Pares, lleva unas semanas ver los resultados. www.lemondata.com.ar
- 24. ¿Cómo llevarlo acabo? Diseño dirigido por Pruebas: •Desarrollo en ciclos cortos (aplicamos TDD): Primero se codifica una Prueba de lo que se desea construir. Luego se debe verificar su fallo (si No falla, no es bueno) Luego se codifica y verifica la ejecución exitosa de la Prueba. Refactorizar hasta que se termine el fragmento que quiero construir (manteniendo las pruebas exitosas). “Las Pruebas están vinculadas a la IC.” Refactorización: •Es la Mejora continua del Diseño. •Los procesos de Refactorización se enfocan en: Remover duplicaciones. Incrementar la cohesión. Disminuir el acoplamiento. www.lemondata.com.ar
- 25. Cerrando… La agilidad requiere una forma diferente de pensar y de ver las cosas, se trata sobre todo de valores y principios. No miremos a Scrum como un conjunto más de prácticas y reglas a seguir, sino como una guía de valores y principios, que podrá hacer que en EQUIPO, con ganas de aprender, mejorar, colaborar y estando comprometidos, desarrollemos Software con un gran Valor agregado y de Calidad. www.lemondata.com.ar