🎈 👶🏽 🛅 ¿Se puede usar Scrum en la subcontratación? 👩🏻‍🎨 🏟️ 🛌🏻

La pregunta es muy controvertida, y personalmente no encontré una respuesta simple y obvia, aunque la he estado buscando durante mucho tiempo y todavía la estoy buscando (sigo creyendo que encontraré una manera de usar la esencia pura de scrum y nada más en el proyecto de outsourcing). Sin embargo, el marco en sí proporciona muchos nishtyaks, cuyos beneficios son difíciles de negar, si no imposibles. Y, sin embargo, en la pregunta por la cual se titula el artículo, se lee un problema real entre líneas. Permitir a la voz.

Problema

Scrum es un marco ágil; implica un desarrollo ágil. El desarrollo ágil requiere plazos flexibles y un presupuesto similar. El desarrollo de la subcontratación, a su vez, en el 95% de los casos (excepto en el callejón sin salida) implica plazos ajustados y un presupuesto ajustado. Condicionalmente: “hazme un portal corporativo en 3 meses, el presupuesto es de 3 millones. Te estoy pagando por el resultado ". Y el cliente tiene razón, quiere ver el resultado. Y el gerente debe llevar al equipo a este resultado. Pero aquí está cómo hacerlo usando scrum?

Este marco supone incertidumbre tanto en tiempo como en presupuesto. Es decir, ya en la etapa inicial del proyecto, el scrum mismo te dice: "Espera, no puedo venir aquí, hay plazos claros y un presupuesto real, debes buscar una ruta crítica, planificar todo con anticipación, buscar algo en cascada".

Solución al problema

Paso 1. Comience con algo en cascada para vender sus servicios.

Desde la infancia, mi papá me enseñó: "No hay blanco y negro, busque en todas partes los pros y los contras". Sí, la cascada está desactualizada, sí, no es muy adecuada para un desarrollo ágil, pero proporciona comprensión y le permite calcular la ruta crítica teniendo en cuenta todos los riesgos. Lo más probable es que la ruta crítica sea inexacta e incluso una evaluación pesimista será muy optimista (si comprende lo que quiero decir), pero este paso le dará una comprensión aproximada de la cantidad de trabajo para usted y su cliente.

Tendrá que pasar mucho tiempo evaluando el proyecto con los desarrolladores. Para la discusión de características. Y este es un tiempo que es una pena gastar, porque las características aún tendrán que sobreestimarse más tarde, pero hasta ahora sin él, en ningún otro lado; de lo contrario, el proyecto no se venderá y el sabueso del desarrollo subcontratado no romperá la cadena, en busca del siguiente hueso: no habrá hueso.

(!) Este paso no significa venta directa, solo se trata de determinar el "de" y "a" condicional en dinero y en términos.

Paso 2. ¡Hurra! Tomamos el proyecto, comenzamos a trabajar en scrum (a su imagen y semejanza)

El proyecto está tomado. Parece que todos los plazos están ahí. La tarea es clara, bueno, impulsó a hacer. ¡Alerta! No seas tan rápido. Lo más probable es que muchas cosas hayan cambiado desde el momento en que evaluó el proyecto por primera vez. Podría, por ejemplo, aparecer diseño o volar nueva lista de deseos del cliente.

Tengo una sugerencia. Prueba scrum. De la cartera de pedidos del producto, seleccione la pila de sprint, novio. Planifique su sprint con cuidado y vea cómo lo maneja el equipo. Haga scrams diarios en el formato "Lo que hizo el desarrollador ayer / Lo que hace hoy". Y retro al final del sprint para resumir los éxitos de cada uno y los éxitos del equipo en su conjunto. Notará rápidamente cómo el KPI de cada desarrollador crece de sprint a sprint, cómo disminuye el número de devoluciones de QA y cómo disminuye la acumulación de productos.

PD: No se apresure a rechazar los deseos de nuevos clientes. Tal vez tengan sentido y se puedan ingresar de forma segura en la cartera de pedidos del producto en lugar de alguna otra funcionalidad que ya no era necesaria para el negocio de su cliente (y, en consecuencia, el propio cliente).

Paso 2.1 Introducir al dueño del producto al proyecto

La mayoría de las veces, las empresas de outsourcing tienen un solo gerente de proyecto. Sin dividirnos en maestros scrum y propietarios de productos, pero este no es un problema tan grande como parece a primera vista.

Por ejemplo, tengo un probador genial en el proyecto, a quien delegué el 90% de las responsabilidades del propietario del producto (el 10% restante es lo que proviene del cliente, y ya se lo paso a mi colega). Además del hecho de que se dedica a las pruebas (y lo hace perfectamente), también mantiene y repone el trabajo atrasado, escribe un dock, crea tablas de flujo y entidades: hace un gran trabajo (no en detrimento de su núcleo), para lo cual simplemente no tengo tiempo, debido al empleo en otros proyectos.

En este enfoque, hay otra gran ventaja. Para un probador experimentado (y solo a esto se le puede confiar la propiedad del producto), esta es una gran oportunidad para no aburrirse y divertirse con nuevas tareas + para sentir su valía. No olvide mostrar confianza en los miembros de su equipo, al menos porque así es como también aumenta su autoridad.

PD: Ahora trabajo en un modelo así, no en todos mis proyectos. En algún lugar, simplemente no se necesita un scrum, porque se complica. Estos son principalmente proyectos pequeños por un período de un mes o menos.

Paso 2.2 Convertir la calificación del reloj en puntos de historia

No es el paso más importante, puedes trabajar sin él, pero es más difícil. El hecho es que cuando evalúas la tarea en horas, el reloj es diferente para todos, a alguien le toma 6 horas crear una entidad de dominio (tarea condicional), alguien tiene 7, alguien tiene 8. En puntos de la historia todos tendrán lo mismo = 8.

Según los puntos de la historia, será más conveniente calcular el KPI de cada desarrollador, compilar una evaluación de desempeño y rastrear el éxito del proyecto, en general.

Organice con los desarrolladores 8 puntos de historia (mb 5 para junio) por día, planifique en función de esto y observe cómo se cierran las tareas y cómo se implementa el proyecto.

Si un desarrollador cierra repentinamente 8 puntos de historia en 4 horas (5 puntos de historia, de acuerdo con los números de Fibonacci), no lo cargue con nuevos identificadores. Aprecio su acuerdo, respete su trabajo. Parte de su tiempo "libre" restante se dedicará a estudiar la próxima característica y a prepararse para el mañana, y parte al autodesarrollo, o incluso al ocio. El buen ocio también motiva a trabajar bien.

Paso 3. Trabaja bien

No haga todo como está escrito en las guías scrum ni en ningún otro estandarizador pm. Tome decisiones con flexibilidad y aproveche la situación. Seleccione cuidadosamente las herramientas que ofrecen los diferentes marcos y no dude en probar una nueva.

No es necesario trabajar en cascada o scrum para gestionar proyectos con éxito. Necesito trabajar bien. Eso es todo.

Conclusión

Se puede usar Scrum, y será muy útil: un excelente marco que ofrece un montón de herramientas geniales para estar constantemente informado, para desarrollarse y proporcionar la base para el crecimiento del equipo, monitorear el progreso del proyecto y considerar el KPI de los miembros de su equipo.

Sin embargo, scrum no es una panacea, y decirle, por ejemplo, al cliente que inicialmente no sabemos cuánto le llevará el proyecto y cuánto tiempo llevará en términos de desarrollo subcontratado, lo más probable es que no funcione. Es todo lo mismo sin elementos de cascada.

Siéntase libre de combinar los marcos y usar las herramientas que le gusten a usted y a su equipo, incluso si no se supone que sean scrum. Haga que funcione convenientemente, porque este es el objetivo principal de cada marco. Y cómo llamarlo depende de usted.

PD: lo tengo HMS - scrum genéticamente modificado.

¿Se puede usar Scrum en la subcontratación?