Mostrando entradas con la etiqueta scrum. Mostrar todas las entradas
Mostrando entradas con la etiqueta scrum. Mostrar todas las entradas

martes, 3 de febrero de 2015

Agilidad y Lean: Gestionar proyectos y negocios del siglo XXI

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.


Figura 1. Libro de referencia  "Startup".



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.


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.


Figura 3. Enlace a la noticia.


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.


Figura 4. Enlace a la noticia.
 

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. 

Figura 5. Manual de referencia Blog de Javier Garzas.


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.


 Figura 6. Diagrama de Gantt.

Enlaces y lecturas recomendadas