¿Puedo usar "historias de usuario" para tareas de mejora de procesos?

9

Actualmente utilizamos JIRA para rastrear nuestro trabajo de desarrollo. Mi administración desea formatear y clasificar todo como "Historias de usuarios", incluidas las tareas relacionadas con el desarrollo que no son de software. Por ejemplo:

"Como administrador de pruebas, ¿puedo realizar pruebas de la aplicación usando solo pruebas automatizadas y no pruebas manuales para poder probar la aplicación de la manera más eficiente posible?

Criterios de aceptación: 1. Convertir 50 pruebas manuales existentes en pruebas totalmente automatizadas 2. Las pruebas deben ejecutarse en menos de 1 hora "

Quiero tener una idea de la comunidad si tiene sentido usar "historias de usuarios" para el trabajo que respalda el proceso de desarrollo de software, no lo hacen los programadores y no da como resultado directamente un código entregable. ¿O debería tratarse / clasificarse de manera diferente (por ejemplo, en JIRA)?

Actualizado el 7/06/2011: pregunta reformulada para centrarse en el término "historia de usuario".

Dan C
fuente
Gracias a todos por sus pensamientos, ¡sigan enviando comentarios! Lo anterior es solo un ejemplo [excesivamente] simplificado ya que aún no tengo uno tal como lo escribió nuestro equipo de administración. Pero en base a las discusiones, quieren poder medir las mejoras del proceso, como "convertir 100 pruebas manuales (o algún porcentaje) a pruebas automatizadas para el final del trimestre", etc. Quieren poner todo esto en JIRA y clasificarlas. como "historias de usuarios" en lugar de "tareas" u otra cosa.
Dan C

Respuestas:

10

si

cualquier parte interesada, cualquier característica que mejore el sistema

[¡Que comiencen los votos negativos puristas!]

Steven A. Lowe
fuente
+1 Solo tenga en claro quiénes son las partes interesadas, es decir, desarrolladores, gerentes, etc. [¡Que comience la guerra de llamas!]
Michael K
1
Soy purista y apruebo esta respuesta.
Tom Anderson
No estoy de acuerdo, pero no votaré porque aprecio tu coraje :)
maple_shaft
Iba a dar una versión larga sin aliento, ¡pero esto lo dice todo! ¡Los "encargados de mantenimiento" y las "personas que trabajan en esto en 3 años" son partes interesadas válidas a considerar!
Al Biglan
7

"Mi administración quiere usar Agile para todo, incluidas las tareas relacionadas con el desarrollo que no son de software".

Esto no significa escribir historias de usuarios para cada característica.

Si desea escribir historias de usuario para cada característica, no necesariamente está siendo ágil. Solo estás escribiendo historias de usuarios para cada característica.

User Stories! = Ágil.

User Stories es una forma de reunir y comprender los requisitos. Se pueden usar de forma perfectamente cascada, si así lo desea. Algunas personas hacen esto.

Agile es una forma de gestionar proyectos. Puede usar Historias de usuario, o no, en un proyecto Agile.

Las Historias de usuarios para administrar la deuda técnica y las tareas internas, una vez más, no tienen nada que ver con ser ágil.

Muchas personas están perfectamente felices de agregar funciones "técnicas" o de "soporte" en un sprint sin perder el tiempo escribiendo una "historia de usuario" falsa para usuarios puramente internos, de valor limitado y sin participación.

Si el control de calidad no comprende su historia, ¿cuánta pérdida comercial real hay?

Si las partes interesadas reales no entienden sus historias, el negocio realmente sufre.

S.Lott
fuente
Estoy de acuerdo en que las "Historias de usuarios" ciertamente pueden existir sin "Agile". Me pregunto si el término "Historia de usuario" es bueno para algo relacionado con la mejora de nuestro proceso de desarrollo y no para agregar una función de aplicación.
Dan C
@Dan C: Lo que importa es esto. Su pregunta confunde dos conceptos no relacionados. "la gerencia quiere usar Agile para todo" es totalmente engañoso en comparación con su pregunta real. Por favor aclara esto.
S.Lott
Buen punto. Reformé la pregunta y proporcioné más contexto.
Dan C
Estoy muy de acuerdo con usted en que las historias de los usuarios no son iguales a las de Agile. Las historias de los usuarios son solo un recordatorio de que un requisito tiene que ser discutido y ese requisito podría ser una característica de un sistema a ser construido, un proceso de negocio a ser mejorado o cualquier cosa de cualquier naturaleza, por ejemplo, planificar una boda. Lo que Agile representa es "Menos documentación, más colaboración" ...... (tenga en cuenta que Agile no dijo "Sin documentación", aboga por "Menos documentación")
Baba Kososhi
2

Esto no tiene sentido para mí. Una "historia de usuario" en esencia es solo eso, una historia de usuario, no una historia de Project Manager, ni una historia de desarrollador, ni una historia de ingeniero de control de calidad.

En esa nota, el software es:

  1. Definible
  2. Comprobable

Las mejoras del proceso son abiertas y, por lo general, subjetivas.

Criterios de aceptación: 1. Mejora de la prueba 1 (por x / a)

¿Cómo se mide la mejora de las pruebas? No hay contrato definible para eso.

Y en una nota no relacionada ESPERO SINCERAMENTE que su ejemplo dado anteriormente,

Como administrador de pruebas, ¿puedo realizar pruebas de la aplicación usando solo pruebas automatizadas y no pruebas manuales para poder probar la aplicación de la manera más eficiente posible?

... es solo un ejemplo, porque hay tanto mal con esto que ni siquiera puedo comenzar a describirlo.

árbol de arce
fuente
¿Quizás tener las mejoras del proceso abiertas es lo malo? Siempre he encontrado que las mejores mejoras son muy específicas, alcanzables, etc. Lo mejor es hacerlas visibles y trabajar con un propietario del producto para priorizarlas. Los criterios de aceptación dados como ejemplos son malos, ¡pero también lo son muchas solicitudes de características inicialmente! Deje que el equipo lo resuelva y los refine. Tal vez se transforman para "crear objetos simulados para interfaces externas X, Y y Z" o algo así ...
Al Biglan
1

La deuda técnica podría manejarse de manera similar a la historia de un usuario, pero esto puede ponerse bastante feo a veces. Por ejemplo, para tener una historia como: "Como desarrollador, quiero tener pruebas de unidad de trabajo para poder confiar en las pruebas para validar si otros cambios rompen algo", no tiene mucho valor para el propietario del producto pero puede ser una buena idea que el equipo lo haga como parte de su propia refactorización que es parte del trabajo en un sprint.

Me gusta la idea de tener tareas separadas de las historias de los usuarios, ya que las tareas no van a ser algo que mostrarías a un usuario final de un sistema, pero podrían ser algo para ayudar a mejorar el mantenimiento y el tiempo que puede tomar para Desarrollar alguna nueva característica. Dependiendo de cuántas tareas, en términos de puntos totales totales, ya que algunas tareas pueden ser de 2 minutos y otras pueden ser de 2 semanas, esto puede ser lo que determina si el equipo toma un sprint y no agrega nuevas características pero funciona en tareas para limpiar cosas que he visto algunas veces donde trabajo.

JB King
fuente
1

En mi humilde opinión, sí, puede usar historias de usuarios para proyectos de desarrollo que no sean de software, no solo tareas de mejora de procesos. Tomemos, por ejemplo, hace 3 años que era el mejor hombre en la boda de mi amigo y usé la metodología ágil y las historias de los usuarios para planificar la boda. Todas las tareas que tuvimos que completar se escribieron como historias de usuarios con personalidad, intención, justificación y criterios de éxito para cada historia de usuario. Todas las partes involucradas participaron en nuestro scrum diario para discutir lo que hicimos el día anterior y lo que estaríamos haciendo ese día. Todos estaban geográficamente dispersos, por lo tanto, realizamos conferencias telefónicas para nuestras reuniones diarias de scrum, planificación de sprints, retrospectivas, redacción de historias y sesiones de estimación ... lo que sea, lo hicimos. Tuvimos 6 sprints en total (3 meses) y la boda fue un éxito asombroso sin dejar piedra sin remover.

Baba Kososhi
fuente
0

Tienes un problema profundo cuando pones "historias de usuario" internas en la mezcla con historias de usuarios reales.

Vuelva a leer tantas definiciones de "parte interesada" como pueda encontrar.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Léelos con mucho, mucho cuidado para que puedas ver la diferencia entre pollos y cerdos.

Las "historias de usuario" internas están escritas por pollos.

Las historias de usuarios reales están escritas por cerdos.

Sus historias de usuario "orientadas al pollo" no son muy importantes. No importa cuánto la administración quiera rastrearlos como si fueran historias de usuarios reales con valor real, no son historias de usuarios reales y no crean valor de la misma manera.

En el borde borroso del argumento está el problema del control de calidad. El control de calidad es importante y sin él, nada funciona.

Eso no convierte mágicamente a QA de repente en un cerdo. Los hace aún no interesados. Proporcionan soporte, infraestructura y una base esencial para el resto del trabajo. Pero sus "historias de usuario" son esencialmente diferentes de las historias de usuarios reales del usuario real.

Si el control de calidad no muestra que se prueba una mejora en la prueba, nadie cierra su negocio. El dinero no se pierde.

Si el usuario no puede hacer negocios en primer lugar, está fuera del negocio. El dinero se pierde Toda la operación es un fracaso total.

No mezcle partes interesadas internas ("pollo") y reales ("cerdo").

S.Lott
fuente
0

El comentario de "pollos y cerdos" pierde el punto. Las partes interesadas internas son pollos cuando se trata del producto que se está desarrollando (a menos que se esté desarrollando para ellos), pero son cerdos cuando se trata del proceso de desarrollo.

La pregunta que hace es si la fórmula de la oración "Como un , Me gustaría poder _ , de modo que pueda __ "sería útil para definir y mejorar los procesos comerciales donde las mejoras no requieren escribir un nuevo código de software. Encontré este hilo porque estoy pensando en hacer lo mismo y estoy buscando las mejores prácticas, pero mi fuerte intuición es que la respuesta a su pregunta es "sí". El propósito de la estructura de la oración es realmente obligar al escritor a abstraer las soluciones que ya podría tener en mente y centrarse en lo que el usuario - en este caso, el usuario del proceso - quiere poder hacerlo. No veo ninguna razón por la cual la historia del usuario no sería útil cuando se aplica al proceso.

El punto sobre los criterios de aceptación es bueno, pero no necesita ser dogmático al respecto (que es ágil de todos modos). Cuando se diseña cualquier proceso de negocios, es un buen ejercicio preguntar: "¿Cómo sabré si el cambio en el proceso logró mi objetivo?" Es cierto que no siempre se puede ejecutar una prueba automatizada para responder esa pregunta, pero esa no es una razón para descalificar la historia del usuario como herramienta.

Michael F
fuente