Generalmente cuando vamos a construir software decimos que vamos a seguir un ciclo de vida, al cual denominamos ciclo de vida del desarrollo, esto es bueno la mayoría de las veces pero si realmente nos interesa el proyecto que vamos a hacer o el cliente al que se lo vamos a vender, es interesante pensar en dos ciclos de vida previos al del desarrollo.
El primero es el ciclo de vida del producto que vamos a hacer y aquí empezamos ya mal, puesto que esto tiene que ver con el negocio y los informáticos, no tocamos esos temas.
El producto nace de una demanda o una necesidad de mercado, que la empresa evalúa, planifica, desarrolla, explota y finalmente aparta del mercado para que sea sustituido por otro nuevo. Cuando alguna de esas etapas puede ser mecanizada, es cuando empezamos a pensar en la informática.
Esta mecanización puede ser directamente en una sola aplicación o en un conjunto de aplicaciones que denominaremos programa. En ese momento planificaremos las diferentes aplicaciones que vamos a desarrollar posteriormente y para ello usaremos un ciclo de vida de la planificación que empezara con una estimación, planificación seguimiento y control para terminar con el cierre del proyecto.
Y que tareas planificaremos pues aquellas que componen el ciclo de vida del desarrollo. Estos matices son importantes porque mucha gente confunde los ciclos de vida con las metodologías o procesos. De ahí la importancia que tiene en dar un toque de Ingeniería de software a los proyectos que desarrollamos o a los productos software que construimos, esa ingeniera es la que puede dotar de visión al grupo de personas que van a trabajar en el proyecto.
Históricamente hemos venido trabajando de una manera en la que primero pensamos que queremos obtener y describimos cuidadosamente el producto final; se empieza a usar el Project para “pintar” las tareas que hemos estimado generalmente usando el método que mi amigo José Villalba comentaba siempre “el CDO”, es decir “cinco dedos oscilantes”, y a partir de aquí el equipo empieza a trabajar.
Se supone que vamos haciendo las cosas secuencialmente, el de los requisitos hace el funcional que pasa a los diseñadores que se lo pasan a los programadores que dejaran al final que los tester prueben y prueben hasta que no quede nada que probar.
Este ciclo de vida se llama en cascada, y se suele representar con una “v”, es impresionante recorrer empresas y ver como se matan o nos matamos por hacer dibujos complicadísimos para que no se parezcan entre si y asi podamos decir que somos innovadores.
Este enfoque tiene una ventaja muy grande, su lógica es aplastante, piensas antes de todo, escribes, sigues un plan, lo mantienes lo más organizado posible, vigilas que no se te vayan los costes y mantienes el tipo en las reuniones con el cliente. Sólo tiene un inconveniente, y es que participan personas.
Pero atención porque lo digo; este modelo implica por ejemplo que las buenas ideas solo se pueden ocurrir al principio del proyecto, porque como a uno se le ocurra una nueva idea cuando ha empezado el diseño, la monta. Por lo que en este modelo una buena idea pero tardía pasa de ser una mejora a ser un problema.
Otro tema es que este modelo hace énfasis fuerte en la documentación, todo lo que tengo en la cabeza lo tengo que escribir, si cambia diez veces lo escribo diez veces, además asi tenemos la evidencia de que hemos hecho nuestro trabajo,¡ no que lo hemos hecho bien! Sino que lo hemos hecho, y curiosamente hacemos documentos para que nadie los lea ya que están muy ocupados trabajando, y claro cuando los lee empiezan los malentendidos.
Escribir un documento es muy complicado, ya que un documento no es ni más ni menos que un dibujo incompleto de mis ideas que cuando tú lo lees creas otra abstracción que es diferente de la primera, por eso no es sorprendente que haya graves problemas de entendimiento.
Por lo tanto deberemos trabajar bastante la comunicación entre las personas conjuntamente con la gestión de expectativas que se generan dentro de cada uno de nosotros.
Algunos ya directamente estaréis pensando en que lo que hay que hacer es usar métodos agiles y dejarnos de monsergas, bueno pues cuidado una cosa es como gestionamos el proyecto y otra es nuestro comportamiento, independientemente de métodos secuenciales o agiles siempre detrás estamos las personas.
Y tampoco es bueno confundir el agile con el “atajing”, es decir con la excusa de ser más ágil lo que hago es coger atajos y quito lo que creo que no es importante o lo que me lleva más tiempo hacer.
Lo dejo aquí para la segunda parte, pero ojo a los “ñaperos” que están siempre al acecho de implantar sus ñapas en las aplicaciones, estaremos atentos.
Regla nº8:” Antes de hacer algo es interesante saber que se quiero hacer y cómo se va a hacer. La improvisación no es buena compañera de viaje”.