Pourquoi être en retard pour un vol et ne pas voler n'est pas toujours une mauvaise chose? Qui est à blâmer d'être en retard pour le quai? Pourquoi venir à l'aéroport à l'avance? L'A380 peut-il voler vers Astrakhan? Pourquoi l'intuition ne fonctionne-t-elle pas toujours? Des surprises se produisent - jamais arrivé et ici encore? Pourquoi les passagers claquent le pilote après l'atterrissage?Supposons que vous développez un système d'information à l'échelle nationale (SIG) à l'échelle nationale. L'équipe projet (analystes, développeurs, testeurs, services de support, services d'infrastructure, etc.) compte plus d'une centaine de personnes. Le système a été mis en œuvre en fonctionnement pilote ou industriel. Des milliers d'organisations se sont intégrées à votre système et ont commencé à travailler avec celui-ci, encore plus prévoient l'intégration. Des dizaines de milliers d'organisations travaillent via une interface Web. Le système contient des informations utiles pour les citoyens et fournit des fonctions intéressantes. Le client et / ou les utilisateurs ont besoin de nouvelles améliorations. Des millions de personnes à travers le pays sont enregistrées et utilisent le système. Les cadeaux du monde extérieur prennent la forme de modifications des prix du pétrole, de sanctions, de restrictions, etc.
Présenté? Donc, exactement un tel projet en ce moment est le projet de logement et de services communaux SIG, dont nous avons commencé à
parler plus tôt et que nous voulons maintenant continuer.
SourceLes premières expériences des frères Wright
Très probablement, si vous travaillez dans une petite entreprise et développez de «petits projets», vous n'avez pas beaucoup de processus de publication en tant que tels. Le schéma de travail ressemble à ceci. Vous prétendez simplement que ce serait bien de publier certaines fonctionnalités dans 4-5 mois. Ensuite, vous écrivez des productions pour un autre mois, développez, développez, puis essayez de stabiliser toute cette économie afin de sortir une nouvelle version du logiciel en fonctionnement. Bien sûr, au moment de la sortie, il s'avère que certaines améliorations ne peuvent en aucun cas être stabilisées, quelque part des défauts dans les productions sont révélés, car les productions ont été faites depuis longtemps et maintenant quelque chose a changé, quelque part il s'est avéré qu'ils ont signé sous une fonctionnalité irréaliste, etc. Néanmoins, cette approche fonctionne assez bien pour elle-même, mais, en règle générale, tant que l'équipe de projet est petite et que l'intensité des changements est faible (le système n'a pas été mis en service ou a été piloté par certains utilisateurs, etc.). En principe, sans processus, vous pouvez mettre à l'échelle des projets assez importants - jusqu'à 20 personnes et jusqu'à 40 personnes - tout dépend de la fraîcheur des individus et de leur dévouement. Certes, beaucoup de gens connaissent la situation lorsque l'équipe de projet, composée de spécialistes cool et désespérés, dans les cas où les délais sont respectés et presque tout a disparu à l'amiable et ... "sur leurs épaules", "sur des boîtes à pizza" morales et volontaires "à travers les montagnes a finalement mis la version en service.
Croyez-moi, nous avons également vécu cela (c'est pourquoi nous aimons maintenant toutes sortes de choses folles comme
Racing Heroes ,
marathons , etc.). Mais à un moment donné, nous avons réalisé que tout a une limite et que lors de la mise en œuvre de systèmes de logement et de services communaux à l'échelle du SIG sans processus de libération clair, nous sommes assurés d'obtenir trois principaux moments désagréables:
- le client n'est pas satisfait de vous, car vous ne pouvez pas prévoir les dates de mise en service de la fonctionnalité et casser constamment les délais, et si une tâche imprévue survient, cela entraîne de gros problèmes;
- la qualité de vie des employés se détériore en raison du chaos constant, des confrontations, des heures supplémentaires, etc.;
- les dirigeants de votre entreprise ne sont pas satisfaits de vous, car les coûts seront totalement incontrôlables.
L' expérience de LANIT dans le développement de logements SIG et de services communaux nous apprend que l'un des moments les plus importants pour passer aux «rails industriels» dans la mise en œuvre de grands projets est la construction de qualité du processus de libération. Bien sûr, cela ne suffit pas pour un bonheur complet, mais le processus de sortie sous-tend tout, et sans cela, vous êtes assuré d'être bien pire qu'il ne pourrait l'être.
Dans cet article, nous décrirons à notre avis deux principales pratiques qui sous-tendent le processus de diffusion efficace dans les systèmes informatiques de l'échelle du logement et des services communaux SIG:
- utilisation d'un schéma de livraison régulière de fonctionnalités,
- cycle de libération raccourci.
D'une part, ces pratiques sont assez bien connues et sont utilisées dans de nombreuses méthodologies, ainsi que enregistrées dans
Agile Manifesto . Cependant, ils sont en grande partie contraires à l'intuition, nécessitent certaines qualifications et compétences, et sont donc difficiles à justifier et à rencontrer un manque de compréhension tant chez le client que dans l'équipe de projet. Leur mise en œuvre dans les normes d'entreprise nécessitera une très bonne compréhension de «ce que nous voulons réaliser» et «pourquoi exactement la mise en œuvre de ces pratiques conduira au résultat souhaité». Ci-dessous, nous examinerons avec des exemples ces pratiques et les principaux problèmes de leur mise en œuvre.
Lorsque nous avons analysé nos processus internes liés à la gestion des versions, une association avec le travail d'une compagnie aérienne moderne est apparue dans ma tête.
Trafic aérien régulier
La compagnie aérienne a fait une analyse de marché, a prédit quelles routes auraient un grand flux de passagers et deviendrait rentable pour la prochaine saison, a négocié avec qui elle était nécessaire, a obtenu les droits sur les routes nécessaires, a lancé des vols réguliers. L'horaire des vols est connu depuis longtemps, en règle générale, de six mois à un an. Qui vole exactement, la compagnie aérienne, bien sûr, est inconnue - elle se concentre sur l'occupation moyenne projetée. De plus, la compagnie aérienne peut conclure des accords à long terme avec les aéroports, réfléchir aux avions qu'il est le plus avantageux de mettre sur les vols, établir ses propres procédures internes, etc. Tout cela contribue à l'optimisation des coûts.SourceSi un employé de l'entreprise a besoin de participer à une réunion importante à un certain moment, puis de s'envoler pour une autre ville en avion, il sélectionne simplement les vols pour lui-même en tenant compte des risques de retard de la réunion et de la situation du trafic.
Les vols réguliers ont leurs inconvénients. Si un employé a acheté un billet d'avion mais n'a pas eu le temps, l'avion ne l'attendra pas. Désagréable? Oui Il se peut que l'employé doive s'envoler aujourd'hui, et il n'y a des vols que demain ou dans une semaine. Pas si bon? Oui Mais le gros avantage est que vous pouvez planifier votre voyage pendant six mois ou un an et être sûr que le vol aura lieu. Vous savez exactement quand vous arrivez, et vous pouvez dire cette heure à vos proches qui peuvent vous rencontrer, ou vous pouvez voler avec un transfert et ne vous inquiétez pas que vous n'aurez pas le temps d'accoster. Eh bien, en général, pensez-y, un énorme avion de fer lourd, qui pour 90% de l'humanité ne comprend pas du tout comment il vole, vous transportera très rapidement, le diable sait où et cela vous coûtera presque comme un jour ou deux dans un train.Revenons au projet. Les utilitaires SIG utilisent régulièrement des fonctionnalités. L'équipe
LANIT établit un calendrier de sortie pour 1 an, où elle fixe les dates de sortie afin que les sorties soient environ 1 fois par mois. Étant donné qu'au cours de l'année, tout peut encore changer cent fois (plus de détails ci-dessous), au moment de la compilation du calendrier, nous ne savons toujours pas exactement quelles améliorations seront mises en œuvre et mises en service.
Lors de la planification, le calendrier d'entretien courant requis pour le service d'infrastructure / d'exploitation est pris en compte. Il est nécessaire que les changements globaux et hétérogènes ne se chevauchent pas - de cette façon, les risques sont réduits et il est plus facile de tout garder sous contrôle. Par exemple, l'installation d'une nouvelle version du logiciel et la mise à niveau simultanée de la version du SGBD ou la mise à jour du micrologiciel des contrôleurs de stockage est une très mauvaise idée.
Le point crucial est que les dates de sortie ne changent pas par la suite. Si la version est prévue pour une certaine date, alors nous devons nous casser dans un gâteau, mais résister à l'heure prévue.Ensuite, nous expliquerons pourquoi et pourquoi.
Le fait que les conditions de chaque version soient approximativement les mêmes (durée, équipe, tâches spécifiques, etc.) vous permet de planifier et de déboguer toutes les procédures de préparation et de publication.
Les personnes qui ne sont pas immergées dans les processus de production peuvent ne pas comprendre la complexité de publier une version sur un projet aussi important qu'un logement SIG et des services communaux. Pour que la version soit publiée, vous devez effectuer de nombreuses opérations, telles que des tests de régression (peut-être plusieurs fois), des tests de charge, des tests de déploiement et des scripts de migration, analyser les statistiques de performances (requêtes SQL, services, etc.) . La situation est aggravée par le fait que ces opérations peuvent être longues, par exemple, le déploiement d'une version sur un banc de test peut prendre une journée. En cas de problème, vous pouvez facilement quitter le programme. Par conséquent, si vous n'avez pas d'horaire avec des cycles réguliers et approximativement de même durée, je vous garantis que chaque problème sera pour vous un test beaucoup plus sérieux à 146%.
Le planning est également nécessaire pour déterminer les délais de correction des défauts et les communiquer aux utilisateurs. En règle générale, nous corrigeons la plupart des défauts existants dans la version actuelle. Cependant, certains défauts peuvent nécessiter plus de temps, ou ils peuvent survenir à la fin du cycle de publication, de sorte qu'ils sont transférés vers la version suivante. Si pour une raison quelconque (voir ci-dessous) nous commençons à changer de version, les utilisateurs recevront automatiquement des corrections plus tard, ce qui n'est pas bon.
Un calendrier de publication des versions est également nécessaire pour planifier la mise en service des améliorations qui ont un délai clair. L'équipe de production sait exactement quand la révision doit être mise en service et sélectionne la version souhaitée, dans laquelle elle est publiée. Si la date de sortie est reportée, cela peut conduire au fait que la révision sera publiée tardivement (sur les conséquences du changement de version en raison d'une tâche importante, voir ci-dessous)
Tout comme les liaisons de transport régulières, c'est la base du système de transport mondial, le processus de libération basé sur la fourniture régulière de fonctionnalités est la base du développement efficace d'un système de logement et de services communaux à l'échelle du SIG. Si ce processus est établi, il est déjà possible de "ficeler" des plans pour la mise en œuvre et la livraison de fonctionnalités.
Malheureusement, la manière d'introduire une telle pratique apparemment utile de tous les côtés est difficile et épineuse. Voici les principaux pièges dans lesquels une équipe peut tomber et qui doivent être surveillés et supprimés.
Embarquement dans un avion après l'enregistrement
Les compagnies aériennes ont une procédure d'enregistrement simplifiée pour les vols, qui comprend notamment une règle selon laquelle un passager doit s'enregistrer pour un vol au plus tard 40 minutes avant le départ. Pourquoi avez-vous besoin de ces 40 minutes? Ils sont nécessaires pour qu'il y ait suffisamment de temps pour enregistrer les bagages, les charger dans l'avion, de sorte qu'en fonction du poids des bagages et du nombre de passagers enregistrés, il soit possible de calculer le carburant requis, de faire le plein de l'avion, etc. De plus, ce temps est nécessaire pour que les passagers aient suffisamment de temps pour trouver la sortie / le terminal souhaité. Il est clair que quelque chose peut mal tourner avec le fret ou le passager (le passager s'est perdu à l'aéroport ou quelque chose s'est passé avec les bagages) et même ces 40 minutes ne suffiront pas. Mais néanmoins, l'heure de la fin de l'immatriculation est un compromis élaboré depuis de nombreuses années entre la perte de temps des passagers et le risque de situations d'urgence.
Si un passager aime arriver à l'aéroport juste à la fin de l'enregistrement, cela signifie simplement qu'il est d'accord avec le risque accru que quelque chose se produise et qu'il ne soit pas à temps pour l'avion. Si la compagnie aérienne rencontre ces personnes, cela conduira au fait qu'elle augmentera ses risques. Peut-être qu'elle devra payer un vol spécial en bus pour l'avion uniquement pour ce passager. Peut-être, pressé lors de l'enregistrement au dernier moment, le personnel de l'aéroport fera une erreur et les bagages s'envoleront vers la mauvaise ville.SourceLors de la publication des versions, l'un des points les plus importants est les critères auxquels la révision doit satisfaire et la date limite à laquelle elle doit être effectuée (similaire à la fin de l'enregistrement). La sortie de la version tous les mois signifie que si une tâche n'est pas prête pour ce délai dans la version actuelle du logiciel, elle est transférée à la prochaine version dans un mois. Souvent, vous pouvez supporter cela, mais il est particulièrement difficile de le faire lorsque la tâche est très importante, mais en même temps, elle n'a que quelques jours ou une semaine de retard. Il y a une très grande tentation de briser le délai et d'inclure la tâche pas encore prête dans la version et d'essayer de la faire sortir.
Pourquoi est-ce mauvais?
Premièrement,
nous devons courageusement admettre et accepter le fait que, toutes les «pressions», «et si nous l'attrapons» est très probablement une crevaison de la gestion de la production. Cela signifie que diverses mesures n'ont pas été prises à l'avance et que la situation est devenue critique. Maintenant, la situation sera corrigée en raison des «héros» des individus ou des équipes - heures supplémentaires, béquilles, chance, etc. Par expérience, cela peut conduire à une solution du problème à court terme, mais si vous le faites tout le temps, cela entraînera des «épuisements» et d'autres conséquences très désagréables.
Deuxièmement, comme dans l'exemple avec la compagnie aérienne, le délai de préparation aux tâches est un compromis entre les délais et les risques. Si nous commençons à violer le délai, alors nous augmentons les risques de problèmes avec la version - soit la version entière ne sera pas publiée à temps, soit la qualité sera réduite, et nous recevrons un arbre d'appels en raison de fonctionnalités inopérantes ou de problèmes de travail sous charge.
Malheureusement, des situations où il y a une tâche très, très importante et qu'il est nécessaire de la publier dans la version actuelle, se présentent. Mais l'idée principale est que de telles situations ne devraient pas être une pratique généralement acceptée et encouragées, mais plutôt reconnues comme un problème et considérées dans des «rétrospectives».Retard de vol dû au passager VIP
Supposons que vous ayez acheté un vol avec transfert. Supposons que vous ayez trouvé un temps suffisant entre les jointures. Vous êtes arrivé à l'avance à l'aéroport, avez effectué l'enregistrement, monté à bord de l'avion, téléphoné à mon père et à ma mère, puis ils ont annoncé que le vol était retardé, car une importante délégation gouvernementale est en retard (bien sûr, au lieu de cela, ils vous parleront du mauvais temps ou de contrôles supplémentaires :)). Vous, ainsi que l'avion tout entier, attendez cette délégation et, par conséquent, vous vous envolez avec un retard important. En arrivant à un point intermédiaire, vous constatez qu'il ne vous reste que 30 minutes pour naviguer dans un immense aéroport, vous rendre physiquement à un autre terminal. Peut-être que vous serez bien sûr à l'heure, ou que vous confondez quelque chose à la hâte et que vous vous enfuyez dans le mauvais terminal ou même que vous n'avez tout simplement pas le temps de passer par toutes les procédures nécessaires. Et si vous êtes également membre d'une autre organisation gouvernementale (mais juste modeste) et que vous vous précipitez également quelque part?SourceAinsi, si la compagnie aérienne autorisait régulièrement une modification des vols, cela entraînerait des problèmes de toutes parts. Pour un passager, cela signifie qu'il devra consacrer plus de temps aux correspondances, les passagers seront plus susceptibles de prendre des risques et d'arriver jusqu'à la fin de l'enregistrement. Cela entraînera encore plus de conflits et une perte de temps. Pour la compagnie aérienne, cela signifie également que plus de temps est nécessaire pour les temps d'arrêt à l'aéroport, augmentant ainsi les coûts.Dans le processus de publication, si soudainement une tâche n'a pas le temps pour l'heure planifiée, il y a aussi une grande tentation de déplacer la version entière - par exemple, d'une semaine. Il semble que ce soit une solution facile et bonne, surtout si cette tâche est sous le contrôle du client principal.Voyons à quoi tout cela mène finalement.
Dans le cadre du projet de logement et de services communaux SIG, dans le cadre de la prochaine version, jusqu'à 100 tâches et plus de corrections de bugs sont publiées. Un changement de version signifie que les utilisateurs obtiendront les fonctionnalités dont ils ont besoin ou des corrections de bugs plus tard. Bien sûr, le problème en discussion est vraiment important, mais en même temps, bon nombre des 99 tâches restantes sont également très importantes, mais comme tout est normal avec elles, nous les avons déjà oubliées.
Ensuite. Si nous commençons à changer régulièrement de version, le client commence à perdre confiance dans le plan de sortie. Il a toujours dans sa tête la pensée que oui, bien sûr, la prochaine sortie est prévue pour le 10, mais très probablement quelque chose va se passer et il y aura un décalage d'une semaine, voire deux. Les raisons des changements peuvent être différentes, mais au final, elles sont toutes oubliées et il subsiste le sentiment d'un processus instable et opaque.
À quoi cela mène-t-il? De plus, si un défaut ou une tâche urgente survient, le client n'accepte pas de le publier dans le cadre d'une version particulière, mais nécessite une version spéciale ou un correctif. En conséquence, nous avons des coûts supplémentaires importants.Si nous autorisons un changement de version, cela réduit la possibilité d'optimiser le processus. Au contraire, si la procédure de libération est uniforme et régulière, nous avons la possibilité de l'améliorer. Après la sortie de la version, nous menons une «rétrospective», où nous discutons les principaux points positifs et négatifs qui se sont produits pendant l'itération. À chaque répétition, nous apportons une sorte d'amélioration, en conséquence, les frais généraux sont réduits, le nombre d'erreurs est réduit, le résultat est amélioré.
Pourquoi un gros avion n'est pas toujours mieux
La compagnie aérienne peut utiliser différents types d'avions sur la route: des avions régionaux pour 75-110 passagers (type SSJ-100 ), ou des avions à fuselage étroit pour 140-180 passagers (type A320 , Boeing 737 ), ou des avions gros-porteurs pour 200-300 passagers (type A330 , A340 ), ou des monstres comme l' A380 , capables de transporter de 525 à 853 passagers. De façon simpliste, nous pouvons supposer que la compagnie aérienne choisit le type d'avion et l'intensité de vol souhaités comme un compromis entre le désir du passager d'avoir autant de vols par jour que possible et le désir de la compagnie aérienne de réduire le coût du transport d'un passager afin de maximiser ses profits.Maintenant, au moins trois compagnies aériennes desservent ma ville natale d'Astrakhan, effectuant un vol par jour sur des avions régionaux ou à fuselage étroit. Même si l'infrastructure aéroportuaire d'Astrakhan permettrait la réception de l'A380 (l'avion le plus grand et le plus spacieux d'Airbus), pour le charger, il faudrait réduire drastiquement l'intensité du vol, ce qui serait totalement gênant pour les passagers. Si la différence de coût n'est pas importante, les passagers préféreront un plus grand nombre de vols par jour.Environ la même logique opère dans le processus de publication. Plus le temps entre les versions est court, mieux c'est pour le client.
, . , , . , , .
.
, . , , , , , . , , “” . , , . . , ( , , , , , , ).
1. ( ), “ , , ” , . , . , . , , — , .
- , . .
—
, . , . , , - , .- , — , , ( ).
, , , . , , . — , (- ) . , , . , , , “” . , , . , . , 1,5-2 , 1,5 , -.
, :
— — , — , — , .
:
— , , . .
, , . .
. , , .. , . , , . .
, . , , , . , !, — . , , , . , , . . , . , , , . , , . , , .
, , , . , 4 , 2-3. . , .
, , .
. ( — ), .. . , - , , . - , . — , . . , , , . , ( , , , , , , , ..), . , , 2018 2018 , , ASAP . 4-5 ! 5 , 2-3 , 1-1,5 .
, , — .!
. , ! ., - , . , , . , , , - , . , , .
, , , , , , . — , .
, - , - . - . , . , , . , , , .
, . . , , - , .
, . , - , , .
, . , :
.
. ? ? ?