STAR UP: UN MODELO DE NEGOCIO DE BASE TECNOLOGICA

http://blog.leanmonitor.com/es/product-market-fit-canvas-la-herramienta-de-innovacion-tecnologica/

https://www.youtube.com/watch?v=7pWqn9W8Doo

CICLO DE VIDA DEL PRODUCTO

Frente a la predicción… adaptación, o el ciclo de vida iterativo e incremental

Es curioso ver como el concepto “ciclo de vida”, una de las piezas más fundamentales, y transcendentales, de la gestión de un proyecto software produce tanta confusión.

En parte, tampoco es de extrañar, debido a que no existe una única terminología al respecto, existen muchas definiciones, conceptos confusos, etc. Por eso vamos a aclarar los principales tipos de ciclos de vida que hay:

Cascada

Las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan (en teoría) de manera lineal, una única vez, y el inicio de una fase no comienza hasta que termina la fase anterior.

Su naturaleza es lineal, típica de la construcción de productos físicos y su principal problema viene de que no deja claro cómo responder cuándo el resultado de una fase no es el esperado.

El ciclo de vida más criticado en los últimos años. En muchos proyectos su implantación ha sido un fracaso, mientras que hay otros proyectos que trabajan perfectamente de esta manera.

El ciclo de vida incremental

Cada iteración (una iteración es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que veremos luego, siendo este punto confuso, por las definiciones) contiene las fases del cascada estándar, pero cada iteración trabaja sobre un sub conjunto de funcionalidad. La entrega total del proyecto se divide en subsistemas priorizados.

Desarrollar por partes el producto software, para después integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregación de módulos en diferentes fases. El agregar cada vez más funcionalidad al sistema.

El ciclo de vida iterativo

En cada ciclo, iteración, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones, en el que cada ciclo mejora más la calidad del producto.

Es importante señalar que este ciclo no implica añadir funcionalidades en el producto, pero si la revisión y la mejora.

Iterativo e incremental

Incremental = añadir, iterativo = retrabajo

Se va liberando partes del producto (prototipos) periódicamente, en cada iteración, y cada nueva versión, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. Aquí hay un post con más información.

Además, el ciclo de vida iterativo e incremental es una de las bases de un proyecto ágil, más concretamente, coniteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente más de dos

Ágil vs. Tradicional

Construir software no es como construir coches o casas

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 [1].

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.

https://www.slideshare.net/JavierGarzas/evolucin-fabricacin-software

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.

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 [2] o Métrica v3 [3].

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) [4]. 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.

La predictibilidad, ciclo de vida en cascada o desarrollo tradicional

En su nacimiento, la gestión de proyectos software intentó imitar la gestión de proyectos de otras disciplinas, como la arquitectura, la industria o la ingeniería civil, hasta el punto de heredar y adaptar al mundo del software muchos de sus roles (p.e. arquitectos software) y tipos de organizaciones (p.e. fábricas de software).

Hoy en día una de las prácticas más discutidas y polémicas de las que se han querido heredar desde otras disciplinas es la llamada predictibilidad, también conocida como gestión de proyectos dirigida por la planificación, desarrollo tradicional o incluso también conocida como desarrollo pesado.

La predictibilidad se basa en dividir un proyecto en fases, por ejemplo, de manera simplificada, “requisitos”, “diseño” y “construcción”, y que cada una de estas fases no comience hasta que termine con éxito la anterior.

https://www.slideshare.net/JavierGarzas/agilidad-back-to-the-futurepptx

Se le llama predictibilidad porque cada fase intenta predecir lo que pasará en la siguiente; por ejemplo, la fase de diseño intenta predecir qué pasará en la programación, y esos diseños intentarán ser muy precisos y detallados, para ser cumplidos sin variación por los programadores.

Además, en este tipo de gestión, cada una de estas fases se realiza una única vez (no hay dos fases de requisitos). Y las fases están claramente diferenciadas (en teoría, está claro cuándo termina el diseño y comienza la programación), hasta el punto de tener profesionales claramente diferenciados y especializados en cada una de ellas: “analistas de requisitos”, “arquitectos de diseño software”, programadores, personas para pruebas, etc.

Normalmente cada fase concluye con un entregable documental que sirve de entrada a la siguiente fase, la “especificación de requisitos software” es la entrada al diseño, el “documento de diseño” la entrada a la construcción, etc.

La gestión de proyectos predictiva es típica en disciplinas como la arquitectura. Y desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas. Tener una fase de diseño muy claramente separada de la programación (hasta el punto de intentar tener una organización cliente que detalle los diseños y otra organización, normalmente llamada fábrica de software, que los implemente). Que la programación no comenzase hasta que terminase el diseño. Que el diseño concluya con unos planos precisos que guíen totalmente la construcción. Que una vez que se hace un diseño éste no se modifique; de hecho, notaciones como UML (Unified Modeling Language es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema) se concibieron para construir los “planos detallados” del software.

Al anterior tipo de gestión de proyectos predictiva, en el mundo del software se le conoce como ciclo de vida en cascada (ver Figura 1).

Figura 1. Ejemplo de ciclo de vida predictivo o en cascada