archivo

Archivo de la etiqueta: metodologías clásicas

El enfoque de planifico todo el proyecto, realizo todo el análisis y después diseño, construyo e implanto está todavía presente en una gran cantidad de personas de nuestra industria.

Muchos desarrolladores recién llegados ven el proceso de desarrollo con ese enfoque, sin embargo el problema no son ellos, tienen todavía mucho tiempo para cambiar, sino personas que se dedican a esto desde hace mucho tiempo y que, como suele pasar en las organizaciones, con el paso de los años han alcanzado responsabilidades directivas.

Quien se ha criado en metodologías clásicas, quien ha trabajado durante muchos años con ellas le resulta muy complicado cambiar sobre todo si se está alejado ya del día a día de los proyectos de desarrollo de software. Con el paso del tiempo todo se idealiza, algo que además si no tiene mucho espíritu crítico te puede llevar a pensar que realmente no fueron tan mal todos esos proyectos en los que trabajaste y que utilizaron enfoques clásicos.

Por otro lado, en el área usuaria o funcional, el enfoque de los proyectos en los que trabajan que serán en su mayoría no software también será, por regla general, de tipo totalista, es decir, contrato un trabajo, lo ejecutas de una vez y adiós.

La aplicación de enfoques ágiles se encuentra con esta resistencia, personas que no terminan de entender por qué aplicas esa estrategia, personas que se sienten más cómodas trabajando sobre una planificación general, independientemente de que la misma nunca se cumpla o que el producto final se parezca bien poco a las expectativas que se tenían sobre el mismo.

Para que proyectos con este enfoque puedan llevarse a cabo es fundamental que todas las partes implicadas en él entiendan, comprendan y compartan que esta forma de entender el desarrollo de software es la que mejor se adapta a su incertidumbre inherente y por tanto, es la que de forma más probable te llevará al cumplimiento de los objetivos.

En general, apliques la metodología que apliques es fundamental que todas las partes remen en la misma dirección, de lo contrario a las resistencias que te vas a encontrar en el propio proceso de desarrollo tendrás que sumarle que estaréis solos tu equipo y tú para poder vencerlas y que las otras partes, por regla general, lo que harán será sumar más resistencia.

Kent Beck, describe todo esto de la siguiente manera: “El software es inherentemente poco fiable y los clientes están condicionados a aceptarlo. Los desarrolladores están condicionados a aceptarlo. Los testers están condicionados a aceptarlo”.

Hasta que el usuario no interacciona con el producto software no comprueba si sus expectativas están satisfechas.

Las expectativas van más allá de una visión funcional del software ya que es absolutamente fundamental que el usuario tenga una buena experiencia de uso. Tal vez usuarios con una gran capacidad de abstracción y que hayan dedicado mucho tiempo al proyecto puedan atisbar antes de interactuar con el producto si funcionalmente les satisface, pero la experiencia de uso no se tiene hasta que se utiliza.

Por ese motivo las metodologías clásicas no terminan de producir buenos resultados, ya que entienden que es posible acertar con todo desde el análisis y que si no, ya vendrá el mantenimiento. El problema que suele producirse en estos casos es que el presupuesto de mantenimiento no existe o de existir suele ser inferior a la envergadura de los cambios que van a ser necesarios.

El feedback del usuario es fundamental desde las etapas más tempranas posibles del desarrollo, de ahí la necesidad de ir construyendo y liberando el producto de manera progresiva.

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

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.