Parece que el mundo está haciendo un buen trabajo en la gestión de los requisitos funcionales de un sistema: puede vincularlos a los beneficios, priorizarlos y administrar su programa de implementación (supongamos un mundo ideal :)
Ahora considere 'capacidades' como modificabilidad, usabilidad, adaptabilidad, reutilización, seguridad, confiabilidad, disponibilidad, etc., etc.,
Técnicamente, uno puede vincularlos con posibles beneficios finales y también priorizar su importancia para un negocio, pero ¿CÓMO se debe administrar su implementación? Suponiendo que priorice las funciones y las necesidades en la misma "pila", por así decirlo, es posible que la disponibilidad sea menor que el conjunto de funciones de "reserva de boletos" (por ejemplo).
Los agilistas pueden argumentar que el diseño debe revelarse por sí mismo y que pueden 'refactorizar' la disponibilidad o la seguridad, etc., más adelante. Honestamente, todo se puede agregar al sistema mediante la refactorización, pero los costos pueden ser prohibitivos y es por eso que uno debe dedicar algo de tiempo (puede ser más) por adelantado al tener en cuenta tales problemas, en mi opinión.
Así que mi pregunta es esta: ¿debería realizar una priorización separada para las enfermedades? ¿Deberían estar en una 'pila' separada (o atraso) propia? ¿Cuál debería ser un buen orden de secuencia al implementar el sistema? Si de hecho realiza dos actividades de priorización independientes, ¿cómo puede compararlas y convencer a las partes interesadas de que está haciendo cosas valiosas primero? Básicamente, ¿cómo justificarías hacer gestión/planificación/diseño de funcionalidades sobre el diseño de conjuntos de funciones?
Dado que las enfermedades tienen compensaciones asociadas, debe poder equilibrarlas bien y pensar en ello más tarde o seguir a YAGNI (no lo necesitará) no será suficiente. ¿Que sugieres?
Los requisitos no funcionales, las 'capacidades' o (el mejor nombre para ellos en mi opinión) los atributos de calidad tienen una influencia significativa sobre la arquitectura. Dado que los atributos de calidad no son realmente algo que su sistema hace sino algo que su sistema es , debe tratarlos de manera diferente a los requisitos funcionales.
Es por esta razón que no es apropiado tratar los atributos de calidad de la misma manera que lo haría con otros elementos de su cartera de pedidos. Ponerlos en la cartera de pedidos implica que se pueden "hacer", lo que nunca puede suceder, ya que muchos atributos de calidad tienen influencia en muchas funciones en muchas iteraciones; algo como la capacidad de prueba, escalabilidad o mantenimiento no es algo que un cliente pueda elegir para un sprint, así que no lo trate como una función en la cartera de pedidos.
Así que mi pregunta es esta: ¿debería realizar una priorización separada para las enfermedades?
Sí. Los atributos de calidad generalmente se registran como un escenario. Estos pueden ser escenarios "formales" de 6 partes o historias de uso simple. Lo más importante es registrar los estímulos, la respuesta y el entorno. Cuanto más específico y medible, mejor. Lo mejor es recoger los grandes, los más importantes al principio utilizando una técnica como el Taller de Atributos de Calidad . El resultado del QAW es una lista priorizada de escenarios de atributos de calidad.
¿Deberían estar en una 'pila' separada (o atraso) propia?
Sí. Los atributos de calidad deben rastrearse por separado . Dos razones.
¿Cuál debería ser un buen orden de secuencia al implementar el sistema?
El truco de esto es que puede poner historias discretas de deuda técnica en la cartera de pedidos (con algunos clientes). Es decir, tareas discretas que influyen directamente en los atributos de calidad específicos. Un ejemplo: "El módulo XYZ tiene muchos errores porque el código está mal escrito, necesitamos refactorizarlo para que sea más fácil de mantener".
Hay muchas estrategias para lidiar con la deuda: frutas al alcance de la mano, aplastar "granjas de errores", "cerrar" la deuda con características para garantizar que esté al tanto de las cosas...
Si de hecho realiza dos actividades de priorización independientes, ¿cómo puede compararlas y convencer a las partes interesadas de que está haciendo cosas valiosas primero? Básicamente, ¿cómo justificarías hacer gestión/planificación/diseño de funcionalidades sobre el diseño de conjuntos de características?
Puede haber compensaciones dentro de un diseño, por ejemplo, la seguridad es más importante que el rendimiento, por lo que es tan importante conocer las grandes por adelantado. Recuerde, los atributos de calidad influyen en el diseño; no son el artefacto que se entrega. No haces seguridad, esta es una propiedad del software que construyes. Acordar esto por adelantado es la única manera de garantizar que las funciones que ofrece tengan la calidad adecuada . Podría haber un millón de formas de resolver un problema, pero solo unas pocas con las propiedades deseadas. No haga esto y sus características serán rechazadas cada vez. "Sí, calcula el XYZ correctamente... pero dos minutos es demasiado..."
¿Debería realizar una priorización separada para las enfermedades? ¿Deberían estar en una 'pila' separada (o atraso) propia?
Las otras respuestas aquí están en el camino correcto. Las funciones para desarrolladores deben estar en la misma cola que las funciones para otras partes interesadas del negocio.
Esto le permitirá realizar un seguimiento de las dependencias entre funciones y ilityfunciones relacionadas con el negocio. También ayudará con su siguiente pregunta:
¿Cuál debería ser un buen orden de secuencia al implementar el sistema? Si de hecho realiza dos actividades de priorización independientes, ¿cómo puede compararlas entre ellas?
Una vez que trata todas las características de la misma manera, puede priorizarlas de la misma manera:
... [¿cómo puede] convencer a las partes interesadas de que está haciendo cosas valiosas primero? Básicamente, ¿cómo justificarías hacer gestión/planificación/diseño de funcionalidades sobre el diseño de conjuntos de funciones?
En los equipos en los que he trabajado, usamos el término Deuda técnica para ayudar a las partes interesadas del negocio a comprender la importancia de mantener la base del código.
ilitylas funciones aparecen en la misma cola. No estoy sugiriendo que se use como un cubo para lanzar elementos o un sumidero de recursos ilimitado. No implementa funciones ni realiza cambios a menos que tenga que hacerlo y/o tenga el presupuesto, y haya hecho una predicción fundamentada de los beneficios que traerá. Esto es lo mismo que las características que provienen directamente de los requisitos comerciales principales. ¿Querías decir otra cosa?ilitiessiempre tendrá una prioridad más alta. Los elementos deben priorizarse según el costo y el beneficio, que deben basarse en una predicción lo más realista posible. La predicción debe basarse en el costo básico, las dependencias de costos y el "interés" del costo. Por ejemplo, si implementa esto ahora, costará menos, o si implementa A antes que B, B será más económico. En muchos casos, esta predicción se puede hacer mediante la comprensión del alcance de cada característica comercial y qué código probablemente tocará, luego un código grep y tal vez una implementación de pico.Los manejaría con el mismo retraso que todas sus historias. Solemos abordar los requisitos no funcionales de 3 maneras (en orden de preferencia):
Como parte de nuestra Definición de Listo donde se aplica a toda la aplicación.
En nuestros Criterios de aceptación para aquellos que solo se aplican a una historia o subconjunto de historias.
Como una Historia donde no pueden ser considerados claramente como parte de los dos primeros pero no queremos olvidarlos.
ilitysen paralelo con los analistas de negocios recopilando requisitos sobre características principales. Priorizar antes de eso (sobre qué incluso reunir requisitos) debe basarse en la intuición y el acuerdo entre las partes interesadas (los desarrolladores son las capacidades WRT de las partes interesadas).Tenga siempre un único backlog y deje que las necesidades del negocio dicten las prioridades.
Los requisitos no funcionales suelen ser más difíciles de resolver frente a los requisitos funcionales y si priorizarlos por encima o por debajo de los requisitos funcionales, es una pregunta que debe hacer a las partes interesadas o al propietario del producto.
El orden de priorización depende completamente del contexto/las necesidades comerciales de su producto.
Trabajo probando sistemas integrados para organizaciones de seguridad pública y para un policía de patrulla (nuestro usuario típico), la confiabilidad del producto es primordial y está muy por delante en términos de prioridad frente al nuevo conjunto de características que el producto tiene para ofrecer.
Doctor
Merlyn Morgan Graham