Imagine que você acaba de ser contratado por uma grande empresa e a sua primeira atividade é a de contribuir na criação de um novo produto. Essa, com certeza, será uma experiência desafiadora. E ela será feita em equipe, um squad. Um conjunto de profissionais, cada qual com sua especialidade, e todos com algo em comum: receberam as mesmas ordens.
A experiência de compor um squad é como a de receber uma nova identidade. Por se tratar de um grupo multidisciplinar com o mesmo objetivo, adquire-se rapidamente grande fluência nas discussões, ao mesmo tempo em que a visão do todo parece estar sempre em expansão. Você domina a sua disciplina e especialidade, o seu papel no squad, mas também sente-se muito capaz de compreender as minúcias do que fazem os seus colegas.
O contato direto com profissionais e cenários de outras áreas é, por si só, realmente muito enriquecedor, e unir esse conceito ao ágil é como atingir o suprassumo do que significa organização. Na ClearSale, por exemplo, essa união recebe um nome específico e de um enorme significado: Harmonia.
“Tá legal, então aqui estou. Nova empresa e novos desafios. Entendi que farei parte de um squad, e também li o que diz o manifesto. Mas e a prática do dia a dia? Como perceber e aplicar esse monte de princípios?”
Na cultura ClearSale, nós temos um processo que encanta a qualquer um logo de cara: o de acolhida. Um período em que todo novo colaborador é apresentado aos times de cada área e vice-versa. Nele, nós nos apresentamos e falamos sobre aquilo que nos move, sobre os motivos pelos quais fazemos o que fazemos, e o que nos levou até aqui. E assim, tão cedo, entendemos porque é tão importante a participação, colaboração e comunicação das pessoas em todas as etapas.
Fazendo uma analogia com os valores descritos no Manifesto, você começa a perceber que os indivíduos e a interação entre eles são mais importantes que processos e ferramentas. Veja, na nossa acolhida existe, sim, um processo no qual também podemos recorrer ao uso de ferramentas, mas isso não é mais importante que ouvir as pessoas, criar vínculo e apresentar a elas a nossa história. Ao final, o esperado neste processo é que haja a sensação de pertencimento e de apoio mútuo, como deve ser em uma acolhida.
Além disso, existe ainda outro bom exemplo sobre a importância de uma boa interação entre pessoas: o desenvolvimento de software.
O desenvolvimento de software é uma atividade humana e pode ser otimizada com interações de qualidade entre as pessoas. Quando conseguimos nos comunicar efetivamente, começamos a atacar o problema que aquele algoritmo veio para resolver, conseguimos colher feedbacks e melhorar cada vez mais. Os processos e as ferramentas nos ajudam, e quanto mais simples e úteis eles forem, melhor será nosso dia-a-dia. Afinal de contas, queremos sempre entregar o nosso software funcionando, livre de bugs.
Usando como base para o nosso desenvolvimento a metodologia Scrum e o ciclo de sprints, é assim que podemos validar se estamos no caminho certo e se o planejamento precisa ser alterado.
Daí, a essa construção podemos interpretar que software em funcionamento é prioridade em relação à documentação abrangente. Ou seja, temos um desenvolvimento ágil quando percebemos rapidamente se estamos ou não estamos entregando valor e se não realizamos desperdícios ao gerar documentos que não refletem a realidade do software. Documentar é muito importante e irá agregar ainda mais valor ao produto, porém o seu valor é secundário e depende do software estar em funcionamento.
Junto a isso, é importante, ainda, ressaltar que devemos atuar em conjunto com o cliente, sempre ouvindo o que ele tem a dizer e compreendendo que essa colaboração favorece a tomada de decisões. Afinal, em um cenário onde o produto final se constrói com o tempo, decisões são sempre tomadas em conjunto. Somos todos uma equipe em busca de um objetivo, e o papel daqueles que atuam como um squad é procurar entender o produto ideal, a dor e as frustrações do cliente. Quando o Manifesto diz que colaboração com o cliente é mais importantes que a negociação de contratos, podemos entender como uma relação de confiança entre as partes: squad e cliente.
E por fim, chegamos ao 4º valor do Manifesto: responder a mudanças é mais importante do que seguir um plano. Falamos bastante sobre ouvir o cliente e entender o problema, mas o que fazer se estivermos no caminho errado? Afinal, isso é totalmente possível. Veja, existe uma cerimônia praticada no scrum chamada de review, que é o momento destinado a apresentar aquilo que foi construído durante a sprint e compreender como essa nova peça se integra ao todo: ao planejamento, aos anseios do cliente e às capacidades do time. Durante uma review, não é incomum que as coisas caiam por terra.
Na cultura ClearSale, por exemplo, errar é, quase sempre, motivo de comemoração, pois entendemos que errar rápido faz muito mais sentido. Existe espaço para mudar, se isso nos colocar mais próximos de onde deveríamos estar. É isso o que realmente interessa, compreende? Por aqui, estamos sempre nos adaptando, experimentando, aprendendo e seguindo. Liberdade com responsabilidade é o nosso lema.
Caminhando por terrenos mais técnicos, existe uma outra cultura que se encaixa muito bem à temática ágil. O DevOps. Uma maneira eficiente de fornecer software compartilhando dores e responsabilidades.
Por convenção, a entrega de um software envolve minimamente três etapas: desenvolver, testar e publicar. Portanto, é normal que para cada uma destas um profissional diferente seja designado à tarefa.
O que devops se propõe a resolver é o dilema existente entre desenvolvimento e operação, ou seja, para um profissional de desenvolvimento, muitas entregas teoricamente representam algo positivo. Afinal, é isso o que fazemos, construímos cada vez mais, e melhor. Mas, para um profissional de operação, o cenário se inverte, pois, cada nova feature precisa ser verificada com grande atenção antes de ser implementada e publicada; e um número excessivo de entregas pode atrasar todo o ciclo de vida de desenvolvimento de software.
A verdade é que existem inúmeras ferramentas e abordagens possíveis para se explorar a partir daqui, então não seria justo que tentássemos explorar todas de uma só vez. Para esta ocasião, separamos uma única, na qual estivemos mais envolvidos em alguns dos nossos squads. Continue a leitura e compreenda um pouco mais sobre o assunto. Falaremos sobre entregas e implantação contínuas.
Adotada normalmente por sistemas que já atingiram alguma maturidade, a abordagem de integração contínua e implantação contínua pode ser interpretada a partir de dois conceitos: automação e monitoramento.
Uma vez adotado o ágil, com a necessidade de entregas tão frequentes quanto se é possível para permitir que novos recursos sejam integrados a um sistema, uma nova categoria de teste é incluída ao projeto: os testes automatizados. O ideal esperado é que uma vez garantida a estabilidade do sistema, toda nova construção deve ser sempre submetida a eles. Dessa forma, como uma tarefa necessariamente posterior à construção do código e anterior ao merge, os testes automatizados se tornam os responsáveis por possibilitar a integração contínua.
Neste pipeline onde iremos inserir os testes, diversas verificações são possíveis. Como análise estática, testes unitários, testes de comportamento, de integração, estresse, etc. Se o código não for rejeitado, é integrado, e a implementação se torna, então, uma possibilidade, onde então, em última etapa, o recurso aprovado é versionado em repositório (normalmente em master branch) e em seguida implementado para uso em produção. Como demonstra a ilustração a seguir:
Em publicações posteriores, planejamos demonstrar como esse processo é realizado na prática; descrevendo o uso real empregado por uma de nossas equipes, explicando variações possíveis deste processo e explorando as ferramentas utilizadas durante a integração.