lunes, 31 de mayo de 2010

Estás realmente haciendo desarrollo ágil?(Traducido con permiso de Jake Scruggs)

Hace tiempo que los que escribimos este post venimos viendo como ha ido quedando de lado y, casi diría, en el olvido la metodología de desarrollo Extreme Programming, conocida como XP, que no trata solamente de prácticas de programación, una creencia bastante extendida. Lo que sigue es la traducción de un post interesante que escribió recientemente Jake Scruggs, Are you really doing agile development?, y que aquí publicamos con su permiso.

Recientemente en el trabajo me pidieron que ayudara a hacer a la compañia más "ágil". Bueno, como primero soy un desarrollador y segundo, un fanático estudioso de procesos, respondí con mi usual "Cuantas, de las 12 prácticas están realmente siguiendo?". Mi pregunta fue recibida con muchos ojos grandes y bocas abiertas. Parece que las 12 prácticas de XP clásicas no son fáciles de ubicar estos días en internet. Tambien parece que la palabra "ágil" (de las metodologías ágiles) ha sido tan exitosa en su difusión que muy poca gente parece recordar que XP significa Extreme Programming. Ahora bien, soy el primero en admitir que "Extreme Programming" es un nombre colosalmente estúpido, pero lo que me gusta de XP y sus 12 prácticas originales es que fueron controversiales y fáciles de evaluar: O bien las estabas siguiendo o no lo hacias.

Lo que no me gusta de la palabra "ágil" es que es tan amplia y definida de una manera tan difusa que casi cualquiera puede autoengañarse y creer que ya es completamente ágil.

Asi que, para solucionar esto, y ayudar a mi compañia a comenzar a medir mejor su "agilidad" , decidi listar las 12 prácticas de XP clásicas (A través del tiempo cambiaron...pero no para mi. Y mantenganse afuera de mi jardin!) y mi altamente subjetiva opinión sobre cada una de ellas. Al final les diré como calcular su índice de "agilidad".

* Planning Game o juego de planificación Obtener requirimientos del usuario, armar historias de usuario (cortas), estimar el tiempo que llevará hacerlas, hacerlas, medir velocidad, examinar estimaciones erradas para pistas acerca de como estimar mejor y repetir. Una historia es una promesa de conversación -- esto solo funciona si el usuario (o representante) está altamente disponible para los desarrolladores y los desarrolladores aprovechan esa disponibilidad chequeando constantemente dudas y presunciones durante el proceso de desarrollo. Nota: Historias que toman más de un dia para completarse reducen el éxito de otras prácticas de XP.

* Small Releases o versiones pequeñas LAs iteraciones deben ser de 1 o 2 semanas (dependiendo de cuan doloroso/caro sea organizar una iteración). Despues de cada iteración se debe implementar una versión en productivo si la aplicación es fácil de desplegar (como por ejemplo una aplicación web).

* Metaphor - Metáfora Nadie sigue esta práctica, puntos extras si tu lo haces.

* Simple Design - Diseño Simple Esto significa distintas cosas en distintos niveles. Cuando se esta empezando un proyecto desde cero, una semana de relevamiento de requerimientos y diseño esta bien. Para una historia individual, diseñar desde unos minutos hasta una hora está bien. Después uno comienza a programar. Importante: Se diseña a medida que uno desarrolla. Para para pasar unas horas en frente de un pizarrón está permitido, e incluso, alentado. Hacer la cosa más simple que pueda funcionar hasta que se vuelva obvio que no funciona. Entonces se rediseña. La idea es que el comienzo de un proyecto es el momento que uno sabe menos del mismo-- por eso hay que distribuir el esfuerzo de diseño a lo largo de la vida del proyecto de manera de poder tomar decisiones cuando uno tiene más conocimiento.

* Testing Testear antes de programar. Cubrimiento del 80% para Java, 90% para Ruby (menos chequeo de exepciones en ruby hace más fácil aumentar el porcentaje de código cubierto). Tests Robustos, atómicos, rápidos. (los Test de unidad deben correr en menos de 5 minutos, todos, en realidad es mejor si es menos de un minuto pero la mayoria cree que es imposible (Les adelanto la respuesta: ES posible )

* Refactoring - Refactorización de código En breve: Rojo, verde, refactorizar!, respuesta larga: Escribir un test que falle, hacerlo pasar, refactorizar el código. Tambien significa que cuando estás pasando por un lugar (de código) desordenado lo dejas un poco mejor de lo que lo encontrastes.

* Pair Programming - Programación de a pares

Más del 80% del tiempo. En serio. Tareas en las que parece que no se puede programar de a pares a menudo significan que no estas usando las técnicas de pair programming correctas. Programar de a pares es una habilidad sobre la que se trabajar. Practiquen para ser mejores en ella.

* Collective Code Ownership - Compartición de código colectiva

Cualquiera puede cambiar cualquier parte del código. Si, deben consultar al que conozca más acerca del código a modificar pero no hay ninguna parte del codigo que sólo el desarrollador X puede tocar.

* Continuous Integration - Integración contínua

Cada check-in en el repositorio remoto dispara un set extensivo de tests de unidad. Los programadores deben ocuparse si el build falla. Por ejemplo, cuando el build falla nadie hace más check-ins hasta que se soluciona. También debe haber algúna penalización social para el que rompe el build (Debe usar un sombrero estúpido por el resto del dia, un deshonroso trofeo "Rompedor del build" que se ubique en el escritorio del susodicho, debe comprar donas o algo para todo el equipo, etc.). Todo esto se basa en la presunción de que el build es confiable y que una falla significa un problema real.

* 40-hour Week - Semana de 40 horas

Ahora es llamada "Paso sostenible" porque "semana de 40 horas" tendía a asustar a los gerentes y corridas de final del proyecto son a veces necesarias incluso en XP. Esto no debe durar por más de 2 semanas, tener un punto claro y definido a partir del cual las horas de más se terminan y no debe suceder más de dos veces en el año. En verdad, si sucede dos veces en el año significa que se deben mejorar las habilidades de estimación.

* On-site Customer - Usuario in-situ

No sucede a menudo para proyectos internos. Se usan en general representanes de Usuarios (o proxies). Estos representantes necesitan tomarse el trabajo de hablar con los usuarios reales constantemente (no solo con los gerentes de los usuarios) y estar totalmente disponibles para contestar preguntas y dudas de los programadores.

* Coding Standards - Estandares de desarrollo

No importan cuales sean pero los programadores necesitan llegar a un consenso y mantenerlo. El consenso no significa que todos digan "si" en la reunión y luego ignoren los estandars cuando les conviene.

Asi que, como obtenemos el índice de agilidad? Tomen la cantidad de prácticas que realmente siguen, dividanlo por 12 y multipliquenlo por 100-- este es el porcentaje de ágiles que están haciendo. No se den un punto si no implementan real y completamente la práctica. Tienen integración continua pero algunos de los tests fallan de manera aleatoria? ningún punto. Programan de a pares "cuando es necesario" lo cual termina siendo el 40% del tiempo? ningún punto! Hacen iteraciones pero no estiman las historias? ningún punto!!

Este es un momento para mirarse objetiva y seriamente ante un espejo, no una fiesta de amor hippie, i.e, la Hippie-Love Fest.

2 comentarios:

  1. El calculo del porcentaje es duramente real. Me parece muy útil "volver" a recordar estos puntos de XP. En lo personal rescato mucho la "rigurosidad" de XP. Y estoy totalmente de acuerdo en que el termino AGIL parece un poco ambiguo o poco claro.
    Muy buena nota.

    ResponderEliminar
  2. Gracias por tu comentario Soup Selektor. Es cierto. Coincido con que la ambiguedad del termino "Agil" y lo que implica serlo es un problema porque termina haciendo daño. Si uno dice estar haciendo ágil, cuando en realidad solo es una excusa para no documentar y/o escribir con papelitos de colores en la pared va a fracasar y la culpa la va a tener la metodología. El problema con esto es que evita que otros, los que vienen despues, intenten un camino diferente que es realmente mejor en mi modesta opinión.

    ResponderEliminar