Costo estimación de software - ¿Por qué no?

A veces siento que no estoy viviendo en el mismo mundo que todo el mundo lo hace. yo era (y yo), involucrado en la estimación de software profesional, evaluación comparativa, y los procesos de contratación de casi la mitad de mi vida, y la mayoría de las personas con las que hablo no tienen ni idea de qué se trata. Especialmente el "groovy", frio, nuevo, joven, generación de jóvenes súper relajados ", no tiene idea de lo que estoy hablando. "La estimación de software es difícil, y siempre sale mal, Entonces, ¿por qué intentarlo??"" #Noestimates ", compruébalo en twitter, es algo real. Y esta gente es seria! Creen en el poder del equipo. Es más fácil decirlo que hacerlo cuando tienes un negocio que gestionar. Como un amigo cercano, que trabaja para un gran integrador de sistemas internacional, siempre me dice: 'Ningún cliente nos dio un millón de dólares con la solicitud de crear cualquier solución de software, siempre que aporte algún valor comercial ". Me molesta mucho cuando la gente dice que la estimación de software ya no es necesaria en el ágil mundo de la entrega.. Está, e incluso más que antes!

Los equipos ágiles suelen utilizar puntos de historia, una unidad de medida de esfuerzo arbitraria que es relativa a una cierta cantidad de trabajo. Los puntos de la historia no son repetibles, no verificable, no objetivo y no defendible. Pero la comunidad ágil parece lograr convencer a la administración de TI en este planeta de que las métricas basadas en puntos de historia son útiles para respaldar las decisiones de administración..

Es realmente como si alguien hubiera convencido a los pintores del mundo de usar "puntos de pared" en lugar de una métrica estandarizada como el metro cuadrado para medir el tamaño de las paredes y estimar sus trabajos de pintura mural.. No creo que mucha gente acepte una cita como "Te cobraré $ 100 por punto de pared ", Correcto? Simplemente no tiene sentido, ya que el número de puntos de la pared nunca se puede medir objetivamente, ya que no esta estandarizado. Para dar una cotización como "$ 100 por metro cuadrado "tiene mucho sentido, porque esta estandarizado, y por lo tanto transparente, predecible y defendible.

 

Solo hoy, hablé con 2 diferentes organizaciones de clientes, ambos se quejan de que su proveedor, trabajando ágil, subestimó por completo el esfuerzo necesario para implementar una pieza de software "imprescindible", lo que resulta en graves sobrecostos en los costos y en la programación. ¿Cómo es esto posible en ágil, usted pregunta? Muy simple! Aunque se supone que el alcance es variable, las organizaciones todavía necesitan un cierto conjunto mínimo de funcionalidades (y no funcional) los requisitos de los usuarios para estar listos e implementados en algún momento y también asignan algo de presupuesto a eso, porque deben cumplir con las leyes financieras y contables. Si subestimas el esfuerzo (y lo hará si utiliza solo estimaciones de expertos!), el equipo será demasiado pequeño y el software no estará listo cuando debería estar.

La estimación de costos de software sigue siendo muy relevante, también en tiempos ágiles. En la conferencia anual de la Asociación Internacional de Análisis y Estimación de Costos (ICEAA), en junio pasado en Phoenix (LOS, Estados Unidos), ICEAA y Nesma presentaron el Cuerpo de conocimientos sobre estimación de costos de software (sCEBoK). En esta conferencia, terminado 450 estimadores de costos de organizaciones como Boeing, NASA, Lockheed Martin, Nosotros marina de guerra, etc. convocado para discutir las prácticas profesionales de estimación de costos, también con respecto al software. Para ellos, no es una opción esconderse detrás de puntos de historia arbitrarios, Deben cumplir con los estándares internacionales y las mejores prácticas para asegurarse de que la estimación sea tan precisa, pero también lo más defendible posible.

Como experimento social, Decidí publicar un mensaje para informar a la industria sobre la iniciativa Nesma / ICEAA en varios grupos de LinkedIn, y me interesó especialmente ver las reacciones del grupo "Desarrollo de software ágil y ajustado", que ha terminado 140.000 miembros. El texto:

"Los procesos de madurez de estimación en promedio son todavía bastante bajos. Se siguen desperdiciando grandes sumas de dinero porque los proyectos no se estimaron profesionalmente, lo que resulta en sobrecostos y costos. Uno de los problemas en toda la industria es el hecho de que el estimador de costos de software a menudo no es una profesión reconocida.. En muchas organizaciones, Las estimaciones se basan en la experiencia y las opiniones de expertos humanos sesgados., en lugar de basarse en datos históricos relevantes y modelos paramétricos. Nesma y ICEAA (Costo Internacional Estimación y Análisis de Asociación) están trabajando juntos para crear un plan de estudios de capacitación y una certificación para el "Estimador de costos de software", un rol profesional para estimar actividades y productos relacionados con el software.

En cooperación con varias organizaciones de apoyo y profesionales de la industria., Nesma e ICEAA han estado trabajando juntos para desarrollar un Cuerpo de Conocimientos sobre Estimación de Costos de Software (sCEBoK). En consonancia con los programas de formación y certificación que ya tiene ICEAA para la estimación de costes, el objetivo es desarrollar un programa de capacitación y certificación específicamente para el estimador de costos de software. El plan es tener los primeros estimadores de costos de software profesionales certificados el próximo año en la conferencia ICEAA en mayo. 2019 en Tampa, FL y en el IWSM en noviembre 2019 Haarlem, Los países bajos'

Por favor, compruébalo si tienes la oportunidad.: https://www.linkedin.com/groups/37631/37631-6422686037318860800

 

Es realmente increíble lo que piensa esta comunidad de profesionales sobre la estimación de costos de software. Solo algunas de las reacciones:

"¿Por qué deberíamos querer madurar perdiendo el tiempo?’

"Nunca me impresionaron las estimaciones precisas sobre nuevos desarrollos".

"Lo siento si esto parece sarcasmo, pero ha inventado una bola de cristal más elegante para producir números aleatorios más precisos ".

"Creo que es mejor que lleve esto a las comunidades de jefes de proyecto y de cascada, ya que las comunidades ágiles simplemente se reirán de esto".

"He visto algunas tonterías de caballos humeantes publicadas en este grupo, pero esto encabeza la pila "

"Presupueste lo que pueda pagar. Haga que los equipos entreguen continuamente para que pueda ver lo que obtiene por su dinero. Mejorar continuamente. Si no obtiene suficiente valor, causa raíz por qué. "

"Otra certificación más para que los aspirantes compren… Justo lo que necesita esta industria ".

 

Y muchos comentarios más duros e injustos, de la comunidad que no parece preocuparse en absoluto por las implicaciones financieras del desarrollo de software (aunque también hubo algunos comentarios de apoyo, yo debo admitir).

Ejecutivos en este planeta, por favor tome nota de estas reacciones, ya que encarnan los verdaderos sentimientos y creencias de muchos profesionales de la industria. Realmente sienten que no necesitan estimación (ya que no es su dinero de todos modos) y no quieren ser responsables de nada, expresando la velocidad en "aleatorio, no repetible, unidades de medida arbitrarias no estandarizadas (p.ej., puntos de la historia)"Y, por tanto, nunca responsable de nada. Tirar dinero a equipos ágiles y esperar lo mejor puede funcionar en algunos casos, pero lo decepcionará en la mayoría de los casos.! "El software es una R&D El proceso y los resultados son impredecibles!' Esto no es verdad! La estimación de software no es fácil, pero se puede hacer de manera precisa, evitando una gran cantidad de sobrecostos en el cronograma y el presupuesto, como lo vemos hoy!

Realmente, este es el problema básico de toda la industria del software. Al negar que sea posible medir con precisión el tamaño de los requisitos de software con el uso de estándares internacionales, la madurez de la estimación sigue siendo baja. Si estudias el trabajo del profesor Abran, por ejemplo, su estudio sobre el poder de predicción de los puntos de la historia frente a la medición del tamaño funcional (https://tinyurl.com/y9jf98tq), Ves que incluso la unidad de medida de esfuerzo arbitraria inventada para que los equipos sigan siendo incomparables e inexplicables (puntos de la historia), no tiene tanto poder de predicción cuando se trata de estimación de software como la medición de tamaño funcional.

La pregunta fundamental sigue siendo ... ¿los ejecutivos de este mundo que tratan con equipos ágiles realmente siguen comprando esto?? En algún momento, pensaría que comprenden que están engañados para que arrojen más dinero a los equipos con resultados cuestionables a seguir.: menos funcionalidad de la esperada / requerida, baja calidad, mayor costo, especialmente en mantenimiento.

ICEAA y Nesma confían en que el Estimador de costos de software certificado se convertirá en una verdadera profesión en la industria., que va a ayudar a las organizaciones a mejorar la madurez de sus procesos con respecto a la estimación, controlar, medición del desempeño, evaluación comparativa y abastecimiento. Software Cost Estimator ayudará a los ejecutivos de TI a mantener el control de sus ágiles equipos de entrega sin molestar a los equipos con gastos generales y desperdicios., al tiempo que aporta suficiente transparencia para tomar decisiones informadas.

Comparte este artículo en:

Deja una respuesta