Metodologías ágiles en TI.

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.