Entrega continua: ¡lo está haciendo mal!

Veo muchos equipos exitosos de DevOps (sí, ¡ya hay unos cuantos!) en un punto de su viaje donde han aprendido a trabajar juntos como un solo equipo, sin ningún muro entre ellos, y ahora se centran en aumentar la velocidad de entrega. Es entonces cuando hacen de la Entrega Continua (Continuous Delivery, CD) una de sus prioridades.

Cuando la mayoría de las personas piensan en CD, piensan en mejorar el ciclo de desarrollo-prueba-implementación-operación. No piensan en cómo acelerar y mejorar el proceso de admisión. Asegurar que la calidad esté integrada a la aplicación (y no probada para la aplicación después de los hechos) es la clave para lograr la aceleración deseada a través de CD. Y las organizaciones de prueba y control de calidad están tratando de transformarse para convertirse en los facilitadores de la aceleración en el proceso de CD (vea los 3 cambios observados en el control de calidad y pruebas empresariales para saber más), mientras integran la calidad en la aplicación.

La brecha en la aceleración de CD

Las organizaciones que trabajan para lograr la entrega continua pronto se dan cuenta de que pueden hacer las cosas bien y con rapidez. Sin embargo, todavía no están seguros de si están creando las cosas correctas. Hay una diferencia entre ambas y, en mi experiencia, esta es una brecha en las iniciativas de CD.

La semana pasada me invitaron a un taller de un día sobre transformación de DevOps en una gran empresa multinacional, al cual asistieron sus equipos de negocios, desarrollo, pruebas, operaciones, PMO y arquitectura empresarial. Esa fue la primera sesión en su viaje, y el objetivo de ese día fue que los diferentes equipos acordaran una terminología común entre los grupos y también identificarán las áreas prioritarias que querían mejorar. Me estaban pidiendo un poco de entrenamiento para asegurarse de que iban por el camino correcto.

Ese día estaba claro que todas las conversaciones inevitablemente convergerían en la forma de acelerar el desarrollo de código, las pruebas y la implementación en los diferentes entornos. Sin embargo, nadie se cuestionó si estaban utilizando la información correcta (es decir, requisitos claros y sin ambigüedades) antes de comenzar a codificar, probar e implementar. Ahí es cuando aparecí para conducir la sesión.

Entonces, ¿cómo asegurarse de que se están creando las cosas correctas y se lo está haciendo? Se trata de enfocarse en mejorar y acelerar el proceso de recolección de requisitos, independientemente de si está en una organización tradicional o ágil.

Un buen ejemplo de esto es la forma en que se comunican los requisitos a través de diferentes equipos. Los requisitos son la base de todo en el ciclo de vida del desarrollo de software (SDLC), y sin embargo, después de 30 años, todavía se comunican de la misma manera a los diferentes equipos: a través del lenguaje escrito. Se escriben en documentos de Word o Excel, o en herramientas de gestión de requisitos. Y ese es un proceso totalmente manual.

Naturalmente, un proceso manual se convierte en un cuello de botella en un proceso de CD altamente automatizado donde el objetivo final es la velocidad con calidad. No sólo eso, sino que los requisitos escritos en texto muchas veces son ambiguos y están abiertos a la interpretación. La ambigüedad es la causa de, aproximadamente, el 56%[i] de los defectos en el código de la aplicación. La primera versión de la famosa cifra que se encuentra debajo fue lanzada hace más de 10 años por projectcartoon.com pero, desafortunadamente, sigue siendo relevante. Cada equipo implicado en el SDLC tiene diversas interpretaciones y expectativas sobre los requisitos.

Las metodologías de desarrollo de software ágil y, más recientemente, las prácticas de CD buscan evitar esto. Cambian el paradigma de desarrollo de software a iteraciones cortas y retroalimentación continua a través de los equipos para asegurar que cualquier brecha de comunicación o expectativas imprecisas que conduzcan a la ambigüedad en los requisitos, sean identificadas y abordadas antes en el ciclo de vida, probando de forma temprana todas las actividades relacionadas con la calidad para prevenir los defectos, en lugar de probarlos. Sin embargo, la mayor parte de esas actividades son manuales, lo cual retrasa el proceso de CD.

Todavía hay demasiado esfuerzo manual

Además de la aceleración de los requisitos que se pasan por alto en las iniciativas de CD, también veo muchas empresas con las que trabajo que siguen haciendo un montón de cosas manualmente, cosas que podrían automatizar.

  • Los casos de prueba siguen estando diseñados de la misma manera: se basan en la lectura de documentos de requisitos o historias de usuarios y el diseño de casos de prueba y pasos de prueba. El proceso es manual y poco metódico. La cobertura de los casos de prueba depende de quién escriba el caso de prueba y su comprensión de los requisitos.
  • La automatización de las pruebas no es algo presente en el SDLC. Alrededor del 70% de las pruebas se siguen haciendo manualmente. Los equipos que han logrado mejores niveles de automatización todavía luchan porque la creación de las pruebas automatizadas sigue siendo un proceso muy manual. Los desarrolladores orientados al desarrollo basado en pruebas o los ingenieros de automatización de pruebas todavía tienen que escribir código manualmente para automatizar las pruebas en la aplicación. Dependiendo del desarrollador o el ingeniero, los scripts de prueba automatizados lograrán diferentes niveles de cobertura de pruebas y deben mantenerse a lo largo del tiempo, lo que también requiere más esfuerzo manual.
  • Los datos de prueba son siempre un cuello de botella y un problema para la mayoría de las organizaciones, ya que ocupan alrededor del 50% del tiempo del evaluador. En un nivel muy simple, generalmente lo abordan al tomar una copia de los datos de producción, enmascararla y ponerla a disposición de los entornos de preproducción. Este proceso es generalmente una mezcla de los procesos manuales y automatizados que tardan mucho tiempo (en algunos casos, de días a semanas). Desafortunadamente, basado en lo que suelo ver en las organizaciones con las que trabajo, la variedad de datos en producción por lo general cubre sólo el 10-20% de los casos de prueba. Eso significa que se necesita tiempo adicional para crear y preparar manualmente los datos.
  • Las interconexiones con otros sistemas (por ejemplo, a través de API, servicios web, etc.) son siempre difíciles porque, normalmente, 56% de esas dependencias no están disponibles para desarrolladores y evaluadores. Esas interconexiones no tienen la capacidad requerida por el sistema bajo prueba o simplemente aún no se han creado. Esto retrasa el tiempo de desarrollo y prueba, ya que las interconexiones tienen que ser simuladas a la hora de probar el código de la aplicación.

Por lo tanto, escuchamos una gran cantidad de conversaciones sobre automatización durante el proceso de entrega continua y que debemos eliminar tantas actividades manuales como sea posible para lograr la máxima aceleración. Sin embargo, está claro ahora que aún tenemos trabajo por hacer.

Los requisitos como la base de la entrega continua

Cuando un arquitecto está diseñando una casa, comienza con un bosquejo o un plano. Ese modelo se revisa una y otra vez con el cliente. Una vez que el cliente está satisfecho, el arquitecto comparte el plano con las otras personas involucradas en el proceso de diseño, como el diseñador de interiores y el ingeniero eléctrico. A continuación, ellos añaden sus diseños como capas en ese plano de base creado por el arquitecto.

Obviamente, se trata de una descripción de muy alto nivel del proceso de diseño de una casa, pero no se distraiga que ya viene la analogía.

Los arquitectos y los otros roles en el proceso descrito anteriormente usan software de diseño asistido por computadora (CAD) en los proyectos de diseño. El software los ayuda a integrar todas las capas de diseño (de las diferentes personas) al plano de base y mantiene un seguimiento completo de todos ellos. Así, a través de la herramienta CAD, cada persona puede ver el proyecto completo con todas las capas activadas o simplemente puede activar su propia capa (por ejemplo, la plomería o la instalación eléctrica) para ver sólo lo que les pertenece. La principal ventaja es que todos los involucrados están trabajando en el mismo plano de base y todos entienden cómo cada cosa encaja en el proyecto.

La mejor parte es cuando hay un cambio en alguna de las capas. El software identifica automáticamente el impacto de los cambios en todas las capas y le pide al usuario que tome medidas para actualizar una capa específica y abordar el impacto en ella. Hay una gran cantidad de sugerencias automatizadas para cada propietario de una capa afectada acerca de cómo pueden implementar una corrección en una capa. A continuación, puede ver un ejemplo de varias capas en un proyecto de diseño de una fábrica representado en una herramienta CAD.

Pruebas verdaderamente tempranas y aceleración máxima del ciclo de vida

Ahora imagine si estos conceptos, técnicas y herramientas de diseño de edificios hubiesen existido en el mundo del diseño de software. ¿Definir un requisito sin ambigüedades? ¿Mantener un seguimiento completo de pantallas, códigos, pruebas manuales, pruebas automatizadas, datos de prueba, interfaces (virtuales o reales), defectos de aplicaciones, etc.? No hay necesidad de seguir imaginando. Conozco a muchas empresas que ya se están acelerando de forma completa el proceso de entrega continua, comenzando con los requisitos y siguiendo con la codificación, las pruebas y la implementación.

Esté atento porque compartiré un enfoque detallado sobre cómo aplicar estas técnicas de diseño de edificios al diseño de software.

 

[i]Investigación de Bender RBT

¿Cuál es su excusa?

Póngase en contacto con CA

Chat
¿Sobre qué le gustaría hablar?
Contacto
Contáctenos 1-800-225-5224
Contáctenos