Desde hace bastante tiempo venimos tratando nuestros proyectos de diseño y desarrollo de software, con metodologías que cada día toman más valor entre las empresas que se dedican al I+D+i. Nos proponemos publicar una serie de post, que para aquellos que no conozcan estas metodologías, tengan la oportunidad de tomar un primer contacto. Unas reseñas, y algunoss manuales para comenzar a implementar en vuestros proyectos lean y scrum.
Si bien la citada edición se centra en la creación se empresas de base tecnológica, nosotros nos centramos de forma introductoria en el desarrollo de Software.
Metodología Ágil Vs. Tradicional
Construir software es muy diferente a construir edificaciones, o máquinas industriales.
En software, la experiencia nos dice que es muy difícil especificar los requisitos en una única y primera fase.
Por la complejidad de muchas de las reglas de negocio que automatizamos
cuando construimos software, es muy difícil saber qué software se
quiere hasta que se trabaja en su implementación y se ven las primeras
versiones o prototipos.
También es muy difícil documentar de una única vez,
a la primera, antes de la codificación,un diseño que especifique de
manera realista y sin variación todas las cuestiones a implementar en la
programación.
Las ingenierías clásicas o la arquitectura necesitan seguir este tipo de ciclos de vida en cascada o predictivos
porque precisan mucho de un diseño previo a la construcción, exhaustivo
e inamovible: disponer de los planos del arquitecto siempre antes de
empezar el edificio. Nadie se imagina que una vez realizados los
cimientos de un edificio se vuelva a rediseñar el plano y se cambie lo
ya construido.
Además, los planos para construir son precisos y pocas veces varían,
ya que la mayoría de los diseños de las ingenierías clásicas,
arquitecturas, etc., pueden hacer un mayor uso de las matemáticas o la
física. En software no es así. Y aunque se pretenda emular ese modo de fabricación, en software no funciona bien, y debemos tener muy claro que es casi imposible cerrar un diseño a la primera para pasarlo a programación sin tener que modificarlo posteriormente.
%2B20.46.08.png)
Por lo general, realizar un cambio en el producto final que construyen las ingenierías clásicas o la arquitectura es muy costoso.
Cambiar, por ejemplo, la posición de una columna en un edificio o
realizar modificaciones a la estructura de un puente ya construido tiene
un alto coste. Y de ahí que la arquitectura o las ingenierías clásicas
pretendan lograr a toda costa diseños o planos de un alto nivel de
detalle, para que una vez que comience la fase de construcción no tengan
que ser modificados. Además, normalmente, en la arquitectura o
en las ingenierías clásicas los costes de construir son muy elevados en
comparación con los de diseñar. El coste del equipo de diseñadores es sustancialmente inferior al de la realización de la obra, del puente, edificio, etc.
%2B20.53.48.png)
La anterior relación de costes no se comporta igual en el caso del software. Por un lado, el software, por su naturaleza (y si se construye mínimamente bien), es más fácil de modificar.
Cambiar líneas de código tiene menos impacto que cambiar los pilares de
un edificio ya construido. De ahí que existan numerosas propuestas que
recomiendan construir rápido una versión software y modificarla
evolutivamente (la técnica de la refactorización trabaja sobre esta
idea). En software no existe esa división tan clara entre los costes del diseño y los de la construcción.
También en las ingenierías clásicas o la arquitectura los roles y especialización necesaria en cada fase son diferentes. Los planos o diseños los realizan arquitectos que no suelen participar en la fase de construcción. La construcción tiene poco componente intelectual y mucho manual, al contrario que el diseño. Y todo apoya a que existan dos actividades claramente diferenciadas: el diseño y la construcción.
En nuestro caso, el producto final, el software, tiene diferencias muy sustanciales con estos productos físicos. Estas diferencias hacen que el proceso de construcción sea diferente.
Durante muchos años, quizás por la juventud de la ingeniería del
software, se han obviado estas diferencias, e incluso se han intentado
encontrar metodologías que imitasen y replicasen los procesos de
construcción tradicional al software. Ejemplo de ello son las primeras
versiones y usos de lenguajes de diseño como UML, o metodologías como RUP o Métrica.
Sin embargo en muchas ocasiones, estos intentos de emular la construcción de software a productos físicos han creado importantes problemas y algunos de los mayores errores a la hora de gestionar proyectos software.
Diferenciar
el cómo se construye software del cómo se construyen los productos
físicos es uno de los pilares de las metodologías ágiles (M.
Fowler, 2005). De hecho es un tema del que se ha escrito mucho .Y
también se ha debatido bastante, desde hace muchos años, con posturas a
favor y en contra.
Y es que en software,es frecuente
que diseño y construcción muchas veces se solapen, y por ello se
recomiende construir por iteraciones, por partes, y el uso de prototipos
incrementales.
Enlaces y lecturas recomendadas
%2B18.32.09.png)
%2B18.39.17.png)
%2B18.51.26.png)
%2B19.09.57.png)
%2B19.15.40.png)
%2B19.24.39.png)
%2B20.24.00.png)
%2B20.56.50.png)
%2B19.51.55.png)
%2B21.03.10.png)