¿Por qué llegar tarde a un vuelo y no volar no siempre es algo malo? ¿Quién tiene la culpa de llegar tarde al muelle? ¿Por qué venir al aeropuerto con anticipación? ¿Puede el A380 volar a Astrakhan? ¿Por qué la intuición no siempre funciona? Las sorpresas suceden, ¿nunca sucedieron y aquí de nuevo? ¿Por qué los pasajeros golpean al piloto después de aterrizar?Suponga que está desarrollando un sistema de información estatal (SIG) a escala nacional. El equipo del proyecto (analistas, desarrolladores, probadores, servicios de soporte, servicios de infraestructura, etc.) es más de cien personas. El sistema se implementó en operación piloto o industrial. Miles de organizaciones se han integrado con su sistema y comenzaron a trabajar con él, incluso más están planeando la integración. Decenas de miles de organizaciones trabajan a través de una interfaz web. El sistema contiene información útil para los ciudadanos y ofrece funciones interesantes. El cliente y / o usuarios requieren nuevas mejoras. Millones de personas en todo el país están registradas y utilizan el sistema. Los obsequios del mundo exterior se presentan en forma de cambios en los precios del petróleo, sanciones, restricciones, etc.
Presentado? Entonces, exactamente un proyecto de este tipo en este momento es el proyecto GIS de vivienda y servicios comunales, del que comenzamos a
hablar antes y ahora queremos continuar.
FuenteLas primeras experiencias de los hermanos Wright.
Lo más probable es que si trabajas en una pequeña empresa y desarrollas “pequeños proyectos”, entonces no tienes muchos procesos de lanzamiento como tales. El esquema de trabajo se parece a esto. Simplemente pretende que sería bueno lanzar algunas funciones en 4-5 meses. Luego, escribe producciones durante otro mes, desarrolla, desarrolla y luego trata de estabilizar toda esta economía para lanzar una nueva versión del software en funcionamiento. Por supuesto, en el momento del lanzamiento resulta que algunas mejoras no pueden estabilizarse de ninguna manera, se revelan fallas en las producciones, ya que las producciones se han realizado durante mucho tiempo y ahora algo ha cambiado, en algún lugar resultó que firmaron bajo una funcionalidad poco realista, etc. Sin embargo, este enfoque funciona bastante bien por sí mismo, pero, por regla general, siempre que el equipo del proyecto sea pequeño y la intensidad de los cambios sea pequeña (el sistema no se puso en funcionamiento o algunos usuarios lo pusieron a prueba, etc.). En principio, sin procesos, puede escalar hasta proyectos bastante grandes, hasta 20 personas y hasta 40 personas, todo depende de la frialdad de las personas y su dedicación. Seguramente, muchas personas están familiarizadas con la situación cuando el equipo del proyecto, que consiste en especialistas frescos y desesperados, en los casos en que los plazos están vencidos y casi todo ha desaparecido amigablemente tenso y ... "sobre sus hombros", "en cajas de pizza moral y de voluntad fuerte" a través de las montañas finalmente sacó la versión a la operación.
Créeme, también pasamos por esto (es por eso que ahora amamos todo tipo de locuras como
Racing Heroes ,
maratones , etc.). Pero en algún momento, nos dimos cuenta de que todo tiene un límite y que al implementar sistemas de vivienda y servicios comunales a escala GIS sin un proceso claro de lanzamiento, tenemos la garantía de obtener tres momentos desagradables principales:
- el cliente no está contento con usted, porque no puede predecir las fechas de lanzamiento de la funcionalidad en funcionamiento y romper constantemente los plazos, y si surge una tarea imprevista, esto genera grandes problemas;
- la calidad de vida de los empleados se está deteriorando debido al caos constante, enfrentamientos, horas extras, etc.
- los líderes de su empresa no están satisfechos con usted, porque los costos serán completamente incontrolables.
La experiencia de LANIT en el desarrollo de viviendas GIS y servicios comunales nos dice que uno de los momentos más importantes para cambiar a "rieles industriales" en la implementación de grandes proyectos es la construcción de calidad del proceso de lanzamiento. Esto, por supuesto, no es suficiente para la felicidad completa, pero el proceso de liberación subyace a todo, y sin él se garantiza que será mucho peor de lo que podría ser.
En este artículo describiremos dos prácticas principales, en nuestra opinión, que subyacen al proceso de lanzamiento efectivo en los sistemas de TI de la escala de servicios comunitarios y de vivienda de SIG:
- uso de un esquema de entrega regular de funcionalidad,
- ciclo de liberación acortado.
Por un lado, estas prácticas son bastante conocidas y se utilizan en muchas metodologías, y también se registran en el
Manifiesto Ágil . Sin embargo, son en gran medida contrarios a la intuición, requieren ciertas calificaciones y habilidades y, por lo tanto, son difíciles de justificar y tienen una falta de comprensión tanto en el Cliente como en el equipo del proyecto. Su implementación en los estándares corporativos requerirá una muy buena comprensión de "lo que queremos lograr" y "por qué exactamente la implementación de estas prácticas conducirá al resultado deseado". A continuación consideraremos con ejemplos estas prácticas y los principales problemas en su implementación.
Cuando analizamos nuestros procesos internos relacionados con la gestión de lanzamientos, una asociación con el trabajo de una aerolínea moderna apareció en mi cabeza.
Tráfico aéreo regular
La aerolínea realizó un análisis de mercado, predijo qué rutas tendrían un gran flujo de pasajeros y serían rentables para la próxima temporada, negoció con quién era necesario, obtuvo los derechos de las rutas necesarias, lanzó vuelos regulares. El horario de vuelo se conoce desde hace mucho tiempo, por lo general, de seis meses a un año. Quien vuela exactamente, la aerolínea, por supuesto, es desconocida: se enfoca en la ocupación promedio proyectada. Además, la aerolínea puede concluir acuerdos a largo plazo con los aeropuertos, pensar en qué aeronave es más ventajosa realizar vuelos, establecer sus propios procedimientos internos, etc. Todo esto contribuye a la optimización de costos.FuenteSi un empleado de la empresa necesita participar en una reunión importante en un momento determinado y luego volar a otra ciudad en avión, simplemente selecciona los vuelos por sí mismo teniendo en cuenta los riesgos de que la reunión se retrase y la situación del tráfico.
Los vuelos regulares tienen sus inconvenientes. Si un empleado compró un boleto para un vuelo, pero no tuvo tiempo, entonces el avión no lo esperará. Desagradable? Si Puede ser que el empleado necesite volar hoy, y hay vuelos solo mañana o dentro de una semana. No tan bueno? Si Pero la gran ventaja es que puede planificar su viaje durante seis meses o un año y asegurarse de que el vuelo tendrá lugar. Sabes exactamente cuándo llegas, y puedes decirle esta vez a tus seres queridos que pueden conocerte, o puedes volar con un traslado y no preocuparte de que no tengas tiempo para atracar. Bueno, en general, piénselo, un enorme y pesado avión de hierro, que para el 90% de la humanidad no comprende cómo vuela en absoluto, lo llevará muy rápidamente, el diablo sabe dónde y le cuesta casi un día o dos en un tren.Volvamos al proyecto. Las utilidades SIG utilizan un suministro regular de funcionalidad. El equipo de
LANIT hace un cronograma de lanzamiento para 1 año, donde fija las fechas de lanzamiento para que los lanzamientos sean aproximadamente 1 vez por mes. Dado que durante el año todo puede cambiar cien veces (más sobre eso a continuación), al momento de compilar el cronograma, aún no sabemos exactamente qué mejoras se implementarán y se pondrán en funcionamiento.
Al planificar, se tiene en cuenta el cronograma de mantenimiento de rutina requerido para el servicio de infraestructura / operación. Es necesario que los cambios globales y heterogéneos no se superpongan entre sí, de esta forma se reducen los riesgos y es más fácil mantener todo bajo control. Por ejemplo, instalar una nueva versión del software y actualizar simultáneamente la versión DBMS o actualizar el firmware de los controladores de almacenamiento es una muy mala idea.
El punto crucial es que las fechas de lanzamiento no cambian posteriormente. Si la versión está planeada para alguna fecha, entonces debemos romper en un pastel, pero resistir el tiempo planeado.A continuación, explicaremos por qué y por qué.
El hecho de que las condiciones para cada lanzamiento sean aproximadamente las mismas (duración, equipo, tareas específicas, etc.) le permite planificar y depurar todos los procedimientos de preparación y lanzamiento.
Las personas que no están inmersas en los procesos de producción pueden no comprender la complejidad de lanzar una versión en un proyecto tan grande como un SIG de vivienda y servicios comunales. Para que se lance la versión, debe realizar muchas operaciones, como pruebas de regresión (quizás varias veces), pruebas de carga, pruebas de implementación y scripts de migración, análisis de estadísticas de rendimiento (consultas SQL, servicios, etc.) . La situación se ve agravada por el hecho de que estas operaciones pueden ser largas, por ejemplo, implementar una versión en un banco de pruebas puede llevar un día. Si algo sale mal, puede salir fácilmente del horario. Por lo tanto, si no tiene un horario con ciclos regulares y aproximadamente de la misma duración, le garantizo que cada problema será para usted 146% una prueba mucho más seria.
El cronograma también es necesario para determinar los plazos para la corrección de defectos y comunicarlos a los usuarios. Nosotros, como regla, corregimos la mayoría de los defectos existentes dentro de la versión actual. Sin embargo, algunos defectos pueden requerir más tiempo o pueden ocurrir al final del ciclo de lanzamiento, por lo que se transfieren a la siguiente versión. Si por alguna razón (ver más abajo) comenzamos a cambiar las versiones, los usuarios recibirán correcciones automáticamente más tarde, lo que no es bueno.
También se necesita un cronograma de lanzamiento de versiones para planificar el lanzamiento en funcionamiento de las mejoras que tienen un plazo claro. El equipo de producción comprende exactamente cuándo debe ponerse en funcionamiento la revisión y selecciona la versión deseada, dentro de la cual se publica. Si se pospone la fecha de lanzamiento, esto puede llevar al hecho de que la revisión se lanzará tarde (sobre las consecuencias del cambio de versión debido a una tarea importante, ver más abajo)
Al igual que los enlaces de transporte regulares, esta es la base del sistema de transporte global, el proceso de lanzamiento basado en la entrega regular de funcionalidad es la base para el desarrollo efectivo de un sistema de vivienda y servicios comunales a escala SIG. Si se establece este proceso, entonces ya es posible "encadenar" planes para la implementación y entrega de funcionalidad.
Desafortunadamente, la forma de introducir esta práctica aparentemente útil desde todos los lados es difícil y espinosa. Las siguientes son las principales trampas en las que puede caer un equipo y que deben ser monitoreadas y suprimidas.
Abordar un avión después del registro
Las aerolíneas tienen un procedimiento de check-in simplificado para los vuelos, que en particular incluye una regla de que un pasajero debe registrarse para un vuelo a más tardar 40 minutos antes de la salida. ¿Por qué necesitas estos 40 minutos? Se necesitan para que haya tiempo suficiente para registrar el equipaje, cargarlo en el avión, de modo que, en función del peso del equipaje y el número de pasajeros registrados, sea posible calcular el combustible requerido, repostar el avión, etc. Además, este tiempo es necesario para que los pasajeros tengan tiempo suficiente para encontrar la salida / terminal deseada. Está claro que algo puede salir mal con la carga o el pasajero (el pasajero se perdió en el aeropuerto o algo sucedió con el equipaje) e incluso estos 40 minutos no serán suficientes. Sin embargo, el tiempo de finalización del registro es un compromiso resuelto durante muchos años entre la pérdida de tiempo de los pasajeros y el riesgo de situaciones de emergencia.
Si a un pasajero le gusta llegar al aeropuerto justo al final del check-in, esto simplemente significa que está de acuerdo con el mayor riesgo de que algo suceda y que no llegue a tiempo para el avión. Si la aerolínea conoce a estas personas, esto conducirá al hecho de que aumentará sus riesgos. Quizás tendrá que pagar un vuelo especial de autobús al avión solo para este pasajero. Quizás, a toda prisa durante el check-in en el último momento, el personal del aeropuerto cometerá un error y el equipaje volará a la ciudad equivocada.FuenteCuando se lanzan lanzamientos, uno de los puntos más importantes es el criterio que debe cumplir la revisión y la fecha límite cuando debe realizarse (similar al final del check-in). El lanzamiento de la versión cada mes significa que si alguna tarea no está lista para este plazo en la versión actual del software, entonces se transfiere a la próxima versión en un mes. A menudo puede soportar esto, pero es especialmente difícil hacerlo cuando la tarea es muy importante, pero al mismo tiempo solo se retrasa unos días o una semana. Hay una gran tentación de romper el plazo e incluir la tarea aún no preparada en el lanzamiento e intentar exprimirla.
¿Por qué es esto malo?
En primer lugar,
debemos admitir y aceptar con valentía el hecho de que todas las "presiones", "qué pasaría si lo atrapamos" probablemente sean un pinchazo en la gestión de la producción. Esto significa que no se tomaron varias medidas por adelantado y la situación se puso en un punto crítico. Ahora la situación se corregirá debido a los "héroes" de individuos o equipos: horas extras, muletas, suerte, etc. Por experiencia, esto puede conducir a una solución del problema a corto plazo, pero si lo hace todo el tiempo, provocará que la gente se "agote" y otras consecuencias muy desagradables.
En segundo lugar, como en el ejemplo con la aerolínea, la fecha límite para la preparación de la tarea es un compromiso entre los plazos y los riesgos. Si comenzamos a violar la fecha límite, aumentamos los riesgos de problemas con la versión: o la versión completa no se lanzará a tiempo, o la calidad se reducirá, y recibiremos un montón de llamadas debido a la funcionalidad inoperante o problemas de trabajo bajo carga.
Desafortunadamente, surgen situaciones en las que hay una tarea muy, muy importante y es necesario liberarla en la versión actual. Pero la idea principal es que tales situaciones no deberían ser una práctica generalmente aceptada y alentada, sino más bien reconocida como un problema y considerada en "retrospectivas".Demora de vuelo por pasajero VIP
Digamos que compró un vuelo con una transferencia. Supongamos que descubrió un tiempo adecuado entre uniones. Llegaste con anticipación al aeropuerto, hiciste el check-in, subiste al avión, llamaste a mi papá y a mi mamá, y luego anunciaron que el vuelo se retrasó, porque una delegación gubernamental importante llega tarde (por supuesto, en su lugar le informarán sobre mal tiempo o controles adicionales :)). Usted, junto con todo el avión, está esperando esta delegación y, como resultado, vuela con un retraso significativo. Al llegar a un punto intermedio, descubre que solo le quedan 30 minutos para navegar en un gran aeropuerto y llegar físicamente a otra terminal. Tal vez usted, por supuesto, llegue a tiempo, o tal vez confunda algo rápidamente y salga corriendo a la terminal equivocada o incluso no tenga tiempo para realizar todos los procedimientos necesarios. ¿Y si también es miembro de alguna otra organización gubernamental (pero simplemente modesta) y también se apresura a alguna parte?FuentePor lo tanto, si la aerolínea permitiera regularmente un cambio en los vuelos, entonces esto generaría problemas desde todos los lados. Para un pasajero, esto significa que tendrá que dedicar más tiempo a las conexiones, los pasajeros tendrán más probabilidades de correr riesgos y llegar hasta el final del registro. Esto conducirá a más conflictos y una pérdida de tiempo. Para la aerolínea, esto también significa que se necesita más tiempo para el tiempo de inactividad en el aeropuerto, lo que aumenta los costos.En el proceso de lanzamiento, si de repente alguna tarea no tiene tiempo para el tiempo programado, también existe la gran tentación de mover todo el lanzamiento, por ejemplo, una semana. Parece que esta es una solución fácil y buena, especialmente si esta tarea está bajo el control del cliente principal.Veamos a qué conduce todo esto en última instancia.
En el proyecto GIS de vivienda y servicios comunales, en el marco de la próxima versión, se emiten hasta 100 tareas y más correcciones de errores. Un cambio de versión significa que los usuarios obtendrán la funcionalidad que necesitan o correcciones de errores más tarde. Por supuesto, el problema en discusión es realmente importante, pero al mismo tiempo, muchas de las 99 tareas restantes también son muy importantes, pero como todo es normal con ellas, ya nos hemos olvidado de ellas.
Siguiente Si comenzamos a cambiar regularmente la versión, el cliente comienza a perder la fe en el plan de lanzamiento. Siempre se le ocurre pensar que sí, por supuesto, el próximo lanzamiento está programado para el 10, pero lo más probable es que suceda algo y habrá un cambio por una semana, o incluso por dos. , .
? , , , . ., . , , . “”, , . - , , , .
— 75-110 ( SSJ-100 ), 140-180 ( A320 , Boeing 737 ), 200-300 ( A330 , A340 ), A380 , 525 853 . , , ., . 380 ( Airbus), , , , . , .. , .
, . , , . , , .
.
, . , , , , , . , , “” . , , . . , ( , , , , , , ).
1. ( ), “ , , ” , . , . , . , , — , .
- , . .
—
, . , . , , - , .- , — , , ( ).
, , , . , , . — , (- ) . , , . , , , “” . , , . , . , 1,5-2 , 1,5 , -.
, :
— — , — , — , .
:
— , , . .
, , . .
. , , .. , . , , . .
, . , , , . , !, — . , , , . , , . . , . , , , . , , . , , .
, , , . , 4 , 2-3. . , .
, , .
. ( — ), .. . , - , , . - , . — , . . , , , . , ( , , , , , , , ..), . , , 2018 2018 , , ASAP . 4-5 ! 5 , 2-3 , 1-1,5 .
, , — .!
. , ! ., - , . , , . , , , - , . , , .
, , , , , , . — , .
, - , - . - . , . , , . , , , .
, . . , , - , .
, . , - , , .
, . , :
.
. ? ? ?