1. “El emperador no tiene traje” Metodologías Ágiles en el Desarrollo de Software Danijel Arsenovski
2. Sobre el orador Nombre: Danijel Arsenovski Experiencia: programador, desarrollador, arquitecto de software, autor etc.
3. ¿Hay algún problema con desarrollo de Software? 2009 Standish Group CHAOS Report (para EE. UU.) 1968: “Crisis de software” 1995: Standish Group CHAOS Report (para EE. UU.)
11. La respuesta al cambio, por encima del seguimiento de un plan.Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
12. Principios del Manifiesto Ágil Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
13. Principios del Manifiesto Ágil La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
14. Metodologías tradicionales vs. metodologías ágiles Predictivo vs. Adaptivo División de trabajo vs. equipos cros-funcionales Equipos de tipo control y comando vs. equipos autogestionados Google trends: “CMMI” – rojo vs. “Agile Development” - azúl
15. Metodologías Ágiles Programación Extrema o XP (Extreme Programming) implica siguientes Prácticas Ágiles Propiedad común de código fuente Programación en Pareja TDD Integración continua y construcción automatizada, Refactorización KISS 40 horas de trabajo por semana
16. Metodologías Ágiles Lean “Muda” (Eliminar basura) Decida lo más tarde posible Scrum Muy popular Ofrece certificaciones Scrum Master no tiene que saber programar Software Craftmanship “raising the bar” Para un software bien hecho Crystal
17. Una Iteración Ágil 1 o 2 semanas de duración (en pasado 3 semanas, hasta 1 mes) Reunión de planificación Historias de usuarios Backlog (listado de tareas) para la iteración Reuniones de avance diarias (”Daily Scrum”) de 15 min: Que ha hecho ayer Que pretendo hacer hoy Que se impone Final de entrega Reunión de aceptación con el cliente Reunión de reflexión Entrega de software operativo Iteración de duración fija (en caso que una tarea no se termina, se deja para la próxima iteración)
18.
19. Prácticas de Programación Ágil Propiedad común de código fuente Construcción automatizada e integración continua Programación en pareja (Pair programming) Desarrollo guiado por pruebas o TDD (Test Driven Development) Refactorización (Refactoring) Excelencia en programación y aprendizaje continuo
20. ¿Cómo implantar metodología ágil dentro de un equipo? Motivación Hay que convencer Gerencia de la empresa Clientes Partir con clientes con cuales se han desarrollado relaciones de confianza Equipo (programadores, jefes de proyecto etc.) Partir con proyectos internos Partir con las practicas, por ejemplo Integración Continua
21. ¿Fracasan proyectos ágiles? ¡Espectacularmente! “La metodología es solamente tan buena como las personas que la llevan a cabo” http://www.infoq.com/presentations/A-Story-of-Project-Failure-Mitch-Lacey
22.
23. Busca aunar a los tecnólogos innovadores de Chile que
