Tenemos el deseo de intentar introducir Scrum en uno de nuestros departamentos de desarrollo, pero tenemos una serie de desafíos que no estamos seguros de cómo resolver. Si alguien pudiera indicarnos la dirección correcta, sería muy bueno.
Estamos produciendo un producto empresarial muy complejo y tenemos 2 propietarios de productos, 10 desarrolladores y 4 probadores.
Tenemos 4 lanzamientos cada año que consisten en 20-30 solicitudes de cambio que van de 10 a 1500 horas cada una. Estamos obligados por un contrato de precio fijo que requiere que tengamos un plazo, alcance y precio fijos en cada uno de estos cambios. Además de las solicitudes de cambio, también hacemos corrección de errores. El ciclo de lanzamiento es fijo y tenemos que entregar paquetes instalables cada 3 meses + una serie de paquetes de servicio y revisiones.
Algunos de los retos a los que nos enfrentamos son:
Preguntas:
El mayor conflicto que verá es probablemente con el alcance y la fecha límite fijos. Bloquear esos dos solo lo dejará abierto para modificar los recursos y la calidad. Por lo general, cambiar las composiciones de los equipos no es algo que desee hacer con frecuencia, pero si tiene suficiente espacio para respirar, no hay motivo para que no pueda usar un equipo en el proyecto todo el tiempo y el otro solo al comienzo del ciclo de lanzamiento hasta que esté listo. razonablemente seguro de que puede cumplir el compromiso. Pero todo esto también sería un problema con la cascada.
¿Cómo podemos manejar las revisiones urgentes en medio de un sprint?
Esto no es raro y ha habido otras preguntas al respecto aquí. En resumen: mantenga una canalización separada de correcciones de errores urgentes y simplemente hágalas a medida que surjan. Tu velocidad en el scrum sufrirá temporalmente, pero de nuevo esto no es nada que no te afecte por igual en la cascada. Si se siente abrumado por las correcciones de errores, puede renegociar el alcance del sprint
¿Cómo manejamos a los desarrolladores de tecnologías especializadas que a menudo tienen tareas en muchas solicitudes de cambio diferentes, lo que significaría que necesitan estar en varios equipos? ¿O equipos pequeños de 1 hombre (no tiene sentido)?
Idealmente, debería estar trabajando hacia el entrenamiento cruzado en estas disciplinas. (Siempre menciono el escenario de 'atropellado por un autobús' para tales situaciones) Cómo integrarlos depende de la naturaleza de su trabajo y cuánto de su tiempo se consume en trabajo especializado.
¿Cómo se integra el gerente de entrega con los equipos de scrum, para que podamos informar el progreso, los problemas de presupuesto, etc. con el cliente? Tenga en cuenta que los propietarios del producto no son capaces de hacer este trabajo.
Oficialmente, en absoluto. Toda la información necesaria para este rol debe estar disponible en el flujo de trabajo normal de scrum, por lo que, en teoría, cualquier parte interesada con acceso al tablero de scrum, quemados, etc., debería poder desempeñar este rol. Los PO serían el ajuste lógico debido a su relación existente con el cliente. ¿Por qué no son capaces de esto? Si se trata de un problema de falta de conocimiento del proyecto, entonces eso se puede remediar.
En general, me parece que está operando dentro de un entorno muy estrictamente controlado. La transición a scrum Y mantener intacto su control existente probablemente causará mucha fricción y duplicará el esfuerzo. Esto es SI tiene el apoyo organizacional para lograrlo en primer lugar. No estoy seguro de cuánto beneficio puede obtener con dicho cambio a menos que su cliente también esté abierto a cambiar a un modelo de contrato menos burocrático (como "Dinero por nada, cambios gratis")
¿Cómo podemos manejar las revisiones urgentes en medio de un sprint?
Agregándolos al Sprint Backlog. Tenga en cuenta que esto es un impedimento para el valor de Focus y puede resultar en ineficiencias debido al cambio de contexto.
¿Cómo manejamos a los desarrolladores de tecnologías especializadas que a menudo tienen tareas en muchas solicitudes de cambio diferentes, lo que significaría que necesitan estar en varios equipos? ¿O equipos pequeños de 1 hombre (lo cual no tiene sentido)?
No todos pueden ser expertos en todo, ni se debe esperar que lo sean. Sin embargo, debe haber superposición en el conocimiento. (Relacionado: Paint Drip People ) ¿Qué sucede si ese único "experto" es atropellado por un autobús?
¿Cómo se integra el gerente de entrega con los equipos de scrum, para que podamos informar el progreso, los problemas de presupuesto, etc. con el cliente? Tenga en cuenta que los propietarios del producto no son capaces de hacer este trabajo.
El gerente de entrega se actualizaría a través de la transparencia, el propietario del producto, la revisión de Sprint, etc.
Lea la Guía de Scrum y comprenda el marco; No creo que esta sea la mejor solución para su situación.
Desde la perspectiva del proceso, Kanban probablemente sería una mejor opción según la información proporcionada. Las correcciones rápidas se pueden priorizar fácilmente en la parte superior de la cola para extraerlas. Las diferentes áreas funcionales de la aplicación pueden abordarse a través de tableros Kanban separados. El administrador de entrega se ve mínimamente afectado.
Desde una perspectiva tecnológica, divida el monolito en muchas aplicaciones enfocadas más pequeñas que interactúan a través de las API. Esto también tiene la ventaja de las soluciones modulares que las ventas pueden aprovechar.