principios de la arquitectura como las historias de usuario “no funcionales” [cerrada]

Question

Estoy a punto de iniciar un proyecto piloto en nuestra compañía en introducir prácticas ágiles, incluyendo el uso de historias de usuario. Después de leer dos libros de Mike Cohn, ágil Estimación y Planificación en particular y de historias de los usuarios Aplicada, ahora tengo una idea más clara de cómo proceder. Tengo confianza en el perfeccionamiento de nuestras técnicas, junto con la práctica.

Sin embargo, hay una cosa que no me convence. En esta entrada del blog Mike Cohn define un tipo específico de casos de uso , al que llamó restricciones, que pueden ser utilizados para definir los requisitos de los llamados no funcionales. Personalmente no me gusta la palabra restricción e incluso el uso de la plantilla clásica "Como ..., quiero ..., de modo que ...".

En lugar voy a tratar de hacer que el cliente a escribir, siempre en las tarjetas, tal vez con la plantilla anterior, los que Nick Rozanski y Eoin maderas llamados, en su libro fantástico Software de Sistemas de Arquitectura , principios de la arquitectura

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

(que también se dividen estos principios en principios de negocio y principios de tecnología , una diferenciación Creo que no hay que preocuparse de.)

Lo que me gustaría hacer con estos principios tarjetas es ponerlos al lado de nuestro tablero de tarjetas de retraso acumulado con el fin de tenerlas siempre presentes durante la definición historias de usuario y las actividades de planificación. También me gustaría animar a los clientes y desarrolladores para recogerlos y ponerlos al lado del tablero iteración cada vez que piensan en una tarjeta podría ser útil como un recordatorio para el equipo.

¿Alguna vez ha tratado de cualquier enfoque similar? Cómo se desalientan por cualquier motivo? Si tiene alguna sugerencia sobre esta materia?

Answer 1

¿Alguna vez ha tratado de cualquier enfoque similar? No he probado algo exactamente igual, pero cuando era un Scrum Master de mi equipo que tenía un proyecto de directriz amplia arquitectónica y la visión (que todos los equipos eran una parte de), que nos recuerda a nosotros mismos, durante las diversas inspeccionar y adaptar las partes de un Sprint y también el proyecto Scrum, como durante Retrospectivas, reuniones de planificación de Sprint e incluso reuniones diarias de Scrum. Algunas de las formas que usamos para recordarnos fueron añadiendo Características Hecho para las tareas que incluían un principio a seguir las directrices de arquitectura, y también se pueden añadir como una pequeña nota de los pedidos pendientes. En mi sugerencia a continuación he mencionado cómo se mira desde un nivel muy alto.

¿Le desalentarlo por cualquier motivo? No, en absoluto. Yo digo que su sugerencia es buena y que debería probarlo durante una reunión de planificación. Y como se sugiere por Ken Schwaber y Jeff Sutherland en su Guía de Scrum, usted debe inspeccionar y adaptar durante los 3 puntos en un sprint - "Hay tres puntos de inspección y adaptación en la reunión de The Daily Scrum Scrum se utiliza para inspeccionar el progreso hacia el. objetivo del Sprint, y para hacer las adaptaciones que optimicen el valor del siguiente día de trabajo. Además, la Revisión del Sprint y reuniones de planificación se utilizan para inspeccionar el avance hacia la meta de lanzamiento y para hacer las adaptaciones que optimicen el valor de la siguiente Sprint. Por último, el Sprint Retrospective se utiliza para revisar el pasado Sprint y determinar qué adaptaciones harán que el próximo Sprint más productiva, satisfactoria y agradable ".

Para cualquier sugerencia sobre este asunto? ¿Es seguro para mí asumir que este proyecto 'ágil' en su empresa es sólo el comienzo y no tener un conjunto sólida visión proyecto todavía? Si es así, sugeriría a organizar un taller de planificación lanzamiento ancho 2 semanas proyecto. El propósito de este taller sería conseguir todos los grupos de interés, puntos de venta, SMS y jefes de proyecto en un solo lugar y desarrollar un Super User Story y Visión, y el resto de los pedidos pendientes, desglosados ??de la súper usuario story.The Súper Historia usuario sería la visión de alto nivel de la meta del proyecto. Si ya ha hecho esto, por favor, pasar por alto esta sugerencia, pero mi punto de tocando el tema es que la visión de alto nivel o una historia de superusuario podrían / ??deberían tener una parte que menciona el siguiente conjunto arquitectónico principio en su empresa.

Las ventajas de este? Se pone el actor involucrado en el aspecto arquitectónico y técnico del derecho producto de la historia de súper usuario que ayuda a crear un buen entendimiento de la visión entre la empresa y el aspecto técnico, y uno no puede vivir sin el otro.

Me puede haber tratado de forma intencionada para extender la respuesta más allá del alcance preguntas para que pueda obtener alguna información sobre mis ideas.

Gracias, Sid.

Answer 2

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

• Sistema apoyará el uso máximo de 30 usuarios.
• Las importaciones debe ejecutarse diariamente.
• Todos los filtros y los resultados de búsqueda tiene que estar en la misma página.

Si el cliente tiene algunos requisitos especiales que no están directamente historia de usuario única, pero tiene un efecto más amplio las escribo como restricciones. Estas limitaciones no son estimados y no son parte de la cartera de productos. Las usamos para recordar algunos de los requisitos de ejecución de historias reales de los usuarios.

Answer 3

Eso fue objeto de una sierra charla que en enero de este año en la fábrica de Arquitecto. Seguí hacia abajo. Fue Lee Ingram de "Business Driven Architecture: un ejemplo de un inicio actual". No puedo encontrar las diapositivas, pero él habló sobre la idea de que los Principios de Aplicación guía de cómo los requisitos se han de cumplir.

Tenía cosas como multiempresa y blanco-etiquetado. Con un servicio web multi-inquilino, usted tiene que planificar desde el principio de la segregación / aislamiento de los usuarios. Del mismo modo, si usted quiere ser capaz de marca blanca de su servicio, entonces muchas más cosas tienen que ser configurable (estilo, etiquetas, etc.). Tanto impacto casi cada historia.

Answer 4

Yo recomiendo presentación Jeff de Patton en el mapeo historia de usuario .

No sólo aclara la composición de exactamente qué propósito sirven historias (o lo que les gustaría llamarlos), así como la forma de construir relaciones o dependencias entre las historias, y cómo tratar con ellos.

Answer 5

Esta idea general de "principios" (o limitaciones) parece una buena idea. He visto lo que sucede cuando lo que realmente debería estar en esta clase - por ejemplo, "sistema debe alcanzar un cierto específico, nivel cuantificado de rendimiento" - sólo se tira en el retraso y la pérdida de entre todas las otras historias "característica": preocupaciones sobre Noone rendimiento (porque "está bien ... hay una historia para que en algún lugar") y luego cuando alguien finalmente no recogerlo (curiosamente, estas cosas siempre se quedan al último, a pesar del alto valor para el cliente) se encuentran con una tarea imposible para los pocos días se espera una historia de tomar, y es probable que en realidad sólo alcanzable con un poco de rediseñar grave del sistema que se debería haber hecho mucho antes y ahora tiene un enorme costo reacondicionamiento.