¿Cuánta documentación de código debe producir un Scrum Team efectivo?

No puede haber una respuesta general a esto. Las empresas multinacionales o públicas varían mucho. El software desarrollado por dichas empresas varía aún más en tamaño, tipo, propósito, uso, esperanza de vida, etc. En general, cuanto más grande, más tiempo se usa y se mantiene, más complejo es el software y más personas están involucradas (al mismo tiempo y /o a largo plazo), y cuanto más regulado esté el dominio, más documentación requiere.

El nuevo Scrum Master se opuso a cualquier documentación.

... lo que suena un poco exagerado para mí. Es muy probable que todas estas personas puedan citar de memoria las partes relevantes del Manifiesto Ágil :

[...] que hemos llegado a valorar: [...] Software funcional sobre documentación completa [...]

Sin embargo, a menudo se olvidan de citar esto:

Es decir, mientras hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Tu dices

parece que nos hemos decidido por documentar cualquier aspecto que tenga el riesgo de impactar en la dependencia de otro departamento.

(En resumen, si rompen algo que no es suyo, tienen alguna documentación para respaldar el proceso, la intención y el razonamiento).

lo que me suena a un enfoque pragmático, el mismo que yo seguiría. De hecho, no tiene ningún valor producir documentación simplemente porque sí, pero siempre que las partes interesadas soliciten documentación y/o se identifique un problema derivado de una documentación inadecuada o desactualizada, el equipo Scrum debe abordarlo. Por supuesto, la conversación cara a cara es más efectiva en muchos niveles que la documentación escrita; sin embargo, dura sólo mientras la memoria de los participantes, y no es factible en algunos casos (por ejemplo, equipos distribuidos). Siempre que necesitamos rastros más duraderos y/o más transferibles de las cosas, necesitamos documentarlos.

La principal refutación contra la documentación en profundidad fue que

• Debe tenerse en cuenta como una historia de usuario y recibir un valor en puntos (que acepto)
• Arruina el flujo de trabajo de los desarrolladores (también aceptado)

Bueno, también se puede decir que las pruebas arruinan el flujo de trabajo de los desarrolladores. Además de las pausas para el almuerzo ;-P

Tenga en cuenta que cualquier cosa a la que uno no esté acostumbrado, tiende a romper el flujo. Una vez que nos acostumbremos y ganemos experiencia, se volverá parte del flujo.

• La documentación está desactualizada dentro de una semana debido a cambios/mejoras en el código, etc. (que no acepto por completo)

De hecho, es un riesgo, pero depende completamente de lo que esté documentado. No documente los detalles de bajo nivel del código que pueden cambiar la próxima semana, sino los aspectos de nivel superior (arquitectura, decisiones de diseño, patrones utilizados, interfaces, etc.) que no tienden a cambiar tan a menudo y/o no están directamente presentes dentro del código, pero son cruciales, por ejemplo, para que una persona externa o un nuevo miembro del equipo obtenga rápidamente una imagen general del sistema.

• La documentación está contenida dentro del código (que he rechazado por completo como la peor práctica)

Depende de lo que esto signifique. Si esto significa la generación automática de documentación a partir de comentarios de código como Javadoc, está bien, aunque en mi experiencia tiene un uso limitado (excepto para las interfaces públicas). Si significa incrustar comentarios explicativos dentro del código, en mi humilde opinión, casi siempre es una mala idea (excepto en casos raros y limitados, como implementar un algoritmo específico o cambios de ajuste de rendimiento). Si significa escribir un código legible, autoexplicativo y fluido, estoy completamente de acuerdo. En mi humilde opinión, el código limpio y bien escrito rara vez necesita comentarios.

Entonces, para resumir con algunas reglas generales:

• Hable con su OP, las partes interesadas y el equipo de Scrum para averiguar quién necesita qué tipo de documentación y por qué (y si su razón es lo suficientemente buena).
• (durante, por ejemplo, revisiones y retrospectivas) Identifique cualquier problema causado por documentación faltante o inadecuada.
• Si hay una necesidad justificada, hacer el trabajo mínimo necesario para satisfacer esa necesidad. (Teniendo en cuenta la vida útil esperada de la necesidad / artefactos, es posible que desee optimizar a largo plazo, no a corto plazo. Por ejemplo, escribir un script para generar automáticamente un documento a partir de archivos de configuración es obviamente más costoso que copiarlo manualmente una vez, pero si este documento debe actualizarse cada semana durante los próximos 5 años o más, el script se amortizará rápidamente).
• Esfuércese siempre por evitar la duplicación de información tanto como sea posible. Idealmente, cada pieza de información tiene una sola fuente, por lo que si necesita una actualización, puede hacerlo una vez en la fuente. Es posible que deba replicarse / copiarse en otros lugares, pero esfuércese por resolver esto mediante la automatización en lugar del trabajo manual.
• Si (y tanto como) produce documentación, esfuércese por hacerlo en el formato más accesible y fácil de mantener (a menos, por supuesto, que sea confidencial). En mi experiencia, esto significa un wiki como Confluence que mencionaste. Puede importar documentos de Word, mantiene un historial de todos los cambios e incluso puede actualizarse automáticamente mediante scripts.
• Además, a medida que cambian los procesos y las necesidades, busque documentación obsoleta o fuera de uso y, si encuentra algo así, elimínelo.

Bueno, la respuesta es realmente "Depende" mezclado con "¿Por qué lo necesitan?" y "¿Qué es lo mínimo que puedes hacer?"

Se trata realmente de entrevistar a las partes interesadas y hacer un análisis tipo 5 por qué. Averigüe por qué necesitan algo, para que luego pueda trabajar para satisfacer esa necesidad con el mínimo trabajo de su parte o incluso no hacerlo porque no se aplica.

Solía ​​ser el líder de PMO para un grupo ágil dentro de una enorme cascada, Six-Sigma, empresa impulsada por el control de calidad. Necesitábamos poder lanzar productos de hardware al mercado a menudo en tan solo tres meses. La nave nodriza tardó de dos a tres años en lanzar un producto. Si bien la empresa principal necesitaba esos 2 o 3 años, tomamos sus productos terminados y los pusimos en nuestro producto, por lo que usamos todos los componentes terminados a los que luego agregamos software.

El proceso de cascada/calidad de la empresa principal sumó meses a nuestros proyectos. Debido a que el equipo de calidad podría impedirnos realizar envíos, no podíamos ignorar el proceso.

Programé entrevistas con las partes interesadas con todas las organizaciones con las que tocamos. Descubrí lo que necesitaban y por qué lo necesitaban. Al profundizar en el por qué, a menudo pude ver que realmente no se aplicaba a nosotros. Fue solo un proceso tan arraigado que nadie lo cuestionó. Luego pude explicar cómo funcionaban nuestros proyectos y por qué no necesitábamos cumplir con estos requisitos.

En los casos en los que teníamos que cumplir con algún requisito corporativo, el análisis de por qué nos permitió ver qué era lo mínimo que necesitábamos hacer para satisfacer.

Ah, y en algunos casos, el análisis de por qué nos mostró que aunque pensábamos que éramos especiales, en realidad no lo éramos. A veces, nuestro equipo tenía que aguantarse y darse cuenta de que teníamos que hacer todo ese trabajo porque realmente era necesario.