El segundo nivel del CMM se llama repetible, justamente porque en base a hechos consumados, debidamente registrados, “es posible” repetir esa experiencia…entendiéndose que haya sido buena .

Ahora claro, es cierto lo que mencionas..que no se puede garantizar el comportamiento de las entidades involucradas, y eso puede incorporar variaciones, pero no es menos cierto que si un proyecto demoró/costó una cantidad X, es muy probable que un proyecto similar esté dentro de un X+/-deltaX.

Ahora del rendimiento de los desarrolladores, creo que hay una componente no menor que tiene que ver con la planificación.
En algún punto anterior, mencionas que se deben considerar hasta los mas mínimos detalles, y creo que en gran medida esa baja productividad de nuestros desarrolladores, tiene que ver, al menos en parte, con una mala planificación. No quiero decir con esto que no sacamos la vuelta, eso es cultural, pero dudo que sea la única causa.

He visto “cartas gantt” de empresas supuestamente “certificadas en CMM”, en el cuerpo de un mail, o en un txt….que no son mas que una lista de deseos y buenas acciones….entonces, obviamente es imposible medir la productividad de un equipo de desarrollo con una planificación de ese tipo.

Atte., Héctor

La planificación no es una ciencia, es una metodología. Por tanto podríamos decir que no existe un algoritmo para planificar que nos garantice cierta exactitud. Entonces podemos asimilar la programación a una heurística; es decir, un conjunto de reglas que por lo general producen un resultado conocido y, en el “por lo general”, está la clave ya que una heurística no garantiza, a diferencia del algoritmo, que siempre dará un resultado conocido, pertinente y exacto.

Por otra parte podemos decir que la planificación trata sobre el futuro. Un proyecto, como sabemos, incluye un conjunto de tareas, plazos, recursos finacieros, recursos humanos, etc. que organizadamente conducirán a un determinado logro. Pero, nada garantiza el comportamiento de las personas, de la sociedad y de la factibilidad del objetivo propuesto, tal que se conjuguen para el logro de la meta. En resumen, todo proyecto tiene una probabilidad de fracaso mayor que 0.

Y, en cuanto al rendimiento de los profesionales, sólo me remito reproducir un comentario generalizado. “los chilenos trabajamos una gran cantidad de horas con una productividad bajísima”. Con esto se nos abre una perspectiva de trabajo muy interesante: cómo efectivamente medimos la productividad de nuestros profesionales. Y, por tanto medir las Horas Hombre es el primer paso para mejorar el rendimiento y la exactitud de nuestra planificación.

Atentamente,

M. Saffirio.

Concuerdo contigo, en que al parecer no habría un método científico relativamente certero para estimar el esfuerzo de un proyecto.

No olvidemos que los PF no es una fórmula mágica que resulta en un plazo, el resultado es un número, que en base a la historia de la organización (en cuanto a desarrollo de proyectos), el desempeño o capacidad de los desarrolladores, complejidad o facilidades de las herramientas y/o del lenguaje…..etc…..se pueden traducir en tiempo con un pequeño margen de error, que en Obras Civiles sería inaceptable…a esto se agregan otros factores como los SLA de otras unidades o proveedores, negociaciones, analisis de riesgos etc…que al ponerlos en la juguera recién permiten visualizar un plazo.

Por lo que me dices entonces, concluyo que el mejor método sería la experiencia y obviamente la historia, apoyándose con técnicas como los PF …pero no utilizando estos como métodos únicos, ¿correcto?.

Otro aspecto importante al momento de establecer plazos y compromisos, es el desempeño del equipo.
Al respecto, ¿cuánto es el % de productividad real (se entiende un promedio) que según tu experiencia posee un desarrollador, llámese Programador, Analista, Jefe de Proyecto??..
He discutido este tema con colegas, y me cuesta un poco aceptar que los porcentajes sean tan bajos, y me gustaría conocer tu percepción al respecto.
Ahora esto es un problema de nuestra cultura o es general?, en paises como Japón o Alemania por ejemplo, que se caracterizan por ser poco sacadores de vuelta, ¿ocurre algo similar?, sabes algo de eso?.

Agradecido por tu amable comentario.

M. Saffirio

La estimación de tiempos de un proyecto informático sigue siendo una ciencia arcana. Claramente los PF sirve para el tema de evaluar cuanto demorará el desarrollo de cierta funcionalidad de software. Por mi parte el método que mejor resultado me ha dado es la simple Carta Gantt pero, haciéndola como una simulación de la ejecuión del proyecto. Esto es incluyendo cada una de las tareas que es necesario realizar, por mínimas y triviales que sean. No te preocupes si salen más de 300 actividades. Ahora lo que pasa que para cada tarea puedes definir precisamente su alcance y quienes son sus responsables, a partir de esto puedes estimar con una mejor aproximación la duración.

Saludos,

M. Saffirio.

Muchas gracias por tu comentario y tu pregunta es muy interesante ya que dá para pensar bastante. Honradamente este tema no lo tengo eleborado pero, como primer apronte partamos que los procesos por razones de negocios mutan permanentemente, en teoría estas mutaciones son las Ordenes de Mantenimiento o Mejoramiento (así las están llamdo ahora), por tanto si tenemo un control sobre los mejoramientos tal que junto con la implementación del mejoramiento actualizamos el modelo y su correspondiente documentación tendriamos el proceso bajo control.

El otro puento, que lo estoy viendo aquí en EASA, es que si no tenemos capacitación permanente y auditorias de procedimientos las implementaciones se diluyen (literalmente).

Me interes seguir analizando contigo este tema.

Saludos cordiales,

MSC

Ahora se que no intervengo en el proceso

Mira, hay un aspecto de tu artículo, que es por si sólo un tema (entre varios otros en realidad), pero me refiero específicamente al dimensionamiento del software, o evaluación de tamaño.
Los puntos de función, son una alternativa pero tiene la desventaja que aplica dentro de un marco muy restringido, en cuánto a tamaño y a tipo de proyecto….o sea, un proyecto de implantación no lo puedo medir con PF….un proyecto muy tecnológico tampoco.

Entonces sería interesante debatir en cuanto a qué otros mecanismos de estimación de tamaño, aparte de los Puntos de Función, de los Puntos de Característica, del Cocomo, etc….aplican sobre otro o todo tipo de proyectos.

Esta fue una discusión que tuve con mis pares cuando implementabamos los PF en el contexto de la metodología de Proyectos en LAN (CMM).
Y era que no podíamos aplicar PF para todo, por poner un caso, un componente de comunicaciones posiblemente tenga PF=0, no obstante su esfuerzo no es menor, una mantención de software de negocio, eventualmente puede resultar con PF=0, y demandar un gran esfuerzo.
El tema es entonces, ¿cómo hacemos una estimación temprana (hablamos en fase de anteproyecto) del tamaño del software, con un método científico, y no con el de los “dedos oscilantes”, (o sea, el mas o menos)…un proyecto que no clasifica para los PF….¿historia?, ¿experiencia?, o hay algo mas elaborado?.