METODOLOGÍAS ÁGILES EN TI

44

Click here to load reader

description

Metodologías ágiles en TI.

Transcript of METODOLOGÍAS ÁGILES EN TI

Page 1: METODOLOGÍAS ÁGILES EN TI

METODOLOGÍAS ÁGILES

Integrantes• Alexi Espinoza• Humbert Ramirez• Francisco Sánchez• Jenny Maza• Ricardo Vilela

Page 2: METODOLOGÍAS ÁGILES EN TI

METODOLOGÍAS ÁGILES EN TIINTRODUCCIÓ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.

Page 3: METODOLOGÍAS ÁGILES EN TI

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.

Page 4: METODOLOGÍAS ÁGILES EN TI

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)

Page 5: METODOLOGÍAS ÁGILES EN TI

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.

Page 6: METODOLOGÍAS ÁGILES EN TI

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).

Page 7: METODOLOGÍAS ÁGILES EN TI

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.

Page 8: METODOLOGÍAS ÁGILES EN TI

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 ÁgilSe 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.

Page 9: METODOLOGÍAS ÁGILES EN TI

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.

Page 10: METODOLOGÍAS ÁGILES EN TI

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.

Page 11: METODOLOGÍAS ÁGILES EN TI

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.

Page 12: METODOLOGÍAS ÁGILES EN TI

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

Page 13: METODOLOGÍAS ÁGILES EN TI

Algunas Metodologías Ágiles de Desarrollo de SW

Metodología Acrónimo Creación Tipo de modelo CaracterísticaAdaptive SoftwareDevelopment

ASD Highsmith 2000 Prácticas + ciclo de vida

Inspirado en sistemasadaptativos complejos

Agile Modeling

AM Ambler 2002 Metodología basada en laprá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 conartefactos RUP

Page 14: METODOLOGÍAS ÁGILES EN TI

Metodología Acrónimo Creación Tipo de modelo CaracterísticaDynamic SolutionsDelivery Model

DSDM Stapleton 1997 Framework/modelo deciclo de vida

Creado por 16 expertosen RAD

EvolutionaryProjectManagement

EVO Gilb 1976 Framework adaptativo

Primer método ágil existente

eXtremeProgramming

XP Beck 1999 Disciplina en prácticas de ingeniería

Método ágil radical

Feature-DrivenDevelopment

FDD De Luca & Coad1998Palmer & Felsing2002

Metodología Método ágil de diseño yconstrucción

Algunas Metodologías Ágiles de Desarrollo de SW

Page 15: METODOLOGÍAS ÁGILES EN TI

Metodología Acrónimo Creación Tipo de modelo CaracterísticaLean Development

LD Charette 2001,Mary y TomPoppendieck

Forma de pensar – modelologístico

Metodología basada enprocesos

Rapid Development

RAD McConnell 1996 Survey de técnicas ymodelos

Selección de best practices, no método

Microsoft SolutionsFramework

MSF Microsoft 1994 Lineamientos, disciplinas,prácticas

Framework dedesarrollo de soluciones

Scrum Scrum Sutherland 1994Schwaber 1995

Proceso – framework demanagement

Complemento de otrosmétodos, ágiles o no

Algunas Metodologías Ágiles de Desarrollo de SW

Page 16: METODOLOGÍAS ÁGILES EN TI

Beneficios de las Metodologías Ágiles

Simplificación de los procesos Calidad mejorada Mejor productividad Mejor gestión del riesgo Aprovecha las inversiones realizadas

Page 17: METODOLOGÍAS ÁGILES EN TI

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.

Page 18: METODOLOGÍAS ÁGILES EN TI

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)

Page 19: METODOLOGÍAS ÁGILES EN TI

Cómo funciona?

Page 20: METODOLOGÍAS ÁGILES EN TI

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.

Page 21: METODOLOGÍAS ÁGILES EN TI

Roles y responsabilidades Cliente Programador Encargado de pruebas Encargado de seguimiento Coach o entrenador Consultor Gestor

Page 22: METODOLOGÍAS ÁGILES EN TI

Prácticas de XP (Claves de éxito)El juego de la planificaciónEntregas pequeñasMetáforaDiseño simplePruebasRefactorizaciónProgramación en parejasPropiedad colectiva del códigoIntegración continúa40 horas por semanaCliente in-situEstándares de programación

Page 23: METODOLOGÍAS ÁGILES EN TI

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.

Page 24: METODOLOGÍAS ÁGILES EN TI

ProcesoFDD 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.

Page 25: METODOLOGÍAS ÁGILES EN TI

RolesRoles Claves: Administrador del Proyecto Arquitecto jefe Manager de desarrollo Programador jefe Propietarios de clases Expertos de dominio

Page 26: METODOLOGÍAS ÁGILES EN TI

RolesRoles de Soporte:Administrador de entregaAbogado/Gurú del LenguajeIngeniero de construcciónHerramientista (Toolsmith)Administrador del sistemaRoles Adicionales: Verificadores (Tester) Encargados del despliegue Escritores técnicos

Page 27: METODOLOGÍAS ÁGILES EN TI

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

Page 28: METODOLOGÍAS ÁGILES EN TI

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

Page 29: METODOLOGÍAS ÁGILES EN TI

SCRUMPROCESO

Page 30: METODOLOGÍAS ÁGILES EN TI

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.

Page 31: METODOLOGÍAS ÁGILES EN TI

ASP (ADAPTIVE SOFTWARE DEVELOPMENT)

Page 32: METODOLOGÍAS ÁGILES EN TI

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”.

Page 33: METODOLOGÍAS ÁGILES EN TI

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.

Page 34: METODOLOGÍAS ÁGILES EN TI

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

Page 35: METODOLOGÍAS ÁGILES EN TI

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.

Page 36: METODOLOGÍAS ÁGILES EN TI

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.

Page 37: METODOLOGÍAS ÁGILES EN TI

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

Page 38: METODOLOGÍAS ÁGILES EN TI

OrigenLa 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.

KANBANPalabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y Ban corresponde a “tarjeta”.

VentajasFá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”

Page 39: METODOLOGÍAS ÁGILES EN TI

Principios KANBAN Calidad garantizadaTodo 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 desperdicioBasado 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 continuaKANBAN 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.

FlexibilidadLo 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).

Page 40: METODOLOGÍAS ÁGILES EN TI

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.

Page 41: METODOLOGÍAS ÁGILES EN TI

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).

Page 42: METODOLOGÍAS ÁGILES EN TI

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.

Page 43: METODOLOGÍAS ÁGILES EN TI

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

Page 44: METODOLOGÍAS ÁGILES EN TI

Diferencias entre SCRUM y KANBANSCRUM KANBANLas 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 estarmarcadas por la previsión de loseventos en lugar de tener un tiempopre-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 opcionalesNo 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.