Agile Software Developmentby @trukuxzo
Scrum……es un marco de trabajo estructurado para dar soporte aldesarrollo de productos complejos.Scrum consiste en los Equi...
ScrumCancelGift wrapReturnSprint2-4 semanasObjetivo del SprintSprintBacklogIncremento del productopotencialmente entregabl...
Scrum Framework•Product Owner•Scrum Master•TeamRoles•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum Meetin...
•Product Owner•Scrum Master•TeamRolesScrum Framework•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum Meetin...
Product Owner Define las funcionalidades del producto Decide sobre las fechas y contenidos de los releases Es responsab...
El ScrumMaster Representa a la gestión del proyecto Responsable de promover los valores y prácticas deScrum Remueve imp...
El Team Típicamente de 5 a 9 personas Multi-funcional: Programadores, testers, analistas, diseñadores, etc. Los miembr...
•Product Owner•Scrum Master•TeamRolesScrum Framework•Product Backlog•Sprint Backlog•Burndown ChartsArtefactos•Sprint Plann...
Sprints En Scrum los proyectos avanzan en una seriede “Sprints” Análogo a las iteraciones en XP La duración típica es 2...
Sprint Planning MeetingPriorización• Analizar y evaluar el ProductBacklog• Seleccionar el objetivo del SprintPlanificación...
Planificación del Sprint El equipo selecciona los temas a partir del ProductBacklog que pueden comprometerse a completar...
Daily Scrum Parámetros Diaria Dura 15 minutos Parados No para la solución de problemas Todo el mundo está invitado ...
Todos responden 3 preguntas No es dar un status report al Scrum Master Se trata de compromisos delante de pares¿Qué hici...
Sprint Review El equipo presenta lo realizado durante el sprint Normalmente adopta la forma de una demo de lasnuevas car...
Sprint Retrospective Periódicamente, se echa un vistazo a lo quefunciona y lo que no Normalmente 15 a 30 minutos Se rea...
Start / Stop / Continue Todo el equipo se reúne y discute lo que les gustaría:Comenzar a hacerDejar de hacerContinuar hac...
•Product Owner•Scrum Master•TeamRolesScrum Framework•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum Meetin...
Product Backlog Los requisitos Una lista de todos lostrabajos deseados en elproyecto Idealmente cada tema tienevalor pa...
Ejemplo de Product BacklogBacklog Item EstimaciónPermitir que un invitado haga una reserva. 3Como invitado, quiero cancela...
El objetivo del Sprint Una breve declaración de cual será el foco del trabajodurante el sprintAplicación con B.DatosServi...
Gestión del Sprint Backlog Los individuos eligen las tareas El trabajo nunca es asignado La estimación del trabajo rest...
Ejemplo de Sprint BacklogTareasCodificar UICodificar negocioTestear negocioEscribir ayuda onlineEscribir la clase fooL8168...
Un Sprint Burndown ChartHours
Hours403020100Mon Tue Wed Thu FriTareasCodificar UICodificar NegocioTestear NegocioEscribir ayuda onlineL816812M M J V4121...
Escalabilidad Normalmente los equipos son de 7 ± 2 personas La escalabilidad proviene de equipos de equipos Factores a ...
Expansión a través de Scrum descrums
Scrum de Scrums de Scrums
Referenciaswww.mountaingoatsoftware.com/scrumwww.scrumalliance.orgen.wikipedia.org/wiki/Scrum_(software_development)
Upcoming SlideShare
Loading in...5
×

Scrum

878
-1

Published on

Scrum - Agile Software Development

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
878
On Slideshare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Scrum

  1. 1. Agile Software Developmentby @trukuxzo
  2. 2. Scrum……es un marco de trabajo estructurado para dar soporte aldesarrollo de productos complejos.Scrum consiste en los Equipos Scrum y en sus roles,eventos, artefactos y reglas asociadas.Cada componente dentro del marco de trabajo sirve a unpropósito específico y es esencial para el éxito de Scrumy para su uso.
  3. 3. ScrumCancelGift wrapReturnSprint2-4 semanasObjetivo del SprintSprintBacklogIncremento del productopotencialmente entregableProductBacklog24 horas
  4. 4. Scrum Framework•Product Owner•Scrum Master•TeamRoles•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum MeetingReuniones•Product Backlog•Sprint Backlog•Burndown ChartsArtefactos
  5. 5. •Product Owner•Scrum Master•TeamRolesScrum Framework•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum MeetingReuniones•Product Backlog•Sprint Backlog•Burndown ChartsArtefactos
  6. 6. Product Owner Define las funcionalidades del producto Decide sobre las fechas y contenidos de los releases Es responsable por la rentabilidad del producto (ROI) Prioriza funcionalidades de acuerdo al valor delmercado/negocio Ajusta funcionalidades y prioridades en cada iteraciónsi es necesario Acepta o rechaza los resultados del trabajo del equipo
  7. 7. El ScrumMaster Representa a la gestión del proyecto Responsable de promover los valores y prácticas deScrum Remueve impedimentos Se asegura de que el equipo es completamentefuncional y productivo Permite la estrecha cooperación en todos los roles yfunciones Escudo del equipo de interferencias externas
  8. 8. El Team Típicamente de 5 a 9 personas Multi-funcional: Programadores, testers, analistas, diseñadores, etc. Los miembros deben ser full-time Puede haber excepciones (Ej.: Infraestructura, SCM, etc.) Los equipos son auto-organizativos Idealmente, no existen títulos pero a veces se utilizan de acuerdoa la organización Solo puede haber cambio de miembros entre los sprints
  9. 9. •Product Owner•Scrum Master•TeamRolesScrum Framework•Product Backlog•Sprint Backlog•Burndown ChartsArtefactos•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum MeetingReuniones
  10. 10. Sprints En Scrum los proyectos avanzan en una seriede “Sprints” Análogo a las iteraciones en XP La duración típica es 2–4 semanas o alo sumoun mes calendario La duración constante conduce a un mejorritmo El product es diseñado, codificado y testeadodurante el Sprint
  11. 11. Sprint Planning MeetingPriorización• Analizar y evaluar el ProductBacklog• Seleccionar el objetivo del SprintPlanificación• Decidir como alcanzar el objetivodel Sprint (diseño)• Crear el Sprint Backlog (tareas)en base a los temas del ProductBacklog (user stories / features)• Estimar Sprint Backlog en horasObjetivodel SprintSprintBacklogCondiciones delNegocioCapacidaddel EquipoProductBacklogTecnologíaProductoActual
  12. 12. Planificación del Sprint El equipo selecciona los temas a partir del ProductBacklog que pueden comprometerse a completar Se crea el Sprint Backlog Se identifican tareas y cada una es estimada (1-16 horas) Realizado colaborativamente, no solo por el ScrumMaster El diseño de Alto Nivel es consideradoCOMO planificadorde vacaciones, YOQUIERO ver fotosde los hoteles.Codificar la capa intermedia (8 hs)Codificar la interfaz de usuario (4)Escribir los test fixtures (4)Codificar la clase foo (6)Actualizar test de performance (4)
  13. 13. Daily Scrum Parámetros Diaria Dura 15 minutos Parados No para la solución de problemas Todo el mundo está invitado Sólo los miembros del equipo, ScrumMaster y ProductOwner, pueden hablar Ayuda a evitar otras reuniones innecesarias
  14. 14. Todos responden 3 preguntas No es dar un status report al Scrum Master Se trata de compromisos delante de pares¿Qué hiciste ayer?1¿Qué vas a hacer hoy?2¿Hay obstáculos en tu camino?3
  15. 15. Sprint Review El equipo presenta lo realizado durante el sprint Normalmente adopta la forma de una demo de lasnuevas características o la arquitectura subyacente Informal Regla de 2 hs preparación No usar diapositivas Todo el equipo participa Se invita a todo el mundo
  16. 16. Sprint Retrospective Periódicamente, se echa un vistazo a lo quefunciona y lo que no Normalmente 15 a 30 minutos Se realiza luego de cada Sprint Todo el equipo participa ScrumMaster Product Owner Equipo Posiblemente clientes y otros
  17. 17. Start / Stop / Continue Todo el equipo se reúne y discute lo que les gustaría:Comenzar a hacerDejar de hacerContinuar haciendoEsto es sólo unade las muchasmaneras dehacer unaretrospectiva.
  18. 18. •Product Owner•Scrum Master•TeamRolesScrum Framework•Sprint Planning•Sprint Review•Sprint Retrospective•Daily Scrum MeetingReuniones•Product Backlog•Sprint Backlog•Burndown ChartsArtefactos
  19. 19. Product Backlog Los requisitos Una lista de todos lostrabajos deseados en elproyecto Idealmente cada tema tienevalor para el usuarios o elcliente Priorizada por el ProductOwner Repriorizada al comienzo decada SprintEste es elProduct Backlog
  20. 20. Ejemplo de Product BacklogBacklog Item EstimaciónPermitir que un invitado haga una reserva. 3Como invitado, quiero cancelar una reserva. 5Como invitado, quiero cambiar las fechas de unareserva.3Como un empleado de hotel, puedo ejecutarinformes de los ingresos por habitacióndisponible8Mejorar el manejo de excepciones 8... 30... 50
  21. 21. El objetivo del Sprint Una breve declaración de cual será el foco del trabajodurante el sprintAplicación con B.DatosServicios FinancierosCiencias BiológicasFunciones de apoyo técniconecesarios para estudios degenética de poblaciones.Soportar más indicadorestécnicos que la empresa ABC entiempo real y streaming de datos.Hacer que la aplicación seejecute en SQL Server, ademásde Oracle.
  22. 22. Gestión del Sprint Backlog Los individuos eligen las tareas El trabajo nunca es asignado La estimación del trabajo restante es actualizadadiariamente Cualquier miembro del equipo puede añadir, borrar ocambiar el Sprint Backlog El trabajo para el Sprint emerge Si el trabajo no está claro, definir un tema del SprintBacklog con una mayor cantidad de tiempo y subdividirlaluego. Actualizar el trabajo restante a medida de que más seconoce
  23. 23. Ejemplo de Sprint BacklogTareasCodificar UICodificar negocioTestear negocioEscribir ayuda onlineEscribir la clase fooL8168128M412168M J41184V88Agregar error logging8101688
  24. 24. Un Sprint Burndown ChartHours
  25. 25. Hours403020100Mon Tue Wed Thu FriTareasCodificar UICodificar NegocioTestear NegocioEscribir ayuda onlineL816812M M J V4121671181016 850
  26. 26. Escalabilidad Normalmente los equipos son de 7 ± 2 personas La escalabilidad proviene de equipos de equipos Factores a tener cuenta Tipo de aplicación Tamaño del equipo Dispersión del equipo Duración del proyecto Scrum se ha utilizado en múltiples proyectos demás de 500 personas
  27. 27. Expansión a través de Scrum descrums
  28. 28. Scrum de Scrums de Scrums
  29. 29. Referenciaswww.mountaingoatsoftware.com/scrumwww.scrumalliance.orgen.wikipedia.org/wiki/Scrum_(software_development)

×