Hola, soy Andrey Kucherenko, líder del equipo de desarrollo móvil de Skyeng. Hacemos aplicaciones móviles para iOS y Android. Tienen la misma funcionalidad y la misma interfaz precisa para el estilo. Pero debido a las diferentes plataformas, el desarrollo de aparentemente una aplicación es bastante costoso. En busca de oportunidades para ahorrar en el desarrollo multiplataforma móvil, probamos cuatro soluciones:
- Combinando desarrolladores de iOS y Android en un equipo
- Creación de grupos de trabajo para resolver problemas complejos.
- Ahorro en documentación
- Escribir código común
Tuve la oportunidad de hacer varios informes sobre lo que surgió; En este artículo, he recopilado las principales observaciones y resultados.
Combinando desarrolladores de iOS y Android en un equipo
Hace dos años, teníamos dos aplicaciones móviles separadas y dos equipos de desarrollo, conectados solo por un gerente de producto común. De esto surgieron muchos problemas: las aplicaciones de cada uno se parecían externamente solo remotamente, funcionaban de muchas maneras, los desarrolladores no tenían idea de cómo estaba organizada la aplicación vecina, regularmente sacaban todo tipo de errores y errores en la lógica. En cierto momento, quedó claro que esto no podía continuar, y lo primero que hicimos al respecto fue unir a los desarrolladores de iOS y Android en un solo equipo de productos, haciendo que una serie de procesos sean comunes.
Uno de estos procesos se ha convertido en una revisión técnica.
Antes de llegar al desarrollador, la tarea va de cierta manera. Para empezar, está formulado en el formato de Historia de usuario, se dibujan bocetos o diseños, después de lo cual se inicia una epopeya en la que se describe el problema del usuario y su solución. De esta forma, la historia cae en el liderazgo del equipo si es una epopeya entre equipos, o en un líder del equipo si está en el mismo equipo. Allí todo se descompone al nivel de las tareas individuales. En cada una de estas tareas, si corresponde, se describe una posible solución, las tareas dentro de Epic se vinculan entre sí, se colocan varios bloqueadores, lo que elimina muchas comunicaciones innecesarias. Después de eso, se lleva a cabo una revisión técnica directamente, en la que se fijará la decisión final y se pondrá la estimación. También en esta etapa, la tarea puede descomponerse aún más si la estimación se obtiene durante más de dos días.
Cómo ahorramos en la revisión técnica conjunta:
- En la mayoría de los casos, resulta la misma solución técnica para iOS y Android. También son posibles diferentes soluciones, esto puede deberse a la diferente arquitectura de las plataformas, pero en el contexto de la tarea, la diferencia suele ser mínima;
- sincroniza la arquitectura y la estructura de las dos aplicaciones. Esto elimina la situación cuando el producto viene con otra característica, y evaluamos la tarea de iOS a las dos horas, y Android a la semana, porque todo tendrá que reescribirse allí;
- la mayoría de las veces, obtenemos una buena calificación. Si nuestras evaluaciones para las plataformas son muy diferentes, esto puede indicar que los desarrolladores no entendieron la tarea o algunos problemas de la plataforma que deben abordarse;
- Con esta revisión, se produce un intercambio de experiencias entre los desarrolladores de iOS y Android, y creo que deberían tener una idea de cómo funciona la plataforma vecina. A menudo resulta que una solución de una plataforma es exitosa para otra;
- simplificación de pruebas manuales. Las características se implementan sobre la base de una solución técnica, si el control de calidad encuentra algún error, esta es una ocasión para repetir los mismos pasos en otra plataforma. Muy a menudo los mismos errores también están ahí;
- soldados universales, capaces de escribir para ambas plataformas: si lo son, puede cambiarlos entre proyectos, lo que aumenta el factor del autobús y facilita la transferencia de vacaciones y ausencias. No hay situaciones en las que una plataforma se adelante durante las vacaciones.
Factor de autobús: la cantidad de personas en el equipo que el autobús debe derribar para que el proyecto no pueda continuar.
Grupos de trabajo para resolver problemas complejos.
Para resolver un problema, muy a menudo, además de escribir directamente el código, necesitamos realizar algunas investigaciones, llevar a cabo el diseño y, si la tarea implica interacción entre equipos, dedicar mucho tiempo a la comunicación. En el contexto del desarrollo móvil, cualquier tarea que no requiera todo esto es algo trivial, que no implica trabajo desde el backend. Los llamo "simples", y todo lo demás, "complejos".
Analicé los registros de trabajo con respecto a la distribución del tiempo dedicado a la escritura de códigos, comunicación, diseño e investigación. Esto es lo que sucede para tareas simples:
Aquí todo está claro, básicamente escribimos el código, el costo es de hasta el 80% del tiempo.
Muy a menudo, las tareas requieren algún tipo de refinamiento desde el backend, esto automáticamente lo hace entre comandos. Aquí, se dedica más tiempo al diseño y la comunicación. La cuota de escritura de código se reduce:
A menudo, los productos vienen con tareas que no encajan bien con la arquitectura actual de la aplicación, y necesitamos pasar tiempo para encontrar una buena solución: tal vez planear algunas refactorizaciones, llevarlas a cabo de inmediato como parte de la tarea, etc. En este caso, se dedica mucho tiempo al diseño:
Finalmente, las tareas con las que generalmente no está claro cómo abordar, dónde primero debe investigar y diseñar:
Si el trabajo en tareas complejas no se puede coordinar de ninguna manera, todo el trabajo no relacionado directamente con la escritura del código se realizará dos veces. Y en tareas complejas, este es el 50% del tiempo de solución, a menudo incluso más.
Encontré una salida: simplemente tomé y bloqueé todas estas tareas en mí mismo. Logré ahorrar tiempo, pero me sobrecargué constantemente, no tuve tiempo suficiente para prestar atención a las tareas de baja prioridad, los desarrolladores tuvieron que esperarme, todo estaba mal. El problema surgió nuevamente y ya lo resolvimos creando grupos de trabajo.
El grupo de trabajo son algunos desarrolladores de iOS y Android que estarán directamente involucrados en la implementación de esta función. Uno es designado como líder, será él quien sea responsable del diseño, la investigación y la interacción con otros equipos. El resultado de su trabajo será la documentación, donde todo está arreglado; Estos muelles luego son revisados por el grupo de trabajo y el líder del equipo, y el equipo continúa con la implementación.
Como resultado, recibimos:
- La carga en el Timlid ha disminuido, mientras que él no pierde el control sobre el progreso de la tarea. Participo en todas las reuniones clave, reviso la solución técnica, realmente controlo la tarea antes de que llegue directamente al desarrollo;
- Los desarrolladores estaban muy motivados. Cuando probamos esta práctica, todos vinieron y dijeron "genial, intentemos de nuevo". No había personas que no quisieran hacer esto y preferirían "simplemente codificar". Las personas tienen más oportunidades de desarrollo;
- El factor del autobús aumentó, el equipo se volvió más independiente, además de aquellos que pueden desarrollarse aún más en líderes de equipo son claramente visibles en tales tareas. El problema de dejar a Timlida de vacaciones se está resolviendo.
Ahorre en documentación
Decidimos mantener la documentación en el mercado y almacenarla en el repositorio de github. La documentación se revisa junto con el código y la solicitud de extracción, por lo que excluimos las situaciones en las que se escribe algo, pero nadie lo lee, y cuando fue necesario, nadie entiende nada. La documentación con un código le permite sumergirse en el contexto, para comprender de qué se trataba pull-rikvest.
Editamos la documentación directamente desde el IDE, la mayoría de ellos son capaces de generar rebajas, no le impide escribir código, no tiene que entrar en confluencia en algún lugar, se reduce el riesgo de que el desarrollador simplemente se olvide de actualizarlo. Para aquellos que descargaron el repositorio localmente, lanzamos enlaces a Github, también pueden leer todo.
Finalmente, este estilo de acoplamiento ayuda en la incorporación de un nuevo desarrollador: junto con el código, recibe todos los estilos de código, convenciones, instrucciones de ensamblaje de aplicaciones posibles y es mucho más fácil ingresar al equipo.
Código común
La idea de escribir código común no es la más nueva; hay muchas herramientas para hacer esto. Intentamos que C ++ escribiera una biblioteca de vocabulario, y tenemos una pequeña aplicación escrita completamente en Kotlin Multiplatform. Teóricamente, cuando utilizamos una herramienta de desarrollo multiplataforma, nuestros costos de escritura de código deberían reducirse a la mitad. Pero aparecen otros adicionales:
costos de inicio. Se tendrá que dedicar mucho tiempo a recopilar, lanzar, probar, probar hipótesis y capacitar a un equipo. En algunos casos, estos costos son tan grandes que el beneficio no es visible en absoluto;
escribir código de plataforma Según mi propia experiencia y en base a varias fuentes, puedo decir que no importa qué herramienta elijas, si tienes una aplicación bastante complicada, tarde o temprano tendrás que escribir el código de la plataforma. El tiempo para escribirlo varía mucho según las herramientas seleccionadas;
Eliminación de defectos. La mayoría de las herramientas todavía son bastante crudas, tienen errores, tendrá que lidiar con algunas versiones que rompen la compatibilidad con versiones anteriores, y también tomará algún tiempo arreglar todo esto;
elusión de restricciones. Las herramientas multiplataforma pueden tener restricciones arquitectónicas o de otro tipo con las que puede toparse y pasar tiempo para sortearlas. A veces, tales restricciones resultan ser tan severas que uno tiene que abandonar por completo la herramienta. Por ejemplo, Airbnb abandonó React Native y regresó al desarrollo nativo;
La complejidad del desarrollo. Debe escribir código para dos plataformas a la vez, lo que no todos saben, además aparecerán comunicaciones adicionales. La falta de IDEs nativos tampoco simplifica este desarrollo.
Para comparar los costos de los métodos de desarrollo multiplataforma que probamos, identifiqué cuatro grupos principales:
- gastos iniciales
- costos generales de escritura de código
- costos de escritura de código de plataforma
- costos de infraestructura (que no se aplica a los primeros tres puntos)
Tomó una confusión y comparó el tiempo que realmente pasó en el desarrollo multiplataforma y el tiempo que supuestamente dedicaríamos al desarrollo nativo.
Cada columna es tarea. En el caso de C ++, resultó ser un comienzo bastante fácil, pero los costos de infraestructura resultaron ser significativos, el ahorro total: solo el 29%. C ++ también se abandonó porque este lenguaje redujo el factor del bus: nuestros desarrolladores móviles no conocen C ++, pueden admitir el código, pero nadie en el equipo tenía ninguna experiencia seria.
Inicios muy altos, pero si bien los costos de código de plataforma e infraestructura son bajos. No teníamos suficiente para un buen análisis del número de tareas, en la posición actual ahorramos un 19%. Suponiendo que haremos muchas tareas y descartaremos los costos iniciales, obtendremos aproximadamente un 40% de ahorro, a menos que, por supuesto, surjan problemas serios en el futuro. Otra ventaja es que la mayoría de los desarrolladores están familiarizados con Kotlin.
El menos es obvio: la complejidad de los procesos. O escribimos para ambas plataformas a la vez, pero no todas pueden hacerlo, o esperamos hasta que alguien escriba la parte general, luego la revisaremos, luego resulta que no encaja, etc. etc. Tenemos que pagar costos adicionales para la fase de diseño, de modo que probablemente todo se liquide de inmediato.
Total:
- Puede y debe ahorrar en procesos de desarrollo móvil y escritura de código. Los procesos correctamente construidos ayudan no solo a guardar, sino que también resuelven una serie de tareas adicionales.
- Al elegir herramientas para el desarrollo móvil multiplataforma, debe evaluar cuidadosamente los riesgos y los costos laborales reales.