¿Existe realmente una relación entre el número de personas asignadas a un proyecto y el número de defectos?

12

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

Observe también que existe una correlación entre el esfuerzo y los 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 persona-tiempo (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, puntos de función o SLOC que componen el proyecto.

Esto parece contradictorio, suponiendo un buen proceso e ingenieros capaces. Por ejemplo, tener más personas significa tener más ojos en 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 apropiadas.

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

— Thomas Owens
fuente

10

"agregar mano de obra a un proyecto de software tardío lo hace más tarde" - Fred Brooks

— Finalizado el

2

@Oded Agregar personas tarde no se menciona en absoluto. Además, la ley de Brooks no dice nada sobre defectos, sino un aumento en los canales de comunicación para tomar decisiones y mantener informadas a las personas. Sospecharía que, como sugiere Karl Bielefeldt, las dificultades de comunicación pueden conducir a defectos.

— Thomas Owens

@ThomasOwens: Sí, la cita es sobre el aumento de los canales de comunicación (y, por lo tanto, las dificultades), con el supuesto de que esto conduciría a defectos.

— Finalizado el

Todavía diría que cuando se lanzan montones de desarrolladores a un proyecto, a menudo es indicativo de una marcha de la muerte.

— Morgan Herlocker

@ironcode El número de desarrolladores en un proyecto debe estar determinado por el tamaño y el alcance del proyecto, y cómo está organizado. Tener demasiados desarrolladores o agregar más desarrolladores más tarde son signos de una mala gestión, tal vez una marcha de la muerte.

— Thomas Owens

14

Mi intuición es así:

Cuantas más personas se asignen a un proyecto de determinado tamaño, mayor será la sobrecarga de comunicación
=> mayores serán las posibilidades de malentendidos y todo tipo de problemas de comunicación
=> mayor será 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
=> mayor será el número de defectos resultantes.

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

Como nota al margen, sus suposiciones enfatizadas a continuación son en mi humilde opinión (lamentablemente) bastante fuertes, teniendo en cuenta el estado de nuestra profesión:

Esto parece contradictorio, suponiendo un buen proceso e ingenieros capaces . [...] mi intuición sugiere que hay poca relación entre el esfuerzo y los defectos en un proyecto que utiliza técnicas de calidad apropiadas .

— Péter Török
fuente

Atribuí el gráfico de Thrashing / Process / Productivity de McConnell para resolver eso. Si no presenta nuevas personas, se acostumbra a la sobrecarga de comunicación involucrada en el proyecto temprano y mantener la comunicación adecuada se vuelve más fácil y más natural. Esto se desglosa según la Ley de Brooks, cuando agrega personas a un proyecto tarde, lo que sería lo mismo que presentar el proceso tarde a un proyecto: un aumento en los canales de comunicación significa un aumento en la agitación y una interrupción de la comunicación que conduce a defectos. Sin embargo, podría estar fuera de lugar en eso. Su razonamiento puede ser válido.

— Thomas Owens

Pero con menos personas es menos probable que les permita mantener sus puntos fuertes. ¿Es más fácil contratar algunos buenos desarrolladores que en realidad podrían ser mejores si pueden enfocarse en un área en lugar de solo un gurú que pueda hacer todo?

— JeffO

@ Jeff O, tienes un punto. OTOH si cada desarrollador se enfoca solo en su propia área fuerte, la comunicación entre ellos puede ser aún más problemática.

— Péter Török

1

¿La comunicación es más problemática o simplemente se requiere?

— JeffO

@Jeff O, OMI, cuanto menos entiendan sobre el área del otro, más comunicación se requiere y mayores serán las posibilidades de malentendidos y suposiciones falsas.

— Péter Török

5

Podría ser solo una correlación. La gerencia tiende a asignar a más personas para que ayuden en proyectos que consideran más complejos, o proyectos que se están quedando atrás debido a muchos errores intransigentes, o proyectos que requieren mucho acoplamiento entre varios componentes. Si pudiera tomar decisiones de gestión fuera de la mezcla, sospecho que la correlación al menos disminuiría, si no se revierte.

— Karl Bielefeldt
fuente

El único problema con esto es que no se menciona el cambio (específicamente un aumento) en el personal con el tiempo. Simplemente dice que si tiene un proyecto con n personas, tendrá m defectos. Agregar personas introduce problemas y problemas de comunicación, pero eso (por lo que puedo decir) está más allá del alcance de la relación simple entre defectos de personas. Estoy de acuerdo en que un efecto secundario de agregar personas tarde es no solo un aumento en los canales de comunicación y la necesidad de capacitar a las personas y ponerlas al día (Ley de Brooks), sino también un aumento potencial en los defectos. Pero eso está fuera de alcance.

— Thomas Owens

Agregar personas tarde es solo un factor que mencioné. La gerencia todavía tiene una tendencia a asignar más personas por adelantado a proyectos que anticipan que son más riesgosos o complejos.

— Karl Bielefeldt

El objetivo de SLIM (y otras herramientas de estimación, cuando se usa correctamente) es ayudar con la estimación de la cantidad necesaria de personas, el costo de un proyecto, el tiempo requerido, etc. Sin embargo, eso requiere que la herramienta se entienda y se use correctamente.

— Thomas Owens

3

Dadas las definiciones recientemente actualizadas de tamaño y esfuerzo, sugeriría que quizás los resultados se deban al hecho de que Effort (total de horas-hombre) es en realidad un mejor estimador del tamaño real del proyecto que las medidas que está utilizando la fuente (Effort 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 cual no es sorprendente en absoluto.

— psr
fuente

2

Esto parece contradictorio, suponiendo un buen proceso e ingenieros capaces.

No creo que puedas asumir ninguno de estos en el mundo real. Cuantas más personas participen en un proyecto, es más probable que tenga manzanas podridas que no puedan seguir el ritmo y frenarán a los mejores desarrolladores. Incluso si sigue las suposiciones, hay algunas otras cosas que ralentizan los proyectos y causan más defectos a medida que aumenta el número de personas:

gastos generales de comunicación
gastos generales de lectura de código (con esto quiero decir que incluso los mejores desarrolladores toman más tiempo para leer y consumir el código de otras personas que el suyo)
las pruebas deben ser más exhaustivas (todos disparamos para obtener una cobertura de prueba del 100%, pero eso rara vez ocurre en el mundo real. Cuantas más personas pones en un proyecto, la refactorización más aterradora se obtiene sin pruebas automatizadas extremadamente exhaustivas, ya que solo esperas tus cambios no tendrá efectos secundarios. No todas las pruebas pueden automatizarse de manera razonable, lo que lleva aún más tiempo).

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

— Morgan Herlocker
fuente

Si la única forma de evitar que 4 desarrolladores trabajen en el mismo archivo es limitar el tamaño del equipo a 3, tienes mayores problemas.

— JeffO

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 mayores números 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 correlacionamos eso con el número total de médicos en el país, estoy seguro de que podríamos decir que "los países con más médicos tuvieron más muertes". Esto no se debe a que los médicos causaron las muertes, sino a que un gran número de médicos es indicativo de una gran población.

— Daniel B
fuente

Para su ejemplo con Windows, estoy seguro de que Windows también tiene más oportunidades de defectos simplemente porque es más grande. Si un desarrollador escribiera un sistema que era 10 SLOC y un sistema que era 10000 SLOC, el sistema con 10000 SLOC tendría una mayor probabilidad de tener un defecto (que incluye errores tipográficos que impiden la compilación, faltan puntos y comas, errores lógicos, etc.) . Por lo general, los proyectos más grandes tendrían más ingenieros, pero la relación no es entre la cantidad de personas y defectos, sino el tamaño y los defectos.

— Thomas Owens

@ThomasOwens - sí, ese era exactamente mi punto.

— Daniel B

¿Por qué no se compararían los errores en relación con el tamaño y la complejidad del proyecto?

— JeffO

@JeffO: medirlo de manera relativa no es completamente trivial (¿cómo lo haces exactamente?). Quizás la declaración original se está sacando de contexto, pero los autores rara vez se refieren a resultados complejos y calculados simplemente como "defectos". En tal caso, esperaría otra palabra como "calidad" (lo que implica que se realizó algún cálculo), o una frase más larga como "defectos por ingeniero asignado". Quizás estoy siendo un poco cínico con los autores aquí :)

— Daniel B

@Jeff Lo estarían. Pero compararía los defectos con el tamaño y la complejidad, no con el número de personas. A medida que aumenta el tamaño y la complejidad, aumentan los defectos y aumenta el número de personas. Entonces sí, aunque el número de personas aumenta, ese aumento en las personas no aumenta el número de defectos.

— Thomas Owens

1

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

Observar el número de defectos inyectados en función del esfuerzo puede tener sentido siempre y cuando suponga que un mayor esfuerzo necesariamente requiere un mayor tamaño, ya que existe una fuerte correlación entre el número de defectos y el 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 (p. Ej., LOC) y el número 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, como usted ha señalado, de personas y problemas de procesos. Dicho esto, los defectos en función del tamaño son una gran medida para comprender si hay un problema y para evaluar la efectividad del cambio.

— Miguel
fuente

0

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

Creo que debe gestionarse bien, pero eso no es fácil. Los pequeños equipos formados por desarrolladores de calidad pueden gestionarse a sí mismos. 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. Pon a los desarrolladores mejores o más experimentados en las áreas difíciles. Elimina algunas de las tareas mundanas o que no son de programación de tus mejores desarrolladores y deja que los desarrolladores junior se encarguen de las interrupciones. 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 por la cantidad de trabajo requerido y los límites de tiempo. Es posible que tenga a alguien que pueda concentrarse en un área específica y volverse más hábil. Es genial tener ese conocimiento completo, pero a veces con un poco de dirección, un desarrollador menor puede tomar algunas instrucciones y ejecutarlo.

La realidad es que no hay muchas personas que hayan manejado un equipo grande en un proyecto exitoso. Incluso si todos son talentosos, es difícil para los equipos grandes autogestionarse. ¿Los egos se interponen en el camino?

— JeffO
fuente