En los últimos años, el desarrollo de software ha incorporado nuevas metodologías y tecnologías. En Omatech hemos adoptado las nuevas técnicas y sistemas que contribuyen a mejorar la calidad del código y a desarrollar productos robustos, que faciliten la escalabilidad y el mantenimiento. Este esfuerzo de actualización constante lo hacemos con criterio, alejados de modas y a partir de la formación y mejora continuas. Así es como impulsamos una permanente búsqueda del equilibrio a la hora de emplear estrategias de desarrollo.

En este post del blog reflexionamos sobre este equilibro y sobre la forma de entender el desarrollo que tiene nuestra consultoría de proyectos digitales, desarrollo web y apps móviles

La mejor versión del desarrollo ágil

Con la implicación de todo nuestro equipo de desarrolladores, y con el apoyo, formación y mentorización de reconocidos expertos en métodos de desarrollo de software, hemos definido una filosofía de desarrollo equilibrada y, al mismo tiempo, audaz. Lo de ser audaces viene de una actitud innovadora, abierta a nuevas ideas y técnicas. Y lo de ser equilibrados viene de solo abrazar aquellos métodos que nos aportan valor cuando se trata de escribir código para los proyectos de nuestros clientes.

Los desarrolladores de Omatech aprovechan lo mejor que el agilismo tiene que ofrecer, al mismo tiempo que incorporan otras valiosas ideas, como la arquitectura hexagonal, los casos de uso y el Domain-Driven Design (DDD). Se trata, por tanto, de encontrar un punto intermedio y de equilibrio, que permite desarrollos eficientes y de calidad en base a un trabajo iterativo con sprints y en base, también, a una sólida toma de requisitos y a un análisis inicial.

Nadie pone en duda las grandes aportaciones del desarrollo Agile durante los últimos 20 años. La chispa del debate se enciende cuando nos hacemos la siguiente pregunta: «¿Qué conjunto de técnicas usamos realmente para ser ágiles de la mejor manera posible?». De ahí la importancia de ser reflexivos y analíticos, para implantar una versión del agilismo con la que desarrollar proyectos con una base muy sólida

Equilibrio en el desarrollo: sprints y análisis inicial

Las iteraciones son muy importantes. Pero también es crucial un trabajo de análisis, diseño y arquitectura previo al desarrollo.

Asimismo, el proceso de desarrollo debe entender los requisitos como un producto vivo y cambiante. A lo largo del proceso de desarrollo, sprint tras sprint, vamos revisitando y seguimos requisitando. Si hace falta, se reevalúan las decisiones de diseño sobre la base de los resultados que se van obteniendo. Pero lo que está claro es que siempre empezamos a escribir código a partir de un análisis inicial. Los proyectos más complejos exigen definir primero los requisitos y la arquitectura.

El riesgo de basar todo un proyecto solo en pruebas es que acabas teniendo una visión de túnel. El Test Driven Development (TDD) solo debería emplearse de forma muy puntual, y el refactoring no puede ser nunca un sustituto del diseño de la arquitectura del proyecto.

Hitos de Omatech en mejora continua en desarrollo

Hacemos un repaso de algunos de los hitos de la mejora continua de Omatech en métodos de desarrollo.

Omatech apuesta por la mejora continua en técnicas de desarrollo

Frameworks Agile: Scrum y Kanban

Con la llegada de Agile al mundo del software, adoptamos frameworks de gestión de proyectos como Scrum y Kanban. Asimismo, incorporamos las historias de usuario.

Arquitectura hexagonal

Siguiendo con nuestra filosofía de mejora continua, incorporamos la arquitectura hexagonal a nuestros proyectos. Lo hicimos de la mano del experto Carlos Buenosvinos. Con este método de desarrollo ganamos en flexibilidad y testabilidad, y conseguimos un código más limpio y mejor organizado. El resultado es un desarrollo más eficiente.

Arquitectura hexagonal en desarrollo de software

Domain Driven Design (DDD)

En muchas publicaciones, la arquitectura hexagonal se relacionaba con el Domain Driven Design (DDD). Se trata de un conjunto de principios y prácticas que ayudan a los desarrolladores a crear software a partir de una mejor interpretación de los términos del negocio del cliente. Con esta mejor comprensión del dominio, los desarrolladores mejoran la toma de requisitos y los procesos que tienen que seguir para escribir el código.

Según este método de desarrollo, el producto que se va a desarrollar debe hablar el lenguaje del cliente. En este enfoque de ingeniería de software es básico el concepto de lenguaje ubicuo, que es el lenguaje compartido por el equipo de desarrollo y por los expertos del dominio (los responsables del área de negocio que impulsa el proyecto digital).

Requisitos

Indagando más sobre el autor de la arquitectura hexagonal, Alistair Cockburn, observamos su defensa de los requisitos. Esta visión se apoyaba en casos de uso que permiten la trazabilidad y ortogonalidad del código. Hemos aprendido sobre las buenas prácticas con requisitos con Luis Fernández (UPM), uno de los grandes sabios de la ingeniería de software en España.

Casos de uso

Hemos adoptado la técnica de los análisis de casos de uso. «Se trata de un punto intermedio entre el Big Design Up Front (BDUF) y la ausencia de análisis y diseño previo. Además, nos permite un desarrollo directo, sin inundar todas las pruebas de dobles. De esta manera, por ahora, evitamos el eterno debate de TDD (Test-Driven Development), ¿sí o no?», explica Luis Fernández.

¿Qué es el caso de uso concebido por Alistair Cockburn? Es un concepto mucho más exhaustivo y metódico que la historia de usuario. Los casos de uso documentan de manera formal los diferentes tipos de conversación del usuario con el sistema. A menudo…

  • Incluyen descripciones detalladas y flujos de usuario.
  • Incorporan requisitos de sistema y funcionalidades bien definidas.
  • Contienen detalles técnicos para consumo del equipo de desarrolladores.

Los casos de uso son una documentación esencial para los desarrolladores, que así evitan tener que repasar miles de líneas de prueba para abordar un problema. Las historias de usuario, en cambio, son una guía más general, centrada en el quién, en la acción y en el resultado previsto.

React

La mejora continua no se detiene. Así, hemos incorporado el framework React, a través de una formación interna liderada por Christian Bohollo.

Portada de Agile! The Good, the Hype and the Ugly, libro que ayuda a aplicar las buenas técnicas del agilismo y a descartar las malas prácticas
Portada de Agile! The Good, the Hype and the Ugly, libro que ayuda a aplicar las buenas técnicas del agilismo y a descartar las malas prácticas.

Agile: aprovechar «lo bueno» y descartar «lo feo»

Luis Fernández recomienda con entusiasmo el título Agile! The Good, the Hype and the Ugly. El libro de Bertrand Meyer es tan práctico y certero como los pistoleros de los westerns de Sergio Leone en que se inspira el título. Nada de discursos filosóficos, complicadas teorías o frases motivacionales. El propósito es que desarrolladores, y también las personas clave en las empresas clientes, apliquen todas las buenas ideas que tiene el agilismo, y descarten todas sus malas prácticas.

Bertrand Meyer es un tótem, así que hay que hacerle caso. Este investigador en lenguajes de programación es el creador del principio Open/Close, que es la O de SOLID Design.

La mejor combinación de técnicas para crear código con valor

Para Omatech, el discurso de Bertrand Meyer es inspirador y estimula una forma de hacer desarrollo auténtica, lógica y con sentido. Como anima Meyer a hacer, estamos siempre en formación continua, buscando el equilibrio con la mejor combinación de todas las técnicas de desarrollo publicadas. El objetivo no es otro que lograr un código limpio y de calidad, que permita gestionar el ámbito, tiempo y coste del proyecto para dar soluciones eficaces y eficientes, es decir, efectivas. Lo importante es crear y dar valor.