El cuento de los tres desarrolladores…

Eransé que se eran tres desarrolladores. Los tres tenían que sincronizar sus hilos, habían oido hablar de las terribles historias sobre problemas de corrupción de memoria, condiciones de carrera, y demás ‘lobos’ capaces de devorar cualquier aplicación cuando se ponía en producción. Menos más que existían los objetos de sincronización pensaron y se pusieron a trabajar.

El primero de los desarrolladores pregunto a su buscador favorito como sincronizar una porción de código en .Net y rápidamente encontró el siguiente código:

lock (typeof(Object))
{
   . . .

Lo pegó en su programa y luego se fue a tomar unas cervecitas con sus colegas.

El segundo de los desarrolladores escribió el mismo código en su proyecto y se fue a tomar unas cervecitas con sus colegas. Una pena que no les gustase más el framework que la cerveza, como al bueno de Unai. Si no hubiesen sabido que su código no era lo suficientemente sólido…

Pero un día, cuando más tranquilos estaban estos desarrolladores, la aplicación se puso en producción y el ventilador del procesador sopló y sopló y sopló… y un interbloqueo apareció. Menos más que un cazador de bugs, Pablo Alvarez, pasaba por allí y milagrosamente salvo a los desarrolladores de ser devorados por el malvado deadlock

No lejos de allí, el tercero de los desarrolladores, un desarrollador responsable, pensó: ‘Quiero que mi aplicación sea sólida, ¿que puedo hacer?’ y llego a la conclusión de que era una buena idea construir su aplicación ‘con sólidos ladrillos’ y activo el análisis estático de código de Visual Studio. A pesar de haber copiado el mismo código ‘de paja’ que había encontrado en su buscador favorito, el análisis de código detecto el error:

 image

El desarrollador aprendió por que era una pésima idea hacer aplicaciones ‘de paja’ que estableciesen locks sobre objetos con identidad débil, corrigió su código y cuando el ventilador sopló y sopló y sopló y la aplicación aguanto.

Moraleja: Más vale prevenir que curar… Si en el casó del DOT que explicaba el amigo Pablo, hubiesen activado el analizador estático de código (FxCop para los amigos), Pablo no hubiese podido contar su apasionante sesión de depuración, pero la aplicación hubiese funcionado a la primera… Una vez más se cumple la máxima de que el coste de un bug aumenta exponencialmente respecto a cuanto tarda en detectarse. Coste de usar FxCop: cero, coste de que una aplicación en producción se caiga cada cierto tiempo… mejor ni pensarlo. ¡Menos mal que el Debugging and Optimization Team de Plain Concepts sale baratito! 🙂

Si alguien duda de la eficacia del análisis de código, solo puedo decir que es la segunda ocasión en la que publico como esta herramienta puede salvar el culo de un desarrollador

¡Un saludo!

He leído: User Stories Applied de Mike Cohn

Comprar User Stories AppliedSi piensas que la gestión de requisitos es clave para que un proyecto triunfe estás en lo cierto. El problema siempre es el mismo, como conseguir que los requisitos se conviertan en algo útil. Las metodologías ágiles abordan el problema de la gestión de requisitos de una manera diferente. Muchos confunden este enfoque diferente y ágil con una ausencia total de gestión de requisitos.

En este libro Mike Cohn deja claro que use la metodología que uses, la gestión de los requisitos es un área vital. Las historias de usuario están ganando adeptos a gran velocidad como herramienta de gestión de requisitos ágil. Aunque las historias de usuario buscan la máxima simplicidad, la gestión de requisitos es un área llena de complejidades.

En este libro Mike Cohn aborda todos los temas fundamentales relacionados con la gestión de los requisitos de un proyecto siempre desde el punto de vista de las historias de usuario como pieza central de esta gestión. Leyendo este libro aprenderemos a distinguir las buenas historias de las no tan buenas, a identificar y modelar los diferentes roles de usuarios de una solución, a determinar las historias presentes en el proyecto y su prioridad mediante diferentes técnicas ágiles, a escribir condiciones de aceptación para las historias que faciliten su testeo y a estimar las historias y usar esas estimaciones para establecer costes y tiempos de desarrollo. Además, como es construmbre en los libros de este extraordinario autor, todos los temas se exponen mediante ejemplos e historias que hacen la lectura muy amena.

La gestión clásica de requisitos falla por una cuestión fundamental: es terriblemente pesada y costosa de llevar a cabo. Y además es sumamente aburrida. En consecuencia raro es el proyecto que cuenta con una gestión explicita de requisitos. Mediante las técnicas ágiles expuestas por Mike Conh en este libro haremos de nuestra gestión de requisitos una tarea llevadera.

Las técnicas explicadas en el libro son susceptibles de ser utilizadas en cualquier metodología y especialmente recomendables en las metodologías ágiles. El libro incluye un capitulo dedicado a explicar como usar las historias de usuario en un marco de trabajo Scrum y además incluye un excelente capitulo resumen sobre Extreme Programming, metodología en la surgen las historias de usuario.

Este libro es la pareja de baile perfecta para otro libro del mismo autor que ya comente con anterioridad en este blog: Agile Estimating And Planning. Pocos libros han impactado tanto en mi visión de la gestión de proyectos como estos dos.

Un consejo, no perdáis de un momento y compradlos. Si seguís este consejo, lo que si os puedo asegurar es que los vais a devorar, son dos libros extraordinarios.