Qué pregunta no es cierto? a ver … con sinceridad, en cuántos proyectos no han podido estimar el esfuerzo de prueba? uno? dos? varios? en todos? Bien, mejor por el momento dejemos la respuesta de lado.
Lo cierto es que actualmente hay muchos proyectos en donde se nos ‘permite’ estimar desde un primer momento, cosa que antes (o actualmente en algunos proyectos) ni se pensaba siquiera porque directamente ese cálculo estaba a cargo del Gerente de Proyecto o del Lider de Desarrollo, ¿o me van a decir que no? jaja
Gracias a Dios, este tema ha ido cambiando y hoy por hoy, con las nuevas metodologías, nuevas prácticas, la globalización, la llegada del Aseguramiento de la Calidad (QA), los nuevos enfoques, y todo eso que a diario esta en contacto con nosotros, ha facilitado nuestra participación en etapas tempranas.
Ahora bien, según un artículo publicado en jummp:
El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.
Todo depende del modelo sobre el cual se trabaje, igual hay algo de cierto en lo que se expone aquí.
Sabemos bien que hay circulando por internet, templates que nos permiten realizar los cálculos de estimación mediante el ingreso de ciertos valores sobre la base de parámetros ya fijados previamente y concebidos gracias a la experiencia en otros proyectos, que como siempre, hay que «tocarlos» algunas veces para adecuarlos al proyecto en el que estamos participando para personalizarlo.
Este tipo de templates aplican en algunos casos a proyectos waterfall (en cascada) y otros, a proyectos ágiles.
Sin embargo, es cierto, a medida que va avanzando el proyecto seguramente deberemos ajustar los tiempos estimados, ya que nos lo dirán (pedirán).
Otro aspecto, y que es muy cierto, y reflejado en este artículo de jummp es:
Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.
Tener un template lo suficientemente flexible, nos servirá para estos casos en que como se expone aquí, deberemos ir manejando esa cierto inestabilidad conceptual por parte del usuario y cuyo impacto es sobre todo el equipo de proyecto.
También es cierto, porque lo he sufrido, lo que expone el artículo de jummp:
Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda.
Y aquí la importancia que tiene la actuación del Gerente de Proyectos junto con el Lider de QA y/o QC es fundamental, ya que la «cintura» (tiempo ganado de experiencia) que tenga cada uno, permitirá resolver/solucionar diferentes situaciones de falta de comunicación que puede llegar a haber, incluyendo los conflictos derivados por supuesto.
No obstante, a veces se gana y otras veces se pierde, ¿no es cierto? Es muy dificil a veces hacerle entender al cliente que lo quiere, en el momento en que lo quiere, no lo va a tener o si lo tiene, no será tal como él lo ha pedido, y aquí es donde comienza a jugar el entendimiento que se haya tenido del requerimiento, y la conformidad que nos haya dado el cliente.
Ciertamente, uno de los últimos párrafos del articulo de jummp expone:
Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.
Y suena lógico ya que el equipo mismo junto con el cliente van madurante a lo largo del ciclo de vida del proyecto, y si seguimos con el mismo cliente desarrollando nuevas adaptaciones o manteniendo sus productos, todo este conocimiento y experiencia comenzará a jugar a nuestro favor para mejorar futuros entendimientos de requerimientos.
Pero, porque siempre hay un «pero» (ja), cerrando con el artículo de jummp:
Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario
No me queda otro comentario que dejar que, es verdad!!!! 🙂
Les mando un abrazo,
Gustavo
Fuente de inspiración:
http://wp.me/ppBOQ-3CI
.
