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.
manuals
production
Brian
fuente
fuente
Respuestas:
Actualizaría el manual:
fuente
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
fuente
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.
fuente
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:
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 .
fuente
En mi organización, generalmente tenemos 3 tipos de lanzamientos:
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.
fuente
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.
fuente