Vimos la semana pasada un poco de historia sobre Extreme Programming y su creador, Kent Beck. Veamos ahora los valores y fundamentos detrás de XP y que hacen que este funcione:
Simplicidad: Se trata de usar la solución que funcione que sea la más simple posible. Aprovechar el concepto de la Navaja de Ockham o seguir el principio KISS (Keep It Simple, Stupid) para desechar ideas demasiado complejas y no hacer over-engineering.
Para ello se tomarán pequeños pasos hasta el objetivo y se iterará hasta conseguirlo. Se adaptará por el camino a lo que se haya aprendido en lugar de pensar una solución compleja al inicio y desarrollarla al pie de la letra.
Comunicación: Kent Beck se dio cuenta de que muchos de los problemas en los equipos de trabajo se debían a que no había una correcta comunicación entre sus miembros. Para ello propone:
- Que todos los miembros del equipo de trabajo se comuniquen cara a cara de forma diaria (similar a las reuniones diarias de Scrum)
- Que todo el mundo trabaje en todas las partes del proyecto, desde la toma de requisitos hasta la codificación.
- Que se cree un sentimiento de pertenencia al equipo y de cooperación entre todos los integrantes.
Coraje: Se trata de crear un ambiente en el que no haya miedo a ser castigado o criticado por cometer un error o por ir retrasado en su tarea. Un ambiente en el que cada persona se sienta libre de decir cuál es realmente el estado en el que está la tarea en la que está trabajando.
Se quiere conseguir la valentía suficiente para que se tomen decisiones libremente porque se busca lo mejor para el proyecto. Se trata de evitar, por ejemplo, que se documenten páginas y páginas de lo que realmente son excusas. Cuando se escribe mucha documentación en realidad se quiere decir “Se me dijo así por lo que yo diseñé/implementé esto”. De esta forma se quiere que nadie pueda poner un “pero” a la decisión que se ha tomado.
Feedback: En XP se da por sentando, que no se puede implementar la opción correcta a la primera. Se debe iterar y volver a mejorar la opción tomada o desarrollar una diferente. Para conseguir esto se necesita obtener retroalimentación de lo que sucedió en la iteración anterior para poder mejorar.
Se generará tanto feedback como se pueda manejar y tan rápido como sea posible. Se irá más despacio si el equipo no puede adaptarse a tanto feedback recibido.
El feedback puede venir en muchas formas posibles, por ejemplo, en resultados de los test ¿Funcionaron? ¿Qué falló? Opiniones de los clientes que ya están usando la aplicación, o funcionalidades introducidas en la aplicación ¿Recibieron muchos clics? ¿Las completaron? ¿Han preguntado por ellas?
Respeto: Es el valor que resume los otros cuatro y sin el que los demás no funcionarán. Si no hay respeto entre los miembros del equipo y éstos no respetan al proyecto y sus compañeros difícilmente se obtendrá un feedback correcto. No tendrán el coraje suficiente para tomar las mejores y más simples decisiones y fallará la comunicación. Nadie, en un equipo de trabajo que usa XP, es más importante que nadie. Ni lo es el jefe del proyecto sobre el resto de miembros ni lo es el ingeniero software sénior con muchos años de experiencia en el trabajo.
