Soy PM en el
servicio de correo de
UniSender . Hace 6 años vine como programador, y ahora soy responsable de la interacción entre los equipos de productos. Anteriormente, nuestro desarrollo consistía en un equipo distribuido y teníamos 2 problemas. Pero no tontos y caminos, sino retrasos en sprints y standups aburridos durante media hora.
Te diré cómo los resolvimos.
Como dije, tuvimos 2 problemas:
- Sprint podría demorarse debido a la falla de una tarea . QA y Dev trabajaron en el mismo sprint, los ámbitos de tareas se fijaron al comienzo del trabajo y todo el equipo se apresuró heroicamente a implementarlo. A veces llegaban errores urgentes que iban a las revisiones "maestras". Las tareas de sprint podrían ser bastante voluminosas. Cuando algunas tareas estaban listas para su lanzamiento, otras aún estaban en desarrollo. Como resultado, el equipo podría retrasar el sprint debido a una tarea.
- Las standups llevaban mucho tiempo y eran de dudosa utilidad . El equipo creció, se hicieron stand-ups en Skype, y al principio nada era un problema. Comenzamos a sospechar que algo andaba mal cuando los levantamientos comenzaron a estirarse durante 20-30 minutos. Los presentes no siempre entendieron lo que otros miembros del equipo estaban haciendo.
Durante algún tiempo vivimos con estos problemas, luego intentamos luchar.
- Redujeron los levantamientos mediante la introducción de regulaciones sobre humanos.
- Redujeron el número de los presentes: solo el líder del equipo fue a stand-ups.
- Intenté sprints semanales.
- Reducido el número de tareas en el sprint.
Estos intentos no dieron el resultado esperado. Se ha llegado a la conclusión de que no se pueden prescindir de los cambios radicales.
Aquí es necesario decir algunas palabras sobre el producto.
Somos una solución SaaS disponible 24/7. Además de la parte visible para los usuarios, la GUI, también tenemos una gran capa de lógica del sistema que funciona independientemente de la hora del día o la situación política en el país. Es decir, el desarrollo y la actualización del servicio están en curso, sin parar.
Yendo a Kanban
La primera revolución a gran escala ocurrió cuando nos dimos cuenta: "Scrum no es adecuado para nosotros".
Decidimos cambiar a Kanban. Por supuesto, no éramos Toyota y no comenzamos a implementar la implementación completa. Por lo tanto, "nuestro kanban" será diferente de "su kanban".
Sprints y trabajo en equipo.
En pocas palabras sobre nuestra versión:
- Consideramos el sprint (una pieza completa de funcionalidad) como la unidad de trabajo.
- Se reunió un equipo para la tarea dependiendo de la carga y las habilidades necesarias. Un equipo usualmente tenía hasta 3 desarrolladores y 1 QA. No hubo equipos permanentes.
- El número de sprints simultáneos se ha convertido en más de uno.
- No había tablero físico y otros atributos de Kanban, las tareas se llevaron a cabo mediante la adición de Jira.
En este caso, el equipo tuvo que hacer un sprint de principio a fin. Esto también se aplica a la fase de prueba: las mismas personas que trabajaron en el sprint corrigieron los errores.
Resultado- Con el retraso de las tareas grandes, las otras no sufrieron, cuyo desarrollo se completó.
- La cantidad de problemas durante las implementaciones ha disminuido: en un sprint hay menos tareas variopintas.
Standups
Los stand-ups se transformaron: fueron visitados por un representante de cada equipo que trabajó en un sprint separado.
Resultado- Las standups se convirtieron en standups y nuevamente comenzamos a encajar en el estándar de 10-15 minutos.
Por lo tanto, pudimos resolver problemas críticos.
Pero ... ¡todo el iceberg comenzó a surgir detrás de la isla!
Después de cambiar a Kanban, obtuvimos un equipo frontend dedicado y había más empleados en el equipo de backend y producto. La interacción entre los departamentos se volvió más complicada: varios equipos podían trabajar en un proyecto.
Resolvimos algunos problemas, pero surgieron otros nuevos:
- No todos participaron en stand-ups, a menudo el equipo tuvo que volver a contar la información.
- Un control de calidad podría tener 2-3 sprints paralelos con diferentes equipos. Tuve que cambiar: recordar las características del sprint y volver a implementar constantemente el código en entornos de prueba.
- El control de calidad no estuvo completamente involucrado en el proceso de trabajar en sprints. A menudo, la tarea los alcanzó al final del sprint y los requisitos se estudiaron una vez que se completó el desarrollo.
- Los equipos se reunieron para el proyecto y su composición a menudo cambió. Un equipo de dos desarrolladores podría trabajar en 3 sprints simultáneamente: 2 sprints en la prueba más 1 sprint actual.
- Fue difícil estimar el tiempo de desarrollo. No está claro cuánto tiempo comerá el sprint sin terminar anterior.
Durante algún tiempo vivimos según las nuevas reglas y luchamos con nuevos desafíos. Intentamos diferentes enfoques y llenamos muchos conos.
Al final, nuevamente comenzamos a sospechar que algo iba mal. Una nueva revolución para ser.
División en equipos, nuevos stand-ups, introducción de Fireteam
Analizamos los procesos desde el inicio de la idea hasta el despliegue de la implementación terminada en prod. Analizamos cómo funcionan las metodologías ágiles en otras empresas. Nos dimos cuenta de que nuestros enfoques del proceso de desarrollo no eran tan malos.
No es necesario romper un sistema de trabajo, necesita arreglar los momentos que causan dolor.
Esto es lo que cambiamos durante el proceso de desarrollo.
Sprints
Todavía operamos sobre el concepto de "sprint". Sprint es un alcance de trabajo de "casi dos semanas" para el equipo.
¿Cuál es el plus? El código no se "daña" y llega al producto sin demoras significativas. Si el equipo va a hacer un sprint en 2 semanas, debe intentar ajustarlo a un mes.
Lo que se puede mejorar. A menudo perdemos la marca y los sprints se retrasan un poco. El tiempo para trabajar en algunos sprints es inicialmente difícil de evaluar (por ejemplo, muchas refactorizaciones). Tenemos que resolver este problema.
División en equipos
Dividimos un equipo grande en varios equipos más pequeños. Cada uno de ellos incluye 2-3 desarrolladores y un control de calidad dedicado. Ahora los equipos son estables y no cambian de proyecto a proyecto. A veces las personas cambian entre equipos para optimizar las listas o agregar la experiencia requerida a un equipo. BA participa en el equipo, pero al mismo tiempo puede liderar 2-3 proyectos.
Aunque el resto sigue siendo un equipo)Al mismo tiempo, todo el equipo trabaja en un proyecto desde el principio hasta su finalización. Un proyecto puede consistir en varios sprints.
¿Cuál es el plus?- Los equipos están en la misma sala. Antes de eso, todos estaban sentados en departamentos.
- El equipo está incluido en el trabajo del proyecto de principio a fin, lo que reduce el factor del bus.
- Los miembros del equipo están presentes en todos los eventos: retro, stand-ups, sesiones plenarias. Todos los empleados están actualizados con las tareas actuales.
- El equipo ya no trabaja en los sprints de otras personas. Ahora todo es nativo.
Lo que se puede mejorar. Me gustaría presentar completamente BA en el equipo. Esto es problemático porque el VA generalmente comienza a trabajar antes que el resto del equipo.
Trabajo en equipo
Un equipo en el trabajo no puede tener más de dos sprints: "el que todavía está en la prueba" y "el nuevo que veremos". Como regla general, después del final del desarrollo, todos, a medida que se lanzan, comienzan a trabajar en un nuevo sprint.
¿Cuál es el plus? El trabajo en equipo se ha vuelto más predecible, todos están familiarizados con el código y pueden apoyar el sprint durante las pruebas. Es menos probable que los participantes cambien entre tareas, y el proceso de cambio ahora es más rápido.
Lo que se puede mejorar. Idealmente, un equipo debería tener solo un sprint en el trabajo. Pero por ahora, un mundo ideal no es nuestro mundo.
Equipo de fuego
Cada equipo es elegido por una semana. Este comando responde a todos los irritantes externos: llamadas de otros departamentos, comportamiento anormal del servicio, revisiones. Llamamos a este equipo "Fireteam".
¿Cuál es el plus? La semana de Fireteam no cuenta para el equipo en el tiempo de sprint. En medio de la lucha contra incendios, los empleados pueden concentrarse en sus tareas:
- Refactorizador
- Completa la tarea de sprint.
- Escribir documentación
- Realizar una transferencia de conocimiento con otros equipos.
Desventaja En la semana del equipo de bomberos, la vida del equipo es muy agitada. Todos los departamentos aman y conocen a estas personas en persona, especialmente el soporte técnico. Debe cambiar constantemente entre diferentes tareas: debitar, leer registros, aserrar tareas urgentes y apagar todos los incendios. Todo esto debe hacerse simultáneamente.
Standups
Introdujimos 2 tipos de stand-ups:
- Equipo Involucró a un equipo que trabaja en el proyecto.
- General Se llevan a cabo una vez por semana, los líderes de cada equipo participan en ellos.
¿Cuál es el plus?- El equipo está informado sobre el estado del sprint.
- Los empleados son conscientes de lo que otros equipos están haciendo.
- Los stand-ups no se convierten en "actividades aburridas para leer de una hoja de papel algunos conjuntos de números". Todos los presentes entienden lo que está en juego. Se ha vuelto más fácil detectar áreas problemáticas en el trabajo.
- Las paradas toman de 5 a 10 minutos.
Desventaja El equipo aún lleva información al equipo.
Resumen
Así, cambiando gradualmente el proceso, resolvimos la mayoría de los problemas apremiantes:
- Hemos reunido equipos estables de 2-3 desarrolladores y QA. Cada equipo ahora no tiene más de 2 sprints, los participantes no trabajan en proyectos de otras personas.
- Hubo un equipo que procesa mensajes de otros departamentos, responde al comportamiento anormal del servicio y las revisiones. Otros equipos no se distraen con estas tareas.
- Ahora la compañía tiene 2 tipos de stand-ups: equipo y general. Todos los empleados están informados sobre el estado de los asuntos de sprint, y un stand-up demora de 5 a 10 minutos.
Bueno, estamos trabajando en eso.
