Vamos falar sobre metodologias ágeis?

O Post a seguir foi o primeiro que eu escrevi na minha vida, foi na época que trabalhei na Concrete Solutions, corrigi algumas coisas, coloquei mais algumas visões que tenho hoje em dia.

Espero que curta essa leitura, eu fiz a correção ouvindo Five Finger Death Punch uma banda de heavy metal que eu simplesmente amo!

Boa leitura!

E aí jovens! Tudo bem? Nesse post vou falar um pouco da minha vivência com metodologias ágeis dentro da Concrete Solutions e tentar explicar o essencial para quem está iniciando na carreira de tecnologia atualmente.

Sabemos que existem diversas metodologias ágeis. Como por exemplo Scrum, XP, Kanban, etc... Essas metodologias servem para gerenciar o desenvolvimento e para realizar boas entregas no menor tempo. Claro, priorizando a qualidade para que assim você possa focar no produto.

A partir de uma visão geral do que o cliente precisa, nós como time precisamos transformar em algo palpável em pouco tempo, e para isso é necessário:

1. Realizar uma reunião com o time para deixar o projeto claro;
2. Alinhar com o time e quebrar em partes o desenvolvimento do projeto;
3. O Product Owner organizará as tarefas e suas prioridades, separando em sprints, que são ciclos para realizar as entregas do projeto.

E pelos estudos que fiz nos últimos tempos, a demora na entrega foi o que motivou a criação desses métodos lá década de 90, um software demorava coisa de 2 a 3 anos para ser entregue.

As entregas eram sempre softwares enxutos, com muitas funcionalidades, o que era bom! Certo?! Errado! (aqui lê-se Erroooooou!). Porque além do alto custo para o desenvolvimento, acabava saindo do escopo do cliente e aquilo que foi solicitado mudou ou não tinha mais serventia.

Comparando com o mercado de TI, que hoje em dia muda tudo em alguns segundos, imaginem no início onde muitas empresas queriam evoluir tecnologicamente falando, e com essa demora na entrega, alguns dos propósitos iniciais daquele software já estavam completamente defasado.

Analisando esses problemas, 17 pessoas com o intuito de resolver está demora se reuniram na cidade de Utah (EUA). Entre elas, estavam os criadores do Extremme Programming, Scrum, Adaptive Software Development, Feature-Driven Development, Pragmatic Programming, entre outros métodos.

Se passaram vários dias de brainstorm, pegando tudo que cada um deles havia criado de expressivo nas metodologias já existentes e gerando ideias para a criação do manifesto ágil (resuminho do que pode ser verificado aqui).

Sendo assim, concluíram como essenciais os seguintes pilares:

• Indivíduos e interações mais que processos e ferramentas.
• Software em funcionamento mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder a mudanças mais que seguir um plano

Ou seja, mesmo tendo o valor nos itens da direita, priorizar os itens à esquerda.

Dessa forma, conseguimos tornar mais humano o desenvolvimento de software. Possibilitando que ele se molde e evolua junto ao time, assim formando o manifesto ágil. Que pode ser implementado na sua empresa, no seu time, equipe de hackathon e onde for necessário realizar entregas com qualidade e agilidade.

Lembrando que o adjetivo ágil no dicionário é: eficiente, rápido no trabalho; diligente, trabalhador.

Você precisa ser ágil, que não enrola nas entregas, não deixa o time na mão e se tiver alguma dificuldade, levantará a mão para pedir ajuda. E não vai esperar até o fim da sprint e dizer que não entregou sua parte porque estava dependendo de alguém e se você não sinalizou isso, a culpa é sua, certo?

Como é o dia-a-dia de um time que usa metodologias ágeis? Eu explico:

Baseado nos times que já trabalhei, começamos com a daily, sendo uma pequena reunião de 15 minutos feita para poder falar o que fizemos no dia anterior, o que faremos no dia atual e se temos alguma dificuldade para poder concluir aquela tarefa. Essa é feita todos os dias de segunda a sexta. As vezes rola de fazer um checkpoint só para atualizar certa tarefa ou demanda.

No começo ou no final da sprint, vamos fazer a retrospectiva e o refinamento. essa data é definida pelo time mas como exemplo da entrega do sprint ser na sexta de manhã e fazer o planejamento na parte da tarde, para começar na segunda-feira atacando aquelas tarefas.

Uma observação muito importante é comunicação sempre! Sempre esteja online no Slack, Teams da Microsoft, Chat da Google, fazendo um sinal de fumaça e levantando-se da mesa e indo até a pessoa (mas em caso de pandemia, #FiqueEmCasa), e segue o baile.

Mas o que eu gostaria de acrescentar é em caso tenha algum problema, seja ele pessoal ou profissional, levanta a mão e converse com a seu time, sejam eles seu Product Owner, Delivery Manager, Project Manager, Dev Team, eles vão dar um jeito de resolver essa barra com você! Se for um impedimento de terceiros por exemplo, e depender de um acesso, um serviço na AWS/Azure ou de qualquer outra plataforma, essas pessoas estão ali para poder te ajudar. Caso eles não tenham uma solução, eles saberão a quem recorrer.

Lembre-se, nem toda chamada de atenção que você ou o time leva é para o mal de vocês. Como um time de futebol, é necessário o trabalho em equipe para poder vencer os desafios que nos foram impostos. Pegue isso, veja os pontos que está errando e melhore. Caso tenha dificuldade de resolver algum ponto específico, tem o seu gestor(a), conselheiro(a), coordenador(a), um(a) amigo(a) para te ajudar a melhorar nisso.

Obrigado!