Veeam Indoor Kitchen: como o processo de P&D funciona

A noite Outra entrevista de P&D está chegando ao fim e nossos entrevistadores estão sintonizados com perguntas inesperadas de um futuro colega. Mas não há surpresas: a proporção deduzida por Wilfredo Pareto também funciona aqui. Em 80% dos casos, ouvimos quatro perguntas - aproximadamente 20% do número total recebido. Como é organizado o seu processo? O que eu farei? Como se tornar um líder sênior / de equipe em um ano? E a relocação para a Europa?

Neste post, responderemos à primeira pergunta e falaremos sobre o processo de desenvolvimento na Veeam - de equipe para equipe, essa resposta muda menos.



Então o processo. Essa é uma sequência repetível de ações que levam ao sucesso todos os dias, ou pelo menos algumas vezes. Você aprendeu a cozinhar sopa de beterraba e toda vez que fica igualmente saboroso - um processo. O estacionamento não é uma batida - domina o processo. O processo permite que o cérebro não pense em uma rotina todas as vezes, transformando-a em trabalho mecânico. O cérebro é liberado para a criatividade.

O processo de desenvolvimento é uma sequência de ações que transformam os desejos dos usuários em produtos tangíveis. Esses desejos são formulados por analistas e gerentes de produto, implementados por desenvolvedores, avaliados criticamente por testadores, descritos por escritores técnicos.

Nós da Veeam estamos fabricando produtos massivos para replicação de backup e data center - para que nada se perca. Um produto in a box clássico sem um cliente específico. À primeira vista, a coisa é simples, mas há nuances, por isso temos feito a segunda década.

Atores

Cada versão é o resultado de vários grupos:

• Gerentes de produto ou analistas . Eles priorizam seu trabalho, comunicando-se com o mundo exterior - clientes e parceiros. A parceria pode incluir tecnologia. Por exemplo, um distribuidor pode dizer o que lhe falta para aumentar as vendas, e o fabricante de um hipervisor pode falar sobre planos para o futuro. Para essa equipe, “habilidades de fala”, é importante a capacidade de capturar e priorizar tendências em um fluxo tempestuoso de opiniões. E então defenda a posição escolhida, diga não, explique por que algo foi feito dessa maneira, e não de outra forma. Não importa em comunicados à imprensa, em conferências ou em particular. Essas pessoas educam o mundo das vendas.
  
• Suporte Técnico Linha de apoio aos nossos clientes. Os indicadores mais importantes de uma equipe são o tempo de resposta a um problema e seu tempo de resolução (SLA). Cerca de alguns milhares de chamadas são atendidas durante o mês. A equipe é composta por várias camadas, inclui grupos de interação com clientes e grupos de análises de chamadas, desenvolvimento de soluções alternativas, etc. Com base nas informações recebidas pelo suporte, é formulada uma lista de melhorias e urgência - seja para implementar em uma correção privada, a próxima atualização ou adiar para o lançamento principal.
  
• Desenvolvedores de P&D . Pessoas que materializam solicitações no código.
  
• Testadores ou controle de qualidade . Primeiros testadores, uma faixa de teste de tanque e um suporte de vibração ao mesmo tempo. Eles não apenas verificam o que já foi implementado, mas também se conectam ao trabalho na fase de concepção. Repetindo as tarefas dos administradores em uma infraestrutura próxima ao combate, é mais fácil entender o quão conveniente é a interface criada ou os algoritmos selecionados são produtivos. Quando o suporte técnico chega à conclusão de que há um defeito no produto, o controle de qualidade reproduz os cenários problemáticos e monitora as correções.
  
• Equipe de escritores técnicos. Eles criam documentação do usuário final, bem como documentos específicos, como "Como funciona" e "Guia de implantação". Eles obtêm material para o trabalho de desenvolvedores, testadores e analistas.
  

Algumas equipes preferem o espaço aberto, mas com mais freqüência - armários

As equipes são vinculadas por meio de um sistema de contabilidade de requisitos. Nós o implementamos com base no Microsoft Team Foundation System, como historicamente o usamos como um sistema de armazenamento da versão de origem. O sistema armazena requisitos (requisitos), defeitos (bugs) e chamadas para suporte (problemas), exigindo a participação de QA e desenvolvedores. Cada questão envolve centenas de participantes que trabalham em milhares de tarefas, requisitos e defeitos. O sistema ajuda a manter tudo isso e, mais importante, distribuir uniformemente a carga, priorizando os desenvolvedores.

Anéis de árvores: ciclos de desenvolvimento

O desenvolvimento do nosso produto é cíclico, cada ciclo termina com o lançamento da próxima versão - release. Aqui está o que se reflete nos lançamentos:

• Tendências de mercado duradouras . Por exemplo, virtualização e o surgimento de infraestruturas em nuvem. Mudar os paradigmas do trabalho de TI leva anos - nesse momento, os usuários estão passando de suspeitas e negações ("que diabos é isso") para reconhecimento em massa ("sim, todo mundo faz"). A virtualização de datacenters deu origem à Veeam, pois, sob condições de virtualização, os produtos antigos para fazer backup de máquinas eram ineficazes.
  
• Suporte para novas plataformas . Uma vez, a Veeam foi projetada apenas para data centers virtualizados, com base na plataforma VMWare. Com o crescente número e tamanho de clientes, é necessário oferecer suporte a novas plataformas. Além do VMWare, outros hipervisores (Hyper-V), servidores físicos, plataformas em nuvem (AWS, Azure) etc. apareceram.
  
• Mudanças táticas no mercado . As próximas versões de sistemas operacionais e hipervisores são lançadas. É obtida experiência com as versões anteriores do nosso produto. Por exemplo, é assim que obtemos suporte em nível de item - recuperação seletiva de servidores de aplicativos populares, como Microsoft Exchange, Microsoft SQL Server, bancos de dados Oracle, etc.
  
• Defeitos . Apesar de todos os nossos esforços, a vida é não-não e apresenta surpresas. Obviamente, tentamos minimizá-los.
  

A cada trimestre, recebemos atualizações (atualizações), aproximadamente uma vez por ano - principais (principais) lançamentos. Eles são bons porque minimizam a sobrecarga de criar funcionalidades volumétricas relacionadas ao suporte a novas plataformas e mudança de paradigmas. Com base nos detalhes do orçamento, os departamentos de TI dos clientes estão mais ativos no final do ano, então lançamos grandes lançamentos também no momento.

As atualizações trimestrais têm principalmente dois objetivos: suporte para novas versões de servidores protegidos e solução de problemas. Nas atualizações, coletamos todas as correções de defeitos descobertas pelos clientes desde o lançamento da versão principal. Além disso, com a ajuda de atualizações, respondemos rapidamente a alterações nas plataformas suportadas. Sob os termos do SLA, a Veeam deve adicionar suporte para a nova versão do hypervisor em não mais de três meses .
E se o produto não funcionar para um cliente específico? Nesse caso, emitimos uma correção particular - em outras palavras, uma muleta. Essas correções são lançadas toda semana e nem sempre estão associadas a defeitos no produto. Por exemplo, as configurações de segurança do cliente podem não ser compatíveis com o produto. Ao emitir uma correção particular, analisamos a frequência do problema e decidimos se a correção deve ser incluída na próxima atualização trimestral.

Do amanhecer ao anoitecer: crônica de lançamento

Cada ciclo de liberação começa com o planejamento - no nível do produto como um todo e no nível de um único requisito. No primeiro caso, a questão das prioridades de negócios e a distribuição dos requisitos entre as equipes são resolvidas. Primeiro de tudo, são discutidos os requisitos ou épicos mais urgentes. De uma maneira boa, não mais que 60% do volume total de trabalho na versão deve ser alocado para a epopeia, para que haja um tempo limite. O planejamento do produto é realizado no nível dos chefes de departamento - produtos, testadores, desenvolvedores.

Desenvolvedores e testadores são divididos em equipes. O número ideal de pessoas em uma equipe é cinco. As equipes são funcionais e universais. Neste último caso, a equipe é auto-suficiente, contém desenvolvedores com experiência em diversas áreas. Os comandos funcionais são mais restritos - eles funcionam na interface do usuário, nos componentes do sistema etc. Pessoas de diferentes equipes funcionais formam equipes virtuais que começam a implementar requisitos. Pelo menos representantes do grupo PM, as equipes de desenvolvimento e teste se reúnem aqui. O líder da equipe é designado como líder de uma das equipes funcionais.

O trabalho começa com o requisito. A equipe virtual se reúne semanalmente. Os participantes falam sobre sucessos na semana passada e planejam trabalhar para a próxima.
O líder da equipe responsável pela moderação modera as reuniões e registra os resultados. Ele também resolve problemas que não podem ser resolvidos em uma equipe virtual. Por exemplo, se você precisar mover datas ou adiar parte das tarefas.

Dentro das equipes de desenvolvimento ou teste funcional, os pontos de controle são mais espaçados. Como regra, um plano semanal é dividido em tarefas com duração não superior a dois a três dias. Algumas equipes criaram raízes na prática de scrum com voláteis diários; em algum lugar, a interação ponto a ponto entre o líder da equipe e a equipe está trabalhando com mais eficiência.


Sala de reunião típica para discutir o status atual do projeto

Todo o desenvolvimento é dividido em iterações semanais ou quinzenais. Durante as primeiras iterações, você precisa criar uma funcionalidade minimamente funcional que subseqüentemente se transformará em carne - por exemplo, uma interface de usuário avançada, API para clientes, etc. E o mais importante, a presença de um esqueleto já permite que os testadores obtenham um recurso.

O ciclo de lançamento inclui lançamentos alfa e beta. Com a ajuda deles, mostramos novos recursos para o mundo exterior e coletamos comentários com antecedência. Se necessário, as decisões sobre arquitetura ou funcionalidade são alteradas. Os cenários são trazidos para o estado alfa e beta não imediatamente, mas em lotes. Como regra, existem cerca de dois beta no ciclo de lançamento.

Após o estágio beta, as equipes entram no modo de teste de regressão. Nesta fase, o produto, como um todo, já está funcionando, a interface do usuário e os scripts já endureceram e mudaram com menos intensidade. Uma equipe de escritores técnicos entra em cena. Ao mesmo tempo, equipes de suporte técnico estão sendo treinadas.

O teste de regressão é realizado em ciclos de duas semanas. O tempo do ciclo é determinado pelo tempo necessário para visualizar todos os cenários do produto. Quanto maior o produto, mais cenários e, consequentemente, ciclos. Um bloco de código é declarado antes do último loop. Isso significa que apenas alterações críticas serão feitas no produto - e somente após várias revisões de código. Tais métodos draconianos são necessários para não introduzir acidentalmente novos defeitos no produto.

Quanto mais próximo o momento do lançamento, mais tempo livre os desenvolvedores têm e menos todos os outros. Os gerentes de produto precisam preparar comunicados de imprensa, coordenar o trabalho dos serviços de marketing. Os testadores devem verificar correções e executar o teste de regressão final. Os escritores técnicos estão adicionando documentação do usuário. Neste momento favorável, os desenvolvedores estão desenvolvendo atividades de pesquisa para os requisitos da próxima versão.

E aqui é um momento emocionante, chamado RTM - Ready To Market. Isso significa que o produto já está pronto para distribuição aos consumidores. Dentro de duas semanas, ele será atormentado por jornalistas, prestadores de serviços. Será mostrado nas apresentações. Duas semanas depois, o produto estará disponível para todos. Nesse momento, também ocorrem mudanças internas: novos ramos do desenvolvimento estão sendo preparados, o código está sendo depositado. E, é claro, a infraestrutura de construção para a próxima versão aumenta. Após o lançamento público (GA), é um momento quente para suporte técnico. E o resto já está trabalhando na próxima versão.

Sobre prioridades

E, finalmente, um pouco de hardware. Como você sabe, na trindade de "rápido, de alta qualidade e barato", você pode escolher no máximo duas opções. Qualidade, tempo e funcionalidade estão constantemente brigando entre si. Em nosso produto in a box, a qualidade vem em primeiro lugar. Hmm, mas qual é a área em que a qualidade não importa? Claro que não. A questão toda é a definição de qualidade.
Para nós, a qualidade é:

• Preservação da confiabilidade e desempenho nas configurações do zoológico . Um cliente possui um modesto data center de dois servidores desde a Batalha de Borodino, enquanto o outro possui uma infraestrutura de ponta em um hangar próximo à Amazon. O produto deve funcionar adequadamente nos dois casos.
  
• Facilidade de uso . O usuário deve no mínimo esforçar-se e certamente lidar sem nenhuma instrução. Porém, simplicidade semelhante está longe de estar sempre escondida atrás da simplicidade externa - tente cruzar perfeitamente com um ouriço.
  
• Herança Os investimentos nas empresas são de longo prazo e os CFOs não serão gastos em TI sem uma boa razão. Portanto, você precisa manter a compatibilidade com as versões anteriores e produtos relacionados. Muitas vezes, durante a reconstrução dos datacenters, os servidores de e-mail dos anos 80 são cercados. E todos zumbem e não pensam em morrer.
  

Com esse conjunto de prioridades para preservar a qualidade, você sempre precisa combinar algo, tanto para desenvolvedores quanto para testadores. Pequenas mudanças no comportamento das funções podem levar a testes de integração forçados da maior parte do produto. Tente adicionar o suporte ao código de idioma asiático ao produto e entenda do que se trata. Portanto, a questão das prioridades é uma questão de discussão conjunta de PMs, testadores e desenvolvedores.

A segunda prioridade, quase indestrutível, é o timing. No caso de atualizações, as datas de lançamento são definidas pelo SLA, no caso de grandes lançamentos - pelo calendário comercial. Segundo as estatísticas, em cada ciclo de lançamento, quase 50% do tempo é gasto em desenvolvimento, 50% em trazer o produto à mente (estágio de correção de bugs).

O que pode mudar é a funcionalidade do próximo lançamento. Uma lista priorizada de requisitos, ou lista de pendências, ajuda aqui. Teoricamente, tudo é simples: escolha a próxima função prioritária na lista de pendências, observe o tempo restante. Quando o tempo estiver próximo do fim, pare e libere a próxima versão do produto. O diabo está escondido nas nuances:

• Incerteza dos requisitos . Por exemplo, o requisito "para suportar o backup de máquinas físicas no OS Linux" pode ser refinado ainda mais. Quais núcleos devem ser suportados? Quais distribuições? Quais sistemas de arquivos? Um e o mesmo requisito de alto nível pode ser implementado em um mês ou um ano. A pergunta está completa.
  
• As equipes têm especializações . Nem todos os requisitos podem ser atendidos por qualquer equipe. O desenvolvedor de C # não grava drivers; o desenvolvedor de componentes do sistema nem sempre lida com o desenvolvimento da Web.
  
• Os requisitos dependem um do outro . Isso nem sempre é visível no nível dos cenários do usuário, mas existem esses relacionamentos internos. Do ponto de vista do mundo externo, o suporte de backup dos sistemas de arquivos NTFS e ExtFS pode ser um requisito com prioridades diferentes, mas por dentro você precisará primeiro criar um mecanismo comum.
  
• Os requisitos são divididos em diferido e não diferido . Se o mercado estiver aguardando na próxima versão por alguma função, e foi anunciado, não funcionará para adiá-lo.
  
• Parte dos requisitos envolve pesquisa . Sem os resultados da pesquisa, é impossível planejar a complexidade da tarefa (talvez seja impossível), e pode ser difícil prever esses resultados.
  

É aqui que o desenvolvimento ágil entra em cena. Para nós, desenvolvimento ágil significa a necessidade de renovação periódica. Novas circunstâncias se tornaram conhecidas - planos alterados. Adicionados novos requisitos de prioridade ao backlog - planos alterados. Não temos tempo com requisitos não atrasados ​​- cortamos parte das tarefas ou alteramos o requisito. Na teoria do controle técnico, isso é chamado de sistema de feedback. Lembre-se de como o piloto automático funciona.

Qualquer planejamento nas condições acima depende de julgamento de especialistas. Uma avaliação especializada do líder da equipe é o elemento que torna todo o processo subsequente claro e estruturado. Outro nome para a avaliação de especialistas é "o método leninista de estrabismo", como Alexander Orlov, da Stratoplan, gosta de repetir. É quando você toma uma decisão com base na experiência e intuição anteriores. Apesar das possíveis críticas, isso funciona. Funciona como todos os nossos processos descritos acima. Se você ainda tiver dúvidas sobre eles, convidamos você a comentar.

O que vem a seguir?

A atual tecnologia de processo é confortável e aconchegante como chinelos em casa. O único problema é que, na Veeam, algum furador invisível sempre o leva: mais rápido, mais, mais, mais.
Mais recentemente, escritórios-piloto foram construídos na Finlândia e na República Tcheca, e este ano estamos nos preparando para a inauguração do centro de P&D de Praga para várias centenas de pessoas.


O lobby do nosso escritório em Praga

Um escritório de desenvolvimento apareceu recentemente em Israel; as equipes no Canadá e na Alemanha estão crescendo. O número de projetos de desenvolvimento conjunto com HP, NetApp, Nutanix, EMC está aumentando.
A manufatura se transforma em um transportador geograficamente distribuído e, ao mesmo tempo, novos processos se cristalizam. No entanto, este é um tópico para um artigo separado.
Fique conectado.