archivo

Archivo de la etiqueta: Yourdon

Tan negativo resulta en un proyecto de desarrollo de software el exceso de documentación como la carencia de la misma.

La documentación debe ser adecuada a la naturaleza del software que se va a desarrollar y tener utilidad, como mínimo para el momento en que se está realizando el proyecto. Si se pierde el enfoque del momento presente y se centra en la utilidad futura que pueda tener la misma, puede que al final no sea útil ni después ni ahora.

La documentación de un proyecto es un instrumento, no un fin, de igual forma que lo es la ingeniería del software. Si la documentación es un objeto decorativo no es útil, es esfuerzo invertido para obtener muy poco valor a cambio.

Esa es mi opinión sobre la documentación, Edward Nash Yourdon, tiene la suya propia que hace patente en la siguiente reflexión, si bien, estoy seguro que el propio Yourdon matizaría sin duda la misma: “No hay nada más despreciable en el mundo de la programación que un programa sin documentar”.

Ed Yourdon destaca dos variables como causantes de que la crisis del software siga hoy tan vigente como cuando Edsger Dijkstra hizo referencia a ella en la década de los 60.

Por un lado vuelve a destacar la falta de habilidades negociadoras que, por regla general, existe en quiénes negocian los contratos y las condiciones de los proyectos, de manera que se aceptan unos parámetros presupuestarios, de plazos y de calidad muy difíciles de cumplir y por otro el hecho de que las nuevas generaciones de desarrolladores no presten la atención que se merece a la experiencia de los más veteranos, lo que provoca que de manera reiterada se vuelva a caer en los mismos errores.

Yo llevo gestionando proyectos software desde hace ocho años y mientras que la tecnología avanza a un ritmo vertiginoso, los problemas de los proyectos de hoy son los mismos que los de ayer.

Comenta Ed Yourdon que independientemente de que existan circunstancias que te empujen irremediablemente a un Death March Project (decisiones de empresa ya sea por la parte cliente o proveedora), en muchas ocasiones se aceptan condiciones que podrían haber sido evitadas o, al menos, paliadas con la existencia de una negociación bien llevada.

El desarrollo de software no solo requiere habilidad técnica, es algo que sabemos todos y que comento con relativa frecuencia en mi blog, sino que son muchas variables las que intervienen para que un proyecto de desarrollo de software, una empresa o una organización tengan éxito.

Una persona no tiene por qué reunir todos esos ingredientes, estamos hablando de que el desarrollo de software es un trabajo en equipo y que va más allá del ámbito del proyecto. Lo importante es que la suma de los ingredientes que proporcionan las personas permitan hacer una buena receta.

La negociación es una habilidad. Hay personas que de manera innata lo hacen muy bien, sin embargo, además de ese instinto, cuanta mucho la técnica y sobre todo la experiencia.

Es cierto que una negociación influye mucho tu posición en la misma, ya que a veces se juega con las cartas marcadas, pero incluso en las circunstancias más adversas se pueden conseguir logros.

Comenta Ed Yourdon que la mejor manera de evitar un Death March Project es no participando en esa locura.

Básicamente lo que viene a decir Yourdon es que poca solución hay cuando las condiciones para la realización del proyecto no son realistas.

Lo peor de todo esto es que la mayoría de la gente que sufre este tipo de proyectos (por parte del proveedor) no son los que han tomado la decisión de participar en él. Probablemente si ellos sufrieran en primera persona la frustración de tener que trabajar innumerables horas, con un desgaste considerable en las relaciones con los que te rodean (dentro y fuera del trabajo) para obtener unos resultados inciertos (por decir algo), se lo pensarían más de una vez.

Esta falta de empatía con tus equipos de trabajo o ese exceso de ambición puede llevar a estas situaciones que, además, pueden terminar volviéndose en su contra porque si el proyecto va mal salpica a todos. Lo que pasa es que en demasiadas ocasiones los culpables no aparecen o ya están lo suficientemente lejos como para que les afecte.

Comenta Ed Yourdon que una señal muy clara de que un proyecto se ha convertido en un Death March Project lo tenemos cuando el responsable del mismo solicita un incremento de los recursos asignados, el cual se encuentra muy por encima de las estimaciones realizadas para la fase actual del desarrollo.

En el momento en que el responsable económico del proyecto o de la cuenta recibe la petición debe preguntar los motivos de la misma. No se debe rechazar sin recopilar antes toda la información necesaria, ya que existirán problemas y es el momento de tomar decisiones.

A veces un proyecto de desarrollo de software se convierte paulatinamente en un Death March Project sin que los responsables de la gestión económica del proyecto por parte del proveedor terminen por darse cuenta de que el mismo ha entrado en una dinámica de difícil salida.

El equipo de proyecto empieza a tener overtime, los plazos que parecían kilométricos ahora se asemejan a centímetros y la calidad de los trabajos empieza a resentirse.

Si el jefe de proyectos está muy apartado del proyecto, el responsable del equipo no le da la información necesaria o no le quiere advertir o es el mismo jefe de proyectos el que piensa que puede darle una vuelta a la situación sin avisar al responsable económico de la cuenta, provocará que la información tarde en llegar a quien tiene que tomar decisiones y tal vez cuando empiecen a aplicarse, las pérdidas del proyecto se verán difícilmente reducidas.

Es cierto como dice Yourdon que un Death March Project se huele en el aire, por lo que al final quien se tiene que enterar se entera, pero el problema no es ese, sino que se entere demasiado tarde como para que las medidas que adopte sirvan para algo.

Edward Nash Yourdon popularizó este término en su libro “Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects”.

¿Qué es un Death March Project? Según Yourdon todo aquel proyecto en donde algunas de las variables necesarias para el éxito del proyecto exceden un porcentaje importante la norma (el mismo Yourdon comenta que no hay una fórmula, ya que son muchos las factores que pueden intervenir en un proyecto de desarrollo de software, si bien considera que fluctuaciones de un 10% sobre las métricas normales que debería tener el proyecto no debería ocasionar un trastorno sensible en el mismo).

Algunas situaciones que pueden dar lugar a Death March Projects las tenemos por ejemplo con un proyecto que se intenta hacer en la mitad del tiempo necesario para desarrollarlo o con un presupuesto que es la mitad del necesario para llevarlo a cabo.

Lo peor de todo es que generalmente un valor inadecuado de estos parámetros tiende a arrastrar a otros por lo que el problema se multiplica.

A veces, una mala estimación del alcance del proyecto o unos cambios en las especificaciones pueden provocar esta situación, sin embargo, en la mayoría de las ocasiones donde existe un Death March Project, se sabe prácticamente desde que se está planificando que es imposible cumplir los objetivos.

Es más, de los casos anteriores, desde que se hace una oferta a un cliente se sabe que no se va a cumplir, dejando el problema a los que después se van a encargar del proyecto.