En un post anterior comentamos lo que creemos que es mejor en Scrum. Ahora hablaremos de XP. Tengo puntos de discordia en XP, especialmente en relación con los requisitos, los requisitos no son las conversaciones en curso como muchos de XP piensan, entonces cuando hablamos de casos de uso no se trata sólo de algo más de niveles de detalle. Podemos utilizar las historias de usuarios sin ningún problema, pero en algunos contextos, no será la mejor solución.
Pero este post no es para hablar de las diferencias de los casos de uso y las historias de usuario, como he dicho antes vamos a hablar aquí de las cosas que me parecen muy saludables en XP, tales prácticas en valores son concebibles para varios proyectos en varios contextos.
Cuatro Valores
Veo muy válido que una metodología de desarrollo de software como XP se centre en valores, es común ver papeles, prácticas, guías, lujo de trabajo, pero ¿principios? no es muy común, pero creo que es muy válido, porque en determinadas situaciones solamente el uso de estos principios harán que el cambio se produzca.
Los cuatro valores de XP son: Comunicación, Simplicidad, Feedback y Coraje. Son valores simples que deben ser usados, incluso como valores en su vida personal, pero ¿por qué utilizar esos valores en el desarrollo de software?
Porque muchas veces para cambiar una situación precisamos coraje. Este coraje puede significar ser sincero y honesto con usted mismo para empezar y luego con la empresa para la que trabaja, a menudo la tortuga se encuentra en la cima del poste para que no exista otro lugar para ella, entonces siempre tienes que estar custionando el que, como y por qué estamos haciendo algo.
La comunicación es clave, fundamental, pero no es porque hay personas en una habitación que la comunicación existe. En muchos casos la única comunicación que ocurre allí es porque existe la dependencia de tareas, hacer que las personas en un proyecto conversen sobre lo que hacen y lo que quieren hacer es la forma para aumentar la participación de las personas en el proyecto, así como comenzar a formar un equipo en lugar de un grupo.
La simplicidad es algo que debería ser objetivo de todos, por increíble que parezca es difícil hacer algo simple, como dijo Leonardo da Vinci: "La simplicidad es el último refinamiento." O como pregona la filosofía KISS: Manténgalo Simple, Estúpido. La Simplicidad ha de ser la forma de trabajo del equipo, desde la arquitectura, hasta el código.
Simple es diferente a simplista
Aquí debemos tener cuidado. Simple no significa simplista, la cuestión no es subestimar las cosas al punto de subestimar la complejidad de cosas. Sino que el detalle es eliminar la complejidad, esto no es posible siempre, entonces debemos tratar de reducir la complejidad a través de abstracciones y el objetivo es reducir la complejidad y no aumentarla. Para que las cosas sean más fáciles debemos tener una arquitectura simple, una metáfora simple, eso no significa fácil.
Simplista es algo que llega a ser estúpido, otra vez, este no es el foco. Ser simple es fundamental, eso facilita el trabajo de los otros en el equipo, no estoy hablando sólo de la simplicidad en la arquitectura, sino en el proceso y en la gestión también.
El temor al feedback
Muchas personas tienen miedo al feedback, así como tienen miedo al cambio. Los cambios de paradigmas son complicados para la mayoría de las personas, como decía el gran Tom De Marco, la primera respuesta al cambio es siempre emocional. Entonces no se apegue a la primera respuesta de las personas, tenemos que encontrar la manera de eludir la situación, todo lo que le hablamos a las personas está en el subconsciente de ellas y en más tiempo o menos tiempo eso comienza a actuar sobre ellas y cuando menos lo piensan ya han modificado su presente.
Volviendo a Coraje
No tenemos que estar contentos con el ritmo de las cosas en nuestra empresa, los límites y las normas existen para ser rotas, lo más importante es hacer que las cosas sucedan aunque para que las personas salgan de la inercia a veces se necesita dar algunos 'empujones'. No todo el mundo tiene el perfil para hacer cualquier actividad en un equipo, tiene que ayudar al equipo a descubrir, saber quien es bueno en eso y centrarse en esos puntos positivos de las personas.
Volviendo a la comunicación
Todavía existe una fuerte cultura en Argentina de que algunas personas no deben saber ciertas cosas, hasta cierto punto estoy de acuerdo con eso, pero en una escala mayor estoy en desacuerdo con esa visión. Cuando las personas están en un proyecto de desarrollo de software se encuentran como en un barco y todo el mundo quiere saber dónde va el barco y qué tan cerca pasará de las rocas puntiagudas.
Las personas pueden no hablar con vos, pero todos se sienten mucho mejor y empiezan a participar más activamente en el proyecto cuando saben la dirección o el rumbo del mismo. Conocer el curso del proyecto significa saber lo que las personas están haciendo y por qué los están haciendo y cómo lo están haciendo. Esto no significa pasar todos los detalles, aunque no es nada que no se pueda lograr con la práctica de la reunión diaria de a pie.
Todas las prácticas de XP se han diseñado de acuerdo con estos 4 valores, las prácticas se ayudan unas a otras, también las prácticas de XP como refactorización, integración continúa, programación en parejas y otras se centran en desarrollar y ayudar a mejorar la comunicación del equipo, esta es una de las principales diferencias de XP con otras metodologías.
¿XP es desorden?
No, XP no es desorden, XP tiene buenas prácticas como la práctica de los grandes gráficos visibles para todos en la habitación del proyecto, así como la práctica de Tracker. Para hacer XP necesitás mucha disciplina y al contrario de lo que las personas piensan si estás sin formalismos y con un método más libre eso no significa que estás utilizando XP.
XP se centra en los valores, además de establecer las prácticas mas próximas al desarrollo de software y pruebas, y eso ayuda a mejorar la calidad del código, así como la comunicación del equipo.
