La imagen que ven arriba es un resumen de las prácticas de XP (agradezco al profesor Agustín Villena por dejar su presentación con licencia Creative Commons), me voy a basar en ella para recorrer las cosas que me llevo de esta experiencia. Antes que nada, quiero indicar que las prácticas de las metodologías ágiles son flexibles y se deben adaptar a la realidad de cada proyecto y una buena parte de ellas puede ser usada en otras áreas aparte del desarrollo de software.
De la gestión del proyecto orientada al valor
En las metodologías ágiles se recomienda darle valor al proyecto lo antes posible a diferencia de las metodologías tradicionales donde el valor del proyecto solo se ve al final. Las diferencias que esto produce son sumamente notorias en lo que respecta a mi experiencia.
- Tener al cliente en el terreno: Esto es simplemente tener al cliente al lado en todo momento para poder hablar con el. Recordemos que el cliente es el usuario final del proyecto y por ende es quien mejor lo conoce. Cualquier pequeña consulta de los requerimientos debe ser realizada directamente con el así como cualquier sugerencia o idea (esto es algo que a los clientes les gusta mucho). Esto nos evita el tener que adivinar lo que el cliente quiere y el tener que cambiar las cosas cuando el cliente ve lo que hicimos. Como extra, el cliente obtiene una visibilidad completa de como se realiza el proceso de desarrollo y le permite comprender lo difícil que es el realizar software. Esto nos evita tener un cliente "gruñon" y este se transforma en un cliente comprensivo (literalmente). Esta es una práctica que definitivamente voy a aplicar y que de hecho exigiria. Tener al cliente disponible para hacerle consultas y sugerencias al mismo tiempo que se le da una visibilidad completa del proyecto es un cambio que nos salva de algunos de los problemas más desagradables del desarrollo de software.
- Realizar entregas pequeñas: Esto se hace para que el cliente pueda ver el valor de las funcionalidades implementadas mucho antes de que el software este terminado. Esto se puede considerar como los releases que se realizan en el desarrollo de software tradicional pero se realizan mucho más rápido. Los cambios que se hacen se notan mucho más rapido, y como tenemos al cliente al lado, este nos puede decir si hay que hacerle algunos cambios. Esta es otra práctica que me llevo. Me permite mostrarle valor al cliente mietras me da un feedback mucho más continuo del software que se esta desarrollando.
- Planning Game: El planning game es una forma de estimar los tiempos que demorara el desarrollo de las funcionalidades a desarrollar. De esta forma todo el grupo (incluido el cliente) puede saber cuanto tiempo demorara el tener las funcionalidades listas. Así que el cliente, tomando en cuenta el tiempo que queda para el proximo release, puede priorizar cuales tareas realizar. De este modo se puede entregar valor más rapidamente al entregar primero las funcionalidades que más valor aportan. Esta es una práctica que es un poco más dificil de llevarse dada la dificultad que suele estar presente a la hora de estimar el desarrollo de las funcionalidades. Sin embargo si el equipo tiene el conocimiento suficiente, esto se puede llevar sin problemas.
- Test de Aceptacion: El cliente puede realizar tests de aceptación los cuales califican si la funcionalidad esta cumplida o no. De este modo los desarrolladores tienen una forma rápida de validar su trabajo. Además de que de este modo evitamos molestar al cliente si es que no es necesario. Esta práctica es algo muy difícil de llevarse principalmente porque casí no hay clientes dipuestos a hacer esto.
En las metodologías ágiles el trabajo en equipo forma una parte importantisima siendo crucial en la obtención de resultados. El alcance usado aquí es muy distinto a las metodologías tradicionales donde se asignan roles y se dividen tareas. En las metodologías ágiles los roles no son fijos y los resultados son de todos. Las individualidades no existen.
- Liderazgo motivador (coaching): El lider del equipo es bastante diferente que en las metodologías tradicionales. En estas, el lider del equipo es un jefe cuya labor consiste en impartir premios y castigos a los desarrolladores. En otras palabras consiste en un jefe que mira por sobre tu hombro que estes trabajando todo el tiempo. En las metodologías ágiles esto cambia radicalmente. La labor del coach consiste en facilitarte la realización de tu trabajo. El es el encargado de distribuir la comida (golosinas) y los bebestibles entre otras cosas, así como asegurarse de que los desarrolladores tengan todo lo que necesitan para trabajar. El coach, no vigila que estes trabajando, sino que te da las facilidades para que lo hagas mejor. Aún así, el coach también puede imponer premios y castigos, aunque lo hace con una frecuencia muchisimo menor que un jefe y no suele ser común que ocurra. El coach también debe saber bastante de la programación que se esta realizando y funciona como un tutor, así que se le pueden hacer preguntas al respecto. Dentro de este contexto es también quien suele hablar más frecuentemente con el cliente. Esta es una práctica que me llevo con mucho gusto. Por experiencia propia puedo decir que se trabaja mucho mejor con un coach que con un jefe que mediante el acto de vigilarte te incomoda y te hace más difícil trabajar.
- Retroalimentación de avance (tracking): Esta es una práctica que resulta bastante útil cuando se acerca un release. Consiste en ver el estado de avance del proyecto de modo de poder descubrir rápidamente si se necesita enfocar recursos en determinadas funcionalidades para poder entregar el mayor valor posible en el release. También sirve para tener una idea de que tan acertadas son las estimaciones realizadas. Esta funcionalidad tiene el mismo problema que el planning game: estimar. Es dificil hacer estimaciones en un principio, pero una vez que se hacen, el tracking le añade un nuevo valor al poder descubrir el estado del proyecto sin dificultad. Para esto recomiendo usar los gráficos burndown que muestran el estado de avance con bastante claridad.
- Stand-Up meeting: Son pequeñas reuniones que ocurren al principio y al final de cada iteración. Son bastante útiles para determinar lo que se va a realizar al principio de cada sesión de trabajo y para dejar claros los resultados y planificar la siguiente al final de cada una. Son reuniones bastante breves que no deberían durar más de diez minutos y por esto los asistentes suelen estar de pie, de ahí el nombre. Como experiencia, les digo que es algo bastante útil, permite conectarse uno con el trabajo y con el trabajo de los demás. El unico inconveniente que le encuentro es el tener que llegar a la hora, pero eso es realmente por mi tendencia a llegar tarde :P.
- Espacio de trabajo informativo: Esta práctica es una las que más recomiendo debido a su enorme utilidad. Consiste en tener la información del proyecto en un lugar visible por todos, todo el tiempo, de manera que sea fácil de leer y actualizar. Un excelente ejemplo de esto (y aprovechando que estamos en la epoca) es el computo de la Teletón. Tenemos unos enormes números que indican el estado de avance que tenemos y cuanto nos falta todo el tiempo, y todos los ven. Se actualizan con frecuencia y de manera rápida. Espero que esto deje claro también la utilidad que tiene. En este espacio de trabajo (que en su oficina puede ser una pizarra o una cartulina con post-it) esta toda la información para que sea consultada y actualizada con frecuencia y facilidad. Uno de los principios que el espacio informativo debe cumplir es el del ventilador de información. Esto consiste en que la información te llega a la cara, no tienes que abrir ningún libro, closet o refrigerador para obtener la información.
- Ritmo sostenido (no a las horas extra): Tal como dice el nombre, esta práctica obliga a los miembros del equipo a trabajar el tiempo justo. Esto hace que todos los miembros del equipo se concentren en trabajar y evita el desgaste causado por las horas extras así como que alguién trabaje más horas que otro. Esta práctica es bastante buena para mantener al equipo en un buen estado, pero es bastante difícil de llevarse. La mayoría de los desarrolladores tienen las costumbre de trabajar horas extras y si además consideramos el hecho de que varios funcionamos con rachas de inspiración que nos cuesta mucho cortar. En otras palabras, es una buena práctica pero es muy difícil de adoptar.
- Retrospectivas: Esto consiste en tener una reunión al final de cada release que analiza todos los problemas que ocurrieron y las formas en que se puede evitar que pasen de nuevo. Hay que tener mucho cuidado de no indicar culpas, ya que la intención es salir adelante como equipo, para esto es necesario un buen coach. Para esto se puede reconocer al principio que todos hicieron el mejor trabajo que pudieron hacer en sus circunstancias. Esto es una buena práctica que permite que todos los miembros del equipo aprendan de los errores que cometieron sus compañeros y eviten el cometerlos. Me la llevo con gusto, para implementarla en futuras ocasiones.
- Programación de a pares (más rotación de equipos): Esta práctica consiste en realizar labores de programación en parejas, dos personas en un solo computador. Aunque pueden haber (y se recomienda tener) dos pantallas, solo uno de ellos puede estar en el teclado. El objetivo de esto es que un miembro de la pareja corrija y ayude a su compañero en las labores de programación. En principio esto puede parecer un malgasto de recursos al tener a una persona sin digitar código, pero la principal labor de un ingeniero de software no es digitar código, sino diseñarlo. La programación de a pares también permite una mejor distribución del conocimiento del trabajo del equipo, lo cual se logra aún mejor si las parejas van rotando cada cierto tiempo, ya que cada persona lleva su propio conocimiento del software más el conocimiento que aprendió de su compañero anterior. Esta es una práctica bastante recomendable, particularmente para proyectos complejos que requieren un conocimiento generalizado del software entre los desarrolladores. Particularmente para los que solemos cometer errores pequeños que despues cuesta mucho trabajo descubrir (que no son pocos), esta práctica resulta bastante útil y mejora su productividad notablemente.
- Estándares de código: El tener estándares de código consiste en tener un conjunto de recomendaciones y guías para que todos codifiquen un mismo problema de la misma forma. Esto permite que todos los desarrolladores entiendan el código escrito por sus compañeros. Esto ahorra varias dificultades de tener que trabajar en grupo haciendo que todos hablen el mismo lenguaje. Esta es una práctica que todo equipo de trabajo debiera tener. No es necesario que el estandar este definido en algún lado, muchas veces me ha tocado ver que surge de manera natural y definido por las mismas herramientas utilizadas, pero el estandar siempre tiene que existir.
- Propiedad colectiva del código: El código resultante del trabajo de todos es de todos. Aquí no existen el código individual, todos pueden leer y modificar el código de cualquier programador. Esto hace que todos sean responsables del trabajo del otro por lo que no existen las culpas. Si alguien se equivoca es culpa del que se equivocó y del resto que no le ayudo ni se dio cuenta. Esta es una excelente forma de promover el trabajo en equipo y la recomiendo.
- Diseño simple: Se evita el diseñar demasiado o diseñar cosas que no se han pedido, esto también es conocido como diseño JIT (Just In Time). La ventaja de esto es que evitamos diseñar cosas que no vamos a implementar mientras que al mismo tiempo mantenemos el diseño simple evitando posibles complicaciones. Esta es una práctica que siempre es recomendable. La metodología tradicional diseña todo el sistema antes de ponerse a implementar, esto nos lleva a una alta probabilidad (certeza) de que el diseño cambie. En las metodologías ágiles el diseño también cambia, pero al haberlo hecho simple y en el momento en que era necesario, casi nunca hay un diseño previo que desechar.
- Desarrollo guiado por tests: En la metodoogía tradicional se suele hacer un proceso de test despues de haber implementado una funcionalidad. En las metodologías agiles es inverso, se hace el test y luego se implementa el código que lo apruebe. De este modo cuando el test es aprobado ya sabemos que esta listo y podemos volver a probarlo las veces que sea necesario al ir implementando nuevas funcionalidades. Otra ventaja de esto es que ayuda enormemente al diseño, antes de implementar la funcionalidad ya sabemos todo lo que tiene que hacer, por lo que la implementación sale mucho más rápido. A pesar de las ventajas de esto, yo no me lo llevaria a mi lugar de trabajo. El desarrollo guiado por tests requiere de librerias que no siempre son faciles de ocupar aparte del tiempo de aprendizaje ocupado, y dependiendo del tamaño del proyecto puede que la ventaja en el diseño no sea notoria. Además, hay cosas que no se pueden testear como el resultado de las imagenes o si algunas partes del diseño gráfico son del gusto del cliente. El desarrollo guiado por tests es bastante bueno, pero sus ventajas no siempre cubren los costos de implementarlo.
- Refactorización: Al haber cambios frecuentes en el código causados por varios programadores a la vez, es lógico que el código no quede siempre de manera optima. Entonces el coach realiza un porceso de refactorización que optimiza el código mediante diversos métodos como: agrupar código similar en funciones, agrupar archivos duplicados y limpiar funciones que no se usan entre otras cosas. Este es un proceso necesario cuando hay varios programadores trabajando en un mismo proyecto. Eventualmente e inevitablemente el código se empieza a desordenar y el proceso de refactorización se vuelve necesario.
- Integración continua: Cuando se termina de implementar una funcionalidad queremos que sea visible lo más pronto posible. Para esto usamos un sistema de integración continua como SVN que nos permite tener versiones del código actualizadas hasta la última funcionalidad correctamente implementada. Esta es una práctica que se ha vuelto muy común y no se si es necesario decir que yo la uso y la recomiendo. No es difícil de implementar y ofrece un buen sistema de tener el software actualizado de acuerdo a lo que hacen los desarrolladores.
De lo que he notado, la principal diferencia (o al menos la que más se siente) con la metodología tradicional para desarrollo de software es la presencia del cliente. un cliente en terreno y compometido con el software que se esta desarrollando influye mucho en la forma en que avanza el proyecto y es a mi gusto lo que hace la principal diferencia entre un modelo de cascada y un extreme programming. Sin la presencia del cliente habria que adivinar al ambiguedad de los requerimientos llevando a la posterior corrección por parte del cliente. Además esto le da al cliente una mayor visibilidad del proyecto, logrando entender así la complejidad de sus requerimientos y una mejor relación con el equipo de desarrollo. El tener al cliente al lado permite una mayor flexibilidad para lanzar los releases y mostrarselos al cliente haciendolo mucho más frecuente que si el cliente no estuviera. Esta constante presencia del cliente también permite el diseño Just In Time, ya que podemos hacer las correcciones en el mismo momento y sabemos que el cliente estará disponible la proxima vez que necesitemos hacer diseño. En mi experiencia, me ha tocado sufrir cambios bruscos de requerimientos por que el cliente no sabia lo que estabamos haciendo o porque alguien habia tenido que adivinar que es lo que queria el cliente.
Otra gran diferencia es la forma de tratar con el equipo de trabajo, sin roles definidos y siendo todos igualmente responsables del código. Al no haber culpas individuales y al ser los meritos del equipo el ambiente de trabajo que genera este es mucho más grato y el grupo esta mucho más unido y dispuesto a cooperar. Dentro de mi experiencia me ha tocado tratar con roles fijos y con poca comunicación en tre los miembros del equipo. Esto ha hecho que hayamos tenido que hacer reuniones de emergencia al ver que nos atrasabamos y entonces realizar una retrospectiva donde existía el sentimiento de culpa con la consiguiente perdida de moral por parte del equipo.
En mis proximos desarrollos, el objetivo es mejorar estos dos puntos: la presencia del cliente y la relación entre los miembros del equipo. Idealmente se tendra al cliente en el lugar todo el tiempo para hacerle consultas y se hara pair programming intercambiando los compañeros cada semana o en un tiempo menor. Enfatizar el hecho de que el código es de todos y que por lo tanto la responsabilidad sobre este también a fin de motivar el apoyo entre los miembros del equipo. Y por último pondría una pizarra con la información relevante del proyecto como un kanban e información sobre el diseño. De este modo se obtiene un buen ambiente de trabajo para cualquier proyecto. de acuerdo a las características del proyecto y del equipo de trabajo se pueden agregar más prácticas como la programación guiada por tests y el planning game.
