¿Cómo explica un equipo Scrum las tareas de infraestructura en la reunión de planificación?

¿Cómo explica un equipo Scrum las tareas de desarrollo / infraestructura en la reunión de planificación?

A primera vista, no parecen historias de usuarios, ya que no ofrecen valor al usuario final.

Sin embargo, adjuntarlos como tareas a una historia de usuario particular a veces tampoco tiene sentido. Por ejemplo, supongamos que la tarea es: "Configurar Bamboo". Esa tarea no es necesaria para completar ninguna historia de usuario, ya que el equipo podría construir e implementar manualmente. Por lo tanto, adjuntarlo a una historia de usuario no tiene sentido ya que esta tarea no es necesaria para completar la historia de usuario.

Entonces, esto sugiere que estas tareas se convierten en historias de usuarios. Pero luego, si la historia del equipo los señala, entonces esto cambia la velocidad, lo cual es extraño ya que el Propietario del producto quiere saber la velocidad contra su cartera de pedidos, no contra su cartera de pedidos con un montón de historias técnicas de usuarios adjuntas.

En realidad no son historias de usuarios. Son historias de partes interesadas. A menos que el software sea pagado directamente por los usuarios, es raro que una historia se cree completamente para su beneficio.

Te doy un par de ejemplos:

• artículos con palabras clave, que permiten a los anunciantes tener anuncios más efectivos
• CAPTCHA, que están ahí para evitar que los moderadores tengan que lidiar con el spam manualmente.

La mayoría de las historias técnicas en realidad proporcionan un beneficio comercial, pero rara vez es para los usuarios. La redacción de una manera diferente puede ayudar. Normalmente uso la plantilla de inyección de características de Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Esto reconoce explícitamente todo tipo de partes interesadas, incluido el equipo de desarrollo. Ahora también puede expresar sus historias técnicas, mencionando el beneficio comercial:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

He escrito un par de publicaciones en el blog sobre esto: No son historias de usuarios , y la función de inyección y manejo de historias técnicas . Espero que ayuden.

La velocidad es una medida de la capacidad del equipo para realizar un trabajo útil (en lugar de arrastrar). Las tareas de infraestructura aún brindan valor al usuario final, aunque indirectamente, al hacer que el equipo sea más eficiente a largo plazo. No tengo ningún problema para rastrear estas cosas como historias de usuarios (el usuario es el equipo de desarrollo en este caso) y priorizarlas adecuadamente. Un propietario del producto en buena comunicación con el (los) cliente (s) debería ser capaz de determinar dónde pueden encajar tales tareas sin interrumpir los entregables.

Hazlos gradualmente.

Si ningún interesado lo quiere, no lo convierta en una historia. Solo cuídalo, poco a poco. Por ejemplo, la primera vez que despliega manualmente. La segunda vez, automatizas un poco. La tercera vez, automatizas un poco más. Finalmente, su compilación no es el mayor problema, por lo que se concentra en otra cosa.

Tendrá más de estas tareas centradas en el desarrollador al principio, y eso está bien; Su velocidad (medida por las historias) será más baja. Esa es una representación correcta de la situación. Pero siempre tendrá algunos, por lo que es importante que el equipo tenga el hábito de hacer lo necesario para mejorar el proceso.

En mi humilde opinión, el enfoque ideal es colocar el esfuerzo de infraestructura como tareas bajo la historia del usuario donde primero tiene valor; como has mencionado

Tomando tu ejemplo; La construcción y despliegue manual implica que es un esfuerzo continuo y no tiene forma de finalización. Existe indefinidamente.

Lo mismo podría decirse del código que automatiza cualquier parte del esfuerzo en una aplicación típica que se realizó previamente de forma manual. Definir este esfuerzo como una tarea bajo una historia de usuario define completo; que por su propia naturaleza tiene valor para el usuario final.

Ciertamente, podría compilar e implementar la aplicación cada sprint, pero eso se convierte en parte de las tareas diarias que no se rastrean formalmente a través del trabajo atrasado y luego todo se vuelve discutible.

Las historias de usuario definen un valor de negocio desde la perspectiva del usuario. Debido a esa infraestructura, las tareas generalmente se consideran un "desperdicio". No significa que no sean necesarios. Significa que realizar más tareas de infraestructura generará menos valor comercial. Debido a esa infraestructura, las tareas no deben considerarse como una historia de usuario y no deben adjuntarse a ninguna historia de usuario.

En una reunión de planificación, el equipo debe considerar qué tareas de infraestructura serán absolutamente necesarias durante el próximo sprint. El compromiso se realizará teniendo en cuenta estas tareas de infraestructura. Afectará la velocidad del equipo, que es el resultado correcto porque la velocidad mide cuánto valor comercial puede ofrecer el equipo.

Nunca equiparé las historias de los usuarios a tener que ofrecer valor al usuario final. Puede ser común, pero no es cómo manejamos las historias de los usuarios. A veces, este tipo de tareas se consideran picos, pero también hemos tenido historias de usuarios regulares, puntos estimados como cualquier otra historia de usuario.

Por lo que he visto, gran parte de la infraestructura se considera un hecho. Esto incluye cosas como:

• Sistema de control de revisiones;
• Sistema de construcción automatizado;
• IDE y otras herramientas para desarrolladores;
• Servidores de desarrollo;
• Proceso de implementación; y
• Proceso de proyecto y estándares.

La mayoría de las metodologías con las que he trabajado no les prestan mucha atención. Estos forman lo que yo llamo Versión 0. Estas cosas deberían estar en su lugar antes de comenzar el desarrollo. Una vez que comience a trabajar en las historias, cualquier cambio en estas cosas podría rastrearse como mejoras en el proceso.

Si bien el equipo de desarrollo puede tener aportes, la mayoría de estos elementos deben ser manejados por un equipo de soporte del proyecto. La estandarización de estos elementos en múltiples proyectos debería tener una recuperación significativa para la organización.

Considera lo siguiente:

• El equipo de Scrum agrega características principales a un conjunto de productos existente.

• Existe la necesidad de actualizar la tecnología / herramientas / utilidades de desarrollo para mantenerse actualizado según las mejores prácticas de ingeniería.

• Tiene sentido cargar por adelantado una versión con este trabajo para que en el transcurso de la versión se puedan resolver los problemas de Sprints.

• Dado que la empresa obtiene un valor indirecto de estos elementos, sugiero que, en aras de la transparencia, se trata de elementos de la cartera de productos (PBI).

• El equipo clasifica estos artículos y los trata como si fueran cualquier PBI.

Este problema para mí se reduce al hecho de que no quiero perder el tiempo tratando de descubrir cómo ocultar este trabajo como tareas debajo de otros PBI más centrados en los negocios.

No quiero que el tamaño de PBI esté sesgado por este tipo de trabajo de infraestructura. Quiero ver lo que se está haciendo y entender lo que estoy pagando.

También creo que es valioso hacer que el equipo entienda el compromiso que está haciendo el negocio al invertir en la infraestructura requerida para ofrecer soluciones de calidad.

XP recomienda tener una "iteración cero" donde todas las herramientas e infraestructura estén configuradas. Escribir historias para estos es opcional, pero probablemente sea una buena idea. Poder probar su infraestructura (compilación incremental, prueba automatizada e implementación, notificaciones, etc.) es beneficioso

En nuestro equipo hacemos lo siguiente:

1. Asume un factor de enfoque más bajo .
2. Intente incluir tales tareas en las historias de usuarios que realmente necesitan implementarlas.
3. Si algunas tareas son totalmente necesarias, pero no proporcionan un valor comercial directo (como migrar pruebas unitarias de un marco a otro), al comienzo del sprint creamos una lista de "tareas continuas" . Estas son tareas relacionadas con el desarrollo que no son historias, pero el equipo de desarrollo quiere que se hagan. Enumeramos estas tareas en nuestro pizarrón, manteniéndolo separado de las historias. Durante el sprint, en cada reunión diaria revisamos lo que se ha hecho para lograrlos.

El paso 2 es el más importante. Como en una práctica ágil, en Scrum intentas hacer lo menos posible para cumplir tus tareas. Tómelo como una forma de no desperdiciar su vida haciendo trabajo innecesario: mi experiencia muestra que hasta el 50% de las cosas "geniales" terminan abandonadas y sin mantenimiento a largo plazo.