Documentación procesos para desarrollo (programador)


(Gus) #1

Buen día.

Estamos introduciéndonos en el agilismo, más precisamente con scrum. Estamos encarando un pequeño proyecto piloto, de desarrollo de un sistema, y nos encontramos con alguna duda que nos está demorando y que no encontramos documentación de soporte.

La duda concreta es cómo se documenta, por ejemplo, un circuito administrativo con sus transacciones para que luego el desarrollador pueda escribir el código que resuelva una historia de usuario.

Me refiero a una transacción compleja que involucre impuestos, responsables, autorizaciones, maquinas de estado y motores especializados, etc etc.
Se utiliza como soporte algún diagrama de UML o BPMN?

Ojalá nos puedan dar luz sobre este aspecto que nos tiene paralizados.

Desde ya les agradezo y espero participar activamente de la comunidad.

Gracias.
Saludos.

Gustavo.


(David Lay) #2

Hola Gus.

Esta es una duda muy recurrente en los incicios en la agilidad, tener estas dudas es una buena señal, de que van en el camino correcto.

Sobre la documentación, no hay reglas en piedra. El manifiesto ágil dice “Software funcional por sobre documentación exhaustiva” y es reforzado por el principio que dicta “El software funcional es la principal medida de avance” y también por el principio que habla de “La mejor forma de traspasar información relevante del proyecto dentro del equipo es mediante conversaciones cara a cara”. Estas dos cosas llevan a pensar a mucha gente que en la agilidad se desprecia la documentación, cosa que no puede estar más lejos de lo que realmente sucede.

La documentación es critica para perdurar el conocimiento, pero solo cierta documentación, no toda la que se pueda producir. La documentación no entrega valor de por sí, por lo que hacer documentación es un desperdicio en muchos casos. Otro asunto es que la documentación no tiene porqué ser un documento o un papel. Videos, audios, imágenes, foros, wikis y postits en una pared también pueden ser formas de documentación mucho más eficientes de producir (generalmente se hacen en paralelo con la discusión) o permiten colaboración o son constantemente actualizadas (resistentes a la obsolecencia)

Si vas a hacer un diagrama en UML, no caigas en el error de usar un programa y dibujar por dos días algo que va a cambiar mañana, cuando un dibujo en pizarra hecho en conjunto con el experto en una reunión de dos horas va a ser más que suficiente (toma una foto de la pizarra y súbela a la wiki/dropbox/googledrive/onedrive/sharepoint del proyecto.

En resumen: haz lo que tengas que hacer, pero de la manera más eficiente posible para reducir el desperdicio. :wink:


(felipetv) #3

echale un vistazo a esta presentacion sobre domain-driven-design


(Gus) #4

Gracias David y Felipe!

Este es un punto en el que noto resistencia de mi parte, voy a seguir tus apreciaciones y experimentar.
Creo que la clave está en atomizar las historias de usuario como para poder describir un proceso complejo en partes para luego completarlo.

Les agradezco que hayan contestado, me quedo atento en el foro.

Creo que una vez que se adopta el agilismo no hay vuelta atrás.

Saludos.

Gus.