¿Cómo planifica el mantenimiento después de un proyecto Scrum?

Algunas de las cosas que esperas que hagan pueden no ser tan esenciales como crees.

Estás operando bajo un paradigma diferente ahora. Sin conocer más detalles, es difícil juzgar cuánto se debe su reacción a un enfoque completamente diferente y cuánto se debe a prácticas realmente insostenibles.

• Especificaciones : la comprensión compartida es más importante que las especificaciones extensas. Me encontré con este problema en mi último proyecto. Especificaciones muy detalladas que se refinaron diligentemente desde los requisitos del usuario hasta las especificaciones de diseño. Pero finalmente, al final del proyecto, nos dimos cuenta de que el PO entendió A, el PM entendió B y el desarrollador implementó C. Si su equipo logra evitar esto, entonces el nivel de especificación que crea su equipo con sus historias de usuario probablemente sea suficiente. Los criterios de aceptación claros y comprobables para una historia pueden ser beneficiosos, pero el juez final de su programa será el cliente. Nada supera eso.
• diseño : el diseño inicial a menudo no cumple con YAGNI y los planes para características que nunca podrían llegar (especialmente en un entorno ágil). Pero nuevamente, su publicación no está clara si no les preocupa el diseño y la estructura o si solo la están creando a medida que se hace necesario. ¿Se habla alguna vez de diseños? ¿Las personas están refactorizando el diseño cuando se implementan nuevas características?
• documentación : el código fuente no debería tener que depender de documentación externa para ser comprensible. ¿Tu equipo tiene en mente la complejidad del código? ¿Las variables y los nombres de funciones son expresivos? ¿Tiene pruebas automatizadas? Si lo hace, entonces probablemente no sean imprudentes en su enfoque.
• diseño de la base de datos : si su base de datos se puede generar a partir de su código, entonces podría decirse que su código ES el diseño de la base de datos. Es probable que la base de datos en este escenario no sea más que una capa de persistencia tonta. Si hubiera decidido serializar todos los datos en archivos xml en lugar de usar los mecanismos predeterminados de su marco, probablemente no esperaría una documentación detallada del formato de archivo.

Más atención a la mantenibilidad podría ser buena para ellos

Sus preocupaciones son saludables y valiosas. Si no está seguro acerca de la mantenibilidad a largo plazo de su código fuente, debe investigar. Como vienes de una mentalidad muy diferente, primero debes aprender la mentalidad que existe en tu equipo actual. Pregunte a sus compañeros de trabajo cómo están abordando la deuda tecnológica y la mantenibilidad. Pero aborda esta conversación desde una posición de "Quiero aprender cómo funciona tu manera" y no "lo estás haciendo diferente/mal".

Luego, si, después de comprender su enfoque, aún no está convencido de que su camino sea seguro, sugiera mejoras (la retrospectiva sería un buen lugar)

Hay mucho que analizar aquí. TLDR; Concéntrese en lo que es importante (código mantenible), en lugar de saltar a una causa raíz supuesta/no verificada (falta de documentación).

Perspectiva

Primero, y quizás lo más importante, es su perspectiva. Por el tono de su pregunta, me parece que no solo no está familiarizado con Scrum, sino que lo menosprecia. Si llega a un proyecto de Scrum con la mentalidad de "¿Cómo puedo solucionar este desagradable problema de Scrum?", fracasará . No se preocupe demasiado por lo que Scrum no hace y, en su lugar, concéntrese en aprender cómo se supone que funciona Scrum.

Documentación

Del Manifiesto Ágil:

Software de trabajo sobre documentación completa

Esto significa, esencialmente, dos cosas. Primero, esa documentación es importante (más sobre eso a continuación). En segundo lugar, que el software que funcione es más importante.

Señala la falta de una especificación de requisitos de software o un diseño detallado. Para mí, esta falta es algo bueno . Gastar demasiado esfuerzo en el diseño inicial tiene dos efectos secundarios. En primer lugar, dedica más tiempo y esfuerzo al diseño y la documentación en lugar de escribir código. En segundo lugar, encierra al equipo en una mentalidad particular, que en casi todos los casos será incorrecta, se volverá incorrecta a medida que cambien los requisitos, o ambas cosas, lo que hará que el equipo sea menos capaz de responder a los cambios y actualizaciones de su código. Ellos siempre, en el fondo de sus mentes, estarán tratando de 'apegarse al plan'. Ambos dañarán la capacidad del equipo para crear software que funcione, lo que, nuevamente, según el Manifiesto Ágil, es más importante que la documentación.

Código primero

Con respecto al enfoque de código primero (frente a un enfoque de base de datos primero, o un enfoque en el que ambos se diseñan por separado y luego se conectan de alguna manera), esa es una pregunta completamente separada que está fuera del alcance de PMSE. Baste decir que hay, al menos, muchas personas que lo consideran un enfoque válido.

Historias de usuarios

Mencionas

Solo crean algunas historias de usuario.

lo que me parece que no comprende el propósito de las historias de usuario o que su equipo no las está utilizando correctamente. Las historias de usuario son una forma de documentación (viva). Años más tarde, al tratar de averiguar por qué se escribió un fragmento de código, debería poder pasar del código a su historia de usuario correspondiente y verlo allí. Si no puede, entonces ese es un problema que debe abordarse.

Un enfoque que he visto que funciona bien es:

1. Guarde todas las Historias de usuario, cada una con una clave única para una fácil búsqueda futura.
2. Incluya esa clave única en el mensaje de confirmación de cualquier código relacionado con esa historia de usuario.

¿Cómo mantener el código más tarde?

La mejor manera de poder mantener el código en el futuro es escribir código mantenible . Eso parece una tautología, pero hay otros enfoques (como la documentación completa) que algunos (en mi opinión, erróneamente) consideran más importantes.

Hay varias formas de lograr esto: revisión de código, programación en pareja, mejor contratación, capacitación y cultura para obtener/crear/retener mejores programadores, asistencia tecnológica (como un StyleCop de algún tipo).

Conclusión

Al final, asegúrese de concentrarse en los problemas correctos. En lugar de centrarse en la falta de documentación de Scrum, céntrese en los objetivos de Scrum y Agile. Estos incluyen mejorar la calidad de las personas y sus interacciones, escribir software que funcione, mejorar la colaboración con el cliente, responder al cambio, así como los diversos objetivos de Scrum; consulte la Guía de Scrum . Si estos objetivos no se cumplen, concéntrese en eso , incluido primero tratar de encontrar la causa, en lugar de suponer automáticamente que conoce la causa (por ejemplo, falta de documentación). Si tiene un objetivo que no se alinea con los objetivos de Agile y Scrum, primero pregúntese qué necesita realmente el proyecto.eso. En algunos casos, lo hace (y, por lo tanto, Agile/Scrum no son adecuados para ese proyecto). En muchos casos, no lo hace.

Dejar código compatible es tan importante para un equipo Agile como para un equipo de desarrollo tradicional.

Es más sencillo describir lo que un equipo Agile intentaría evitar:

• No escriba documentación solo porque es lo que está 'hecho', es decir, solo escriba documentación que sepa que será valiosa para las personas que respaldan el código en el futuro.
• Evite la documentación que es difícil de mantener o que puede quedar obsoleta rápidamente.
• Mantenga el diseño del código (y de la base de datos) lo más simple y legible posible.

También puede considerar el uso de técnicas de autodocumentación, como el desarrollo impulsado por el comportamiento (BDD) . Esta es una excelente manera de integrar el diseño de requisitos en la base del código.

Otro enfoque importante es mantener un alto nivel de cobertura de prueba de regresión automatizada. Esto es importante ya que les dará a los desarrolladores que trabajan en el código en el futuro la confianza para hacer cambios, sabiendo que no han roto ninguna funcionalidad existente.