Historias del sistema para arquitectura ágil

Question

Al tratar de aplicar principios ágiles a nuestro proceso de desarrollo, en particular los principios scrum y las historias de usuario similares a XP, enfrentamos un problema acerca de la arquitectura.

Tal vez todavía estamos demasiado vinculados al desarrollo centrado en la arquitectura, sin embargo, estamos tratando de mantener un fuerte desarrollo basado en componentes, combinado con los principios de modelado ágil. Nuestro objetivo es tener un diseño pequeño por adelantado, propenso a evoluciones durante el desarrollo.

Lo que estoy buscando es algo que me podría permitir ubicar en mis historias de retraso acumulado historias sobre mi arquitectura y los componentes dentro de ella: historias de desarrollo, no solo historias de uso. La historia del sistema podría ser un tipo diferente de historia del usuario, que dice algo que no está estrictamente relacionado con el valor comercial, sino que está relacionado con la arquitectura y las preocupaciones de calidad de un sistema.

Editar: encontré this research de la Universidad de Aalborg sobre "historias desarrollador".

¿Tiene alguna experiencia, idea u oposición?

¡Gracias de antemano! (esta es mi primera pregunta!: D)

Answer 1

OMI un retraso debe no incluir desarrollador cuentos. No hay forma de que un Propietario de Producto pueda priorizar sensiblemente estos junto con la funcionalidad comercial. ¿Y qué sucede si el Propietario del producto considera que uno de ellos no es importante y, por lo tanto, lo retira de la cartera de pedidos? Si el equipo insiste en mantener la historia, usted se encuentra en una situación en la que la titularidad de la acumulación no está clara.

Sin embargo, definitivamente creo que el equipo necesita construir arquitectura desde el principio del proyecto. Un problema en mi proyecto fue que nos enfocamos demasiado en la funcionalidad en los primeros sprints.

Pensemos en la "deuda arquitectónica" (similar a la deuda técnica) como el tiempo que debe dedicarse a la construcción de infraestructura y arquitectura. A diferencia de la deuda técnica (que comienza en cero y se acumula a medida que el equipo produce funcionalidad sin la refactorización adecuada), un equipo comienza con con deuda arquitectónica y debe trabajar para reducirla. El tiempo dedicado a reducir la deuda arquitectónica significa que se gasta menos tiempo en producir la funcionalidad, es decir,una velocidad de equipo menor y una salida de velocidad reducida. De esta manera, la deuda arquitectónica es similar a la deuda técnica. Si surgieran requisitos que no se ajustaban a la arquitectura actual, entonces el nivel de la deuda arquitectónica aumentaría.

Tenga en cuenta que el equipo debe decidir (y poder justificar ante el propietario del producto) cómo van a pasar su tiempo. Y para que puedan dividir su esfuerzo entre la funcionalidad, la deuda técnica y la deuda arquitectónica como mejor les parezca.

Sin embargo, el trabajo en arquitectura aún debería ser impulsado por la funcionalidad. En otras palabras, el equipo debe construir infraestructura para respaldar y habilitar una historia de usuario en particular. No solo porque creen que será útil en el futuro. The YAGNI principle se aplica a ese tipo de enfoque.

Answer 2

Se aplica mi respuesta here.

Existe un equilibrio muy desafiante entre hacer trabajos de arquitectura y más trabajos específicos. Técnicamente, ambos son enfoques y trabajos válidos, pero cuanto más demore una cantidad de producto utilizable (resultados de carrera) mayor será el riesgo de que no esté creando el producto correcto (requisitos del usuario, requisitos de rendimiento, etc.). Tan pronto como sea posible, llegue a un punto en el que pueda realizar pruebas de nivel del sistema para comprobar que su producto funciona y puede demostrar el valor y la dirección del producto con los interesados.

Answer 3

Es tan simple como poner un Asegúrese de que el componente de registro puede ser probado desconectada de todos los demás componentes 'usuario' historia, su cartera de pedidos del sistema DEBE tener/Desarrollo-historias, siempre y cuando se sync'ed con el deseo del dueño del producto de dicha implementación.

Esta es la forma en que suele poner los requisitos no funcionales en una cartera de pedidos, así como "El modelo de dominio tiene que ejecutarse en un centro de datos diferente bajo el balanceo de carga", etc.

Answer 4

Una de las lentes que me parece útil para llevar en las historias de desarrollador es pensar en quién es el "usuario" de una historia determinada. El hecho de que no esté escribiendo una característica que será vista por personas ajenas a su empresa no significa que no haya un usuario para esa tarea. Puede escribir código para un equipo en el pasillo. En algunos casos, el usuario es usted mismo. Este es a menudo el caso de las historias de desarrolladores. Piense "Como desarrollador, tengo una arquitectura escalable para que pueda agregar nuevas funcionalidades fácilmente". Al llamar al usuario en particular, le da al propietario del producto una idea de quién verá el valor de la historia. Y señalar el "por qué" también es útil para transmitir qué beneficio espera alcanzar la historia. Como otros lo han mencionado, la gestión del retraso se reduce a una negociación entre el propietario del producto y el equipo. Y, como siempre, debe determinar qué funciona mejor para su equipo, independientemente del dogma del proceso. Cada equipo tiene una situación diferente, y las ideas que funcionan bien para un equipo no siempre se traducen en otra.

Answer 5

En nuestro equipo lo llamamos "tarjetas de TI", que son tarjetas de la forma: "Como desarrollador, quiero refactorizar el componente xyz. Para reducir el costo de mantenimiento y aumentar la flexibilidad".

Los miembros del equipo son libres de elegir cualquier tarjeta de TI que consideren importante en lugar de mostrar una "Tarjeta de características" de la cartera de pedidos priorizada.

Creo que este enfoque funciona razonablemente bien para mantener la deuda técnica en un nivel aceptable y permitir un ritmo saludable de innovación.

Sin embargo, me pareció un poco deficiente como medio de rediseñar el sistema. Es difícil justificar las largas desviaciones del flujo de producción de características.

Mientras escribo esto, estoy pensando en que uno podría acercarse a la arquitectura con las historias. Identifica los objetivos arquitectónicos con épicas que desglosas en un tema para enfocarte.