Putting it together

by Luismi Cavallé

Para poder, siguiendo el hilo del último post, reducir repentinamente el scope de una iteración llegado el caso será necesario haber desarrollado siguiendo un determinado orden.

Una opción tentadora es desarrollar dirigidos por la arquitectura. Es tentadora desde el punto de vista individual, ya que, “oye, ya que estoy con la base de datos, voy a crearme todas las tablas que necesito”, aunque sean de distintas funcionalidades porque “al final las voy a tener que hacer igual y ya que estoy…”. Cuando acabo con las tablas me ocupo de los modelos. Con la misma idea: “venga, me escribo todos los tests de mis modelos, así luego implementarlos es sencillo, además gracias a los test sé cuando he acabado de trabajar con el modelo. Así que lo hago y me olvido del modelo…”. Y así sucesivamente.

Desde el punto de vista del grupo también es tentador (y clásico) tener gente experta en cada capa. El super-DBA, amo y señor de la base de datos. El que se lleva mejor con el backend, muy familiarizado con el TDD y que deja un modelo testado y coherente. Luego tengo al crack del front-end, que es un figura tanto de css y html como de javascript y flash. Sin duda resulta muy atractiva la idea de la especialización, con los mejores profesionales en cada área parece que el producto final vaya a tener más calidad y además de manera más productiva.

El problema de dejar que la arquitectura dirija el desarrollo es que, en general, durante una iteración no se tiene nada acabado hasta el final. Esto hace imposible reducir el scope en caso de que lo necesitemos. Tampoco se tiene una idea precisa del avance de la iteración, no sabemos si llevamos retraso o no hasta el último momento, pues no hay ninguna funcionalidad acabada y no se dispone de ningún otro indicador al respecto. Por último, los problemas de integración tienden a aparecer solo al final, pues no es hasta entonces cuando realmente se puede probar la funcionalidad completa.

Seguir un enfoque donde sea la funcionalidad la que dirija el desarrollo quizá sea más exigente. Implementar una funcionalidad completa cada vez (incluso dividiendo cada funcionalidad en mini-funcionalidades) exige al desarrollador ser capaz de cambiar el chip continuamente entre capas y además manejarse comodamente en todas ellas. En realidad exige más del desarrollador pero, a cambio, le ofrece mucha más diversión. En todo caso, además de diversión al programador (cosa que sí tiene importancia y por eso se menciona), seguir un enfoque de este tipo ofrece otros beneficios. Estamos creando software funcional mucho más pronto. Esto nos permite tener una idea clara del avance de la iteración y permite identificar desviaciones muy pronto (algún día hablaremos del gráfico burndown). Tenemos más capacidad de reacción y en todo caso siempre software funcional, algo que entregar. El riesgo relacionado con la integración se limita ya que los problemas de integración se afrontan pronto y sobre el scope reducido de cada funcionalidad —y es que eso de la integración continua no consiste solo en instalarse el CruiseControl.

En definitiva, somos más flexibles y estamos más preparados para el cambio. ¿Que vamos a necesitar profesionales con más talento? Desde luego. ¿Acaso alguien duda de que se necesitan profesionales con mucho talento para desarrollar software en serio?