¿Cuándo podemos decir de un desarrollo Software que hemos finalizado una versión?
En mi modesta opinión, uno de los aspectos más complicados en el desarrollo del Software, es saber decir no a las cosas que a veces se nos piden abordar, y por supuesto, que la otra parte entienda si es un no relativo, un no taxativo o un no absoluto. Normalmente siempre que hay un no por medio, tendemos a hacerlo absoluto, y con ello creamos una tensión poco recomendable. Siempre que hay un sí, todo va bien, pero cuando un no, hay que estudiar antes de nada porqué se ha producido.
Pero las decisiones de qué hacer o qué no hacer, afectan directamente en la consecución del proyecto y en muchísimas ocasiones, en los plazos establecidos. Scrum me gusta precisamente porque dentro de un Sprint, traza los plazos (plazos cortos) y las tareas (realistas y abordables).
La consecución de tareas realistas y en los plazos establecidos, debe generar algo,… algo que se pueda ver, tocar, y casi oler y saborear. No importa si de momento presenta poca funcionalidad, por otra parte será lo normal al principio, al contrario de esto, lo que realmente importa es que vayamos comprobando todos, que las cosas se están haciendo como se quieren hacer y de la forma y modo en la que se quieren hacer (hablo de todos, desarrolladores, jefe de proyectos, cliente, usuarios, etc). De ahí que Scrum por otra parte, parta de la tesis que a cada Sprint finalizado, se revise para comprobar no sólo dónde nos podemos colgar las medallas o dar una palmadita de complacencia en la espalda del compañero, sino dónde debemos apretar más, dónde debemos prestar más atención o cuidado, o dónde hemos cometido determinados errores o meteduras de pata con el fin de que no volvamos a caer o tropezar con la misma piedra. Nadie ha nacido aprendido… es algo que repito siempre una y otra vez… y desde luego, el que se equivoca es porque ha hecho algo… tened por seguro que el que no se equivoca jamás de los jamases es el que nunca hace nada.
Pero en todo esto, el resultado último de todas estas consecuciones resumidas de forma drástica, es un resultado… y en el desarrollo del Software, el resultado suele ser una versión Software… pero… ¿cuándo podemos decir realmente que hemos finalizado una versión Software?.
Hago esta pregunta en alto, sin tampoco responderla como si fuera un teorema matemático porque en sí, un desarrollo Software jamás finaliza. Sin embargo, sí hay un momento en el que ondeamos o debemos ondear la bandera a cuadros como si hubiera finalizado la carrera, y es que en mi opinión, es necesario marcar desde el principio cuales son los objetivos, plazos y las funcionalidades a cubrir. Es obvio ¿verdad?.
Me voy a centrar en Scrum para comentar algunas cosas más, porque creo que una metodología que está cogiendo bastante protagonismo en los últimos tiempos.
Scrum es ágil, flexible, adaptable a las necesidades y cambios que van surgiendo, y es válido para muchos proyectos y empresas. Ok, vale. Pero hay un peligro que se corre a veces cuando la gente habla y trabaja a la ligera con Scrum, quizás por no saber marcar las pautas o líneas de demarcación claramente o quizás por otras cuestiones, pero el hecho es que la gente puede confundir a veces la agilidad, flexibilidad y otros aspectos con que alguien pueda pedir y pedir cosas sin parar y nosotros como estamos ante una metodología ágil, no sepamos decir no a las cosas o simplemente pensemos que es una pequeña cosa que podemos abordar. Debemos recordar, que muchas cosas pequeñas forman una cosa grande. Vale, sí, es obvio, pero por si alguno no se da cuenta, lo digo.
La solución a esto es clara. El cronograma, se marca con la idea de cumplirlo, pero si se agregan tareas o acciones, el cronograma quedará afectado como es lógico. Debemos evitar a toda costa, que el cronograma sea infinito.
Aún y así, es necesario siempre, decir dónde vamos a trazar una línea de tiza en el suelo para marcar la versión de Software como versión finalizada.
Las funcionalidades de mejora y añadidos con respecto a la aplicación y que se salgan bastante del cronograma prefijado inicialmente, se deberían abordar en una segunda versión. Pero es necesario siempre, marcar la finalización de una versión para a partir de ella iniciar si se quiere un nuevo proceso de desarrollo.
Curiosamente, esta forma de trabajar en la que se da banderazo de llegada a una versión (versión 1) y se arranca un nuevo proyecto (versión 2) para agregar esas funcionalidades demandadas o detectadas, es la que se sigue en muchísimos proyectos y empresas, como por ejemplo Microsoft (para muestra un botón, los .NET Framework). Seguramente mucha gente al leer todo esto piense en que es lógico muchas de las cosas que comento, pero no porque algunos piensen que es lógico, debemos pensar en que la mayoría de la gente lo entiende así.
Para mí, aún sabiendo estos aspectos que comento, una de las cosas que veo más complicadas en el desarrollo del Software es saber marcar adecuadamente con la tiza, la línea que separa una versión finalizada del proyecto con la parte en la que se inicia una nueva versión de la aplicación.
Si alguien conoce algún teorema matemático que resuelva la ecuación, que lo comente por favor.
2 Responsesso far
Saludos Jorge…
Muy interesante tu articulo, realmente. Cuando llevamos un tiempo en esta profesión comenzamos a desarrollar software, pensamos que sabemos todo – mañas y artificios – y entregamos proyectos a nuestros clientes y continuamos dando mantenimiento a estas aplicaciones después de cierto tiempo, colocando parches y demás parches. Y un día llega nuestro cliente y nos dice «yo quiero mostrar un pequeño presupuesto por Internet» y nosotros decimos «bueno eso hay que ver como lo resolvemos, creo que se puede hacer algo», mentiras… mentiras… puras mentiras sabemos que hay cosas que no se deben hacer y aplicaciones que no fueron concebidas para eso. Pero nosotros somos súper desarrolladores y nos retamos nosotros mismo. Pienso que si le decimos NO a nuestro cliente justificando el porque no se pude hacer o no se debería hacer dentro del proyecto actual, nuestro cliente comprenderá.
Scrum nos puede ayudar mucho a planificar y seguir un inicio y fin del proyecto. Mas cuando se trabaja en equipo… no soy un arquitecto, soy un simple albañil que pega bloques (con mi herramienta vs2005) con buenas prácticas probadas anteriormente.
Saludos…
¡Excelente Perucho!
En mi opinión, para mí todos somos ladrilleros. Desde el arquitecto hasta el becario que entró hace dos días. TODOS somos iguales de importantes. La diferencia está en el rol que desempeña cada uno. Esa es la única gran diferencia. Luego podemos hablar de otras diferencias como por ejemplo los conocimientos, la experiencia y así unas cuantas más, pero en la cadena de «montaje», todo el mundo es indispensable,… prescindible sí, pero indispensable.
En esa línea de montaje está el cliente, y tú has enfocado muy bien algunas de las cosas que quería comentar aquí. Lo difícil que resulta decir NO. Y desgraciadamente en nuestra profesión, es difícil encontrar a personas que saben decir NO.
Muchas gracias por tu comentario. Lo he saboreado muchísimo y me ha encantado. Gracias.