Nuestro equipo de ingeniería usa scrum ágil y finalmente estamos creciendo lo suficiente como para poder delegar más funciones de scrum a más miembros, incluidos algunos de los ingenieros como yo.
Una función que estamos introduciendo y para la que me he ofrecido como voluntario es lo que llamamos el "gorila".
El papel de un portero en este contexto es:
Una cola de trabajo separada del sprint está disponible para que los gorilas trabajen durante el tiempo de inactividad. Esta cola son tareas pequeñas y de baja prioridad que no afectan las necesidades comerciales ni los objetivos del sprint. El progreso de estas tareas debe detenerse para que el portero pueda cumplir con su papel.
Estoy buscando una definición mucho más formal de este rol, y cualquier información al respecto que pueda tener en mis manos. ¿Existe tal información? ¿Este rol tiene otros nombres que producen mejores resultados de búsqueda?
Como han dicho otros, no existe un rol llamado "Bouncer" en Scrum. La Guía Scrum define exactamente tres roles dentro del Equipo Scrum :
El Equipo Scrum está formado por un Product Owner, el Equipo de Desarrollo y un Scrum Master.
Debido a que un Equipo Scrum es multifuncional, el equipo ciertamente puede elegir realizar cualquier actividad que avance sus Objetivos de Sprint, y puede hacerlo de cualquier manera que tenga sentido para el equipo. Sin embargo, definir roles adicionales (en lugar de procesos) es un antipatrón de Scrum que generalmente indica un problema de proceso subyacente.
Su equipo está definiendo un rol llamado "Bouncer" para realizar la clasificación y brindar apoyo. Cuando tu dices:
El papel de un portero en este contexto es:
comunicar y realizar un seguimiento del soporte,
investigar los problemas entrantes y
escalar según corresponda
está describiendo claramente una función de soporte recurrente en lugar de un desarrollo de productos o un trabajo con límite de tiempo, que son los dominios para los que se diseñó Scrum. Eso no significa que Scrum no permita la corrección de errores o el soporte; simplemente significa que diseñar un proceso de soporte fuera del marco Scrum y luego calzarlo nuevamente en Scrum es generalmente The Wrong Thing to Do™.
En Scrum, todo el trabajo debe priorizarse en el Product Backlog, estimado durante la Planificación del Sprint, y debe estar relacionado con el Sprint Goal actual. En un marco Scrum correctamente implementado, los errores o defectos externos al Sprint actual se colocan en el Product Backlog, se analizan y priorizan durante el Refinamiento del Backlog, y luego se planifican si están dentro del alcance durante la Planificación del Sprint.
Esto tiene sentido porque Scrum es principalmente un marco de gestión de proyectos y su objetivo es gestionar proyectos que tienen un alcance definido y una duración limitada. El soporte continuo o los procesos repetitivos no son proyectos y pueden ser difíciles de administrar dentro de un marco que está diseñado para cajas de tiempo en lugar de ciclos de procedimiento.
En mi opinión, los errores o defectos en el producto de un proyecto definitivamente pertenecen al Equipo Scrum, pero deben manejarse dentro del marco Scrum. Sin embargo, el soporte continuo no debe ser parte de Scrum a menos que se haya tomado una decisión comercial para reducir permanentemente la capacidad del equipo para asignar un espacio de tiempo para el soporte dentro de cada Sprint.
Una mejor alternativa es configurar un proceso de soporte separado , tal vez usando Kanban u otra metodología ágil impulsada por ciclos o colas, que luego podría manejar los problemas directamente o retroalimentarlos al Backlog de productos de Scrum, según corresponda. Conceptualmente, dicho proceso de soporte está fuera del marco Scrum, ¡pero eso no significa que deba estar aislado!
He usado Scrum para procesos administrativos, de soporte y administrativos que no están basados en proyectos. se puede hacer Sin embargo, la característica central de Scrum es la caja de tiempo, y el soporte no está inherentemente impulsado por estimaciones o cajas de tiempo.
La única forma en que he podido hacer que Scrum funcione en tales esfuerzos que no son proyectos es:
Si no está de acuerdo con todo lo anterior, entonces Scrum no es el marco adecuado para su proceso de soporte. Evalúe Kanban como una alternativa para el trabajo controlado por colas, o encuentre otro proceso que sea más adecuado para sus necesidades comerciales y políticas.
Para obtener más información sobre cómo manejar las tareas de soporte continuo o recurrente dentro de Scrum, o sobre por qué Scrum suele ser la opción incorrecta para administrar un proceso de soporte continuo, consulte las siguientes respuestas relacionadas:
Parece que está describiendo un rol de soporte clásico fuera de Teams Sprint. Clasificar la cola de soporte para dejar espacio al equipo de scrum para hacer su trabajo principal.
Felicitaciones a usted.
¿Quizás debería considerar configurar un tablero Kanban para respaldar su trabajo de clasificación?
Pero para responder formalmente a su pregunta, no existe un rol de scrum tan ágil para describir el trabajo que está haciendo. Esto se debe a que el marco Scrum es liviano y permite flexibilidad para que los equipos lo implementen de una manera que funcione para ellos.
Saludos
Scrum prescribe solo tres roles: Scrum Master, Product Owner y Delivery (o Dev) Team.
Dicho esto, nada impide que el equipo decida cómo quieren abordar los desafíos que enfrentan. Si tener a alguien que asuma estas responsabilidades funciona para su equipo, genial. Sin embargo, no encontrará ninguna definición formal.
Sin embargo, una pregunta que tengo es por qué, cuando no está evaluando el soporte, no solo ayudaría a otros miembros del equipo en el trabajo de sprint. Parece que te estás separando artificialmente del equipo.
Scrum solo proporciona tres roles: Scrum Master, Product Owner y Development Team. No hay otros roles definidos en Scrum. Dado que Scrum permite que se deleguen algunos elementos de cada función, puede optar por dar un nombre a la función asignada a la persona a la que se le delegan ciertas tareas y este nombre depende de su organización.
El rol de propietario del producto es responsable de la gestión de la cartera de productos, y parece que la mayoría de estas tareas entran directamente en ese ámbito. Específicamente, la Guía Scrum dice esto sobre el propietario del producto :
El propietario del producto es la única persona responsable de gestionar la cartera de productos. La gestión de la cartera de productos incluye:
- Expresar claramente los elementos del Product Backlog;
- Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones;
- Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
- Asegurarse de que el Product Backlog sea visible, transparente y claro para todos, y muestre en qué trabajará el Equipo Scrum a continuación; y,
- Asegurarse de que el equipo de desarrollo comprenda los elementos de la cartera de productos al nivel necesario.
El propietario del producto puede hacer el trabajo anterior o hacer que el equipo de desarrollo lo haga. Sin embargo, el propietario del producto sigue siendo responsable.
Si los problemas se informan desde fuera del equipo Scrum (que consta de los tres roles), esos problemas tienen un impacto en la cartera de productos. Cosas como informes de errores, cambios en funciones existentes o solicitudes de nuevas funciones serían elementos nuevos o modificados de la Lista de Producto.
Tenga en cuenta que el propietario del producto puede delegar algunas de estas responsabilidades al equipo de desarrollo. Por supuesto, hacer esto reducirá la capacidad del equipo. Sin embargo, involucrar al personal técnico antes puede llevar a elementos de la cartera de productos más refinados a las sesiones de planificación de Sprint. Esta es una compensación que el equipo (o, a veces, la organización) debe hacer.
Una cosa que menciona, "comunicar y rastrear el soporte" también puede caer en el rol de Scrum Master . Scrum Master brinda apoyo no solo al equipo de desarrollo, sino también al propietario del producto y a la organización. El Scrum Master debería ayudar al propietario del producto a encontrar formas de lidiar con estas solicitudes entrantes y métodos para administrar adecuadamente la cartera de productos, incluida la redacción de buenos elementos de la cartera de productos. El Scrum Master también es responsable de asegurarse de que se elimine cualquier impedimento para el Equipo de Desarrollo.
Dejando a un lado toda esa definición de Scrum, puede identificar otras tareas que deben realizarse durante el transcurso de un Sprint y quién será responsable de manejarlas. Y depende de usted identificar adecuadamente estos roles y encontrar buenas maneras de delegarlos, ya sea de forma permanente o rotativa.
Personalmente, creo que el propietario del producto, quizás con el apoyo de un miembro del equipo de desarrollo (quizás de forma rotativa) y el Scrum Master, debería tomar la iniciativa en estos elementos. Investigar los problemas entrantes y convertirlos en elementos de la cartera de productos es definitivamente una función del propietario del producto, que se puede delegar. Trabajar para resolver los impedimentos es definitivamente una función de Scrum Master, que puede incluir la escalada adecuada. El soporte de seguimiento puede ser una responsabilidad compartida, pero consideraría que esta es una tarea que debe realizar el Scrum Master para permitir que el Equipo de desarrollo se centre en el desarrollo en lugar de realizar un seguimiento del trabajo de otras personas.
Vicki Laidler
Matt Walther
alan larimer