SEPG LA 2005 Presentation "Practicas Agiles En Mejora De Procesos"
111
Prácticas Ágiles en Mejora de Procesos Walter Ariel Risi Pragma Consultores [email protected] Miroslav Pavlovic Practia Consulting [email protected] m John Gómez Practia Consulting [email protected]
-
Upload
walter-risi -
Category
Documents
-
view
682 -
download
2
Transcript of SEPG LA 2005 Presentation "Practicas Agiles En Mejora De Procesos"
Prácticas Ágiles en Mejora de Procesos
Walter Ariel RisiPragma Consultores
Miroslav PavlovicPractia Consulting
John GómezPractia Consulting
Objetivos del Tutorial
• Mostrar como una correcta interpretación y buen uso de los principios y prácticas de las metodologías ágiles pueden potenciar las iniciativas de mejora de procesos.
• Introducir los conceptos básicos sobre lo ágil y desmitificar las posiciones radicales asumidas por promotores y detractores.
• A través de escenarios de uso reales, mostrar como los modelos rigurosos y los ágiles son complementarios.
Agenda
• Módulo 1: Introducción- Explica los conceptos básicos
detrás de las metodologías ágiles.• Módulo 2: Escenarios de
Aplicación- Explica como las metodologías
ágiles contribuyen a la mejora de los procesos de la organización, a través de escenarios provenientes de la experiencia de los autores.
• Módulo 3: ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil?- Explica cómo realizar un proyecto
de mejora basado en metodologías ágiles.
• Módulo 4: Conclusiones y Recomendaciones- Esboza algunas conclusiones sobre
lo visto en el curso, y brinda una serie de recomendaciones para el buen uso de las metodologías ágiles.
Prácticas Ágiles en Mejora de Procesos
IntroducciónEscenarios de Aplicación
¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil?Conclusiones y Recomendaciones
Índice del Módulo
• Introducción y Conceptos Básicos
• La Alianza Ágil• El Manifiesto Ágil• Orígenes y Precursores• Metodologías más
Conocidas• Mitos y Realidades• Algunas Conclusiones
El Dilema del Software
•Hoy en día, el software es una parte crítica de todo negocio
•Sin embargo, el desarrollo de software aún sufre de problemas como...
- Calidad insuficiente o muy variable
- Proyectos que exceden sus tiempos y costos
El Proceso al Rescate
• No es novedad que una forma de resolver los problemas de calidad (y otros) de un producto es mejorando la forma de construir tales productos.
• …o sea, mejorando los procesos.
• En una actividad humana como es el desarrollo software, esto es casi equivalente a mejorar la metodología que se sigue para construir los productos
Procesos y Metodologías
Con los fines mencionados han surgido gran cantidad de enfoques metodológicos a lo largo de los años:(Cascada, cascada desfasada, espiral, prototipos
incrementales, desarrollo por etapas, etc.)
¿Qué tienen en común los
anteriores enfoques?
Están inspirados en la producción
industrial
¿Y hay algo de malo en
ello?
¡No! sólo que requieren una
cierta predecibilidad
¡Lamentablemente, muchas veces el contexto de un proyecto es menos
predecible o estable que lo deseado!
El Surgimiento de la “Agilidad”
• Durante el trascurso de los años 90, varias personas se dieron cuenta de que las cosas estaban cambiando.
El ambiente cambiante y turbulento era cada vez más la regla que la excepción.
• Estas personas observaron la necesidad de desarrollar metodologías livianas y maniobrables, que pudieran operar en ese ambiente turbulento.
• A pesar de que los detalles de estas metodologías varían, todas comparten algunos principios comunes.
Estas metodologías son conocidas colectivamente hoy en día como
“metodologías ágiles”.
¿Qué es una Metodología Ágil?
• Las metodologías ágiles se entienden como un conjunto de metodologías para desarrollo de software surgidas en la década de los 90.
• Lo ágil se define (por los mismos “agilistas”) como la habilidad de responder de forma versátil al cambio para maximizar los beneficios
• Las metodologías ágiles varían en su forma de “responder al cambio”, pero en general comparten características como las siguientes- Usar procesos de construcción iterativos- Entregar software funcional lo más pronto
posible- Privilegiar el valor de la gente sobre el valor
del proceso- Fortalecer la comunicación y la colaboración
• Los valores y principios compartidos por toda metodología ágil fueron enunciados en el “manifiesto ágil”, por la “alianza ágil”.
La Alianza Ágil
• 17 promotores de los "procesos livianos" se reunieron en Utah (EEUU), a principios del 2001, a discutir que tenían en común.
- En primer lugar, acordaron que todos apuntaban sus esfuerzos a responder" al cambio.
• Acordaron que la palabra "ágil" ilustraba esto mejor que el término "liviano“.
- En segundo lugar, estuvieron de acuerdo en 4 valores fundamentales.
- Finalmente, estuvieron de acuerdo en 12 principios.
Esos 4 valores y 12principios formaronel “Manifiesto Ágil”
Esas 17 personasFormaron la
“Alianza Ágil”
El Manifiesto Ágil (I)
• “Estamos descubriendo mejores formas de desarrollar software al hacerlo y al ayudar a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
- individuos y sus interacciones sobre procesos y herramientas
- software funcional sobre documentación exhaustiva
- colaboración con el cliente sobre negociación de contratos
- responder al cambio sobre seguimiento de un plan
• Esto significa, que mientras hay valor en los ítems de la derecha, damos más valor a los de la izquierda.”
El Manifiesto Ágil (II)
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
El Manifiesto Ágil (III)
7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
En Resumen
• Las metodologías ágiles proponen tener el proceso “suficiente” (ni más ni menos) para cumplir con los objetivos
• Usar procesos de construcción iterativos• Entregar software funcional lo más pronto posible• Privilegiar el valor de la gente sobre el valor del
proceso• Fortalecer la comunicación y la colaboración• Orientar la metodología alrededor de un conjunto de
valores y principios• Lo ágil se define (por los mismos “agilistas”) como la
habilidad de responder de forma versátil al cambio para maximizar los beneficios
Orígenes y Precursores (I)
Las metodologías ágiles tal como las conocemos surgen en los años 90, pero los conceptos subyacentes
no son nuevos
"Agile software development is not new. It has been around since the
beginning of software development, but did not
show a competitive advantage in the 1970s and 1980s (...) However, it did win the development races
in the turbulent 1990s" Alistair Cockburn
IntegraciónContinua
IteracionesCortas
Programación de a Pares
Priorización de Requerimientos
Involucramiento del Cliente
Time-Boxing
Orígenes y Precursores (II)
• …y no sólo conceptos de software!
Desarrollo de Nuevos Productos
(Nonaka y Takeuchi)
Just-in-Time
Lean Manufacturing
Lean Thinking
Sistema de Producción
Toyota
Auto-Control yAuto-Dirección
Metodologías Ágiles más Conocidas
• XP (Extreme Programming – Kent Beck)• SCRUM (Jeff Sutherland, Ken Schwaber)• Crystal (Alistair Cockburn)• DSDM (DSDM Consortium)• Feature Driven Development (Jeff de
Luca, Peter Coad, Together Soft)• Adaptive Software Development (Jim
Highsmith)• Lean Development (Mary y Tom
Poppendieck, Robert Charette)
SCRUM Básico
• Más que una metodología de desarrollo es una metodología de gestión de proyectos, no contiene definiciones en áreas de ingeniería
• Con visión de que el trabajo es efectuado por equipos auto-organizados y auto-dirigidos
• Está basada en un proceso constructivo iterativo e incremental donde las iteraciones tienen duración fija
• Contiene definición de roles, prácticas y productos de trabajo, escritas de forma simple
• Está soportada en un conjunto de valores y principios
El Ciclo de SCRUM
Elementos de SCRUM
• Product Backlog• Sprint
- Planificación- Revisión- Sprint Backlog- SCRUM- Retrospectiva (Reflexión)
• Roles- Product Owner- Scrum Master- Team
• Valores- Compromiso, foco, apertura,
coraje y respeto
Backlog de Producto
Product Backlog
169
118
87 0 0 0 0
I tem Característica/ Requerimiento
Status Estimación original
Factor de complejidad
Estimación ajustada
Spri
nt
1
Spri
nt
2
Spri
nt
3
Spri
nt
4
Spri
nt
5
Spri
nt
6
1 Requerimiento 1 Completado 12,0 0,2 14,4 0,02 Requerimiento 2 Completado 15,0 0,3 19,5 0,03 Requerimiento 3 Completado 16,0 0,1 17,6 0,0
4 Requerimiento 4 Comprometido 14,0 0,2 16,8 16,8 7,05 Requerimiento 5 Comprometido 13,0 0,3 16,9 16,9 8,36 Requerimiento 6 Comprometido 18,0 0,2 21,6 21,6 9,0
7 Requerimiento 7 No comprometido 12,0 0,2 14,4 14,4 14,48 Requerimiento 8 No comprometido 16,0 0,1 17,6 17,6 17,69 Requerimiento 9 No comprometido 18,0 0,3 23,4 23,4 23,410 Requerimiento 10 No comprometido 6,0 0,2 7,2 7,2 7,2
Total esfuerzo
Backlog de Sprint
Sprint Backlog
272
242
218
194
Id Product Backlog Item
Tareas Status Asignada a
Estimación original
Progreso sobre
estimación
Día
1
Día
2
Día
3
Día
4
Requerimiento 41 Tarea 4.1 Completada John 20 100,0% 20 12 6 02 Tarea 4.2 En curso Miroslav 40 50,0% 40 36 26 203 Tarea 4.3 No iniciada John 36 0,0% 36 36 36 36
Requerimiento 54 Tarea 5.1 No iniciada John 24 0,0% 24 24 24 245 Tarea 5.2 En curso Claudio 36 72,2% 36 30 22 106 Tarea 5.3 En curso Daniel 44 27,3% 44 32 32 32
Requerimiento 67 Tarea 6.1 No iniciada John 32 0,0% 32 32 32 328 Tarea 6.2 No iniciada Daniel 40 0,0% 40 40 40 40
Esfuerzo pendiente
Mitos y Realidades
•Mito“Persona o cosa a las que se
atribuyen cualidades o excelencias que no tienen, o bien una realidad de la que carecen”
•Realidad“Lo que es efectivo o tiene
valor práctico, en contraposición con lo fantástico e ilusorio”
Existen muchos mitos y realidades entorno a la discusión Metodologías Ágiles
(m.a.) vs. Metodologías Tradicionales (m.t.)
¿“Ágil” Significa “Hacker”?
• Mitos- Las m.a. promueven y ensalzan el
“hacking”, es decir, la codificación directa sin paso por etapas de análisis y diseño (anti-ágil)
- El único producto de valor dentro del desarrollo es el código (ágil-fanático)
• Realidad- Las m.a. dan mucho valor al código
como resultado del desarrollo, esto no significa que no haya otros resultados valiosos
- Los equipos deben determinar cuáles son los resultados valiosos para sus clientes y orientar su trabajo en ese sentido (documentos de análisis, diseño, etc.)
Ciclo de Vida
•Mitos- Las m.t. implican casi siempre el
uso de un ciclo de vida clásico en cascada (ágil-fanático)
- Los proyectos donde no se conocen todos los requerimientos completamente al principio fracasan si usan un modelo en cascada (ágil-fanático)
- Los ciclos de vida iterativos son exclusivos de las m.a. (ágil-fanático)
•Realidad- Malas experiencias y malas
interpretaciones han conducido a conceptos erróneos sobre el ciclo en cascada
- Los ciclos de vida iterativos existen mucho antes de las m.a.
- Todas las m.a. proponen un ciclo de vida iterativo e incremental
Diseño
• Mitos- En las m.a. no hay ninguna actividad
de diseño o este no tiene ninguna importancia (anti-ágil)
- En las m.t. se promueve que no debe escribirse una sola línea de código sin antes terminar todo el diseño (ágil-fanático, anti-ágil?)
• Realidad- Las m.a. más conocidas proponen
etapas de diseño cortas y livianas pero otras prácticas de las mismas m.a. (p. ej., integración continua) implican alta disciplina y calidad técnica del diseño
Pruebas
•Mitos- En las m.a. no se realizan pruebas o
estas son consideradas de ninguna o poca importancia (anti-ágil)
- En las m.t. no hay actividades de pruebas concurrentes con otras actividades de desarrollo (ágil-fanático)
- En las m.t. las pruebas solo se inician cuando todo el código se ha finalizado (ágil-fanático, anti-ágil?)
•Realidad- En las m.a. la disciplina de pruebas
es fuerte y se promueve el diseño de pruebas antes de la construcción del código
- En general, la visión de que las actividades de pruebas (planificación, diseño, ejecución) son permanentes es común a todas las metodologías
Planificación (I)
• Mitos- Las m.a. promueven no realizar ningún
tipo de plan para orientar el desarrollo (anti-ágil)
- No hay que planificar (o no es posible) en un ambiente muy turbulento donde las cosas cambian todos los días (ágil-fanático)
- Las m.t. con la tendencia a planificar todos los aspectos del proyecto buscan predecir sus resultados y esto no es viable porque la incertidumbre no se puede eliminar (ágil-fanático)
- Dado que en las m.a. no se puede planificar todo el proyecto entonces no son viables en contratos de plazo y precio fijo (anti-ágil)
- En las m.a. no hay ningún manejo del riesgo (anti-ágil)
Planificación (II)
• Realidades- Todas las m.a. incluyen algún método de planificación,
promoviendo que se incluyan los elementos mínimos necesarios para poder ejecutar el proyecto
- Si bien hay pocas evidencias de manejo explícito del riesgo en las m.a. los procesos constructivos, el manejo de los requerimientos, la incertidumbre y el cambio contribuyen al manejo del riesgo
- Muchas compañías que usan m.a. lo hacen dentro de esquemas de contratos a plazo y precio fijos
- Los planes deben ser herramientas que guíen la ejecución del proyecto y deben siempre reflejar la realidad del mismo, este concepto es común a todas las metodologías
Documentación
• Mitos- En las m.a. no se documenta o esta
actividad se considera de ninguna o mínima importancia (anti-ágil)
- En las m.t. es más importante la documentación que el software (ágil-fanático)
- En los proyectos hechos con m.t. se pasa más tiempo documentando que construyendo el producto (ágil-fanático, anti-ágil?)
• Realidad- En las m.a. se concede más valor al
producto desarrollado que a la documentación
- Determinar la documentación suficiente para cumplir con los objetivos y desarrollar actividades para construirla y mantenerla es un concepto común a todas las metodologías
- El método más efectivo de comunicación es la conversación cara a cara
Gente
•Mitos- En las m.t. las personas son consideradas de
poca o mínima importancia o como recursos intercambiables (ágil-fanático, anti-ágil?)
- En las m.t. no se promueven técnicas efectivas de comunicación, colaboración y trabajo en equipo (ágil-fanático, anti-ágil?)
- En las m.a. se crea una alta dependencia de las personas (anti-ágil)
•Realidad- Las m.a. consideran a la gente como más
importante que los procesos- Las m.a. promueven explícitamente
prácticas de colaboración y comunicación- Las m.t. consideran a la gente como más
importante que los procesos (si, este es igual a la primera viñeta)
- Pocas m.t. contienen dentro de sus definiciones prácticas específicas de comunicación
Disciplina
• Mitos- En las m.a. no hay disciplina ni
exigencias fuertes al equipo de trabajo y por eso son más fáciles de usar (todos)
- Rigidez es lo mismo que disciplina (todos)
• Realidad- La rigidez entendida como el
conjunto de reglas de la metodología y el formalismo implícito en su definición no tiene nada que ver con la disciplina
- Las m.a. requieren la misma y en ocasiones incluso más disciplina que las m.t. en su implementación
Clientes
•Mitos- Las m.t. no promueven el mantener
foco en el cliente y sus necesidades (ágil fanático)
- En las m.a. se requiere que el cliente trabaje en el mismo espacio y con la misma dedicación que el equipo (anti-ágil)
•Realidad- El mantener el foco en las necesidades
del cliente, en agregar valor al producto desarrollado y orientarse al cumplimiento de objetivos del proyecto es un concepto común a todas las metodologías
- En las m.a. no es obligatorio que el cliente trabaje junto con el equipo todo el tiempo. El concepto real es el de usuario con conocimiento de los objetivos disponible
CMMI vs. Metodologías Ágiles
• Mitos- CMMI y las m.a. no son compatibles
(todos)- Si no se aplica una metodología ágil
de libro entonces no se es ágil (ágil fanático)
• Realidad- Es posible implementar CMMI
tomando como base una metodología ágil, complementando las insuficiencias (tal como se hace con cualquier otra)
- Crear el balance adecuado de prácticas ágiles con los requerimientos del modelo puede permitir su uso en cualquier organización
Algunas Conclusiones (I)
• Las metodologías ágiles surgen en los años 90, como respuesta a un contexto de desarrollo de software turbulento y cambiante.
• En general, una metodología ágil es aquella que adhiere a los valores y principios del manifiesto.
• Los conceptos subyacentes a las mismas no son necesariamente nuevos, aunque toman nueva importancia a partir del momento en que se usan combinados.
Algunas Conclusiones (II)
• Hay una serie de malas interpretaciones en uno y otro sentido (ágiles y tradicionales).
• Las metodologías ágiles no son “balas de plata” pero tampoco son “la peor desgracia” sucedida a la ingeniería de software
• Ningún planteamiento es completo por si mismo, dado que ninguna metodología es apropiada para todos los proyectos, todos los equipos y todas las compañías
• Es posible y recomendable encontrar el balance que permite agregar el mayor valor a mi proceso, mi equipo, mi proyecto
¿Preguntas?
Prácticas Ágiles en Mejora de Procesos
IntroducciónEscenarios de Aplicación
¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil?Conclusiones y Recomendaciones
Índice del Módulo
• Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma
• Escenario 2: Implementando una Metodología Ágil completa
• Escenario 3: CMMI Complementando lo Ágil
• Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas
Sobreviviendo a Cambios Drásticos …
• La Historia de un Sistema• La Historia de un Proyecto.• ¡Un Cambio Inesperado!• ¿Qué Hicimos?• ¿Cómo nos Ayudó el Usar un Enfoque Ágil?
La Historia de un Sistema
• Sistema financiero para mesa de dinero de importante banco.
Sistema
• La mesa de dinero es parte del “core business”.
¡Por lo tanto, hablamos de un sistema
crítico!
La Historia de un Proyecto
• Una nueva versión sistema en cuestión reemplazaría a otra aplicación.
• La “otra aplicación” tenía costos muy elevados.
• Al momento de esta historia, faltaba un mes para comenzar el “paralelo” de la versión mencionada…
CONSTRUCCIÓN
PARALELO
¿Para cuándo
dijo que lo
quiere?
¡Un Cambio Inesperado!
¡Necesitamos la nueva versión
del sistema para bajar costos!
¡Necesitamos el sistema
para la semana próxima!
La Situación Resultante Fue…
CONSTRUCCIÓN
PARALELO
CONSTRUCCIÓN
PARALELO
¿Qué Podíamos Hacer?
• El sistema pasó a tener modo “time box”.
CONSTRUCCIÓN
PARALELO
…para que aquí se tenga la
funcionalidad requerida?
¿Qué hacemos aquí en el tiempo disponible…
• Un proyecto de estas características debe llegar o llegar, pero...
Podando Requerimientos…
• La primera actividad que procedimos a hacer es ver que requerimientos eran necesarios para la nueva fecha límite, cuáles podían post-ponerse y cuáles eliminarse.
• La “poda de requerimientos” (requirements scrubbing) es una buena práctica implícita en modelos ágiles (se hace lo que el cliente desea realmente, no más).
¿Cómo Podamos Requerimientos?
1. Armamos una lista exhaustiva de los requerimientos.
2. Identificamos un representante “con capacidad de decisión”.
3. Priorizamos los requerimientos en base a su importancia para la fecha de entrega.
4. Acordamos cuáles eran los N requerimientos prioritarios para la fecha.
Requerimiento…
Requerimiento…
Requerimiento…
Requerimiento…
Requerimiento…
1
2
3
Organizando el Trabajo Pendiente
• Con los requerimientos priorizados y “podados”, armamos un “backlog”.
• Un “backlog” es una forma liviana de organizar el trabajo pendiente (actividades y requerimientos).
• El backlog es la forma que utiliza Scrum para registrar el trabajo pendiente para el producto y para una iteración de trabajo.
• Definimos un backlog del producto, y un backlog para cada iteración.
• Usamos esta forma de backlog para organizar nuestras actividades en iteraciones de un día cada una.
¿Cómo Armamos el Backlog?
• Asignamos los requerimientos a “iteraciones” dependiendo de su prioridad.
ID Iteración Orden Descripción
REQ10 1 1 …
REQ23 1 2 …
REQ06 1 3 …
REQ02 2 1 …
REQ33 2 2 …
REQ18 3 1 …
REQ30 3 2 …
REQ01 3 3 …
Primera Iteració
n
Tercera Iteració
n
Segunda
Iteración
¡Avanzando a Paso Firme!
• Con un backlog armado y time-boxes definidos, lo importante era entonces asegurarnos de avanzar “siempre para adelante”.
• Si implementamos un requerimiento, veamos que cuando lo integremos, el producto siga andando.
• Si no llegamos a terminar con todos los requerimientos, aún así tendremos un producto funcionando que podamos mostrar.
Builds Continuos y Pruebas Básicas
• La estrategia que utilizamos consiste en builds continuos y “smoke test” (prueba básica de la funcionalidad del sistema).
DESARROLLO BUILD
Pasa a integración lo más pronto
posible (diario, al menos).
SMOKE TEST
Se prueba que no se “rompa”
el build.
Se Itera por
EstasFases…
El programador libera código.
Armando una Estrategia de Builds Continuos…
• ¿Cómo lo hicimos?- El desarrollador (1 o 2) desarrollaba según el
back-log, y al finalizar, notificaba por mail al “integrador”.
- El integrador tomaba el código y lo integraba con el resto del producto.
- Compilaba.- Probaba “por arriba” el producto, para verificar
que no “se había roto”.- Si había problemas, se devolvía al desarrollador.
También nos resultó conveniente…
• En nuestro caso, el integrador también subía el código a un repositorio.- Es una buena práctica subir el código a un repositorio
(CVS, PVCS) cada vez que se logra un build exitoso.- Se pueden generar mini líneas base por cada build.- Conviene notificar entonces al equipo de que hay una
nueva versión “estable” del código para usar como base.
BUILD
¿Exitoso?
DESARROLLOREPOSITORIO
NotificarEquipo
Sí
Optimizando el Desarrollo
• Un principio de XP dice “haz lo más simple que pueda funcionar”.
• Solíamos tener la costumbre de hacer modelos complejos y soluciones genéricas…
¿Por qué no hacer las cosas “bien”, pero a la vez en forma simple y directa?
¿Cómo Evitamos la Complejidad Excesiva?
Evitamos atacar una solución genérica
o compleja si no era absolutamente necesario
Evitamos “gold plating”(introducir complejidad
Adicional sólo porque es Interesante o desafiante)
Poniendo Todo Eso Junto…
TIME BOX
TIME BOX TIME BOX TIME BOX
+ Simplicidad en elDesarrollo (¡PeroNo Negligencia!)
Desarrollo
Build S. Test
…el Resultado Fue…
• Al llegar a la fecha límite, teníamos “casi” todos los requerimientos exigidos para el time-box. Los más prioritarios estaban implementados, y el producto estaba funcionando.
• El usuario encontró el producto suficiente para comenzar, y acordó que era válido seguir “puliendo” el producto durante las próximas semanas.
Independiente de que quedara “backlog” pendiente, el producto resultante cumplía con
lo que se necesitaba para la fecha…
“EL PROYECTO LLEGÓ”
¿Cómo Ayudó el Usar un Enfoque Ágil?
• Podar los requerimientos nos permitió convertir un objetivo irrealizable en uno “difícil” pero realista.
• Usando iteraciones / time-boxes y un backlog pudimos hacer seguimiento del proyecto es una forma ultra-liviana, que consumía muy pocos recursos.
• Mediante la estrategia de build continuo y smoke test, pudimos tener un producto desde la primera iteración y “mantenerlo andando”.- Al llegar a la fecha límite, teníamos un producto
funcionando desde hace tiempo.• Adoptando simplicidad en el desarrollo evitamos perder
de vista el objetivo.
Índice del Módulo
• Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma
• Escenario 2: Implementando una Metodología Ágil completa
• Escenario 3: CMMI Complementando lo Ágil
• Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas
Un poco de historia para empezar
• Esta es una experiencia en un proyecto de mejora de una empresa pequeña dedicada al desarrollo de videojuegos para PC
• El proyecto empezó con la orientación de formalizar y hacer más rigurosos muchos de los procesos de la empresa
• Durante el camino se detectaron debilidades importantes de gestión en un proyecto crítico y había que solucionarlas a la brevedad
• En ese momento se optó por implementar SCRUM en este proyecto para resolver los problemas de gestión y volverlo a curso
El contexto de esta aplicación
• Un segmento “especial” de la industria: hacer juegos no es un juego!!!
• La gente que hace juegos: solo 40% del equipo son ingenieros, los demás son diseñadores y artistas
• Este proyecto nuevo no es igual:- Nuevo cliente (y estratégico)- Equipo más grande (antes +5 ahora
+15)- Mucho más complejo y grande que los
anteriores- Tenemos 7 meses para Alpha pero
empezamos en el mes 3 y la fecha final no cambió!!!
- Después de 1 mes de proyecto no se ven avances, los requerimientos cambian con frecuencia, no se sabe el estado del proyecto y la moral es baja
¿Qué hacemos ahora?
• Organicemos el equipo: en vez de 1 de 15 que sean 3 de 5, todos autosuficientes (multidisciplinarios)
• Asignemos a cada equipo responsabilidades claras de módulos del producto en cada entrega, la administración no va a intervenir en este proceso
• Para la próxima entrega en un mes más fijemos una meta y dejemos que cada equipo planifique sus tareas, la administración se compromete a no cambiar la meta
• Llevemos un registro de estas tareas y revisemos su estado diariamente
• Diariamente revisemos los problemas y riesgos que tenemos para tomar acciones correctivas y preventivas lo más pronto posible
• Hagamos pública toda la información sobre las actividades, problemas y riesgos del proyecto e involucremos a todo el equipo
Un nuevo enfoque
• Esto parece SCRUM pero no le cuenten a nadie!!!
• Cada equipo nombra un líder que actúa como responsable de cumplir la meta y resuelve los problemas (“Scrum Master”)
• Se realiza una reunión diaria de seguimiento
- Duración fija- Foco en actividades efectuadas, a
efectuar y detección de problemas• Las tareas se publican en tarjetas (en un
tablero de corcho) y se reestiman diariamente
• El progreso se visualiza en gráficos de “burn-down”
• Los líderes de cada equipo también se reúnen diariamente para analizar balance de carga y ver temas de integración
Las herramientas
Las herramientas (2)
MS5 - Content 2 - Planning Worksheet
Id Name Team Role
working days this
sprint
working hours this
sprint
support factor (% reserved
for support)
drag factor (% lost
time)
Process Manageme
nt
Expected QA Recycle
hours
Available hours
before planning:
Total planned so
far (from Sprint
Backlog
Remaining unplanned
hours
1 Ice Man Red Team 18 144 0,05 0 10,8 0 126 88 382 Rookie Blue Team 18 144 0,05 0 10,8 0 126 72 543 Drake Yellow Team 18 144 0 0 10,8 0 133 90 434 Ruso Blue Team 12 96 0 0 7,2 0 89 83 65 Andres Yellow Team Master 18 144 0,2 0 10,8 0 104 112 -8
Planning Parameters Planning metricsTeam
Las herramientas (3)
MS5 - Content 2 - Sprint BacklogDay 1 2 3 4 5 6 7
1187
388
317
325
235
131
493
428
Id Team Task description Status Owner Level Orig Est Hrs
04-A
br
05-A
br
06-A
br
07-A
br
08-A
br
11-A
br
12-A
br
1 Red Scene easy preview In Progress Ice Man 1 4 4 4 4 4 4 4 2
2 Red Pet basics Completed Ice Man 1 8 8 8 8 0 8 4 0
3 Red Arcade minigame Not Started Ice Man 1 8 8 8 8 8 8 8 8
4 Blue Room customization In Progress Rookie 1 10 10 10 8 8
5 Blue Mouse out disappear In Progress Rookie 1 4 4 4 6 4
6 Yellow Money and dialog script function Completed Drake 1 4 4 4 4 4 4 0 0
total effort remaining by day
Las herramientas (4)
MS5 - Content 2 - Team Burndown Chart
0
50
100
150
200
250
300
350
400
450
500
Ho
urs
of
Eff
ort
Re
ma
inin
g
Effort Remaining Tasks Remaining
Resultados del proyecto
• El proyecto logró cumplir con sus plazos manteniendo buenos niveles de calidad
• Los problemas de visibilidad se redujeron, los compromisos se reafirmaron
• El equipo recuperó la confianza y aprendió a autogestionarse y apoyarse en la administración para resolver los problemas ASAP
• Al delegar responsabilidades de gestión más otros miembros del equipo quedaron con la capacidad de liderar equipos y la administración pudo dedicarse a temas más estratégicos
Para tener en cuenta
• SCRUM se usó para resolver los problemas de gestión del proyecto, fue apropiado porque:- Aumentó la comunicación, la visibilidad, el trabajo en
equipo y el compromiso- Hizo a los equipos más aptos para responder
flexiblemente al ambiente con alta tasa de cambios• SCRUM no aportó prácticas de ingeniería o diseño,
estas se conservaron y varias fueron determinantes para los resultados (p.ej. La integración continua el código)
• Las prácticas más livianas (pero no menos disciplinadas) fueron más fáciles de implementar y de comprender para el equipo, especialmente los “no-ingenieros”
No todo es color de rosa
• En las primeras iteraciones (Sprints) fue muy difícil llegar a estimaciones precisas para el trabajo de todo el mes (se revisaba por nuevas tareas semanalmente)
• Al principio el equipo recibió el método como “otra de esas ideas” de la gerencia y no asumió el compromiso
• Varios miembros del equipo fueron renuentes a escribir todas sus tareas en el backlog y más aún a reestimarlas diariamente
¿Y qué pasó después?
• Ante los buenos resultados se decidió continuar usando SCRUM para gestionar los proyectos (ya se han iniciado 3 más), el equipo participó completamente en esa decisión
• Se profundizó y “formalizó” la implementación de la metodología con las herramientas y prácticas restantes
• El proyecto de mejora se reorganizó: ahora se busca fortalecer otros procesos usando CMMI como referencia pero manteniendo la agilidad
Índice del Módulo
• Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma
• Escenario 2: Implementando una Metodología Ágil completa
• Escenario 3: CMMI Complementando lo Ágil
• Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas
Una historia diferente
• Esta experiencia es de una empresa pequeña de desarrollo ya usaba una metodología ágil y tiene la necesidad de “certificar” CMMI, al menos nivel 2
• El equipo de trabajo y la administración están muy satisfechos con los resultados que les ha traído usar esta metodología ágil y no quieren perder eso
• Qué dilema!!! Necesitamos ser CMMI pero queremos ser ágiles, qué se puede hacer?
El contexto
• Una empresa de desarrollo de software bancario con algo más de 50 personas
• El área a evaluar tiene solo 6 personas!!!
• Usan Crystal Clear, una de las metodologías ágiles más livianas
• Hay que desarrollar 6 áreas de proceso (no SAM) para nivel 2 y que no se pierda la esencia de lo ágil
Las fortalezas presentes
• Un ciclo de vida definido: iterativo-incremental
• Se lleva un backlog de tareas y se realiza seguimiento y registro diario de su estado con gráficos de “burn-down”
• Además del backlog de cada iteración existe un cronograma de iteraciones
• Se lleva un backlog de riesgos y problemas• Hay integración continua del código y
pruebas unitarias automáticas (que se codifican antes de los programas)
Las cosas a mejorar
• La administración de requerimientos es demasiado informal
• No existe un proceso de estimación• Varios de los aspectos importantes de
planificación no se tienen en cuenta explícitamente
• No hay prácticas de QA• No hay mediciones (ni análisis por
supuesto)
Principales puntos de trabajo
• Foco muy fuerte en uso de herramientas para automatizar procesos (administración de requerimientos p.ej.)
• Definir artefactos de trabajo más livianos que cumplieran los requisitos del modelo CMMI
• Definir los procesos inexistentes con la filosofía de trabajo ágil (estimación, QA, métricas)
Lo que aprendimos y lo que viene
• Fue más difícil lograr que ciertos artefactos requeridos pudieran ser usados en el ambiente sin limitar su agilidad que usar los artefactos ágiles presentes para cumplir los requisitos del modelo
• La etapa de definiciones finalizó y se inició el pilotaje de los procesos con muy buenos resultados hasta ahora
• Se espera realizar la evaluación en marzo del 2006
Índice del Módulo
• Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma
• Escenario 2: Implementando una Metodología Ágil completa
• Escenario 3: CMMI Complementando lo Ágil
• Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas
No solo en pequeñas empresas
• Esta es una experiencia de uso de prácticas ágiles en un proyecto en una empresa de servicios de salud y financieros que emplea a más de 2000 personas (+200 en IT, +130 en desarrollo)
• Esta empresa está en camino de evaluación de CMMI nivel 3 a mediados del próximo año y tiene ya varios procesos establecidos y en uso en varias áreas
• La necesidad de las prácticas ágiles surge dentro de un proyecto que es crítico para el negocio, con plazos muy agresivos y que ha tenido dificultades para mostrar resultados tangibles
Un proyecto en crisis
• Es el proyecto de desarrollo de un nuevo producto para el negocio, esta no es una empresa de desarrollo
• Después de más de 6 meses de proyecto aún no se ha entregado ni una sola característica del producto funcionando
• Un proyecto hermano se canceló y el usuario está muy tenso, en menos de tres meses se debe vender el primer producto y la solución tiene que estar lista
• La fecha de entrega de la versión con las primeras funcionalidades no se cumplió, el usuario otorga un mes más para mostrar algo o…
Nuestras debilidades
• Los procesos de gestión establecidos no son suficientes para manejar varios aspectos conflictivos del proyecto
• Los miembros del equipo están confundidos sobre sus responsabilidades y varios vienen con muy baja moral (del proyecto cancelado)
• Se necesita visibilidad permanente para tomar medidas a tiempo
SCRUM ataca de nuevo
• Se reubica el equipo en un solo espacio para que queden colocalizados
• Se transmiten los valores y principios de SCRUM al equipo y se dejan claros los objetivos del primer mes
• Se prepara una sesión para planificar el mes, en esta sesión se asignan responsabilidades, se revisan dedicaciones, se resuelven problemas y se inicia el backlog
• Se inician las reuniones diarias controlando el foco del equipo, el backlog se actualiza diariamente y se publican las tareas y los gráficos de “burn-down”
Resultados iniciales
• El equipo cumple la primera meta, quedan menos de dos meses para la meta final pero ahora hay más confianza
• El equipo trabaja como equipo, las responsabilidades y compromisos están claros
• Ya existe una versión de producto funcional que el usuario puede probar y que demuestra que el equipo si es capaz de cumplir compromisos y mostrar resultados
• Otros proyectos, jefaturas de área y gerencias se muestran impresionados por la dinámica que se logra del equipo y asisten como oyentes a las reuniones diarias
Burn-down del primer Sprint
- Team Burndown Chart
1093
-400
-200
0
200
400
600
800
1000
1200
16-A
go
17-A
go
18-A
go
19-A
go
22-A
go
23-A
go
24-A
go
25-A
go
26-A
go
29-A
go
30-A
go
31-A
go
01-S
ep
02-S
ep
05-S
ep
06-S
ep
07-S
ep
08-S
ep
09-S
ep
12-S
ep
13-S
ep
14-S
ep
15-S
ep
16-S
ep
Ho
urs
of
Eff
ort
Re
ma
inin
g
Remaining effort Daily burnedRemaining tasks Ideal Burndown
Nadie dijo que era fácil
• La reunión inicial de planificación que SCRUM propone de 8 horas tomo 2 días y medio!!! Se cumplieron los objetivos pero superando muchos momentos difíciles y de frustración
• El equipo tuvo muchas dificultades para trabajar coordinadamente y ajustar y balancear tareas
• También hubo dificultades de estimación (en ambos sentidos) que se hicieron evidentes el primer Sprint
No hay incompatibilidades
• Los procesos de gestión de SCRUM se integraron bien con los procesos más formales de planificación y seguimiento ya establecidos
• Se mantuvieron los artefactos y prácticas de ingeniería establecidos con las adaptaciones necesarias de uno y otro lado
• De nuevo, se soportó el desarrollo en práctica de integración continua que no estuvo exenta de dificultades debido a los estándares más rigurosos de la organización
Lo que viene
• El equipo continua con sus siguientes iteraciones (2 más) para cumplir la meta final, se espera un aumento significativo de la productividad
• Se analizará la conveniencia de involucrar SCRUM como parte de los procesos estándar para uso en algunos proyectos específicos
¿Preguntas?
Prácticas Ágiles en Mejora de Procesos
IntroducciónEscenarios de Aplicación
¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil?
Conclusiones y Recomendaciones
Índice del Módulo
• Recapitulando• Factores a analizar para el
uso de prácticas ágiles• Factores de éxito• Beneficios conocidos• Riesgos
Recapitulando
• Es claro que lo “ágil” es una alternativa real para los proyectos de mejora
• Decimos que es real porque no puede negarse que tiene una fuerza importante y una presencia cada vez mayor en muchos y diferentes ambientes y no solo en desarrollo de software
• Además hemos visto varios escenarios en el que a partir de experiencias en terreno se han probado sus beneficios y aprendido de sus limitaciones
• Estos escenarios muestran que para la mejora no hay que escoger disyuntivamente entre modelos formales y modelos ágiles
La necesidad del balance
• Hoy es reconocido que no existe una metodología única para todos los tipos de proyecto
• Proyectos diferentes, contextos diferentes, equipos diferentes necesitan metodologías diferentes para lograr sus objetivos
• Por eso no se puede suponer que existe un modelo completo (recordemos “No Silver Bullet” de Brooks)
• Por otro lado los modelos formales y ágiles han logrado éxitos en sus propios “nichos”
• El problema es que en los negocios y actividades de hoy más complejas y vertiginosas las condiciones de esos “nichos” se entremezclan continuamente y necesitamos escoger lo mejor de ambos mundos
Analizando los factores de balance
Personnel
Dynamism (% Requirements-change/month)
Culture (% thriving on chaos vs. order)
Size (# of personnel)
Criticality (Loss due to impact of defects)
5030
105
1
90
70
50
30
10
3
10
30
100
300
35
30
25
20
15
Essential Funds Discretionary
Funds Comfort
Single Life
Many Lives
(% Level 1B) (% Level 2&3)
0
10
20
30
40
Agile
Plan-driven
Personnel
Dynamism (% Requirements-change/month)
Culture (% thriving on chaos vs. order)
Size (# of personnel)
Criticality (Loss due to impact of defects)
5030
105
1
90
70
50
30
10
3
10
30
100
300
35
30
25
20
15
Essential Funds Discretionary
Funds Comfort
Single Life
Many Lives
(% Level 1B) (% Level 2&3)
0
10
20
30
40
Agile
Plan-driven
Tomado de Boehm and Turner, Balancing Agility and Discipline, 2000
Factores de éxito en el balance
• Mantener el foco en agregar valor a las actividades (evitar la “procesitis”)
• No asumir posiciones radicales para ningún lado
• No perder de vista las restricciones• No asumir que porque ha funcionado para
otros va a funcionar para mi, hay que mantener control y visibilidad constantes
• No asumir que porque funcionó una vez va a funcionar siempre, (idem al anterior)
• Se aplica lo que se predica, se usa al implementar la misma disciplina que se exige
Al usar prácticas ágiles tener en cuenta
• Pequeños incrementos que funcionen orientados por el valor que agregan
• Se privilegia la gente, hay que estar atentos a sus necesidades y motivaciones y también a sus capacidades
• Hacer foco continuo en la transmisión de valores y principios
• Fomentar intensamente el trabajo de equipo y la comunicación directa
• Promover un ambiente de excelenciaEn esencia: ser ágiles también para
implementar!!!
Un ejemplo de balance:
IDEAL + SCRUM: Guiando el proyecto de mejora
• IDEAL sienta el marco general y las etapas e hitos clave
• Con SCRUM se definen actividades concretas en iteraciones para cada unidad de mejora
• Al inicio de cada iteración se planifica el SCRUM, este se convierte en el plan táctico de cada unidad de mejora
• El equipo de mejora se mantiene informado y se registran los problemas y el progreso diariamente
• Al final de cada iteración se revisan los avances y se analizan los resultados para proponer mejoras
Beneficios esperables del balance
• Procesos más efectivos• Menos burocracia, mayor valor
agregado• Personas y equipos más
comprometidos, más motivados• Mejor comunicación y visibilidad de
resultados• Resultados tangibles más pronto
Riesgos conocidos
• El número uno: malas interpretaciones y posiciones radicales, propias y del equipo
• No planificar las mejoras ni realizar seguimiento y control constantes (no porque sea ágil se implementa solo)
• Abandonar las buenas prácticas que ya existían por “la nueva onda”
• Perder el impulso inicial (con lo ágil también puede pasar)
¿Preguntas?
Prácticas Ágiles en Mejora de Procesos
IntroducciónEscenarios de Aplicación
¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil?Conclusiones y Recomendaciones
Resumiendo …
• Las metodologías ágiles surgen en los años 90, como respuesta a un contexto de desarrollo de software turbulento y cambiante.
• Lo ágil se define (por los mismos “agilistas”) como la habilidad de responder de forma versátil al cambio para maximizar los beneficios
• Hacia el año 2001, los principales promotores de este tipo de metodologías crean la “alianza ágil”.
• La alianza ágil enuncia los principios de lo “ágil” en el llamado “manifiesto ágil”.
• En general, una metodología ágil es aquella que adhiere a los valores y principios del manifiesto.- Usar procesos de construcción iterativos- Entregar software funcional lo más pronto posible- Privilegiar el valor de la gente sobre el valor del
proceso- Fortalecer la comunicación y la colaboración
¿Los Conceptos son Nuevos?
• Los conceptos subyacentes a las mismas no son necesariamente nuevos, aunque toman nueva importancia a partir del momento en que se usan combinados. - Prácticas como iteraciones cortas para reducir el riesgo,
programación de a pares, etc, ya existían mucho antes de que el mismo concepto de ágil existiera.
- Incluso en otras industrias, el concepto de “reducir el peso del proceso” existe ya desde hace mucho tiempo (p. ej. Lean, Auto-Dirección).
• Una lectura de este hecho es que nadie debería “alarmarse” por las prácticas ágiles. Son buenas prácticas que ya existían, “empaquetadas” de una manera nueva, para atender necesidades del contexto actual.
¡Ni Héroes ni Villanos!
• Hay una serie de malas interpretaciones en uno y otro sentido (ágiles y tradicionales).- Mitos y realidades sobre Ágil vs.
Hacker, Diseño, Pruebas, Planificación, Ágil vs. CMMI, etc.
• Las metodologías ágiles no son “balas de plata” pero tampoco son “la peor desgracia” sucedida a la ingeniería de software.
Recomendaciones para Mejora Ágil
• Es claro que lo “ágil” es una alternativa real para los proyectos de mejora
• Hemos visto varios escenarios en el que a partir de experiencias en terreno se han probado sus beneficios y aprendido de sus limitaciones
• No necesariamente hay que implementar una metodología ágil completa. Se pueden combinar con CMMI, se pueden implementar ciertas prácticas clave …
• Cómo en la mayoría de las iniciativas de mejora de procesos, la clave parece estar en una sana mezcla de las prácticas que mejor se ajustan a la organización.
¡¡Recordemos que entodos los casos, la metodología debe adaptarse a la organización, y no a la
inversa!
Conclusiones Finales
• Ningún planteamiento es completo por si mismo, dado que ninguna metodología es apropiada para todos los proyectos, equipos y compañías
• ¡Ser ágil no necesariamente significa lo mismo en todo contexto! - ¿Es lo mismo ser ágil para una
compañía de aviones que para una pequeña compañía de IS?
• Es posible y recomendable encontrar el balance que permite agregar el mayor valor a mi proceso, mi equipo, mi proyecto
Cantidad de Personas
1-6 20 40 100 500 …
Pérdida de Confort
Pérdida Monetaria
Discreta
Pérdida Monetaria
Esencial
Pérdida de Vidas
Cri
ticid
ad
Pes
o
“LA CLAVE ES EL BALANCE”
¿Preguntas?
110
Autores
Walter Ariel RisiPragma [email protected]
Miroslav PavlovicPractia [email protected]
John GómezPractia [email protected]
¡¡¡Muchas Gracias!!!
111
Para mayor información
Argentina
San Martín 575 4to
(C1004AAK) Buenos Aires
Tel (+5411) 4327-1999
España
Sta. Engracia, 169
(28003) Madrid
Tel (+ 3491) 295-1547
Visite nuestros WEB SITES:
www.pragmaconsultores.com
- Información Detallada de Servicios
- Nuestra Experiencia: Clientes y Proyectos
- Nuestro Compromiso y Nuestra Metodología de Trabajo
www.qafactory.com
- Fábrica de Aseguramiento de la Calidad
- Beneficios y Detalle del Servicio
Contáctenos:
Chile
Luis T. Ojeda 0191 Of. 701,
Providencia, Santiago
Tel (+562) 334-3361
