METODOLOGÍAS ÁGILES

  • 866 views
Uploaded on

Metodologías ágiles.

Metodologías ágiles.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
866
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
71
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Integrantes • Alexi Espinoza • Humbert Ramirez • Francisco Sánchez • Jenny Maza • Ricardo Vilela
  • 2. METODOLOGÍAS ÁGILES EN TI INTRODUCCIÓN Sabemos que…  Los procesos de desarrollo llevan asociados un mayor énfasis en el control del proceso mismo.  Existe una gran rigurosidad en la definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. El esquema tradicional en el que se basa los puntos anteriores ha demostrado ser efectivo y necesario en proyectos de gran tamaño (tiempo y recursos) en donde por lo general se exige un alto grado de análisis en el proceso.
  • 3. Sin embargo… El enfoque anterior no resulta ser el más adecuado:  Los proyectos que actualmente surgen presentan un entorno del sistema muy cambiante.  Ahora se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.  Existen mayores restricciones de tiempo y flexibilidad. Ante esto las metodologías ágiles emergen como una potencial respuesta para llenar ese vacío metodológico.  Se constituyen en una alternativa de solución a medida para ese entorno cambiante.  Aportan una elevada simplificación en donde a pesar de ello no renuncian a las prácticas esenciales para asegurar la calidad del producto o servicio.
  • 4. ANTECEDENTES  Muchas ideas que se plantean en las metodologías ágiles fueron reflejadas por Frederick Phillips Brooks en su mítico libro, The Mythical Man Month y en gran parte responden al sentido común.  En el manifiesto de Edsger Dijkstra se hacía un llamado a la disciplina concretándose en el ya famoso Manifest for Agile Software Development, una petición por la atenuación de los procesos en pro de las personas.  * Hacia la década de los 90’ surgió un enfoque revolucionario… En la comunidad de Ingeniería de Software fue conocido como RAD (Rapid Application Development)
  • 5. RAD (Rapid Application Development) Caracterizado por:  Un entorno de desarrollo altamente productivo.  Grupos pequeños de programadores.  Herramientas que generaban código en forma automática tomando como entradas sintaxis de alto nivel. En febrero de 2001 nace el término ‘ágil’ (Utah-EEUU) aplicado al desarrollo de software. Al mismo tiempo se creó The Agile Alliance dedicada a:  Promover los conceptos relacionados con el desarrollo ágil de software.  Ayudar a las organizaciones para que adopten dichos conceptos.
  • 6. Podemos indicar entonces que… La aparición de las metodologías ágiles son asociadas a todo un conjunto de factores tales como:  “Plumbing”, en definitiva describe la falta de agilidad de los modelos de desarrollo existente.  Las metodologías existentes en aquel momento no cumplieron las expectativas planteadas inicialmente.  Explosión de la red y las aplicaciones.  Movimiento open source. I. Y qué es ser ágil?... Jim Highsmith dice que ser Agile significa ser capaz de “Deliver quickly, Change quickly, Change often” (Entregar rápido, cambiar rápido, cambiar con frecuencia).
  • 7. II. Y qué es ser ágil?...  Se centra en la interacción, comunicación, y en la reducción de la creación de artefactos intermedios  Reconocer a las personas como principales patrocinadoras para que un proyecto triunfe  Dar una orientación a la efectividad y la manejabilidad. Es algo más que seguir las guías que se suponen hacen un proyecto ágil; la verdadera agilidad es más que un conjunto de prácticas, es un estado de ánimo.
  • 8. El Manifiesto Ágil Se acuñó el término “Métodos Ágiles” (Salt Lake City) para definir los métodos que estaban surgiendo como alternativa a las metodologías formales. Valores del Desarrollo Ágil Se basa en 04 principios fundamentales en los que se valora:  Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.  Desarrollar software que funciona más que conseguir una buena documentación.  La colaboración con el cliente más que la negociación de un contrato.  Responder a los cambios más que seguir estrictamente un plan.
  • 9. I. Doce principios del Manifiesto… 1. 1. La prioridad es satisfacer al cliente. 2. 2. Dar la bienvenida a los cambios. 3. 3. Entregar frecuentemente software (en el menor intervalo de tiempo posible entre entregas). 4. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. 5. Construir el proyecto en torno a individuos motivados. 6. 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo.
  • 10. II. Doce principios del Manifiesto… 7. El software que funciona es la medida principal de progreso. 8. Los procesos ágiles promueven un desarrollo sostenible. 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 a cómo llegar a ser más efectivo.
  • 11. I. Metodologías Ágiles versus Metodologías Tradicionales Metodologías Ágiles Metodologías Tradicionales Basadas en heurísticas provenientes de prácticas de producción de código. Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo. Especialmente preparadas para cambios durante el proyecto. Cierta resistencia a los cambios. Impuestas internamente (por el equipo). Impuestas externamente. Proceso menos controlado, con pocos principios. Proceso mucho más controlado, con numerosas políticas/normas. No existe contrato tradicional o al menos es bastante flexible Existe un contrato prefijado.
  • 12. Metodologías Ágiles Metodologías Tradicionales El cliente es parte del equipo de desarrollo. El cliente interactúa con el equipo de desarrollo mediante reuniones. Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio. Grupos grandes y posiblemente distribuidos. Pocos artefactos. Más artefactos. Pocos roles. Más roles. Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se expresa mediante modelos. I. Metodologías Ágiles versus Metodologías Tradicionales
  • 13. Algunas Metodologías Ágiles de Desarrollo de SW Metodología Acrónimo Creación Tipo de modelo Característica Adaptive Software Development ASD Highsmith 2000 Prácticas + ciclo de vida Inspirado en sistemas adaptativos complejos Agile Modeling AM Ambler 2002 Metodología basada en la práctica Suministra modelado ágil a otros métodos Cristal Methods CM Cockbum 1998 Familia de metodologías Metodología ágil con énfasis en modelo Agile RUP dX Booch, Martin, Newkirk 1998 Framework/Disciplina XP dado vuelta con artefactos RUP
  • 14. Metodología Acrónimo Creación Tipo de modelo Característica Dynamic Solutions Delivery Model DSDM Stapleton 1997 Framework/modelo de ciclo de vida Creado por 16 expertos en RAD Evolutionary Project Management EVO Gilb 1976 Framework adaptativo Primer método ágil existente eXtreme Programming XP Beck 1999 Disciplina en prácticas de ingeniería Método ágil radical Feature- Driven Development FDD De Luca & Coad 1998 Palmer & Felsing 2002 Metodología Método ágil de diseño y construcción Algunas Metodologías Ágiles de Desarrollo de SW
  • 15. Metodología Acrónimo Creación Tipo de modelo Característica Lean Development LD Charette 2001, Mary y Tom Poppendieck Forma de pensar – modelo logístico Metodología basada en procesos Rapid Development RAD McConnell 1996 Survey de técnicas y modelos Selección de best practices, no método Microsoft Solutions Framework MSF Microsoft 1994 Lineamientos, disciplinas, prácticas Framework de desarrollo de soluciones Scrum Scrum Sutherland 1994 Schwaber 1995 Proceso – framework de management Complemento de otros métodos, ágiles o no Algunas Metodologías Ágiles de Desarrollo de SW
  • 16. Beneficios de las Metodologías Ágiles  Simplificación de los procesos  Calidad mejorada  Mejor productividad  Mejor gestión del riesgo  Aprovecha las inversiones realizadas
  • 17. XP- EXTREME PROGRAMMING Qué es?  Es una metodología ágil bien estructurada.  Se centra en potenciar las relaciones interpersonales, promoviendo el continuo trabajo en equipo.  Un enfoque refrescante en contraposición a la metodologías tradicionales.
  • 18. Las cuatro claves de XP  Comunicación  Simplicidad  Retroalimentación (Feedback)  Coraje …Y cuando usar XP?  Proyectos de duración no muy larga con requisitos imprecisos y muy cambiantes.  El riesgo del proyecto es muy alto.  Equipos de desarrollo pequeños (2 a 12 personas)
  • 19. Cómo funciona?
  • 20. Historias de Usuario  Utilizadas para especificar los requisitos del software.  Parecidas a los casos de uso, pero más relajadas.  Son redactadas por el cliente, no por el equipo de desarrollo.  Sirven para crear las pruebas de aceptación.  A cada historia se le estima un tiempo.  Tarjetas de papel que contienen: número de historia, fecha, tipo de actividad, prueba funcional, prioridad, estimación técnica, descripción.
  • 21. Roles y responsabilidades  Cliente  Programador  Encargado de pruebas  Encargado de seguimiento  Coach o entrenador  Consultor  Gestor
  • 22. Prácticas de XP (Claves de éxito) El juego de la planificación Entregas pequeñas Metáfora Diseño simple Pruebas Refactorización Programación en parejas Propiedad colectiva del código Integración continúa 40 horas por semana Cliente in-situ Estándares de programación
  • 23. FDD – FEATURE DRIVEN DEVELOPMENT Fue desarrollado por Jeff De Luca y el viejo gurú de la orientación a objetos Peter Coad. Es una técnica de programación guiada por rasgos o características, centradas en el usuario, no en el programador. Los principios de FDD son pocos y simples:  Se requiere un sistema para construir sistemas si se pretende escalar a proyectos grandes.  Un proceso simple y bien definido trabaja mejor.  Los pasos de un proceso deben ser lógicos y su mérito inmediatamente obvio para cada miembro del equipo.  Vanagloriarse del proceso puede impedir el trabajo real.
  • 24. Proceso FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y una salida.
  • 25. Roles Roles Claves:  Administrador del Proyecto  Arquitecto jefe  Manager de desarrollo  Programador jefe  Propietarios de clases  Expertos de dominio
  • 26. Roles Roles de Soporte: Administrador de entrega Abogado/Gurú del Lenguaje Ingeniero de construcción Herramientista (Toolsmith) Administrador del sistema Roles Adicionales:  Verificadores (Tester)  Encargados del despliegue  Escritores técnicos
  • 27. SCRUM  Entrega parciales y regulares del producto final.  Aplicado proyecto complejos.  Resultados pronto  Es empleado para situaciones como: • Demoras en las entregas • Costos elevados • Calidad no aceptable • Rotación de los equipos alta
  • 28. SCRUM BENEFICIOS  Gestión regular de las expectativas del cliente  Resultados anticipados (“Time to market”)  Flexibilidad y adaptación  Retorno de la inversión (ROI)  Mitigación de Riesgos  Productividad y calidad  Alineamiento entre cliente y equipo.  Equipo motivado
  • 29. SCRUM PROCESO
  • 30. ASP (ADAPTIVE SOFTWARE DEVELOPMENT)  Desarrollo adaptable de software.  Se adapta al cambio  Trabaja bajo un ciclo especular - colaborar – aprender  Funcionamiento cíclico.  Aprende de los errores y vuelve a iniciar el ciclo de desarrollo.
  • 31. ASP (ADAPTIVE SOFTWARE DEVELOPMENT)
  • 32. Crystal Clear  Crystal Clear es la menor de la familia de metodologías Crystal desarrollada por el investigador de IBM el Dr. Alistair Cockbum.  El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad.  Crystal Clear está diseñada para ser utilizada por equipos de hasta ocho integrantes y en el desarrollo de sistemas cuyos posibles errores puedan causar una pérdida prudencial de dinero o de confort.  “Crystal Clear es una metodología centrada en el factor humano, donde un diseñador líder y de dos a siete desarrolladores más se encuentran juntos en un local grande o en locales adyacentes con radiadores de información como pizarras y diagramas bien visibles en la pared, teniendo acceso fácil a usuarios claves; eliminando las distracciones; entregando código funcional, testeado y utilizable en intervalos de uno a tres meses; reflexionando periódicamente y ajustando continuamente su estilo de trabajo”.
  • 33. Propiedades  Crystal Clear se centra en tres propiedades claves:  Efectuar entregas frecuentes.  Mejora reflexiva  Comunicación Osmótica.  Otras propiedades importantes son:  Confianza Personal  Foco en la tarea  Acceso Fácil a Usuarios Expertos.  Trabajo en ambiente técnico.
  • 34. Estrategias  Las estrategias que propone Crystal Clear son:  Exploración de 360º  Victoria Temprana  Esqueleto Ambulante  Re arquitectura Incremental  Radiadores de Información  Las tres primeras guían el camino del equipo durante los primeros momentos del desarrollo y las dos restantes pueden aplicarse durante todo el proyecto
  • 35. Técnicas  Las técnicas propuestas por Crystal Clear  Taller de Perfilación de la Metodología.  Talleres de Reflexión.  Planeación Rápida  Estimación Delfos  Reuniones diarias  Diseño de Interacciones Esenciales  Miniatura del Proceso  Programación Lado a Lado  Gráfico de Quemado.
  • 36. Roles nominados  En Crystal Clear existen ocho roles nominados  Patrocinador Ejecutivo  Usuario Embajador  Diseñador Líder  Diseñador – Programador  Experto del Negocio  Coordinador  Verificador  Escritor  Los cuatro primeros necesariamente deben ser desempeñados por personas distintas, mientras los restantes pueden ser roles adicionales asignados a algunos miembros del equipo.
  • 37. Ciclos de Crystal Clear  Crystal Clear define su proceso como un conjunto de ciclos anidados de diferentes duraciones. Cada ciclo tiene su propia secuencia, y pueden desarrollarse simultáneamente varias actividades pertenecientes a distintos ciclos. Crystal Clear posee siete ciclos:  Ciclo del Proyecto  Ciclos de Entrega  Ciclo de Iteración.  Ciclos Semanales  Ciclos Diarios  Ciclos de Integración
  • 38.  Origen La metodología KANBAN tiene su origen en los procesos de producción “just- in-time” (JIT) ideados por TOYOTA, en los que se utilizaban tarjetas para identificar necesidades de material en la cadena de producción.  KANBAN Palabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y Ban corresponde a “tarjeta”.  Ventajas Fácil de utilizar, actualizar y asumir por parte del equipo. Destaca por ser una técnica de gestión de las tareas muy visual, que permite ver a golpe de vista el estado de los proyectos, así como también pautar el desarrollo del trabajo de manera efectiva. KANBAN “Sistema de producción altamente efectivo y eficiente”
  • 39. Principios KANBAN  Calidad garantizada Todo lo que se hace debe salir bien a la primera, no hay margen de error. En KANBAN no se premia la rapidez, sino la calidad final de las tareas realizadas. Basado en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien a la primera.  Reducción del desperdicio Basado en hacer solamente lo justo y necesario, pero hacerlo bien. Supone la reducción de todo aquello que es superficial o secundario (principio YAGNI).  Mejora continua KANBAN no es simplemente un método de gestión, sino también un sistema de mejora en el desarrollo de proyectos, según los objetivos a alcanzar.  Flexibilidad Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas), pudiéndose priorizar aquellas tareas entrantes según las necesidades del momento (capacidad de dar respuesta a tareas imprevistas).
  • 40. Cómo configurar KANBAN? 1. Definir el flujo de trabajo de los proyectos  Debemos crear nuestro propio tablero, que deberá ser visible y accesible por parte de todos los miembros del equipo.  Cada una de las columnas corresponderá a un estado concreto del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada proyecto (p.e: diagnóstico, definición, programación, ejecución, testing, etc.).  A medida que se avanza, las nuevas tareas (mejoras, incidencias o nuevas funcionalidades) se acumulan en la sección inicial, de manera que en las reuniones periódicas con el cliente se priorizan y se colocan dentro de la sección que se estima oportuna.  No hay unas fases del ciclo de producción establecidas sino que se definirán según el caso en cuestión, o se establecerá un modelo aplicable genéricamente para cualquier proyecto de la organización.
  • 41. 2. Visualizar las fases del ciclo de producción Cada una de las tareas a realizar se escribe en un post-it y se pega en el tablero, en la fase que corresponda. La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada, en análisis, en diseño, etc.). Dichos post-its contienen la información básica para que el equipo sepa rápidamente la carga total de trabajo: descripción de la tarea con la estimación de horas. Se pueden emplear fotos para asignar responsables así como también usar tarjetas con distintas formas para poner observaciones o indicar bloqueos (cuando una tarea no puede hacerse porqué depende de otra).
  • 42. 3. Stop Starting, start finishing “Principal aporte de KANBAN: El trabajo en curso debe estar limitado y, por tanto, existe un número máximo de tareas a realizar en cada fase.”  Se trata de definir el máximo número de tareas que podemos tener en cada una de las fases (p.e: 3 tareas en la fase de planificación; 2, en la fase de desarrollo; una, en la fase de pruebas, etc.).  No se puede abrir una nueva tarea sin finalizar otra.  Se pretende dar respuesta al problema habitual de muchas empresas de tener muchas tareas abiertas pero con un ratio de finalización muy bajo. Aquí lo importante es que las tareas que se abran se cierren antes de empezar con la siguiente.
  • 43. 4. Control del Flujo  La metodología KANBAN no se aplica a un único proyecto, sino que mezcla tareas y proyectos.  Se mantiene a los trabajadores con un flujo de trabajo constante. Las tareas más importantes en cola para ser desarrolladas  Seguimiento pasivo para no tener que interrumpir al trabajador en cada momento. Nos permite hacer un seguimiento del trabajo realizado, almacenando la información que nos proporcionan las tarjetas
  • 44. Diferencias entre SCRUM y KANBAN SCRUM KANBAN Las iteraciones deben ser de tiempo fijo. El tiempo fijo en las iteraciones es opcional. La cadencia puede variar en función del plan del producto y la mejora del proceso. Pueden estar marcadas por la previsión de los eventos en lugar de tener un tiempo pre-fijado. El equipo asume un compromiso de trabajo por iteración El compromiso es opcional. La métrica por defecto para la planificación y la mejora del proceso es la Velocidad. La métrica por defecto para la planificación y la mejora del proceso es el Lead Time (tiempo de entrega o tiempo medio que tarda una petición en salir del ciclo) Los equipos deben ser multifuncionales. Los equipos pueden ser multifuncionales o especializados. Las funcionalidades deben dividirse en partes que puedan completarse en un sprint. No hay ninguna prescripción en cuanto al tamaño de las divisiones. Deben emplearse gráficos Burndown. No se prescriben diagramas de seguimiento concretos Se emplea una limitación WIP indirecta (por sprint). Se emplea una limitación WIP directa (marcada por el estado del trabajo). Se deben realizar estimaciones. Las estimaciones son opcionales No se pueden añadir tareas en medio de una iteración. Siempre que haya capacidad disponible, se pueden añadir tareas. La pila del sprint pertenece a un equipo determinado. Varios equipos o personas pueden compartir la misma pizarra Kanban. Se prescriben 3 roles (PP/SM/Equipo). No hay roles prescritos. En cada sprint se limpia el tablero de seguimiento. El tablero Kanban es persistente. La pila del producto debe estar priorizada. La priorización es opcional.