Por fin, llega la segunda parte de este análisis de herramientas y prácticas ágiles, basado en los resultados de una encuesta sobre las 10 prácticas ágiles que los distintos votantes encontraban como más útiles.
Nos faltaban de repasar las cuatro últimas herramientas, que si bien estaban entre las 10 más útiles, la encuesta las dejaba muy por debajo de las ya mencionadas. Vamos a repasar pues las que faltan:
Digital / Analog Taskboard.
Es una herramienta de seguimiento de proyectos ágiles, donde la información se estructura como muestra la figura siguiente:
- Visibilidad. Se ve de un vistazo la situación del proyecto a alto nivel, y da una visión del estado de la iteración.
- Simplicidad. Es fácil planificar y replanificar. Basta con mover las hojas de tarea (tarjetas).
- Disponibilidad. En el caso de equipos distribuidos, es especialmente útil la versión electrónica de este taskboard, permitiendo la visión/actualización desde cualquier punto.
- Actualización del burndown chart
Planificación de la iteración. Es la fase de la iteración en la que se planifican las tareas de dicha iteración (se decide qué incluir en dicha iteración). Esto se hace en función de la capacidad de trabajo del equipo, y de la prioridad de las historias de usuario. Mediante técnicas como Pareto, se intenta realizar el máximo de historias de usuario, con el esfuerzo disponible para la iteración (capacidad del equipo).
Test Driven Development
(de Wikipedia): Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requisitos se hayan implementado correctamente
Regression Testing
Las pruebas de regresión, son un tipo de pruebas orientadas a detectar nuevos fallos o fallos previamente detectados y ya corregidos, originados al realizar cambios en el sistema como pueden ser: updates, patches, cambios funcionales, etc.
Ahora que tenemos todas las herramientas identificadas, hagamos un breve análisis del resultado de la encuesta sobre utilidad, añadiendo un par de parámetros: coste de implantación y coste de uso.
| Coste implantación | Coste uso diario | |
| Automated Builds | 7 | 1 |
| Continuous Integration | 10 | 2 |
| Daily Standup Meeting | 0 | 1 |
| Iteration Planning | 2 | 2 |
| Coding Standards | 7 | 2 |
| Unit Testing | 8 | 5 |
| Digital / Analog Taskboard. | 3 | 1 |
| Release Planning | 2 | 2 |
| Test Driven Development | 10 | 3 |
| Regression Testing | 5 | 7 |
La tabla anterior muestra unos valores ponderados (no expresan horas ni ninguna otra unidad de medida, sino que son valores que yo he estimado a nivel comparativo, para hacer un análisis cualitativo). Usando los valores anteriores, y con un poco de matemáticas, llegaríamos a la conclusión de que si ordenamos la lista de prácticas por beneficio/coste de implantación, la lista quedaría así:
| Daily Standup Meeting |
| Iteration Planning |
| Release Planning |
| Digital / Analog Taskboard. |
| Automated Builds |
| Regression Testing |
| Coding Standards |
| Continuous Integration |
| Unit Testing |
| Test Driven Development |
Bueno, esto no es muy novedoso. Ya lo sospechábamos: la práctica que mejor resultado da, y que menor coste tiene, es el Daily Stand Up Meeting. Aquí ya, es cuando haríamos las reflexiones oportunas.
Y como vuelta de tuerca final, sería hacer los mismos cálculos, pero incorporando los costes de uso diario. Aquí ya dependería del proyecto, pero los resultados pueden ser algo de este estilo:
| Daily Standup Meeting |
| Digital / Analog Taskboard. |
| Iteration Planning |
| Release Planning |
| Automated Builds |
| Coding Standards |
| Continuous Integration |
| Test Driven Development |
| Unit Testing |
| Regression Testing |
Aquí ya vemos como se "recolocan" las prácticas, de forma que las que mejor rendimiento nos dan al proyecto, al mínimo coste, se han situado arriba, dejando relegadas algunas de las que más cuestan llevar a cabo. Por supuesto, esto ha sido un ejercicio que en la práctica habría que afinar mucho más, porque tanto las fórmulas utilizadas como los cálculos realizados han sido un tanto burdos para obtener resultados cualitativos. Os invito a todos a realizar algo similar aplicado a vuestros proyectos y costes, y ver qué prácticas son las que os da mejor ratio rendimiento/coste. Hasta la próxima.
