El equipo de desarrolladores siempre tiene tareas internas (como mejoras ambientales, mejoras de procesos, etc.). A veces pueden estar relacionados con el proyecto actual, a veces no.
No hay problema, si estas tareas están relacionadas con el proyecto actual (por ejemplo, hacer un proceso de Integración Continua para el proyecto actual). El Product Owner no tendrá objeciones para agregar estas tareas a Project Backlog y puede establecer prioridades para todas ellas.
Pero, ¿qué debemos hacer si estas tareas son comunes y no están relacionadas con el proyecto actual (por ejemplo, queremos establecer convenciones de código y utilizar un verificador de estilo de código automático en nuestro proceso). Incluso si persuadimos al Product Owner para que agregue esta tarea a Product Backlog, estoy seguro de que establecerá una prioridad para esta tarea lo más pequeña posible. Y tiene sentido para él, porque la realización de esta tarea no dará un gran beneficio para el proyecto actual. Pero, por otro lado, aumentará la calidad del equipo de desarrolladores en los proyectos actuales y en todos los demás (PO, por supuesto, no se preocupa en absoluto por otros proyectos).
Y en general, creo que no es una buena idea agregar al Product Backlog tareas que no estén relacionadas directamente con el producto .
Pero si no informamos al Product Owner sobre estas cosas y no las agregamos a Product Backlog, sino que las hacemos durante Scrum, entonces Scrum perderá su transparencia (uno de los tres pilares de Scrum, como dijo la Guía de Scrum).
Entonces, ¿qué debemos hacer con este tipo de tareas?
Este es un tema complejo, pero la respuesta corta es:
El Product Backlog es una forma en que el propietario del producto hace que el costo de hacer negocios sea visible para la organización. Eso significa que algunas historias de procesos de equipo deben colocarse en el Product Backlog y priorizarse adecuadamente para que Scrum funcione.
Considere los siguientes ejemplos:
Como nuevo desarrollador
, necesito configurar mi entorno de desarrollo
para poder trabajar de manera productiva en los elementos de la cartera de productos.
Como equipo de desarrollo
, necesitamos un servidor de integración continua instalado y configurado
para que podamos estar seguros de que cada Sprint ofrece un incremento potencialmente entregable.
Estas historias pertenecen al Product Backlog. De hecho, la primera historia debe agregarse una vez a la parte superior de la cartera de pedidos para cada nuevo desarrollador que se una al proyecto, ya que es algo que debe suceder, requiere la asignación de recursos del presupuesto del proyecto y consume la capacidad del equipo hasta que el nuevo desarrollador tenga una entorno de trabajo funcional.
Aunque este tipo de historias no agregan valor al producto , agregan valor al proyecto . Además, la Ley de Transparencia de CodeGnome dice "¡Ningún trabajo invisible, nunca!" Eso significa que estos tipos de historias de procesos deben ser visibles porque representan el trabajo que debe realizarse y crearán un lastre en el proyecto hasta que se implementen correctamente.
Algunas cosas, como la instalación de un nuevo IDE, pueden considerarse simplemente una sobrecarga del proceso. Hacer la distinción entre la sobrecarga del proceso que debe estar únicamente en el Sprint Backlog y las historias que afectan el Sprint Goal y la capacidad del Sprint en sí, requiere que cada equipo desarrolle algunas definiciones prácticas y criterios de filtrado.
Realmente no hay una respuesta de "talla única", pero la distinción entre el trabajo general y el que consume capacidad ciertamente debe ser resuelta por el equipo. Una vez que se hace la distinción, se debe seguir el proceso adecuado para cada tipo de trabajo de manera consistente y con tanto rigor como el equipo pueda manejar.
El PO debe ser consciente de esto, y ayudaría a facilitar una discusión entre los desarrolladores y los PO para que conozca el dolor y el impacto a corto/largo plazo de no hacerlo. Tratar de hacer las cosas bajo el radar es una excelente manera de tener clientes enojados (incluido el PO) y el equipo siempre debe esforzarse por ser transparente sobre los problemas que tienen.
En cuanto a si debería incluirse o no en la cartera de pedidos, le preguntaría al equipo qué quieren hacer. Probablemente va a ir 1 de 2 maneras:
Si la tarea para el desarrollador vuelve a ocurrir como: "Complete su hoja de tiempo para que le paguen", eso es una sobrecarga y no se acumula en la iteración.
Si la tarea o la historia proporciona un valor discreto y tangible, ya sea funcional o no funcional, se incluye en el backlog del producto y, finalmente, en el backlog de iteración una vez que el equipo lo prioriza y lo compromete.
Trabaje con el propietario de su producto para que comprenda el valor de las tareas no funcionales, ya que casi siempre afectan la calidad del producto o la capacidad del equipo para entregar un volumen determinado de elementos funcionales en el futuro.
Por lo general, cuando escucho a los desarrolladores de mis equipos describir un trabajo pendiente como no funcional, interpreto que estamos trabajando con un trabajo pendiente "no suficientemente explicado para que el PO entienda el valor" que requiere algo de trabajo de comunicación.
¿Podríamos realmente refinar la pregunta de cómo reportamos el tiempo de trabajo efectivo?
Estoy absolutamente de acuerdo con Code Gnomes: "Ningún trabajo invisible nunca", pero en la situación en la que tiene una pérdida continua de tiempo de recursos, potencialmente fuera del proyecto, por ejemplo.
No creo que estos deban estar en la cartera de pedidos, pero debe informar que el tiempo de trabajo efectivo del recurso es inferior al tiempo completo. Sé que en TFS puedes mostrar esto, y si mantienes un plan de proyecto tradicional, obviamente puedes hacerlo, pero no conozco ninguna otra herramienta.
Ashok Ramachandran
Todd A. Jacobs
Ewan