Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
UNA INTRODUCCIÓN A SCRUM
Jorge Hernán Abad Londoño
jorge.abad@gmail.com
jorge.abad@gmail.com
¿Por que fallan los proyectos?
¿Por qué fallan los suyos?
09/08/2014 2
Estadísticas de Colombia – 2012
PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
jorge.abad@gmail.com
PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
Estadísticas de Colombia – 2012
jorge.abad@gmail.com
Estadísticas de Colombia
– 2012
PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
jorge.abad@gmail.com
Causa de Fracasos en los
Proyectos
09/08/2014 6
• Cronogramas poco realistas
• Personal inadecuado
• ...
Tipos de proyecto de acuerdo a los
requisitos y la tecnología
jorge.abad@gmail.com
¿Pregunta?
09/08/2014 8
¿VIAJARÍA USTED EN UN
AVIÓN AL QUE USTED LE
ESCRIBIÓ EL SOFTWARE DE
NAVEGACIÓ...
jorge.abad@gmail.com
Manifiesto Ágil
Estamos descubriendo formas mejores de desarrollar software
tanto por nuestra propia ...
jorge.abad@gmail.com
Los 12 Principios
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y ...
jorge.abad@gmail.com
Los 12 Principios
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrol...
jorge.abad@gmail.com
Valores
• Compromiso
• Enfoque y Foco
• Apertura y transparencia
• Respeto
• Coraje
09/08/2014
PLANIF...
Cambio de Esquema de Negociación
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software...
jorge.abad@gmail.com
Objetivo: Pasar a la otra orilla a pie sin
mojarse (sin usar un puente, etc, etc.)
09/08/2014 14
jorge.abad@gmail.com
Lacey, Mitch. The Scrum Field Guide: Practical
Advice for Your First Year (Agile Software
Development...
jorge.abad@gmail.com
Adaptando el plan en vez
de adaptarnos al plan
09/08/2014 16
El espiritu de Scrum.
Alan Cyment
09/08/2014 17
Crecimiento orgánico
(iterativo e incremental)
Dibujo realizado por Jeff Patton
Una mujer
con una
pradera
at...
09/08/2014 18
Diferencias entre enfoque iterativo y
enfoque orgánico (iterativo e
incremental)
Dibujo realizado por Jeff P...
Cambio de Esquema de Negociación
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software...
SCRUM
“El Arte de Amar los Lunes”.
Alan Cyment
jorge.abad@gmail.com
Estamos perdiendo la carrera
de relevos
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product De...
jorge.abad@gmail.com
• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el m...
jorge.abad@gmail.com
• Scrum es una framework metodológico para la
gestión de proyectos, expuesta por Hirotaka
Takeuchi e ...
jorge.abad@gmail.com
Orígenes de Scrum
• Jeff Sutherland
o Scrums iniciales en Easel Corp en 1993
o IDX 500 personas hacie...
jorge.abad@gmail.com
Scrum ha sido utilizado por:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed ...
jorge.abad@gmail.com
Scrum ha sido utilizado para:• Software comercial
• Desarrollos internos
• Desarrollos bajo Contrato
...
jorge.abad@gmail.com
Características
 Equipos auto-organizados
 El producto avanza en una serie de
“Sprints" de dos sema...
jorge.abad@gmail.com
Scrum
Cancel
Gift wrap
Return
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Backlog
Incremento del pr...
jorge.abad@gmail.com
Poniendo todo junto
Imagen disponible en
www.mountaingoatsoftware.com/scrum
jorge.abad@gmail.com
Sprints
• En Scrum los proyectos avanzan en una
serie de “Sprints”
o Análogo a las iteraciones en XP
...
jorge.abad@gmail.com
Desarrollo secuencial vs.
superpuesto
Source: “The New New Product Development Game” by
Takeuchi and ...
jorge.abad@gmail.com
No hay cambios en un
sprint
 Planee la duración del sprint en torno a
cuánto tiempo usted puede comp...
jorge.abad@gmail.com
Scrum Framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retro...
jorge.abad@gmail.com
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
...
jorge.abad@gmail.com
jorge.abad@gmail.com
jorge.abad@gmail.com
Product Owner
 Define las funcionalidades del producto
 Decide sobre las fechas y contenidos de los...
jorge.abad@gmail.com
Product Owner
El espiritu de Scrum.
Alan Cyment
jorge.abad@gmail.com
El ScrumMaster
• Representa a la gestión del proyecto
• Responsable de promover los valores y práctic...
jorge.abad@gmail.com
El Team
 Típicamente de 5 a 9 personas
 Multi-funcional:
◦ Programadores, testers, analistas, diseñ...
jorge.abad@gmail.com
Interacción entre los roles
Fuente: El espiritu de Scrum.
Alan Cyment
jorge.abad@gmail.com
•Product owner
•ScrumMaster
•Team
Roles
Scrum Framework
•Product backlog
•Sprint backlog
•Burndown ch...
jorge.abad@gmail.com
Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetiv...
jorge.abad@gmail.com
Planificación del Sprint
• El equipo selecciona los temas a partir del Product
Backlog que pueden com...
jorge.abad@gmail.com
Daily Scrum
• Parámetros
o Diaria
o Dura 15 minutos
o Parados
• No para la solución de problemas
o To...
jorge.abad@gmail.com
Todos responden 3
preguntas
• No es dar un status report al Scrum Master
• Se trata de compromisos de...
jorge.abad@gmail.com
Sprint review
 El equipo presenta lo realizado durante
el sprint
 Normalmente adopta la forma de un...
jorge.abad@gmail.com
Sprint retrospective
• Periódicamente, se echa un vistazo a lo
que funciona y lo que no
• Normalmente...
jorge.abad@gmail.com
Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les
gustaría :
Comenzar a hacer
De...
jorge.abad@gmail.com
Retrospective
• Por lo general se evalua
Felicidad
Productividad
Calidad
Esto es sólo una
de las much...
jorge.abad@gmail.com
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retro...
jorge.abad@gmail.com
Product Backlog
• Los requisitos
• Una lista de todos los trabajos
deseados en el proyecto
• Idealmen...
jorge.abad@gmail.com
Product
Backlog
09/08/2014 53
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Ye...
jorge.abad@gmail.com
Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Co...
jorge.abad@gmail.com
Ejemplo de Product
Backlog
jorge.abad@gmail.com
El objetivo del Sprint
• Una breve declaración de cual será el foco del
trabajo durante el sprint
Apl...
jorge.abad@gmail.com
Gestión del Sprint Backlog
 Los individuos eligen las tareas
 El trabajo nunca es asignado
 La est...
jorge.abad@gmail.com
Ejemplo de Sprint Backlog
Tareas
Codificar UI
Codificar negocio
Testear negocio
Escribir ayuda online...
jorge.abad@gmail.com
Ejemplo de Sprint
Backlog
jorge.abad@gmail.com
Seguimiento
• Es recomendable, que el propietario del
producto emplee una hoja de cálculo, alguna
her...
Tablero de mando - Kanban
Recordemos
jorge.abad@gmail.com
Un Sprint Burndown Chart
Hours
jorge.abad@gmail.com
Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tareas
Codificar UI
Codificar Negocio
Testear Negocio
Escribi...
jorge.abad@gmail.com
Escalabilidad
• Normalmente los equipos son de 7 ± 2
personas
o La escalabilidad proviene de equipos ...
jorge.abad@gmail.com
Expansión a través de
Scrum de scrums
jorge.abad@gmail.com
Scrum de scrums de scrums
jorge.abad@gmail.com
Scrum of Scrums / Meta-
Scrum
Scrum
09/08/2014 73
Scrum estar acompañado
de buenas prácticas de
ingeniería.
 Versionone.com
09/08/2014 75
Scrum = reglas + espíritu + buenas
prácticas
¿En resumen en qué
consiste scrum?
El espiritu de Scrum.
Alan C...
jorge.abad@gmail.com
La magia no existe
• Ken Schwaber: “En Scrum, un grupo en el que se
lleven mal entre ellos, no compre...
jorge.abad@gmail.com
Donde seguir?
• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com
• w...
jorge.abad@gmail.com
Una lista de lecturas sobre Scrum
• Agile and Iterative Development: A Manager’s Guide by
Craig Larma...
ANEXOS
Introducción a Agile
El juego de la Estimación
Historias de Usuario
Introducción a Agile
jorge.abad@gmail.com
jorge.abad@gmail.com
El Manifesto Ágil – una
declaración de valores
Procesos y
herramientas
Individuos e
interacciones
sob...
jorge.abad@gmail.com
Algunos principios y
valores ágiles
• La prioridad mayor es la satisfacción del cliente haciendo
entr...
jorge.abad@gmail.com
Ágil no es hacer lo que se
quiera
• … ni tampoco programación heroica
jorge.abad@gmail.com
jorge.abad@gmail.com
La magia no existe
• Ken Schwaber: “En Scrum, un grupo en el que se
lleven mal entre ellos, no compre...
El juego de la
estimación
jorge.abad@gmail.com
Poker Game
• Planificación de póquer es una variación del
método Delphi.
• Es simple, se burla y los ...
jorge.abad@gmail.com
La baraja de Cartas
• Cada juevo de cartas incluye los
números 0, (0,5), 1, 2, 3, 5, 8, 13,
20, 40, 1...
jorge.abad@gmail.com
La reunión de
planificación (1)
• Al comienzo de la planificación de póquer,
cada estimador se le da ...
jorge.abad@gmail.com
La reunión de
planificación (2)
• El Dueño del producto (Product Owner) responde todas
las preguntas ...
jorge.abad@gmail.com
La reunión de
planificación (3)
• Valores altos de tiempo implican
o Baja granularidad
o Alta complej...
jorge.abad@gmail.com
Resultados
• En muchos casos, las estimaciones convergen en
la segunda ronda. En caso contrario se de...
Historia de usuarios
Fuente Wikipedia
jorge.abad@gmail.com
Historias de Usuario
• Una historia de usuario es una representación de un
requerimiento de software ...
jorge.abad@gmail.com
Historias de Usuario
• Las historias de usuario son una forma rápida de
administrar los requerimiento...
jorge.abad@gmail.com
Características
• Independientes unas de otras: De ser necesario, combinar las historias
dependientes...
jorge.abad@gmail.com
Características
• Si bien el estilo puede ser libre, la historia de usuario
debe responder a tres pre...
jorge.abad@gmail.com
Beneficios
• Al ser muy corta esta representa requisitos del
modelo de negocio que pueden implementar...
jorge.abad@gmail.com
Limitaciones
• Sin pruebas de validación pueden quedar abiertas a
distintas interpretaciones haciendo...
jorge.abad@gmail.com
Un enfoque BDD (Behavior
Driven Development)
• Title (one line describing the story)
•
• Narrative:
•...
jorge.abad@gmail.com
Ejemplo
BDD
• Scenario 1: Account has sufficient funds
• Given the account balance is $100
• And the ...
jorge.abad@gmail.com
Aviso de Copyright
• Usted es libre de:
o Compartir- copiar, distribuir y trasmitir el trabajo
o Modi...
jorge.abad@gmail.com
Información de Contacto
Presentado por: Mike Cohn
mike@mountaingoatsoftware.com
www.mountaingoatsoftw...
jorge.abad@gmail.com
Tomado de:
• Una introducción a Scrum - Ernesto Grafeuille.
• Enriquecido y Modificado por: Jorge H. ...
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Una introducción a Scrum - Por Jorge Abad @jorge_abad
Prochain SlideShare
Chargement dans…5
×

Una introducción a Scrum - Por Jorge Abad @jorge_abad

Corresponde a la presentación realizada en @agilesColombia sobre Scrum y sus características principales. https://www.youtube.com/watch?v=8WgZ2NjodbE

  • Soyez le premier à commenter

Una introducción a Scrum - Por Jorge Abad @jorge_abad

  1. 1. UNA INTRODUCCIÓN A SCRUM Jorge Hernán Abad Londoño jorge.abad@gmail.com
  2. 2. jorge.abad@gmail.com ¿Por que fallan los proyectos? ¿Por qué fallan los suyos? 09/08/2014 2
  3. 3. Estadísticas de Colombia – 2012 PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
  4. 4. jorge.abad@gmail.com PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS Estadísticas de Colombia – 2012
  5. 5. jorge.abad@gmail.com Estadísticas de Colombia – 2012 PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
  6. 6. jorge.abad@gmail.com Causa de Fracasos en los Proyectos 09/08/2014 6 • Cronogramas poco realistas • Personal inadecuado • Cambios en los requerimientos • Trabajo de pobre calidad • Creer en magia  Winning with Software: An Executive Strategy. Watts S. Humphrey
  7. 7. Tipos de proyecto de acuerdo a los requisitos y la tecnología
  8. 8. jorge.abad@gmail.com ¿Pregunta? 09/08/2014 8 ¿VIAJARÍA USTED EN UN AVIÓN AL QUE USTED LE ESCRIBIÓ EL SOFTWARE DE NAVEGACIÓN? PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS
  9. 9. jorge.abad@gmail.com Manifiesto Ágil 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/iso/es/ © 2001, los autores mencionados mediante esta nota se autoriza la copia y distribución de esta declaración a través de cualquier medio pero sólo de forma íntegra.
  10. 10. jorge.abad@gmail.com Los 12 Principios 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 7. El software funcionando es la medida principal de progreso. http://agilemanifesto.org/iso/es/
  11. 11. jorge.abad@gmail.com Los 12 Principios 8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10.La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11.Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. 12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. http://agilemanifesto.org/iso/es/
  12. 12. jorge.abad@gmail.com Valores • Compromiso • Enfoque y Foco • Apertura y transparencia • Respeto • Coraje 09/08/2014 PLANIFICACIÓN Y GESTIÓN DE PROYECTOS INFORMÁTICOS ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE – UNIVERSIDAD DE 12
  13. 13. Cambio de Esquema de Negociación Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
  14. 14. jorge.abad@gmail.com Objetivo: Pasar a la otra orilla a pie sin mojarse (sin usar un puente, etc, etc.) 09/08/2014 14
  15. 15. jorge.abad@gmail.com Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
  16. 16. jorge.abad@gmail.com Adaptando el plan en vez de adaptarnos al plan 09/08/2014 16 El espiritu de Scrum. Alan Cyment
  17. 17. 09/08/2014 17 Crecimiento orgánico (iterativo e incremental) Dibujo realizado por Jeff Patton Una mujer con una pradera atrás
  18. 18. 09/08/2014 18 Diferencias entre enfoque iterativo y enfoque orgánico (iterativo e incremental) Dibujo realizado por Jeff Patton
  19. 19. Cambio de Esquema de Negociación Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
  20. 20. SCRUM “El Arte de Amar los Lunes”. Alan Cyment
  21. 21. jorge.abad@gmail.com Estamos perdiendo la carrera de relevos Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986. “En enfoque de ‘carrera de relevos’ en el desarrollo de productos ... puede entrar en conflicto con los objetivos de máxima velocidad y flexibilidad. En su lugar, un enfoque holístico o estilo ‘rugby’ - donde un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y hacia atrás -pueden servir mejor a los actuales requisitos competitivos".
  22. 22. jorge.abad@gmail.com • Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. • Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). • El negocio fija las prioridades. Los equipos se auto- organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. • Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint. Scrum en 100 palabras
  23. 23. jorge.abad@gmail.com • Scrum es una framework metodológico para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que: o El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad. o Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas. o El mercado exige ciclos de desarrollo más cortos. SCRUM
  24. 24. jorge.abad@gmail.com Orígenes de Scrum • Jeff Sutherland o Scrums iniciales en Easel Corp en 1993 o IDX 500 personas haciendo Scrum • Ken Schwaber o ADM o Se presenta Scrum en OOPSLA 96 con Sutherland o Autor de tres libros sobre Scrum • Mike Beedle o Patrones Scrum en PLOPD4 • Ken Schwaber and Mike Cohn o Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance
  25. 25. jorge.abad@gmail.com Scrum ha sido utilizado por: •Microsoft •Yahoo •Google •Electronic Arts •High Moon Studios •Lockheed Martin •Philips •Siemens •Nokia •Capital One •BBC •Intuit •Intuit •Nielsen Media •First American Real Estate •BMC Software •Ipswitch •John Deere •Lexis Nexis •Sabre •Salesforce.com •Time Warner •Turner Broadcasting •Oce
  26. 26. jorge.abad@gmail.com Scrum ha sido utilizado para:• Software comercial • Desarrollos internos • Desarrollos bajo Contrato • Proyectos Fixed-price • Aplicaciones Financieras • Aplicaciones certificadas ISO 9001 • Sistemas Embebidos • Sistemas con requisitos 7x24 y 99.999% de disponibilidad • Joint Strike Fighter • Desarrollo de video juegos • Sistemas críticos de soporte vital, aprobados por laFDA • Software de control satelital • Sitios Web • Software para Handheld • Teléfonos portátiles • Aplicaciones de Network switching • Aplicaciones de ISV • Algunas de las más grandes aplicaciones en uso
  27. 27. jorge.abad@gmail.com Características  Equipos auto-organizados  El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración  Los requisitos son capturados como elementos de una lista de “Product Backlog"  No hay prácticas de ingeniería prescritas  Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos  Uno de los “procesos ágiles”
  28. 28. jorge.abad@gmail.com Scrum Cancel Gift wrap Return Sprint 2-4 semanas Objetivo del Sprint Sprint Backlog Incremento del producto potencialmente entregable Product Backlog 24 horas
  29. 29. jorge.abad@gmail.com Poniendo todo junto Imagen disponible en www.mountaingoatsoftware.com/scrum
  30. 30. jorge.abad@gmail.com Sprints • En Scrum los proyectos avanzan en una serie de “Sprints” o Análogo a las iteraciones en XP • La duración típica es 2–4 semanas o a lo sumo un mes calendario • La duración constante conduce a un mejor ritmo • El product es diseñado, codificado y testeado durante el Sprint
  31. 31. jorge.abad@gmail.com Desarrollo secuencial vs. superpuesto Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo Requisitos Diseño Código Test
  32. 32. jorge.abad@gmail.com No hay cambios en un sprint  Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint Cambios
  33. 33. jorge.abad@gmail.com Scrum Framework •Product owner •ScrumMaster •Team Roles •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  34. 34. jorge.abad@gmail.com Scrum framework •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos •Product owner •ScrumMaster •Team Roles
  35. 35. jorge.abad@gmail.com
  36. 36. jorge.abad@gmail.com
  37. 37. jorge.abad@gmail.com 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 del mercado/negocio  Ajusta funcionalidades y prioridades en cada iteración si es necesario  Acepta o rechaza los resultados del trabajo del equipo
  38. 38. jorge.abad@gmail.com Product Owner El espiritu de Scrum. Alan Cyment
  39. 39. jorge.abad@gmail.com El ScrumMaster • Representa a la gestión del proyecto • Responsable de promover los valores y prácticas de Scrum • Remueve impedimentos • Se asegura de que el equipo es completamente funcional y productivo • Permite la estrecha cooperación en todos los roles y funciones • Escudo del equipo de interferencias externas
  40. 40. jorge.abad@gmail.com 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 acuerdo a la organización  Solo puede haber cambio de miembros entre los sprints
  41. 41. jorge.abad@gmail.com Interacción entre los roles Fuente: El espiritu de Scrum. Alan Cyment
  42. 42. jorge.abad@gmail.com •Product owner •ScrumMaster •Team Roles Scrum Framework •Product backlog •Sprint backlog •Burndown charts Artefactos •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones
  43. 43. jorge.abad@gmail.com Sprint Planning meeting Priorización • Analizar y evaluar el Product Backlog • Seleccionar el objetivo del Sprint Planificación • Decidir como alcanzar el objetivo del Sprint (diseño) • Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features) • Estimar Sprint Backlog en horas Objetivo del Sprint Sprint Backlog Condicione s del Negocio Capacidad del Equipo Product Backlog Tecnología Producto Actual
  44. 44. jorge.abad@gmail.com Planificación del Sprint • El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar • Se crea el Sprint Backlog o Se identifican tareas y cada una es estimada (1-16 horas) o Realizado colaborativamente, no solo por el ScrumMaster • El diseño de Alto Nivel es considerado YO COMO planificador de vacaciones, QUIERO ver fotos de los hoteles. PARA poder mostrar diferentes sitios a mis clientes 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)
  45. 45. jorge.abad@gmail.com Daily Scrum • Parámetros o Diaria o Dura 15 minutos o Parados • No para la solución de problemas o Todo el mundo está invitado o Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar o Ayuda a evitar otras reuniones innecesarias
  46. 46. jorge.abad@gmail.com 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
  47. 47. jorge.abad@gmail.com Sprint review  El equipo presenta lo realizado durante el sprint  Normalmente adopta la forma de una demo de las nuevas 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
  48. 48. jorge.abad@gmail.com Sprint retrospective • Periódicamente, se echa un vistazo a lo que funciona y lo que no • Normalmente 1 hora • Se realiza luego de cada sprint • Todo el equipo participa o ScrumMaster o Product owner o Equipo o Posiblemente clientes y otros
  49. 49. jorge.abad@gmail.com Start / Stop / Continue • Todo el equipo se reúne y discute lo que les gustaría : Comenzar a hacer Dejar de hacer Continuar haciendo Esto es sólo una de las muchas maneras de hacer una retrospectiva.
  50. 50. jorge.abad@gmail.com Retrospective • Por lo general se evalua Felicidad Productividad Calidad Esto es sólo una de las muchas maneras de hacer una retrospectiva.
  51. 51. jorge.abad@gmail.com •Product owner •ScrumMaster •Team Roles Scrum framework •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  52. 52. jorge.abad@gmail.com Product Backlog • Los requisitos • Una lista de todos los trabajos deseados en el proyecto • Idealmente cada tema tiene valor para el usuarios o el cliente • Priorizada por el Product Owner • Repriorizada al comienzo de cada Sprint • Se aplica PARETO (el 20% de las historias de usuario cumplen con el 80% de las necesidades del P.O. Este es el product backlog
  53. 53. jorge.abad@gmail.com Product Backlog 09/08/2014 53 Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series) • Existen técnicas de priorización como: o Visual Story Mapping, o Minimal Market Feature, o Impact Mapping
  54. 54. jorge.abad@gmail.com Ejemplo de Product Backlog Backlog item Estimación Permitir que un invitado a hacer una reserva. 3 Como invitado, quiero cancelar una reserva. 5 Como invitado, quiero cambiar las fechas de una reserva. 3 Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible 8 Mejorar el manejo de excepciones 8 ... 30 ... 50
  55. 55. jorge.abad@gmail.com Ejemplo de Product Backlog
  56. 56. jorge.abad@gmail.com El objetivo del Sprint • Una breve declaración de cual será el foco del trabajo durante el sprint Aplicación con B.Datos Servicios Financieros Ciencias Biológicas Funciones de apoyo técnico necesarios para estudios de genética de poblaciones. Soportar más indicadores técnicos que la empresa ABC en tiempo real y streaming de datos. Hacer que la aplicación se ejecute en SQL Server, además de Oracle.
  57. 57. jorge.abad@gmail.com Gestión del Sprint Backlog  Los individuos eligen las tareas  El trabajo nunca es asignado  La estimación del trabajo restante es actualizada diariamente  Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog  El trabajo para el Sprint emerge  Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego.  Actualizar el trabajo restante a medida de que más se conoce
  58. 58. jorge.abad@gmail.com Ejemplo de Sprint Backlog Tareas Codificar UI Codificar negocio Testear negocio Escribir ayuda online Escribir la clase foo L 8 16 8 12 8 M 4 12 16 8 M J 4 11 8 4 V 8 8 Agregar error logging 8 10 16 8 8
  59. 59. jorge.abad@gmail.com Ejemplo de Sprint Backlog
  60. 60. jorge.abad@gmail.com Seguimiento • Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto. • Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala. • Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).
  61. 61. Tablero de mando - Kanban
  62. 62. Recordemos
  63. 63. jorge.abad@gmail.com Un Sprint Burndown Chart Hours
  64. 64. jorge.abad@gmail.com Hours 40 30 20 10 0 Mon Tue Wed Thu Fri Tareas Codificar UI Codificar Negocio Testear Negocio Escribir ayuda online L 8 16 8 12 M M J V 4 12 16 7 11 8 10 16 8 50
  65. 65. jorge.abad@gmail.com Escalabilidad • Normalmente los equipos son de 7 ± 2 personas o La escalabilidad proviene de equipos de equipos • Factores a tener cuenta o Tipo de aplicación o Tamaño del equipo o Dispersión del equipo o Duración del proyecto • Scrum se ha utilizado en múltiples proyectos de más de 500 personas
  66. 66. jorge.abad@gmail.com Expansión a través de Scrum de scrums
  67. 67. jorge.abad@gmail.com Scrum de scrums de scrums
  68. 68. jorge.abad@gmail.com Scrum of Scrums / Meta- Scrum Scrum
  69. 69. 09/08/2014 73 Scrum estar acompañado de buenas prácticas de ingeniería.
  70. 70.  Versionone.com
  71. 71. 09/08/2014 75 Scrum = reglas + espíritu + buenas prácticas ¿En resumen en qué consiste scrum? El espiritu de Scrum. Alan Cyment
  72. 72. jorge.abad@gmail.com La magia no existe • Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ” • Dan visibilidad y transparencia desde el principio, aunque no resuelven todos los problemas. • No ser extremista, usar lo que te funcione • Se recomienda primero usar todo, luego hacer modificaciones. Cuidado con “Scrum but…”
  73. 73. jorge.abad@gmail.com Donde seguir? • www.mountaingoatsoftware.com/scrum • www.scrumalliance.org • www.controlchaos.com • www.scrum.org • scrumdevelopment@yahoogroups.com
  74. 74. jorge.abad@gmail.com Una lista de lecturas sobre Scrum • Agile and Iterative Development: A Manager’s Guide by Craig Larman • Agile Estimating and Planning by Mike Cohn • Agile Project Management with Scrum by Ken Schwaber • Agile Retrospectives by Esther Derby and Diana Larsen • Agile Software Development Ecosystems by Jim Highsmith • Agile Software Development with Scrum by Ken Schwaber and Mike Beedle • Scrum and The Enterprise by Ken Schwaber • User Stories Applied for Agile Software Development by Mike Cohn • Artículos semanales en www.scrumalliance.org
  75. 75. ANEXOS Introducción a Agile El juego de la Estimación Historias de Usuario
  76. 76. Introducción a Agile
  77. 77. jorge.abad@gmail.com
  78. 78. jorge.abad@gmail.com El Manifesto Ágil – una declaración de valores Procesos y herramientas Individuos e interacciones sobre Seguimiento de un plan Responder ante el cambio sobre Fuente: www.agilemanifesto.org Documentación exhaustiva Software que funciona sobre Negociación de contratos Colaboración con el cliente sobre
  79. 79. jorge.abad@gmail.com Algunos principios y valores ágiles • La prioridad mayor es la satisfacción del cliente haciendo entregas continuas de software valioso para él • Los cambios son bienvenidos siempre • La medida principal de progreso es el software funcionando • El gestor es un facilitador no un controlador • Equipos auto-organizados y multidisciplinares • Inspeccionar y adaptar • Mejora continua • Respeto, claridad y comunicación • Ritmo sostenible • La arquitectura y diseño emergen
  80. 80. jorge.abad@gmail.com Ágil no es hacer lo que se quiera • … ni tampoco programación heroica
  81. 81. jorge.abad@gmail.com
  82. 82. jorge.abad@gmail.com La magia no existe • Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ” • Dan visibilidad y transparencia desde el principio, aunque no resuelven todos los problemas. • No ser extremista, usar lo que te funcione • Se recomienda primero usar todo, luego hacer modificaciones. Cuidado con “Scrum but…”
  83. 83. El juego de la estimación
  84. 84. jorge.abad@gmail.com Poker Game • Planificación de póquer es una variación del método Delphi. • Es simple, se burla y los resultados de estim • Planificación de póquer se utiliza para estimar el esfuerzo o el tamaño relativo de las tareas en el desarrollo de software de manera fiable. • Los miembros del equipo del proyecto se reúnen y en unas pocas rondas mediante el Poker Game llegan a un consenso sobre el tamaño de cada tema o tarea.
  85. 85. jorge.abad@gmail.com La baraja de Cartas • Cada juevo de cartas incluye los números 0, (0,5), 1, 2, 3, 5, 8, 13, 20, 40, 100, y, a veces, un café tarjeta. • Cada miembro del equipo necesita una baraja de cartas
  86. 86. jorge.abad@gmail.com La reunión de planificación (1) • Al comienzo de la planificación de póquer, cada estimador se le da un mazo de cartas. • Para cada Historia de Usuario o tema que se va a estimar, un moderador lee la descripción. • El moderador suele ser el propietario del producto o una analista. Sin embargo, el moderador puede ser cualquier persona, ya que no hay privilegio especial asociado con el papel.
  87. 87. jorge.abad@gmail.com La reunión de planificación (2) • El Dueño del producto (Product Owner) responde todas las preguntas que tienen los estimadores. • Después de todas las preguntas cada estimador selecciona una carta de forma secreta e individual. • Las tarjetas no se muestran hasta que todos hayan hecho su estimación. Luego todos muestran al mismo tiempo la carta elegida • El grupo puede discutir la historia y sus estimaciones durante unos minutos más. Principalmente se indaga a las personas que están lejanas de la media que explique su posición. • Tras el debate se hace otra ronda de estimacion en privado.
  88. 88. jorge.abad@gmail.com La reunión de planificación (3) • Valores altos de tiempo implican o Baja granularidad o Alta complejidad o  se recomienda en lo posible dividir en tareas más pequeñas. • Si sale (?) Implica que no se tiene idea de que se esta hablando • Si sale la taza de café, indica que la persona esta casada.
  89. 89. jorge.abad@gmail.com Resultados • En muchos casos, las estimaciones convergen en la segunda ronda. En caso contrario se debe repetir el proceso. • El objetivo es converger a una única estimación.
  90. 90. Historia de usuarios Fuente Wikipedia
  91. 91. jorge.abad@gmail.com Historias de Usuario • Una historia de usuario es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.
  92. 92. jorge.abad@gmail.com Historias de Usuario • Las historias de usuario son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requerimientos cambiantes.
  93. 93. jorge.abad@gmail.com Características • Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes. • Negociables: La historia en si misma no lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación. • Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador. • Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto. • Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia. • Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.
  94. 94. jorge.abad@gmail.com Características • Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio? Por ello, algunos autores[1] recomiendan redactar las historias de usuario según el formato: • Como (rol) quiero (algo) para poder (beneficio). • Adicionalmente se debe plasmar los CRITERIOS DE ACEPTACIÓN.
  95. 95. jorge.abad@gmail.com Beneficios • Al ser muy corta esta representa requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas) • Necesitan poco mantenimiento • Mantienen una relación cercana con el cliente • Permite dividir los proyectos en pequeñas entregas • Permite estimar fácilmente el esfuerzo de desarrollo • Es ideal para proyectos con requerimientos volátiles o no muy claros
  96. 96. jorge.abad@gmail.com Limitaciones • Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contrato • Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso • Podría resultar difícil escalar a proyectos grandes • Requiere desarrolladores muy competentes • Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contrato • Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso • Podría resultar difícil escalar a proyectos grandes • Requiere desarrolladores muy competentes
  97. 97. jorge.abad@gmail.com Un enfoque BDD (Behavior Driven Development) • Title (one line describing the story) • • Narrative: • As a [role] • I want [feature] • So that [benefit] • • Acceptance Criteria: (presented as Scenarios) • • Scenario 1: Title • Given [context] • And [some more context]... • When [event] • Then [outcome] • And [another outcome]... • • Scenario 2: ... 09/08/2014 104 Fuente: http://dannorth.net/whats-in-a-story/
  98. 98. jorge.abad@gmail.com Ejemplo BDD • Scenario 1: Account has sufficient funds • Given the account balance is $100 • And the card is valid • And the machine contains enough money • When the Account Holder requests $20 • Then the ATM should dispense $20 • And the account balance should be $80 • And the card should be returned 09/08/2014 105 • Scenario 2: Account has insufficient funds • Given the account balance is $10 • And the card is valid • And the machine contains enough money • When the Account Holder requests $20 • Then the ATM should not dispense any money • And the ATM should say there are insufficient funds • And the account balance should be $20 • And the card should be returned Story: Account Holder withdraws cash As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed • Scenario 3: Card has been disabled • Given the card is disabled • When the Account Holder requests $20 • Then the ATM should retain the card • And the ATM should say the card has been retained Fuente: http://dannorth.net/whats-in-a-story/
  99. 99. jorge.abad@gmail.com Aviso de Copyright • Usted es libre de: o Compartir- copiar, distribuir y trasmitir el trabajo o Modificar- adaptar el trabajo • Bajo las siguientes condiciones o Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo). • Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor. • Para más información ver http://creativecommons.org/licenses/by/3.0/
  100. 100. jorge.abad@gmail.com Información de Contacto Presentado por: Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 (office)
  101. 101. jorge.abad@gmail.com Tomado de: • Una introducción a Scrum - Ernesto Grafeuille. • Enriquecido y Modificado por: Jorge H. Abad L. – jorge.abad@gmail.com o Blogs: • http://lecciones-aprendidas.blogspot.com/ • http://ing-sw.blogspot.com/

×