SCRUM

6. feb., 2020

Queridos lectores y seguidores de nuestro sitio web y de nuestras redes sociales.

Queremos invitarlos a formar parte del siguiente Challenge o Reto creado desde nuestras redes sociales Twitter @PMPMedellin e Instagram @PMPMedellin. Donde estamos convocando para que nos compartan uno o varios mitos de scrum diferentes a los que ya hemos publicado o que en su defecto nos hagan comentarios sobre los mitos publicados por nosotros. Ánimo  y recuerda colocar el Hashtag  #RetoMitosScrum

3. feb., 2020

Para los que no han escuchado el término "DevOps", éste fue utilizado por primera vez en el año 2008 por el autor Patrick Debois, durante un evento de agilismo celebrado en Bélgica. Tiempo después el término ha venido ganando terreno y comenzó a sonar fuerte durante los "DevOpsDays".

Desde su nacimiento, "DevOps" ha estado ligado al uso de metodologías ágiles, y es claro que no son pocas las personas que incluso llegan a confundir las prácticas de Devops con las metodologías ágiles.

Dentro de las prácticas DevOps tenemos entre otras las siguientes:

1) La integración continua: Es una técnica de desarrollo software que consiste en combinar los cambios de código periódicamente en un repositorio central. En ella se construye el código y se le hace testing de forma frecuente mediante pruebas estáticas (análisis de código) automatizadas, con el objetivo de adelantar la corrección de errores y su identificación temprana.

2) La entrega continua : Es una técnica de desarrollo software que permite que los cambios del código se trasladen a un entorno donde se realizan pruebas funcionales y automatizadas, consintiendo la liberación de versiones automáticas a producción una vez validadas.


3) El despliegue continuo: Se diferencia del anterior en que el paso a producción de los cambios del código se realiza de forma automática.

Pero, entonces ¿Qué es "DevOps" ? Podríamos decir que es un modelo cultural y organizacional que promueve la colaboración para permitir una IT de alto rendimiento que permita alcanzar los objetivos de negocio.

 

En otras palabras es un movimiento cultural que facilita la obtención de los mejores resultados en la implementación y operación de las aplicaciones a través de la mejora de las interacciones humanas (esto es : equipos de desarrollo, calidad y operaciones).

Puede afirmarse que el cambio cultural es el mayor factor de éxito del modelo de DevOps, aunque su marco de desarrollo se apoya en cinco valores enmarcados dentro del Modelo conocido bajo el acrónimo CALMS.

"Modelo CALMS"

C - Cultura: 

La cultura organizacional se basa en las características de las personas y la forma en la que se comunican y relacionan entre sí. Aquí factores como la transparencia, confianza, responsabilidad compartida, las creencias, capacidad de aprendizaje, gestión del cambio, la mejora continua y la experimentación son la base del éxito de los equipos DevOps.

A-Automatización:

Tener procesos repetibles y estandarizados permiten la utilización de la automatización y facilitan la fiabilidad de los sistemas.

Los equipos que comienzan con la automatización lo hacen en cuatro puntos: la construcción automatizada mediante el uso de técnicas como la integración continua; la realización de las pruebas automatizadas; el despliegue automatizado y el aprovisionamiento automatizado de los sistemas. El aprovisionamiento automatizado de los sistemas permite que mediante su estandarización evitemos situaciones tan típicas en el mundo del desarrollo de Software como “En mi entorno me funciona”.

 

DevOps propone la aplicación de herramientas que automaticen gran parte de los procesos existentes a lo largo del ciclo de vida como son:

 

  • Automatización de las revisiones de código.
  • Automatización de la construcción y del despliegue.
  • Automatización de los controles de calidad.
  • Automatización del provisionamiento de infraestructuras.

 

L-Lean:

Lean es una filosofía que empuja a los individuos que lo utilizan a pensar cómo hacer los servicios o productos mejor en su día a día. Focalizado en la mejora continua, en la reducción o eliminación de todo aquello que genere pérdida (las 3 Mu: Muda, Muri y Mura) en el proceso extremo a extremo (E2E- End to End) buscando aportar el mayor valor al cliente. Lean usa el Value Stream Map como herramienta de optimización del proceso extremo a extremo.

 

En el desarrollo de software Lean los autores "Tom y Mary Poppendieck" identificaron como desperdicios para el desarrollo de software los siguientes:

 

  • Código o funcionalidad innecesaria en las aplicaciones.
  • Sobrepasar la capacidad del equipo, o empezar más de lo que puede terminarse.
  • Retrasos en el proceso de desarrollo de software.
  • Requisitos poco claros o con cambios constantes.
  • Burocracia.
  • Comunicación lenta o inefectiva
  • Trabajo parcialmente terminado
  • Defectos o problemas de calidad
  • Cambio de tareas

 

M-Medición:

La utilización de indicadores es un indispensable para mejorar de forma continua un servicio o un producto. En una implementación DevOps deberían existir indicadores para medir todo: procesos, personas y herramientas.

Para ello se tienen en cuenta las siguientes métricas:

  • Proceso como MTTR, tiempo de despliegue, número de test ejecutados(fallidos y correctos).
  • Rendimiento como número de builds o número de puestas en producción.
  • Innovación como ideas exitosas puestas en marcha, experimentación.
  • Cultura como satisfacción, avisos.

S-Sharing (Colaboración):

La existencia de silos en las organizaciones y empresas, de diferentes formas de pensar, de uso de distintas herramientas o entornos, de procesos no integrados y, en general, de objetivos y expectativas no alineadas en la organización hacen que DevOps ofrezca una solución holística y que dé respuesta al nuevo paradigma que propone la transformación digital. La colaboración y responsabilidad extremo a extremo en DevOps consigue que la creación de equipos por desarrollo de proyecto o producto sea un factor clave frente a la formación de equipos por funciones (desarrollo, calidad y operaciones). Dichos equipos cuentan con autonomía, son autogestionados y autoorganizados, tienen habilidad para experimentar e innovar rápido y teniendo como foco principal el aportar valor al cliente.

 

Finalmente, podríamos decir que "DevOps" está sustentado en una cultura de colaboración y responsabilidad transversal. En un cambio de actitud donde el trabajo es trabajo de todos, con Devops se busca innovar y mejorar de forma continua, teniendo como foco el cliente final y el mejoramiento de su experiencia. Es por ello que lo único que nos queda es preguntarnos si nuestra organización esta preparada para dar este salto y si nosotros como personas y profesionales estamos dispuestos a aceptar el cambio y subirnos en este nuevo barco que de seguro nos llevará a buen puerto.

Autor: Ing. Javier Mauricio León Reyes

@Twitter e Instagram: @PMPMedellin

Fuentes Consultadas:

https://www.mtp.es/entendiendo-devops/

http://revistas.usbbog.edu.co/index.php/GuillermoOckham/article/download/4270/3540/

https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es-devops/

https://devopsti.wordpress.com/2014/08/25/clams-o-como-devops-logra-integrar-los-objetivos-de-desarrollo-y-operaciones/

23. oct., 2019

"La agilidad empresarial es la capacidad de una organización de adaptarse rápidamente a los cambios del mercado de manera tanto interna como externa".

En este proceso de adaptación surgen algunas situaciones que se vuelven obstáculos o barreras para que las compañías logren transformarse y meterse en el tren del cambio que está exigiendo el mundo de los negocios en la actualidad.

En este artículo vamos a mencionar algunos de estos obstáculos que tienen que superar las organizaciones en este camino:

1. El factor cultural es el principal obstáculo de la transformación digital y del ingreso de las organizaciones al mundo de la agilidad empresarial. Cerca de un 62% de las empresas corroborá esta idea según la firma Capgemini en un estudio realizado recientemente. Por otra parte Capgemini en el mismo estudio identifica que existe en muchas organizaciones una completa falta de sinfonía entre la alta dirección y los empleados en todas las áreas que comporta la cultura digital. Por ello en lo primero que se debe trabajar es en los aspectos de cultura y muchas veces estos son ignorados y/o no se les da la suficiente importancia.

Bill Gates afirma que “Para tener éxito hoy en día es necesario querer y ser capaz de reconsiderar, revitalizar, reaccionar y reinventar constantemente”. Esto solo es posible si se cuenta con una cultura orientada al cambio y que este centrada en las necesidades de los clientes.  

Otro de los inconvenientes que se encuentra en este punto, es que en muchos casos las empresas no consiguen que sus empleados participen en el viaje hacia el cambio de cultura corporativa. Implicar a los empleados es fundamental para inculcar una actitud digital efectiva y acelerar la transformación cultural de la organización. La alta dirección y los mandos intermedios son esenciales para traducir la visión digital en resultados tangibles y para incentivar las conductas digitales positivas. El experto Ian Rogers- Chief Digital Officer de LVMH, así lo explica: “El gran momento de una organización ocurre al aceptar que la transformación digital no es una cuestión meramente técnica, sino un cambio cultural”.

2. "Tomar Agile como moda". En definitiva como lo mencionabamos anteriormente no es una moda , sino en realidad constituye una necesidad porque el mundo esta dando giros vertiginosos y cada día con mayor rapidez. Estos cambios hacen que las organizaciones evolucionen y tengan que efectuar procesos de adaptación como resultado de las necesidades de sus clientes - Si quieres ver ejemplos de lo que pasa cuando no haces caso de estos cambios puedes ver empresas como Kodak, Blockbuster y recientemente Wework y Forever21 en algunos países de américa latina.

3.  La falta o disminución de presupuesto- esto está relacionado con la importancia que se le da al proceso de transformación por parte de los altos ejecutivos y por ello los equipos finalmente terminan también desmotivados cuando su presupuesto se ve afectado.

4. Tecnología muy antigua u obsoleta en planta. En realidad esto es un reto, porque al contar con equipos viejos y arquitecturas monolíticas que impiden el desacoplamiento hace más dificil el proceso de cambio. En estos casos es necesario revisar la posibilidad de efectuar un proceso de renovación tecnológica.

5. Incapacidad para determinar un retorno de inversión a partir de la transformación digital. Este punto es un caso de miopia empresarial que debe ser resuelto de manera pronta, porque todos los cambios se generan para dar solución a nuevos problemas y necesidades y los clientes obviamente si no ven resueltas las mismas optarán por productos y servicios de la competencia.

6. Falta de capacidades, habilidades y experiencia en el equipo. Este reto se le asigna a los agile coach y a los Scrum Másters dado que ellos deben facilitar que sus equipos aprendan y participar de la mano del product owner en la selección del personal idóneo para los proyectos a realizar.

7. Falta de visión y compromiso a nivel ejecutivo. Este punto está relacionado con el primer punto y es uno de los más díficiles de sortear por parte de los equipos, porque sin liderazgo los resultados que se pueden obtener no son muchos dado que de allí se derivan las reducciones de prespuesto, cambios de prioridad frecuentes, entre otros obstáculos.

8.Gestión ingenua de recursos:

En este punto, queremos decir que muchas veces se cree que agregar personas a un equipo hará que se aumente el progreso. Esto se veía mucho en la Gerencia de Proyectos Tradicional donde se decía que si una mujer daba a luz un niño en 9 meses, si colocabamos 9 mujeres embarazadas en un mes tendríamos el bebé. Y como esta paradoja se presenta - así ocurre lo mismo en los proyectos Scrum- Esto no es posible. 

El proceso con la asignación de personas no siempre tiene una relación directa, ya que depende de los niveles de capacitación y conocimiento del negocio de las personas que estas añadiendo a tu equipo. En ocasiones traer más personas puede por el contrario restar valor. Lo que se recomienda es agregar equipos y personas a tu proyecto si eres consciente de los recursos intangibles y su conocimiento, para que no frenes el progreso sino que lo impulses y se facilite el derrame de conocimiento al interior de los equipos.

9. Equipos organizados por componentes: Cuando los equipos se organizan por una sola función reducen la capacidad de la empresa para volver a priorizar sus capacidades, aumentan los cuellos de botella de coordinación e introducen riesgos de integración.

El enfoque del equipo de componentes sería eficiente si el desarrollo de nuevos productos fuera tan predecible como la fabricación. En la práctica, lo que ocurre en realidad es que las prioridades cambian y las estimaciones resultan incorrectas, por lo que es difícil obtener el enfoque adecuado de las personas para desarrollar capacidades que afectan a múltiples componentes.

Lo opuesto al equipo componente es el equipo característico. Un equipo de características abarca tanto componentes como disciplinas y, por lo tanto, es capaz de crear características de valor comercial en distintos segmentos y totalmente probados. El enfoque de equipo de características reemplaza el pensamiento de eficiencia del siglo pasado con un concepto de autonomía de equipo, propiedad y responsabilidad. La acumulación de productos de los equipos de características se basa en el valor comercial, no en la dependencia de la tecnología. Si aún vives con los diagramas de Gantt, es probable que todavía no tengas equipos de características.

La creación de equipos de características tiene un coste: los desarrolladores deben aprender nuevas habilidades, lo que inicialmente los ralentizará. Afortunadamente, la mayoría de los desarrolladores disfrutan aprendiendo nuevas habilidades. Las técnicas como la designación de un "tutor componente" técnico para cada área pueden ayudar a medida que los equipos aprenden. Al igual que con cualquier desarrollo escalado, la integración continua (pruebas automatizadas que se ejecutan con mayor frecuencia) es crucial para evitar fallos en pruebas de regresión.

Una vez que una organización ha dominado los equipos de características, un próximo paso podría ser los equipos de funciones de propósito general con afinidad reducida a las áreas de características. Si bien este paso puede tardar años, este siglo pertenecerá a la organización de aprendizaje.

10. Equipos organizados por especialización funcional: Cada equipo requiere una combinación de actividades de desarrollo. Se obtiene agilidad a través del análisis continuo de los requisitos, el diseño continuo, la integración continua y las pruebas continuas, todo lo que se alimenta mutuamente.

11. La distracción: Una organización típica desperdicia mucho dinero en el cambio innecesario de tareas. Esto quiere decir que los equipos carecen de enfoque y es por ello que toman meses en alcanzar una estabilidad. Los equipos deben llegar al estado de autogestión necesario para un alto rendimiento y calidad. Algunas personas se encuentran perpetuamente en múltiples rutas críticas al mismo tiempo, lo que limita gravemente la productividad total. Para una escala efectiva, estas personas deben convertirse en mentores en lugar de ejecutores de tareas. Para aumentar su influencia, deben renunciar a algún control.

Las prácticas de gestión tradicionales que refuerzan la especialización exacerbarán el problema. Cuando un gerente pasa esto por alto al asignar trabajo a un individuo, hay menos posibilidad de asesorar a otros en las habilidades críticas. Un grupo de personas que se están moviendo individualmente no participará en el aprendizaje colaborativo que se espera de un equipo. Las organizaciones profundizan en estos surcos cada día.

En los rangos más altos, los problemas de la multitarea, la distracción, la ansiedad y la incapacidad de ganar influencia al abandonar el control son aún peores.

La comunicación lateral efectiva entre los equipos ayuda a los propietarios a concentrarse con calma en las responsabilidades, como priorizar el trabajo y ser el árbitro final de los requisitos.

12. Renuncia a priorizar: En el desarrollo de productos, el nuevo descubrimiento es el objetivo. Para gestionar esta realidad, el product owner debe llevar a cabo una reunión de refinamiento del portafolio de productos con el equipo en cada carrera. A medida que surgen grandes elementos del portafolio de productos, encuentra los aspectos de alto valor de ellos y divírlos en elementos más pequeños separados (generalmente "historias de usuario"). El product owner  del producto controla el alcance al decidir qué elementos encajarán en la proyección de lanzamiento, dadas las tendencias históricas de descubrimiento y de alcance.

13.Deuda técnica : Los problemas de administración de una organización son finalmente visibles en el código fuente. Esta "deuda técnica" causa problemas de producción y un alto coste de cambio. Idealmente, las pruebas de regresión se automatizan utilizando el mismo lenguaje de programación que nuestro código de producción, en lugar de herramientas propias que refuerzan la especialización. En el siglo XXI, se esperarán habilidades de ingeniería de cualquier desarrollador. Los equipos que inicialmente no tienen estas habilidades deben intentarlo hasta que las hayan aprendido.

14. Falta de compromiso con la transformación: Se requiere coraje, imaginación y apoyo de la gerencia. Muy pocos prestan la debida atención, y la administración a menudo no apoya a quienes lo hacen.

Como vemos hay muchos retos por superar  en este proceso de transformación y son múltiples las situaciones que se presentan, alguna por ignorancia, algunas por malas prácticas y otras situaciones por la misma forma como están conformadas las organizaciones en el hoy que no están preparadas para éste cambio. Sin embargo, lo importante es tener consciencia de que es algo inminente y que debemos afrontar de la mejor manera. Así que debemos estar dispuestos a aprender, a desaprender y sobre todo tener la mente abierta a que la cultura que se tiene hoy no será la misma del mañana, las necesidades de nuestro cliente cambian y nosotros debemos colocarlo en un lugar céntrico por ello debemos cambiar a su ritmo.  

Si te gustó este artículo no dudes en compartirlo con amigos, colegas y familiares. PMPMedellin contribuye cada día con llevarte nuevos conocimientos y contenidos actualizados.

Autor: Ing. Javier Mauricio León Reyes

Twitter e Instagram: @PMPMedellin

Fuente de la imagen:

https://arbolabc.com/imagenes-de-animales/guepardo

Fuentes consultadas:

22. oct., 2019

¿ Qué es la Deuda Técnica?

El concepto de deuda técnica no es un concepto fácil de explicar, dado que es algo intangible. Es decir, es algo que no se ve, pero que se sabe que está allí presente, acumulándose y evolucionando para convertirse en un problema que puede desencadenar reprocesos, sobrecostos, atrasos y problemas en el equipo de desarrollo de un proyecto Scrum.

De donde tomó su nombre la "Deuda Técnica" ?

El término surgío de la analogía utilizada por Ward Cunningham, en el año de 1992. Él comparó un desarrollo de software que presenta carencias a nivel técnico por entregarlo de manera temprana, con la petición de un crédito financiero.

Así como el crédito permite obtener liquidez a corto plazo, a costa de generar unos intereses a liquidar en un período de tiempo prolongado, las carencias en el desarrollo de software nos dan un entregable a corto plazo, pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado, sumando un esfuerzo extra - que son los intereses. Entonces las carencias de calidad en el desarrollo de software generan una deuda técnica igual a los intereses que genera un crédito bancario.

Origen de la Deuda Técnica

Ahora bien, la deuda técnica tiene 2 orígenes según menciona el  autor Steve McConnell:

  • Deuda añadida de forma involuntaria debida a trabajos de baja o poca calidad. Se atribuye normalmente al desconocimiento del equipo.
  • Deuda añadida intencionadamente para recortar tiempos haciendo las cosas mal. Se atribuye a un bajo sentido de la responsabilidad o de visión a largo plazo del equipo.

Principales causas de la deuda técnica en Scrum:

1. Definición previa insuficiente, este punto se le puede asignar a una mala labor del product owner.

2. La principal causa de la deuda técnica son las presiones en fecha y planes que impone el Negocio y los sponsors. En muchos casos, el equipo de desarrollo toma “atajos” para poder llegar a cumplir su compromiso dentro del plazo(Sprint).

3. Falta de colaboración: No compartir conocimientos hace que el software desarrollado no sea de calidad.

4. Falta de documentación: Por no disponer de tiempo se puede perder una forma común de desarrollar.

5. Falta de comprensión: Si la organización no conoce el concepto de deuda técnica, no podrá conocer las consecuencias de desarrollar un software de mala calidad.

6. Falta de procesos o entendimiento.

7. Componentes fuertemente acoplados. Es por ello que se propone con Scrum el uso de algunos patrones de diseño , arquitectura y de desarrollo que facilitan el desacoplamiento del código.

8. Baterías de pruebas incompletas. Un mal proceso de testing puede desencadenar deuda técnica porque los errores ingresarían al product Backlog como HU para ser implementadas.

9. Posponer procesos de refactorización.

10. liderazgo técnico pobre.

11. cambios en las especificaciones a última hora.

Y ¿ Cómo gestionamos la Deuda Técnica?

No debemos perder de vista que Scrum se basa en tres pilares: Transparencia, inspección y adaptabilidad. Estos pilares deben estar presentes en cada sprint del proyecto dentro del equipo del proyecto. Por ende tendremos el control sobre la deuda técnica y sus consecuencias si seguimos estos sencillos consejos:

1. Aprovechar al máximo la reunión Daily Meeting: Cada día el equipo de desarrollo puede detectar de manera rápida los posibles errores que se van presentando y tomar decisiones sobre su solución de forma individual o en conjuntos de errores para evitar problemas de calidad en el software.

2. Incluir dentro de las estimaciones HU y tareas (así como en la planeción) que sean relevantes como testing,  documentación y refactorización.

3. En caso de que sospeches que hay deuda técnica, utilizar futuros Sprints para refactorizar y no seguir heredando problemas en el desarrollo del software. "Recuerda que al mal tiempo darle prisa".

4. Involucrar a la organización. La mejor manera de hacer entender a los directivos es con hechos y datos. Estimar las horas extras que se necesitan en caso de que haya deuda técnica y llevar esas horas a dinero ya que normalmente ellos entienden mejor cuando se habla de  beneficios o pérdidas económicas.

5. Involucrar al scrum Máster : El SM es quien se encargará de evitar la deuda técnica y defenderá al equipo de eventos o fechas que puedan dañar la calidad de los entregables.

6. Cuidar el DOD - Definition of Done,  cualquier factor que elimine la deuda técnica debe estar incluído y nunca olvidar que el DOD debe estar siempre actualizado.

7. Si dentro de tu quehacer diario encuentras código que necesite ser refactorizado, documenta la situación para que éste la evidencia de esta deuda técnica. Este papel deberá ser tenido presente en la planning para ser estimado.

8. El equipo nunca debe trabajar en una funcionalidad que tenga deuda técnica sin solucionarla, esto porque se añadiria deuda sobre la deuda ya generada.

9. La decisión de realizar una nueva funcionalidad de una Historia de Usuario  y/o pagar deuda técnica no es responsabilidad del equipo de desarrollo , debe ser binaria con el Product Owner.

Esperamos que esta información haya sido útil para tí y tu equipo. Si te gustó el artículo compártelo con tus colegas, familiares y amigos que trabajen en proyectos de TI o de ingeniería y con metodologías de trabajo ágiles.

Autor: Ing.Javier Mauricio León Reyes

Twitter e Instagram: @PMPMedellin

Fuentes consultadas: 

http://scrumizate.com/post/61/cmo-luchar-contra-la-deuda-tcnica

8. oct., 2019

En este artículo queremos mencionar las principales caraterísticas de la arquitectura ágil resultado de la investigación de diversos artículos escritos por arquitectos y agilistas expertos en éste tema.

Así cómo los arquitectos tradicionales realizan procesos de modelado de construcciones a un alto nivel de abstracción, proveen posibles alternativas frente a la solución de un problema, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades de un  problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. El arquitecto de sofware hace los mismo en los proyectos de TI.  De esta manera se hace imposible pensar que un rascacielos de 300 metros pueda ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales y aplicaciones - Apps puedan ser implementados de manera estable sin una arquitectura bien concebida.

De acuerdo con lo que dicen los autores Bass, Clements y Kasman - “La arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software brinda una garantía de calidad del desarrollo de software y permite tener un sistema que cumpla con los requerimientos funcionales y no funcionales que el cliente espera. Por otra parte, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software, es decir, que influye en la eficiencia de manera directa. 

El autor Charlie Alfred dice textualmente : “La arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum”.

Teniendo presente la importancia de la arquitectura en el mundo del desarrollo de software, mencionaremos las  principales caraterísticas que se debe tener la arquitectura en un entorno Ágil. Dado que en los entornos actuales (VUCA) como ya hemos mencionado en artículos previos las condiciones son un poco diferentes por la velocidad que el cambio trae al mercado.

"Características de la arquitectura Ágil":

1. Arquitectura Incremental: Para iniciar, hay muchas personas que consideran que al iniciar el proyecto se debe contar con todo el diseño de la arquitectura (claro y detallado) antes de iniciar el trabajo por parte de los desarrolladores o el Sprint 1 y tenemos que es por ello que en la metodología tradicional ésto tomaba mucho tiempo de análisis - generando la no producción de ningún entregable en una fase inicial. Al fenómeno de diseñar a la perfección le llaman algunos autores "Big Design Upfront". Este enfoque ha sido  ampliamente criticado en los últimos años por quienes adoptan marcos de trabajo ágiles. Bajo un enfoque ágile se habla de una arquitectura base que tiene evolución a lo largo del proyecto, es decir, una arquitectura incremental. Se desconfía de un gran modelo de diseño y lo que se busca es definir la arquitectura mínima con la cual se podría iniciar la operación del primer entregable o en mejores términos del Mínimo producto viable. De este modo Sprint tras Sprint se pueden ir incluyendo cambios en la arquitectura buscando su optimización. Es importante decir en este punto, que esto no implica que no iniciemos con algunos elementos mínimos de referencia como son : un lenguaje definido, un framework, una base de datos, etc. Es común, también que dentro de una organización tengamos algunos lineamientos, estándares y políticas ya previamente definidas que se deban utilizar y otras que definirá el equipo Scrum de manera colaborativa. Lo que nos deja  abierta la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene para nuestro proyecto.

2. Diseño emergente : Esta es una propuesta respaldada por muchos en los entornos ágiles para el diseño de software, pues considera que el proceso de analisis  y diseño de software emerge cuando sea necesario para entregar los incrementos de cada sprint. Uno de los fundamentos de este enfoque es "la idea del cambio continuo". Aún cuando los requerimientos de software no cambien, en los últimos años la tecnología y la gente sí lo hace, cada vez con más frecuencia. Al finalizar el proceso de desarrollo y entregar los resultados finales, quedará un diseño simple y conforme a lo que fue realmente es necesario, que puede evolucionar con el tiempo siguiendo el mismo método.

3. Definir el propósito del diseño : No debemos olvidar que el propósito del diseño de software es principalmente comunicar de forma técnica las diferentes estructuras y comportamientos de un software, para facilitar su estudio, construcción y mantenimiento, así como la orquestación de los esfuerzos de construcción.

En la academia suele ser admirada y recomendada la notación UML,  que comprende diferentes diagramas y modelos aplicable a distintos niveles del diseño de un software. Esto no significa, que sea necesario diagramar absolutamente todo lo que esté allí definido. En  tanto los ingenieros logren comprender el diseño y construir el software de forma organizada, el propósito habrá sido cumplido. Por tanto, el diseño sólo debe cubrir aquello que sea necesario comunicar y bajo el medio más efectivo y óptimo para hacerlo. No debemos olvidar que a veces "Menos es Más", no quiero decir que no debemos documentar el diseño a lo que me refiero es que lo más importante es tener diseños simples.

4. Flexibilidad: Por la forma en que se construyen las aplicaciones hoy en día, es muy común la adopción de frameworks, el uso de APIs, librerías y de convenciones para facilitar los esfuerzos de construcción. El diseño de estos componentes está previamente definido.

Un desarrollador simplemente debe comprender la arquitectura de estos frameworks y apegarse a las convenciones recomendadas para que su diseño se mantenga consistente, y por tanto, sea fácil de asimilar por alguien más que domine el mismo framework.

Así, muchos aspectos del diseño se reducen a definir la arquitectura del software, sus componentes, aspectos de GUI y UI y UX, estructuras de datos, flujogramas, entre otros elementos estrictamente necesarios para comprender y avanzar.

5. Modelo C4: El autor Simón Brown quien es un consultor independiente en desarrollo especializado en arquitectura de software. Hace aproximadamente 2 años propuso un modelo para diseño de software simple, fácil de navegar y que comunica con más eficiencia.

Su modelo lo llamó Modelo C4, el dice que basta con definir los siguientes cuatro diagramas, relacionados entre sí y navegables en profundidad como si fuese un mapa:

  • Contexto: Visualiza el sistema en la organización, su relación con distintos actores que pueden ser usuarios y otros sistemas.
  • Contenedores: Visualiza la división del sistema en entornos de ejecución o almacenamiento, reflejando mejor la infraestructura.
  • Componentes: Visualiza internamente las piezas que componen un contenedor en particular, como aplicaciones o servicios.
  • Clases: Consiste en un diagrama de clases UML para aquellos casos donde sí sea necesario llegar a ese nivel.

6. Validación continua: Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayude a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de carga, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación. 

Esa validación permanente en el entorno de desarrollo y de QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico y poder tomar mejores decisiones en nuestro modelo de arquitectura.

7. La arquitectura no es solo una tarea del arquitecto: Como mencionabamos previamente, dado que no se diseña la arquitectura por completo desde el inicio y que no es un tema que atañe solo al que tiene el título del "Arquitecto" sino que es un tema discutido por todo el equipo e incluso con el Product Owner y los involucrados del negocio. Y dado que las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista. Nos encontramos también con que las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se va validando en la implementación. Ahora bien, no quiere decir esto que si tu compañía tiene un equipo de Arquitectura Corporativa o Empresarial esto está mal. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación apoyando al equipo y ayudando a tomar mejores decisiones.

Todas estas ideas tienen mucho más contexto y trasfondo. Quisimos en esta pequeña recopilación de información - mostrar un breve resumen de lo que investigamos de algunos artículos revisados y con base en nuestra experiencia en proyectos de TI llevados a cabo bajo  marcos de trabajo ágiles y utilizando Scrum como framework principal.

Si te gustó esta información compártela con familiares, colegas y amigos.

Visita nuestos otros blogs en el siguiente link : http://www.pmpmedellin.com/431433692.

Autor : Ing. Javier León Reyes

Fuentes consultadas:

Paper “Software Architecture in the Agile Life Cycle”  2013. Lo puedes revisar en este link:

https://www.dropbox.com/s/ho52huc71ewe6tz/Arquitectura%20en%20el%20Ciclo%20de%20Vida%20Agil.pdf?dl=0

https://martinalaimo.com/es/blog/arquitectos-agiles

https://jonathan.vargas.cr/es/temas/desarrollo/18287-arquitectura-y-diseno-de-software-en-el-mundo-agil

https://sg.com.mx/revista/30/el-papel-la-arquitectura-software-scrum

https://www.codeandbeyond.org/2018/09/3-elementos-para-una-arquitectura-mas.html