Por que chegar atrasado a um voo e não voar nem sempre é uma coisa ruim? Quem é o culpado por chegar atrasado ao cais? Por que vir ao aeroporto com antecedência? O A380 pode voar para Astrakhan? Por que a intuição nem sempre funciona? Surpresas acontecem - nunca aconteceu e aqui de novo? Por que os passageiros batem no piloto após o pouso?Suponha que você esteja desenvolvendo um sistema de informações em nível estadual (SIG) em escala nacional. A equipe do projeto (analistas, desenvolvedores, testadores, serviços de suporte, serviços de infraestrutura etc.) é composta por mais de cem pessoas. O sistema foi implementado em operação piloto ou industrial. Milhares de organizações se integraram ao seu sistema e começaram a trabalhar com ele; ainda mais, estão planejando a integração. Dezenas de milhares de organizações trabalham através de uma interface da Web. O sistema contém informações úteis para os cidadãos e fornece funções interessantes. O cliente e / ou usuários exigem novas melhorias. Milhões de pessoas em todo o país estão registradas e usam o sistema. Presentes do mundo exterior vêm na forma de mudanças nos preços do petróleo, sanções, restrições, etc.
Apresentado? Portanto, exatamente esse projeto no momento é o projeto GIS de habitação e serviços comunitários, sobre o qual começamos a
falar mais cedo e agora queremos continuar.
FonteAs primeiras experiências dos irmãos Wright
Provavelmente, se você trabalha em uma pequena empresa e desenvolve "pequenos projetos", não possui muitos processos de liberação como tal. O esquema de trabalho se parece com isso. Você apenas finge que seria bom lançar alguns recursos em 4-5 meses. Em seguida, você escreve produções para outro mês, desenvolve, desenvolve e tenta estabilizar toda essa economia para lançar uma nova versão do software em operação. É claro que, no momento do lançamento, verifica-se que algumas melhorias não podem ser estabilizadas de forma alguma, são reveladas falhas em algumas produções, uma vez que as produções são feitas há muito tempo e agora algo mudou, em algum lugar, elas foram assinadas sob funcionalidade irrealista etc. No entanto, essa abordagem funciona muito bem para si mesma, mas, como regra, desde que a equipe do projeto seja pequena e a intensidade das alterações seja pequena (o sistema não foi colocado em operação ou foi pilotado por alguns usuários, etc.). Em princípio, sem processos, você pode escalar para projetos razoavelmente grandes - até 20 pessoas e até 40 pessoas - tudo depende da frieza dos indivíduos e de sua dedicação. Certamente, muitas pessoas estão familiarizadas com a situação em que a equipe do projeto, formada por especialistas legais e desesperados, nos casos em que os prazos terminam e quase tudo desaparece amigavelmente sobrecarregado e ... "nos ombros", "nas caixas de pizza moral e de força de vontade" pelas montanhas eventualmente colocou a versão em operação.
Acredite, nós também passamos por isso (é por isso que agora adoramos todo tipo de loucura, como
Racing Heroes ,
maratonas , etc.). Mas, em algum momento, percebemos que tudo tem um limite e que, ao implementar sistemas de habitação e serviços comunitários em escala GIS, sem um processo claro de liberação, temos a garantia de obter três momentos desagradáveis principais:
- o cliente está descontente com você, porque você não pode prever as datas do lançamento da funcionalidade em operação e constantemente quebra os prazos; se surgir uma tarefa imprevista, isso leva a grandes problemas;
- a qualidade de vida dos funcionários está se deteriorando devido ao constante caos, confrontos, horas extras, etc;
- os líderes da sua empresa estão insatisfeitos com você, porque os custos serão completamente incontroláveis.
A experiência da LANIT no desenvolvimento de serviços habitacionais e comunitários de SIG nos diz que um dos momentos mais importantes para mudar para "trilhos industriais" na implementação de grandes projetos é a construção de qualidade do processo de liberação. Isso, é claro, não é suficiente para a felicidade completa, mas o processo de lançamento está subjacente a tudo, e sem ela você é garantido que será muito pior do que poderia ser.
Neste artigo, descreveremos duas práticas principais que sustentam o processo efetivo de liberação em sistemas de TI da escala de serviços de alojamento e comunidade GIS:
- uso de um esquema de entrega regular de funcionalidade,
- ciclo de liberação reduzido.
Por um lado, essas práticas são bastante conhecidas e são usadas em muitas metodologias, além de registradas no
Agile Manifesto . No entanto, eles são amplamente contrários à intuição, exigem certas qualificações e habilidades e, portanto, são difíceis de justificar e atendem a uma falta de entendimento tanto no Cliente quanto na equipe do projeto. Sua implementação nos padrões corporativos exigirá uma compreensão muito boa do “o que queremos alcançar” e “por que exatamente a implementação dessas práticas levará ao resultado desejado”. A seguir, consideraremos com exemplos essas práticas e os principais problemas em sua implementação.
Quando analisamos nossos processos internos relacionados ao gerenciamento de liberações, uma associação com o trabalho de uma companhia aérea moderna apareceu na minha cabeça.
Tráfego aéreo regular
A companhia aérea fez uma análise de mercado, previu quais rotas teriam um grande fluxo de passageiros e se tornariam lucrativas para a próxima temporada, negociadas com quem era necessário, obtendo direitos sobre as rotas necessárias, lançando vôos regulares. O horário do voo é conhecido há muito tempo, por regra, de seis meses a um ano. Quem voa exatamente, a companhia aérea, é claro, é desconhecida - ela se concentra na ocupação média projetada. Além disso, a companhia aérea pode concluir acordos de longo prazo com os aeroportos, pensar em quais aeronaves é mais vantajoso embarcar em voos, estabelecer seus próprios procedimentos internos, etc. Isso tudo contribui para a otimização de custos.FonteSe um funcionário da empresa precisar participar de uma reunião importante em um determinado horário e depois voar para outra cidade de avião, ele simplesmente seleciona os voos para si, levando em consideração os riscos de atrasar a reunião e a situação do tráfego.
Os vôos regulares têm suas desvantagens. Se um funcionário comprou uma passagem para um voo, mas não teve tempo, o avião não esperou. Desagradável? Sim Pode ser que o funcionário precise ir embora hoje, e só há voos amanhã ou daqui a uma semana. Não é tão bom? Sim Mas a grande vantagem é que você pode planejar sua viagem por seis meses ou um ano e ter certeza de que o voo ocorrerá. Você sabe exatamente quando chegar e poderá contar esse horário aos seus entes queridos que podem conhecê-lo, ou pode voar com uma transferência e não se preocupe, pois não terá tempo para atracar. Bem, em geral, pense bem: um avião enorme e pesado de ferro, que para 90% da humanidade não entende como voa, o levará muito rapidamente, o diabo sabe onde e vai custar quase um dia ou dois em um trem.Vamos voltar ao projeto. Os utilitários GIS usam um fornecimento regular de funcionalidade. A equipe
LANIT faz um cronograma de lançamento para 1 ano, onde fixa as datas de lançamento para que os lançamentos sejam cerca de 1 vez por mês. Como durante o ano tudo ainda pode mudar centenas de vezes (mais sobre isso abaixo), na hora de compilar o cronograma, ainda não sabemos exatamente quais melhorias serão implementadas e colocadas em operação.
Ao planejar, o cronograma de manutenção de rotina necessária para o serviço de infraestrutura / operação é levado em consideração. É necessário que mudanças globais e heterogêneas não se sobreponham - dessa forma, os riscos são reduzidos e é mais fácil manter tudo sob controle. Por exemplo, instalar uma nova versão do software e atualizar simultaneamente a versão do DBMS ou atualizar o firmware dos controladores de armazenamento é uma péssima idéia.
O ponto crucial é que as datas de lançamento não mudam posteriormente. Se a versão estiver planejada para alguma data, devemos dividir o bolo, mas aguentar o tempo planejado.A seguir, explicaremos o porquê e o porquê.
O fato de as condições de cada release serem aproximadamente as mesmas (duração, equipe, tarefas específicas etc.) permite planejar e depurar todos os procedimentos de preparação e lançamento.
As pessoas que não estão imersas nos processos de produção podem não entender a complexidade de liberar uma versão em um projeto tão grande como um alojamento GIS e serviços comunitários. Para que a versão seja lançada, é necessário executar várias operações, como teste de regressão (talvez várias vezes), teste de carga, teste de scripts de implantação e migração, analisar estatísticas de desempenho (consultas SQL, serviços etc.) . A situação é agravada pelo fato de que essas operações podem ser longas, por exemplo, a implantação de uma versão em uma bancada de testes pode demorar um dia. Se algo der errado, você pode sair facilmente da programação. Portanto, se você não tiver um cronograma com ciclos regulares e aproximadamente da mesma duração, garanto que cada problema será para você 146% um teste muito mais sério.
O cronograma também é necessário para determinar os prazos para a correção de defeitos e comunicá-los aos usuários. Como regra, corrigimos a maioria dos defeitos existentes na versão atual. No entanto, alguns defeitos podem exigir mais tempo ou podem ocorrer no final do ciclo de liberação, portanto, são transferidos para a próxima versão. Se, por algum motivo (veja abaixo), começarmos a mudar de versão, os usuários receberão correções automaticamente mais tarde, o que não é bom.
Também é necessário um cronograma de lançamento de versões para planejar o lançamento para operação de melhorias com prazo claro. A equipe de produção entende exatamente quando a revisão deve ser colocada em operação e seleciona a versão desejada, dentro da qual ela é lançada. Se a data de lançamento for adiada, isso poderá levar ao fato de que a revisão será lançada com atraso (sobre as consequências da mudança de versão devido a uma tarefa importante, veja abaixo)
Assim como as ligações regulares de transporte, esta é a base do sistema de transporte global, o processo de liberação baseado na entrega regular de funcionalidade é a base para o desenvolvimento efetivo de um sistema de serviços comunitários e de habitação em escala GIS. Se esse processo for estabelecido, já é possível "encadear" planos para a implementação e entrega da funcionalidade.
Infelizmente, a maneira de introduzir tal prática aparentemente útil por todos os lados é difícil e espinhosa. A seguir estão as principais armadilhas nas quais uma equipe pode cair e que devem ser monitoradas e suprimidas.
Embarcar em um avião após o registro
As companhias aéreas têm um procedimento de check-in simplificado para voos, que inclui, em particular, uma regra de que um passageiro deve fazer check-in para um voo o mais tardar 40 minutos antes da partida. Por que você precisa desses 40 minutos? Eles são necessários para que haja tempo suficiente para despachar a bagagem e carregá-la no avião, para que, com base no peso da bagagem e no número de passageiros registrados, seja possível calcular o combustível necessário, reabastecer o avião etc. Além disso, esse tempo é necessário para que os passageiros tenham tempo suficiente para encontrar a saída / terminal desejado. É claro que algo pode dar errado com a carga ou o passageiro (o passageiro se perdeu no aeroporto ou algo aconteceu com a bagagem) e mesmo esses 40 minutos não serão suficientes. No entanto, o tempo do final do registro é um compromisso estabelecido ao longo de muitos anos entre desperdiçar tempo do passageiro e o risco de situações de emergência.
Se um passageiro gosta de chegar ao aeroporto próximo ao final do check-in, isso significa simplesmente que ele concorda com o aumento do risco de que algo aconteça e ele não chegará a tempo para o avião. Se a companhia aérea conhecer essas pessoas, isso levará ao fato de que aumentará seus riscos. Talvez ela tenha que pagar por um voo especial de ônibus para o avião apenas para esse passageiro. Talvez, com pressa durante o check-in no último momento, a equipe do aeroporto cometa um erro e a bagagem voe para a cidade errada.FonteAo liberar lançamentos, um dos pontos mais importantes é o critério que a revisão deve atender e o prazo em que deve ser feito (semelhante ao final do check-in). O lançamento da versão todos os meses significa que, se alguma tarefa não estiver pronta para esse prazo na versão atual do software, ela será transferida para a próxima versão em um mês. Geralmente, você pode aguentar isso, mas é especialmente difícil fazer isso quando a tarefa é muito importante, mas ao mesmo tempo, demora apenas alguns dias ou uma semana. Há uma grande tentação de quebrar o prazo e incluir a tarefa ainda não pronta no lançamento e tentar reduzi-lo.
Por que isso é ruim?
Em primeiro lugar,
devemos admitir e aceitar corajosamente o fato de que todas as "pressões", "e se as capturarmos", provavelmente são um furo no gerenciamento da produção. Isso significa que várias medidas não foram tomadas com antecedência e a situação foi levada a um ponto crítico. Agora a situação será corrigida devido aos “heróis” de indivíduos ou equipes - horas extras, muletas, sorte, etc. Por experiência, isso pode levar a uma solução para o problema no curto prazo, mas se você fizer isso o tempo todo, isso levará as pessoas a "se esgotarem" e outras consequências muito desagradáveis.
Em segundo lugar, como no exemplo da companhia aérea, o prazo para a preparação das tarefas é um compromisso entre prazos e riscos. Se começarmos a violar o prazo, aumentamos os riscos de problemas com a versão - a versão inteira não será lançada no prazo ou a qualidade será reduzida e receberemos um grande número de chamadas devido a funcionalidades inoperantes ou problemas trabalhando sob carga.
Infelizmente, surgem situações em que há uma tarefa muito, muito importante e é necessária para liberá-la na versão atual. Mas a idéia principal é que tais situações não devem ser geralmente aceitas e encorajadas, mas sim reconhecidas como um problema e consideradas em “retrospectivas”.Atraso no vôo devido ao passageiro VIP
Digamos que você comprou um voo com uma transferência. Suponha que você tenha planejado um tempo adequado entre as junções. Você chegou com antecedência ao aeroporto, fez o check-in, embarcou no avião, telefonou para meu pai e minha mãe e eles anunciaram que o voo estava atrasado, porque uma delegação importante do governo está atrasada (é claro, em vez disso, eles falarão sobre mau tempo ou verificações adicionais :)). Você, juntamente com todo o avião, aguarda esta delegação e, como resultado, voa com um atraso significativo. Chegando a um ponto intermediário, você encontra apenas 30 minutos para navegar em um aeroporto enorme e chegar fisicamente a outro terminal. Talvez você, é claro, chegue a tempo, ou talvez confunda algo com pressa e corra para o terminal errado ou simplesmente não tenha tempo para passar por todos os procedimentos necessários. E se você também é membro de alguma outra organização governamental (mas apenas modesta) e também corre para algum lugar?FonteAssim, se a companhia aérea regularmente permitisse uma mudança nos voos, isso levaria a problemas de todos os lados. Para um passageiro, isso significa que ele precisará dedicar mais tempo para as conexões, é mais provável que os passageiros corram riscos e cheguem até o final do registro. Isso levará a ainda mais conflitos e perda de tempo. Para a companhia aérea, isso também significa que é necessário mais tempo para o tempo de inatividade no aeroporto, aumentando assim os custos.No processo de lançamento, se de repente alguma tarefa não tiver tempo para o horário agendado, também haverá uma grande tentação de mover o lançamento inteiro - por exemplo, por uma semana. Parece que esta é uma solução fácil e boa, especialmente se esta tarefa estiver sob o controle do cliente principal.Vamos dar uma olhada no que tudo isso leva.
No projeto de habitação e serviços comunitários do GIS, como parte da próxima versão, são emitidas até 100 tarefas e mais correções. Uma mudança de versão significa que os usuários obterão a funcionalidade necessária ou as correções de erros posteriormente. Obviamente, o problema em discussão é realmente importante, mas, ao mesmo tempo, muitas das 99 tarefas restantes também são muito importantes, mas como tudo é normal com elas, já as esquecemos.
Próximo. Se começarmos a mudar regularmente a versão, o cliente começará a perder a fé no plano de lançamento. , , , 10- , - , . , .
? , , , . ., . , , . “”, , . - , , , .
— 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 .
, , — .!
. , ! ., - , . , , . , , , - , . , , .
, , , , , , . — , .
, - , - . - . , . , , . , , , .
, . . , , - , .
, . , - , , .
, . , :
.
. ? ? ?