Aunque a algunos les pueda sorprender, antes de Scrum… existieron otras metodologías de desarrollo. Sí. Aunque ahora casi nadie las recuerde. Pero esas metodologías que también tuvieron su momento, sus fans, groupies y época de esplendor, en la que muchos pensaron que a aquellas metodologías nunca les podría llegar… el declive.
Por aquello de que conocer el pasado es la manera de entender el presente, e intuir el futuro, en este post he querido hacer un homenaje y resumen a las 3 metodologías de gestión y desarrollo software que, en mi opinión, fueron las más importantes en los 80 y los 90: Métrica 3, OMT y RUP. La primera por su popularidad en España, las otras dos en el mundo.
Métrica versión 3.
Se definía como “metodología de planificación, desarrollo y mantenimiento de sistemas de información” y fue creada por el Ministerio de Administraciones Públicas (MAP) español.
Extensa y amplia colección de pdfs (recuerdo que me toco hacer un proyecto con Métrica 3 para…), basada en la ISO/IEC 12207 (te dejo un post donde se trata la 12207) y que aun se puede descargar libremente en la web del ministerio.
La versión 3 de Métrica fue, y es, la más famosa de las versiones. Y aún la usan muchas empresas, ya que en muchas subcontrataciones de la administración era, y es, un requisito obligado.
Aquella era una época en la que muchos países querían tener su propia metodología: Merise en Francia, SSADM en Reino Unido y Métrica en España.
Y también era la época de las “tocho” metodologías, es decir, que contenían cientos de páginas y requerimientos. Y métrica 3 no era la peor en este sentido. A mí por ejemplo me toco también sufrir otra del estilo, pero peor, menos popular, hoy casi desconocida, y de inmensidad planetaria llamada MARTE (Metodología Armónica de Telefónica).
Object-Modeling Technique (OMT).
Metodología desarrollada a principios de los noventa, en el 91 concretamente, y de la que muchos ingenieros en informática de nuestra generación nos toco examinar
nos en la Universidad.
Su padres fueron los en aquellos tiempos populares Rumbaugh, Blaha y Premerlani. Como su propio nombre indica, era una metodología pensada para el desarrollo orientado a objetos, y con los siguientes objetivos: Comunicación con los clientes, visualización y reducir la complejidad. Lo anterior, mmm, tiene un toque a ágil ¿no?
Fue una de las metodologías más populares en su tiempo, y que nació específicamente para el desarrollo OO. Y evolucionó sus metodologías predecesoras: las estructuradas.
Además, su importancia histórica viene de que es la metodología que inspiró del lenguaje UML…
La metodología Rational Unified Process (RUP) y el lenguaje (que no metodología) UML.
Hubo una vez una popular empresa llamada “Rational Machines”, que fundaron en el 81 Paul Levy and Mike Devlin para crear estrategias modernas que ayudasen en el desarrollo software, principalmente para modelar arquitecturas y desarrollo iterativo (sí, ya sé que todo desarrollo iterativo no es ágil, pero, mmm, lo tiene un toque ágil ¿no?).
El éxito de Rational llego a ser tal que tuvo hasta 4000 empleados y fue vendida en 2003 a IBM por 2.1 billiones de dólares. Su principal modelo
de negocio se basaba en vender herramientas, las llamadas CASE, que asistían a la hora de aplicar sus metodologías, como fue el caso de su popular Rational Rose. En aquel momento era la empresa donde todo fan de la ingeniería del software quería trabajar.
Aunque sin duda el gran éxito de Rational fue fichar a los que por aquellos tiempos eran los referentes del sector. En el 81, fichan al popular experto en OO Grady Booch. En el 95, fichan a James Rumbaugh (el de OMT) y, además, Rational compra la empresa Objectory AB, la empresa de Ivar Jacobson (el inventor de los casos de uso y de la metodología Objectory). Los tres anteriores (conocidos popularmente como los 3 amigos) liderarán durante años las metodologías de desarrollo software, y crearon el Unified Modeling Language (UML). Posteriormente crearon la metodología Rational Unified Process (RUP).
RUP se definía como un “iterative development, component-based architecture, modelling, continuous developer-driven testing, requirements management, and automated testing”.
Otras…
Por no alargar el post, me dejo otras muchas importantes metodologías, como el método de Booch, OOram, las tarjetas CRC de Kent Beck (sí Kent Beck, el de XP), el RDD de Rebecca Wirfs-Brock y Brian Wilkerson, Coad/Yourdon, Objectory, etc.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pingback: Bitacoras.com
Para opinar un poco respecto a las metodologías. Con respecto a RUP, si bien se creó a fines de los 90, ha sido muy usada en la década pasada y actualmente aún sigue siendo usada sobre todo para proyecto medianos y grandes. Scrum es más actual pero aún no tiene la popularidad ni el nivel de aplicación que tiene RUP. Por otra parte considero que RUP o el UP también puede ser considerado un proceso ágil, esto depende de cómo se aplique o use la metodología. Como bien lo manifiesta CRAIG LARMAN, la intensión del UP fue que sea un proceso ágil y no un proceso «pesado». Esto implica que puede usarse un pequeño número de actividades y artefactos, es adaptable y no predictivo, no hay un plan detallado para todo el proyecto sino un plan detallado por iteración. Por tanto, creo que es importante aplicar adecuadamente la metodología y adaptándola a las características del proyecto, y tener presente que la metodología que apliquemos debe siempre colaborar en todo el proceso de desarrollo e incluso se podría usar buenas prácticas o técnicas de distintas metodología con la intención de obtener un producto de calidad.
Saludos cordiales.
Respecto a Métrica 3, en mi opinión es la metodología más completa y más resistente que conozco. Si se combina con ciertas metodologías o prácticas ágiles y diseño O.O., pueden hacer una combinación insuperable.
Lo mejor de Métrica 3 es que cubre tanto la parte de toma de requerimientos, como la de diseño técnico y funcional, el desarrollo, los juegos de pruebas, etc, es decir, todo. Otras metodologías inciden sólo en un parte (en la gestión o en el desarrollo…), o son demasiado superficiales.
Métrica 3 es profunda en todas las etapas del ciclo de vida de los proyectos. Creo que la seguiré utilizando muchos años.
Hola,
Lo que le echo en falta es tratar explicitamente proyectos en los que se adecue más un ciclo de vida iterativo, y una «ruta» más ligera para proyectos pequeños.
Saludos Jor
Si, tienes razón para proyectos pequeños o mantenimientos no es muy aplicable.
Hola ¿podrías explicarme por favor como se utiliza Métrica 3?
<>
Yo casi lo llamaría «vocación profesional» 😉
Y te animo a poner un post con los topics de los fans y friquis de 2015-2020. ¿Machine learning, IoT, Cloud IaaS? ¿Blockchain? ¿Connected Vehicle? ¿Drones? ¿Pay-per-use services and subscriptions?
Nunca hubo tanta oportunidad, ni tan poca gente formada, ni tanto desprecio por la experiencia y la veteranía.
Gracias por tú aporte, me dio risa el comentario que Scrum no era tan popular en el 2012, Hoy día comenzando pleno 2021, es increíble lo fuerte que ha sonado Scrum y los avances que se han visto.