¿Cómo debemos manejar las características cosméticas adicionales en los sprints de Scrum?

Estaba leyendo los documentos de Scrum y dice que las tareas en Sprint deberían ser "potencialmente enviables".

Estoy confundido por lo que esto significa. Supongamos que en Sprint 1 el objetivo era "formulario de registro de usuario".

¿Cuántos detalles necesito agregar para que algo esté listo para enviar? Por ejemplo:

1. Puedo mostrar el formulario simple con campos sin ningún estilo elegante y marcarlos como hechos
2. Solo puedo hacer la validación del lado del cliente como marcar como hecho, pero el lado del servidor también es la opción o ambas
3. También puedo agregar algunos consejos sobre herramientas sofisticadas de jQuery, pasar el mouse por encima, captcha, colores, etiquetas para el formulario
4. Luego hay mucho estilo sobre cómo mostrar mensajes de error en la pantalla

Puedo hacer infinitamente sobre un tema. Entonces, ¿cómo dividimos eso y cuándo puedo pensar en eso como un envío listo?

¿O necesito escribir cada cosa lo más pequeña posible como mostrar errores, ventanas emergentes o texto de cuadro de luz como subtareas y ponerlas como sprint. Esto llevaría a miles de tareas para todo el proyecto.

Quiero decir, una vez más, si algunos funcionan para Internet Explorer y otros para Firefox, nuevamente necesito dividirlos como tareas también. Hay que dedicarles tiempo y cuando el gerente me pregunta qué hiciste en ese momento, no tendré ninguna tarea que contar, pero en realidad todas son parte del registro de usuarios

Acuerde esto con el propietario del producto y el equipo Scrum, no con Internet. Esto debe determinarse en su Definición de hecho, y dependerá en gran medida de cómo trabaje el equipo.

Aunque la característica debería ser 'enviable' (odio este término en Scrum), se podría argumentar que la funcionalidad es enviable sin la interfaz de usuario. Muchas personas sufren esta idea errónea en Scrum: el objetivo de un sprint es obtener tantas historias como sea posible (idealmente todas) 'Hecho', pero definitivamente no es necesario incorporarlo en algo que pueda ser lanzado.

Es importante planchar cosas como esta temprano, para que todos en todo el equipo trabajen para un objetivo común. El espíritu de Scrum es la comunicación, así que pregúntele al equipo de Scrum y saque una conclusión lógica.

Puede trabajar en un equipo donde la interfaz de usuario generalmente se maneja por separado, por ejemplo, por un equipo diferente o una vez que los expertos de la interfaz de usuario decidan cómo debe verse el formulario, etc. Alternativamente, en un pequeño proyecto / equipo, es de esperar que la interfaz de usuario se construya como usted Vamos.

Mientras el equipo sepa la respuesta, es irrelevante cuál es la respuesta.

Si las características cosméticas son parte de la característica, probablemente deberían hacerse como parte de la historia. El punto es que, una vez que dices que una historia está hecha, no deberías tener que codificar más una característica en particular. Sin embargo, en última instancia, esto lo decide el propietario del producto: pueden desear las características cosméticas o no. Esto debe explicarse en los criterios de aceptación.

Eso no significa necesariamente que esté listo para que lo use el usuario final, solo significa que está listo para alguien . Que alguien podría ser un probador u otro equipo, como el equipo de fondo.

Si está preguntando esto como desarrollador, la respuesta se convierte en "ya sabe, porque el propietario del producto le dirá si quiere las características cosméticas o no".

Si está preguntando esto como propietario de un producto, simplemente tiene que decidir si desea dividir la función en más de una historia. No hay ningún requisito, aparte de que debe satisfacer que , como un medio para satisfacer a su cliente .

Recuerde: el objetivo no es adherirse estrictamente al scrum. El objetivo es entregar software de alta calidad al usuario final. Úselo como guía cuando tenga dificultades con preguntas como esta. ¿Agregar los cosméticos en la misma historia que las partes puramente funcionales lo ayudará a entregar un código de calidad a su cliente? ¿O ayudará dividir eso en dos historias? O la respuesta es clara, o no importa y puedes hacer lo que sea que funcione para tu equipo.

"Potencialmente enviable" significa enviable no necesariamente algo que usted envía. Por ejemplo:

Un formulario de registro web que se ve terrible y no tiene validación en los campos, puede estar bien para algunas situaciones, como un proyecto escolar, pero en un negocio multimillonario, dañaría la marca para mostrar a los usuarios finales. El código puede enviarse sin ser algo que desee enviar o que la comercialización o legal le permita enviar.

Es algo que los programadores (y otras personas que están en el proceso en este momento, por ejemplo, los diseñadores) estarían encantados de lanzar como lo está ahora, incluso si, por alguna razón, nunca se lanzaría de esa manera (por ejemplo, necesita ser traducido a otros idiomas antes de que pueda enviarse a cualquier persona: Canadá tiene reglas estrictas sobre el gobierno que compra software que da igual consideración al francés como al inglés).

Este es un punto de control de calidad, miras a todos a los ojos y les preguntas si estarían encantados de enviarlo como está ahora, sin trabajo adicional, sin verificar para ver si hicieron esa última cosa. He oído que esto se llama el punto de control del ingeniero de avión. Miras a un ingeniero a los ojos y les preguntas si están dispuestos a acompañarte en el vuelo de prueba.

La idea es ser lo más ágil posible. Cuanto más rápido pueda hacer llegar algo a usuarios reales; ya sea que se trate de copias beta del código para seleccionar individuos o pruebas A / B en su sitio web, mejor. Si muestra a los usuarios un código que es demasiado aproximado, definido según sus expectativas para su producto, entonces le brindarán comentarios inútiles. Hablarán sobre cosas en las que no está buscando información, como: no les gusta que el botón sea amarillo o que el cuadro de texto no se alinee con las etiquetas. Si ES lo suficientemente bueno, puede obtener comentarios útiles. ¡Cuanto más rápido recibas este comentario, mejor! Puede validar el ajuste del producto / mercado y las suposiciones que ha hecho sobre la característica que ha intentado crear.

Enviar la función es la parte menos importante de esto. Lo importante es mover al equipo de desarrollo y terminar las Historias de usuarios. Llegar al punto en el que puede reclamar que se hace algo es un gran motivador.

Según tengo entendido, cada historia debe ser "factible" y "enviable" en la medida en que esté lista para ser consumida por alguien , no necesariamente por el usuario final . Por lo tanto, su historia puede ofrecer algunas funcionalidades que luego se pueden entregar al propietario del producto, que puede elegir que se lance a los usuarios finales o volver a repetir la función.

Dicho esto, no está impedido de incluir el estilo en la historia "Como usuario final, podré registrarme". En nuestro equipo, tratamos de hacer que cada historia sea lo más pequeña posible para mantener una mayor previsibilidad y asegurarnos de que podamos cumplir lo que prometemos. Si tenemos un diseño listo por adelantado y creemos que es trivial de aplicar, está incluido en la historia. Si creemos que puede haber alguna iteración en el diseño, esa es una historia separada, posiblemente múltiple.

Además de las otras excelentes respuestas a esta pregunta, también puede pensar en las características cosméticas como la parte de alcance variable del triángulo alcance-recursos-tiempo. Asegúrese de cumplir con los requisitos básicos de esa historia y agregue las cosas bonitas si tiene tiempo.

Se supone que Scrum no garantiza la entrega de ciertas funciones en un momento dado. Se supone que le brinda el máximo trabajo útil posible en un momento dado. Si las características cosméticas "opcionales" no se realizan durante ese sprint, debería ser porque no fueron posibles.

Depende de la persona que establece los requisitos, el "propietario del producto". Como programador, podría estar contento con una página de "formulario de registro" sin estilo que simplemente demuestra que la lógica de negocios en mis servicios web funciona correctamente, y que el registro le permite autenticarse contra otros recursos en el sistema. De hecho, "potencialmente enviable", ya que no necesariamente implica que literalmente lo enviaremos a un cliente, podría permitir que este sea el resultado de la primera historia de usuario sobre el tema, particularmente si el equipo técnico y El equipo de diseño son recursos separados con atrasos separados.

En un proyecto más maduro, puede enviar una versión "diseñada por el desarrollador" de la característica, con un estilo mínimo, a un cliente piloto o beta, pero volver a visitar la misma característica para las modificaciones de funcionalidad (basadas en comentarios) y la finalización del diseño.

El propósito de la metodología ágil es permitir que sus requisitos impulsen el proceso de desarrollo de software, en lugar de lo contrario. No caiga en la trampa de suponer que una descripción de la metodología es el Requisito verdadero y único ortodoxo. Es más fácil decirlo que hacerlo, por supuesto, particularmente si estás en una organización grande donde Scrum se ha convertido en una excusa para imponer el caos en el equipo de desarrollo.