¿Aquí quíen #@$@#~€ barre? … o lo mínimo que todo desarrollador debe saber sobre IDisposable y los finalizadores

  Durante mucho tiempo, mi cuadrilla, disfruto de un chamizo donde nos reuníamos para fumar, beber, comer, ver cine, jugar a cartas y otras cuestiones menos confesables… fueron años divertidos. El chamizo siempre planteaba la misma duda… ¿a quien coño le toca barrer?  La gente, ya se sabe, a la menor ocasión, se escudaba en las falta de reglas claras y la consecuencia es que nadie barría… al final la acumulación de colillas, cascos de cervezas y en general residuos no orgánicos de todo tipo hacían que el chamizo colapsase y tuviésemos que dedicar un día completo a limpiarlo… con el consiguiente mosqueo… hartos de la situación establecimos unas normas claras y nunca más volvió ha haber problemas.


 


Lo mismo que nos pasaba a nosotros le pasa a veces a .Net… el pobre recolector de basura y la pobre memoria a veces dicen basta por que muchos desarrolladores de .Net desconocen algunas normas y patrones claros de cómo se debe implementar IDisposable. En este post voy a comentar esas normas… sin justificarlas. Solo quiero exponer una serie de normas que si se respetan nos ayudaran a evitar que nuestras aplicaciones tenga problemas en lo relativo a la memoria por no liberar recursos de manera adecuada. También quiero dejar claro que es un mito que las aplicaciones de .Net no puedan fugar memoria. Es más díficil que esto ocurra que cuando desarrollamos en leguajes no manejados pero puede ocurrir y evidentemente siempre pueden ocurrir consumos de memoria elevados por no liberar a tiempo los recursos.


 


Vayamos al grano de este post y contestemos a la pregunta clave que hoy abordaremos: ¿Cuándo y cómo el desarrollador debe coger la escoba e implementar IDisposable o un finalizador?


 


Simplificando mucho el asunto: el recolector de basura pasa cuando quiere. Si nuestra clase mantiene estructuras que consumen mucha memoria o que representan recursos limitados del sistema operativo (habitualmente representados mediante handles), nos puede interesar decirle al mundo que deberian liberarse cuanto antes. La manera de lanzar ese mensaje al mundo es implementar IDisposable.  Cuando uno de nuestros tipos implementa IDisposable todos los programadores de .Net del mundo (o mejor del universo) reciben un mensaje claro: esta clase contiene recursos valiosos que deben ser liberados cuanto antes, no debemos esperar a que el recolector de basura actúe. Para ello el típico patrón es usar las clases que implementan IDisposable mediante using. IDisposable NO es llamado por el recolector de basura, nosotros debemos hacerlo, bien usando using, que se encargará de llamar a Dispose cuanto sale de ambito o llamando explícitamente al método Dispose del objeto. Resumiendo: Llamar a Dispose nos permite liberar recursos valiosos de manera temprana.


 


Ocurre a menudo, que los recursos valiosos de los que hablo además son recursos no manejados. Los recursos no manejados no son liberados por el recolector de basura. Nosotros como desarrolladores somos los encargados de liberarlos. La manera de liberar esos recursos es implementando un finalizador. Los finalizadores SI son llamados por el recolector de basura cuando limpian un objeto de memoria.  Resumiendo: Los finalizadores nos permiten asegurar que nuestro código de limpieza de recursos no manejados, escrito en el finalizador, será ejecutado cuando el recolector de basura libere nuestro objeto. Pero este momento se puede demorar mucho.


 


Generalmente IDisposable y los finalizadores van de la mano, por la cuestión ya comentada de que los recursos no manejados suelen ser recursos valiosos que, en consecuencia, conviene liberar lo antes posible.


 


Ahora que ya conocemos cuándo debemos implementar los finalizadores e IDisposable vamos a ver como implementarlos. La manera en la que se implementan es siguiendo el patrón IDisposable que tiene la siguiente forma (por favor leed los comentarios):


 



    1 public class DisposableClass : IDisposable


    2 {


    3   //Finalizador.


    4   //Llamado por el GC al eliminar el objeto de memoria.


    5   ~DisposableClass()


    6   {


    7     //Liberamos los recursos no manejados


    8     Dispose(false);


    9   }


   10 


   11   //Llamado explicitamente por el desarrollador.


   12   //bien usando using o invocandolo explicitamente.


   13   public void Dispose()


   14   {


   15     //Llamamos a Dispose para liberar los recursos mantenidos por la clase


   16     Dispose(true);


   17     //Puesto que ya hemos realizado la liberación de recursos, no es


   18     //necesario que el GC llame al finalizador


   19     System.GC.SuppressFinalize(this);


   20   }


   21 


   22   //Esta función aglutina todo el proceso de liberación de recursos.


   23   //Se invoca desde el finalizador pasando false, pues el finalizador solo


   24   //debe liberar recursos no manejados.


   25   //Se invoca desde el método Dispose pasando true pues queremos en ese caso


   26   //liberar todos los recursos valisos agregados por el objeto, sena estos


   27   //manejados o no.


   28   protected virtual void Dispose(bool disposing)


   29   {


   30     if (disposing)


   31     {


   32       //Liberar aquí los objetos manejados agregados en esta clase


   33       //que implementen IDisposable llamando explicitamente a su método Dispose.


   34     }


   35 


   36     //Liberar aquí todos los recursos no manejados.


   37   }


   38 }


 


He prentendido aquí, comentar las pautas generales que todo desarrollador debe como mínimo conocer sobre este tema y que nos sirven como guia general. Hay situaciones complejas, como el uso de liberías no manejadas usando DllImport que exigen más atenciones y consideraciones. Además no he entrado en el porque de las cosas o en detalles de la recoloección de memoria que son interesantes. ¡Solo quería cubrir lo mínimo que todo el mundo debe saber! Seguro que algunos de vosotros querréis indagar más sobre el tema. Si es así, os recomiendo la lectura de DG Update- Dispose, Finalization, and Resource Management de Joe Duffy. Excelente artículo sobre el tema adornado con anotaciones de gente del nivel de Jeffrey Ritcher, Herb Sutter, Krzysztof Cwalina…


 


¡Un saludo!

Esteroides para tu MSBuild

MSBuild Extension Pack


Todos los que usamos y sufrimos MSBuild sabemos que las tareas son el elemento clave de este framework de construcción automatizada (como en la gran mayoría).


Digo sufrir porque mantener los scripts de MSBuild (o de NAnt) es un infierno. ¿De quíen fue la brillante idea de expresar algo tan procedimiental como un proceso de construción como un churro de XML? Supongo que alguien que penso más en facilitarle la labor a quien desarrollaba MSBuild que al quien lo usa. ¿Para cuando un sistema de construcción basado en scripting en lugar de en XML?.


Pero bueno quejas a parte… voy a contaros lo que os iba a contar: en codeplex existe un proyecto sumamenete interesante: MSBuild Extensions Pack, se trata de un amplio conjunto de tareas para MSBuild que nos permite y facilita el realizar un motón de labores interesantes desde nuestro proceso de construcción. Encontramos tareas de todo tipo: Tareas para Biztalk, tareas relacionadas con la calidad de código, una tarea que permite enviar un email, tareas para crear .cab o .zip, tareas para COM+, para modificar variables de entorno, para interactuar con el visor de eventos, una tarea para hacer ping, tareas para trabajar con contadores de rendimiento, tareas para modificar el registro, para obtener información sobre los discos, para interactuar con servicios de la máquina, para trabajar con el sistema de archivos, para interactuar con la GAC, para interactuar con WMI, para reproducir sonidos desde la build (ya molaría una sirena de alarma cuando falla la build ejejej….), para trabajar con certificados, para trajar contra Source Safe, para construir proyectos de VB6, para crear AppPools y sitios en IIS 7, etc…


Vamos que antes de que os planteéis el crear una tarea deberíais leer el archivo de ayuda del proyecto.

El cambio horario y .net

reloj  Este próximo domingo, 26 de Octubre, se ajustará la hora en España al horario de invierno. A las 3:00 serán las 2:00. La buena noticia es que podremos dormir una hora más, la mala, que esto puede afectar a nuestras aplicaciones.

Fijaros por ejemplo el caso de una aplicación que calcule la producción de piezas de una máquina por hora, por poner un ejemplo. Si queremos saber la producción media por hora entre las 1:00 y las 4:00 de la mañana, deberemos tener en cuenta que en realidad habrán transcurrido cuatro horas y no tres, debido al cambio horario. Según como estemos manejando las fechas en nuestra aplicación puede que nuestros cálculos sean correcto o no.

Para que los cálculos sean correctos debemos utilizar horas universales para calcular el intervalo de tiempo transcurrido.

Como nada deja las cosas más claras que un ejemplo, compilad y observad los resultados de código que pongo a continuación, quizás os sorprendan:

using System;

 

namespace DayligthSavingsTimeEffects

{

   class Program

   {

     static void Main(string[] args)

     {

       DateTime dt1 = new DateTime(2008, 10, 26, 1, 0, 0);

       DateTime dt2 = new DateTime(2008, 10, 26, 4, 0, 0);

 

       double hoursElapsed = (dt2 – dt1).TotalHours;

       Console.WriteLine(

         «Horas entre la 1 y las 4 (sin tener en cuenta el cambio horario): {0}»,

         hoursElapsed);

 

       hoursElapsed = (dt2.ToUniversalTime() – dt1.ToUniversalTime()).TotalHours;

       Console.WriteLine(

         «Horas entre las 1 y las 4 (teniendo en cuenta el cambio horario): {0}»,

         hoursElapsed);

     }

   }

}

La moraleja es: siempre que hagáis operaciones entre horas en las que se deban considerar los posibles cambios horarios, convertid antes a hora universal. O lo que es mejor aun, siempre haced las operaciones entre horas, con horas universales. Fijaros que este problema no solo afecta a operaciones en las que queremos ver el tiempo transcurrido sino también a operaciones en las que sumemos horas, por ejemplo.

Trabajar con fechas parece simple pero debemos tener un buen puñado de cuestiones en mente si queremos evitar problemas cuando nuestra aplicación corra en sistemas con diferentes calendarios o diferentes políticas de cambio horario para ahorro de energia. En la MSDN hay un interesante artículo que recopila todas la buenas prácticas que debemos considerar al trabajar con fechas, merece la pena leerlo.

El rendimiento, la percepción y el teléfono escacharrado…

¿cúal será la realidad? Dice el doctor House que los pacientes siempre mienten… yo digo que los usuarios no siempre dicen la verdad cuando hablan de rendimiento… al final las consecuencias son similares: House o yo acabamos dando palos de ciego. Lo más curioso de la situación es que, al contrario de los pacientes de House, los usuarios no mienten de manera consciente tratando de ocultar trapos sucios. Los usuarios no siempre dicen la verdad por dos motivos: el primero, por que su percepción le engaña a menudo, el segundo por que no siempre es el usuario que sufre el problema de rendimiento el que nos da la información.

Os voy a contar una historia que ilustra la situación.

Llamada a soporte postventa de un cliente. En concreto llama el Director del departamento de producción de Tromperris. El nunca toca el software de gestión de Tromperris, pero que más da, el es el Jefe y resulta que sus indios están en pie de guerra por que los informes vitales que imprimen todos, absolutamente todos, los días tardan la barbaridad de diez minutos en generarse ¡inaceptable!. La gente de soporte se acojona, no sin motivo, por que ha llamado el Jefe y tal y escala el problema ‘ipso facto’ sin recabar más información. Así que aquí estoy yo lidiando con el problema.

¿Por qué el Jefe llamó y dijo diez minutos?. La historia es como sigue:

Jefe: Supervisor, ¿cuál es el problema más grave que hay con la aplicación de gestión de Tromperris?

Supervisor: No, sé… quizás los informes, algunos tardan mucho…

Jefe: ¿Cuánto es mucho?

Supervisor: No se… preguntaré a los indios, que son los que se quejan…

Indio: Los informes que más tardan son los de fin de mes, tardan más que el resto… como tres minutos…

Supervisor: Que barbaridad, ¡tres minutos!… Hay que tomar medidas inmediatas… se lo diré al jefe…

[El indio se encoje de hombros y sigue a los suyo…]

Supervisor: Jefe, ya se lo que tardan los informes… ¡casi cinco minutos!

Jefe: Ahora mismo llamo, ¡cinco minutos perdidos todos los días!, no puede ser…

[El jefe llama a soporte]

Jefe: Los informes tardan 10 minutos (si exagero un poco seguro que me hacen más caso, piensa, no sin razón…

Soporte: Ahora mismo los escalamos… (si ha llamado el Jefe y dice que es tan grave lo será ¿no?)

Como yo ya se que los usuarios no siempre dicen la verdad, trato de objetivar la información. Así que sin más, cojo una traza con el profiler de Sql Server y trazo todas las consultas que tarden más de tres minutos y que veo… que no hay consulta alguna que tarde más de tres minutos, así que difícil será que algún informe tarde cinco minutos… es más, tras bajar el tiempo de filtrado, no veo la consulta que el informe lanza por ningún lado. Sospechoso… a lo mejor el informe no se lanza con tanta frecuencia como el usuario dice… miro los logs de la aplicación y parece que el informe en cuestión ¡solo se lanza a final de cada mes!.

Ejecuto el informe, y el profiler no miente, dos minutos de consulta. Algo normal para el volumen de información consultado. Lanzo el informe de nuevo, cronometro en mano y tres minutos hasta que lo tengo en pantalla. Correcto.

Al final la cosa se enmaraña, como no, lo que sea para no bajarnos del burro… así que ahí estoy yo en el cliente, con el indio…

Yo: Aupa, así que el informe tarda diez minutos… yo no veo eso en las trazas…

Indio: ¿diez minutos? No… menos, pero es lento…

Yo: ¿Cuánto crees que debería tardar el informe?

Indio: No se, unos tres minutos o así… total le saco una vez al mes.

Yo: Lanza el informe que cronometramos…

[Tres minutos después]

Yo: Tres minutos….

Indio: Pensé que era más… como solo le saco una vez al mes y el resto van más rápido…

Moralejas:

  1. No te fíes de lo que te cuentan solo de lo que te cuentan los profilers y los logs…
  2. En cuestiones de rendimiento, todo el mundo exagera.

Solo actuar en base a datos y dejar de lado percepciones y cadenas de exageraciones va a permitir que en cuestiones de rendimiento no demos palos de ciego.

¡Un saludo!

Disponible la presentación de mi ponencia en ALM Sessions’08

Ya podéis descargar la presentación de mi ponencia en ALM Sessions’08 titulada Control de proyectos con metodologías ágiles y Team System.



Sobre el evento, solo puedo decir que fue un gran exito de público, con casi 500 asistentes. Desde mi punto de vista me parece que es un excelente sintoma de como está despegando el interés por la gestión del ciclo de vida del software en general y sobre Team System en particular.


Agradecer desde aquí su interés a todos los asistentes a mi ponencia. La verdad es que me sorprendio muy gratamente la cantidad de público.


Aprovecho para recordaros que como complemento a este evento, se celebrará el dia 18 de Noviembre un Workshop más extenso en las oficinas de Microsoft en Madrid, con un coste de 30€, si estáis interesados os podéis inscribir aquí.


¡Un saludo!

Estaré en: Microsoft ALM’08 Sessions :: Control de proyectos con metodologías ágiles y Team System

Por fin está aquí el evento del año sobre gestión del ciclo de vida organizado con Microsoft. Plain Concepts es uno de los partners Platinum del evento, dada nuestra implicación con la comunidad entorno a las metodologías de desarrollo y Team System, no podía ser de otra manera :). Agenda ALM'08


Pues bien, como podéis ver en la imagen de la agenda que pongo arriba a las 11.00 impartiré un workshop sobre Control de proyectos con metodologías ágiles y Team System. En la imagen también podéis ver los temás que trataré. ¡Espero veros por allí!.


Como complemento a este evento, se celebrará el dia 18 de Noviembre un Workshop más extenso en las oficinas de Microsoft en Madrid, con un coste de 30€, si estáis interesados os podéis inscribir aquí.

Estimación vs adivinación

Hace tiempo escribí dos entradas sobre estimación: una titulada Estimando (no practicando la brujería) y otra Recibiendo estimaciones. Hoy he recibido una viñeta por correo electrónico que es el complemento idoneo para esos dos posts. ¿Alguno de vosotros no ha vivido esta situación en su carrera profesional?.


No deja de ser curioso cuantas situaciones anómalas se dan en el desarrollo de software en torno a un tema vital como es la estimación.


Estimando 


Nota: No se donde se ha publicado originalmente esta viñeta, si alguien lo sabe, rogaría que me lo dijese, para poner la pertinente referencia.


Nota 2: Me informa el amigo Ramón Sola de que la viñeta se publico originalmente en el blog Sinergia sin control, por cierto, no os perdáis los comentarios… esto me ha permitido linkar el sitio como dios manda y descubrir un puñado más de geniales viñetas… excelente viñeta blog.


¡Un saludo!

Exprimiendo Scrum: Scrum y el control del proyecto (I): el avance

Burndonw Chart Un aspecto clave en la gestión de proyectos ha sido, es y será el control del proyecto. Dentro del control del proyecto se consideran una gran variedad de aspectos, diferentes según el autor que se consulte, pero hay dos que destacan de manera clara sobre el resto: el avance y la visibilidad. Es evidente que existen otros aspectos relacionados con el control del proyecto, pero me centraré en esos dos. En este primer post hablaré sobre la avance y en una segunda entrega, hablaré sobre la visibilidad.

Pensad un poco, cuando un gerente o un comercial o un director se acerca a los implicados en un proyecto ¿qué es lo que siempre pregunta?. Las dos grandes preguntas que todo equipo de desarrollo responde continuamente son: ¿Está hecho ya? ¿Cuánto queda para que este hecho? Da igual si esto se aplica a tareas, requisitos o el proyecto entero, esas son las preguntas que siempre respondemos. Se hace evidente que si esta es la realidad, sería conveniente adecuar lo que nuestra metodología aporta a esta realidad. Las cuestiones antes comentadas parecen simples de responder, pero, ¿en cuántos proyectos estas preguntas encuentra una respuesta clara?.

Scrum se apoya en dos conceptos clave para darnos las respuestas que necesitamos: el concepto de ‘hecho’ y la velocidad como principal métrica.

El concepto de hecho

En la gestión de proyectos, uno de los aspectos que siempre se han remarcado es que tanto las tareas (unidad básica de gestión de proyectos) como las historias de usuario, escenarios, requisitos o casos de uso (unidad básica de liberación de valor de los proyectos) deben ser binarias. Es decir en esencia tenemos que poder distinguir si están completadas o no. Una puerta solo puede estar cerrada o abierta, una tarea o un requisito solo pueden estar completados o no. Las tareas y los requisitos que no están completadas no suman valor, no añaden progreso al proyecto. Esto se hace evidente si tenemos en cuenta que el 10% final de toda tarea o requisito se lleva el 90% del tiempo. ¿Cual es el progreso de un requisito descompuesto en cinco tareas si todas ellas están al 90% de progreso si lo miramos desde el punto de vista del valor liberado para el cliente? ¡Cero!. En las metodologías ágiles y por lo tanto en Scrum, la principal métrica de progreso es el valor liberado para el cliente. Recordemos uno de los principios del manifiesto ágil: ‘El software que funciona es la principal medida del progreso’.

Otro aspecto relevante es tener en cuenta que el nivel de hecho no es igual para todos los proyectos de Scrum. En la gran mayoría de las implantaciones de Scrum en las que participo el nivel de hecho viene definido de manera estándar de un modo similar al siguiente: una historia de usuario se considera hecha si el código esta escrito, se a compilado correctamente en una build de integración diaria, todas las pruebas unitarias se han ejecutado satisfactoriamente y con cobertura suficiente, el tester ha realizado al menos las pruebas de humo en una build que integre el escenario, y el tester ha comprobado que el escenario ha pasado las condiciones de aceptación establecidas inicialmente por el producto owner. Evidentemente este nivel de hecho puede ser o no suficiente. Algunos proyectos en los que he participado añaden nuevas condiciones: que el manual de usuario incluya la documentación necesaria para la historia, que todas las pantallas de la historia estén traducidas, que las haya revisado el departamento jurídico… Establecer lo que entendemos por hecho es algo que debemos establecer de manera explicita en todo proyecto de Scrum. Se trata de una condición imprescindible para poder confiar en las métricas de progreso que recopilemos.

La velocidad es la clave

En las metodologías ágiles, la velocidad de desarrollo, entendida como el trabajo realizado frente al trabajo que hemos estimado que nos queda por hacer es la principal métrica. Utilizar la velocidad como principal métrica está fundamentado en que incrementos en este aspecto del desarrollo son síntoma claro de mejora del proceso de desarrollo. Si desarrollamos más rápido, es que desarrollamos mejor. Además es una métrica difícilmente sesgable, problema habitual cuando trabajamos con métricas, si para mejorar la velocidad de desarrollo sacrificamos por ejemplo la calidad, olvidándola, o el equipo, forzándole por encima de su capacidad o cualquier otro aspecto, tarde o temprano esto se verá reflejado en la velocidad. Además la velocidad es una métrica que nos permite estimar con facilidad cuando el proyecto estará concluido o que magnitud de funcionalidad se debe quedar fuera para cumplir una fecha concreta.

Implantar una métrica de progreso clara, nos permite informar a partes ajenas al desarrollo de cuál es el comportamiento del proyecto de manera analítica, explícita y difícilmente rebatible. Esto hace que el resto de los afectados por un proyecto puedan actuar en fase a datos. Los comerciales no comprometen fechas imposibles, los redactores técnicos pueden planificar cuando podrán comenzar a capturar pantallazos de la documentación, el departamento de calidad final sabrá cuando debe esperar carga de trabajo relacionada con nuestro proyecto, etc… No es lo mismo contarle a tu jefe que crees que el proyecto va retrasado que enseñarle un burndown chart que muestra sin lugar a dudas que el proyecto va retrasado… En el primer caso la respuesta será ‘Hombre, Rodrigo, mira que eres pesimista hombre, si ese retraso, que yo no creo que exista, lo solucionáis vosotros con trabajo duro’ y tu sales del despacho de tu jefe con cara de que has caído otra vez en el juego de las bolitas de los trileros… Lo bueno de las métricas claras es que ¡hasta tu jefe las entiende!, son datos, no sensaciones y son difícilmente rebatibles.

Mirad el burdown chart que muestra la imagen que ilustra el post. En el eje X tenemos el trabajo que hemos estimado que nos queda por hacer. En el eje Y tenemos los 20 sprints con los que contamos para completar la funcionalidad. Ahora mismo hemos completado el sprint 10, si duda se trata de un momento excelente para hace una replanificación. Viendo la línea de tendencia (línea morada discontinua) se hace evidente que no vamos a completar todo el trabajo que estimamos que nos queda. Estamos alejados de la línea idea (línea verde fina), y lo que es peor, no parece que converjamos hacia ella. Se hace visible para cualquiera que no vamos a completar toda la funcionalidad. Es más, según el gráfico, al ritmo que vamos, no vamos a completar requisitos por al menos 60 puntos de estimación (punto final de la línea de tendencia). Los números nos dan la verdad, absoluta, irrebatible… incluso para tu jefe :). ‘Donde no ha mata no hay patata’ que dicen en mi pueblo.

En  esta situación se hace evidente que lo único que podemos hacer para completar toda la funcionalidad son dos cosas: alargar la duración del proyecto o mejorar la velocidad.

Alargar la duración del proyecto es siempre una mala idea y un mal síntoma. Es una mala idea, porque si movemos la fecha de fin estamos lanzando un mensaje erróneo al equipo de desarrollo: no pasa nada si os retrasáis… y la realidad es que cuando los proyectos se retrasan siempre pasa algo. Inevitablemente el equipo de desarrollo se va a ‘relajar’. ¿Recordáis lo que pasaba cuando os alargaban la fecha de un examen? Yo llegaba igual de bien o del mal preparado… Es un mal síntoma, porque ¿realmente necesitamos toda la funcionalidad? Vale que sí, que nos creemos que la necesitamos… ahora pensad en el proyecto de más éxito en el que hayáis trabajo… ¿Entregasteis TODA la funcionalidad? ¡Probablemnte no!, pero si ¡entregasteis toda la funcionalidad más importante!. Si nos vemos en la necesidad de alargar un proyecto es porque hemos cometido un error de base: no nos hemos centrado en liberar primero la funcionalidad que mayor valor tenia para el cliente. Recordad: 20% de la funcionalidad 80% del valor… pero claro para esto debemos haber priorizado por el valor. Si nos vemos en la necesidad de alargar el proyecto es porque no hemos liberado la funcionalidad importante en primer lugar. Recordemos de nuevo los principios del manifiesto ágil: ‘Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor’.

¿Cómo podemos mejorar la velocidad? Pues no hay balas de plata en esto. Es muy difícil mejorar la velocidad a saltos, la velocidad se mejora en pequeños incrementos no en grandes saltos. ¡Ahora necesitamos un gran salto!… Que no va a ocurrir… Asumámoslo… Si somos responsables solo podemos pensar en recortar funcionalidad por 60 puntos de estimación. Puede parecer traumático, pero no lo es… ¡si hemos hecho primero aquellas partes que más valor liberan para el cliente del proyecto!. Es muy probable que el cliente ni siquiera note que hemos recortado la funcionalidad… los clientes perciben y miden valor… no funcionalidad.

A veces, puede ocurrir que el burndown chart del proyecto muestre que vamos sobrados… al menos en teoria… en la práctica yo no lo he visto, así que ni comentaré la situación. Si os véis en esa situación, enhorabuena, por una vez váis a acaba el proyecto antes de tiempo y sin recortar absolutamente nada de funcionalidad…

Resumiendo: el concepto de hecho y la velocidad como métrica nos van a permitir medir el avance de nuestro proyecto de una manera analítica, basada en datos, que exige poca burocracia y que nos permite tomar decisiones informadas en lugar de decisiones basadas en percepciones.

Evidentemente para que este enfoque funcione tenemos que tener un proceso explicito, sano y ágil de estimación.

¡Espero vuestros comentarios!