Scrum sugiere equipos pequeños hasta donde yo sé. Esto significa que a menudo tenemos un solo desarrollador frontend, un solo desarrollador backend, un solo ingeniero de control de calidad, etc.
¿No afecta negativamente el éxito del proyecto? Si, por ejemplo, un desarrollador de back-end se enferma, ¿qué debemos hacer como gerente? ¿Debe un cliente pagar por nuestro trabajo como antes, a pesar de que no podemos producir tanto valor como cuando todo el equipo trabajaba en conjunto? ¿Cómo debe consignarse esta situación en un documento de contrato?
La parte de scrum es irrelevante para las preguntas específicas que se hacen.
Hay conceptos erróneos sobre Scrum y el tamaño de los equipos. El primer error común que he visto es que Scrum exige equipos pequeños, específicamente un Equipo de Desarrollo de entre 3 y 9 personas. Scrum contiene varios conceptos que son inmutables: "roles, eventos, artefactos y reglas", y cambiar estos conceptos básicos daría como resultado algo que no es Scrum. Las afirmaciones de que "menos de tres miembros del Equipo de Desarrollo" y "tener más de nueve miembros" se refieren a los rangos en los que se ha visto que Scrum es más óptimo. No significa que Scrum no se pueda usar con un Equipo de Desarrollo de una o dos o diez u once personas, sino con equipos menores de tres o mayores de nueve,
La característica clave de un Equipo de Desarrollo es que son multifuncionales y tienen "todas las habilidades como equipo necesarias para crear un Incremento de producto". Además, Scrum no reconoce títulos o sub-equipos entre los miembros del Equipo de Desarrollo. Tener un "desarrollador frontend", un "desarrollador backend", un "ingeniero de control de calidad", etc., es reconocer títulos entre los miembros. Considere que alguien puede tener experiencia en un dominio o habilidad en particular, pero el equipo debe esforzarse por distribuir el conocimiento y la capacidad de trabajo entre todos los miembros del equipo.
En una situación en la que el equipo depende de una sola persona para proporcionar conocimientos y habilidades particulares para entregar, eso es algo que debe identificarse como un riesgo del proyecto. Como con cualquier riesgo, se puede evitar, reducir, compartir o retener. El riesgo se puede evitar aumentando el tamaño del equipo para duplicar las habilidades clave o no asumir un trabajo que sea demasiado arriesgado. Se puede reducir implementando el intercambio de conocimientos, y los Sprints más cortos también pueden reducir la posibilidad de que ocurran eventos inesperados en la caja de tiempo. Se puede retener aceptando el riesgo tal como es y avanzando.
Scrum no sugiere ciegamente "equipos pequeños" sin calificación y definitivamente no aboga por tener un equipo tan pequeño que un miembro enfermo signifique que el trabajo no puede progresar. La guía de Scrum dice (énfasis mío):
El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño para seguir siendo ágil y lo suficientemente grande para completar un trabajo significativo dentro de un Sprint. Menos de tres miembros del equipo de desarrollo disminuyen la interacción y dan como resultado menores ganancias de productividad. Los Equipos de Desarrollo más pequeños pueden encontrar limitaciones de habilidades durante el Sprint, lo que hace que el Equipo de Desarrollo no pueda entregar un Incremento potencialmente liberable. Tener más de nueve miembros requiere demasiada coordinación. Los Grandes Equipos de Desarrollo generan demasiada complejidad para que un proceso empírico sea útil.
En el escenario de su pregunta de tener solo 3 miembros del equipo de desarrollo, estaría en el equipo de tamaño más bajo que recomienda Scrum. Hay varias formas de reducir los riesgos que usted describe de que un miembro del equipo no esté disponible, las más obvias serían
¿No afecta negativamente el éxito del proyecto? De ninguna manera eso no se aplicaría si no estuvieras haciendo Scrum y tuvieras cuellos de botella en las personas.
Si, por ejemplo, un desarrollador de back-end se enferma, ¿qué debemos hacer como gerente? A corto plazo, discuta con el equipo qué es lo más valioso que pueden hacer sin que ese miembro esté presente. A largo plazo, trabaje con el equipo para eliminar este cuello de botella.
¿Debe un cliente pagar por nuestro trabajo como antes, a pesar de que no podemos producir tanto valor como cuando todo el equipo trabajaba en conjunto? - Si no puede producir tanto valor usando Scrum como cuando usa una metodología diferente, entonces adopte esa otra metodología o mejore la forma en que está haciendo Scrum.
¿Cómo debe constar esta situación en un documento contractual? - No esperaría que un documento de contrato entre en el nivel de detalle de discutir lo que sucede cuando un miembro del equipo está enfermo.
Como ya lo etiquetó, es (en parte) una pregunta sobre Gestión de riesgos, por lo que abordaré esa parte, ya que la parte de Scrum se ha abordado en las otras buenas respuestas.
Obviamente, si decide tener equipos pequeños, el factor de riesgo de que un solo miembro del equipo no pueda trabajar es alto.
Esto se abordaría en su análisis de riesgos. Es decir, qué tan alto es el riesgo y qué planea hacer para mitigarlo. Si esto se agrega al contrato es una pregunta para su equipo legal.
Como regla general, generalmente rellenamos el cronograma teniendo en cuenta alrededor del 20% para licencia por enfermedad y vacaciones. Algo más que eso, o que el miembro del equipo no esté disponible permanentemente, probablemente caiga bajo la cláusula de fuerza mayor, implícita o explícita en los contratos.
En conclusión: nunca desea una situación en la que un solo miembro del equipo no esté disponible durante más de unos pocos días pueda poner en peligro el proyecto. Necesita algún plan de contingencia como tener un "aprendiz de todo el comercio" disponible para hacerse cargo en caso de emergencia.
Me imagino que esto tiene un precio en el contrato, aunque probablemente no se mencione explícitamente.
Mezclar DevOps con Scrum ayuda aquí, lo que significa combinar responsabilidades entre desarrolladores y operaciones para un mayor aprendizaje y eficiencia. He visto muchos proyectos retrasados esperando que un equipo externo (ya menudo menos motivado) tome una acción simple. A menudo, esas acciones administrativas se llevan a cabo con un equipo externo, como los DBA, por costumbre o silos, por lo que trasladarlas al equipo es de gran ayuda (recomiendo el libro Phoenix Project, que habla de esto, así como de CI/CD).
Esto funciona especialmente bien si puede contratar o hacer crecer "desarrolladores de pila completa". Cuando sea razonable, los conjuntos de habilidades deben superponerse. Por ejemplo, si bien su recurso de interfaz de usuario puede comprender completamente los puntos finos de accesibilidad, usabilidad y estilo, si se enferman, un desarrollador debería poder retomar. Mover operaciones como la base de datos o la configuración del entorno al equipo reducirá aún más su riesgo.
Las pruebas de integración automatizadas (idealmente combinadas con la entrega continua) también son muy útiles aquí. Si se hace correctamente, un desarrollador puede escribirlos o al menos mantenerlos si tiene una persona de control de calidad dedicada y se enferma. Otro enfoque es transferir esa responsabilidad a los desarrolladores, aunque las personas tienen fuertes sentimientos a favor y en contra (por ejemplo, que las pruebas de control de calidad son un conjunto de habilidades específicas que no todos pueden hacer).
usuario3067860