Tengo una tarea en mi trabajo pendiente de Jira que no sé si debería estar dentro de una historia de usuario. Hay tareas relacionadas con el desarrollo, el servidor, la configuración, etc. El usuario no pidió tener esas tareas/características, pero como desarrolladores sabemos que necesitamos tenerlas. p.ej:
Minimizar el código con la tarea Gulp
Podría convertir esa tarea en una historia de usuario como:
Podría cambiar el rol de desarrollador, pero eso no será una historia de usuario :
¿Es esta tarea un buen ejemplo de creación de historias de usuario donde no hay una historia de usuario? Una historia de usuario con tareas (demasiado) generales. p.ej:
¿O debería simplemente tenerlo como una tarea simple (sin historia de usuario) en mi cartera de pedidos?
Otros ejemplos de historias técnicas de usuarios:
La creación de historias de usuarios es para iniciar la conversación y brindarle al equipo contexto para comprender el problema en cuestión y crear la solución correcta. También obliga al escritor a pensar en el valor que agrega. Usar algo como INVEST tiene sentido aquí.
Si el valor de las tareas técnicas es claro, creo que usar un formato de historia de usuario es solo una pérdida de tiempo. Pregúntate por qué quieres escribirlo en ese formato, ¿qué ganas? Solo por escribir todas las tareas en el mismo formato es una razón inválida si me preguntas.
En su ejemplo, los usuarios no quieren minimizar el sitio web, esa es la solución. Quieren que sea más rápido, pero ¿realmente o es un desarrollador que piensa que los usuarios quieren esto? Escribir una historia de usuario sobre "Usuarios que desean un sitio web más rápido" podría conducir a más soluciones que simplemente minimizarlo.
Cuestiona el valor, encuentra la manera de hacerlo, no te limites al formato de historia de usuario. Descubra lo que funciona para usted para cada tipo diferente de tarea. Estaría bien con tareas simples y claras en mi trabajo pendiente siempre que podamos INVERTIRLO.
¡Al final solo se trata de hacer el trabajo! :)
Tengo una tarea en mi trabajo pendiente de Jira
¿De dónde vienen? Por lo general, el propietario del producto administrará la acumulación de productos y agregará historias de usuarios para indicar lo que quieren.
El usuario no solicitó tener esas tareas/características, pero como desarrollador sabemos que necesitamos tenerlas.
Luego habla con el Product Owner y explícale el valor del trabajo. Estoy seguro de que el propietario del producto verá el objetivo del trabajo y creará una historia que signifique el valor para los usuarios.
Sin embargo, si está hablando de tareas de desarrollo de rutina (como configurar entornos, agregar configuraciones, etc.), simplemente agréguelas como tareas separadas (no se moleste con el formato de la historia del usuario). Es responsabilidad del equipo de desarrollo entregar un producto de calidad. No necesitan justificar todas y cada una de las tareas que realizan para lograrlo.
Alternativamente, puede envolverlos debajo de una historia de usuario existente. Por ejemplo, digamos que la primera historia que planea hacer en un sprint es configurar la página de bienvenida para el sitio. Resuelva todas las tareas técnicas que necesita en esta historia (como obtener el certificado SSL, configurar el proxy, etc.). De esa manera, cuando entregue la primera historia, también entregará un incremento liberable.
Esto hará que la historia sea más grande, pero está bien, ya que simplemente refleja el trabajo que debe hacer para publicar la primera historia.
No es inusual que los equipos de Scrum solo entreguen una historia en su primer sprint. Esto es por la razón mencionada anteriormente, envolvieron todo el trabajo de cimentación en ese primer piso.
Con cualquier proyecto, las historias se escriben dentro de un contexto de suposiciones. "el sitio web estará alojado", "los usuarios tendrán acceso a Internet", etc.
A veces, estos se aclaran con una "Definición de hecho" o un conjunto de "requisitos técnicos" que se aplican a cualquier historia. Pero te sugiero que los ataques como un "Sprint 0"
En Sprint 0, configura el entorno y los marcos que usará, elige lenguajes y marcos, compra nombres de dominio, etc. Esto incluiría secuencias de comandos de implementación e integración continua, por lo que la compresión y la agrupación de secuencias de comandos, etc., estarían integradas en el proceso de compilación. En su caso particular, 'cree un script de compilación que ejecute trago en todos los archivos'
La idea es eliminar todas las tareas de configuración, de modo que pueda concentrarse en ofrecer características para el proyecto en lugar de ser golpeado constantemente por bloqueadores técnicos, "tenemos que esperar al firewall" o "CI está roto nuevamente".
Al final del sprint 0, debe tener un proyecto básico de "hola mundo" y vivir con pruebas de unidad/integración/aceptación o cualquier otro requisito básico que tenga establecido.
A partir de ellos, se trata de agregar funciones adicionales a este proyecto base, siguiendo la plantilla de lo que ya está allí. En lugar de tener que inventar o discutir soluciones técnicas.
aqwert