Recientemente leí este artículo sobre una buena proporción entre desarrolladores y personas de control de calidad del software y me pregunto si existe un concepto similar para desarrolladores/no desarrolladores en un equipo SCRUM.
Esto se debe al hecho de que los contextos de trabajo actuales y anteriores para mí son muy diferentes:
contexto antiguo : equipo SCRUM de 5 a 6 desarrolladores, un probador (casos de prueba, algunas pruebas manuales), un líder técnico (altamente técnico, la mayor parte del tiempo se dedica a escribir código, fracción significativa durante la mayoría de las reuniones técnicas), el PO, uno gestor de personas que gestiona tres equipos SCRUM en total, una fracción de un maestro SCRUM. El administrador de personas es el típico "anteriormente técnico", pero no escribe código en este rol
contexto actual : equipo SCRUM de 2-3 desarrolladores, 1/2 probador (es decir, también involucrado en otro proyecto), un "líder de equipo" que debe manejar las tareas de gestión de personas y dedicar una fracción significativa a abordar historias (es decir, escribir código), el PO . El líder del equipo suele estar involucrado en tantas reuniones (tanto técnicas como no técnicas) que dedican menos del 10 % de su tiempo a escribir código.
Después de trabajar más de un año en cada configuración, siento que el primer contexto que tiene una proporción más baja de no desarrolladores a desarrolladores es significativamente más eficiente.
Otra fuente de ineficiencia para el segundo texto podría estar relacionada con que la misma persona trabaje tanto en "modo interrumpido" (reuniones, debates, etc.) como en "modo enfocado" (tiempo continuo asignado a una sola actividad, como la codificación). , pero eso está fuera del enfoque actual de la pregunta.
¿Hay alguna recomendación relacionada con la proporción entre desarrolladores y no desarrolladores en un equipo SCRUM?
Hay muchos factores que influyen en la proporción de desarrolladores y no desarrolladores, que incluyen:
No solo hay muchos factores que influyen en la relación, sino que la relación ideal puede cambiar con el tiempo e incluso dependiendo del trabajo que esté haciendo el equipo en ese momento.
Un buen enfoque para un equipo es monitorear qué tan bien está funcionando la relación actual. Por ejemplo, ¿cuál es la tasa de defectos escapados? ¿Cómo es la calidad general de la base de código? Con base en esta retroalimentación, el equipo puede decidir si necesita cambiar su composición o proporcionar intercambio de conocimientos o capacitación para permitir una mayor capacidad de habilidades cruzadas.
La única proporción que encontrarás es 1 Product Owner y 1 Scrum Master por equipo de desarrollo.
Cualquier persona en un equipo Scrum (además de PO y SM) debe esforzarse por ser desarrollador.
Sin embargo, un desarrollador puede tener varias funciones diferentes. Algunos estarán más orientados a la tecnología y, por lo tanto, ayudarán a definir la arquitectura. Algunos estarán más orientados a las personas y asumirán la carga de representar al equipo en las discusiones con otros compañeros. Algunos estarán más enfocados en asegurarse de que la calidad del software sea buena.
Pero todos son desarrolladores.
Si tiene un QA en su equipo que no codifica, es posible que su equipo no haya desarrollado las habilidades necesarias para garantizar la calidad de los entregables.
La relación ideal es la que mejor permite al equipo entregar con éxito un Incremento de Producto al final del Sprint.
La Guía Scrum no diferencia entre tipos de desarrolladores, y solo requiere que el equipo tenga todas las habilidades necesarias para hacer el trabajo. La combinación específica dependerá de cuál sea su Producto, y es probable que cambie con el tiempo, y el cambio podría implicar que las personas entren y salgan del equipo, o podría implicar que las personas permanezcan en el equipo pero realicen diferentes partes del trabajo: por ejemplo, las personas que realizan principalmente pruebas podrían involucrarse en la codificación, o alguien que haya estado codificando podría ayudar con el análisis comercial para obtener los requisitos del usuario.
Esto es algo que el Equipo Scrum puede abordar en Retrospectiva; todo lo que necesita es hacer tres preguntas:
Algunos tipos de productos y pilas de tecnología se prestan para el desarrollo basado en pruebas, en cuyo caso unos pocos ingenieros de control de calidad pueden recorrer un largo camino. Otros productos pueden requerir pruebas manuales; por ejemplo, el software que se ejecuta en hardware personalizado necesita una prueba completa del sistema a través de probadores manuales, y en esos casos, necesitaría un equilibrio saludable entre los desarrolladores y los ingenieros de control de calidad.
Cuando el equipo comienza a superar las 10 personas y realmente están comenzando a producir lanzamientos de productos, la calidad y la confiabilidad se vuelven importantes porque la falta de estas cosas dará como resultado un riesgo para la reputación y una erosión de la confianza de los clientes.
Bogdán
Bart van Ingen Schenau