Publicación 4 - La Ley de brooks de El Mitico Hombre Mes PDF

Preview

Summary

Download Publicación 4 - La Ley de brooks de El Mitico Hombre Mes PDF

Description

Producir software no es una cuestión trivial: Ley de Brooks 27 Febrero, 2013 por Joaquín Oriente — 7 Comments

“

“Lo que en otras ingenierías son técnicas probadas y rutinarias, en ingeniería software se consideran innovaciones radicales” The Mythical Man-Month (1975) – Fred Brooks

En la actualidad estamos viviendo un momento histórico mágico, donde todo parece quererse solucionar por la vía del recorte, en un intento de querer aumentar la productividad, aún

en

aras

de

una

menor

calidad

de

lo

que

producimos.Porque ya vimos que la calidad muchas veces no está ni se la espera, y hasta ahí lo vemos claro.

Aún así, y propulsado por los requisitos de licitaciones o proyectos europeos varios, parece que se han establecido como una obligación, o algo bastante “del día a día” (y yo estoy muy feliz con ello, que conste) las certicaciones y modelos de evaluación de la calidad de los procesos de desarrollo software, como pueden ser ISO 15504 o CMMI. Parece que de esta manera hemos encontrado, un camino de mejora continua para tratar de controlar nuestro berenjenal propio, o la gran variabilidad que sufren los procesos de desarrollo de muchas factorías software actuales. No obstante, alcanzar el nivel necesario de mejora continua en una organización para poder atacar esta variabilidad está a años luz de muchas factorías software españolas (vimos un camino de mejora continua enfocado a procesos industriales en este vídeo como una escalera donde no te puedes saltar ningún paso), teniendo en cuenta que estas mismas empresas no están dispuestas a invertir los recursos necesarios para poder alcanzarlo. Y en parte es porque estas empresas están viendo otra película, ya que aunque pocas veces alcanzan los resultados que esperan se niegan a ver la realidad: producir software no es una cuestión trivial trivial, sino que debe partir de técnicas y metodologías propias de una ingeniería. Ya en 1975 Fred Brooks desmontaba en The Mythical Man-

Month la tentación de asemejar las tareas de desarrollo software y los trabajadores asignados a las mismas al hecho de cosechar trigo o recoger algodón. Una de las diferencias existentes entre la cosecha de trigo y el desarrollo de software (una de tantas

) se da en la

existencia o no de tareas en los que los trabajadores pueden trabajar de manera independiente o aislada.

En la recogida de algodón sí que se da esta condición, con lo que ante un retraso en la campaña de recogida se puede acelerar

sus

tareas

simplemente

añadiendo

más

trabajadores. Esto no se da en las tareas de desarrollo software donde existe un alto nivel de dependencia e intercomunicación entre sus partes y los miembros de los equipos que las llevan a cabo. De esta forma, ante un proyecto retrasado, añadir más personas al equipo puede ser contraproducente, ya que de entrada se están utilizando más recursos para abordar las mismas tareas, por otra parte se está particionando más el trabajo, y nalmente se está añadiendo mayor complejidad a las comunicaciones entre el equipo. Esto en principio no es malo, pero añadir mayor complejidad en el proyecto en curso, una vez existe una desviación o retraso en el mismo, puede ser letal.

“

El esfuerzo por coordinar las diferentes partes de una tarea tiene un coste de n(n – 1)/2, siendo n el número de partes. Y esto si solamente deben coordinarse de dos en dos, ya que si se dan otro tipo de grupos el sobrecoste es mucho más elevado.

Además, agregar más integrantes a un equipo añade una tarea que antes no existía, hacer la transferencia de los conocimientos necesarios a los nuevos integrantes, lo que es doblemente dramático, ya que se va a invertir tiempo de un integrante del equipo inicial en formar a las nuevas adquisiciones. De esta forma, la Ley de Brooks se formula como sigue:

“

“Añadir más personas a un proy proyecto ecto (software) retr retrasado asado lo hace retrasarse aún más” más”..

Por todo esto, estimar un desarrollo software o intentar replanicar sus tareas no es una cuestión que se pueda abordar simplemente con el sentido común o con el dedo. Se hacen necesarias técnicas especícas como puntos función o puntos por caso de uso, o las aproximaciones de las metodologías ágiles, donde se acepta la dicultad intrínseca de planicar y se trata de planicar “a corto”, para pegarse a la realidad y no negarla con engañosos diagramas de Gantt que se convierten en un brindis al Sol. Si además, añadimos a la salsa la necesidad de tener en cuenta en las planicaciones de los desarrollos el tiempo que se necesita para hacer pruebas unitarias, de integración, de sistema…

“

Brooks hace una aproximación de que es necesario utilizar el 50% de tiempo de una tarea de desarrollo en realizar pruebas, porque si no invertimos este tiempo lo pagaremos más caro, más tarde y seguramente fuera de plazo.

Y lo dejamos aquí, no sin hacer evidente que hay ciertas cuestiones, como hacer estimaciones y planicaciones creíbles o tener un buen plan de pruebas, que no son prescindibles en un proyecto software. Todo cuenta y no es fácil, ni intuitivo, juntar las piezas. ¿Piensas que hay algo de realidad en todo esto? Todo comentario será bienvenido. Mientras tanto seguimos en la brecha. Salud y Calidad! Photo credit: jurvetson / Foter.com / CC BY...