¿Cuáles son los roles clave en un equipo Scrum?

Según tengo entendido, el propietario del producto, el Scrum Master y el equipo de desarrollo son los roles principales en un equipo Scrum. Tengo que configurar un equipo .Net Scrum con 5-8 miembros. No tengo suficiente conocimiento sobre Scrum. ¿Alguien puede dar una solución a estos problemas?

  • ¿Cuáles son los roles clave que deben estar en un equipo Scrum?
  • ¿Quién lleva a cabo las revisiones de código en un equipo Scrum?
  • ¿Los equipos Scrum tienen un rol llamado líder de equipo y líder técnico?
También le recomiendo encarecidamente que transmita de inmediato sus inquietudes a su gerente de contratación. No estas solo. Dentro de su propia organización, hay personas con experiencia que pueden ayudarlo a poner los pies en el suelo. "No hay vergüenza en alcanzar ese salvavidas, ni en ser el que dice que lo necesitas..."

Respuestas (3)

Roles principales en Scrum

¿Cuáles son los roles clave que deben estar en un equipo Scrum?

Scrum define solo tres roles principales para el marco.

  1. Un propietario del producto, cuyo rol es una especie de fusión de un gerente de producto tradicional y un patrocinador del proyecto, pero tiene mucha más interacción con el equipo de desarrollo de lo que requeriría un rol más tradicional.

  2. Un Scrum Master, quien es el árbitro del proceso que asegura que se sigue la metodología. Un Scrum Master también es responsable de entrenar al equipo y a la organización sobre cómo aprovechar al máximo los procesos y artefactos de Scrum.

    El scrum master actúa como entrenador, guiando al equipo a niveles cada vez más altos de cohesión, autoorganización y desempeño. Mientras que el entregable de un equipo es el producto, el entregable de un maestro de scrum es el equipo autoorganizado.

    Sims, Chris; Johnson, Hillary Louise (2011-02-15). Los Elementos de Scrum (p. 74). Dymaxicon. Versión Kindle.

  3. Un equipo de desarrollo, que es un grupo cohesivo, autoorganizado y multifuncional que contiene todas las habilidades necesarias para cumplir con los objetivos del proyecto.

    Los equipos Scrum son altamente colaborativos; también se autoorganizan. Los miembros del equipo tienen autoridad total sobre cómo se realiza el trabajo. Solo el equipo decide qué herramientas y técnicas usar, y qué miembros del equipo trabajarán en qué tareas.

    Sims, Chris; Johnson, Hillary Louise (2011-02-15). Los Elementos de Scrum (Ubicaciones Kindle 976-978). Dymaxicon. Versión Kindle.

Reseñas de código

¿Quién lleva a cabo las revisiones de código en un equipo Scrum?

Las revisiones de código son una práctica, no un requisito de marco, y no uno que se adopte universalmente. Por ejemplo, consulte las revisiones de código consideradas dañinas .

Sin embargo, algunos equipos de Scrum adoptan revisiones de código, ya sea porque se identifican como útiles durante una Retrospectiva de Sprint o porque la organización matriz las requiere. A menos que la organización principal proporcione un mandato, la forma en que se manejan las revisiones de código es un problema que un equipo de desarrollo autoorganizado debe resolver por sí mismo.

En última instancia, el objetivo es un código mantenible de alta calidad. Si el equipo de desarrollo encuentra útiles las revisiones de código para cumplir con su "definición de hecho" aceptada, genial. Si no, tal vez el desarrollo basado en pruebas o alguna otra práctica funcione igual de bien (¡o mejor!) para un equipo en particular.

Su trabajo no es encargar a alguien que haga revisiones de código; su trabajo es arbitrar el proceso para asegurarse de que el equipo esté continuamente inspeccionando y adaptando sus prácticas.

Títulos para los miembros del equipo de desarrollo

¿Los equipos Scrum tienen un rol llamado líder de equipo y líder técnico?

El marco Scrum promueve la propiedad colectiva del código y el equipo tiene éxito o fracasa como grupo. Como resultado, los títulos que diferencian a los miembros del equipo son la antítesis de los principios de Scrum, aunque, sin embargo, la organización matriz los utiliza en las descripciones de puestos y los archivos de Recursos Humanos.

Mírelo de esta manera: si designa a Bob como el líder del equipo, entonces le está asignando la responsabilidad de los entregables específicos. ¿Por qué Alice debería asumir las responsabilidades de Bob?

Del mismo modo, si formalmente convierte a Alice en "la persona de control de calidad", ¿por qué Alice debería tomar la propiedad colectiva del código o trabajar en historias de arquitectura? Sin duda, se la incorporó al equipo para asegurarse de que hubiera algún conocimiento de control de calidad especializado disponible para el equipo, pero "funcionalidad cruzada" no significa responsabilidades aisladas dentro del proyecto.

Los miembros del equipo tendrán títulos dentro de la organización, que ocasionalmente reflejan las habilidades que aportan a un equipo de proyecto. Sin embargo, depende del equipo autoorganizarse y distribuir la responsabilidad dentro del equipo. Como Scrum Master, solo debe intervenir si es obvio que el equipo no se está organizando a sí mismo, lo que se mide por si el equipo está alcanzando o no sus Sprint Goals y la "definición de hecho".

Asignar roles de liderazgo dentro del equipo no es una práctica ágil y ciertamente no es Scrum. Si se encuentra en una posición en la que esto es necesario, entonces debería revisar su proceso general y tratar de identificar qué impide la autoorganización del Equipo de Desarrollo.

Ya Esta es una excelente respuesta. ¡Respuesta tardía pero una respuesta más reciente!
"Excelente." Un espléndido resumen.

Para citar la Guía de Scrum , "Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; no hay excepciones a esta regla"; En ese sentido, sería contraproducente restringir a los desarrolladores a deberes específicos. La idea es que el equipo de desarrollo se autoorganice para realizar tareas y superar obstáculos a medida que surjan las necesidades (y los recursos estén disponibles).

En cuanto a las revisiones de código, existen muchos métodos para realizar revisiones de código (consulte el capítulo 3 de Los secretos mejor guardados de las revisiones de código entre pares ).). Depende de usted y su equipo llevar a cabo y evaluar los métodos de revisión de código que mejor complementen la cultura de su equipo (aunque una rama de control de calidad separada puede recopilar y analizar métricas que pueden ayudar a evaluar la efectividad de un método de revisión de código) . Si tiene desarrolladores que son mejores con el código del cliente, puede ser un beneficio para ellos revisar el código del cliente para una mejor detección de defectos. También puede ser un beneficio para los desarrolladores que no están familiarizados con el código del cliente revisarlo para que se familiaricen más con el lado del cliente en caso de que necesiten intervenir y hacer la programación del cliente en el futuro. Un beneficio de Agile y Scrum es que el equipo de desarrollo puede autoorganizarse para probar la efectividad de varios métodos de revisión de código. A pesar de todo, el equipo de desarrollo debe ser responsable de revisar el código creado por el equipo de desarrollo. También puede haber un equipo de control de calidad externo que revise más el código, pero eso no es necesario para una implementación básica de revisiones de código o scrum.

¿Cuáles son los roles clave que deben estar en un equipo Scrum?

Los propietarios de productos, los desarrolladores y el personal de control de calidad son clave para el éxito de los proyectos basados ​​en pilas .NET. Tenga en cuenta que no he mencionado el rol de Scrum Master. Lo explicaré más tarde.

Si el equipo está desarrollando una API web, un sitio web ASP.NET MVC, una aplicación de escritorio o .NET Xamarin Mobile, todo lo que necesita son propietarios de productos, desarrolladores y personal de control de calidad. Sin embargo, si está desarrollando una solución .NET basada en la nube, también necesitará el rol de ingeniero de DevOps que administrará la nube. Si está utilizando CICD, entonces el ingeniero DevOps es aún más necesario para configurar las canalizaciones de CICD.

Los desarrolladores pueden tener una persona con rol de Arquitecto (al menos 7 años de experiencia en .NET). El arquitecto será una persona que ayudará a los propietarios de productos a diseñar correctamente la función, los ayudará en los puntos de la historia y apoyará a los desarrolladores en las decisiones de diseño.

De manera similar, Quality Assurances podría tener personal capacitado para pruebas automatizadas como xUnit, Selenium y JUnit.

El rol de Scrum Master realmente no es útil a menos que la persona sea un administrador de productos de software consumado. En lugar de contratar a un Scrum Master, contrate a un Agile Coach que apoye al equipo. Si todo lo que Scrum Master está haciendo es reunir a las personas en un momento específico en Zoom, Skype o en un lugar de una oficina, entonces es mejor que lo reemplacen las alertas de Google Calendar. Los equipos de software son los que más sufren si el líder no es un profesional de software consumado. Alguien tiene que administrar JIRA o un sistema de emisión de boletos similar. Scrum Master podría usarse como un rol de seguimiento en tickets, hoja de ruta, lanzamientos, hitos y entregables.

¿Quién lleva a cabo las revisiones de código en un equipo Scrum?

El arquitecto o, por lo general, otros 2 miembros del equipo revisan el código.

¿Los equipos Scrum tienen un rol llamado líder de equipo y líder técnico?

Los desarrolladores deben ser una combinación de pasantes, desarrolladores junior, desarrolladores senior, líderes técnicos y arquitectos.

Por lo general, hay equipos pequeños de 1 pasante, 1 desarrollador junior, 2 desarrolladores senior y 1 líder técnico. Si tiene 2 de estos equipos, entonces 1 Arquitecto para mediar en la discusión entre estos dos equipos.

Cada equipo debe tener 1 Product Owner. Si hay más de 1 propietario del producto, uno será el propietario principal del producto. El propietario del producto es el rol más crítico. Crea historias y prioriza la acumulación. Si los desarrolladores no obtienen historias, no podrán desarrollarlas y el control de calidad no podrá probarlas correctamente. Es mejor tener 2 pasantes de productos con cada uno de los propietarios de productos para facilitar la escritura precisa de la historia.

Si el trabajo es intenso, entonces cada equipo de 5 desarrolladores debe tener 1 persona de control de calidad y 1 ingeniero de confiabilidad del sitio o ingeniero de DevOps.