El desarrollo móvil nativo está muerto!
El desarrollo móvil nativo está muerto!!
Las 9 de la mañana en nuestra empresa!, gritos de nuestros gerente debido al retraso de nuestros proyectos exclaman!:
El desarrollo móvil nativo está muerto!! Larga vida a React Native!, a Xamarin! y al nuevo chico de la cuadra, Flutter!!
Las 9 de la mañana en nuestra empresa!, gritos de nuestros gerente debido al retraso de nuestros proyectos exclaman!:
“Nos estamos moviendo demasiado lento!!”. La idea es que los marcos multiplataforma de forma predeterminada aumenten el rendimiento de un equipo, ya que puede compartir código, y casi cada pulsación de tecla que toque un desarrollador contará para obtener una característica determinada en la línea de llegada para todas las plataformas es la nueva metodología agíl que se esta dando!. (Es lo que anuncia nuestro gerente Senior).
!!Tenemos plazos muy ajustados dictados por marketing y dependemos de otros cinco equipos. Estamos produciendo a alta velocidad constante en todos nuestros equipos, pero están divididos en todas las plataformas. Si mantenemos esta velocidad, aún no será suficiente para entregar a tiempo. Tal vez si utilizáramos una solución multiplataforma como React Native, nuestros equipos frontend web y móviles podrían convertirse en un solo equipo y enviar funciones más rápido en todas las plataformas. Mencionan en la reunión de departamento de esta semana nuestro arquitecto estrella.
El razonamiento en este caso es que la velocidad es una propiedad que se puede sumar linealmente, lo que significa que su magnitud es directamente proporcional mmm!!. Por lo tanto, si tres equipos tienen una velocidad dada, si están fusionados en un solo equipo, su velocidad será cercana a la suma de las tres velocidades. Los frameworks multiplataforma parecen ser algo natural para este tipo de “hack ágil” (Siguiendo con las metodologías ágiles indica un nuevo jefe de proyectos).
“group of people playing soccer” by Quino Al on Unsplash
“Nuestros equipos se mueven a diferentes ritmos indica un gerente!!”
A veces, el síntoma que los gerentes quieren abordar es que los equipos se muevan a diferentes ritmos:
¿Cómo es que nuestro equipo de escritorio implementó esto en un día!!, iOS tarda una semana!!! y Android dos semanas y media? !!!!!mm Es exactamente la misma característica en todas las plataformas, incluso se ve igual. Me imagino que debería tomar el mismo tiempo para todos??. Quizás si usáramos Xamarin, podríamos hacer que todos hicieran su implementación con las mismas API básicas, posiblemente compartiendo también su código. (Se indica en la reunión de máxima prioridad. Con tono de llamada de atención de nuestro mayor Gerente de tecnología).
Un desarrollador valiente del equipo se pronuncia:
Parecería lógico a primera vista que la implementación de la misma característica debería tomar aproximadamente el mismo tiempo para dos equipos de un tamaño comparable, pero a menudo no es el caso. Los proyectos que tienen lanzamientos entrelazados en toda la plataforma no pueden evitar adaptarse al equipo más lento, y trabajar en torno al problema haciendo que el código y la implementación sean los mismos para todos los equipos parece ser una buena idea.
Un desarrollador experimentado de los más confiable para el area de gerencia argumenta lo siguiente:
.. pero ¿te estás dirigiendo a la causa raíz?
Al poner cada uno de esos asuntos bajo un examen más minucioso, probablemente sentirá un hormigueo en la parte posterior de su mente que le dice que esos son solo síntomas de problemas subyacentes más grandes.
Siempre que la producción de un equipo se considere demasiado lenta, a menudo sólo un presentimiento, pero a veces respaldada por datos, la gerencia comenzará a buscar soluciones que aumenten la velocidad. El problema real a menudo está un poco más oculto, y podría no ser visto o entendido por aquellos que toman las decisiones en este tipo de cambios drásticos. Es posible que un gerente sénior no se dé cuenta, por los motivos que sean, de que los equipos se mueven lentamente debido a problemas de proceso o de personal, por lo que asumen que se trata de un problema técnico.
En nuestra experiencia “dice el desarrollador” , los problemas técnicos raramente son la causa de tales ineficiencias. Lo que vemos más a menudo es que el problema radica en otro lado. En estos casos, es extremadamente común ver causas “humanas” que desencadenan la cascada que está detrás de los síntomas.
A veces es simple naturaleza humana, ¿simple? (pregunta el gerente a nuestro desarrollador? si simple: a veces alguien es demasiado orgulloso, o demasiado asustado, para admitir que están equivocados y algo que ellos (u otra persona) están haciendo daño al equipo. Otras veces es la falta de coordinación entre los equipos interdependientes, o tal vez la comunicación interrumpida. O tal vez la gente que trabaja en uno o más equipos está exhausta después de quemarse porque un plazo arbitrario o ajustado los forzó a entrar en una marcha de la muerte y en el modo de crisis.
El gerente argumenta:
Los líderes del equipo, la gerencia media y los desarrolladores no son infalibles. Por eso, por ejemplo, realizamos retrospectivas en todos nuestros proyectos e insistimos en que todos en los equipos participen en ellas; El primer paso para solucionar problemas es hablar sobre ellos. Cuanto antes mejor!!, también: una autopsia después de que las cosas se cayeron y se quemaron puede proporcionar información útil, pero deberíamos hacer todo lo posible para corregir el curso lo antes posible siempre que creamos que algo no funciona. (Ya se nota el ambiente en pie de guerra).
Nuestro desarrollador ya se desato y sigue su descarga emocional de la siguiente forma:
Pero a veces, cuando un trabajo está en riesgo, o cuando la organización circundante tiene una cultura de señalar con el dedo, los problemas se barren debajo de la alfombra y (no) tergiversados voluntariamente. Esto significa que los problemas técnicos se culpan por lo que se trata de causas muy no técnicas. Como era de esperar, esto lleva a equipos infelices a adoptar tecnologías que no les gustan necesariamente, además de los problemas iniciales.
Tienes razón no lo había pensado!, dice el Gerente Senior en un tono de disgusto y a la vez entra en una etapa de entender lo que esta ocurriendo.
Nuestro desarrollador se pone de pie en la reunion y argumenta lo siguiente:
Las herramientas multiplataforma a menudo se malinterpretan en su alcance y capacidades, y esto crea una percepción distorsionada de que pueden ayudar en estas situaciones. Desafortunadamente, algunos (quieren) creer que una cultura y un problema de proceso pueden resolverse con una herramienta, y que son las diferencias comerciales y de idioma actuales las que retrasan la colaboración entre equipos. Sin embargo, si varios equipos de una corporación que escriben Swift para iOS o Java para Android no comparten el código y, lo que es más importante, comparten conocimiento del dominio, es poco probable que la introducción de un marco multiplataforma o cualquier otro cambio tecnológico arreglara esto.
Y que propones buen desarrollador?, exclama nuestro Gerente en un tono sarcástico pero a la vez entendiendo la ventaja del argumento dado por el desarrollador.
Mejora tu estructura
El problema puede estar en varios otros lugares. El entorno de la empresa puede desalentar la eficacia, debido a un alto grado de burocracia o debido a la comunicación indirecta y diferida. La teoría de la ventana rotas formulado por criminología se traduce muy bien a los equipos de desarrollo y entornos de trabajo también. Si un equipo no se ocupa de las cosas pequeñas, eventualmente también descuidará las cosas grandes. Si sus TODOs nunca se abordan, si el estilo del código es incoherente, si los problemas desaparecen en un mar de otras entradas cuando se agregan a su rastreador, si las esquinas se cortan de forma regular para “ahorrar tiempo” y la deuda tecnológica está continuamente acumulados pero nunca tratados, sus equipos lucharán para ser apasionados, ser productivos y ser eficientes. Producirán códigos incorrectos, diseños defectuosos, procesos inadecuados que se complicarán entre sí y empeorarán las cosas, en un ciclo de autorrefuerzo en el que los miembros del equipo se preocupan cada vez menos por qué y cómo funcionan.
Las soluciones a estos problemas no son tan sencillas como la simple adopción de una nueva tecnología, y pueden implicar pasar por un proceso doloroso antes de que las cosas mejoren. Inspírese de cómo otras compañías abordaron sus problemas. Los dolores de equipo y productividad son extremadamente comunes y cada organización los golpea en algún momento. No hay vergüenza en tener dolores de crecimiento, siempre y cuando admitamos que hay dolores e intentemos abordarlos.
Una de las estrategias de reorganización más famosas es la reestructuración ágil de Spotify en tribus, escuadrones, capítulos y gremios. Los escuadrones son equipos verticales y los capítulos son especializaciones horizontales dentro de una tribu, mientras que un gremio es un organismo de tribu cruzada que lidera el camino con respecto a un tema específico (por ejemplo, la seguridad). Puede obtener más información al respecto en el blog de Spotify . Sin embargo, lo que funcionó para Spotify podría no funcionar para su empresa. Es muy importante que elija una estructura y procesos que se ajusten a su entorno, en lugar de intentar forzar una estructura alienígena sobre ella.
Coordinar equipos y sus rendimientos
Uno de los síntomas que mencionamos son los diferentes ritmos en los que los equipos de desarrollo se mueven en diferentes plataformas. Si bien esto se percibe como un problema, de alguna manera está intrínsecamente relacionado con la forma en que funcionan los diferentes equipos y plataformas. La razón más común por la que los equipos trabajan a diferentes ritmos es porque tienen que lidiar con distintas bases de códigos, arquitecturas y niveles de deuda tecnológica .
Un caso común es que la aplicación de iOS tiene una base de código bien mantenida y lidera el conjunto de características, mientras que la base de código de Android ha sido arrojada apresuradamente y nunca ha visto una arquitectura coherente, o al revés. Este último equipo probablemente esté lidiando con enormes cantidades de deuda tecnológica que los ralentiza, un acoplamiento estricto y una baja capacidad de prueba del código que hace que cualquier cambio sea complicado y arriesgado, y una falta de claridad arquitectónica. Hacer cualquier cambio será una tarea monumental, y la velocidad será extremadamente baja.
Escucha a tus desarrolladores!!. Ellos plantearán estos problemas siempre que les solicite estimaciones sobre una función. Asegúrese de incorporar su proceso y programa el tiempo suficiente para que alcancen un nivel aceptable de deuda tecnológica antes de pasar a la siguiente gran parte del trabajo. Por ejemplo, les permite programar una cantidad determinada de mantenimiento en cada sprint o ciclo de desarrollo, y definir plazos de bajo riesgo, como justo después de un lanzamiento, para realizar tareas más grandes, como mejorar la arquitectura y completar los huecos que dejan. cortar esquinas para llegar a la liberación.
Recuerde que los modos de contracción solo pueden mantenerse en ráfagas cortas y raras, y solo deberían ocurrir en circunstancias excepcionales. Las marchas de la muerte son la mejor manera de alienar a su equipo, hacer que sean improductivas y poner en riesgo su salud, todo mientras todavía faltan plazos y características. Establecer expectativas realistas durante la planificación es vital para poder entregar a tiempo y en el alcance, y esta es la razón por la cual todo el equipo debe ser parte de la planificación. Imponer plazos arbitrarios es tan perjudicial como cambiar los ámbitos sin tener en cuenta las diferentes fechas límite; incluso si sus equipos siguen prácticas ágiles, no significa que puedan entregar características arbitrarias en un tiempo arbitrario. Significa que pueden entregar una característica determinada con un alcance inmutable bien definido a tiempo o entregar funciones vagamente definidas con un alcance variable eventualmente , posiblemente antes que con un proceso de cascada.
Centrarse en el valor
Otra falacia común que lleva a los gerentes y equipos a analizar los marcos multiplataforma es que les permitirá ahorrar dinero. Desafortunadamente, eso rara vez es el caso. Realmente apreciamos los marcos que no enfocan su mensaje de marketing en la promesa (a menudo falsa) de ahorrar dinero, sino en el hecho de que pueden aportar valor.
El equipo de Flutter, por ejemplo, a menudo dice que lo que aportan es la capacidad de ofrecer más valor para los usuarios y, por lo tanto, para las empresas. Con Flutter, según su teoría, los desarrolladores pueden alcanzar una mayor velocidad. Con una velocidad más alta, el cliente y el usuario obtienen más valor por la misma cantidad de dinero, en forma de más características, más experimentación y más soluciones para los usuarios. Nunca enfocan su mensaje en compartir código o en reducir costos. En realidad, los lenguajes de programación y las pilas de tecnología son una pequeña parte de la construcción de una aplicación.
Ninguna solución multiplataforma aislará a su equipo de las complejidades y sutilezas de las plataformas en las que se ejecutan. Algo más que aplicaciones triviales, y su equipo inevitablemente tendrá que lidiar con las peculiaridades del sistema operativo que las hospeda. Donde radica esa línea de trivialidad, depende del marco y cómo se emplean. Por ejemplo, Xamarin puede tener esa línea más o menos cerca de cero, dependiendo de si usa Xamarin.Forms o no. Para otros, varía en las API que tienes que usar.
Como resultado, aún necesitará tener al menos un desarrollador que sea un experto en cada plataforma del equipo para poder ser completamente productivo. Dependiendo del marco específico, puede tener dificultades para dotar de personal a un equipo. Esto podría resultar más caro de lo previsto, anulando cualquier ganancia teórica del código compartido. Es un equilibrio cuidadoso que se encuentra y no es para todos.
No creemos que la necesidad de expertos en plataformas vaya a desaparecer, ya que ninguna solución multiplataforma ha encontrado una forma de deshacerse de eso. Considere los 20 años de ejecución de Java, el Slogan de “Escribir una vez, ejecutar en todas partes”, o Mono — el antecesor de Xamarin, o cualquier otra tecnología. Siempre hay una situación en la que necesita, directa o indirectamente, interactuar con la plataforma subyacente fuera del “espacio seguro” del marco.
Lo que esto significa es que elegir un SDK multiplataforma porque se supone que debe ahorrarle dinero es muy probable que sea una mala idea. Lo que debe aspirar a obtener de un equipo multiplataforma es el valor para sus usuarios y, por extensión, para su negocio. Para obtener valor, debe ser consciente de los procesos y el estado de ánimo de sus equipos, y aún así estar al tanto de qué tipo de valor puede aportar un marco y en qué condiciones.
Obtenga valor de la plataforma cruzada
Esto no significa que todos esos marcos multiplataforma no tengan cabida en nuestras cajas de herramientas. Lo que significa es que debemos tratarlos como herramientas, que es lo que son, en lugar de soluciones. Si tiene un problema que puede resolverse con una herramienta de este tipo, y un equipo que puede elegir el nuevo marco y dominarlo, y usted es consciente de los compromisos que implica su elección, puede obtener un gran valor de estos. herramientas y llegar a una solución satisfactoria.
La mera existencia de estos marcos muestra que alguien pensó que podría ser la herramienta adecuada para resolver sus problemas. Facebook creó React Native porque tenían muchos desarrolladores de frontend que estaban familiarizados con ReactJS, y no podían formar equipos móviles lo suficientemente rápido para su enorme crecimiento. Crearon equipos mixtos de ReactJS y desarrolladores móviles, y les dieron una herramienta que les permitió a todos trabajar en aplicaciones móviles.
Es por eso que React Native funciona tan bien para ellos. Además de tener muchos más ingenieros que la mayoría de las compañías que pueden plantear problemas, tienen muchos desarrolladores familiarizados con el paradigma y el lenguaje, o familiarizados con las plataformas subyacentes. Lo mismo vale para AirBnb, que lo está usando con gran éxito. AirBnb logró encontrar problemas que se ajustan a las fortalezas de la herramienta; Facebook había construido la herramienta para trabajar en su situación específica. Las docenas de corporaciones que emplearon con éxito a Xamarin para construir herramientas y proyectos tenían muchos desarrolladores de .Net a su disposición. La agencia que desarrolló la aplicación Hamilton en Flutter en realidad no tenía mucho en el camino de los desarrolladores de Dart, pero tenían el tipo perfecto de proyecto para el marco: interfaz de usuario de marca relativamente baja, con marca, que usa Firebase, para entregarse rápidamente.Y todos tienen algo en común: utilizaron la herramienta adecuada para sus problemas o, en el caso de Facebook, crearon una herramienta que se ajustaba a sus problemas. Como casi nadie es Facebook y no podemos permitirnos crear herramientas desde cero cada vez que tenemos un problema, todo lo que podemos hacer es asegurarnos de que necesitamos una nueva herramienta en primer lugar, y solo en ese caso elegir la que funciona mejor para nosotros.
CONCLUSIÓN
Antes de elegir una herramienta, no importa cuál sea su naturaleza, es importante primero comprender a fondo los problemas y puntos débiles que está tratando de aliviar. Si y solo si su problema es de naturaleza técnica, entonces debe proceder a elegir la herramienta que mejor lo ayude a resolverlo. Pero si su problema está arraigado en otra parte, no importa qué tecnología adopte, estará condenado a repetir los errores del pasado. Después de todo, las tecnologías no pueden crear un proceso o un equipo.
Articulo referencia https://blog.novoda.com/if-cross-platform-is-the-answer-make-sure-youre-asking-the-right-question/
By Jaime Hernández on September 2, 2018.
Exported from Medium on March 15, 2025.
~devjaime