www.chileagil.cl
Agustín Villena M.
agustin.villena@chileagil.cl
16-04-2009

Esta obra está publicada bajo una Atribución-No Comercial-

Licenciar Igual 2.0 Chile de Creative Commons. Para ver una
copia de esta licencia, visite
http://creativecommons.org/licenses/by-nc-sa/2.0/cl/
agustin.villena@gmail.com

Logros de Proyectos de Software

◦ Pequeño avance
Fuente:
“CHAOS Report”, EE.UU.
The Standish Group
16-04-2009 agustin.villena@chileagil.cl

Pero con poca productividad

Fuente:
“CHAOS Report”, EE.UU.
The Standish Group
16-04-2009 agustin.villena@chileagil.cl

Como lo describió el
Como lo programó el
Como lo explicó el Como lo entendió el Como lo diseñó el
área comercial
Desarrollador
cliente Jefe de Proyecto Analista
Como se documentó el Qué fue instalado en Qué se le cobró al Cómo fue soportado Qué necesitaba el
proyecto el cliente cliente cliente en realidad
16-04-2009 agustin.villena@chileagil.cl

Y en Chile, ¿será mejor?

◦ ...
16-04-2009 agustin.villena@chileagil.cl

Plano de Negocio
Problema
Valor
(Necesidad)
Lenguaje de Negocio
Ámbito de la
Lenguaje
Funcionalidades
Común
Base
gestión
(Soluciones)
Lenguaje Técnico
TAREAS
Calidad
Plano Técnico
agustin.villena@chileagil.cl

Avance de Proyecto:
- ¿Cuánto hemos avanzado realmente
(en generar real valor)?
- ¿Cuáles y cuántas funcionalidades queda por hacer?
- ¿Cuánto tiempo se requerirá para dichas funcionalidades?
- ¿Qué defectos puede tener el producto?
Método de Trabajo
- ¿Qué prácticas y estándares se debe seguir?
- ¿Qué errores no se debe repetir?
- ¿Qué debemos mejorar?
?
?
Tecnología:
Desarrollador - ¿Cuál tecnología usar?
Cliente
¿Concuerdan? - ¿Qué sabemos hacer con
Problema en resolución:
¿Concuerdan?
la tecnología utilizada?
- ¿Cuáles son la necesidades
- ¿Cuáles es posible hacer
actuales? (limites) con la
- ¿Cuáles son prioritarias? tecnología?
Trabajo en Equipo:
?
- ¿Cómo mantener la motivación?
- ¿Cómo comunicarse efectivamente?
- ¿Hay áreas del proyecto que sólo puedan ser
mantenidas por uno?
agustin.villena@chileagil.cl
Equipo de Desarrollo

agustin.villena@chileagil.cl

Lidiar con el Riesgo
¿Causa del Riesgo?

La incertidumbre
agustin.villena@gmail.com

Concepto: “Desarrollo de

nuevo producto” (NPD)
◦ Alta incertidumbre,
tecnológica y de
requerimientos
◦ Alta probabilidad de cambio
el proyecto
◦ Se estima mejor mientras más
se resuelve el problema
¡Un desarrollo de software es

un NPD!
agustin.villena@gmail.com

agustin.villena@gmail.com

Tradicionalmente, para atacar la incertidumbre,

◦ se trata de definir todo desde un principio
◦ generando un diseño y plan detallado, que luego el desarrollador
debe ejecutar
 Conformado por requerimientos abstractos y detallados
◦ En este modelo, el cliente delega su responsabilidad en el
desarrollador
 Y si este no cumple lo definido es castigado por multas en el contrato
agustin.villena@gmail.com

Esto da origen al Modelo de Cascada de desarrollo

Análisis y
especificación de
requerimientos
Diseño
Codificación y
Test de Módulos
Integración y
Test del Sistema
Instalación y
Mantenimiento
agustin.villena@gmail.com

NO hay retroalimentación entre el problema de

negocio y el producto desarrollado
◦ Es fácil caer en el sesgo tecnológico (cool features)
◦ Se pierde sincronía con las necesidades reales del negocio
 Hasta que es demasiado tarde
agustin.villena@gmail.com

Mientras más se trate de definir a priori un problema

de software que posee incertidumbre,
más probabilidad hay de error
Y se agrega inflexibilidad ante los (muy) posibles

cambios
Problema típico
del
ciclo de vida
“cascada”
agustin.villena@gmail.com
agustin.villena@gmail.com

Cree que a medida que avanza

un proyecto, los cambios son
más caros
◦ Se tiende a desarrollar cosas
que se cree que alguna vez
se necesitarán
◦ Tiende a priorizar según sus propia
visión, no la del negocio
 Primero diseñamos toda la BD y sus
mantenedores, y entonces
implementamos las aplicaciones
cliente
agustin.villena@gmail.com

Única zona
donde hay
Valor para el cliente
agustin.villena@gmail.com

agustin.villena@chileagil.cl 16-04-2009

Cliente Problema de Negocio
Proyecto de
Software
Ingeniero
de Software
Producto de
Software
Equipo de
Desarrollo
Tecnología

Antecedente 1
Software fails to deliver…
and fails to deliver value!
Kent Beck, “Extreme Programming Explained”, 1999
En 2001, Kent Beck y otros autores de enfoques similares

proponen los Principios Ágiles:
Individuos e interacciones Procesos y herramientas.
Software funcional Documentación exhaustiva
por sobre
Colaboración con el cliente Negociación de contratos
Responder al cambio Seguir un plan
agustin.villena@chileagil.cl

• Ken Beck, 1999, “Extreme Programming Explained”
Extreme
Programming • Enfoque empírico e integral de un proyecto de software
(XP) • Equipos pequeños que incluyen al cliente
• Basado en el enfoque de gestión de la innovación de productos de Hirotaka
Takeuchi and Ikujiro Nonaka, 1986
• Sutherland and Schwaber , lo presentan en OOPSLA (1995)
Scrum • Define un conjunto de herramientas de gestión y visualización de avance
• Metáfora: se requiere abarcar todas las disciplinas requeridas, tal como la
formación de scrum del rugby
• Mary y Tom Poppendieck, “Lean Software Development”
Lean
Software • Define las bases teóricas de las metodologías ágiles, a partir del Toyota
Development Production System
16-04-2009 agustin.villena@chileagil.cl

Es la metodología ágil más famosa en la

actualidad
Enunciada por Kent Beck, Ward Cunningham,

and Ron Jeffries.
Concebida en el proyecto C3 (Chrysler

Comprehensive Compensation)
Documentada en el WikiWiki original

◦ http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Plasmada en 1999 en el libro

“Extreme Programming Explained”
◦ Acaba de salir la segunda edición en el 2005
agustin.villena@chileagil.cl

Ciclo de Gestión del Proyecto Orientada al Valor
Cliente Problema de Negocio
Ciclo de Gestión del Desarrollo en Equipo
Proyecto de
Software
Ingeniero
de Software
Ciclo de
Programación
Producto de
de calidad
Software
Equipo de
Desarrollo
Tecnología
XP lo organiza en ciclos de
Entorno de un
retroalimentación y aprendizaje acelerado
proyecto de software
agustin.villena@chileagil.cl

El desarrollo de software es una actividad humana

◦ Es afectada por la motivación, creencias y los instintos de las personas
Valores Comunes: son los que permiten que las personas trabajen por el

beneficio común antes que el propio
Comunicación
Respeto Simplicidad
Coraje Retroalimentación
agustin.villena@gmail.com

Reglas que orientan la toma de decisiones

• Comunicación abierta y honesta
• Enseñar a aprender
• Trabajar con los instintos de las personas
• Siempre asumir simplicidad
• Viajar con equipaje: poco, simple y valioso
• Cambios paso a paso
• Adaptar de XP a la realidad local
• Jugar a ganar
• Responsabilidad aceptada (antes que asignada)
• Trabajo de Calidad
• Atacar los problemas urgentes, dejando la mayor cantidad de opciones abiertas
• Retroalimentación Rápida (favorece el aprendizaje)
• Medir honestamente
• Experimentos concretos
agustin.villena@gmail.com

Embrace change
•
• Aceptar con naturalidad y entusiasmo el cambio
YAGNI: You Arent’ Gonna Need It.
•
Avoid PrematureGeneralization
• ¡No lo vas a necesitar! (No hagas sobrediseño)
Once and Only Once
•
DRY: Don’t repeat yourself
RefactorMercilessly
Una funcionalidad en una y solo una parte del sistema
Fail fast
•
• Si va a fallar, que lo haga pronto, para asi escoger otro camino
Do The Simplest Thing That Could Possibly Work
•
• Haz lo más “simple” que podría funcionar
agustin.villena@gmail.com

Kent Beck:

◦ “Llevar buenas prácticas de Ingeniería de Software al
extremo”
Buen Práctica Práctica Extrema
Software funcionando Entregas Incrementales e Integración Continua
Revisiones de código Programación de a pares
Sistema de Pruebas Estructurado Desarrollo Guiado por Pruebas
Tener alineado al cliente Cliente in situ
agustin.villena@gmail.com

Entregas
pequeñas
Planning Game
Gestión del Proyecto
orientada al valor
Cliente en
terreno
(Un sólo equipo)
Tests de Aceptación
Definición Validación
del Cliente
Desarrollo
Planning Game de la Iteración
Gestión del Desarrollo en Equipo
Liderazgo Motivador
Diseño
(Coaching)
Simple
Programación de a
Programación Incremental
Programación en Equipo
Retroalimentación de Avance pares
(Tracking) (+ Mantener el
equipo rotando)
de Calidad
Desarrollo
Integración
Guiado por
continua
Tests
Stand Up Meeting
Estándares de Código
Espacio de Trabajo
Informativo
Refactorización
Propiedad Colectiva
de Código
Ritmo Sostenido
( No a las horas extra)
Retrospectivas

funcionalidades
funcionalidades
tiempo tiempo
Valor entregado de un proyecto tradicional Valor ideal que debiera entregar un proyecto
Tradicionalmente ¿No debiera ser así?
agustin.villena@gmail.com

El desarrollo se debe dividir

en iteraciones cortas de
tiempo fijo
Al fin de cada iteración del

desarrollo, debe tenerse un
producto funcional y útil
Alto valor promedio
para el cliente
agustin.villena@chileagil.cl

Visión tradicional ¿Y si fuera así?
 
agustin.villena@chileagil.cl
agustin.villena@gmail.com

Tiempo disponible para el proyecto

Costo (Recursos) que se dispondrán

Alcance, es decir conjunto de funcionalidades que se

desarrollarán
Y la que se suele olvidar

◦ Calidad (eficacia, resistencia a fallas, eficiencia, etc.)
agustin.villena@chileagil.cl

Por lo regular se fijan las 3 primeras variables:

◦ “Hazme un administrador de estas tablas de la base de datos, en una
semana, con dos programadores”
¿Qué sucede al haber cambio?:

◦ Tiempo y Costo no son en realidad muy flexibles
◦ El Alcance está fijo por el diseño y el plan definido
◦ Variable que sufre: la Calidad,
lo que afecta el valor generado para el cliente
◦ Esto genera conflicto
 El cliente siempre querrá el mayor valor por sus recursos invertidos
 Y el desarrollador la mayor calidad
¿Qué persona sana desea hacer un trabajo mediocre?
agustin.villena@chileagil.cl

Definamos contratos en que la duración de cada

iteración esté prefijada, inamoviblemente
◦ ¡No existen “atrasos”!
Y lo que se ajusta es el alcance (cantidad y cualidad de

las funcionalidades) del proyecto para la iteración
agustin.villena@chileagil.cl

El objetivo es que todos adquieran la confianza de que las metas del proyecto (de negocio y técnicas) son

alcanzables
Aquí el cliente comparte su responsabilidad sobre el proyecto con el desarrollador, en una relación de

sinergia
◦ (inspirado en el modelo Toyota de gestión)
Cliente Desarrollador
Desea Valor recibido por cada Calidad del trabajo
maximizar semana de desarrollo realizado
Qué será implementado, y Cuánto se estima que
en qué prioridad, según las demorará una tarea
Puede
necesidades de su (idealmente)
definir
negocio
Funcionalidades Sus estimaciones en base a
Puede solicitadas por otras no nuevos descubrimientos
cambiar implementadas de costo
equivalente (canjear)
agustin.villena@chileagil.cl

C = Cliente
El flujo del Planning Game
D = Desarrollador
C Fase de Exploración
Escribir Historias
para toda la iteración
D
Estimar Historias
C
Dividir Historias
NO
El Planning Game
 ¿Estimable?
Experimentos Concretos D
◦ Juego colaborativo que
SI
sigue las los roles y Fase de Compromiso
C
Ordenar por Valor
reglas de la gestión ágil D
Ordenar por Riesgo
◦ Se usan historias de D
Definir Velocidad
usuario escritas en C
Decidir Alcance
tarjetas
Recuperación D Fase de Maniobra
C
Nueva Historia
Iteración
Velocidad Cliente requiere
C
sobreestimada nueva historia
Planning Game de la Iteración
D
Desarrollo XP
Plan no es
adecuado
D
Ejecutar
Re-Estimar D Test
no
¿OK?
C
Funcionales Validar
si
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Gestión del Desarrollo en Equipo
Stand Up Meeting
Liderazgo Motivador
(Coaching)
Espacio de Trabajo Planning Game de la Iteración
Retroalimentación de Avance
Informativo
(Tracking)
Retrospectivas
Ritmo Sostenido
( No a las horas extra)
Ciclo de Desarrollo
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Planning Game de la Iteración

◦ Plan orientado al trabajo técnico (descomponer historias de
usuario en tareas)
StandUpMeeting

◦ Mini-reunión al comenzar la jornada, en que todos, de pie,
definen lo que harán
 Asi se va directo al grano
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Productividad Sostenida

(No al sobretiempo)
◦ Los equipos XP trabajan duro, y a un ritmo que puede
sostenerse indefinidamente. Esto significa:
 Se trabaja sobretiempo sólo cuando es efectivo, pero se entiende
como algo extra-ordinario
 Un proceso ordenado saca el mejor provecho del tiempo ya
asignado
 Un desarrollador cansado no produce más que uno descansado
 También llamado “40 horas a la semana” (aplicado a jornada
completa)
◦ Otra aplicación del timeboxing
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
¿Cómo alcanzar el justo medio entre…?

 Gestión centralizada
 Caos
Se definen dos roles

◦ Coach (Entrenador)
◦ Tracker (Medidor de avance)
… pueden ser cumplidos por la misma persona
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
Ayudar al resto a hacer un trabajo aún mejor
de calidad

Que todos tomen buenas decisiones

Estar disponible para ser socio de desarrollo (en especial de los novicios)

Vislumbrar objetivos de refactorización de gran escala, y promover las

refactorizaciones pequeñas que ayuden
Ayudar a los programadores con destrezas individuales

◦ Testing,
◦ Formateo y estandarización de código
◦ refactorización
Explicar el proceso a gerentes de mayor nivel

Proveer de juguetes y comida 

agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Usar métricas para medir el avance del proyecto (solo las

indispensables)
◦ Por ejemplo:
Tiempo de desarrollo / Tiempo calendario
◦ Actualizarlas mínimo 2 veces por semana
Ayudar al Entrenador a

◦ Motivar al cambio de una manera gentil y no coercitiva
Mostrar la información en una Carta Grande y Visible para

todo el equipo en el Espacio Informativo
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Burn Down Chart:
Estado de Avance (Kanban) 

Horas de trabajo que quedan
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
En vez de pasar a
 
◦ diseñar-programar-probar- ◦ Diseñar continuamente, Probar
continuamente, Armar
depurar-armar-entregar,
continuamente , Revisar
continuamente y Entregar temprana
y frecuentemente
Diseño
Simple
Programación de a
Programación Incremental
Programación en Equipo
pares
(+ Mantener el
equipo rotando)
de Calidad
Desarrollo
Integración
Guiado por
continua
Tests
Estándares de Código
Refactorización
Propiedad Colectiva
de Código

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Programación de a pares

◦ Un computador, un teclado, un mouse, y dos
programadores
◦ Empírico
 código un 20% más simple
 15% adicional de productividad sobre el trabajo separado
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Propiedad Colectiva de Código:

todos son propietarios (y responsables) de todo el código
◦ NO existen módulos intocables
Estilo común de codificación:

Usar convenciones que permitan que cualquier desarrollador
pueda entender, usar y modificar el código desarrollado por el
equipo
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Propiedad Colectiva de Código:

todos son propietarios (y responsables) de todo el código
◦ NO existen módulos intocables
Estilo común de codificación:

Usar convenciones que permitan que cualquier desarrollador
pueda entender, usar y modificar el código desarrollado por el
equipo
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
Diseñar para lo que realmente se necesita

◦ Ojo: si nadie conoce el problema, es imposible saber qué se
necesita
◦ => hay que pensar continuamente el problema
También llamado “Diseño Simple”

◦ Simple = Elegante, Limpio, Directo
◦ Simple != Fácil
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
¿Qué define el mejor y más simple diseño?

Se siguen 4 guías en orden de prioridad
1.El sistema (código y pruebas incluidos) debe comunicar todo lo
que se desea comunicar
2.No debe existir código duplicado
3.El sistema debe tener el menor número de clases
4.El sistema debe tener el menor número de métodos
agustin.villena@gmail.com

Tests son programados antes de programar la implementación. Luego de

programar, se verifica la correctitud automáticamente
Aumenta la confianza del desarrollador en su código

Facilita el mejorar el código sin provocar errores en cascada

Herramientas:

◦JUnit : Java
◦NUnit : .NET
◦PyUnit : Python
◦CPPUnit : C++
◦etc.
agustin.villena@gmail.com

16-04-2009 agustin.villena@chileagil.cl

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
◦ Cuando dos segmentos de código hagan los mismo,
se refactoriza para combinarlos y simplificar el
código resultante… SIEMPRE
◦ Permite la implementación del llamado “Diseño
Emergente”, en contraste con “Diseño detallado”
agustin.villena@gmail.com

Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo
Ciclo de
Programación
de calidad
◦ Generar ejecutables funcionales periódicamente (a lo más
diaramente)
◦ Se valida además la integridad del código corriendo las suites
de tests de aceptación y de unidad
 Depende de tener un sistema de pruebas
◦ Ojalá sea automático
Cruisecontrol , de Martin Fowler
agustin.villena@gmail.com

Extreme programming

◦ www.extremeprogramming.org
WikiWiki entry point for XP

◦ http://c2.com/cgi/wiki?ExtremeProgr
ammingRoadmap
Scrum Development Process

◦ www.controlchaos.org
Gestión Ágil de Software
 www.chileagil.cl
◦ www.agilemanagement.net
Lean Software Development Artículos y Enlaces sobre Metodologías
 
Ágiles y su adopción e impacto en la
◦ www.poppendieck.com
industria local
Agile Alliance

◦ www.agilealliance.org
agustin.villena@chileagil.cl