Como uma equipe Ágil pode se comportar com demandas Top-down (inclusive o QA)
O meu exemplo aqui será embasado em um produto novo, em cuja equipe de TI (Salesforce) estou alocado. O projeto teve início em Maio de 2023 e foi concluído no fim de Junho do mesmo ano e eu atuei com QA (Quality Assurance).
Você faz parte de uma equipe que segue a Metodologia Ágil?
O que você sente quando a sua equipe precisa atender uma demanda top-down?
Como sua equipe costuma se portar com prazos que não necessariamente partiram dela, ou seja, vieram de cima?
Você sai correndo? Já recorre ao Rivotril? Maldiz o Top-down? Como o Chicó de O Auto da Compadecida, você diz “Ô, promessa desgraçada! Ô promessa sem jeito!!!”?
Calma! Só significa que esse artigo é pra você.
Imagine o seguinte cenário: a sua empresa lançará um produto novo. A data já está marcada, todos os outros setores já estão por dentro, já tem até comercial no YouTube, nos canais de TV aberta e a sua equipe precisa desenvolver a solução em tempo hábil (para a empresa).
A primeira coisa que vem à mente é o timebox, pois o tempo de desenvolvimento não foi estipulado pela sua equipe, ou não somente por ela.
Logo depois, vem a sensação de que não será possível entregar com a devida qualidade, com o máximo de cenários testados e validados.
Antes de qualquer coisa, vamos “desdemonizar” o Top-down, partindo do princípio de que os gestores/coordenadores dispõem de certo know-how para estarem onde estão (pense sobre… seu chefe vai gostar de saber que você tenta se colocar no lugar dele).
O gestor que se preze tem uma visão do todo, do conjunto. Tem a famosa “dor-de-dono” (ainda se não for mesmo o dono), então provavelmente não tomaria decisões que colocariam em risco o projeto em questão e o nome da empresa, ao comprometer-se inclusive com prazos.
Agora, finalmente, vamos a algumas das possíveis soluções:
- Priorização TOTAL da demanda – A equipe volta-se inteira e trabalha dia e noite se necessário.
Outras histórias são deixadas de lado, a não ser incidentes muito urgentes. - Subdivisão da equipe – Squads maiores podem deslocar profissionais para o projeto específico, mantendo ainda outros com as histórias que já estavam em andamento e tratando as que podem chegar.
No caso da equipe de que faço parte, a solução foi seguir o caminho do item 2.
Dessa forma, eu fui designado para a parte de QA, deixando meu parceiro no setor testando outras demandas da squad, assim como foi feito com os desenvolvedores também.
Para me ajudar, veio um outro analista de qualidade, este mais focado para a automação de testes utilizando o Selenium.
Cada história referente ao produto novo teve recursos com foco 100% (cem por cento) no seu desenvolvimento e teste.
O Scrum Master e a PO (Product Owner) “flutuavam” entre a squad principal e a que foi especialmente escolhida para a Feature. Eles optaram por realizarmos não necessariamente todos os ritos do ágil, portanto ficamos mais focados em dailys, refinamentos e homologações.
Assim, foi possível demonstrarmos todo nosso trabalho no cliente.
Soluções de desenvolvimento, prazos e cenários de teste com evidências estão todos lá!
Sabe-se que nem sempre as coisas acontecem de forma tão fluida quando se trata de quebra de rotina.
Ainda assim, as interrupções no dia-a-dia de uma squad que já vivencia o Ágil com demandas de cima tendem a colocar à prova as nossas soft-skills (habilidades sutis / não-técnicas), na realidade. Mais ainda do que as hard-skills (habilidades técnicas)!
Um desenvolvedor que sabe codificar com maestria, conhece as ferramentas de que dispõe (nosso exemplo é a linguagem Apex aplicada ao Salesforce), simplesmente pode não ser tão produtivo se não tiver resiliência para contornar a possível falta de tempo hábil (ou pelo menos o tempo a que estava acostumado a ter para desenvolver).
Eu, como QA, sem o devido foco, não saberia “virar a chave” tão rapidamente para abraçar o desafio. Com criatividade (e o grande ChatGPT me ajudando a formular os cenários), além da parceria do outro QA que cuidou extremamente bem da parte de automação de testes, pude me concentrar ainda melhor nos testes manuais, evidências e homologações.
Por falar em criatividade, a decisão dos gestores imediatos junto ao nosso SM (Scrum Master) em dividir a equipe para dar clareza sobre onde focar foi muito assertiva também, não deixando de ser uma solução… adivinhe… criativa!
A comunicação constante da nossa PO com as áreas que seriam beneficiadas com os novos desenvolvimentos foi decisiva! Em poucos instantes, dúvidas pontuais eram resolvidas e podíamos dar prosseguimento às soluções.
A situação foi tão bem gerida que é possível você estar perguntando: “Será que REALMENTE foi uma demanda top-down?”
A resposta é interpretativa – minha opinião é que sim. Porém, ainda que chegássemos à conclusão de que o maior traço de top-down fosse apenas o timebox, resta lembrar que só a adaptabilidade pode fazer com que uma demanda deste tipo possa ser tratada e entregue utilizando o Ágil.
Nossa PO, ao demonstrar reconhecimento à equipe, classificou nossa forma de tratar o projeto como “Ágil do Ágil”.
