h1

The Art of Agile Development

03/15/2012

Wizbook [Icon By Buuf]  Libros.

Primero hazlo. Luego hazlo bien. Luego hazlo rápido.

— Anónimo.

The Art of Agile Development de James Shore y Shane Warden es un extenso compendio de tips y trucos para trabajar de manera óptima con Extreme Programming (XP). Aunque presenta algunos puntos generales relacionados a las metodologías ágiles, el libro está muy enfocado a XP de principio a fin, mostrando sus prácticas, roles y herramientas y explicando cómo pueden llevarse a cabo de la mejor manera posible. Recomiendo ampliamente el libro para todos aquellos que quieran incursionar en las metodologías ágiles, ya que la información es muy completa pues incluye una descripción detallada, secciones de preguntas y respuestas, contraindicaciones y alternativas de implementación para cada práctica de XP.

El libro está dividido en tres secciones: la primera muestra una pequeña introducción sobre la razón de ser de las metodologías ágiles, incluyendo el Manifiesto Ágil con sus valores y principios. Luego proporciona una introducción a XP; sus actividades, roles, ciclo de vida, requisitos y una multitud de conceptos que todo desarrollador o líder de proyecto ágil debería conocer: refactoring, timeboxing, historias, iteraciones o velocidad.

La segunda sección concentra todas las prácticas de XP: programación por pares, reuniones diarias, desarrollo orientado a pruebas y soluciones “de punta” (también conocidas como pruebas de concepto), por mencionar algunas de ellas. Ésta sección es bastante extensa, ya que contiene 37 prácticas que deben ser conocidas y dominadas perfectamente para llevar a cabo un buen proyecto con XP. Esto va más allá de las 12 prácticas originales, ya que incluye otras como gestión del riesgo, definición de “terminado terminado” (done done), uso de un lenguaje común ó pruebas exploratorias. Asimismo, los autores renombraron algunas de las prácticas originales para hacerlas un poco más comprensibles. Por ejemplo, la bien conocida práctica de limitar la semana laboral a 40 horas es descrita en el libro como “trabajo energizado”:

Práctica Planeación Análisis Diseño y Codificación Pruebas Despliegue
Pensando  
Programación por pares      
Trabajo energizado (40 Hrs./Semana)
Espacio de trabajo informativo        
Análisis de Causa-Raíz      
Retrospectivas      
Colaborando  
Confianza
Sentarse juntos (Cliente On-Site)  
Involucramiento real del cliente        
Lenguaje Ubicuo (Metáforas)        
Reuniones Diarias        
Estándares de código        
Demo de iteración        
Reporteo
Liberando  
“Terminado Terminado”      
Sin bugs      
Control de Versiones        
Build de 10 minutos      
Integración Continua      
Pertenencia colectiva del código        
Documentación        
Planeando  
Visión      
Planeación del Release      
El juego de la planeación      
Administración de riesgo        
Planeación de la iteración      
Holgura      
Historias      
Estimaciones        
Desarrollando  
Requerimientos incrementales      
Pruebas de usuario      
Desarrollo orientado a pruebas      
Refactoring        
Diseño Simplificado        
Diseño y Arquitectura Incrementales        
Soluciones “de punta” (Pruebas de Concepto)        
Optimización de desempeño        
Pruebas Exploratorias        

Cómo las prácticas de XP equivalen a las fases tradicionales del desarrollo de software. XP hace uso de iteraciones en vez de fases, por lo que el equipo realiza alguna de estas actividades al menos una vez por semana; la mayoría de éstas se implementa de manera diaria. (Fuente: The Art of Agile Development. Shore & Warden. (O’Reilly, 2007))

La tercera y última sección define algunos consejos a tomar en cuenta durante la implementación. Por ejemplo, que es necesario dar pequeños pasos a la hora de programar una solución, siempre considerando la retroalimentación del cliente. Esto se hace para que en caso de una metida de pata, podamos retroceder fácilmente, evitando desperdicio innecesario de recursos asignados, tiempo de desarrollo o esfuerzo en acciones de debugging. Esta sección es más bien para filosofar un poco al comparar la teoría contra la práctica.

Por qué hacer releases cortos

Uno de los capítulos del libro más interesantes tiene que ver con las liberaciones cortas en vez de un gran despliegue al final del proyecto. Además de la probabilidad de toparnos con más bugs o haber desarrollado funcionalidad innecesaria, si esperamos hasta el final del proyecto para hacer uso de características ya terminadas anteriormente, estamos desaprovechando una gran oportunidad de negocio: si realizamos liberaciones más pequeñas, será posible obtener los beneficios de la funcionalidad inmediatamente después de que ésta haya sido completada:

Efect of small releases on value

El efecto de pequeños releases en el valor total del proyecto.

Mientras el primer proyecto sólo obtendrá un beneficio marginal (6 × $) al final de seis meses de desarrollo, el segundo proyecto tendrá beneficios desde el segundo mes de iniciado ($$); al cuarto mes tendrá los beneficios del segundo release ($$) más los beneficios del primer release, que ha estado funcionando por dos meses ($$$$). Al sexto mes, el proyecto contará con los beneficios del primer release funcionando por ya cuatro meses ($$$$$$), el segundo release trabajando por dos meses ($$$$) y el último release ($$). Al final de ambos proyectos, la segunda implementación claramente posee un mayor valor de retorno (6 × $ vs. 10 × $).

Otra manera de apreciar este efecto es liberando funcionalidad o características que pueden “marcar la diferencia”, tan pronto como sea posible. Una de las mejores anécdotas del libro lo dice todo:

Imagina que eres el gerente de producto de un equipo creando un nuevo procesador de texto. El mercado de los procesadores de texto es bastante maduro, así que puede parecer imposible crear un release inicial pequeño. Hay mucho por hacer para igualar a la competencia; aún más lo es proveer algo nuevo y atractivo. Necesitas formato básico, corrección ortográfica y gramatical, tablas, imágenes, impresiones… la lista sigue hasta el infinito.

Abordar un proyecto de procesador de texto de esta manera es intimidante, al punto de parecer un esfuerzo inútil. En vez de tratar de igualar a la competencia, es mejor enfocarse en las características que hacen de tu procesador de texto algo único. Debes liberar aquella funcionalidad primero – probablemente, ésta tendrá el mayor valor.

Supón que la diferenciación competitiva de tu procesador de texto radica en su poderosa capacidad de colaboración y alojamiento en la web. El primer release tiene cuatro características: formato básico, impresiones, alojamiento desde la web y colaboración. Publicarás éste primer release como un preestreno técnico para generar anticipación. Subsecuentes liberaciones pueden mejorar las características básicas justificando una cuota: tablas, imágenes y listas en un release; corrección ortográfica y gramatical en otro, etcétera.

Si esto parece descabellado, considera a Writely, la aplicación de procesamiento de texto en línea. Ésta no posee la cantidad de características que tiene Microsoft Word y probablemente no la tendrá en muchos años. En vez de eso, se concentra en lo que la distingue por mérito propio: colaboración, edición remota de documentos, almacenamiento seguro en línea y facilidad de uso.

De acuerdo al inversionista de capital de riesgo Peter Rip, los desarrolladores liberaron la versión alfa de Writely dos semanas después de que decidieron crearla. ¿Cuál es el valor de hacer liberaciones tempranas? Pregúntenle a Google. Diez meses después, ellos compraron Writely, aunque éste ni siquiera estuviera cerca de poseer el conjunto de características de Microsoft Word. Writely es ahora conocido como Google Docs.

The Art of Agile Development. Shore & Warden. (O’Reilly, 2007).

A la misma bati-hora, en el mismo bati-canal

Otra cosa que me llamó la atención acerca del libro es que éste posee conceptos que no se encuentran en los ensayos originales de Kent Beck (“padre” de XP) y algunos de éstos, no aparecen en ningún otro lugar. Por ejemplo, en el libro aluden a un rol que yo desconocía por completo: el Batman.

Lidiar con peticiones de emergencia de vez en cuando está bien – es una buena manera de mantener al equipo reaccionando con entusiasmo. Por otra parte, una emergencia en cada iteración significa que algo está mal.


En algunos casos, sin embargo, el equipo posee una necesidad legítima de proveer soporte continuo para solicitudes ad-hoc. Si esto es cierto en tu equipo, sacrifica un programador para convertirlo en el Batman.

“Batman” es un término militar así como un personaje del comic: éste se refiere a un soldado asignado a lidiar con faenas rutinarias de tal forma que los oficiales se puedan concentrar en sus propias responsabilidades. En un equipo XP, el Batman lidia con emergencias organizacionales y solicitudes de soporte de tal forma que los otros programadores puedan enfocarse en desarrollar. El Batman no tiene otras obligaciones: no trabaja en historias de usuario ni en el plan de iteración.

Debes rotar a un programador en el rol de Batman por cada iteración para prevenir el así llamado síndrome de desgaste ocupacional (ó burn-out). Si la carga es particularmente pesada, posiblemente necesites dos o más Batmen por cada iteración.

The Art of Agile Development. Shore & Warden. (O’Reilly, 2007).

Cabe mencionar que en mi experiencia, la mejor manera de lidiar con este tipo de emergencias es cambiar la manera en que estamos trabajando: Scrumban es lo primero que apareció en mi mente para prevenir la pérdida de un integrante del equipo ante bomberazos constantes.

Sin embargo, éste y otros tantos conceptos originales hacen su aparición a lo largo del libro, y aunque muchos de ellos ya son conocidos por todos, es interesante ver el tratamiento que les dan los autores.

Conclusiones

The Art of Agile Development es una lectura obligatoria para todos los practicantes novatos que deseen familiarizarse con los conceptos del desarrollo ágil, o en el caso de aquellos que ya se consideran experimentados, para refinar y enriquecer sus conocimientos. De hecho, sin importar si queremos manejar XP, Scrum, DSDM o cualquier otra metodología ágil, deberíamos echarle una ojeada a éste libro, porque proporciona un buen fundamento teórico sobre cuál basar nuestros proyectos de desarrollo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: