¿Cómo deberían encajar los escritores técnicos dentro de un equipo Scrum?

Creo que mi empresa podría beneficiarse al agregar un redactor técnico al equipo; asegurándonos de que nuestra producción sea unificada y de alta calidad. Para nuestro proyecto actual, necesitamos producir una variedad de documentos, tanto internos como externos, con una variedad de profundidad técnica.

¿Dónde deberían posicionarse estas personas en un equipo Scrum? En nuestro proyecto actual, hemos empujado la documentación (aparte de los detalles técnicos profundos) hasta el final de nuestros sprints. ¿Es este un plan sensato?

No es necesario que tenga un escritor técnico dedicado si el resto de su equipo puede cubrir ese rol. Sin embargo, si incluye uno (o más), vea mi respuesta detallada a continuación sobre cómo deberían encajar.
Edité su pregunta ligeramente para que el resumen se ajuste al cuerpo de su pregunta. Si no he capturado completamente su intención, siéntase libre de editar más.

Respuestas (1)

TL;DR

En nuestro proyecto actual, hemos empujado la documentación (aparte de los detalles técnicos profundos) hasta el final de nuestros sprints. ¿Es este un plan sensato?

No.

Redacción técnica para equipos ágiles

Los valores ágiles de Maifesto:

Software funcional sobre documentación completa...[E]aquí hay valor en los elementos de la derecha, [pero] valoramos más los elementos de la izquierda.

Entonces, ¿qué significa eso para los redactores técnicos en un equipo multifuncional? En mi experiencia significa:

  1. La documentación adecuada (lo que sea que eso signifique para el equipo/proyecto) debe ser parte de la Definición de Terminado.
  2. El código debe ser lo más autodocumentado posible.
  3. Los conjuntos de pruebas deben funcionar como documentación técnica en la mayor medida posible.
  4. Los redactores técnicos deben participar en la planificación de Sprint para identificar historias y tareas en las que se pueda necesitar documentación adicional.
  5. Los escritores técnicos deben participar durante todo el sprint para coordinarse con los desarrolladores y evaluadores para asegurarse de que el equipo se comunique y coordine los requisitos de documentación y los entregables que deben incluirse en la iteración.
  6. Cualquier cosa que necesite documentación debe diseñarse y desarrollarse teniendo en cuenta la documentación, en lugar de tratar la documentación como un complemento de última hora.

Los redactores técnicos son miembros de pleno derecho del equipo

Ningún miembro del equipo debe ser un ciudadano de segunda clase. Reduce la cohesión y la eficiencia del equipo tratar a los redactores técnicos como algo más que miembros integrales de un equipo multifuncional.

Además de la dinámica social y los requisitos del marco, tratar a los escritores técnicos como ciudadanos de primera clase garantiza que:

  1. Las tareas de documentación se incluirán en su proceso.
  2. La transferencia de conocimientos entre codificadores, evaluadores y escritores será un flujo constante de gran ancho de banda, en lugar de una serie de entrevistas de última hora donde la falta de conocimiento del dominio empañará los resultados.

  3. Los individuos tienen la oportunidad de convertirse en multifuncionales, no solo el equipo.

    • Los desarrolladores deberían aprender algo sobre pruebas y escritura.
    • Los evaluadores deben aprender algo sobre el desarrollo y la escritura.
    • Los escritores técnicos deben aprender lo suficiente sobre las disciplinas técnicas para poder hacer preguntas significativas cuando el código o las pruebas de "autodocumentación" simplemente no lo son .

Si descubre que necesita escritores técnicos para garantizar el éxito de su proyecto, entonces pertenecen al equipo como colaboradores valiosos y esenciales y deben intercalarse a lo largo de sus procesos iterativos. Una vez que haya tomado la decisión de incluir escritores técnicos en el equipo, su inclusión dentro del grupo central es un área en la que su millaje no debería variar.

Esto parece abordar el mismo punto que el Manifiesto Ágil: documentación para otros desarrolladores sobre los requisitos, el diseño, la implementación y las pruebas. En mi experiencia, los escritores técnicos escriben documentación orientada al usuario (manuales de usuario, instrucciones de instalación, instrucciones de implementación). Algunos de estos puntos pueden ser relevantes (como definir la documentación en la definición de hecho, la participación de los escritores en la planificación del sprint, incorporar documentación al proceso), pero otros parecen no serlo. Mi interpretación de la pregunta es que la atención se centra en los escritores de documentos orientados al usuario.
@ThomasOwens Estás malinterpretando la Definición de Listo en este contexto. Si agrega la función foo , entonces la Definición de Hecho debería requerir un capítulo orientado al usuario en el manual sobre cómo usar esta nueva e increíble función foo . Lanzar esto "por encima de la pared" al escritor técnico al final del sprint rara vez es la mejor manera de proporcionar el tiempo o la información técnica adecuados para escribir una documentación efectiva. Segregar la documentación que le importa al equipo del proyecto de la documentación que los usuarios finales pueden necesitar crea un riesgo de proyecto innecesario. YMMV.
Estoy de acuerdo con eso, pero los escritores técnicos (a menos que también tengan experiencia en el desarrollo de software) no podrán usar código (independientemente de cuán autodocumentado sea) o pruebas unitarias como parte de su proceso de documentación. Además, dependiendo de su familiaridad con el sistema, es posible que no sepan hasta qué punto una historia de usuario conducirá a cambios o nuevas partes de los documentos (e incluso el equipo puede no saberlo, hasta después de que se haya diseñado).
Estoy interesado en obtener más información sobre los segundos puntos 2 y 3 (en la sección "Los escritores técnicos son miembros de pleno derecho del equipo"), que son cruciales pero solo obtienen algunas oraciones en esta respuesta, especialmente con respecto a corto ( 2-3 semanas) sprints. También tratando con 4 y 5 en la sección "Redacción técnica para equipos ágiles". He trabajado antes en equipos Scrum, y la integración de entidades no técnicas/no usuarios/no clientes siempre ha sido problemática. ¿Cómo maneja estas 4 cosas en Scrum (especialmente cuando se mantiene un sprint de alta velocidad y corto tiempo)?
@ThomasOwens Ha pasado de la aclaración a hacer una serie de preguntas fundamentalmente diferentes. Son buenas preguntas, así que te animo a que las hagas como preguntas nuevas o las muevas al chat.
No son diferentes. Te estoy pidiendo que desarrolles algunos puntos. Por ejemplo, usted dice que "la transferencia de conocimiento entre codificadores, evaluadores y escritores será un flujo constante de gran ancho de banda". Estoy completamente de acuerdo y experimenté esto. ¿Cómo gestionas esto en un entorno Scrum? Nunca experimenté una buena manera de hacer esto en sprints de 2 semanas sin reducir significativamente la velocidad. Lo mismo ocurre con la participación de los escritores cuando (todavía) no tienen experiencia en el dominio o en un producto (similar). Usted dice un buen conjunto de cosas que hacer, pero no da idea de cómo implementarlas razonablemente dentro del contexto de Scrum.
@ThomasOwens usted dice, "la integración de entidades no técnicas/no usuarios/no clientes siempre ha sido problemática", pero no entiendo lo que quiere decir. Los he integrado de la misma manera que he integrado a cualquier otra persona. Tengo experiencia con varios artistas de diferentes disciplinas, diseñadores, analistas de negocios, traductores. Cada historia de usuario debe generar tareas para las que sea más adecuado completarlas. Hacen esas tareas justo a tiempo para que el desarrollador las use. Muchos tienen habilidades especializadas, pero ¿no es lo mismo que algunos desarrolladores? Algunos desarrolladores son más adecuados para diferentes tareas de programación.
@CodeGnome gracias por sus esfuerzos. Mi preocupación acerca de involucrar a los escritores de tecnología en el sprint es el posible esfuerzo desperdiciado que podría resultar. En nuestro caso, estamos creando flujos de procesos comerciales complejos para una solución ERP. Los muchachos que irán al sitio e implementarán estos sistemas tendrán que administrar la configuración, que es muy compleja y es un desafío para documentar . Si bien el código/las pruebas se "autodocumentan" hasta cierto punto, la capacidad de cambiar drásticamente el flujo del proceso en el código es fácil; sin embargo, hacer esto podría invalidar una gran cantidad de trabajo ya producido por el escritor técnico.
¿Cómo deberían encajar los escritores técnicos dentro de un equipo Scrum?
RespuestasAquíPolítica de privacidad1y, 0v