En esta publicación, hablaré sobre los problemas que nuestro equipo Scrum Front End enfrentó durante un año trabajando en un proyecto decente. Comenzamos a desarrollar el proyecto desde cero utilizando la pila de tecnología React + Typescript. Mirando hacia atrás, veo muchos millones desperdiciados simplemente porque el proceso de desarrollo no se estableció desde el principio. Pero hay razones para esto.
Primero tenías que ganar la licitación. Para hacer esto, era necesario presentar rápidamente un Producto valioso mínimo. Y aquí radica el primer error que costó una cantidad decente para nuestro cliente. Suena así: rápidamente corta MVP. El cliente quiere ver rápidamente el resultado, pero esto significa que sacrificamos una buena infraestructura, una arquitectura confiable y un año después llegamos a la conclusión de que nuestra arquitectura Front End requiere una refactorización seria. Unos pocos meses. Entonces filtramos 500,000 rublos.
Mirando hacia atrás, puedo decir con confianza que lo primero que se debe hacer es tener en cuenta toda la funcionalidad que el cliente quería ver al final, después de unos años. Por lo tanto, podríamos evitar errores arquitectónicos en el estilo de "esta arquitectura no proporciona esto". Como resultado, cada chip principal requería una refactorización seria.
Para ganar la licitación, nuestra empresa envió desarrolladores que no tenían experiencia en el diseño de grandes aplicaciones y sistemas extensibles confiables. Claro, la licitación no es una orden, y nadie quiere dispersar a un buen personal. Pero la falta de un arquitecto técnico en el (nivel de clase) llevó al hecho de que nuestra aplicación se convirtió en código de espagueti y dejó de cumplir con los requisitos de SOLID. Y aquí yace el error de cada cliente. No es posible mantener un ritmo constante de desarrollo sin aumentar los recursos del equipo. El principio ágil "Los inversores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente" solo funciona en caso de que los requisitos se conocieran y se resolvieran desde el principio, se diseñó todo el conjunto de funcionalidades, una arquitectura confiable y extensible (en una palabra, si cada clase se pensó teniendo en cuenta el final funcionalidad del sistema) y procesos claramente definidos. Y esto tenía que hacerse en MPV antes de aserrar el producto. De lo contrario, con el tiempo lineal, la complejidad de la aplicación crece exponencialmente. Esto significa que la función de corte en un año le costará a O (e (N)) más caro que al principio.
En nuestro equipo, el único diseñador era un empleado remoto. Fue un grave error. Un empleado remoto siempre vive su propia vida. Dibuja un diseño para sí mismo, bella y bien, el cliente está contento. Pero todos estos encantos finalmente se reducen al hecho de que en las mismas formas lógicas tenemos N estilos y diseños diferentes. Desde el principio, valió la pena poner un requisito: estilizar un cierto marco (teníamos Ant Design). Si algo no está allí, haz lo que está allí. El cliente pensó que React era un constructor de bloques. Y todavía no entiende por qué estamos aserrando formas primitivas durante 4 días. React es un constructor, pero solo si al comienzo del desarrollo tenemos un conjunto de componentes reutilizables similares (marco UI). Un diseñador sin experiencia en diseño nunca lo hará por sí mismo. El desarrollador nunca le dirá al cliente sobre esto. Esto debe ser seguido por el líder. Entonces, el líder del equipo de Front End debería ser el desarrollador de Front End en el pasado, y no el Back End como siempre. Por lo tanto, llegamos a la conclusión de que un equipo ágil completamente funcional debe incluir un líder competente en cada una de sus áreas de trabajo (FE, BE). Estos líderes deben tener fuertes habilidades blandas para transmitir al cliente lo que estoy tratando de describir en este artículo. Y esto es muy, muy difícil.
Cuando lanzamos el primer lanzamiento, nos dimos cuenta de que algo se estaba rompiendo constantemente el último día antes de la demostración. A lo largo del año de desarrollo, cada rama de lanzamiento se convierte en un conjunto infernal de muletas (apáguelo, retírelo) que luego mágicamente terminan en la rama de desarrollo. Y hay una serie de confirmaciones (activar esto, activarlo). Después de un año, llegamos a la conclusión de que necesitamos tener una política de ramificación clara. Pero lo más importante, una persona responsable que eliminaría el caos existente. Esto significaba: o moderar los deseos caóticos del cliente, o moderar los errores caóticos, o en cada stand tener su propia configuración deshabilitando algún tipo de funciones gráficas o botones. Ajustar cada botón en una declaración if es una locura. Hemos llegado a la conclusión de que necesitamos una arquitectura de front-end modular modular con función de complemento (deshabilitar - habilitar). Pensé durante mucho tiempo cómo lograr tal arquitectura. Pero una cosa entendí con seguridad. Necesitábamos un contexto completo. Así nació la biblioteca js-beans (https://www.npmjs.com/package/js-beans). Cada stand tenía su propio contexto json. Los complementos se recopilaron en una cadena (cadena) a través del patrón Proxy. Por ejemplo, teníamos una fuente de datos como un contenedor separado, y se realizaron varias transformaciones como contenedores Proxy opcionales reemplazando este contenedor, pero inyectándolo en sí mismo. Por ejemplo, si necesita escalar el modelo de datos para probar el rendimiento de FPS, simplemente agrego la línea para habilitar el complemento de escalado en el archivo json. Algo se rompió en la producción, pero no se reproduce localmente, enciendo el registrador con una línea sin reconstruir el soporte (el soporte tarda unos 20 minutos, y una docena de stands no siempre son suficientes para todos). O si necesita apagar rápidamente algún módulo debido al hecho de que puede romperse (deshabilite el bean opcional en el contexto).
A medida que pasó el tiempo, las gradas se apagaron durante una semana. Era imposible desarrollar el frente localmente. No hemos previsto una arquitectura autónoma en los mokas. Tuve que atravesar el dolor con un crujido. Mirando hacia atrás ahora, lo habría hecho desde el principio. Pero teníamos MVP y nos vimos obligados a escribir código sin una ingeniería profunda. Pero el cliente nos consideró profesionales y pensó que deberíamos escribir el código inmediatamente sin errores. Aquí está el siguiente error. El nombre de la empresa no habla de la profesionalidad del equipo. La profesionalidad del equipo está determinada por la profesionalidad del líder del equipo. Si no hay un líder técnico en el equipo, en un año su proyecto se detendrá. Entonces fusionas un par de millones más.
Teníamos un arquitecto remoto. Pero solo se sabía una cosa sobre él: lo es. La última etapa de desarrollo del líder según Vladimir Tarasov. En esto nuestro arquitecto logró la perfección. Error número N: no tiene un arquitecto técnico que diseñe el sistema a nivel de clase. No tiene una persona para pedir ayuda si está parado. Solicite ayuda de otros equipos más experimentados, nos dijo el cliente. Pero por alguna razón, los otros equipos nunca tuvieron tiempo de ayudarnos. Nuestro PR ha estado colgando por segundo mes. Sinceramente espero que haya un hombre valiente que lo apruebe. Como resultado, la vida ha recompensado nuestro código con una rica abundancia de fenómenos paranormales en forma de magia y muletas para todas las ocasiones. Solo faltaba uno. Anotaciones especiales
Magic y @Kostyle. Buena idea para el próximo ES.
Decidimos que más medios y menos hombres eran más rentables para el proyecto. Ahora pensamos de manera diferente. Si tiene un presupuesto pequeño, debe contratar a los especialistas más caros. Si usted, como el nuestro, no tiene problemas de presupuesto, puede ahorrar de forma segura en especialistas y convertir la Revisión de Código en una batalla de psíquicos.
Pensamos que cumpliríamos los plazos trimestrales. Ahora pensamos de manera diferente. En resumen, para bien, necesitamos reescribir el proyecto. Y preferiblemente desde cero. Espero que nuestro cliente nunca lo sepa. Después de todo, recientemente tuvimos un magnífico trabajo en equipo)
Decidimos jugar con las nuevas tecnologías en las que teníamos poca experiencia. Nos lo recomendaron. Por supuesto que queríamos ganar experiencia. Ahora creo que sería mejor usar solo aquellas tecnologías en las que tengo experiencia.
Dimos estimaciones basadas en un día laboral de 8 horas. En realidad, las estimaciones deben darse sobre la base de un día laboral de 4 horas. ¿Por qué nadie incluye té, contar historias interesantes, encontrar un baño en el navegador, hablar por teléfono, correspondencia, estudiar nuevas tecnologías y, lo más importante, disputas entusiastas dentro del equipo? Este último es probablemente el más inevitable y el más caro. Aunque, para ser honesto, para Open Space aún necesitas tirar un par de horas. La conversación constante reduce terriblemente la concentración. ¡Bendito el cliente que comprende todo esto!
Nuestras estimaciones fueron agotadoras y se convirtieron en una tediosa polémica técnica de todos modos. La efectividad de los mítines fue mínima. Pero encontramos una solución: deliciosa pizza. Cuando un olor delicioso irrita la nariz, una persona comienza a expresar sus pensamientos con mayor claridad.
Al principio teníamos un equipo pequeño, luego un equipo grande. La planificación tomó 2-3 horas. Standup 30 minutos. Por lo que respeto a nuestro PO, es porque decidió dividirlo en muchos pequeños y asignar su propio mini PO en cada uno de ellos. Esta fue probablemente la mejor decisión en la historia de nuestro proyecto.
Desde el principio, no tuvimos tiempo para escribir pruebas. Después de medio año, llegamos a la conclusión de que aún necesitaban ser escritos. Pero todavía no encontramos tiempo para esto. Se ha acumulado una deuda técnica de mayor prioridad. No ahorre deudas técnicas, esto es utopía. El siempre lo será.
Mis conclusiones subjetivas personales:
- Si sus desarrolladores no entienden para qué sirve IOC para FrontEnd, lo más probable es que cuando entiendan que sea demasiado tarde.
- Si sus desarrolladores no entienden por qué FrontEnd necesita conocimiento de OOP, entonces su código difícilmente puede ser compatible.
- Los especialistas menos costosos son mejores que los más rentables.
- Si tiene un arquitecto, lo más probable es que necesite uno más.
- Si está cortando MVP, termínelo y cambie el proyecto.
- Si MVP ya se ha registrado antes que usted, no vaya a este proyecto.
- Si tienes un MVP y no quieres irte, lo más probable es que cambies de opinión.
- Si tienes el MVP de zapilili y quieres que tu proyecto sobreviva, reescríbelo desde cero.
- Si le muestra este artículo a un cliente, lo más probable es que lo despidan.
- Si trabajas en Agile, lo más probable es que me entiendas.
Es poco probable que evite todos estos problemas incluso después de leer este artículo. Mi objetivo es mostrarte que esto es inevitable. Y no importa cuánto lo intentes, nunca tendrás las condiciones ideales. Así que prepárate para ello. Y antes del despido, puede mostrar este artículo de forma segura a su cliente. Deja que esté moralmente listo para esto.
PD: Maxim, si alguna vez lees este artículo, debes saber que todo lo que describí es completamente ficticio y no se parece a nuestro proyecto) Pero todo esto no es importante, porque hoy me voy de vacaciones. ¡Las primeras vacaciones en un año de arduo trabajo irregular! (como plomo FE).