Conheça o livro Accelerate: um resumo

Desenvolver softwares é uma das tarefas mais divertidas. Você coloca os fones de ouvido, em poucos minutos entra no “flow”, e quando dá por si, o código já esvaiu pelos dedos. Porém tão importante (e divertido) quanto desenvolver, é manter o software funcionando. Para isso, é preciso saber se o processo de desenvolvimento em si está saudável, quais são os principais requisitos a serem atendidos (sejam funcionais ou não-funcionais). Um trabalho de gestão, que só é possível através de números. Afinal: Apenas o que pode ser mensurado, pode ser gerido.

Desde sempre queremos quantificar o nosso trabalho, atribuir uma medida de valor – até para que ele seja vendido – e aferir a qualidade dele. E sim, na área de software possuímos muitas, muitas, muuuuitas métricas e formas (as vezes até contraditórias) de medir esses resultados. Uma organização que queira lidar com todos esses números, pode acabar se afogando em estatística e perder resultados. De igual forma, uma organização que os ignora completamente, além de amadora, não sabe o que está fazendo.

O livro Accelerate

Como resposta a esse mesmo cenário, a Dra Nicole Forsgren, ao lado de Jez Humble e Gene Kim, publicaram uma extensa pesquisa, que está apresentada no livro Accelerate: The Science of Lean Software and DevOps – Building and scaling high performing technology organizations. Se o título do livro já dá um parágrafo, imagine o conteúdo? E por isso eu vou me atrever a resumir:

Quando nos deparamos com esse título, se você pensou que iria ler sobre XP, Agile e afins, você está certo e errado ao mesmo tempo. O livro não aborda esses temas diretamente, mas fala sobre quais práticas e métricas podem reduzir o tempo de entrega (Time to Marketing), mantendo a aplicação estável (Mean Time To Recover/Mean Time Between Failures) e um processo de deploy automatizado e sem traumas (Deploy Frequency / Change Failure Rate). E inevitavelmente XP e Agile fazem parte dessas práticas.

Mas qual a receita do sucesso?

Para os pesquisadores, possuir uma política madura de CI e CD é a base do sucesso. Dela decorrem as demais práticas e por conta dela, olhamos para determinadas métricas. Por exemplo: de acordo com o livro, a pessoa desenvolvedora deveria ser capaz de fazer múltiplos deploys por dia.

Apenas esta mudança implicaria em seguir uma estrutura de versionamento de código trunk based: aquela em que você abre as features branches à partir da Branch main e devolve os Pull Requests pra ela. Totalmente o contrário do Git Flow workflow, em que você possui um regime de entregas menos constantes, sem a liberdade de um deploy direto em produção pelo time de desenvolvimento.

Pode parecer loucura, não é mesmo? E seria, se a pesquisa não ressaltasse a importância de ter uma extensa bateria de testes sendo executada para cada commit. Seria loucura se o ambiente produtivo não estivesse constantemente sendo monitorado, com extração de métricas e dados que possibilitem avaliar a saúde da aplicação e a saudabilidade das entregas. Com essas salva-guardas, o time tem liberdade para atualizar o ambiente produtivo sem medo, uma vez que ele sempre está de olho nas métricas.

Eu devo copiar a estratégia do Accelerate?

Do meu ponto de vista, como toda pesquisa, o Accelerate mostra o compilado das informações que coletou. O que não quer dizer que todas as empresas seguem à risca a receita apresentada. Nem quer dizer que todos os times nessas empresas seguem o mesmo fluxo.

Para adotar essa estratégia de deploy contínuo, todos os times envolvidos precisam estar culturalmente muito alinhados e maduros. Por isso o subtítulo contém a palavra “Building”: trata-se de um processo construtivo. Cultura não se estabelece, se constrói. E é necessário que em todos os espaços, existam pessoas suficientemente aculturadas, conhecedoras dos processos (e dos seus porquês) para disseminar essa mesma cultura para os seus pares.

Então, não se trata de copiar, mas sim de planejar a caminhada da sua organização até aquele ponto. A estratégia? Essa vai variar de caso para caso. Onde, hoje, você está perdendo mais dinheiro? É com o TTM? Quais são as causas que tem levado suas entregas a demorarem tanto? Sua aplicação está instável? O motivo são altas taxas de retrabalho, ou o processo de deploy está com falhas?

Por mais que as métricas destacadas pelo Accelerate surjam à partir das necessidades do modelo de entrega, são essas mesmas métricas que podem te ajudar a amadurecer os seus times até chegar no deploy [realmente] contínuo.

E quando vamos falar dessas métricas?

Falar das métricas uma por uma tornaria esse post extremamente extenso. Por isso, vou dedicar um post para cada métrica ou grupo de métricas. Por isso, recomendo que salve essa página nos favoritos. Assim que um artigo estiver pronto, vou atualizar o final com o link para os artigos com as métricas.

E nunca é demais pedir: conto com a sua participação nos comentários! Iria enriquecer demais o nosso papo!

• Mean Time To Recover/Mean Time Between Failures (MTTR/MTBF)
• Deploy Frequency / Change Failure Rate  (DF/CFR)
• APDex
• TTM