División de historias-b-agile

Por lo tanto, es más o menos una cuestión de gusto si prefiere un diagrama de caso de uso gráfico o una lista de historias de usuario (textuales).

Permítanme resumir la discusión sobre los requisitos de estructuración en grande: Independientemente de la notación, una descomposición de un gran problema en un proceso desencadenado externamente es la forma más neutral de lograr este desglose. NO se basa en ninguna estructura interna de los sistemas (ni en sus funciones ,ni en sus subsistemas, ni en sus objetos).,,), pero exclusivamente sobre las necesidades del medio ambiente.

Esto no quiere decir que las otras estrategias de descomposición mencionadas anteriormente no funcionen, sino solo una sugerencia para no atascarse en discusiones estructurales internas.

Dividir en el pequeño

Como puede ver en el simple ejemplo del sistema de navegación anterior a este proceso (independientemente de la notación que prefiera) parece ser demasiado complejo para implementarse en una iteración. Definitivamente necesitas dividirlo en trozos más pequeños. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) sugirió muchas formas de abordar trozos más grandes y dividirlos en historias lo suficientemente pequeñas para una iteración.

Mientras que los métodos clásicos sugerían principalmente comprender mejor un proceso complejo observando su secuencia de pasos, ahora nos enfrentamos a un problema adicional en el mundo ágil: queremos crear valor en cada iteración, es decir, crear incrementos de producto potencialmente transportables. No es suficiente descomponer un proceso grande (un caso de uso o una historia grande) para entenderlo mejor. Después de la descomposición, cada una de las partes aún debe entregar algún valor al usuario independientemente de las otras partes.

Esto inhibe las divisiones técnicas, como la división en sus capas técnicas, como la interfaz de usuario, la funcionalidad del dominio y la capa de persistencia, ya que implementar primero la capa de persistencia (es decir, crear algunas tablas de base de datos) no ofrece ningún valor comercial hasta que puede llenarlas y mostrarlas. Lo mismo ocurre a menudo con la descomposición pura de los procesos de negocio en sus pasos: implementar solo el paso 7 de un proceso complejo puede no ofrecer ningún valor mientras los pasos predecesor y sucesor no estén allí.

(Solo un interesante comentario histórico sobre las guerras de terminología entre metodólogos: Mike Cohn se quejó de que las historias de usuario no son casos de uso simplemente usando el argumento: pueden ser demasiado grandes para implementarlas en una iteración. Ivar Jacobson aceptó ese argumento sobre el tamaño, pero retrocedió al afirmar que las “secciones de casos de uso” son una forma mucho mejor de pensar que trabajar con historias de usuario lo suficientemente pequeñas, ya que las secciones de casos de uso ofrecen un valor de extremo a extremo.)