En previsión de AppsConf 2018, entrevistamos a especialistas de grandes empresas sobre las características y procesos distintivos de grandes equipos involucrados en el desarrollo de aplicaciones móviles. Se utilizan los enfoques para el trabajo, qué escollos esperan a los remeros que llegan a una enorme galera. Si el origen extranjero de la empresa deja una huella en los procesos de trabajo, lea todo sobre esto bajo el corte.
Philip Uvarov, desarrollador de Android en Spotify. La compañía ha estado trabajando durante los últimos seis meses, en uno de los equipos de plataforma que respaldan a otros desarrolladores en Spotify. Vive en Suecia. Antes de Spotify, trabajó en una startup sueca, e incluso antes en Avito.
Artyom Olkov, desarrollador principal de iOS en Odnoklassniki. Actualmente lidera el desarrollo de iOS de uno de los productos. Además del desarrollo en sí, es responsable de la arquitectura, el diseño, la distribución de tareas, la coordinación con el diseño, las API de back-end, etc. En total, Odnoklassniki ahora tiene unos 60 ingenieros móviles que se dividen en equipos más pequeños. El equipo de Artem - 11 personas.
Maxim Efimov, ingeniero de software sénior en Uber. Lleva dos años trabajando en la empresa, se dedica al desarrollo de Android. Forma parte del equipo de pagos de pasajeros, que procesa todo lo relacionado con los pagos en la aplicación de pasajeros de Uber. Antes de eso, desarrolló para Android en otras compañías, principalmente por encargo, e incluso antes, escribió en C ++ (soluciones de servidor para sistemas SCADA). En Uber, como parte del departamento de pagos, hay varios equipos más similares para otras aplicaciones, así como equipos de infraestructura, un total de varias docenas de equipos.
Evgeny Suvorov, jefe de desarrollo de unidades móviles en Avito: ha estado desarrollando aplicaciones móviles durante aproximadamente ocho años. Probé juegos, trabajo independiente, trabajé en empresas de outsourcing, en una empresa grande, después de lo cual me cambié al desarrollo de productos.
Comencemos con las características. ¿Cuál es la diferencia entre el trabajo de los equipos con un gran equipo de desarrolladores en la empresa?Artem Olkov (Odnoklassniki): En mi opinión, las peculiaridades están relacionadas no con la escala de la empresa, sino con la forma en que se organizan los procesos dentro de ella y qué papel juega el equipo en estos procesos. En términos generales, si su equipo crea la plataforma móvil en la que se basan otras aplicaciones o servicios de la compañía, 1000 solicitudes de diferentes rincones volarán hacia ella y sin un buen gerente de producto, el desarrollo se ahogará. Si el equipo realiza un servicio independiente sin integraciones complejas, el proceso se verá mucho más simple.
Maxim Efimov (Uber): En mi opinión, la característica más característica es la velocidad del trabajo.
Los equipos pequeños, en principio, trabajan mucho más rápido. Pero al mismo tiempo, los equipos grandes tienen un producto bruto final del desarrollador, por supuesto, porque todo un grupo de personas se dedica aproximadamente a lo mismo. Y de esto se desprende una visión diferente de cómo se implementan los proyectos en general.
En las pequeñas empresas, a menudo encajamos en términos, condicionalmente, hasta un día o hasta una semana. Podemos calcular y planificar todo por adelantado. En equipos grandes, esto es difícil de hacer, porque todo está vinculado a una gran cantidad de personas. Por lo tanto, el enfoque de planificación es algo diferente. Los proyectos se realizan con ciertas tolerancias en términos de tiempo, y la calidad y las características que hacemos son primordiales. Y solo después de eso es la necesidad de ajustarse a los plazos.
Otro punto interesante: cómo los equipos están de acuerdo entre sí. Si de cinco a diez personas trabajan en el proyecto, pueden reunirse fácilmente en la sala de reuniones y, después de pasar dos o tres horas, resolver todos los problemas. Y puedes ir más allá para hacer el proyecto. Pero cuando cientos de personas están involucradas en el proyecto, esto no funcionará. En Uber, tenemos ciertos mecanismos de comunicación que permiten a los equipos no interferir entre sí, integrarse de manera efectiva, etc. En las pequeñas empresas, todo esto, en principio, no existe.
Philip Uvarov (Spotify) : Creo que la característica principal es que no conozco a todos los desarrolladores de Android en persona. Y también tenemos responsabilidades muy divididas. Esto le permite estar siempre en el contexto de lo que está haciendo y lo suficientemente rápido como para entregar productos en su dirección.
¿Cómo se sincroniza su equipo con otros dentro de la empresa?Evgeny Suvorov (Avito): nuestros equipos están conectados por una aplicación móvil: Avito. Todos ellos contribuyen a este producto, es decir, el punto de sincronización en nuestra base de código y funcionalidad.
Philip Uvarov (Spotify) : tenemos equipos multifuncionales que se ocupan de problemas específicos (por ejemplo, cómo desarrollamos análisis para clientes móviles) se combinan en un departamento grande: lo llamamos "tribu" (tribu). Como regla general, los equipos dentro de una tribu están muy estrechamente interconectados, tienen un intercambio activo de experiencia. Además, por supuesto, tenemos clientes: estos son otros desarrolladores, por lo que respaldamos las soluciones que creamos para ellos.
Maxim Efimov (Uber) : Tenemos equipos pequeños, cada uno con no más de 20 personas. Están unidos en unidades estructurales que son responsables de grandes áreas, por ejemplo, una aplicación móvil. Al mismo tiempo, los equipos mismos son bastante autónomos, porque si reducimos todo a un solo sistema de control con subordinación directa, obtendremos un sistema muy ineficiente.
La idea general del producto se transmite a equipos individuales a través de gerentes o propietarios de productos. Hay una estructura separada que une a estas personas y ayuda a construir una comprensión de cómo y hacia dónde nos estamos moviendo. En algún nivel superior, se pueden definir objetivos estratégicos como cuidar la seguridad de los pasajeros. Bueno, los detalles se resuelven uno o dos niveles a continuación. Por ejemplo, tenemos ciertos mecanismos de seguridad en países donde la gente usa principalmente efectivo para pagar.
Artem Olkov (Odnoklassniki): Estamos comprometidos en un servicio separado. Entonces, digamos que somos una startup dentro de una gran empresa. Por supuesto, vivimos en la misma infraestructura. Y en todo lo demás, estamos muy separados. Incluso dentro del marco de integración, a menudo utilizamos la API pública de nuestras propias herramientas.
¿Hay algún problema típico de los equipos grandes? ¿Con qué tienes que lidiar?Evgeny Suvorov (Avito) : En mi opinión, los procesos en un gran equipo se ven principalmente afectados.
Todos los muchachos, como regla, tienen experiencia, incluso los juniors pueden resolver problemas técnicos. Pero los problemas con los procesos pueden ralentizar fácilmente a todos, por lo que es mejor automatizar los procesos.
Y eso significa integración continua de alta calidad, entrega continua, automatización de pruebas.
Philip Uvarov (Spotify) : Creo que el mayor problema es la difusión del conocimiento dentro de la empresa. Puede que no tenga una idea de lo que está sucediendo en algunos equipos distantes. Y lo mismo es cierto en la dirección opuesta: muchos equipos no tienen idea de que tenemos un equipo de análisis en Spotify. Aquí es donde se siente la escala.
El segundo punto es la velocidad de tomar decisiones innovadoras: adaptación del mismo Kotlin y otras nuevas tecnologías. Una cosa es venir y decirle a cinco desarrolladores: "Desde hoy escribimos en Kotlin", pero es otra muy distinta decirlo a 100 desarrolladores. Hay una gran infraestructura que necesita ser traducida, para de alguna manera apoyar estas innovaciones (CI, etc.).
Artem Olkov (Odnoklassniki): Sí, realmente hay dos problemas: la transferencia de conocimiento y la coordinación de acciones, incluida la modernización.
¿Las grandes empresas tienen formas comprobadas de resolver estos problemas?Philip Uvarov (Spotify) : Para resolver el primer problema, compartir conocimientos, tenemos gremios. Este es un grupo de desarrolladores por función, por ejemplo, el gremio de Android, que cada dos semanas celebra algunos eventos: presentaciones, almuerzos, donde puedes discutir problemas urgentes o compartir algo, etc. También tenemos, nuevamente, gremios Se realizan conferencias internas. Además, hay listas de correo, etc. Queda un problema humano simple: es difícil mantenerse al día con todo esto.
Me gustaría destacar el entrenamiento interno (entrenamiento avanzado) como una línea separada. Tenemos nuestra propia Universidad de datos, donde puede aprender cómo convertirse en ingeniero de datos. Ahora los colegas están pensando en crear el mismo esquema para el aprendizaje móvil.
Artem Olkov (Compañeros de clase): No tenemos gremios pronunciados.
De una forma u otra, los muchachos unidos por una tarea se cruzan en diferentes reuniones: se conocen, se comunican en una sala de fumadores o en el almuerzo. Hay salas de chat separadas, por ejemplo, solo para apodos de iOS. Dentro del equipo, por supuesto, el problema se resuelve más fácilmente: todos estamos sentados en la misma "margarita".
Si tienes alguna pregunta, levanta la mano, saluda a la que necesitas y él te contesta. Para transferir conocimiento, también utilizamos manifestaciones matutinas de 15 minutos, donde todos dicen qué, cómo, por qué y por qué lo hicieron. Todavía hay una cierta capa de documentación donde se toman los puntos principales.
El segundo problema, la coordinación de las acciones, lo resuelve una administración competente.
Maxim Efimov (Uber): En realidad, en el mismo intercambio de conocimientos, no veo el problema. Veo que el mecanismo de compartir en sí es diferente. En equipos pequeños, esto simplemente se hace de todos modos. Reunidos - hablados. Y tenemos procesos convenientes que nos permiten organizar todo para que funcione. Por cierto, hablaré de ellos en mi
discurso en AppsConf 2018. La idea es que en nuestra empresa casi todo el desarrollo es bastante transparente. Las personas de cualquier equipo pueden ver lo que otros desarrolladores están haciendo y usar algo de esto en casa.
Evgeny Suvorov (Avito): También organizamos reuniones 2 veces a la semana. Nos encanta la automatización, y esta tarea también está automatizada. Hay un proceso en el que durante la semana las personas abordan temas de los que les gustaría hablar en una reunión general de desarrolladores de iOS o Android. Y si hay una citación, vamos a hacerlo. Durante las reuniones, los equipos de productos hablan sobre las características que implementaron en el producto, porque de lo contrario es difícil hacer un seguimiento de todo lo que sucede.
Nos conocimos desde el principio, pero fue con el crecimiento de la compañía que estas reuniones se hicieron más relevantes.
Además, hay salas de chat donde puede discutir cualquier problema específico.
¿Por qué principio tiene sentido dividir a muchos desarrolladores en una empresa: por plataforma, por funcionalidad o de alguna otra manera?Artem Olkov (Odnoklassniki): Todavía depende de lo que hagas y de cómo
ganes dinero.
En teoría, puedo imaginar la estructura de una empresa de outsourcing en la que una división, por ejemplo, trabajará en una plataforma. Pero para una compañía de alimentos, apenas puedo imaginar una forma diferente de división, excepto para equipos funcionales.
Porque si coloca todos los apodos de iOS en un montón, agregue tareas en ellos, sin tener un puente muy corto de comunicación con el diseño, el backend o las pruebas, tendrá que dedicar demasiado tiempo a la coordinación.
Philip Uvarov (Spotify) : Todos compartimos el producto. Por ejemplo, nuestro equipo se dedica a análisis e incluye iOS, desarrolladores de back-end y muchos otros. En mi opinión, esta es una división de equipos muy razonable, que también conduce a ciertos problemas, pero al mismo tiempo funciona bien en tal escala.
Maxim Efimov (Uber): Me parece que la idea de dividir equipos por plataforma (iOS, Android, backend) a gran escala no funcionará muy bien. Separa bastante a los desarrolladores y, como resultado, la sincronización, por ejemplo, de dos aplicaciones móviles para diferentes plataformas, costará mucho más. Y el beneficio del hecho de que las personas en el equipo solo ven a las personas desde su plataforma, como me parece, no es tanto. Sí, compartir conocimiento es más fácil, pero ¿vale la pena? Creo que no
Además, la idea de que algunos equipos hacen cosas básicas que todos los demás usan, por ejemplo, algunos botones, listas, campos de entrada de texto, me parece interesante.
Evgeny Suvorov (Avito): Estoy de acuerdo, esa estructura es bastante exitosa y recientemente la implementamos en nuestro Avito, al menos en la parte de la tienda de comestibles.
Nuestro equipo se hizo grande, probablemente, cuando tuvimos cinco desarrolladores, ya que incluso con tanta cantidad, la autoorganización era difícil. Se hizo más difícil para los chicos ver una característica, tuvieron que separarlos de alguna manera, criarlos en diferentes ángulos, en diferentes características. Los desacuerdos comenzaron en asuntos arquitectónicos y de otro tipo, y las comunicaciones se volvieron más complicadas.
En algún momento, Avito tenía dos grandes equipos: desarrollo de iOS y Android, 15 personas cada uno. Y en esta etapa comenzamos a dividirnos en equipos de productos: se destacaron los grupos "experiencia del comprador", "experiencia del vendedor", mensajería instantánea, entrega, etc. Esto resolvió el problema con prioridades. Anteriormente, muchos gerentes de proyectos acudían a equipos con solicitudes de funciones, y para ellos cada una de estas funciones tenía la prioridad número uno. Como resultado, tenemos 20 proyectos y sus prioridades transversales no están claras. Los padres tuvieron que manejar esto manualmente. Después de destacar los equipos multifuncionales, cada uno de los cuales tiene su propia línea de desarrollo, sus prioridades y recursos, todo se volvió más simple.
Al mismo tiempo, todavía tenemos pequeños equipos de plataforma que toman, como lo llamamos, decisiones "horizontales" que se implementan para todos los equipos de productos.
¿Las reorganizaciones del equipo a menudo tienen lugar?Philip Uvarov (Spotify) : algún tipo de movimiento ocurre cada semana. En nuestra empresa, los equipos son pequeños y autónomos. Si lo desea, puede pasar fácilmente de uno a otro. La frecuencia con la que esto sucede depende del equipo y la dirección en la que trabaje. Donde trabajo, esto no se pronuncia. Pero Spotify es famoso por el hecho de que trabajamos de forma ágil y, en muchos sentidos, cosas como OKR, etc., se nos fueron. Por lo tanto, la gerencia de la compañía no teme cambiar las prioridades, si de repente se da cuenta de que algo no está funcionando. Simplemente cambiamos a otra cosa.
Maxim Efimov (Uber): Tuvimos reformas a gran escala, principalmente relacionadas con el rápido crecimiento de la oficina de Amsterdam. Durante el año, el número de empleados casi se duplicó. Los equipos en los que se reclutaron personas se hicieron muy grandes y fue difícil para un gerente administrar dicha estructura. En este sentido, los equipos simplemente se dividieron en varios "subcomandos", cada uno de los cuales estaba involucrado en un área más estrecha. Me parece que este es un proceso natural.
¿Está de acuerdo con la idea de que en un equipo grande, para que la calidad del código no sufra, vale la pena evitar contratar juniors y seniors sobrecalificados?Philip Uvarov (Spotify) : Creo que ni lo uno ni lo otro. Cada año, Spotify recluta a muchos graduados universitarios a través de la práctica de verano (algunas de las personas después de la práctica reciben una invitación para trabajar). Del mismo modo, tomamos fácilmente a personas con múltiples doctorados.
Las habilidades técnicas son geniales, pero puedes enseñarlas. Si una persona no sabe cómo trabajar en equipo, será extremadamente difícil. Por lo tanto, tales empresas prestan casi más atención a las habilidades blandas.
Y para que la calidad no sufra, necesitamos buenas entrevistas que nos permitan seleccionar desarrolladores no inferiores a algún nivel básico.
Maxim Efimov (Uber): Partimos de un principio ligeramente diferente. Tenemos una proporción deseable de desarrolladores experimentados y junio. Solo para que no haya situación cuando hay una multitud de dzhuns, y no hay nadie para ayudarlos y explicarles cómo trabajar. Por lo tanto, tratamos de mantener un equilibrio.
Adherirse al principio de "no reclutar demasiados señores" no ve el punto. Encontrar un señor es una búsqueda bastante difícil. Hay muchas compañías en el mercado, y la competencia por los desarrolladores es severa. Las personas con experiencia se instalan con éxito en casi cualquier lugar, por lo que renunciar a personal calificado hoy y luego reclutarlos mañana no es realista. Estas personas no se sentarán y esperarán hasta que queramos invitarlos. Y en mi práctica, si una persona tiene buenas competencias, entonces no es un problema encontrarle un lugar en la empresa. Pero debemos proceder de una situación específica. Necesitamos tomar una decisión, dependiendo de las ambiciones que tenga cada persona en el equipo, ver los próximos proyectos, si podemos sacarlos nosotros mismos, a quién necesitamos. Es decir, es necesario descender a la planificación de bajo nivel.
Evgeny Suvorov (Avito): En mi opinión, al reclutar personas mayores, no debes temer que tengan a su propio rey en la cabeza o que no obedecerán.
En nuestra empresa, los propios desarrolladores ofrecen formas de resolver ciertos problemas. Y las personas mayores a menudo tienen soluciones de alta calidad. Tienen experiencia, por lo tanto, con su participación, los problemas se pueden resolver más rápido. Hay otro problema: sus tareas pueden no parecer interesantes o ambiciosas para las personas mayores.
Los jóvenes también deben ser abordados individualmente. Cuando todavía éramos un equipo, de vez en cuando había una sensación intuitiva de que el equipo podría sacar otro junio. Y en ese momento fue posible tomar a un tipo ambicioso maravilloso que creció rápidamente para convertirse en un ingeniero de calidad. En un equipo con procesos bien establecidos, la capacitación es realmente rápida. Sí, y los Jones son diferentes: algunos vienen después de la universidad con ojos ardientes, pero no pueden hacer nada, mientras que otros tienen siete años de experiencia en backend, simplemente cambiaron a aplicaciones móviles.
Es decir, no tenemos miedo de los juniors, pero nos centramos en los sentimientos del equipo, ya sea que lo necesite o no.
Programación, sincronización, distribución de tareas.
¿La planificación y sincronización de desarrolladores dentro de una gran empresa (incluso en equipos pequeños) requiere mucha energía?Philip Uvarov (Spotify) : Esta es solo la división de equipos por producto y no por función: solo planificamos nuestro pequeño producto dentro de la empresa y, a menudo, no nos importa lo que hagan el resto de los millones de desarrolladores.
Artem Olkov (Odnoklassniki): Aquí solo puedo hablar sobre nuestro equipo específico. Hemos comenzado el desarrollo, y esto le da ciertas indulgencias: le permite ser más libre. Por el momento, solo tenemos reuniones diarias de 15 minutos sobre el estado actual y el cierre por hora del anterior / planificación del próximo sprint una vez por semana. Todo lo demás se decide de manera personal.
Maxim Efimov (Uber): En nuestro caso, no muy grande. Quizás es 1.5-2 veces más de lo que me ocupaba cuando trabajaba en la subcontratación.
Es cierto que hay algunos procesos en la empresa, como la revisión de código, que dificultan el desarrollo. Hablando en términos generales, hasta que un equipo responsable de su código revise su confirmación, puede tomar algo de tiempo. Pero no creo que esto se refiera a la tarifa de sincronización. Se trata más de cómo se configura todo este esquema en un nivel bajo: quién revisa a quién, cómo se organiza la espera, etc.
Evgeny Suvorov (Avito): inicialmente resolvimos el problema de sincronización con lanzamientos frecuentes. Como resultado, la sincronización en sí misma ahora toma un poco. Todo está casi automatizado.
¿Necesito distribuir tareas de una manera especial para que la calidad del código no sufra?Philip Uvarov (Spotify) : en equipos grandes, tiene sentido distribuir el producto por área de responsabilidad. Por lo tanto, siempre habrá personas que se acercarán a ellos de manera responsable porque vivirán con ellos más tarde. Su contexto no cambia, es decir , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
. , , . . . , , , . .
. AppsConf 2018ApplsConf 2018 . , .