Tengo la tarea de reescribir una guía de usuario completa que no se ha actualizado durante años en una empresa y soy el único redactor técnico del equipo. Solo se enviaron notas de lanzamiento durante todos estos años. La empresa adopta el proceso de desarrollo ágil y un sprint suele durar tres semanas.
He estado pensando cómo debería abordar esta tarea. ¿Debería estar escribiendo la guía usando lo que esté en el sistema al momento de escribirla, luego, cuando todas las secciones estén completas, incorpore lo que faltó en las notas de la versión? ¿O debería escribir primero las secciones involucradas en los sprints y luego trabajar en otras secciones cuando esté libre? ¿Hay otros enfoques mejores?
He escrito manuales bajo un proceso Scrum, así que describiré lo que funcionó para mi equipo.
Voy a tratar tu tarea como si estuvieras escribiendo un nuevo libro. Según su descripción, estaría reemplazando la gran mayoría del contenido de todos modos, por lo que es mejor pensar en él como un libro nuevo (para el cual podría aprovechar el bit ocasional escrito previamente) que una actualización.
Primero tendrá que idear un esquema o plan de ataque amplio. ¿Qué temas necesita cubrir (en qué detalle)? ¿La organización del libro original funciona ahora o necesita reorganizar las cosas? En (¡o antes de!) tu primer sprint, elabora tu lista inicial de trabajo por hacer. Empieza a pensar en cómo se descompone en historias. (Este es el backlog inicial; debe esperar descubrir más cosas que deberán cubrirse a medida que avanzan los sprints. Use su proceso habitual para administrarlos; en nuestro caso, los problemas recién descubiertos se agregaron al backlog y se consideraron en la siguiente planificación). sesión.)
Durante la planificación del sprint, usted (plural) debe identificar en cuál de estas tareas trabajar ahora, debido a la urgencia, la estabilidad del código o cualquier otro criterio que esté en juego en su equipo.
Durante cada sprint deberías estar trabajando en los siguientes tipos de tareas:
Escribir material nuevo (alcance para adaptarse al sprint, menos el otro trabajo que debe hacer en este sprint)
Abordar los comentarios de lo que escribió en el último sprint (debería recibir comentarios de los desarrolladores, evaluadores y representantes de los usuarios a medida que avanza)
Actualizar el trabajo anterior para los cambios en el código, si corresponde; si está trabajando en el documento junto con los desarrolladores que trabajan en el código, probablemente habrá cambios que deberá abordar.
Durante los últimos sprints antes del lanzamiento, comience a pensar en lo que deberá incluirse en las notas de lanzamiento. Supongo que las notas de la versión son un proyecto de equipo, ya que generalmente incluyen cosas como una lista de errores del control de calidad. Su parte de esto es identificar lo que es lo suficientemente importante para documentar que no se incluirá en la guía del usuario, y luego descubrir cómo abordarlo en las notas de la versión. Esto debería dar como resultado una historia para su último sprint, con el equipo acordando las tareas que se incluirán.
(Debo mencionar que en mi último equipo ágil, las notas de la versión en realidad fueron administradas por el equipo de control de calidad, no por los escritores técnicos, por lo que mi consejo sobre ese punto se basa en lo que he visto/escuché hacer a otros, no en información personal directa). experiencia.)
SF.
Adiós intercambio de pila
Jaime
Jaspe