project-management - puede - que preguntar a un project manager

Escribiendo historias de usuario para tareas técnicas internas (8)

En general, las tareas técnicas en el PB son mal vistas porque rara vez entregan directamente el valor comercial al cliente. Es por eso que las Historias de usuarios son populares, porque te obligan a pensar en el valor comercial de la historia y a quién se la están enviando.

Entonces, ¿por qué estás actualizando la base de datos? ¿Puede identificar el valor de negocios al actualizarlo y por qué el Propietario del producto debe permitirle actualizar la base de datos en lugar de crear nuevas funciones?

¿Es debido a una nueva característica que lo hará posible o facilitará hacer algo en su aplicación? En ese caso, ese elemento debería ser el elemento PB, y la actualización de la base de datos debería ser una tarea dentro de esa historia. Si ya tiene historias en el PB que se beneficiarían con la actualización, entonces debe aumentar las estimaciones para una o más de esas historias y agregar 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 anterior del soporte? En ese caso, podría tener la actualización como la historia; algo así como: "Como gerente del departamento, quiero estar seguro de que tenemos soporte para todo el software para que la continuidad del negocio no corra riesgo si algo sale mal". Sin embargo, incluso eso lo está empujando. En general, este tipo de razón no es realmente parte de un proyecto, a menos que el proyecto haya estado funcionando durante tanto tiempo que el software del sistema deje de ser compatible.

¿Es por rendimiento? Entonces, la historia debe ser sobre algún aspecto del rendimiento de la aplicación que debe mejorarse para ofrecer valor empresarial. Algo como: "Como CSR, necesito poder recuperar la información del cliente en un tiempo razonable para que los clientes en el teléfono estén satisfechos con nuestro servicio". Entonces la actualización se convierte en una tarea bajo esa historia.

¿Es por alguna razón totalmente técnica? Si no puede identificar cómo la actualización generará valor comercial, ¿por qué lo haría? ¿Por qué el propietario del producto lo seleccionaría para un Sprint?

Estoy tratando de administrar mis proyectos un poco mejor, así que estoy tratando de aplicar algunas de las características de scrum (eventualmente todas).

Mirando las historias de usuario específicamente el formato de alto nivel parece ser:

Como usuario puedo caracterizar la descripción

El artefacto está haciendo algo

¿Cómo escribiría "Actualizar la base de datos"?

¿Es simplemente actualizar la base de datos?

Creo que estoy siendo rechazado porque no hay un actor / cliente específico y que el cliente es el departamento de TI.

Es simplemente "Actualizar la base de datos" o tal vez "Cuando se instala la nueva versión, debe haber una manera de migrar la base de datos existente". Si ya conoce más detalles sobre este paso, inclúyalos. Pero la historia existe principalmente para asegurarse de que algo no se olvida; No es para ser detallado.

Más adelante, cuando implementes esta historia, puedes realizarla (en qué tablas, necesitamos una o más copias de seguridad, hay un escenario alternativo, etc.).

OTOH, si el proyecto es más complejo, esto puede convertirse en una "etiqueta", como un aviso post-it que se debe adjuntar a muchas historias. Eso significa que debe incluir esto como una "sub historia" a todas las historias que cambian la base de datos. Como puede ver, estas "historias que abarcan proyectos" son un poco difíciles de rastrear con métodos ágiles.

Esto llega a la vanguardia de por qué las historias de usuarios son tan grandes.

¿Qué beneficio da la actualización de su base de datos al usuario final? ¿Ninguna? Entonces no gastes el tiempo y el dinero haciéndolo. Dedique ese tiempo y dinero a proporcionar algo que le dé valor a su usuario final.

¿Si lo hace? Entonces piensa de otra manera. ¿Tal vez solo pueda implementar una nueva característica cuando tiene la versión x de su software de base de datos? En la dependencia de la historia, podría mencionar la actualización de la base de datos necesaria para proporcionar esta función.

tl; dr No solo actualices por el bien de eso. Asegúrese de que la actualización agregue valor tangible a sus clientes.

Las historias de infraestructura no necesitan seguir la plantilla de historia prescrita. Simplemente escriba lo que debe hacerse y haga una estimación en consecuencia

Qué tal si:

Como persona de soporte de aplicaciones , quiero estar en la última versión de la base de datos porque es más confiable / más seguro / lo que sea .

Podrías incluso decir refactorización así:

Como desarrollador de aplicaciones , quiero todas las clases de datos en un módulo para poder agregar nuevos campos a la aplicación muy rápidamente .

Quién se beneficia
Que quieres hacer
Cual es el beneficio

Lo ideal es que no quieras que todas las historias sean desarrolladores, pero algunas tienen sentido (afilar tu hacha en lugar de cortar árboles y todo eso).

Scrum no es muy prescriptivo y no hay nada en Scrum que lo obligue a usar las Historias de usuario para sus elementos de productos pendientes (PBI). Definitivamente, puedes hacer Scrum sin capturar requisitos / características como historias de usuario, las historias de usuario son solo una forma de hacerlo. En realidad, las historias funcionan para muchos equipos, especialmente equipos de desarrollo web, pero esto no significa que funcionen en todos los casos y en todos los proyectos (muchos proyectos son desarrollo web pero no todos, como en su caso). No hay consenso sobre el uso de historias.

Dicho esto, la plantilla recomendada para Historias de usuarios es En realidad como un <role>, quiero <action> para que <benefits> . No quiero ser exigente, pero si elige usar historias, le sugeriría que lo use tal como está, sin eliminar ninguna parte. Primero, usar un rol ayuda (un mismo usuario / persona puede tener varios roles) para descubrir historias. Luego, especificar los beneficios es realmente importante para exponer el valor empresarial de una historia para priorizarlos bien. Con respecto al valor, debe pensar en él como usuario final / cliente (" ponerse las gafas de cliente " --Mary Poppendieck). Realmente no siempre es tan fácil expresar los beneficios, pero algunas herramientas pueden ayudar y mi preferida es la de los 5 por qué (que se usa para el análisis de la causa raíz).

En su caso, esto podría llevar a algo como: Como departamento de TI, quiero que la base de datos se actualice para que los usuarios puedan beneficiarse de las últimas funciones de la aplicación y [haga un mejor trabajo | tenga una mejor experiencia de usuario] (no muy satisfactorio sin embargo, use los 5 porqués).

Pero personalmente, no encuentro que las historias de usuario sean el mejor medio para tareas técnicas, incluso si es claramente possible usarlas y si tienen sus puntos fuertes. Teóricamente, las historias capturan la esencia, no los detalles y deberían ser un apoyo para la discusión. Puede que me equivoque, pero no encuentro que las tareas técnicas ofrezcan mucho espacio para la discusión y la creatividad. Entonces, dependiendo de quién los lea, qué debe transmitir, puedo usarlos o no. Otra opción podría ser mezclar historias con otro formalismo para sus PBI. Como dije, el punto no es usar historias, el punto es tener una lista de elementos priorizados y estimados .

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

Si agregar un foo a una barra requiere una actualización de la base de datos entre bambalinas, entonces incluirá ese trabajo en la implementación de esa historia de usuario.

Las historias de los usuarios están redactadas de esta manera para garantizar que cualquier trabajo beneficie directamente al usuario final de alguna manera.

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

Para su ejemplo, una historia de usuario podría verse así:

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 agregado un criterio de aceptación porque sin esto nunca sabrá cuándo se realiza el trabajo. Ahora en este punto, tiene un caso de negocios para actualizar la base de datos. Esta historia se descompondría en una historia donde el rol es el departamento de TI o DBA, como:

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 la descomposición de la historia se agrega a su caja de herramientas, la historia debe comenzar desde donde el usuario es una parte real de la empresa, y el "tal que" lleva a un valor comercial real. Luego, descomponga la historia en una o más historias en las que los usuarios internos hagan cosas "para que" los usuarios reales obtengan los beneficios que necesitan.

Aquí hay un par de artículos que hablan sobre la descomposición de las historias:

http://jpattonassociates.com/the_shrinking_story/

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