It seems like an open-and-shut case.
o código congela são uma relíquia. Um remanescente dos dias em que metodologias rígidas de cascata ofereciam a única opção para o desenvolvimento e lançamento de produtos. Todo o conceito de parar a produção e adiar o lançamento—apenas para testar bugs e outras questões funcionais—não tem lugar na gestão moderna e ágil do produto.
pelo menos essa parece ser a visão consensual entre muitos gurus ágeis.
mas será que aguenta? Uma vez que você arranha a superfície dos argumentos mais comuns contra a incorporação de código congela em Gestão Ágil de produtos, eles ainda parecerão arcaicos?
nesta peça, vamos explorar os três principais argumentos contra a incorporação de código congela em sua gestão ágil do produto, e vamos quebrar onde esses argumentos se desmoronam, tudo para ajudá-lo a tomar uma melhor decisão sobre se você deve ou não incorporar código congela em sua gestão ágil do produto.
- argumento 1: Os bloqueios de código são irrelevantes e desnecessários
- argumento 2: o código congela quebrar um princípio de Ágil principal
- argumento 3: o código congela leva a lançamentos mais lentos e de menor qualidade
- Making the Case for Code Freezes: A Losing Battle?
- the Problem With Argument 1: Automatic Testing Is Not Comprehensive
- o problema com o argumento 2: “Reduzir”, não “eliminar”
- O Problema Com O Argumento 3: Repensar a velocidade e a qualidade
- deve utilizar o código congela na sua gestão ágil do produto?
argumento 1: Os bloqueios de código são irrelevantes e desnecessários
este argumento é muito simples e concreto-as modernas metodologias ágeis e ferramentas eliminaram a necessidade de uma janela de teste e de QA dedicada.
metodologias ágeis tais como revisões de códigos de pares, programação de pares, e o monitoramento constante da saúde do sistema lhe dão uma visibilidade muito maior em uma aplicação ou desempenho do recurso enquanto ele está sendo desenvolvido. Bugs and issues are easier, and more likely, to be caught during development itself, and resolved prior to any dedicated testing and QA activities.
novas ferramentas também automatizaram muitos testes. Eles constantemente avaliam o código para se certificar de que está limpo e pronto para a produção em todos os momentos. As questões são identificadas em tempo real, e os alertas são imediatamente enviados para resolvê-las O MAIS RÁPIDO POSSÍVEL. O número de testes que foram automatizados já é amplo e continua a crescer, reduzindo drasticamente o volume de testes manuais que precisam ser realizados.
o resultado destas novas metodologias e ferramentas ágeis é fácil de ver. A maioria das atividades de teste de core e de QA realizadas durante um congelamento de código estão sendo realizadas durante o desenvolvimento, ou realizadas por software. Em ágil, software e recursos agora sair do desenvolvimento em um nível de confiança muito maior do que eles costumavam, tornando um código dedicado congelar mais difícil e mais difícil de justificar.
argumento 2: o código congela quebrar um princípio de Ágil principal
este segundo argumento é um pouco mais alto. Basicamente, ele argumenta que o code freezes não tem uma casa em metodologia ágil porque eles quebram um dos princípios fundamentais da Metodologia Ágil— reduzindo o tempo entre o desenvolvimento e lançamento.
quanto mais afinada for a sua abordagem à ágil, mais irá tentar encolher esta janela de tempo. As abordagens atuais mais refinadas de agilidade são a integração contínua e o desenvolvimento contínuo (CICD), e visam quebrar o desenvolvimento em pequenas mudanças incrementais, a fim de “liberar” alterações ao código o mais rapidamente possível. Na aplicação mais pura do CICD, o desenvolvimento e a liberação quase não existem como fases distintas-o novo código é integrado na aplicação quase logo que está concluído.
em contraste, você precisa manter fases distintas de desenvolvimento e liberação se você vai implantar o código congela. Afinal de contas, é onde o código congela vive entre essas duas fases distintas. Em vez de tentar minimizar ou eliminar essa janela de tempo entre o desenvolvimento e lançamento como a maioria da metodologia ágil, o código congela forçá-lo a formalizar esta janela ao ponto de que você precisa para construir o seu desenvolvimento e liberar horários em torno dele.
se o código congela não se alinhar com os princípios de ágil, então é difícil fazer o caso que ainda pertencem à metodologia.
argumento 3: o código congela leva a lançamentos mais lentos e de menor qualidade
este argumento final é grande, e inclui alguns ângulos diferentes.
para começar, argumenta que o código congela adiciona muita complexidade e partes móveis adicionais ao seu roteiro, e naturalmente aumenta as chances de que algo vai correr mal e desvia sua linha do tempo. Mesmo que nada corra mal, o trabalho envolvido no code congela é demorado e imprevisível (como você não sabe quais bugs você vai encontrar ou quanto tempo vai demorar para corrigi-los), que simplesmente adicionando código congela ao seu roteiro você vai criar ciclos de desenvolvimento mais lento e liberação.
em seguida, argumenta que o código congela irá reduzir a produtividade da sua equipe de desenvolvimento. Enquanto ágil em geral, e CICD especificamente, manter seus desenvolvedores constantemente trabalhando em uma cadeia ininterrupta de produtividade, o código congela forçar seus desenvolvedores a parar o trabalho em intervalos pré-definidos. Ao fazer isso, você vai quebrar o ritmo deles e forçá-los a tentar trabalhar em torno de suas políticas de congelamento de código, em vez de encontrar e manter qualquer fluxo que os torna mais produtivos.
Finalmente, argumenta-se que a criação dedicado windows onde você interromper o recebimento de requisitos de negócios, irá limitar as características e funcionalidades de seus lançamentos para o que pode ser concluído antes do congelamento, o que levará a uma menor qualidade, menos abrangentes de software e aplicativos.
Making the Case for Code Freezes: A Losing Battle?
neste ponto, está parecendo muito sombrio para qualquer um que ainda quer incluir o código congela em Metodologia Ágil. Detratores desta prática fazer algumas argumentos convincentes e, globalmente, um caso sólido que, uma vez que o desenvolvimento da moderna metodologia Ágil, código congela tornaram-se:
- Obsoleto e irrelevante
- Desalinhados com as modernas práticas de desenvolvimento
- Uma barreira para a rápida, de alta qualidade lançamentos
Mas enquanto estes argumentos são convincentes, e contêm uma grande quantidade de informações precisas, elas não são à prova de balas. E há falhas fundamentais dentro de cada uma que precisam ser discutidas antes de fechar o livro de código congela como um elemento útil de Gestão Ágil do produto.
the Problem With Argument 1: Automatic Testing Is Not Comprehensive
automatic QA and Agile development practices have increased the quality of code as it’s produced, that’s a fact. Mas só porque um pedaço de código passou nos testes unitários, isso não significa que esteja realmente pronto para a produção. Mesmo as abordagens mais refinadas de CICD nem sempre incluem passos críticos—como testes de regressão-que garantem que um pedaço de código é livre de defeitos. Quando se trata disso, há apenas algumas coisas que você não pode testar e resolver enquanto um pedaço de código está em produção.
se você optar por utilizar o Code freezes, você não vai desistir dos benefícios de QA automatizada e melhores práticas ágeis. Você e sua equipe simplesmente pegarão os problemas menores e triviais do seu código durante a produção, limpando os decks para se concentrar em pegar problemas maiores e de maior impacto durante o seu congelamento, tais como a estabilidade geral e confiabilidade de seu novo software ou recurso.
o problema com o argumento 2: “Reduzir”, não “eliminar”
ágil é projetado para reduzir o tempo entre o desenvolvimento e a liberação, isso também é um fato. Mas há uma grande diferença entre tentar reduzir esta janela e tentar eliminá-la completamente. Fazê-lo seria quase impossível, especialmente para projectos maiores.
o congelamento do código pode ser muito curto em CICD—ou pode apenas aplicar-se a um ramo específico enquanto o desenvolvimento continua em outros ramos-mas ainda existe. Não importa quão ágil refinado tornou-se, há quase sempre vai haver um ponto em todos os roteiros de desenvolvimento e lançamento, onde um novo pedaço de software ou recurso será avaliado em um estado fixo antes de sair para os usuários do mundo real.
O Problema Com O Argumento 3: Repensar a velocidade e a qualidade
se utilizar o código congela, irá adicionar um novo passo ao seu ciclo de desenvolvimento e lançamento. Não há dúvida quanto a isso. E sempre que você adiciona um novo passo a qualquer processo, você desacelera esse processo e cria um novo ponto de falha potencial. O código congela não é excepção.
mas é importante dar um passo atrás, e ter uma visão mais ampla de desaceleração e perda de produtividade.
se o seu recurso tiver erros, terá de corrigi-los, independentemente de ter apanhado esses erros durante um congelamento de código, ou se eles se deram a conhecer após o lançamento. A partir de uma perspectiva de desenvolvimento puro, a quantidade de tempo necessário para corrigi-los será aproximadamente o mesmo em ambos os cenários.
Mas se você está lidando com bugs em um ambiente ao vivo, você tem uma série de outros problemas que você precisa para tomar o tempo para lidar com, incluindo:
- Decidir se reverter o buggy recurso ou deixá-lo viver.
- retirar os seus programadores dos seus novos projectos, depois de começarem a trabalhar.
- compensando seus usuários do mundo real que foram impactados pelos bugs.
- responder e gerir os seus stakeholders internos que não estão muito satisfeitos com a sua libertação problemática.
a lista continua. Não há nada mais complicado, demorado e destrutivo para a produtividade-para você e sua equipe—do que liberar um recurso quebrado ou produto. O código congela para minimizar as hipóteses de isto acontecer.
e quanto ao argumento de que o código congela levam a características e produtos de menor qualidade porque reduzem a quantidade de requisitos de negócio que você pode coletar? As suas necessidades de Negócio serão sempre pouco mais do que um” melhor palpite ” sobre como o seu produto ou recurso deve funcionar. Os requisitos mais valiosos virão sempre de usuários do mundo real, implantando seu produto ou recurso em cenários do mundo real. E você só pode coletar esses requisitos dando aos seus usuários liberações funcionais que eles podem implantar o mais fluidamente possível, e livre de bugs.
deve utilizar o código congela na sua gestão ágil do produto?
em última análise, o Code freezes ainda desempenham um papel importante para muitos gerentes de produtos ágeis.
agora, há casos em que eles desempenham um papel menos crítico. Projetos muito pequenos podem não precisar de períodos de congelamento de código dedicados. Novos recursos que têm consequências relativamente menores se eles enviar imperfeitamente pode não valer a pena o congelamento. O mesmo é verdade para os planos de lançamento por fases—como Canary Releases—quando você só quer testar novos recursos com um público quente que você se preparou para esperar uma experiência buggy, imperfeita.
mas na maioria dos casos, vale a pena tomar o tempo—mesmo um período de tempo muito curto—para ter certeza que suas novas características são tão perfeitas quanto você pensa que são Antes de colocá-las nas mãos das pessoas que mais importam: seus usuários do mundo real.
este artigo foi inicialmente publicado em flagship.io
