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

33

¿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.

scrum planning usuario11347
fuente

Respuestas:

25

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.

Lunivore
fuente
3
Semántica ... En mi humilde opinión, esto va en contra de la filosofía ágil; agregando la separación necesaria donde no proporciona ningún valor real más que cálidos sentimientos difusos.
Aaron McIver
55
¿Estás hablando por experiencia o teorizando? Pregunto porque he usado esta plantilla con varios equipos ahora, y descubrí que poner el objetivo primero realmente ayuda a establecer lo que es necesario para lograr la visión del proyecto. Mike Cohn usa "para que" opcionalmente. No lo creo.
Lunivore
1
Veo que esta plantilla es útil para ayudar a comunicar el valor de la tarea técnica a realizar a la PO no técnica. Hay una diferencia entre "como analista de control de calidad, quiero un servidor de integración continua para que la aplicación se pruebe todos los días automáticamente" y "para reducir la cantidad de pruebas manuales necesarias al final del proyecto, y la probabilidad de un error al pasar a producción, como equipo de control de calidad queremos probar un servidor de integración continua ". Mostrar el negocio oculto le da al OP suficiente información para decidir si incluirlo o no.
Soronthar
1
@Soronthar ¿Dónde termina entonces? "Para reducir los niveles de frustración, como equipo de desarrollo queremos hacer nuestras propias reglas" Es de naturaleza circular. Esa es una razón por la que permaneció enfocado en el usuario y eso es todo. Las tareas deben estar ocultas de la orden de compra; ya que la OP no debería tener que preocuparse por esos detalles.
Aaron McIver
9
Ah, y por si no estaba claro, me importa más hacer un trabajo útil que hacer con Scrum. O magra. O BDD. También creo que el trabajo más útil en software tiene que ver con el aprendizaje y la gestión de riesgos. Cuando la metodología se interpone en el camino de hacer un trabajo útil, tiendo hacia el trabajo útil.
Lunivore
12

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.

Kristo
fuente
3
Creo que es peligroso para los equipos difuminar la distinción entre cosas que son directamente valiosas para el usuario y cosas que, con suerte, proporcionan un valor indirecto. En particular, un enfoque de "todo lo que nos gusta es valioso" alienta a los desarrolladores a usar chapa de oro e infraestructura por el bien de la infraestructura. Recomiendo encarecidamente que las personas solo cuenten historias con valor comercial directo hacia la velocidad, porque eso es lo único por lo que los clientes pagarán dinero en efectivo.
William Pietri
3
Bailando con osos. Todo lo que haces que es realmente valioso es sobre todo valioso porque nadie lo ha hecho antes (de lo contrario, hay otras formas más baratas de hacerlo). La mayor parte de lo que hacemos que es valioso es aprender a hacer las cosas nuevas. Las tareas de infraestructura nos ayudan a obtener comentarios sobre las cosas nuevas y a aprender más rápidamente. Estoy con @Kristo si nos ayuda a aprender más rápido.
Lunivore
@Lunivore: la diferencia es que nadie te paga por aprender. Te pagan por lo que haces con el aprendizaje. Los equipos siempre deben tomarse un tiempo para mejorar sus herramientas y sus conocimientos. Pero contarlo como velocidad lo confunde con el tipo de trabajo que el equipo debe hacer.
William Pietri
No se trata solo de herramientas y conocimiento. Experimento de pensamiento de Ashley Johnson: Piensa en el último proyecto que hiciste. Piense en cuánto tiempo tomaría volver a hacerlo con las mismas personas, los mismos requisitos, la misma tecnología, pero habiendo aprendido todo lo que aprendió. Las cotizaciones de los PM se ejecutan en alrededor del 25% al ​​33%; el resto es la cantidad de aprendizaje que hacemos en proyectos de software. Lea la publicación de Dan North sobre Deliberate Discovery: dannorth.net/2010/08/30/introducing-deliberate-discovery
Lunivore
11

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.

William Pietri
fuente
+1: Solución Spike la primera vez, luego refactorícela para que sea mejor y más confiable la segunda vez.
S.Lott
Entonces, ¿cómo se asegura de que las tareas centradas en el desarrollador no se hagan cargo del sprint, especialmente cuando aún no ha establecido una buena métrica de velocidad? No quisiera perderme una entrega temprana porque pasamos demasiado tiempo en cosas que ayudarán a largo plazo.
Kristo
Y de todos modos, debería dedicar tiempo a la reflexión regular y a realizar mejoras en el proceso como esta.
Michael
@Kristo, no creo que su gerente de clientes / productos le permita salirse con la suya. Incluso sin una velocidad establecida, hará una buena suposición y negociará el valor que se entregará para esos primeros sprints. Además, si te disparas como @ S.Lott sugiere que no entregarás de todos modos.
Michael
@Kristo: Te aseguras haciéndolo gradualmente y reflexionando regularmente. Cuando comienzas, todo lo que sabes es que definitivamente estarás haciendo la cantidad incorrecta. Cada semana, hable sobre si debería estar haciendo más o menos infraestructura y si se está enfocando en las cosas de mayor valor. Siempre es un acto de equilibrio.
William Pietri
6

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.

Aaron McIver
fuente
Gracias por esta respuesta Finalmente aclara cómo se debe hacer esto: "el enfoque ideal es colocar el esfuerzo de infraestructura como tareas bajo la historia del usuario donde primero tiene valor".
Igor Popov
En realidad, este trabajo de infraestructura debería ser parte de la Definición de Hecho.
Igor Popov
4

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.

Ladislav Mrnka
fuente
2

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.

Andy Wiesendanger
fuente
Algunos equipos trabajan de esa manera, pero eso hace que sea más difícil medir el valor entregado. Personalmente, sugiero que los equipos solo creen historias que tengan valor comercial. (Los picos tienen valor comercial porque la gente del producto está comprando información sobre opciones futuras y sus costos.)
William Pietri
Pero, ¿qué es el valor comercial? Es un término amplio, y cualquier cosa que permita a una empresa lanzar software antes / mejor / etc. tiene valor para esa empresa.
Andy Wiesendanger
La distinción que estoy haciendo es entre cosas de valor directo principalmente para el equipo y cosas de valor directo principalmente para las personas a las que realmente estás allí para servir. Creo que solo debes contar el último hacia la velocidad porque ese es el único valor que finalmente importa. Las cosas que se hacen para ayudar a mejorar esa creación de valor se contabilizan en velocidad a través de una velocidad mejorada a largo plazo. Contarlo de inmediato distorsiona los incentivos y cuenta dos veces la ganancia.
William Pietri
2

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.

BillThor
fuente
1
+1: Si esto no está en su lugar, Agile es realmente difícil. Infraestructura y plataforma estables y probadas, una especie de requisito previo para la agilidad.
S.Lott
1

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.

Chris
fuente
0

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

Steven A. Lowe
fuente
2
XP no lo recomienda. Algunas personas lo hacen, pero definitivamente no es parte de la Programación Extrema según lo definido por Beck, et al. Personalmente, creo que Iteration Zero es una mala idea.
William Pietri
Otro problema, no siempre comienza en 0, puede darse cuenta de que necesita algo ahora o en el próximo sprint.
Andy Wiesendanger
@William: ver "Planificación de la programación extrema" por Kent Beck, Capítulo 15, página 66.
Steven A. Lowe
Eso no es una recomendación. Dicen que es una idea y dicen: "Si no ha trabajado con su tecnología antes, considere pasar dos semanas obteniendo la tecnología justo antes de comenzar a programar". Y no sugieren "toda la infraestructura", solo pruebas automatizadas básicas, compilar e implementar scripts.
William Pietri
@William: aha, veo a qué te refieres. No me refería a toda la infraestructura de software , solo a las cosas que mencionaste
Steven A. Lowe,
0

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.

P Shved
fuente