Algo muy común es que los equipos de cada proyecto carecen de un flujo de trabajo claro. Lo más importante es que los programadores no entienden cómo comunicarse con los clientes y entre ellos. Cómo establecer un proceso continuo de desarrollo de productos de calidad. Cómo planificar tu día de trabajo y sprint.
Al final, todo esto se traducirá en plazos de interrupción, horas extra, enfrentamientos constantes sobre quién es responsable e insatisfacción del cliente: dónde y cómo se transfiere todo. Por lo general, todo esto conducirá a cambios en el programador y en todo el equipo. Pérdida de clientes, degradación de la reputación, etc.
Lo primero que debes hacer es diseñar un flujo de trabajo que se ajuste a la visión en ese momento desde cero
Lo primero que debes hacer es diseñar un flujo de trabajo que se ajuste a la visión en ese momento desde cero y escribir una descripción del mismo para el equipo. No es fácil de implementar. Debes mostrarle a tu equipo que esto no es solo una tormenta, sino también una forma real de salir del apuro, debes asumir mayor responsabilidad y eliminar los hábitos que no sumen al equipo.
Proceso de equipo interno (entre desarrolladores):
-Todas las tareas se crean en el sistema común.
-Cada tarea debe describirse tanto como sea posible, y una acción debe realizarse estrictamente.
-Cualquier función (si es lo suficientemente compleja) se dividirá en muchas más pequeños.
-El equipo trabaja en funciones como una sola tarea. Primero, completamos una función juntos, la enviamos para probar y luego pasamos a la siguiente función.
-Cada tarea está marcada como backend o frontend.
-Una vez completada la tarea, pasará al estado de revisión de código (esto creará una solicitud de extracción para su colega).
-Quién completa la tarea, quién ocupa inmediatamente su tiempo para este fin.
-Después de verificar el código, se aprobará y luego, la persona que realizó esta tarea lo fusiona de forma independiente en la rama maestra y luego cambia su estado para estar listo para la implementación en el servidor de desarrollo.
-Todas las tareas que están listas para implementarse en el servidor de desarrollo las implementa el líder del equipo (es su ámbito de responsabilidad) y, a veces, los miembros del equipo en situaciones de emergencia.
-Después de la implementación, todas las tareas que están listas para implementarse en el servidor original se transferirán al estado, listas para ser probadas en el servidor original.
-Todas las tareas son probadas por el cliente.
-Una vez que el cliente prueba la tarea en el servidor original, la transfiere a un estado en el que está lista para implementarse en producción.
-Para la implementación de producción, debe haber una rama separada y solo fusionamos la base de datos principal antes de la implementación.
-Si el cliente encuentra un error durante la prueba, volverá a la tarea de revisión y se configurará para volver al estado de revisión. Por lo tanto, separamos las nuevas tareas de las no probadas.
-Como resultado, todas las tareas desde la creación hasta su finalización: por hacer → en desarrollo → revisión de código → listo para implementar para los desarrolladores → control de calidad del desarrollador → (regresar al desarrollador) → listo para implementar en el producto → listo para la calidad el producto Verificar → completar.
-Cada desarrollador prueba de forma independiente su código, incluidas las pruebas como usuario del sitio. Si no está seguro de si el código funciona correctamente, no puede fusionar ramas de la principal.
-Cada tarea tiene una prioridad. El cliente o el líder del equipo determina la misma.
-Los desarrolladores primero asumen las tareas prioritarias.
-Si se encuentran diferentes errores en el sistema, o una tarea consiste en el trabajo de varios expertos, los desarrolladores pueden asignarse tareas entre sí.
-Todas las tareas creadas por el cliente son evaluadas por el líder del equipo, quien luego evalúa o solicita al cliente que las modifique o se las asigne a uno de los miembros del equipo.
