Não sou especialista em metodologia ágil.
Desculpe começar dessa forma, mas gostaria de deixar as expectativas no lugar certo, apesar de também não querer que você desista do artigo só por causa dessa afirmação. O objetivo é discutirmos e aprendermos em conjunto. Sempre quis levantar este tópico nas comunidades, porque a ideia é compartilhar experiências e, também, alguns pontos de uma pesquisa que fiz recentemente e ainda não está rica de dados, mas talvez sirva como um ponto inicial para tocarmos mais vezes neste assunto. Então, ajustando um pouco mais as expectativas, com esta nossa conversa, espero que vocês também participem, opinem, deixem feedbacks, coloquem suas experiências e enriqueçam o conteúdo como nossas comunidades de tecnologia sempre fazem tão bem.
Minha carreira ainda está no começo, trabalho como desenvolvedora há pouco mais que 3 anos, mas já tive oportunidade de ser inserida ao mundo dos frameworks ágeis. Nem tudo são flores, mas confesso que gostei bastante. Acredito que muitos dos aspectos de se trabalhar com ágil facilitam o trabalho, a comunicação e a resolução de problemas.
Permitam-me colocar um adendo aqui, porque já fui questionada sobre isso em diversas ocasiões, até mesmo em entrevistas de emprego: o que chamo de frameworks ágeis são as mesmas metodologias ágeis que ouvimos chamar no mercado. Acredito que me acostumei a chamar de framework por causa da literatura sobre o assunto que tive contato. Mas entendo que as duas formas de falar são bem aceitas. Eu, pelo menos, não tenho problemas com isso, então vamos em frente.
Conheci o Scrum, o Kanban, o Lean e mais alguns nomes de métodos famosos que temos por aí. Pude aprender sobre isso no trabalho, nas comunidades e também estudando sobre o assunto. Porém, a maioria dos materiais que encontro ou a maioria das discussões que vejo por aí, sejam nas empresas, nos eventos ou nas comunidades, é baseada em pontos de vista de quaisquer papéis dentro do ágil, exceto das pessoas desenvolvedoras. Não sei se notei isso apenas porque sou desenvolvedora ou se é porque realmente não há nada tão profundo ou em grande número levantado sobre esse lado do dado dos frameworks ágeis. Então, faço um convite para falarmos sobre este lado de cá, o lado de quem coloca a mão no código.
Há um tempo, levantei esse ponto nas redes sociais. Sei que parece bobo, mas a comunidade costuma ser bem ativa em algumas delas e fazem excelentes contribuições quando uma discussão é levantada. Mas também tive diversas conversas sobre isso com outras pessoas, de empresas variadas. Muitas das pessoas desenvolvedoras que comentaram, citaram a enorme diferença que sentem entre o que cada papel do ágil entende sobre o que de fato é o ágil e como ele deveria funcionar e, que muitas das vezes, a pessoa desenvolvedora é a última a ser ouvida ou envolvida nos processos do ágil. Então, disponibilizei um formulário com algumas perguntas que, na ocasião, achei que poderiam ser relevantes para conversarmos. Recebi alguns feedbacks incríveis de como eu poderia melhorar a pesquisa e, se acharem que devemos prosseguir com essa conversa, podemos criar uma nova pesquisa e coletar mais dados de melhor forma. Essa primeira foi iniciada em maio de 2019, apenas para pessoas desenvolvedoras.
Em uma das perguntas, levantei o seguinte ponto:
Você recebeu treinamento na empresa onde trabalha para poder utilizar esse framework ou metodologia ágil?
Eu achei interessante o fato de que 43,5% das pessoas não tiveram uma oportunidade de aprender sobre o que são os frameworks e como utilizá-los da melhor forma. Foram apenas “seguindo o baile” durante a execução dos projetos. Além disso, se juntarmos com os 16,5% que tiveram que buscar conhecimento de forma gratuita em eventos, comunidades e cursos e os 2,6% que fizeram o mesmo, porém de forma paga, temos um grande número de pessoas que não tiveram apoio da empresa em que trabalham. De todos que responderam, apenas 37,4% participaram de treinamento na empresa. Mas também levantei a seguinte questão na pesquisa:
Você se sente preparado(a) para trabalhar com frameworks ou metodologias ágeis?
Nesta questão, 80% das pessoas que responderam, disseram que sim, sentem-se preparadas para trabalhar com frameworks ágeis. Enquanto isso, apenas 2,6% das pessoas disseram que não se sentem preparadas e 17,4% das pessoas responderam que não sabem dizer se estão ou não preparadas.
Mas, analisando friamente, não acredito que isso seja o suficiente para identificarmos o quanto sabemos ou não sabemos sobre os frameworks. Não digo que deveríamos ser todos certificados para podermos falar sobre isso, não é essa a ideia. Teríamos que fazer uma análise muito mais profunda sobre como foi o processo de treinamento e, muito além disso, analisar o quanto é possível aplicar tudo o que aprendemos da forma correta. E é aqui que quero levantar um dos primeiros pontos da discussão.
Todos nós sabemos o quanto é difícil relacionar teoria com a prática e que no decorrer dos dias, e a pressa de que tudo é para ontem, poucas são as vezes que conseguimos realizar os processos do jeito certo, ou sequer realizar parte deles.
O que mais ouço dos colegas de profissão é que muitas pessoas confundem “ser ágil” com “ser rápido na entrega”. E que nem sempre essa é a visão apenas dos clientes, mas também dos próprios membros da equipe do projeto.
Mas se é ágil, por que perder tempo com todas essas cerimônias (daily, planning, retrospectiva, entre outras)?
Não era para ser ágil? Por que não está pronto?
Esses são só alguns dos questionamentos que acontecem e que, sinceramente, do meu ponto de vista, não fazem sentido algum. Uma equipe não vai entregar uma atividade em menos tempo só porque o projeto está dentro de um framework ágil, mesmo que ele facilite alguns processos. Com esses questionamentos, entramos em outros pontos que acabam atrapalhando um pouco a vida do time de desenvolvimento: cultura ágil, estimativa e priorização de entregas.
Virar a chave em uma equipe ou nos projetos e dizer que agora todo mundo é ágil, não é tão simples quanto parece. Os frameworks ágeis são uma transformação de cultura e essa transformação deve ser feita em todos: no time de desenvolvimento, nos gestores, no cliente, na área comercial… Literalmente todo mundo que estiver envolvido de alguma forma. Por isso, estudar sobre o assunto, discutir sobre diferentes pontos de vista, levantar questionamentos, participar de eventos, treinamentos, alinhar pensamento e entendimento no time… Tudo isso é importante para que as coisas caminhem para o lado certo e não vire uma enorme bola de neve de entregas acumuladas que, na verdade, não foram entregues por causa de inúmeros impedimentos ou bugs que surgiram, muitas vezes por falta de planejamento, ou por dizer que tudo é prioridade, ocasionando estimativas incorretas. Então é necessária uma análise para entender se o que se conhece, está sendo aplicado da melhor forma para o desenvolvimento do projeto.
Na sua visão, o framework ou metodologia ágil tem uma aplicação correta no(s) projeto(s)?
Um dos pontos positivos que considero nos frameworks ágeis é que eles podem ser adaptados quando aplicados no mundo real. Nem tudo precisa ser seguido conforme rege a literatura do assunto. Mas devemos ressaltar que ainda assim, o planejamento é um dos passos mais importantes a serem considerados em qualquer projeto. Já vi também, visões de algumas pessoas apontando que frameworks ágeis não precisam de processos para darem certo, algo que entendo não ser correto, pois eles possuem processos e dicas de como podem ser realizados.
Nessa questão, apenas 13,9% das pessoas disseram que suas equipes conseguem aplicar 100% da metodologia no projeto. Das demais respostas, 62,6% disseram que realizam adaptações para utilizar o framework e 23,5% responderam que acreditam que o framework está sendo utilizado de forma incorreta. Vocês enxergam isso como algo preocupante?
O(s) projeto(s) no(s) qual(is) você trabalha tem entregas por sprints?
Essas respostas também podem ser vistas como preocupantes ao meu ver. 45,2% das respostas indicam que as estimativas são quase irrelevantes, pois mesmo que as entregas sejam por sprints, já foi definida uma data de entrega previamente. Acredito que muitos de nós já estivemos em projetos assim e que nem sempre a estimativa dá certo ou é considerada porque a data de entrega já está definida e temos que atendê-la. Este ponto envolve outras situações, como experiência e sincronia do time, quantidade de pessoas para desenvolver, quantidade de horas disponíveis para a entrega, entre outros.
Outra questão que fiquei curiosa sobre como seria o resultado dessa pesquisa, era entender o quanto nos permitem participar de cerimônias como plannings, daily, retrospectivas etc.
Você e o time de desenvolvimento tem a oportunidade de participarem das plannings?
Confesso que fiquei surpresa de ver que 90,4% das pessoas disseram que participam das plannings e apenas 9,6% responderam que não tem a oportunidade de participarem.
Quanto as demais cerimônias, conforme o próximo gráfico, 83,5% das pessoas apontaram que participam, enquanto 8,7% participam apenas da daily e 7,8% não participa de nenhuma outra cerimônia.
Você e o time de desenvolvimento tem a oportunidade de participarem das demais cerimônias (review, retrospectiva, daily, entre outras)?
Aproveitando essas questões, levanto outra reflexão: será que os profissionais que estão com a oportunidade de participar de todas as cerimônias, o que é incrível, possuem voz? O que quero dizer é: o quanto são consideradas, por exemplo, as estimativas feitas? E, tão importante quanto a questão anterior, quanto estamos conseguindo ou não acertar essas estimativas de entregas para cada sprint, ou as outras formas como são feitas? Será que estamos conseguindo prever e apontar possíveis problemas?
Estimativa, pelo menos para mim, costuma ser uma das dificuldades em um projeto, apesar de já terem me dito que essa habilidade, adquirimos com a experiência. Mas também há outras dificuldades que um time de desenvolvimento pode passar e algumas delas foram relatadas pelas pessoas na pesquisa. Seguem as que receberam a maior parte dos votos, em ordem:
- (54,8%) Estimar as atividades em projetos que já tenham data de entrega definida;
- (51,3%) Ter especificações claras e definidas para que possa realizar as atividades;
- (44,3%) Ser solicitado para realizar novas atividades durante uma sprint que não tinham sido definidas;
- (28,7%) Entregar dentro da sprint;
- (23,5%) Estimar as atividades mesmo sem data final para entrega definida;
- (20%) Ter contato com direto com o cliente;
- (17,4%) Entender o papel de cada um no projeto (P.O., Scrum Master, Time de Desenvolvimento, entre outros);
- (14,8%) Comunicação entre as pessoas do time de desenvolvimento;
- (14,8%) Ter que aprender novas tecnologias de maneira muito mais rápida que o normal;
- (13%) Entender o objetivo das cerimônias (planning, daily, retrospectiva, entre outras).
Muitas outras dificuldades foram apontadas, mas essas foram as 10 mais citadas durante a pesquisa.
Não posso esquecer de comentar sobre algo que é extremamente complicado de lidar e foi uma das dificuldades citadas acima: a tal da atividade que não era prevista e foi colocada no meio de uma sprint porque ela é extremamente urgente. Isso bagunça um pouco (muito, na verdade) aquela entrega. Normalmente, quando conseguimos analisar o que foi colocado em uma planning, fazemos as estimativas apontando o que poderia ser entregue na sprint correspondente. Em um mundo perfeito, a sprint segue até o fim com aquelas atividades e fazemos aquela parte de entrega. Mas o que mais acontece é: incluem uma ou mais tarefas ou alteram, de forma significativa, as especificações de uma ou mais atividades que seriam daquela sprint. E tudo se perde. A bola de neve nasce, cresce, se reproduz e dificilmente morre. O time de desenvolvimento também precisa se preparar para isso e tanto o cliente quanto os demais envolvidos, devem, então, priorizar. E outras atividades devem ser “sacrificadas” para que aquela urgência seja atendida naquela sprint. E o que foi sacrificado, poderia ser colocado nas próximas sprints, assim por diante. Acredito que posso dizer o quanto entendemos que imprevistos acontecem, problemas surgem e prioridades mudam. Mas todos os envolvidos deveriam também levar em conta o que deve ser perdido para que o imprevisto seja atendido. Algo que nem sempre é respeitado.
Não tive o intuito aqui de “puxar sardinha” para o nosso lado, o lado das pessoas desenvolvedoras. Mas acredito que tenha deixado diversos pontos sobre os quais podemos explorar e conversar, além de avaliar o quanto deveríamos estar mais envolvidos desde a criação do projeto. Também caberia falarmos mais sobre as responsabilidades de cada um dos papéis dentro dos profissionais num framework ágil.
Nós, como pessoas desenvolvedoras, temos muito o que aprender com frameworks ágeis. Por exemplo, como apontado nas dificuldades, muitos de nós possuem dificuldade de entender o objetivo de cada uma das reuniões e como é importante participarmos delas. Também temos dificuldades como acertar estimativas e, até mesmo, entender nosso papel e como nos posicionar perante os problemas, além de aprendermos a lidar melhor com os clientes. Aquele velho papo de que precisamos evoluir não apenas nosso perfil técnico, mas também desenvolver melhor nosso lado profissional, as soft skills. Mas ressalto que é importante estarmos envolvidos no processo de planejamento de qualquer projeto que nos envolvam. Não apenas para questões de estimativa, mas acredito que quando estamos participando do planejamento, entendemos melhor o negócio e o que precisa ser feito, além de ficarmos mais inseridos nos processos. Utilizar frameworks ágeis não é algo tão fácil, mas como parte da equipe, acredito que podemos evoluir com todos os demais envolvidos. E essa conversa é bem maior que apenas um texto no medium.
Por favor, como disse no início, fiquem a vontade para participarem dessa discussão, deixarem feedbacks e compartilharem conhecimento e experiências. Vamos crescer juntos.
Morganna Giovanelli, estudante de Análise e Desenvolvimento de Sistemas da FATEC de Mogi das Cruzes, desenvolvedora apaixonada por tecnologia, por comunidades e pelo nosso mundão nerd e evangelizadora da palavra da Ada Lovelace.