Escribir historias de usuario para tareas técnicas internas [cerrada]

Question

Estoy tratando de manejar mis proyectos un poco mejor, así que estoy en el intento de aplicar un poco de (finalmente todos) las características de scrum .

En cuanto a historias de usuario específicamente el formato de alto nivel parece ser:

usuario puede Función Descripción

o

Artefacto es Hacer Algo

¿Cómo voy a escribir "Actualización de la base de datos"?

¿Es simplemente Actualiza la base de datos?

Creo que estoy siendo arrojado fuera ya que no hay agente / cliente específico y que el cliente es el departamento de TI.

Answer 1

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value]. 

Para su ejemplo una historia de usuario podría tener este aspecto:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

He añadido un criterio de aceptación, porque sin esto, nunca se sabe cuando se realiza el trabajo. En este punto, usted tiene un caso de negocio para la actualización de la base de datos. Esta historia se puede descomponer en una historia donde el papel es el departamento de TI o DBA, así:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

Cuando se añade la descomposición historia a su caja de herramientas, la historia debe comenzar desde donde el usuario es una parte real de la empresa, y el "para que" conduce a un valor de negocio real. A continuación, descomponer la historia en una o más historias en las que los usuarios internos hacen las cosas "por lo que" los usuarios obtener los beneficios reales de necesidad.

Aquí hay un par de artículos que hablan de la historia de descomposición:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Answer 2

Scrum no es muy prescriptivo y no hay no en Scrum que te obliga a usar historias de los usuarios para sus elementos de la Pila de Producto (PBIS). Definitivamente, usted puede hacer Scrum sin capturar requisitos / características como historias de usuario, historias de usuario son sólo una manera de hacerlo. En realidad, las historias funcionan para muchos equipos, especialmente los equipos de desarrollo web, pero esto no quiere decir que funcionan en todos los casos y en cada proyecto (muchos proyectos son el desarrollo web, pero no todos, al igual que en su caso). No hay consenso sobre el uso de historias.

Dicho esto, la plantilla recomendada para historias de los usuarios es en realidad Como , quiero para que . No me refiero a ser exigente, pero, si usted elige utilizar historias, yo con gusto mejor utilizar tal cual, sin quitar ninguna parte. En primer lugar, utilizando un papel do ayuda (un mismo usuario / persona puede tener varias funciones) para descubrir historias. A continuación, especificando los beneficios es realmente importante para exponer el valor de negocio de una historia con el fin de dar prioridad a ellos también. En cuanto al valor, se debe pensar en él como el usuario final / cliente ( " poner en vasos de clientes " --Mary Poppendieck). Realmente no es siempre tan fácil de expresar los beneficios, pero algunas herramientas puede ayudar y mi preferido es el 5 porqués (que se utiliza para análisis de la causa raíz).

En su caso, esto podría conducir a algo como: A medida que el departamento de TI, quiero que la base de datos para ser actualizado para que los usuarios se beneficia de las últimas características de la aplicación y [hacer un mejor trabajo | tener una mejor experiencia de usuario ] (no muy satisfactoria, sin embargo, utilizar los 5 porqués).

Pero personalmente no me parece que las historias de usuario son el mejor medio para tareas técnicas, incluso si es claramente posible usarlos y si tienen sus puntos fuertes. En teoría, historias capturan la esencia, no los detalles y deben ser un apoyo para la discusión. Puedo estar equivocado, pero no me parece que las tareas técnicas ofrecen mucho espacio para la discusión y la creatividad. Por lo tanto, dependiendo de quién los leerá, lo que debe transmitir, puede ser que utilice o no. Otra opción podría ser para mezclar historias con otro formalismo para su PBIs. Como ya he dicho, el punto no es el uso de historias, el punto es tener una lista de elementos priorizados y estimados .

Answer 3

Actualiza la base de datos puede ser una de las tareas involucradas en la implementación de otra historia que aporta un valor directo al usuario, por ejemplo, I como un usuario puede agregar un nuevo foo a mi bar .

Si la adición de un foo a bar requiere actualizar una base de datos detrás de las escenas, entonces habría que incluir el trabajo en la aplicación de esa historia de usuario.

Historias de usuarios están redactadas de esta manera para ayudar a asegurar que cualquier trabajo beneficia directamente al usuario final, de alguna manera.

Answer 4

Esto se pone a la vanguardia de por qué las historias de usuario son tan grandes.

Qué beneficio no actualizar su base de datos de dar a los usuarios finales? ¿Ninguna? Entonces no pasar el tiempo y dinero que lo hace. Gastar tiempo y dinero proporcionando algo que le dará valor a su usuario final.

Si lo hace? Después, piensa de otra manera. Tal vez sólo se puede aplicar una nueva característica cuando se tiene la versión X de su software de base de datos? En la dependencia de la historia, se puede mencionar que la actualización de base de datos necesaria para proporcionar esta función.

tl; dr No se limite a actualizar para el bien de ella. Asegúrese de que la actualización añade valor tangible a sus clientes.

Answer 5

En general, las tareas técnicas en el PB no están bien vistas, ya que muy raramente directamente proporcionar un valor comercial al cliente. Es por eso que las historias de usuario son populares, porque te obligan a pensar en el valor de negocio de la historia, y que está siendo entregado a.

Así que, ¿por qué estás actualizando la base de datos? ¿Puede identificar el valor del negocio en la mejora de ella, y ¿por qué el dueño del producto de acuerdo en dejar de actualizar la base de datos en lugar de construir nuevas características?

Es a causa de una nueva característica que hará que sea posible o hacer que sea más fácil hacer algo en su aplicación? En ese caso, algo que debería ser el elemento PB y la actualización de base de datos debe ser una tarea dentro de esa historia. Si ya tiene historias en el PP que se beneficiarían de la actualización, entonces usted debe aumentar las estimaciones para una o más de esas historias, y añadir la actualización como una tarea técnica a la historia.

¿Es porque el proveedor de la base de datos está cortando una versión antigua de apoyo? En ese caso, usted podría tener la actualización como la historia; algo así como: "A medida que el gerente de departamento, quiero estar seguro de que tenemos el apoyo de todo el software de modo que la continuidad de la empresa no está en riesgo si algo va mal". Incluso que lo empuja, sin embargo. En general, este tipo de razón no es realmente parte de un proyecto, a menos que el proyecto ha estado pasando tanto tiempo el software del sistema se apaga apoyo.

¿Es para el rendimiento? A continuación, la historia debe ser sobre algún aspecto del rendimiento de la aplicación que necesita ser mejorado para proporcionar un valor comercial. Algo así como: "Como RSE tengo que ser capaz de recuperar la información del cliente en un tiempo razonable para que los clientes en el teléfono están satisfechos con nuestro servicio". A continuación, la actualización se convierte en una tarea bajo esa historia.

¿Es por alguna razón técnica totalmente? Si no puede identificar la forma en que la actualización se va a entregar valor de negocio, entonces ¿por qué hacerlo? ¿Por qué el propietario del producto seleccionarlo para un sprint?

Answer 6

Se trata simplemente de "Actualización de la Base de Datos" o tal vez "Cuando se instala la nueva versión, tiene que haber una manera de migrar la base de datos existente". Si ya conoce más detalles acerca de este paso, luego incluirlos. Pero la historia sobre todo existe para asegurarse de que hay algo que no se olvida; no es que se detalla.

Más tarde, cuando se llega a poner en práctica esta historia, puede carne hacia fuera (las tablas, ¿necesitamos una o más copias de seguridad, hay una caída de vuelta escenario, etc).

otoh, si el proyecto es más complejo, esto puede convertirse en una "etiqueta", como un post-it note que debe ser unido a muchas historias. Esto significa que debe incluir esto como un "sub historia" a todas las historias que cambian la base de datos. Como se puede ver, estas "historias-que abarca proyectos" son un poco difícil de pista con los métodos ágiles.

Answer 7

Infraestructura historias no tienen que seguir la plantilla historia prescrito. Simplemente escriba lo que hay que hacer y en consecuencia estimar

Answer 8

¿Qué hay de:

A medida que la persona de apoyo aplicación Quiero estar en la versión más reciente de base de datos porque es más fiable / más seguro / lo que sea .

Incluso se puede refactorización frase así:

A medida que el desarrollador aplicación Quiero que todos los clases de datos en un módulo para que pueda añadir nuevos campos para la aplicación muy rápidamente .

1. ¿Quién se beneficia
2. ¿Qué quieres hacer
3. ¿Cuál es el beneficio

Lo ideal es que no desea que todos los cuentos tienen que ser los desarrolladores 1, pero algunos tienen sentido (afilar su hacha en lugar de la tala de árboles y todo eso).