He empezado esta semana a leerme la segunda edición del libro de Extreme Programming Explained (2004), escrito por Kent Beck y Cynthia Andres. Sinceramente, pensaba que tendría otro tono del que tiene realmente, y me está sorprendiendo gratamente.
Valores que comparte Extreme Programming
El libro comienza explicando qué es XP y por qué surge. Tras la introducción, que es buenísima, pasa a hablar de qué valores y principios se necesita tener interiorizados en un equipo de desarrollo para que XP funcione de verdad. Expone 5 valores básicos (comunicación, simplicidad, feedback, coraje y respeto) pero que no serán los únicos en cualquier equipo, sino que cada uno a partir de aquí tendrá los suyos propios definiendo así su propia cultura.
Comunicación:
- para compartir conocimiento
- para evitar problemas
- para conseguir una cooperación efectiva
Simplicidad:
- «What’s the simplest thing that can possible work?«
- para eliminar complejidad innecesaria
- para tener soluciones adaptadas al conocimiento del equipo
Feedback:
- para ir reorientando el camino
- para ayudarnos a tomar decisiones: cuando no sabemos qué hacer, elegimos un camino y vamos comprobando
- «Being satisfied with improvement rather than expecting instant perfection«
Coraje:
- «Effective action in the face of fear»
- para tomar acción: si sabes qué problema tienes, haz algo con ello
- para tomar acción pero con control, combinándolo con los otros valores
Respeto:
- Es necesario que te importe el resto del equipo
- Es necesario que te importe el proyecto/producto
- Es necesario que todas las contribuciones sean consideradas
- «No one is intrinsically worth more than anyone else«
Más valores ágiles
Resulta que si buscas los valores Scrum (compromiso, foco, apertura, respeto y coraje) te das cuenta que «respeto» y «coraje» se repiten con respecto a XP. Qué curioso.
El respeto es un valor que creo que se entiende sin necesidad de explicación. Kent Beck coloca al respeto como base transversal sobre la que se apoyan el resto de valores, y yo estoy de acuerdo con esa visión. Qué menos que sentirnos parte equitativa de un conjunto mayor, donde todos valemos y participamos por igual. Solo así podemos crecer juntos como equipo.
Y si nos centramos en «coraje»… quizás sí que podamos indagar un poco más en por qué es importante en los mundos de desarrollo de software.
¿Por qué «coraje» especialmente?
Un poco de historia
Durante muchos años, el desarrollo software se ha entendido como un trabajo de «ordeno y mando»; un trabajo donde, si eras la persona que generaba el negocio, no hacía falta pensar mucho para sacarle rentabilidad:
«¿Necesitamos hacer un proyecto a un cliente en tiempo récord y además ya hemos hecho uno parecido en el pasado? ¡Genial! Copiamos y pegamos, cambiamos estas tres cosas para adaptarlo al nuevo cliente, y voilà. Ya lo tenemos. ¡Wow! ¡Cuánto beneficio tiene trabajar así! Creo que vamos a dedicarnos a hacer esto una y otra y otra vez»
¿Qué ha ido pasando con proyectos guiados con esta filosofía?. Que cuando ha habido que mantenerlos o cambiarlos a posteriori (cosa que siempre o con mucha probabilidad pasa), el desarrollador que estaba frente a la pantalla en ese momento (seguramente, no fuera ni el mismo desarrollador que programó el proyecto inicial) quería pegarse un tiro: aquel código era incomprensible e intocable. Tocaras donde tocaras, bugs salvajes aparecían en los lugares más inesperados. ¿Y en qué se convertía eso? En retrasos con respecto a contratos de los proyectos, en broncas de los jefes, en frustración por trabajar con código que te producía arcadas y en sentirte solo e incomprendido; ya que por más que le explicaras a tu jefe el estado del proyecto, no llegaba a entenderlo: «¡Pero si hace 2 años lo hicimos en la mitad de tiempo! ¿¿por qué ahora cuesta el triple??«. Mucho mucho mucho sufrimiento.
Entendiendo los problemas que produce la falta de coraje
¿Qué ha pasado? ¿Por qué hemos llegado a este punto donde parece que ya nada tiene solución?. Obviamente, hemos dejado pasar demasiado tiempo sin afrontar ciertos problemas:
- El primer desarrollador que empezó el proyecto, no pensó en hacerlo mantenible para 5 ó 10 años. Cuando empiezas a crear software lo haces lo mejor que puedes, con tu nivel de competencia en ese momento, y además puede que juegues con limitaciones de tiempo o jefes que demandan y demandan sin escuchar otras alternativas. Es muy posible que, desarrollador tras desarrollador en esos 5 ó 10 años, no tuvieran la energía suficiente como para explicar a los jefes otros enfoques necesarios a hacer, y simplemente continuaran por inercia manteniendo lo que había: «apaño por aquí, ñapa por allá, pim, pam… ¡salimos airosos del hito! ¡bravoooo!«. Éxitos a corto plazo (¿a quién le importa el medio-largo? a lo mejor ni sigo en la empresa para entonces).
- El proyecto por fuera parecía que estaba bien hecho, pero por dentro era un monstruo de dos cuerpos y tres cabezas. Así fue engañando a todos los que tenía aplaudiendo el éxito alrededor.
- Se establecieron y arraigaron creencias en cerebros de ciertos managers con estas nuevas estadísticas: «Para hacer esto se tarda X tiempo siempre. Lo tomaremos como patrón para estimar y seguir ganando dinero«. Falsa creencia con la que todos estaban comodísimos en ese momento.
- Volvió a surgir un proyecto similar, y a un jefe se le encendió la bombilla: «¡Oh! ¡Podemos reutilizar el código del proyecto PEPE, que seguro que es muy parecido, y como tardaremos X tiempo, lo podemos vender a tanto con tanto beneficio!«. Como no es costumbre involucrar a los desarrolladores en la estimación y venta de los proyectos en una mediana-gran empresa, los jefes se comprometen a scope, deadline y precio fijo con el cliente («¡no hay problema! ¡lo tenemos todo controlado!«). ¿Os suena el triángulo de hierro?. Pues eso mismo.
- Y… ¡bum! El presente. Un nuevo equipo de desarrolladores tiene que hacer la implementación de ese nuevo proyecto, el cual no conocen, y que cuando lo abren y destapan, «¡Oh sorpresa!«, tiene más deuda técnica que código: «no es escalable para el caso que nos ocupa esta vez; hay que cambiar aquí, aquí, aquí y aquí para hacer lo que requiere este proyecto y este cliente«.
¿Cuándo habría que haber tenido coraje?
Primera oportunidad: cuando preveemos
Como profesionales competentes sabemos cuándo no estamos haciendo un trabajo de calidad, y qué va a suponer seguir por caminos de «ñapas» en el futuro. Es nuestra responsabilidad poner las cartas sobre la mesa y plantarnos si no estamos cómodos con la velocidad que se nos pide, si lo que estamos produciendo no tiene la suficiente calidad como para poder mantenerse en el futuro (futuro cercano, medio o lejano). Si la calidad que el código necesita no encaja con el tiempo estimado, es nuestra responsabilidad decirlo abiertamente y que lo entienda todo el mundo involucrado (especialmente los managers).
Segunda oportunidad: cuando es demasiado tarde y la realidad aprieta
Tras la puesta en común del equipo, y tomar una opinión al respecto de la situación actual, pueden pasar dos cosas:
- O que el equipo se queje internamente, sufra en silencio e intente ir sacando el proyecto como puede poco a poco, pero sin manifestar y afrontar de cara el problema (alertando bien a quien haya que alertar – jefes con expectativas -)
- O que el equipo afronte de verdad el problema y no quiera seguir ocultando fango debajo de la alfombra ni un minuto más. En este caso el equipo podría afrontar el problema de varias maneras, pero la que se me ocurre mientras escribo podría ser: «reunión el próximo lunes con los jefes involucrados, con datos, hasta que consigamos exponer el problema que existe y se entienda tal y como lo entendemos nosotros«.
Coraje en el día a día
Pórtate bien, sé responsable cada vez que te remangues a tirar código:
- Refactorizar un poco cada día debería ser un mantra (aunque eso suponga cargar más horas en Jira a la tarea correspondiente y que un manager, Scrum Master o quien sea pregunte «¿por qué se ha tardado 10h y no 5h?«. Se explica con seguridad, y a otra cosa).
- Seguir la ley del Boy Scout: «deja el
campocódigo por el que pasas mejor de lo que te lo encontraste«. - No trabajar solos por norma, no queremos héroes solitarios, somos un equipo (aunque eso suponga que haya gente alrededor que nunca haya trabajado así que cuestione si estamos perdiendo tiempo por hacer pair programming o mob programming. Se le contesta con seguridad: «Los beneficios de trabajar así son éstos, esta es nuestra cultura de equipo y como profesionales es como queremos/debemos trabajar«).
- Desarrollar testeando. Si no haces tests que comprueben que el código que creas funciona estás arriesgándote a que la lógica de negocio se rompa en algún punto y condenando a tus compañeros de equipo cuando les toque pasar por ese código. No programes «salvajemente» (aunque eso suponga pedir formación porque no sabes hacer tests ¡¡y quieres/debes hacer tests!!, o eso suponga tardar un poco más en hacer la tarea correspondiente que tienes entre manos. Luego se explica con coherencia y seguridad a quien haga falta, porque es de ser responsables)
- Conocer y preocuparte por saber más sobre cómo producir código de calidad, cómo construir mejor software. No conocer conceptos (en mundos de desarrollo OOO, por ejemplo) como principios SOLID, clean code, patrones de diseño, filosofías como KISS o YAGNI… hace que tu código esté muy acoplado y que sea muy difícil de mantener a posteriori, por ti mismo y por los compañeros que vendrán (y si para eso hace falta más tiempo para formación, ¡pídelo! ¡reclámalo como profesional que eres y que quieres ser! ¡estás en tu derecho! te lo dice una Scrum Master, que es la que cuida la velocidad del equipo: ¡¡¡¡pero una velocidad que sea sostenible en el tiempo, no nos equivoquemos!!!!)
Como desarrollador profesional que eres: «si sabes qué problema tienes, haz algo con ello». Se necesita que tomes partido, que reclames a tus jefes lo que haga falta para poder trabajar bien y que te formes constantemente. Explícalo con confianza, activamente y con asertividad a cualquiera que le interese.