Las 10 prácticas ágiles más útiles (II)

Esta es la 2ª parte de una serie de artículos. Haz clic aquí para ir al post anterior.
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:

Este cuadro de mando tiene varias ventajas:

  • 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

Release Planning
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.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s