Principios arquitectónicos como historias de usuarios "no funcionales"

Question

Estoy a punto de iniciar un proyecto piloto en nuestra empresa para introducir prácticas ágiles, incluido el uso de historias de usuarios. Después de leer dos libros de Mike Cohn, Agile Estimating and Planning en particular y User Stories Applied, ahora tengo una idea más clara de cómo proceder. Confío en refinar nuestras técnicas junto con la práctica.

Sin embargo, hay una cosa que no me convence. In this blog post Mike Cohn define un tipo específico de historias de usuario, que llamó restricciones, que se pueden usar para definir los llamados requisitos no funcionales. Personalmente, no me gusta la palabra constraint e incluso el uso de la plantilla clásica "Como un ..., quiero ..., para que ...".

Más bien voy a intentar hacer al cliente escribir, siempre en las tarjetas, tal vez con la plantilla anterior, aquellos que Nick Rozanski y Eoin Woods, llamados en su libro fantástico Software Systems Architecture, principios de la arquitectura:

"Un Principio arquitectónico es una declaración de creencia, enfoque o intención que guía la definición de una arquitectura".

(que también se dividen estos principios en principios de negocio y principios tecnológicos, una diferenciación creo que no hay que preocuparse de.)

Lo que me gustaría hacer con estos principios tarjetas es ponerlos junto a nuestro tablero de tarjetas de trabajo atrasado para tenerlos siempre presentes durante la definición de las historias de usuario y las actividades de planificación. También alentaría a los clientes y a los desarrolladores a que los recojan y los coloquen junto a la pizarra de iteración cada vez que crean que una tarjeta podría ser útil como recordatorio para el equipo.

¿Alguna vez ha probado un enfoque similar? ¿Lo desalientas por alguna razón? ¿Tienes alguna sugerencia sobre este asunto?

Answer 1

¿Alguna vez ha probado un enfoque similar? No he probado algo exactamente similar, pero cuando era Scrum Master de mi equipo teníamos una visión y una guía arquitectónica amplia (de la que formaban parte todos los equipos), de la cual nos recordamos durante los diversos puntos de inspección y adaptación. de un Sprint y también del Proyecto Scrum, como durante las Retrospectivas, las reuniones de Sprint Planning e incluso las reuniones Daily Scrum. Algunas de las formas en que solíamos recordarnos eran agregando los criterios de finalización para las tareas que incluían un principio para seguir las pautas arquitectónicas, y también se podían agregar como una pequeña nota en las acumulaciones. En mi sugerencia a continuación, he mencionado cómo esto fue visto desde un nivel realmente alto.

¿Lo desalienta por algún motivo? No, en absoluto. Digo que tu sugerencia es buena y deberías probarla para una reunión de planificación. Y como sugirieron Ken Schwaber y Jeff Sutherland en su Scrum Guide, deberías inspeccionar y adaptarte durante los 3 puntos en un Sprint: "Hay tres puntos para la inspección y adaptación en Scrum. La reunión Daily Scrum se usa para inspeccionar el progreso hacia el Objetivo de Sprint y hacer adaptaciones que optimicen el valor del próximo día de trabajo. Además, las reuniones de Revisión y planificación de Sprint se utilizan para inspeccionar el progreso hacia la Meta de lanzamiento y para realizar adaptaciones que optimicen el valor del próximo Sprint. la Retrospectiva de Sprint se usa para revisar el pasado Sprint y determinar qué adaptaciones harán que el próximo Sprint sea más productivo, satisfactorio y agradable ".

¿Tiene alguna sugerencia sobre este asunto? ¿Es seguro para mí suponer que este proyecto 'Agile' en su empresa apenas está comenzando y que aún no tiene un proyecto sólido de visión establecido? En caso afirmativo, le sugiero que organice un taller de planificación de 2 semanas de amplia publicación. El objetivo de este taller sería obtener todas las partes interesadas, organizaciones de productores, SM y gerentes de proyecto en una sola ubicación y desarrollar una historia y visión de superusuario, y el resto de las listas acumuladas desglosadas de la historia del superusuario. La historia de superusuario sería la visión de alto nivel del objetivo del proyecto. Si ya ha hecho esto, por favor ignore esta sugerencia, PERO mi punto de plantear es que la visión de alto nivel o la historia del super usuario podría/debería tener una parte que menciona seguir el principio arquitectónico establecido en su empresa.

¿Ventajas de esto? Involucra a la parte interesada en el aspecto arquitectónico y técnico del producto directamente de la historia del Superusuario, lo que ayuda a crear una buena comprensión de la visión entre el negocio y el aspecto técnico, y uno no puede vivir sin el otro.

Es posible que intencionalmente haya intentado extender la respuesta más allá del alcance de las preguntas para que también pueda obtener algunos comentarios sobre mis ideas.

Gracias, Sid.

Answer 2

Ese fue el tema de una charla que vi en enero de este año en la Architect Factory. Lo rastreé. Fue la "Arquitectura impulsada por el negocio: un ejemplo de un inicio actual" de Lee Ingram. No puedo encontrar diapositivas, pero habló sobre la idea de los principios generales que guían cómo se deben cumplir los requisitos.

Tenía cosas como multi-tenancy y etiquetado en blanco. Con un servicio web multiusuario, debe planificar desde el principio la segregación/aislamiento de los usuarios. Del mismo modo, si desea poder etiquetar su servicio en blanco, entonces muchas cosas más deben ser configurables (estilo, etiquetas, etc.). Ambos impactan casi cada historia.

Answer 3

Recomiendo encarecidamente Jeff Patton's presentation on user story mapping.

Él no solo aclara la composición exacta de qué sirven las historias (o lo que quiera llamarlas), sino también cómo construir relaciones o dependencias entre historias y cómo lidiar con ellas.

Answer 4

Lo estoy haciendo de la manera que usted ha descrito. Tengo restricciones definidas en las tarjetas (de otro color). Las restricciones no están escritas en formato de historia de usuario sino como una oración simple como:

• El sistema admitirá el uso máximo de 30 usuarios.
• Las importaciones deben ejecutarse a diario.
• Todos los filtros y resultados de búsqueda deben estar en la misma página.

Si el cliente tiene algunos requisitos especiales que no son directamente historia de un solo usuario pero tiene un efecto más amplio, los escribo como restricciones. Estas restricciones no se estiman y no forman parte de la acumulación de productos. Los usamos para recordar algunos requisitos de implementación para historias reales de usuarios.

Answer 5

Esta idea general de "principios" (o restricciones) parece buena. He visto lo que sucede cuando las cosas que realmente deberían ser de esta clase, por ejemplo, "el sistema debe alcanzar un nivel de rendimiento específico y cuantificado", simplemente quedan en la lista de espera y se pierden entre todas las demás historias de "características": a nadie le preocupa rendimiento (porque "está bien ... hay una historia para eso en algún lugar") y luego, cuando alguien finalmente lo recoge (curiosamente, estas cosas siempre se quedan para durar, a pesar del alto valor para el cliente) se encuentran con un tarea imposible para los pocos días que se espera que la historia se lleve a cabo, y probablemente solo sea realmente alcanzable con una seria reconstrucción del sistema que debería haberse hecho mucho antes y ahora tiene un costo de reacondicionamiento masivo.