Comentando el libro “the art of agile development”

XP
Imagen de http://www.extremeprogramming.org/

Introducción

El libro the art of agile development trata de TODAS las etapas de un desarrollo utilizando XP. He escrito todas en mayúsculas porque el libro es muy completo y habla de cada etapa con mucho detalle.
Los autores del libro son James Shore y Shane Warden. James Shore lo conocía de antes porque tiene una página sobre TDD en Javascript que tiene muy buena pinta:

http://www.letscodejavascript.com/

Dentro de cada capítulo hay un apartado con posibles preguntas que nos podemos hacer, problemas que podemos tener y posibles alternativas a ciertas prácticas.
Al ser un libro muy completo y con muchos detalles, es muy fácil el encontrar una pequeña joya en forma de consejo en muchas de sus hojas.

Hay, a continuación, un apartado sobre XP y luego una serie de conceptos que aparecen en el libro y que me han gustado especialmente. Estos conceptos son root cause analysis, informative workspace, pair programming y theory of constrains.

XP

Extreme programming (XP) es una metodología que a diferencia de otras metodologías Agile se centra mucho en prácticas para los programadores.
Así, dentro de las prácticas de XP tenemos pair programming, TDD, simple design y refactoring.
Todas estas prácticas permiten que el equipo se centre en llegar a la excelencia técnica, que es uno de los principios detrás del manifiesto Agile.
Creo que tener estas prácticas es algo que la diferencia de otras metodologías y que puede hacerla que tenga mayor número de éxitos, pero que a su vez resulta complicado de implantar al tener más prácticas que, por ejemplo, Scrum.
Si quieres saber más sobre XP, en la siguiente página hay mucha información sobre esta:
http://www.extremeprogramming.org

Root cause analysis

Root cause analysis es un método que nos permite llegar a la raíz de un problema. En nuestro caso, lo podemos utilizar cuando nos encontremos con un error en nuestro código de producción.
Cuando nos encontremos con un problema en nuestro código debemos de preguntarnos 5 veces el porqué se ha producido.
Una cosa importante sobre este tema y que comentan en el libro es que resulta fácil el culpar a una persona del problema, pero que detrás de la persona tenemos nuestro proceso de desarrollo, por lo que si tenemos que culpar a alguien hay que culpar a nuestro proceso y, luego, intentar mejorarlo.

Informative Workspace

La idea es muy simple, añadir información relevante relativa al proyecto en la zona de trabajo.
Tener una zona de trabajo con información del proyecto permite a todo el equipo y a la gente fuera del equipo el ver el progreso de este, simplemente caminando alrededor.
El objetivo principal de esta práctica es la información. Difundir información entre todas las personas involucradas en el proyecto.
Los gráficos deben de estar en este espacio porque permiten de una forma simple, eficaz y sin malentendidos el informar. Hay principalmente dos gráficos en XP y son: iteration plan y release plan.
También comentan que es mejor utilizar un bolígrafo y un papel en vez de pantallas, debido a que nos da más flexibilidad y en que de un solo vistazo se puede ver todo.
Creo que otra de las cosas en las que ayuda estas prácticas es en aumentar la confianza de los stakeholders en el equipo ya que pueden ver en todo momento el estado del proyecto.

Pair programming

Lo primero que llama la atención sobre pair programming en el libro, es que esta en la sección de pensar (thinking). Lo que nos da una idea para que lo utilizan los autores.

Esta práctica mejora, según los autores, el poder mental (brainpower) mientras estamos programando. Así, mientras el que esta programando (driver) solo esta pendiente de desarrollar, la otra persona (navigator) tiene como tarea la de pensar.
Cuando practicamos pair programming no es que dos personas este realizando el trabajo de dos, sino que se divide el trabajo, uno programa y el otro piensa. No es que el que programa no esté pensando sino que la pareja tiene mas tiempo para hacerlo.

He practicando pair programming en los coderetreat y todas las veces acabé muy cansando porque al estar con una pareja estas todo el tiempo concentrado al 100%. Otra gran cosa es que se aprende muchísimo y creo que en general todo el mundo tiene la misma sensación.

Theory of constraints

La teoría de las limitación dice que en todo sistema hay una y solo una limitación y que esta es la que provoca que se ralentice el sistema.

XP considera que la limitación en software development es el desarrollador. Eso es algo que se dice muchas pero que muchas veces en el libro.
Después de leerlo tantas veces estaba algo mosqueado porque aunque es cierto que los programadores podemos mejorar para que el sistema vaya mejor creo que hay otras posibles opciones. Como puede ser los managers que en muchos cosas ralentizán el trabajo de los programadores con sus decisiones, o la poca integración de la gente de negocio en el proceso de desarrollo.
Escribí un tweet y tuve la suerte de que jb me respondió.

Is the developers the constraint in software developer? why? @jbrains @ronjeffries
— Enrique Martín (@kikers25) January 21, 2015

 

Resumen

Aunque tiene unos años es un libro muy recomendable. Me ha ayudado a entender XP y todos las prácticas relacionados con XP.
Tiene muchos consejos sobre cómo implantar XP en una organización y creo que son muy útiles.

Personalmente, me encantaría practicar XP porque aunque sé que las primeras semanas o meses voy a estar muy cansado, debido principalmente a pair programming, voy a poder aprender muchísimo y creo que el resultado final va a ser un gran producto.

*Modificado 25-03-2015: añadido enlaces al libro e información de los autores