Cantidad de trabajo de rutina en el desarrollo de software y su efecto en la estimación.

Estoy convencido de que la cantidad de trabajo de rutina en el desarrollo de software es, y debería ser, relativamente pequeña, si no insignificante, y que este es el problema fundamental de la estimación de software.

Permítanme describir cómo llego a esta conclusión y decirme si la argumentación tiene fallas graves:

Todo lo que se puede estimar con alta precisión es el trabajo de rutina, lo que significa cosas que se han hecho antes. Todos los demás tipos de trabajo que implican investigación y creatividad no pueden estimarse realmente, al menos no con una precisión de, digamos, +/- 20 por ciento.
El desarrollo de software se trata de evitar tareas repetitivas. Uno de sus principios básicos es SECO (no se repita). Cada vez que un programador se encuentra haciendo cosas repetitivas, es hora de encontrar una abstracción que evite esta repetición. Estas abstracciones pueden ser cosas simples como extraer el código repetido en una función o ponerlo en un bucle. También pueden ser más complejos como crear un lenguaje específico de dominio. En cualquier caso, implementarlos implicará investigación (¿alguien ha hecho esto antes?) O creatividad.

De estos dos puntos extraigo la conclusión anterior.

En realidad, me he estado preguntando durante bastante tiempo por qué esta relación no se menciona en ninguna otra discusión, publicación de blog o artículo sobre estimación de software. ¿Es demasiado teórico? ¿Están equivocados mis supuestos? O es demasiado trivial, pero entonces, ¿por qué la mayoría de los desarrolladores que conozco creen que pueden hacer estimaciones con una precisión de +/- 20 por ciento o mejor?

development-process estimation Frank Puffer
fuente

El 99% de todo el desarrollo de software fuera de áreas como los núcleos se han realizado miles de veces antes. Demasiados desarrolladores solo quieren hacer todo de una manera nueva y elegante, reinventando los mismos viejos problemas una y otra vez.

Doblado

@Bent: ¿Entonces estás diciendo que el desarrollo de software es principalmente copiar y pegar? Sé que muchos desarrolladores trabajan de esa manera y a menudo descubrieron que esto conduce a un código que no se puede mantener. Pero esa es una historia diferente. Incluso si alguien trabaja de esa manera, tiene que averiguar qué copiar y de dónde. Esto es algo que también consideraría como trabajo de investigación.

Frank Puffer

@rwong: Por supuesto, tiene sentido usar bibliotecas. Pero encontrar la función correcta en una biblioteca y la forma correcta de usarla es un trabajo de investigación (si la biblioteca es queja y / o no la conoce bien) o trivial (si ya conoce esa función). Lo que usted llama 'código de pegamento' es, en mi experiencia, a menudo complejo. Implementarlo no es un trabajo de rutina necesario.

Frank Puffer

@ JohnR.Strohm: No leí estos libros específicos, pero estoy familiarizado con los conceptos básicos de COCOMO; sin embargo, nunca lo he usado en la práctica. También he leído otros dos o tres libros de DeMarco. ¿Podría dar una pista sobre qué contenido específico está relacionado con mi pregunta?

Frank Puffer

@FrankPuffer, la "Economía de la Ingeniería del Software" de Boehm es una lectura obligatoria para la estimación del software. El libro de Demarco no se queda atrás. La respuesta CORTA es esta: si está lo suficientemente familiarizado con lo que debe hacer el software para estimarlo, está lo suficientemente familiarizado como para considerarlo relativamente rutinario.

John R. Strohm

Respuestas:

En cualquier proyecto dado, esto puede ser cierto. Sin embargo, si trabaja en proyectos múltiples y similares para diferentes compañías a lo largo de los años, puede encontrarse 'resolviendo' básicamente el mismo problema muchas veces con solo pequeñas variaciones.

Por ejemplo, he escrito capas de acceso a datos tantas veces que ahora prefiero hacerlo "a mano" en lugar de usar el popular ORM del mes. Es más rápido y fácil para mí lidiar con los 'problemas de rutina' con soluciones conocidas que encontrar y resolver nuevas peculiaridades en componentes de terceros.

Obviamente, podría escribir mi propio ORM para simplificar el código repetitivo sin agregar las peculiaridades desconocidas en el sistema de otra persona, pero este código pertenecería a la compañía para la que estaba trabajando en ese momento, y otros desarrolladores lo encontrarían tan peculiar como cualquier otro ORM de terceros.

De manera similar, en mi experiencia, la mayoría de la programación es la automatización de los procesos comerciales y, aunque a cada negocio le gusta pensar que sus procesos son únicos para ellos; En realidad no lo son.

¡No quiere decir que la estimación sea fácil! Es más fácil, pero creo que en estos días el problema de la estimación se debe a la insuficiencia de los requisitos y no al tiempo dedicado a la codificación.

Los requisitos tienden a caer en tres categorías:

Vago, detalles que quedan para el desarrollador.

"Hazme un sitio web, tiene que ser genial y vender mis widgets"

Estos tienden a ser los más fáciles de estimar, ya que cuando ocurre un problema difícil e inesperado, simplemente puede cambiar los requisitos a algo funcionalmente equivalente y evitar el problema.

Muy especifico

"Hacer el color de fondo del encabezado # ff1100"

Súper rápido de hacer y, nuevamente, fácil de estimar. ¡Pero! El requisito está obligado a cambiar. "Hmm no, no lo dudes, prueba este otro rojo" o "¡Espera! ¡Solo quise decir en esa página!" así que el lapso de tiempo real de "cuánto tiempo hasta que esté satisfecho con el color del encabezado" no tiene nada que ver con las estimaciones de codificación

Vago, detalles asumidos

"Hazme un sitio web (como Facebook)"

Aquí la multitud de suposiciones no declaradas, "por supuesto que querrá un logotipo diferente", "debe tener un desplazamiento infinito", "debe ser escalable a mil millones de usuarios". controle efectivamente la estimación. O el desarrollador piensa en todo y empuja la estimación más allá de las expectativas "1 hora de hombre de mil millones", o piensa / asume que solo se requieren las características básicas y da una estimación demasiado baja. "Oh, una semana o dos, supongo que solo quieres poner Facebook en un iframe ¿verdad?"

Con experiencia, la codificación es muy rápida, pero los requisitos de diseño son (por lo general) difíciles, y esto es cada vez más necesario para los no codificadores. Con metodologías ágiles que aumentan la velocidad de codificación al trasladar esta responsabilidad al 'negocio' en lugar de a los desarrolladores.

Ewan
fuente

Estoy totalmente de acuerdo con lo que ha escrito sobre requisitos inadecuados, pero esa es una historia diferente. En la primera parte de su respuesta, dice que a menudo sigue utilizando técnicas bien conocidas para que una gran parte de su trabajo se convierta en rutina. Lo haces deliberadamente sin abstracciones adicionales. Esto probablemente funciona bien por un corto período de tiempo, quizás de 2 a 5 años, dependiendo de las tecnologías que esté utilizando. Pero entonces puede notar que no ha mejorado su proceso tanto como algunos de sus competidores. Además, otros desarrolladores que mantendrán su código más tarde podrían tener un problema.

Frank Puffer

Obviamente, no es que nunca use cosas de terceros. El punto es que si ya sabes cómo hacer algo con la herramienta X, la estimación es fácil

Ewan

No solo la estimación sino también la implementación se vuelve fácil en este caso. Si todo tu proyecto es así, tienes suerte. Pero en mi experiencia esto solo sucede en pequeños proyectos. Todos los proyectos más grandes (> 10 días) en los que estuve involucrado requirieron algunos conceptos o tecnologías nuevos y eso es lo que causó la mayor parte del trabajo, lo que hizo que el esfuerzo por las cosas estándar fuera insignificante.

Frank Puffer

No entremos en una guerra de llamas de 'quién es el mejor programador'. Todo lo que digo es que mientras más cosas hayas hecho antes, menos cosas nuevas hay. Sin embargo, si todos sus proyectos exigen el uso de nuevas tecnologías para la mayoría de las características ... Parece extraño

Ewan

@Ewan "conceptos o tecnologías". Para mí, el primero tiende a relacionarse con las reglas de negocio y / o lo que quiere el diseñador. No se trata solo de nuevas tecnologías.

Izkata

¿Por qué la mayoría de los desarrolladores que conozco creen que pueden hacer estimaciones con una precisión de +/- 20 por ciento o mejor?

Porque estimamos nuestra paciencia con el problema mucho más que el problema real.

Si voy a animar una pelota que rebota, podría pasar un día, una semana, un mes o un año y seguir teniendo una animación de una pelota que rebota. Espero que se vea mejor cuanto más tiempo pase en él, pero en cierto momento estoy siendo ridículo.

La cantidad de esfuerzo que puse para hacer que la pelota rebote es una función del tiempo que es razonable gastar en ella. Si mi nivel de habilidad no es suficiente, puedo terminar con una pelota que simplemente se queda allí. Pero cuando llegue la fecha límite, ¿debería dejarla pasar o al menos obtener una pelota en la pantalla? Waterfall insistió en que la pelota rebotara, por lo que el horario se deslizó. Agile dice que solo saquen la pelota. Al menos descubriremos cuánto le importa a la gente el rebote. Entonces la calidad se deslizó.

Trato de asegurarme de que mis bolas rebotan, pero cuando se acerca la fecha límite, es mejor producir una bola estática que nada. Por lo tanto, calculo el tiempo en función de lo que parece un tiempo razonable para dedicarlo a un problema antes de hablar sobre alternativas. A veces la pelota simplemente no va a rebotar. A veces eso está bien. Desaparecer por un mes no está bien.

naranja confitada
fuente

Buen punto, entonces básicamente estás diciendo que la estimación debe basarse en el valor que tiene una determinada característica para el cliente (o propietario del producto). Personalmente, me gusta este enfoque, pero en mi experiencia no es así como se entiende generalmente la estimación de software, incluso en un entorno ágil. Un inconveniente es que a menudo no tiene esta información sobre el valor de una característica para el cliente. Otro inconveniente es que no puede manejar paquetes de trabajo que no resultan directamente en una característica visible para el cliente.

Frank Puffer

@FrankPuffer No estoy de acuerdo con que los métodos ágiles no lo aclaren. SCRUM en particular ni siquiera le pide a los desarrolladores que estimen hasta que el valor de la característica sea tan alto que en realidad esté programado para realizarse, es decir, justo a tiempo. Los métodos ágiles son particularmente adecuados para esto: primero identifique las características con el valor comercial más alto, luego estúmelas, luego HAGA ELLAS, y vea cuánto tiempo realmente tomó. Enjuague la repetición. Después de unos pocos ciclos de esto, tendrá una muy buena idea de la estimación del tiempo de desarrollo real.

RibaldEddie