Ajedrez - antoniomartel.com

Archivos por Etiqueta: equipo de trabajo

Dependemos demasiado de héroes: otro error habitual en la gestión de proyectos

Cuando dependemos demasiado de uno o dos programadores estrella dentro de nuestro equipo, de los que necesitamos que no fallen nunca, que hagan muchas horas extra porque no llegamos o que, cuando están de vacaciones, los echamos demasiado en falta, estamos ante un gran problema.

Scrum nos puede ayudar a conseguir grandes equipos de trabajo, equipos de alto rendimiento que pueden conseguir entregar mucho trabajo y de calidad. Si lo que tenemos es un equipo formado por un desarrollador estrella del que dependemos absolutamente y el resto del equipo sólo resuelve tareas de menor nivel, no tenemos exactamente un Equipo de Trabajo, tenemos un cirujano y tres o cuatro auxiliares.

Debemos evitar esto facilitando que más miembros del Equipo de Trabajo conozcan las partes de la arquitectura que sólo el programador o programadora estrella conocen, que otras personas realicen también las partes del trabajo que sólo le tocaban a él para que el conocimiento (y el esfuerzo) quede más distribuido.

Por bueno que sea, un Equipo de Trabajo completo siempre podrá producir más que sólo nuestro héroe y además no lo agotaremos a base de horas extra y llamadas durante las vacaciones. Poco a poco el resto del Equipo de Trabajo debe ir acostumbrándose a asignarse a sí mismo las tareas que típicamente sólo hacía el programador estrella e irá ganando en experiencia y en confianza en sí mismo hasta alcanzar un nivel óptimo.
Dependemos demasiado de héroes
Dependemos demasiado de héroes

El equipo de trabajo Scrum

En un proyecto gestionado con Scrum el equipo de trabajo estará formado por tres perfiles: el Dueño del Producto (Product Owner), el Scrum Master y el Equipo de Desarrollo (Development Team).

Ninguno de esos perfiles es el de jefe de proyectos o rol similar ya que estos equipos Scrum son autoorganizados. Esto quiere decir que ellos mismos deciden cómo llevar a cabo el trabajo y se reparten las tareas ¿Quién mejor que el Dueño del Producto para saber lo que hay que hacer y lo que se quiere conseguir? ¿Y quién mejor que el Equipo de Desarrollo para saber cómo hay que las tareas? Ellos dividirán las funcionalidades en tareas más pequeñas, las priorizarán y se las asignarán a si mismos. Ellos mismos se organizan el trabajo cada dos o tres semanas, lo que dure el Sprint.

Los equipos de trabajo también son multifuncionales. Esto significa que dentro del mismo equipo de trabajo encontraremos todos los perfiles necesarios para hacer el trabajo. Si hay que analizar algo lo hará algún miembro del equipo de trabajo. Si hay que realizar una tarea de administración de base de datos lo hará algún otro miembro del equipo (como en DevOps).

Por ejemplo, si necesitamos que se realicen frecuentemente este tipo de tareas de base de datos en el trabajo diario tendremos que contar con alguien con formación de DBA en el equipo. De esta forma el equipo de trabajo puede también autoorganizarse al no depender de otro departamento que tendrá sus propias prioridades y por el que habría que esperar a que realice la tarea. Mientras espera el equipo de desarrollo tendría que dedicarse a otras cosas, quizás menos importantes, hasta que se lleve a cabo la tarea por otro departamento o área de negocio.

Este modelo de equipos de trabajo de Scrum mejora la flexibilidad y la productividad al no estar tan encorsetado y tener un equipo más creativo e independiente.

Al realizar entregas iterativas e incrementales, es decir, realizar una entrega del producto cada vez mayor al finalizar cada Sprint, el equipo de trabajo obtiene feedback de la opinión de los usuarios y los interesados de forma frecuente. Este feedback le permitirá priorizar las próximas tareas y corregir la línea a seguir si es necesario. Estas entregas incrementales son de producto «Terminado» y probado. De esta forma siempre hay disponible una versión plenamente funcional del producto lista para ser usada.

Suscríbete