archivo

Archivos diarios: junio 4, 2011

Soy de la opinión de que los equipos de proyecto deben estar conformados, siempre que se pueda (a veces la asignación actual de personal a proyectos o condicionamientos por parte del cliente impiden llevar a cabo lo que quiero expresar en este artículo) por personal cuyas habilidades y talentos se complementen, de manera que las debilidades de unos sean compensadas por las fortalezas de otros.

Lo que para un técnico puede ser un suplicio para otro resulta casi un juego y viceversa. Una buena designación de personal a proyectos es aquella en la que los integrantes puedan poner de manifiesto todo el potencial que sea posible.

Desgraciadamente, por regla general, los equipos de proyecto parecen más el resultado de un juego de datos que otra cosa.

Hasta ahora se habían analizado las bondades del desarrollo iterativo incremental desde el punto de vista de su adecuación a la naturaleza adaptativa del proceso de desarrollo de software. De esta forma se podían ir realizando los oportunos cambios del producto que se está desarrollando de manera que los usuarios puedan disponer cuanto antes de unas funcionalidades que se ajusten a sus necesidades, teniendo en cuenta que el producto software se va a ir obteniendo poco a poco y que aquellas funcionalidades menos prioritarias, aún siendo importantes, tendrán que esperar a que les llegue su turno, el cual dependerá de las tareas que se hayan declarado más prioritarias y de la cantidad de cambios sobre funcionalidades ya implementadas.

Otra ventaja que tiene el desarrollo iterativo incremental, siempre y cuando establezca una estrategia de entregas frecuentes (algo que comparten las metodologías ágiles) es que permite a los participantes en el proyecto: equipo de proyecto, usuarios, responsables técnicos del cliente, mantener la atención en el proyecto, lo que viene a denominarse enfoque.

Cuando en proyectos desarrollados con metodologías clásicas tenemos períodos de análisis de meses, se termina perdiendo en muchas ocasiones la orientación en el proyecto, sobre todo por parte de aquellas personas que no tienen una dedicación mayoritaria al mismo. Esta pérdida de enfoque se traduce al final en tiempo perdido y prisas, muchas prisas, por intentar hacer en menos tiempo lo que se debería haber realizado de una manera más continua.

El área usuaria no soporta bien proyectos con largos períodos de análisis, diseño y construcción sin ver resultados. Pierden la conciencia del trabajo que está realizando el área técnica, por eso junto a la naturaleza evolutiva del proceso de desarrollo y de requisitos que realmente han cambiado respecto a su definición inicial, existe una importante tasa de cambios en las especificaciones.

Todavía resulta peor el hecho de que los usuarios pierdan el interés en el proyecto, ahí si que entrará en un riesgo importante el sistema de información. Tal vez el proyecto siga hacia adelante y se entregue un producto que se pase a producción, pero será un extraño para los usuarios que salvo que se vean obligados por sus superiores no lo utilizarán. Si al final lo terminan usando comenzará el verdadero proceso iterativo e incremental, pero con las urgencias y problemas que tiene retocar un producto en producción que más que probablemente se aleja de lo que esperaban los usuarios.