FACCI METODOLOGIAS AGILES

844 views
748 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
844
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
46
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

FACCI METODOLOGIAS AGILES

  1. 1. “Beneficios del Uso de Metodologías en el Desarrollo de Proyectos”
  2. 2.  ¿Podré cumplir con los plazos?  ¿Estaré dentro de lo presupuestado?  ¿El cliente quedará satisfecho? Las Metodologías pueden ser la ayuda que necesitamos, si podemos usarlas correctamente !!
  3. 3. Metodologías ...
  4. 4. ¿Qué es una Metodología ... Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente.
  5. 5. Metodología Tradicional Existen hace mucho tiempo, no han sido exitosas porque son muy burócratas, se han orientado al documento más que a los resultados.
  6. 6. Metodología Ágil Son la justa medida entre “ningún proceso” y “demasiado proceso”, proporcionando simplemente “suficiente proceso” para que el esfuerzo valga la pena !!!
  7. 7. Metodologías Ágiles
  8. 8.  Las Metodologías Ágiles (AMs) valoran:  Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas  Desarrollar software que funciona más que conseguir una buena documentación  Minimalismo respecto del modelado y la documentación del sistema  La colaboración con el cliente más que la negociación de un contrato  Responder a los cambios más que seguir estrictamente una planificación
  9. 9.  Dificultad para implantar metodologías tradicionales.  Una solución a medida para un segmento importante de proyectos de desarrollo de software  “Aceptar el cambio” ...
  10. 10. Tradicionales  Grandes  Con requerimientos estables  Aplicaciones críticas  Grandes equipos de desarrollo  Equipo de desarrollo distribuidos geográficamente Agiles  Ambientes dinámicos, con equipos de trabajo pequeños y produciendo aplicaciones no críticas  Requerimientos desconocidos o inestables, garantizando un menor riesgo ante la posibilidad de cambio en los requerimientos
  11. 11. Costo del cambio tiempo Tradicional Suposición AMs
  12. 12. Principios: 1. La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor 2. Dar la bienvenida a los cambios. Los AMs capturan los cambios para que el cliente tenga una ventaja competitiva 3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente
  13. 13. 8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante 9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad 10. La simplicidad es esencial 11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos 12. En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento
  14. 14. Metodología Ágil Metodología No Ágil Pocos Artefactos Más Artefactos Pocos Roles Más Roles No existe un contrato tradicional o al menos es bastante flexible Existe un contrato prefijado Cliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio Grupos grandes Menos énfasis en la arquitectura La arquitectura es esencial
  15. 15.  Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org  SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com  DSDM (Dynamic Systems Development Method), www.dsdm.org  Lean Programming, Mary Poppendieck, www.poppendieck.com  FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd  Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com  Adaptative Software Development, Jim Highsmith www.adaptivesd.com
  16. 16. eXtreme Programming
  17. 17.  Metodología liviana de desarrollo de software  Conjunto de practicas y reglas empleadas para desarrollar software  Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes  Originada en el proyecto C3 para Chrysler  En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo
  18. 18.  “Haz la cosa mas simple posible que funcione”  “Mantén el sistema en la condición mas simple posible”
  19. 19.  El cliente es parte del equipo de desarrollo  Comunicación entre gestión y desarrollo  Comunicación entre desarrolladores
  20. 20.  Velocidad, pero además calidad  Testeo continuo a través de todo el proceso  Testeo como herramienta de especificación y desarrollo  Testeo como garantía de integridad del código frente a cambios
  21. 21.  Reacción frente a los cambios
  22. 22. Prototipo arquitectónico Planificación de entregas Iteración Tests de aceptación Pequeñas entregas Historias de usuario Metáfora de sistema Prototipo requerimientos Estimación incierta Estimación confiable Plan de entregas Versión mas reciente Aprobación del cliente Escenarios de testeo Historias nuevas Velocidad del proyecto Próxima iteración bugs
  23. 23. Próxima iteración Planificación de iteración Desarrollo Versión mas reciente Velocidad de proyecto Plan de iteración Plan de entregas Bugs Historias de usuario Tests de aceptación fallados Funcionalidades nuevas Corrección de bugs Día a día Historias nuevas, Velocidad de proyecto Aprender y comunicar
  24. 24. Corrección de bugs Reunión de pie Manejo colectivo del software Próxima tarea o test de aceptación fallido Plan de iteración Día a día tareas Tests de aceptación fallados Tests de unidad pasados al 100% Test de aceptación aprobado Tareas sin terminar Demasiado por hacer Nueva funcionalidad Aprender y comunicar Programación en pares Reconstrucción de código
  25. 25. Próxima tarea o test de aceptación Creación de unidad de testeo Programación en pares 100% de unidades de testeo pasados Pares Unidad de testeo fallida Mover Gente Se necesita ayuda Cambio de par Unidad de testeo aprobada Código simple Código complejo Reconstrucción despiadada Ejecutar todas las unidades de testeo Test de aceptación aprobado Ejecutar test de aceptación fallados
  26. 26.  Proceso de planificación  Entregas pequeñas  Metáfora del sistema  Diseño simple  Testeo  Reconstrucción  Programación en pares  Propiedad colectiva  Integración continua  Semana de 40 horas  Cliente siempre disponible
  27. 27. SCRUM
  28. 28.  Scrum es una metodología ágil de desarrollo de software.  Ken Schwaber y Jeff Sutherland fueron los precursores de este método demostrando ampliamente su valía en proyectos de gran envergadura con un alto número de personal involucrado es su consecución.
  29. 29.  Desarrollo de software por medio de iteraciones (Sprints).  Indicado para proyectos con un rápido cambio de requerimientos.  Gran protagonismo de reuniones a lo largo del proyecto.
  30. 30.  Product Backlog.  Sprint Backlog.  Spring Planning meeting.  Revisión de Sprint.
  31. 31.  Propietario del producto.  Usuarios del producto.  Scrum master.  Equipo scrum.
  32. 32.  Base del desarrollo en Scrum.  Periodo mensual donde se llevan a cabo una serie de tareas previamente establecidas.
  33. 33.  Lista de las tareas a realizar durante todo el proyecto.  No es una lista fija se puede eliminar o añadir tareas conforme avance el proyecto.  Se prioriza las tareas según los requisitos de los usuarios o del propietario de la aplicación.
  34. 34.  Reunión que se realiza antes de cada Sprint.  Se hace conjuntamente con el Propietario del producto el Scrum Master y el equipo Scrum.  Enfocar la reunión hacia los requisitos mas prioritarios.
  35. 35.  Después de solventar cualquier tipo de duda sobre los requisitos se pasa a decidir las tareas a desarrollar en el Sprint.
  36. 36.  Lista elaborada por el equipo Scrum.  Se especifican las tareas que se van a desarrollar a lo largo del Sprint.  Tiene gran importancia ser realista en la elaboración del Sprint Backlog para poder finalizar las tareas acordadas.
  37. 37.  Se realiza al final de cada Sprint.  Se deben reunir el propietario de la aplicación los usuarios así como el Scrum Master y su equipo , además también es recomendable que acudan ingenieros de otros proyectos para dar su punto de vista.
  38. 38. VENTAJAS:  Programación organizada  Menor taza de errores  Satisfacción del programador DESVENTAJAS:  Es recomendable emplearlo solo en proyectos a corto plazo
  39. 39. SEMEJANZAS  Es un Agile Manifiesto.  Existen una Interacción de Usuario a Usuario.  Realizan los Proyectos en un Corto Periodo de Tiempo.  Trabajan en Equipo.
  40. 40. SCRUM XP (EXTREME PROGRAMMING) Las iteraciones de entregas son de 2 a 4 semanas. Las iteraciones de entrega son a 1 a 3 semanas. Lo que se termina, funciona y este bien, se aparta y ya no se toca. Las tareas q se van entregando a los diferentes clientes son susceptibles a las modificaciones. Cada miembro del Scrum Team trabaja de forma individual. Los miembros programan en pareja en un proyecto XP. El Scrum Team trata de seguir el orden de prioridad que marca el Product Owner, en el Sprint Backlog pueden ser modificadas. El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definidas por el cliente. Esta basada en la administración del proyecto. Se centra mas en la propia programación o creación del producto.
  41. 41. HISTORIA DE USUARIOS - EJEMPLOS Historia de Usuario Número: 1 Nombre :Ingreso de Calificaciones Modificación de Historia de Usuario (Nro. y Nombre): Usuario/Rol: Secretaria Iteración/Sprint Asignada: 1 Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: Alta (Alto / Medio / Bajo) Descripción: Permite el ingreso de las calificaciones de cada parcial de los estudiantes que se encuentran matriculados tanto en la modalidad semestral como anual Observaciones: Actualmente la información es llevada de maneja semi automática en hojas de cálculo.
  42. 42. Historia de usuario Numero:2 Nombre: Operaciones de corte Usuario/Rol: Jefe de producción Modificación de historia numero: Iteración asignada: 2 Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: Medio (Alto / Medio / Bajo) Descripción: El jefe de producción tendrá la tarea de marcar el producto al ser finalizado en esta área, para que pueda ser pasado por el horno de templado, es necesario llevar el control porque una vez templado el vidrio no puede ser modificado Observaciones: HISTORIA DE USUARIOS - EJEMPLOS
  43. 43. HISTORIA DE USUARIOS - EJEMPLOS Historia de usuario Numero:3 Nombre: Generación de reportes Usuario/Rol: Ingeniero de templado Modificación de historia numero: Iteración/Sprint asignada: 2 Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: Medio (Alto / Medio / Bajo) Descripción: El ingeniero de templado tendrá la opción de marcar los vidrios una vez hayan sido procesados por el horno de templado para dar orden de culminación y entrega del producto. Observaciones:

×