[10/02/2021] Los equipos ágiles y de desarrollo de aplicaciones han estado trabajando a distancia durante la mayor parte del año pasado. Los desarrolladores han descubierto cómo utilizar Zoom, Microsoft Teams y Google Meet para realizar reuniones virtuales. Algunos utilizan Slack para las comunicaciones asíncronas, mientras que otros se centran en las capacidades de colaboración integradas en herramientas ágiles como Jira, Azure DevOps y Asana. Los mejores equipos de desarrollo a distancia también han mejorado sus conductos CI/CD y otras automatizaciones devops para reducir el trabajo y abordar los procesos propensos a errores.
Ir más allá de las prácticas básicas de colaboración es esencial para los equipos de desarrollo remotos. Según una encuesta reciente, el 65% de los ejecutivos de TI afirmaron que al menos una cuarta parte de su planilla seguiría trabajando a distancia. Y, de hecho, las empresas que ofrecen más oportunidades de trabajo a distancia pueden ser un buen cambio. Una segunda encuesta sobre el futuro del trabajo y el desarrollo de software informa de que casi el 60% de los encuestados aumentó la productividad de los desarrolladores de software al trabajar a distancia.
Entonces, si los desarrolladores que trabajan a distancia son una nueva norma, ¿qué deberían hacer los equipos de desarrollo ágil para mantener la productividad y la calidad del software, o mejor, para aumentarlas? Me he centrado en la colaboración en artículos anteriores sobre prácticas remotas para equipos ágiles y equipos remotos de desarrollo e ingeniería, incluyendo la celebración de reuniones y el intercambio de conocimientos. En este artículo, sugiero otras siete mejores prácticas en torno al proceso de desarrollo de aplicaciones.
Utilizar la planificación ágil continua para mantener las hojas de ruta y los backlogs
El proceso de desarrollo debe comenzar discutiendo los objetivos, las prioridades y los requisitos con el propietario del producto ágil, el equipo de desarrollo y otras partes interesadas. Estas discusiones conducen a la redacción de historias, la estimación y el desarrollo de soluciones.
Las soluciones de software sólidas, innovadoras y seguras suelen requerir más de un sprint de planificación. Además, la mayoría de las partes interesadas del negocio quieren tener visibilidad en el plan de lanzamiento y la hoja de ruta para planificar las actividades de cambio de la transformación digital, como el marketing para las aplicaciones orientadas al cliente y la formación para las aplicaciones de experiencia de los empleados.
Es difícil lograr este nivel de planificación si los equipos solo tienen backlogs para los próximos uno o dos sprints, y organizar reuniones de planificación trimestrales es menos productivo para los equipos de desarrollo remotos.
La mejor práctica es planificar continuamente añadiendo, estimando y priorizando características e historias al backlog en cada sprint. Los mejores equipos aspiran a tener al menos cuatro sprints de un backlog de historias dimensionadas y talones de historias estimadas. Los equipos que hacen esto tienen más tiempo para involucrar a las partes interesadas en la definición del MVP, desarrollar soluciones arquitectónicas sólidas y trabajar a través de las dependencias.
Utilizar una herramienta de pizarra para hacer una lluvia de ideas y documentar las soluciones
Una imagen vale más que mil palabras, y colaborar con las partes interesadas en la elaboración de personajes de clientes, mapas de viaje y declaraciones de problemas es una buena práctica. Los equipos deben invertir tiempo en desarrollar una comprensión compartida de los objetivos y las necesidades de los usuarios finales, pero esto no es fácil cuando las personas no pueden entrar en una sala para hacer una lluvia de ideas sobre oportunidades y soluciones.
Los equipos de desarrollo deben utilizar mejores herramientas que las pizarras blancas para realizar una lluvia de ideas con los propietarios del producto y las partes interesadas. Dos herramientas a tener en cuenta son Miro y Creately; ambas ofrecen numerosas plantillas para que los equipos comiencen a realizar diagramas colaborativos. Los equipos que desarrollan interfaces de usuario deberían utilizar herramientas de diagramación como Balsamiq, Moqups, Adobe XD y otras alternativas.
Los equipos de desarrollo también deberían utilizar herramientas de diagramación para planificar la arquitectura y las implementaciones. Tres de las más populares son Gliffy, Lucidchart y Visio.
Invierta tiempo en aprender, en hacer picos y en innovar con POCs
La innovación, el aprendizaje y la experimentación no deben detenerse porque los equipos de desarrollo trabajen a distancia. Tal vez los almuerzos y aprendizajes sean menos impactantes para los equipos de desarrollo remotos, pero hay opciones para que los equipos remotos establezcan una cadencia en el aprendizaje, la experimentación y el intercambio de conocimientos. He aquí algunas ideas:
- Una vez al mes, elija un servicio de nube pública, haga que un equipo de desarrollo realice un POC ágil y luego comparta los resultados con otros equipos.
- Mirar hacia adelante en las futuras características priorizadas por el propietario del producto, y crear picos en el backlog para probar nuevas tecnologías o validar las opciones de implementación.
- Investigar nuevas oportunidades de aprendizaje, especialmente en agilidad y scrum, certificaciones de devops, ciencia de datos o certificaciones de la nube. Cuando los compañeros de equipo realicen cursos, pídales que proporcionen una actualización virtual a todos sobre lo que han aprendido y cómo los equipos pueden aplicar esos conceptos.
La clave para los equipos remotos no es solo el aprendizaje. Compartir con los compañeros de equipo y aplicar lo aprendido es una forma estupenda de que los grupos se mantengan conectados, así como de reforzar una cultura de aprendizaje constante.
Salga de su zona de confort con el código bajo
Muchas veces, los equipos de desarrollo remotos son llamados a entregar aplicaciones, integraciones y modernizaciones estratégicamente importantes. Pero hay otras veces en las que la organización necesita desplegar una capacidad muy rápidamente, o la aplicación solicitada se utilizará sólo durante un corto período de tiempo, o la aplicación requiere flujos de trabajo e integraciones complejas. Cuando los equipos de desarrollo sienten que sus platos están demasiado llenos o que la aplicación solicitada está fuera de sus puntos fuertes de desarrollo, deberían considerar opciones alternativas para desarrollar y dar soporte a las aplicaciones.
Una de esas opciones de aplicación debería incluir el uso de una plataforma de bajo código. Las plataformas de bajo código y de desarrollo ciudadano son opciones importantes para los equipos de desarrollo remotos que probablemente tengan una pila creciente de solicitudes de aplicaciones para digitalizar los flujos de trabajo y modernizar las aplicaciones heredadas.
La mejor práctica aquí es salir de la zona de confort del desarrollador y de la suposición de que la mejor herramienta para el trabajo es siempre la codificación. Los desarrolladores son innovadores, solucionadores de problemas y artesanos. Entender las diferentes opciones de implementación puede llevar a ofrecer nuevas capacidades más rápidamente.
Desplazar las pruebas y la seguridad
Independientemente de cómo se desarrollen las aplicaciones y de dónde se desplieguen, los equipos de desarrollo deben probar las aplicaciones para garantizar que las versiones de las mismas cumplen los requisitos funcionales, las normas de rendimiento, los requisitos de seguridad y otras obligaciones de cumplimiento. Los equipos de desarrollo remotos no pueden confiar en que los usuarios finales realicen pruebas de aceptación de usuarios sólidas. Tendrán que automatizar las pruebas de plataforma, API, funcionalidad, rendimiento y seguridad. Los equipos con pipelines CI/CD deberían considerar la posibilidad de realizar pruebas continuas, en las que el pipeline activa un subconjunto de las pruebas automatizadas.
Los equipos de desarrollo remotos también deberían sentir una mayor urgencia por implementar estrategias de pruebas por turnos, en las que se establecen y automatizan pruebas sólidas en una fase más temprana del proceso de desarrollo. Nadie quiere desplegar defectos en producción o responder a incidentes de producción, pero las barreras para solucionarlos (y los costos y tensiones) pueden ser significativamente mayores cuando muchas personas trabajan de forma remota.
Otras dos áreas de interés para los equipos de desarrollo remoto son la seguridad de los turnos y el uso de indicadores de características cuando se introducen nuevas capacidades. La mejor práctica en este caso es que los equipos de desarrollo remoto deberían centrarse más en mejorar la calidad de las implantaciones que en aumentar la frecuencia de las mismas. Los despliegues de alta calidad son más importantes que la velocidad.
Automatizar la gestión de cambios de bajo riesgo
Lo último que quieren los equipos de desarrollo remoto es pasar horas en una reunión de la junta consultiva de cambios para obtener la aprobación de los despliegues de aplicaciones de bajo riesgo. Esta reunión puede no ser un gran uso del tiempo, pero la formalidad del proceso es importante para los equipos operativos y de seguridad, que a menudo rastrean los incidentes de producción hasta estas aprobaciones de cambios. Además, muchas empresas deben tener un proceso de aprobación de cambios para el cumplimiento de SOC 2 y otras auditorías.
Junto con los líderes de operaciones y de cumplimiento, los equipos de desarrollo que han implementado prácticas de CI/CD, pruebas continuas y seguridad por turnos, deberían explorar opciones para digitalizar o automatizar las aprobaciones de los cambios de bajo riesgo. Las herramientas pueden ayudar a aliviar los trámites de aprobación de cambios, por ejemplo, mediante la aprobación automática de cambios estándar en Jira Service Manager.
Desarrollar una cultura de fuera a dentro buscando la opinión de otros desarrolladores
Los equipos de desarrollo también deberían buscar otras buenas prácticas. He aquí algunos buenos ejemplos:
- Tiffany Jachja, defensora de los desarrolladores en Harness, recomienda mantener una mentalidad que dé prioridad a la salud (por ejemplo, horarios flexibles, descansos, buena ergonomía) y crear una cultura que promueva el intercambio digital.
- Semi Koen comparte varias recomendaciones para trabajar desde casa y sugiere evitar las distracciones digitales y mantenerse visible en las herramientas de colaboración.
- Varios desarrolladores ofrecen recomendaciones para los standups de scrum remotos, y Ekram Aktas recomienda centrarse en los obstáculos y permitir que los desarrolladores "en la zona" se pierdan la reunión.
- Por último, si tienes preguntas o dudas sobre el trabajo de desarrollo a distancia, o estás interesado en conocer la perspectiva de un desarrollador sobre el trabajo a distancia, te recomiendo que consultes el artículo de Tom Cafferkey "10 myths I busted working remotely as a developer”.
Los equipos de desarrollo que buscan consejos, opiniones y mejores prácticas externas pueden aprovechar las ideas y soluciones de otras personas para superar sus retos de trabajo a distancia. También pueden obtener conocimientos sobre la lluvia de ideas, la innovación y la creación de soluciones que pueden aplicar a las oportunidades y desafíos más amplios de la empresa.
Basado en el artículo de Isaac Sacolick (InfoWorld) y editado por CIO Perú
Isaac Sacolick es el autor de Driving Digital: The Leader's Guide to Business Transformation through Technology, que cubre muchas prácticas como la metodología ágil, devops y ciencia de datos que son fundamentales para los programas exitosos de transformación digital. Sacolick es un reconocido CIO social, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com, también es presidente de StarCIO.