¿Existe realmente una relación entre la cantidad de personas asignadas a un proyecto y la cantidad de defectos?

12

Aquí hay una cita de un manual de capacitación en el trabajo sobre SLIM y estimación de software:

  

Note también, hay una correlación entre Esfuerzo y Defectos. Esto significa que cuantas más personas se asignen a un proyecto de un tamaño determinado, más defectos habrá.

El esfuerzo es tiempo personal (persona-años, persona-meses) para el proyecto. Defectos es el recuento de defectos detectados en cualquier punto del ciclo de vida. El tamaño se define como los casos de uso, los puntos de función o SLOC que componen el proyecto.

Esto parece contrario a la intuición, suponiendo un buen proceso e ingenieros capaces. Por ejemplo, tener más personas significa más información sobre todos los artefactos (especificaciones de requisitos, diseños, códigos, pruebas). Además de tener más ojos, mi intuición sugiere que hay poca relación entre el esfuerzo y los defectos en un proyecto que utiliza técnicas de calidad adecuadas.

No he podido encontrar ningún documento, aparte de aquellos sobre el Modelo de Putnam (que es usado por SLIM), que sugiere algún tipo de relación conocida entre defectos y esfuerzo o defectos y la cantidad de personas en un proyecto. ¿Es esta una relación conocida y la afirmación de que "más personas = más defectos" es válida?

    
pregunta Thomas Owens 30.09.2011 - 14:53

7 respuestas

14

Mi intuición es así:

Cuantas más personas se asignen a un proyecto de un tamaño determinado, mayor será la sobrecarga de comunicación
= > cuanto mayor sea la posibilidad de malentendidos y todo tipo de problemas de comunicación
= > cuanto mayor sea el número de defectos resultantes.

Y

Los buenos desarrolladores son más raros, por lo tanto, más difíciles de encontrar y contratar, que los mediocres / malos. = > cuantas más personas se asignen a un proyecto de un tamaño determinado, menor será su nivel promedio de competencia
= > cuanto mayor sea el número de defectos resultantes.

Pero estos pueden ser solo mi razonamiento, no tengo evidencia de apoyo.

Como nota al margen, sus supuestos que se destacan a continuación son IMHO (lamentablemente) bastante sólidos, teniendo en cuenta el estado de nuestra profesión:

  

Esto parece contrario a la intuición, suponiendo un buen proceso e ingenieros capaces . mi intuición sugiere que existe poca relación entre el esfuerzo y los defectos en un proyecto que utiliza técnicas de calidad adecuadas .

    
respondido por el Péter Török 30.09.2011 - 15:17
5

Podría ser simplemente una correlación. La administración tiende a asignar más personas para ayudar en los proyectos que consideren más complejos, o proyectos que se están retrasando debido a muchos errores intransigentes, o proyectos que requieren una gran cantidad de acoplamiento entre varios componentes. Si pudiera tomar decisiones administrativas fuera de la mezcla, sospecho que la correlación al menos disminuiría, si no se revertiría.

    
respondido por el Karl Bielefeldt 30.09.2011 - 15:02
3

Dadas las definiciones actualizadas de tamaño y esfuerzo, sugeriría que quizás los resultados se deben al hecho de que el Esfuerzo (total de horas-hombre) es en realidad un mejor estimador del tamaño real del proyecto que las medidas que usa la fuente ( El esfuerzo sería una medida perfecta si todos los equipos y los recursos del equipo fueran equivalentes.

Por lo tanto, lo que realmente está sucediendo es que los proyectos más grandes tienen más defectos, lo que no es sorprendente en absoluto.

    
respondido por el psr 30.09.2011 - 20:48
2
  

Esto parece contrario a la intuición, suponiendo un buen proceso e ingenieros capaces.

No creo que puedas asumir ninguno de estos en el mundo real. Cuanta más gente participe en un proyecto, más probabilidades tendrá de tener manzanas malas que no puedan mantenerse al día y ralentizarán a los mejores desarrolladores. Incluso si sigue los supuestos, hay algunas otras cosas que retrasan los proyectos y causan más defectos a medida que aumenta el número de personas:

  • gastos generales de comunicación
  • sobrecarga de lectura de código (con esto quiero decir que incluso los mejores desarrolladores tardan más tiempo en leer y consumir el código de otras personas que en el suyo)
  • las pruebas deben ser más exhaustivas (todos buscamos una cobertura de prueba del 100%, pero eso rara vez sucede en el mundo real. Cuantas más personas se ponen en un proyecto, la refactorización más espantosa se obtiene sin pruebas automatizadas extremadamente completas, ya que solo estás esperando que sus cambios no tengan efectos secundarios. No todas las pruebas pueden automatizarse de una manera razonable, lo que lleva incluso más tiempo).

En mi experiencia, los efectos negativos de los proyectos cargados con desarrolladores disminuyen cuando el proyecto es muy modular y solo tiene 1 o 2 personas por nivel. No me importa qué sistema de control de versiones esté utilizando, tener 4 desarrolladores y todos los registros de combinación automática en el mismo archivo a la vez probablemente sea una mala idea.

    
respondido por el Morgan Herlocker 30.09.2011 - 15:18
2

Hay una diferencia entre correlación y causalidad; La cita parece estar diciendo que el número total de defectos tiende a ser mayor para proyectos donde se asignan un mayor número de ingenieros. Esto tiene mucho sentido para mí, estoy seguro de que MS Windows tiene más defectos que las aplicaciones que creo, pero eso no significa que mis aplicaciones tengan una calidad superior.

Para dar otro ejemplo más abstracto: si tomamos el número total de muertes por país y lo relacionamos con el número total de médicos en el país, estoy seguro de que podríamos decir "los países con más médicos tuvieron más muertes". Esto no sería porque los médicos causaron las muertes, sino que un gran número de médicos son indicativos de una gran población.

    
respondido por el Daniel B 30.09.2011 - 15:41
1

Dejemos de lado la afirmación sobre el número de personas por un momento.

El hecho de considerar el número de defectos inyectados como una función del esfuerzo puede tener sentido siempre que se suponga que un mayor esfuerzo necesariamente requiere un aumento de tamaño, ya que existe una fuerte correlación entre el número de defectos y tamaño del software.

Entonces, si asume que cuanto más esfuerzo se pone en un proyecto, más líneas de código se escriben, entonces probablemente podría usar el esfuerzo como proxy del tamaño para predecir la cantidad de defectos. Watts Humphrey, Capers Jones y otros han demostrado una y otra vez la correlación entre el tamaño (por ejemplo, LOC) y la cantidad de defectos.

No veo cómo se ajusta el número de personas, aparte de que más personas implican más esfuerzo.

Como nota al margen, no confunda la correlación con la causalidad. Si bien existe una correlación entre el tamaño y el número de defectos inyectados, el tamaño no es la causa. La causa generalmente proviene de, como usted ha señalado, las personas y los problemas del proceso. Dicho esto, los defectos en función del tamaño son una gran medida para comprender si existe un problema y para evaluar la efectividad del cambio.

    
respondido por el Michael 30.09.2011 - 17:19
0

Supongo que esto se limita a los miembros del equipo de programación central y no a una situación en la que haya especialistas como: UI, UX, DBA, etc.

Creo que debe manejarse bien, pero eso no es fácil. Pequeños equipos formados por desarrolladores de calidad pueden manejarse solos. Es más probable que evite grandes secciones de código creadas por alguien con menos talento.

Tener más miembros del equipo puede facilitar la división de tareas. Ponga a los devlopers mejores o más experimentados en las áreas difíciles. Quita algunas de las tareas mundanas o no programadas de tus mejores desarrolladores y deja que los desarrolladores junior manejen las interacciones. Esto requerirá más planificación y reflexión, pero brinda la oportunidad de aprovechar su talento.

Existe la idea de que es mejor tener un gran desarrollador que necesite adquirir una nueva habilidad que un desarrollador por debajo del promedio que ya lo sabe. Esto es genial si tienes tiempo. Probablemente la razón por la que se están asignando más desarrolladores a un proyecto es debido a la cantidad de trabajo requerido y los límites de tiempo. Es posible que tengas a alguien que pueda enfocarse en un área específica y que tenga más habilidades. Es genial tener ese conocimiento completo, pero a veces con un poco de dirección, un desarrollador menor puede tomar algunas instrucciones y correr con él.

La realidad es que no hay muchas personas que hayan dirigido un gran equipo en un proyecto exitoso. Incluso si todos tienen talento, es difícil que los equipos grandes se autogestionen. ¿Se interponen los egos?

    
respondido por el JeffO 30.09.2011 - 17:19

Lea otras preguntas en las etiquetas