El equipo de desarrollo en Scrum es el conjunto de profesionales que se encarga de crear y entregar producto terminado, el cual se pueda poner en producción al final de cada sprint. De esta forma, el desarrollo es incremental.
La organización es la encargada de estructurar y empoderar a lo s equipos de desarrollo para que estos organicen y gestionen su propio trabajo.
Características del equipo de desarrollo
El equipo de desarrollo en Scrum tiene las siguientes características:
Autoorganizado. Sabe cómo y qué va a desarrollar durante el sprint. Se autogestiona en términos de roles y actividades internas.
Multifuncional. Es un grupo multidisciplinario capaz de realizar cualquier actividad, si cuenta con las personas indicadas para la ejecución de las diferentes tareas.
No tiene títulos. Es decir, no hay jerarquía y todos se deben tratar por igual, con respeto y buscando el consenso para sacar lo mejor de las diferentes habilidades individuales.
No hay subequipos. No existen grupos dentro del equipo de desarrollo. Las actividades y responsabilidades se asignan por igual.
No se modifica el equipo de desarrollo hasta terminar el sprint. Esto con el fin de no afectar el desarrollo de las actividades planeadas.
El tamaño óptimo del equipo de desarrollo debe ser lo suficientemente pequeño como para garantizar la agilidad, pero también lo suficientemente grande para completar el trabajo encomendado.
Lo ideal es que el equipo de desarrollo esté conformado por 3 a 9 personas, sin considerar al Product Owner o Scrum Master. Si estas dos personas también se dedican a desarrollar, se deben contar como parte del equipo de desarrollo. Así es posible asegurar que no existan dependencias externas y que no se vuelva inmanejable la gestión del equipo.
Contribución creada con los aportes de: Flavio Rico Mendez, Christian Gómez, DAVID EDUARDO BAEZ SANCHEZ y korpi
Aportes 515
Preguntas 48
Ordenar por:
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
Consiste en un grupo de profesionales que realizan el trabajo de entregar un incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada sprint.
La organización debe poder empoderar al Dev team para que estos se organicen y gestionen su propio trabajo. Deben darles la confianza al equipo.
<h3>Características:</h3>
Autoorganizados.
Multifuncionales
No tienen títulos
No hay subequipos
Solo se pude modificar al terminar el sprint. (No se puede modificar al equipo de desarrollo hasta que acabe el sprint)
El equipo puede ser de 3 a 9 personas sin tomar en cuenta el product owner y al scrum master. Al menos que uno de esos dos hagan código o diseño y que este dentro de sus funciones diarias hacer esta actividades.
LA BASE DEL EQUIPO DE DESARROLLO: El equipo de desarrollo son un conjunto de profesionales que realizan el trabajo de realizar los diferentes incrementos o entregables del Sprint. Así el desarrollo es incremental.
La organización es la encargada de darle lo necesario al equipo de desarrollo para que este se empodere, así sean autoorganizativos y gestionen el tiempo de trabajo en el Sprint.
Características:
Autoorganizado: ellos saben cómo y cuando van a desarrollar dentro del Sprint. Se autogestiona en roles y actividades internas.
Multifuncional: Es un grupo multidisciplinario capaz de realizar cualquier actividad, teniendo las personas necesarias para las diferentes tareas.
No tiene títulos: Es decir se debe tratar por igual, con respeto y deben buscar el consenso para apoyarse con las diferentes habilidades individuales.
No hay sub-equipos: No se pueden hacer grupos dentro del equipo de desarrollo, tiene que existir actividades y responsabilidades iguales.
No se modifica el equipo de desarrollo hasta terminar el Sprint: esto con el fin de no afectar el desarrollo de las actividades que se tienen que realizar.
El tamaño optimo del equipo de desarrollo debe de ser pequeño para garantizar la agilidad, pero también lo suficientemente grande para completar el trabajo encomendado. Entre 3 y 9 personas sin considerar al producto Owner o Scrum Master, si estos dos miembros también se dedican a desarrollar entonces deben de ser incluidos también en el equipo de desarrollo. Así aseguramos que no existan dependencias externas y que no se vuelva inmanejable la gestión del equipo.
La base del equipo de desarrollo generalmente va de acuerdo con el producto a desarrollar, que en si partimos siempre con el Product Owner, que hace las veces del representante del cliente y muchas veces como escudo del equipo de desarrollo (hasta del Scrum Master).
Las actividades en si no necesariamente existe una fórmula mágica, donde se dice en qué actividad participa y en donde no, dado que, de la misma forma que el número del equipo depende del producto, igual sucede que, dependiendo del “producto final” (prefiero nombrarle como un entregable o producto parcial) puedan participar los demás miembros del equipo Scrum. Por ejemplo, al tener una reunión con el cliente y trabajar un mokup para el diseño de entrada en la captura de información de un formulario de denuncias en línea, discutir sobre la cantidad de elementos (campos) a capturar, la factibilidad legal sobre dicha captura, la oportunidad de solicitar las pruebas de la denuncia, los mensajes que deben aparecer para la protección legal del denunciante, etc, etc … en realidad sería un “tiempo muerto” para los desarrolladores, dado que la definición de la base de datos, la estructura que debe tener, el diseño que se debe aplicar, entre otros puntos se decide cuando se tenga claro las cosas del cliente. Ocurre lo contrario cuando se presenta el “entregable” de la funcionalidad de la captura de datos básicos y de los archivos que se adjuntan para recoger las apreciaciones del cliente, donde se obtienen importantes comentarios, como la captura del IP del denunciante (por si hacen denuncias falsas), validar el documento de identidad (con el registro nacional), …
Bueno, una opinión de la experiencia que me tocó seguir con algunos clientes.
Consiste en los profesionales que realizan el trabajo de entregar un incremento del producto “Terminado” que potencialmente se pueda poner en produccion al final de cada sprint
La organización es la encargada de estructurar y empoderar a lo s equipos de Desarrollo para que estos organicen y gestionen su propio trabajo.
Caracteristicas:
Autoorganizado
Multifuncionales
No tiene títulos
No hay subequipos
Solo se puede modificar al termianr el sprint
El tamaño optimo del equipo de desarrollo es lo suficientemente pequeño comom para permanecer agil y lo suficientenmente grande como para completar una cantidad de trabajo significativa. De 3 a 9 personas sin contar con el Product Owner ni el Scrum Master.
Actividad Scrum Master Equipo de Desarrollo
Asistir al Scrum Diario : Dueño del Producto / Scrum Master/ Equipo de Desarrollo
Dar prioridad al Backlog del producto :Dueño del Producto
Asistir a las retrespectivas : Dueño del Producto / Scrum Master/ Equipo de Desarrollo
Hacer pruebas del incremento : Equipo de Desarrollo
Mostrar resultados del sprint en la revisión del sprint : Equipo de Desarrollo
Trabajar en el desarrollo del incremento : Equipo de Desarrollo
Promover la implementación de Scrum : Scrum Master
Crear historias de usuario : Dueño del Producto
Organizar los eventos del equipo : Scrum Master
Implementar mejoras en el proceso : Scrum Master
Representar al cliente : Dueño del Producto
Planear el Sprint : Dueño del Producto / Scrum Master/ Equipo de Desarrollo
Estimar historias de usuarios: Dueño del Producto
Resolver Impedimentos: Scrum Master
Cancelar el Sprint: Dueño del Producto
El equipo de desarrollo se encarga de entregar funcionalidad al final de un sprint.
La empresa o organización se debe encargar de poderle dar el empoderamiento y desarrollo necesario al equipo para que estos organicen y gestionen su propio trabajo.
Característica del equipo de desarrollo
-Autoorganizado, solo se le da el objetivo del sprint.
-Multifuncional, que puede resolver tareas de diferentes tipos
-No tienen títulos, solo personas con más experiencias que otras
-No hay subequipos, es un solo equipo y trabajan a un mismo ritmo
-No se puede modificar el equipo hasta que termine el sprint.
El tamaño debe ser lo suficientemente pequeño para que se ágil y suficientemente grande para cumplir con los objetivos, puede ser entre 3 y 9 personas.
Discúlpame Gerardo por cuestionarte, pero un equipo de Scrum sí se puede dividir en subequipos. Esto ocurre cuando es un proyecto muy grande. De ahí el concepto scrum de scrums
- Asistir al SCRUM diario: SCRUM MASTER y Equipo de Desarrollo.
- Dar prioridad al Backlog: Product Owner.
- Asistir a las Retrospectivas: SCRUM Master y Equipo de Desarrollo.
- Hacer pruebas del Incremento: Equipo de desarrollo.
- Mostrar el resultado del Sprint: Product Owner, SCRUM Master y Equipo de Desarrollo.
- Trabajar en en el desarrollo del incremento: Equipo de Desarrollo.
- Promover la implementacion de SCRUM: SCRUM Master.
- Crear historias de usuario: Product Owner
- Organizar los eventos del equipo: SCRUM Master.
- Implementar mejoras en el proceso: Product Owner, SCRUM Master y Equipo de Desarrollo.
- Representar al cliente: Product Owner.
Planear el sprint: Product Owner y SCRUM Master.
- Estimar historias de usuario: Product Owner y SCRUM Master.
- Resolver impedimentos: SCRUM Master.
- Cancelar el sprint: Product Owner y SCRUM Master.
Deben asistir el Scrum Master y el Product Owner.
Las personas que deben asistir a la Daily Scrum son solo los miembros del Development Team. Ellos son los responsables de que se haga bien. El Scrum Master, el Product Owner o cualquier Stakeholder podrán asistir como oyentes, pero no son necesarios para que se realice y siempre que sea útil para el Development Team.
fuente: https://docs.google.com/document/d/19IlgTXxCxV0qELJxpy2be1aPaXbxuYqLUUZmcbDdIrg/edit#
Solo los miembros del equipo que trabajaron en las tareas durante el sprint anterior deben asistir a la retrospectiva del sprint. Esto incluye al Scrum master (también conocido como líder del equipo Scrum), que organiza la reunión, a los miembros individuales del equipo y, a veces, al encargado del producto.
fuente: https://asana.com/es/resources/sprint-retrospective
¿QUIÉN ESCRIBE HISTORIAS DE USUARIO?
Cualquiera puede escribir historias de usuario. Es responsabilidad del Product Owner asegurarse de que exista una Product Backlog actualizado y priorizado de historias de usuario ágiles, pero eso no significa que el Product Owner es quien los escribe. El transcurso de un buen proyecto ágil, debe contar con historia de usuario escritos por cada miembro del equipo.
Además, ten en cuenta que quién escribe una historia de usuario es mucho menos importante que quién está involucrado en las discusiones de la misma.
fuente: https://scrum.mx/informate/historias-de-usuario#:~:text=¿Quién escribe historias de usuario,Owner es quien los escribe.
¿Quiénes participan en el Sprint Planning?
Durante la planificación interviene todo el Equipo Scrum, es decir, el Product Owner, el Scrum Master y los Developers.
El Scrum Master se debe asegurar de que este evento ocurra y se cumpla su objetivo. También actuará como facilitador para evitar salirse del timebox asignado, o evitar que ciertas personas acaparen todas las conversaciones y decisiones. El Product Owner se debe asegurar de que los asistentes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se relacionan con el Objetivo del Producto. Adicionalmente cualquier miembro del Equipo Scrum puede invitar a otros asistentes para brindar asesoramiento.
fuente: https://ittude.com.ar/b/scrum/que-es-el-sprint-planning/
Algunas persona que tratan de realizar el rol de Scrum master, tienen la creencia que son ellos quienes deciden las actividades que debe desarrollar cada persona, me aprece importante y resaltar que el equipo sea quien decida que actividadesahce cada miembro.
Esta es mi respuesta al ejercicio propuesto, me parece importante acotar que quizá en algunos puntos puedan involucrarse otros roles, pero que la responsabilidad no cae directamente en ellos.
El equipo de desarrollo en Scrum tiene las siguientes características:
* **Autoorganizado.** Sabe cómo y qué va a desarrollar durante el sprint. Se autogestiona en términos de roles y actividades internas.
* **Multifuncional**. Es un grupo multidisciplinario capaz de realizar cualquier actividad, si cuenta con las personas indicadas para la ejecución de las diferentes tareas.
* **No tiene títulos**. Es decir, no hay jerarquía y todos se deben tratar por igual, con respeto y buscando el consenso para sacar lo mejor de las diferentes habilidades individuales.
* **No hay subequipos**. No existen grupos dentro del equipo de desarrollo. Las actividades y responsabilidades se asignan por igual.
* **No se modifica el equipo de desarrollo hasta terminar el sprint**. Esto con el fin de no afectar el desarrollo de las actividades planeadas.
El Equipo de Desarrollo en Scrum es un grupo de profesionales que trabajan juntos para crear el producto durante los sprints. Este equipo es auto-organizado y multifuncional, lo que significa que todos colaboran y comparten responsabilidades para completar el trabajo necesario
Este es mi ejercicio. Realmente sentí mucha ambigüedad en varios items. Espero retroalimentación de quien quiera.
También comparto mis apuntes: <https://puzzle-legend-c4e.notion.site/Comprender-los-roles-de-Scrum-6664b61eaa5a4bc6a4351a777eed364f>, de este segundo módulo, seguramente les pueden dar un buen uso.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?