¿Qué desafíos enfrenta como único escritor técnico en su empresa que sigue el modelo Agile para el desarrollo de software?

Trataré de responder esta pregunta, aunque puede que no sea exacto porque nunca he trabajado como el único escritor en un equipo ágil. Sin embargo, he trabajado en organizaciones que siguen a Agile.

En una de esas empresas, tuve la suerte de trabajar con excelentes consultores en Agile. La compañía estaba haciendo la transición de cascada a Ágil y estos consultores fueron contratados para ayudar en la transición. Al menos desde el punto de vista de la documentación, creo que hicieron un trabajo increíble.

Antes de que estos consultores llegaran, la documentación siempre se entregaba al menos un sprint después del desarrollo real. Cuando llegaron los consultores, nos explicaron lo que significa Agile verdadero. En el verdadero sentido, al final de cada sprint Agile, el producto debería estar listo para salir al mercado. En nuestro caso, claramente no lo estábamos. Nuestro producto habría estado listo, pero no nuestra documentación.

Los consultores hicieron un gran trabajo al explicarnos esto y cambiamos la forma en que trabajamos. Los escritores técnicos (y miembros de otras funciones) se convirtieron en una parte activa de la reunión de pie diaria. Nos incluyeron en la planificación de sprint y demostraciones. Esto nos dio una mejor comprensión de lo que se está desarrollando en el sprint. Cuando se desarrolló la característica, trabajamos en las descripciones generales y las introducciones para la característica. Cuando se desarrolló la función, trabajamos con el equipo de prueba para documentar los procedimientos y otros detalles funcionales. Estábamos abiertos al retrabajo causado por la corrección de errores, pero logramos hacer todo al final del sprint.

Para resumir, como escritor técnico que trabaja en Agile:

  • Sea parte de todas las ceremonias de scrum y exprese sus opiniones y preocupaciones. Es importante que todo el equipo comprenda cómo encaja. Es posible que necesiten modificar la forma en que trabajan para ayudarlo a alcanzar sus objetivos. Recuerde, en Agile, el éxito de un individuo no se valora tanto como el éxito del equipo scrum.
  • Estar abierto a retrabajar. En Agile, habrá casos en los que tendría que volver a trabajar en lo que ya está documentado. Esto está completamente bien. Si está reelaborando algo, la mayoría de las veces, todos los demás equipos también lo están haciendo.
  • Es posible que también tengas que modificar tu estilo de trabajo. Como dije antes, el éxito de su (y de todos los demás miembros del equipo) radica en el éxito del equipo. Esté abierto a adaptarse con sus compañeros de equipo para asegurarse de entregar un excelente producto. Estas cosas generalmente se ordenan mejor durante las reuniones de planificación de sprint.

Espero que esto responda a su pregunta.

La respuesta de Tarun es acertada con respecto a ser consciente de los principios de ágil. Es difícil para un escritor técnico mantenerse al día con el resto del equipo de desarrollo en un entorno ágil porque el objetivo (es decir, su producto) para el que está escribiendo se mueve muy rápido. Como sugiere su respuesta, es común que el lado de la documentación de las cosas vaya a la zaga del desarrollo.

Le daré una idea de la parte del “escritor técnico único” de su pregunta. Probablemente ya lo sepas, pero tú y el trabajo que haces son una idea de último momento para el resto de tu equipo. El desarrollo ágil es una gran oportunidad para cambiar su mentalidad. Vaya a cada reunión: planificación de lanzamientos (sí, usted pertenece a esa), planificación de sprints, refinamientos de pedidos pendientes, stand-ups diarios, demostraciones y retros. Es posible que no tenga nada que decir durante algunas de estas reuniones, pero el punto es que usted está allí y el resto del equipo lo notó. Eventualmente, tendrá éxito al inculcar a sus compañeros de equipo que la documentación es tan integral para un producto de software exitoso como cualquier otra función en el equipo. ¡Buena suerte!

La falta de tiempo para terminar la documentación y una menor comprensión del producto y los procedimientos son dos grandes problemas para escribir en forma ágil. Dado que los productos se mueven a un ritmo rápido en Agile, pueden tener dos opciones los redactores técnicos:

1. Participación en todos los eventos SCRUM desde el principio (todas las reuniones, incluidas las reuniones de requisitos)

2. La entrega de documentación para un sprint en el siguiente sprint significa un sprint detrás.

Obviamente, todos preferirán el primer enfoque. Por lo tanto, siempre es mejor ganar conocimiento como las PYME y ser paralelos en la carrera.

Fui un escritor técnico único durante algún tiempo en un grupo que intentaba volverse ágil. Entonces, uno de los primeros problemas será la falta de tiempo para terminar las cosas. Tarun Amembal y Ryan Anthony han dado excelentes respuestas a esta pregunta. Estoy totalmente de acuerdo con ellos.