Recientemente me encontré debatiendo sobre la utilidad de los criterios de aceptación en una historia de usuario. Tenga en cuenta que el equipo en cuestión no es un equipo de funciones, es un equipo de componentes técnicos (si eso cambia las cosas).
Los miembros del equipo han estado escribiendo una página o dos con cosas que construirán; no tanto como un documento de especificaciones, sino como un documento de definición de lo que se debe hacer. Allí, está bastante claro cuál es el alcance de la historia. Entonces, en efecto, el veredicto fue que no había necesidad de preocuparse por los criterios de aceptación (en el ticket de Jira, por ejemplo).
Esto parece estar funcionando con el equipo, ya que no hubo ambigüedad en la implementación (y si hay alguna, el equipo lo discutirá entre ellos), por lo que estoy desconcertado sobre qué agregarían los criterios de aceptación a esta historia de usuario y si Vale la pena hacer cumplir eso.
No hay un formulario para los criterios de aceptación. Si su documento describe lo que debe hacerse con suficiente detalle para escribir pruebas, entonces ese documento es su criterio de aceptación.
Tenga en cuenta que una historia tiene tres partes: tarjeta, conversación y confirmación. La tarjeta es una forma de recordarle al equipo sobre el trabajo. La conversación (y cualquier nota requerida o detalles que surjan de esas conversaciones) ayudan al equipo a trabajar para encontrar una solución. La confirmación es cómo te aseguras de que se ha realizado el trabajo, a menudo a través de pruebas automatizadas. Hay diferentes formas de capturar lo que necesita probar de las conversaciones asociadas.
Por supuesto, puede utilizar un diseño o un documento de requisitos como base de sus criterios de aceptación. No es necesario volver a registrar esa información en una historia si ya la tienes. Sin embargo, el control de cambios puede ser difícil con los documentos. Si su cartera de pedidos cambia y crea nuevas historias, es posible que desee conservar las versiones anteriores de sus documentos. Puede ser difícil para varias personas editar el mismo documento simultáneamente y mantener la claridad sobre qué versión es relevante para una historia determinada. Por estas razones, muchas personas recurren a los documentos solo cuando tienen que hacerlo y, de lo contrario, confían en las historias como el lugar preferido para poner los criterios de aceptación.
Los criterios de aceptación son contra lo que se llevan a cabo las pruebas de aceptación (¡del lado del cliente!). Puede , pero no tiene que ser 100% de conformidad con los requisitos. No debería ser más (porque eso implicaría que los requisitos no estaban completos), pero podría ser un subconjunto de requisitos, especialmente para el desarrollo gradual.
Los criterios de aceptación los establece el cliente, ya que, en función del resultado de la prueba de aceptación, acepta o rechaza el entregable. Por lo tanto:
Para hacer eco de lo anterior... ¡ "Criterios de aceptación" representa lo que la empresa (!) aceptará!"
Usted, "sentado en su mazmorra de desarrollo de código", comprende completamente las complejidades del código fuente que está desarrollando. Pero, el negocio no lo hace, y no lo necesita, "y ese es el punto".
En su lugar, explican en detalle sus "criterios de aceptación". (Y esté muy agradecido de que lo hayan hecho). Porque su código fuente, cuando finalmente se les entregue, será "una herramienta en sus manos". Tiene que permitirles realmente hacer su trabajo. (No el suyo.) Tiene que estar absolutamente seguro de que el software que finalmente les entregue los satisfaga completamente en todos estos puntos comerciales (!) . De lo contrario, no has hecho tu trabajo en absoluto.
Debe tener en cuenta que la aceptación puede ser una combinación de criterios funcionales y no funcionales, es decir, tanto "qué" ofrece la solución como "cómo" lo ofrece, que podría ser rendimiento, capacidad, confiabilidad, mantenibilidad, etc. en. Todos estos deben ser capturados. Si todos están en la especificación de diseño, es posible que no necesite criterios de aceptación separados (según su pregunta original).
Si no se especifican, le sugiero que cree un documento de aceptación, para evitar argumentos como "¡Nunca dijo que tendría que hacer frente a 20,000 usuarios simultáneos!", o "Pensé que sería obvio que el el sistema debería seguir funcionando a través de actualizaciones de hardware". O incluso "¿Por qué lo creaste con tanta capacidad libre? ¡Nunca necesitará manejar más de 10,000 entradas en la base de datos!"
Iain9688
dqm