Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 39 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Scrum (20)

Anuncio

Más reciente (20)

Anuncio

Scrum

  1. 1. ¿Por que fallan los proyectos? ¿Por qué fallan los suyos?
  2. 2. La cruda realidad
  3. 3. Causa de Fracasos en los Proyectos  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
  4. 4. ¿VIAJARÍA USTED EN UN AVIÓN AL QUE USTED LE ESCRIBIÓ EL SOFTWARE DE NAVEGACIÓN?
  5. 5. 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/
  6. 6. 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/
  7. 7. 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/
  8. 8. Valores  Compromiso  Enfoque y Foco  Apertura y transparencia  Respeto  Coraje
  9. 9. Objetivo: Pasar a la otra orilla a pie sin mojarse (sin usar un puente, etc, etc.)
  10. 10. Crecimiento orgánico (iterativo e incremental) Una mujer con una pradera atrás
  11. 11. Diferencias entre enfoque iterativo y enfoque orgánico (iterativo e incremental)
  12. 12. SCRUM “El Arte de Amar los Lunes”. Alan Cyment
  13. 13.  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:  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.  Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.  El mercado exige ciclos de desarrollo más cortos.
  14. 14. 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
  15. 15. 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
  16. 16. 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”
  17. 17. Sprints  En Scrum los proyectos avanzan en una serie de “Sprints”  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
  18. 18. Scrum Framework •Product owner •ScrumMaster •Team Roles •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  19. 19. Scrum framework •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos •Product owner •ScrumMaster •Team Roles
  20. 20. 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
  21. 21. Product Owner El espiritu de Scrum. Alan Cyment
  22. 22. 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
  23. 23. 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
  24. 24. Interacción entre los roles Fuente: El espiritu de Scrum. Alan Cyment
  25. 25. •Product owner •ScrumMaster •Team Roles Scrum Framework •Product backlog •Sprint backlog •Burndown charts Artefactos •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones
  26. 26. 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
  27. 27. Planificación del Sprint  El equipo selecciona los temas a partir del Product Backlog 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 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)
  28. 28. 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 Product Owner, pueden hablar  Ayuda a evitar otras reuniones innecesarias
  29. 29. 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
  30. 30. 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
  31. 31. 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  ScrumMaster  Product owner  Equipo  Posiblemente clientes y otros
  32. 32. Retrospective  Por lo general se evalua Felicidad Productividad Calidad Esto es sólo una de las muchas maneras de hacer una retrospectiva.
  33. 33. •Product owner •ScrumMaster •Team Roles Scrum framework •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  34. 34. Ejemplo de Product Backlog
  35. 35. 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
  36. 36. Scrum estar acompañado de buenas prácticas de ingeniería. Scrum = reglas + espíritu + buenas prácticas

×