Manuales - ¿Qué tan actualizados?

Si tiene un producto que ha estado en el mercado durante mucho tiempo, pero todavía está en desarrollo activo diariamente, ¿con qué frecuencia deben actualizarse los manuales? Si sus usuarios se actualizan constantemente a la versión de vanguardia debido al hecho de que su organización considera que las últimas correcciones de errores siempre están en la versión enviada. Es decir, podría corregir un error un día y al día siguiente está llegando a la producción.

Actualizaría el manual:

1. Para cada lanzamiento principal, y
2. Cuando las nuevas características importantes se vuelven estables y maduras lo suficiente como para saber que no van a cambiar cada cinco minutos.

actualice el manual (PDF) cada vez que un cambio de código altere las instrucciones del manual, solo haga que la actualización del manual sea parte del proceso de lanzamiento

si los usuarios confían en el manual para decirles cómo usar el producto y el producto cambia, entonces es de sentido común que las secciones relevantes del manual también deberían cambiar

En 2010, ¿todavía nos referimos a la documentación impresa? ¿Por qué? ;)

Con toda seriedad, la documentación (ya sea ayuda de la aplicación "F1", PDF o documentación en línea) debe ser parte de cada versión. Cero excusas. Es así de simple "publicar". De hecho, en mi opinión, no hay excusa para no actualizar la documentación de forma regular (en línea y PDF), incluso entre versiones, tan pronto como se conozcan y corrijan los problemas. No necesita el mismo nivel de control de calidad, ni siquiera cerca.

Supongo que está hablando de la documentación del usuario final. Escribir documentación es una molestia en el @ $$ y aunque he desarrollado alguna técnica para convencerme de lo contrario, todavía tengo problemas con eso. Así es como trato de administrarlo:

Integre la actualización de la documentación en su DoD ( Definición de hecho )

Esto asegurará que su documentación estará actualizada al final de la finalización de cada historia de usuario.

Aquí está la definición de hecho que escribimos. Traté de mantener los formatos originales, así que entiendes la idea. Es una página A4 puesta en la pizarra.

---------- 8 <------------ Cortar aquí ------------ 8 <----------

Lo no negociable

Definición de "Hecho"

• Código con 80% de cobertura de prueba unitaria, comprometido en repositorio

• Capturas de pantalla si corresponde (1024x728, 395x281, 170x121 y 729x329)

• Descripciones de funciones, si corresponde (50 caracteres, 100 caracteres)

• Documentación completa del usuario final

• Qué hay de nuevo archivo actualizado correctamente

---------- 8 <------------ Cortar aquí ------------ 8 <----------

Por supuesto, puede agregar un proceso de revisión en la documentación. Tenemos eso ya que ninguno de nosotros somos hablantes nativos de inglés.

Una de las ventajas de la definición de Hecho de esta manera es que su producto es potencialmente enviable al final de la finalización de cada historia de usuario.

Use esta técnica en combinación con esta .

En mi organización, generalmente tenemos 3 tipos de lanzamientos:

1. Lanzamiento de ingeniería: básicamente una solución para un cliente específico o alguna característica que solo un cliente en particular ha solicitado de forma inmediata.
2. Lanzamiento menor: correcciones de errores, soporte incremental
3. Lanzamiento principal: soporte de nuevas funciones, etc.

Por definición, Major Release debe tener la documentación relevante en línea y fuera de línea. Nuestro sistema de seguimiento garantiza que la documentación forme parte de la lista de verificación.

Las versiones menores solo necesitan documentación sobre cualquier cosa nueva que se haya agregado a nivel de percepción del usuario. Entonces, si ha incluido otra heurística que podría reducir la complejidad del tiempo en algunos escenarios específicos, puede o no ser una llamada importante para incluirla en el pdf.

Las versiones de ingeniería podrían funcionar sin documentación. Algunas notas de uso informal deberían ser lo suficientemente buenas para comenzar.

La documentación debe estar sincronizada con cualquier software que envíe a un cliente. Cualquier otra falta de coincidencia te dará problemas. Y si no tiene un escritor en el personal, intente contratistas. Una vez que encuentre uno que le guste, manténgalo retenido.