Cada una de nuestras versiones de software va acompañada de un conjunto de notas de la versión, que incluyen breves descripciones de lo siguiente: nuevas funciones, cambios importantes o importantes en funciones antiguas y correcciones de errores importantes. Las nuevas características son bastante fáciles; la gente sabe lo que está pasando allí. Nuestro desafío es con los otros dos, que se reducen a cambios.
La forma en que este documento se compila ahora es algo como esto:
Los errores, cuando se crean o en cualquier momento posterior, pueden o no anotarse con "afecta al documento".
Hacia el final del ciclo, el escritor asignado consulta todos esos errores y comienza a preguntar sobre otras cosas que deben mencionarse.
En muchos casos, el contenido del error (descripción o corrección) no es lo suficientemente esclarecedor para dicho escritor asignado, quien luego comienza a pedir aclaraciones a las personas involucradas.
El escritor hace su mejor esfuerzo y envía un borrador para su revisión. Las iteraciones suceden.
Ahora casi nunca puede tomar algo directamente del error porque, bueno, los errores los escriben los desarrolladores que hablan con otros desarrolladores y no están destinados a estar orientados al usuario. Un escritor suficientemente técnico puede traducir uno a otro, pero no todas las tiendas los tienen (y si los tienen, probablemente estén escribiendo otros documentos; las notas de publicación tienden a recaer en escritores más jóvenes). Muchos desarrolladores podrían escribir notas publicitarias razonables para las notas de la versión (no son obras de arte), pero necesitan pensar en eso como una tarea separada.
Entonces, con todo eso como trasfondo, mi pregunta es: ¿cómo podemos mejorar nuestro flujo de trabajo para producir notas de lanzamiento decentes más fácilmente, con menos ida y vuelta y menos búsqueda del tesoro?
La idea de dejar que los desarrolladores escriban las notas se hará añicos en el precipicio de la realidad. La mayoría de los desarrolladores no quieren escribirlos, por lo que incluso si los fuerza de alguna manera, solo obtendrá un lío y no una nota. Solo para que conste: soy un desarrollador.
Lo que puede hacer es simplemente mejorar un poco su flujo de trabajo existente. Un poco a menudo hace maravillas y, de todos modos, nunca obtendrá un flujo de trabajo perfecto.
Lo que significa que siempre habrá ida y vuelta, eso ya lo sabes. Así que los mejores flujos de trabajo están automatizados, porque se saltan ese maldito factor humano. Trate de automatizar tanto como sea posible. (Nunca envíe a un humano a hacer el trabajo de una máquina).
"anotar con 'afecta documentos'" - sáltate eso. Eso es depender de los humanos y, por lo tanto, es propenso a errores. Apuesto a que tienes un nivel de prioridad en los errores. Defina que los errores de los dos niveles superiores se anotan automáticamente con "afectar documentos". ¿De verdad te preocupas por los demás? Los desarrolladores no.
"Hacia el final del ciclo..." - ¡Ay! Sabes lo que sucede si cambias una tarea al final de un ciclo, entonces, ¿por qué lo haces? Obtiene la lista de errores relevantes ahora automáticamente. Tenga una reunión (real, no aburrida) cada semana, cada dos semanas, lo que sea, con el líder del proyecto. Revise la lista, haga sus preguntas, obtenga respuestas.
"... no es lo suficientemente esclarecedor": si las cosas aún no están claras (dentro de ese ritmo de una o dos semanas), pregunte a los desarrolladores. Nunca puedes evitar hablarle a esa pésima manada de vez en cuando. Es una pena.
"Las iteraciones suceden": el desarrollo es iteración. Por su misma definición. Nunca te librarás de eso. Abrázalo. Es una cura, no una enfermedad.
En primer lugar, los no escritores técnicos son mejores escritores técnicos que los escritores no técnicos. Por lo general, pueden escribir de una manera comprensible para los legos y objetivamente correcta (a diferencia de los escritores no técnicos que a menudo escriben algo perfectamente claro, pero completamente incorrecto), solo necesitan que se les pida que lo hagan, no lo harán. , si no saben que deben!
En lugar de que personas sin conocimientos técnicos ensamblen las notas, haga que personas técnicas se encarguen de ensamblarlas de una manera relativamente fácil de leer. Mejor, si todos en el equipo escribieran notas breves sobre todo lo que hicieron en persona, cada error que archivaron, y se les pidiera que lo explicaran de una manera relativamente no técnica (típico de las notas de lanzamiento: saben qué son las notas de lanzamiento). Son 10 minutos de trabajo al mes, y tienes un buen anteproyecto casi completo.
Solo entonces haga que el escritor no técnico edite el borrador, haciéndolo bonito, corrigiendo errores o suavizando el lenguaje aún demasiado técnico. Si algo es difícil de entender, consulte, realice el ida y vuelta habitual, pero el número de estos casos debería reducirse a 2-3 por iteración de docenas. Simplemente, en lugar de pedirles a los escritores no técnicos que atraviesen el abismo para llegar a los profesionales, pídales que se encuentren a mitad de camino; esencialmente, todos se convierten en escritores, pero usted está obteniendo un buen editor.
La compilación de notas de la versión NO es el trabajo de un solo autor. Idealmente, es parte integrante de su sistema de gestión de proyectos y control de código fuente. Sus desarrolladores tendrían un conjunto de pruebas automatizadas para todos los errores informados y características documentadas, y cualquier cambio necesario requeriría un cambio en dicha prueba, que podría notar automáticamente un cambio en las notas de la versión.
Considere, por cierto, cómo dos juegos hacen sus notas de lanzamiento.
Estoy en una empresa diferente ahora que cuando hice esta pregunta, pero la nueva también tenía el problema de las notas de la versión. Así es como lo resolvimos (a instancias del doctor):
Cuando se presenta un error, si es un informe del cliente o está orientado al cliente, se marca la casilla "necesita una nota de publicación". (Hay un equipo de clasificación que los revisa y podría cambiar esto, pero este es el punto de partida).
Cuando un desarrollador corrige un error, si ese campo está marcado, escribe una breve nota de lanzamiento allí mismo en el error (hay un campo para ello). Razonamiento: simplemente lo arregló; este es el mejor momento para capturar cuál era el problema.
El control de calidad revisa/actualiza la nota de la versión como parte de la verificación de errores. (Los desarrolladores a veces escriben descripciones "internas", como que el problema fue que tal o cual mutex se retuvo demasiado tiempo en lugar de decir que algo se congeló; los evaluadores saben qué síntomas y cambios están buscando y pueden verificar, por lo que ellos pueden arreglar algo de esto.)
Cerca del lanzamiento, la gente en doc los revisa todos para asegurarse de que tengan un inglés coherente. (Hay un informe para encontrarlos a todos; es el mismo informe que se incluye en el documento final).
Obviamente, si alguien decide tarde en el proceso que ese error necesita una nota de lanzamiento después de todo, esto falla. Pero para los que sabemos que necesitarán (o probablemente necesitarán) una nota de lanzamiento, tratamos de capturar la información lo antes posible y mejorarla a medida que avanzamos. El costo incremental para el desarrollador en el momento de corregir el error es muy bajo, mientras que el costo para cualquiera que intente resolverlo semanas después es mucho mayor.