Roles
Los miembros de un equipo Scrum realizan al menos uno de tres roles. La mayoría de las personas realizan el rol de equipo, que tiene la responsabilidad de crear el software. Además, el propietario del producto se asegura de que los clientes están representados en el equipo y el ScrumMaster ayuda al equipo y al propietario del producto a seguir los procesos de Scrum eficazmente.
En este tema
Equipo
El equipo está compuesto de los individuos que son responsables de la creación del software. Selecciona los casos de usuario al principio del sprint, colabora para implementar y probar los casos de usuario durante el sprint y presenta el software finalizado en la revisión del sprint. El equipo se organiza por sí solo, ya que se administra a sí mismo y administra su trabajo. Además, intercambia funciones, ya que contiene los conocimientos necesarios para entregar los casos de usuario en el trabajo pendiente del producto. MSF for Agile Software Development v5.0 no distingue los roles del equipo por criterios como la disciplina de ingeniería o el área de especialización.
Cualidades de un buen equipo
Un buen equipo de software es difícil de reunir, además de que lleva tiempo crearlo. Hay ejemplos de buenos equipos a nuestro alrededor: equipos quirúrgicos, equipos de baloncesto o perros pastores y sus dueños. Cada miembro del equipo puede tener su especialidad, aunque el equipo funciona en conjunto y tiene éxito o fracasa en conjunto.
Los buenos equipos de software también se componen de individuos que se unen para conseguir un objetivo común. Un equipo de software no se debería percibir como una colección de expertos que realizan solo las tareas en las que están especializados por turnos. En su lugar, un equipo debe ser un grupo de personas cuyas habilidades y experiencia colectivos sobrepasa el conocimiento de cada persona. Por medio de la colaboración, la comunicación, la confianza y la franqueza, un equipo puede conseguir el éxito e ir más allá de las capacidades de sus miembros para convertirse en una sola unidad de alto rendimiento.
Un buen equipo cuenta con las personas y los conocimientos necesarios para entregar software que funciona. Los miembros permanentes del equipo deben tener todas o la mayoría de las habilidades necesarias para llevar a cabo el proyecto. Las personas especializadas, por ejemplo, diseñadores, cirujanos, arquitectos o expertos en una tecnología concreta, pueden no estar disponibles todo el tiempo. El equipo puede contar con especialistas externos para actividades a corto plazo. Sin embargo, los miembros permanentes del equipo deberían ser un grupo de personas que pueda cubrir la mayor parte de las habilidades necesarias para completar el trabajo.
Responsabilidades básicas del equipo
La responsabilidad primaria del equipo es crear software que cumple las expectativas del cliente y los criterios del equipo para el software finalizado. Las responsabilidades del equipo comienzan en la reunión de planeación del sprint y terminan en la reunión de revisión del sprint. En la reunión de planeación del sprint, el equipo divide los casos de usuario en tareas. En la reunión de revisión del sprint, el equipo muestra el software que funciona al propietario del producto y posiblemente a los clientes.
El equipo también es responsable de sus propios resultados. Se administra en la definición y finalización del trabajo seleccionado y en la colaboración entre los miembros del equipo para optimizar la efectividad del equipo. Además, siempre debe trabajar para mejorar los resultados comprometiéndose en las siguientes actividades:
Definir los criterios de finalización y completar cada tarea antes de iniciar la siguiente.
Adoptar procedimientos de ingeniería eficaces.
Para obtener más información, vea Procedimientos de ingeniería.
Ayudar al propietario del producto a construir y dar prioridad a casos de usuario eficaces.
Calcular los casos de usuario.
ScrumMaster
Como ScrumMaster, tiene la responsabilidad de crear y mantener un equipo con una actitud positiva que cumpla los procesos de Scrum. Es el agente de cambio que ayuda al equipo a superar los obstáculos.
Cualidades de un buen ScrumMaster
Para ser un buen ScrumMaster, debe poseer o forjar unas capacidades excelentes de comunicación, negociación y resolución de conflictos. Utilizará estos conocimientos diariamente para ayudar a su equipo a desarrollarse. Debe escuchar activamente no solo a las palabras que las personas dicen y escriben; también debe atender a cómo envían sus mensajes (su lenguaje corporal, expresiones faciales, forma de hablar y otra comunicación no verbal). Debe hacer preguntas que revelen problemas ocultos y confirmar que ha entendido lo que dice la gente. Debe usar estos conocimientos para identificar problemas potenciales en el equipo y para ayudar a evitar que se conviertan en problemas reales. Es más barato corregir un error poco después de detectarlo, y es más fácil y menos molesto corregir un problema del equipo cuando es pequeño y manejable que cuando es grande y está fuera de control. Debe hacer que el equipo, el propietario del producto y las partes interesadas de la otra empresa se sientan cómodos mientras controla el equipo para aumentar significativamente su productividad. Debe recopilar, analizar y presentar los datos a las partes interesadas de la empresa de una forma que muestre cómo mejora y crece el equipo. Por ejemplo, si el equipo ha aumentado significativamente la cantidad de valor que produce a la vez que genera menos errores, debe mostrar esa mejora a las partes interesadas de la empresa.
Responsabilidades principales del ScrumMaster
Su responsabilidad principal es asegurarse de que el equipo y el propietario del producto sigan los procesos de Scrum. Por ejemplo, no debe permitir que la reunión de Scrum diaria se convierta en una discusión abierta que dure 45 minutos. También se asegurará de que el propietario del producto no pida al equipo que agregue trabajo a un sprint después de iniciarlo. Debe evitar que el equipo presente casos de usuario en la reunión de revisión de sprint si esos casos no están finalizados completamente.
Ayudará a solucionar los problemas de bloqueo que pueda encontrar el equipo. Es posible que necesite realizar pequeñas tareas, como aprobación de un pedido de compra para un nuevo equipo de compilación, o realizar tareas más desafiantes, como resolver conflictos entre los miembros del equipo. Cuando el equipo se involucra en una interacción negativa, debe ayudar al equipo a recuperarse y trabajar con más eficacia en el futuro.
Propietario del producto
Como propietario del producto, su función primaria es actuar como punto de contacto entre los clientes y el equipo. Diversos clientes y partes interesadas le atraerán en muchas direcciones.
Características de un buen propietario de producto
Debe analizar los requisitos del cliente y articularlos como casos de usuario. Debe tener buenas habilidades de negociación para ayudar a los clientes a entender las compensaciones entre las características solicitadas y el impacto que tienen en la programación. Debe trabajar con los clientes para asignar prioridades al trabajo pendiente del producto para que el equipo cree el producto o sistema más valioso, con un solo incremento a la vez. Debe tener conocimientos en la materia del área o sector de negocio del sistema que se va a crear. Por ejemplo, debe tener conocimientos de sanidad y seguros de salud si el equipo va a crear un sistema de atención sanitaria para un hospital. Sin este conocimiento, no se pueden asignar prioridades al trabajo pendiente del producto con eficacia, ni explicar los elementos de trabajo pendiente del producto al equipo. También se beneficiará de los conocimientos financieros básicos, como la capacidad de entender el período de reembolso en un sistema, la amortización del presupuesto y los presupuestos de capital y gasto. Su comprensión de los procesos de Scrum y su compromiso con ellos también es muy importante para el éxito del equipo.
Responsabilidades base del propietario del producto
Sus responsabilidades básicas son presentar los requisitos de los clientes y de las partes interesadas al equipo, y responder a las preguntas del equipo. Debe mantener actualizado el trabajo pendiente del producto y darle prioridad. Para mantener el trabajo pendiente del producto, debe comunicarse periódicamente con los clientes, las partes interesadas y el equipo. Debe reunirse con las partes interesadas al menos cada semana o cada dos semanas. El orden en el que se implementan los casos de usuario afectará al período de reembolso y la cantidad de trabajo que el equipo debe realizar. El equipo le ayudará a entender cómo afecta la secuencia de casos de usuario al trabajo. Debe ayudar a las partes interesadas a entender los efectos de estas decisiones de clasificación. También puede reducir la necesidad de usar especificaciones detalladas si está disponible para el equipo cuando surjan preguntas sobre cómo implementar la funcionalidad. Para mantener al equipo en acción, debe tener estas respuestas o ser capaz de encontrarlas muy rápidamente (en unas horas). Si no está disponible, los resultados del equipo se verán afectados.
Nota
El nivel de detalle en las especificaciones depende de muchos factores, que incluyen el tipo de aplicación que su equipo está desarrollando. Para muchas aplicaciones, las especificaciones más eficientes son los casos de usuario elaborados correctamente y las líneas abiertas de comunicación. Sin embargo, una aplicación que procesa las pruebas de laboratorio podría requerir especificaciones detalladas para que el equipo pueda analizar con más detalle el impacto de las modificaciones que realizan a lo largo del tiempo.
También trabajará con el equipo y las partes interesadas para generar las pruebas de aceptación. Las pruebas de aceptación ayudan a determinar si un caso de usuario concreto está completo y listo para la revisión del sprint. Debe entender, identificar y articular el riesgo para el equipo y las partes interesadas.