Introducción Ágil a eXtreme Programming

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


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


Y en Chile, ¿será mejor?

◦ ...


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


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?

Equipo de Desarrollo

Lidiar con el Riesgo
¿Causa del Riesgo?


La incertidumbre


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!


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


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


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


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”


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


Única zona
donde hay
Valor para el cliente


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


• 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


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


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


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


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


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


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


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í?


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


Visión tradicional ¿Y si fuera así?
 


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


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?


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


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)

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

D
Desarrollo XP
Plan no es
adecuado
D
Ejecutar
Re-Estimar D Test
no
¿OK?
C
Funcionales Validar
si


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




Ciclo de
Programación
de calidad


◦ 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




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




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




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 





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




Ciclo de
Programación
de calidad

Burn Down Chart:
Estado de Avance (Kanban) 

Horas de trabajo que quedan




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




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




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




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


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.




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”




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

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


Introducción Ágil a eXtreme Programming

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Introducción Ágil a eXtreme Programming

Ähnlich wie Introducción Ágil a eXtreme Programming (20)

Mehr von ChileAgil

Mehr von ChileAgil (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Introducción Ágil a eXtreme Programming