Este artículo está escrito por Paul Craig, desarrollador sénior, equipo de la plataforma CDS en el Servicio Digital Canadiense (CDS). Este artículo se publicó por primera vez como una publicación de blog para el CDS , que colabora con los departamentos federales canadienses para crear servicios digitales más simples y utilizables. Lee el artículo original aquí.


Es un buen momento para trabajar en la prestación de servicios digitales. Las personas están más conectadas que nunca esperando tener acceso a servicios digitales modernos. Al mismo tiempo, el desarrollo 'ágil' (construir y probar prototipos en semanas en lugar de pasar años en la planificación) ha ganado aceptación generalizada.

Como líder técnico en el Servicio Digital Canadiense (CDS), he visto muchos de los problemas con los que se encuentran los nuevos equipos, derivados de un choque cultural entre los equipos ágiles que priorizan el código y los procesos de activación en cascada con mucho papeleo. Los departamentos que experimentan con equipos ágiles todavía quieren que trabajen con grupos de aprobación, lo que en última instancia significa encontrar un lugar dentro de las culturas departamentales existentes y aprobar el trabajo como cualquier otro equipo.

La metodología Agile prioriza la participación temprana del usuario. Los comentarios de los usuarios no solo le brindan información para mejorar su producto, sino que también funcionan como documentación interna que aumenta su credibilidad.

En un equipo ágil, su fortaleza es su capacidad para crear rápidamente prototipos y hablar con los usuarios, pero su debilidad es la percepción de que estas prácticas introducen un riesgo indebido. Es crucial lograr un equilibrio entre llegar rápidamente al lanzamiento de un producto y escribir la documentación requerida por los procesos de activación tradicionales . Los equipos ágiles exitosos deben moverse rápido y estar seguros.

Muévase rápido: la ventaja ágil

Los equipos ágiles son el verdadero negocio. Algunas de las empresas más grandes de la actualidad llegaron a donde están porque los flujos de trabajo ágiles son realmente buenos para entregar valor rápidamente, superando a las empresas más establecidas con modelos de entrega más lentos.

En general, como parte de un equipo ágil, desea definir su MVP (producto mínimo viable) y luego probarlo con los usuarios lo antes posible. La planificación en cascada no tiene una buena respuesta a las 'necesidades del usuario'. La metodología Agile prioriza la participación temprana del usuario. Los comentarios de los usuarios no solo le brindan información para mejorar su producto, sino que también funcionan como documentación interna que aumenta su credibilidad.

Una vez que esté seguro de que su producto funciona, concéntrese en lo que necesita hacer para lanzarlo. Es mucho mejor tener un servicio 'alfa' lanzado que un prototipo interno altamente pulido. Por supuesto, la contrapartida con 'rápido' es que, convencionalmente entendido, significa comprometer la seguridad, por lo que debe equilibrar 'moverse rápido' con 'estar seguro'.

'Estar seguro' en ágil

Para los equipos ágiles, existen 4 formas principales en las que el desarrollo ágil es más seguro que el desarrollo tradicional de productos en cascada.

  1. Agile reduce los errores existenciales en el diseño de un servicio: la participación temprana del usuario mitiga el riesgo de lanzar un servicio de bajo rendimiento.
  2. Agile reduce el costo de los errores: la iteración frecuente significa cambios más pequeños con mayor frecuencia, lo que significa que los errores tienden a ser más pequeños y más rápidos de reparar.
  3. Agile reduce la probabilidad de errores mediante un mayor uso de procesos automatizados. Además de estos argumentos ágiles ortodoxos, hay un último punto más filosófico a considerar.
  4. Agile es, sobre todo, un enfoque flexible que se adapta rápidamente. Los equipos ágiles son pragmáticos en la resolución de problemas para los usuarios.

Hemos discutido previamente la primera respuesta en otras publicaciones (consulte las publicaciones de blog Aprendiendo de las personas que desean usar nuestro servicio de informes y Pruebas de validación: una forma de desafiar sus suposiciones ), así que veamos las demás.

Agile reduce el costo de los errores

Tratar de prevenir problemas mediante la superposición de comités puede crear un círculo vicioso. Todas estas capas de gobierno se crean para evitar errores costosos, pero los errores suelen ser costosos debido a un gobierno excesivo.

Por el contrario, el desarrollo ágil de productos reduce el costo de los errores . Los equipos que lanzan a diario pueden corregir errores en cuestión de horas, mientras que en los equipos más tradicionales es posible que esté viendo "silos de lanzamiento" de 3 a 12 meses.

Agile reduce la probabilidad de errores

La gobernanza en cascada tradicional se basa en humanos para auditar los productos antes de su lanzamiento.

Esto es costoso de ejecutar y difícil de escalar 1 . Si desea moverse el doble de rápido, debe contratar el doble de personal. Por el contrario, el desarrollo ágil de software busca reemplazar este cuello de botella con pruebas automatizadas que una computadora puede realizar, generalmente en cuestión de segundos. Es muy común que la documentación de seguridad esté desactualizada: una vez escrita, describe cómo solía funcionar el sistema, mientras que las pruebas automatizadas (creadas a través de auditorías dirigidas por humanos) eliminan la necesidad de documentación y están actualizadas por definición. .

Ágil es flexible

El segundo principio del Manifiesto para el desarrollo ágil de software es 'software de trabajo sobre documentación completa', lo que parece un enfoque bastante bueno: concentrémonos en construir el producto en lugar de escribir largos documentos de Word o presentaciones de PowerPoint. Sin embargo, el primer principio es 'individuos e interacciones sobre procesos y herramientas' y, lamentablemente, la gobernanza actual establece que estos equipos requieren una documentación completa. Los equipos de supervisión tradicionales solicitan a los equipos de productos una extensa documentación escrita sobre cómo funciona y se administra su sistema. Si no lo proporciona, hay pocas posibilidades de que su proyecto sea aprobado. Como equipo ágil en el gobierno, su principio es 'software de trabajo' y 'documentación completa'.

¿Moverse más rápido o ser más seguro?

En resumen, las dos consideraciones importantes para los equipos ágiles en organizaciones grandes son:

  1. Entregar valor rápidamente , lo que significa poner algo en manos de los usuarios rápidamente, sin pasar años en la planificación.
  2. Administrar el riesgo (percibido) , lo que significa protegerse contra los errores y completar el papeleo.

Los equipos que se mueven rápido optimizan la velocidad y construyen rápidamente. Los equipos que son seguros se toman su tiempo, se enfocan en probar las canalizaciones y, a veces, en escribir documentos grandes.

Estos dos puntos parecen estar en tensión entre sí. Si quieres la máxima velocidad, no escribas ninguna prueba. Simplemente escriba el código, envíelo y pruébelo en producción haciendo que los usuarios reales encuentren errores. En cambio, si quieres la máxima seguridad, nunca sueltes nada. El software que nunca se ejecuta nunca se piratea.

Entonces, ¿dónde debe ubicarse en el continuo 'rápido' versus 'seguro'? Para responder a esto, averigüe a qué se enfrenta. Si los plazos típicos de desarrollo de productos son de 2 a 3 años para el lanzamiento, vea si puede lanzar un servicio alfa en 6 a 9 meses.

Conclusión

Como profesionales ágiles, la oportunidad que existe en el gobierno es clara: los proyectos de TI gubernamentales tradicionales a menudo no logran entregar productos que pongan a los usuarios en primer lugar o que cumplan con las expectativas de los usuarios.

Dados estos problemas sistémicos, parece pan comido cambiar a un modelo ampliamente exitoso de entrega de proyectos que prioriza la retroalimentación rápida y el retorno temprano de la inversión. Los equipos ágiles hacen más con menos gastos generales y, al probar con los usuarios, tienen más confianza en lo que están construyendo.

Sin embargo, los equipos ágiles del gobierno canadiense operan en condiciones bastante duras y, por lo general, tienen que buscar acomodo dentro de una cultura existente de evitación extrema de riesgos. La fortaleza de los equipos ágiles es su enfoque en el envío temprano y la mejora gradual, pero tiene que enviar algo . Dado esto, es extremadamente importante equilibrar un compromiso con la seguridad con el deseo de llegar rápidamente a un lanzamiento.

Combinar dos enfoques opuestos siempre presentará desafíos, pero es importante mantenerse enfocado en brindar valor real a los ciudadanos. Al final del día, debe demostrar que su enfoque funciona haciendo que funcione. Elija un producto, mantenga un estricto control sobre su alcance, póngalo en manos de los usuarios y cuente su historia en el camino. Moverse rápido muestra lo que es posible, mientras que estar seguro garantiza que sea viable.

  1. La práctica de Ingeniería de Confiabilidad del Sistema define este trabajo repetitivo y de bajo valor como 'trabajo duro'. [devolver]

👋 ¡Puedes crear una publicación como esta! Comparta sus pensamientos con una comunidad de servidores públicos. Aprende más

(Crédito de la imagen: Unsplash)