El ciclo de vida del software es conocido por la mayoría de los programadores modernos.
Incluso un niño que escribe su primer programa
<?php echo "Hello, ! " ?>
o
fprintf( ' !\n');
Entiende el proceso.
- Reflexionando sobre la tarea: la etapa de la idea
- Piensa en la tarea y de qué manera debe implementarse: análisis y elaboración de requisitos,
construyendo un modelo de software y un plan de implementación. En resumen, la etapa arquitectónica. - Programacion
- Pruebas "Lo que pasó allí"
- Operación
Entre las etapas 1-5, tenemos procesos que interactúan continuamente.
Para esto, hay todo tipo de cascadas, Scrum, etc.
Entonces, cuando su proyecto se infla a varios tipos de frontend,
Como lo requiere el mundo moderno de TI, el cliente quiere maximizar la audiencia para maximizar sus propias ganancias.
Y por esta razón, todos observamos una gran cantidad de proyectos en los que hay varios tipos de interfaces que interactúan a través de la API con un servidor centralizado.
En términos generales, un "proyecto sólido estándar" tiene tres tipos de frentes:
- Sitio
- Aplicación móvil en Android
- Aplicación móvil IOS
Con una única API desarrollada para intercambiar datos a través de REST.
Un buen ejemplo en el que confiaré es en las redes sociales (vea mi artículo anterior sobre su propio reproductor basado en videos de YouTube)
Un proyecto grande tiene tres opciones para obtener ganancias o cualquier criterio que
condicionalmente Web, apple y android.
Es conveniente que los programadores interactúen con la arquitectura centralizada del backend y se concentren en su frente personal, que están desarrollando.
Y aquí aparece lo más destacado del artículo.
El hecho es que en el nivel superior de toma de decisiones entre los superiores
Se forma una nueva característica, que va hacia atrás. Pero como el "jefe" es una persona imperfecta,
entonces tiene que bajar sus poderes a los niveles inferiores.
Por lo tanto, en nuestro caso, por regla general, sobre cada frente también aparecen sus jefes de "bajo nivel" de acuerdo con motivos jerárquicos o formales. Algo
tipo de timlides para simplicidad.
Y la tarea de desarrollar un gran proyecto en forma de una especie de "ciclo de vida de desarrollo"
y la operación del software se divide en sus ciclos de vida.
Y la pregunta surge al sincronizar los procesos de los ciclos de vida “mini”, porque si está por delante, por ejemplo, de un desarrollador web de una nueva característica, debe esperar a un desarrollador móvil.
De lo contrario, el significado de la nueva característica como tal se pierde en prioridad, porque ahora todos estamos en la web y en aplicaciones móviles desde teléfonos inteligentes.
Pensemos en cómo evaluar la introducción de nuevas características para minimizar los recursos humanos en tal situación.
Aquí voy a expresar las tesis:
- Al implementar una característica en uno de los frentes, debemos tener en cuenta los ciclos de otros frentes, o programar stubs estándar, para que luego podamos "ponernos al día" con las características de otros frentes e incluso igualarlos.
- Puede crear un esquema para el ciclo de desarrollo de software en su conjunto para que todos lo hagan condicionalmente bien, luego la característica se implementará a tiempo, pero al menos se perderá la independencia de los equipos de front-end entre ellos, luego la alimentación y la agilidad para todo el sistema perderán su relevancia o aumentarán el tiempo de iteración desarrollo En resumen, se producirán más conversaciones y el código se escribirá más lentamente.
- Los frentes aislados, en principio, son más rápidos, pero luego se necesitan más pruebas de integración de costos humanos.
- Los esquemas que se están implementando actualmente: cada frente se desarrolla por separado y de forma independiente entre sí con un mínimo de interacciones, pero aquí se pierden algunos de los conceptos básicos de TI: de alguna manera obtendremos un grupo de usuarios distinto de cero que a veces verá errores.
Aquí la filosofía de la pregunta es que a los usuarios no les gustan los errores por definición. Y el cliente busca maximizar las ganancias, por lo que una gran complicación del sistema de alguna manera ralentizará esa maximización, porque este es el ciclo final de vida del proceso del software.
En proyectos más pequeños, este proceso es aún peor: muchos clientes ofrecen desarrollo móvil al sitio remoto, aunque el back-end y la web se llevan a cabo por su cuenta, y regularmente reciben un frenado uniforme en la implementación de funciones.
Por otro lado, existe un obstáculo peligroso para la automatización formal del proceso de implementación: es habitual entre los desarrolladores preguntar al usuario sobre las actualizaciones continuas, por lo que en modo silencioso no funcionará revertir los cambios sin consentimiento.
Mi idea es una idea así: mientras mantiene el tipo principal de ciclo de vida y tiene subtipos en este caso de frentes independientes, debe tener en cuenta una prioridad
tipo de frente (por dinero, razones históricas o de otro tipo), pero deben ser una unidad por debajo del tipo de ciclo de nivel superior.
Es decir, si el frente web prioritario funciona en un scrum semanal, entonces el scrum interno en el frente móvil debería tener el primer doble scrum, dos semanas, de lo contrario
La confusión comenzará. Pero la implementación de una versión grande común de los frentes debe hacerse al mismo tiempo, de lo contrario, tendrá el autor del artículo que escribe esto. Pensemos ...