De monolitos a equipos modulares.

Las grandes empresas a menudo lamentan el problema de la adaptabilidad y la maniobrabilidad. Más precisamente, casi por la ausencia total de ambos.

Imagínese: todos los equipos de la plataforma están ocupados con una característica, y la empresa tiene un requisito urgente de hacer otra cosa o ajustar la funcionalidad que ya se está desarrollando. Y en este momento el trabajo en una característica se detiene y el trabajo en otra comienza. En el momento siguiente, aparecen nuevos requisitos de la empresa y la función permanece sin terminar. Los desarrolladores se ofenden y el negocio está sufriendo.



Aquí hay otra situación: la API está cambiando, debe ejecutar con urgencia al departamento de back-end para conocer los detalles y luego volver a los frentes (iOS / Android / web). Además, después de discutir sus correcciones con los frentes, debe volver a la parte de atrás y hablar sobre nuestros requisitos. Fue muy agotador, perdió el tiempo de los equipos, un desarrollador individual y los nervios de todas las personas interesadas.

Mi nombre es Valery, nuestro equipo participó en QIWI Wallet para iOS. Pero siempre fue necesario mantener la comunicación con otros equipos, de lo contrario se produciría una desincronización completa. En cuanto a nuestros inconvenientes, el negocio siempre avanza y da libertad para la experimentación. Por lo tanto, surgió la cuestión de cambiar la estructura existente. Un ambiente favorable para probar nuestras ideas para el cambio fue el scrum. Cada dos semanas, nosotros dentro de la plataforma podríamos editar el curso para que al menos de alguna manera estuviera coordinado con otros equipos. Tomó mucho tiempo probar las teorías. De un mes a seis meses. ¿Qué opciones hemos probado?

Característica oouner

Una persona del equipo fue nombrada responsable de la función para el próximo sprint. Esta persona pasó parte de su tiempo con diseñadores y con una característica de otro equipo de primera línea (el respaldo decidió no usar la característica destacada), descubriendo las trampas y sutilezas del próximo trabajo, estuvo de acuerdo con el backend sobre el contrato. También supervisó todos los cambios en el backend y los negocios. Y todo parece estar bien. Nadie corre en pánico, excepto esta persona que recibe el golpe de un entorno cambiante sobre sí mismo. Todos se tranquilizaron por un momento.

Pero la felicidad continuó exactamente hasta que la característica del OUNER se enfermó exactamente antes de su sprint. Y toda la ilusión de apaciguamiento se disolvió, y volvimos a donde comenzamos.

Aseo general

Se invitó a representantes de diferentes plataformas a preparar un equipo de plataforma. Se volvió un poco mejor, pero a los chicos no les gustó (por lo que se dice) sentarse en varias reuniones seguidas. Pero la razón principal es la variabilidad de las API y los contratos, el cambio en los objetivos del sprint, y es bueno si solo cambia el primer día del sprint. Pero generalmente de todos modos, los cambios cayeron durante las dos semanas. En pocas palabras: los objetivos no se cumplen, los chicos están procesando, el negocio está sufriendo.

Chats

Una de las opciones no estándar era la creación de chats. Se creó un chat separado para cada función. Además, también hubo salas de chat de equipos donde se discutieron los problemas. Y también un chat general específicamente para problemas donde estaban todos los equipos. Al principio, el problema parecía estar resuelto.

Pero los chats se multiplicaron rápidamente y, ya sabes, se convirtió en una carga. Cuando apareció un problema, no quedó claro dónde buscar información, ya sea en el chat en la sección de perfil, o en el chat al refactorizar el cliente de red o reemplazar el módulo de información del usuario. Como resultado, se volvió solo más confuso. Nuevamente tuve que correr entre departamentos.

Feature-tim

Luego vino una tienda de abarrotes y se ofreció a probar el formato de función-tima. ¿Qué significa esto? Se toman dos desarrolladores de cada plataforma (iOS, Android, web, backend) y dos probadores) y se forma un nuevo equipo.

Se suponía que este enfoque resolvería varios problemas importantes, además de la coherencia y la velocidad de lanzamiento de los lanzamientos:

Autonomía
Un equipo que va a las reuniones juntos es lo más independiente posible de los demás. El enlace principal de las dependencias externas es el producto.

Prueba de teoría rápida
Después de todo, antes de que todo el equipo de billetera hiciera alguna nueva funcionalidad y sucedió que esta funcionalidad tan genial no fue para los usuarios. Resulta que todo el desarrollo vio cosas innecesarias y el presupuesto no fue a ninguna parte.

Todo el equipo comprende qué es el "desarrollo de productos".
Se realizan funciones o llegan requisitos comerciales, y el desarrollador no siempre comprende por qué, por qué y quién lo necesita.

Todo el equipo afecta el producto. Hasta la invención de nuevas características.
Como resultado, a todos les gustó este enfoque, y en este momento tenemos 3 equipos independientes que se dedican a sus tareas de producto. Ahora, al cambiar el contrato, no necesita correr por los departamentos y buscar responsables, tampoco hay necesidad de un montón de chats confusos, solo toque a un desarrollador sentado cerca. Las reuniones se llevan a cabo todos los destacados, donde los representantes de todas las plataformas y QA están presentes de inmediato.

Las preguntas se resuelven con palabras en un par de minutos y nadie experimenta el mismo dolor. Además, otro gran beneficio para el negocio es que si la función no llegó a los usuarios, solo se utilizará una característica del equipo (en este momento de cada tres), y no todo el desarrollo, como era antes.

Como resultado, logramos las siguientes ventajas:

• Autonomía de otros equipos.
• El desarrollo flexible máximo, podemos cambiar de rumbo con seguridad, si el software lo requiere.
• Resolución de problemas rápida y fácil.
• Una prueba rápida de teorías de características.

Espero que este ejemplo te ayude a resolver problemas de comunicación entre equipos. Si tiene otras opciones interesantes, estoy esperando comentarios).

Gracias

Y pronto tendremos un mitap para desarrolladores de iOS.