Se você é de computação, a não ser que estivesse congelado ou vivendo em uma caverna isolado do mundo nos últimos 18 anos pelo menos (o manifesto ágil é de 2001), já ouviu falar de métodos ágeis.
Muito se fala em ser ágil e como as equipes devem se adaptar as adversidades do dia a dia. O cliente muda de ideia diversas vezes, o cronograma e orçamentos são apertados e ainda tem os defeitos para divertir nossa vida.
Porém, com isso, vejo ainda muita confusão sobre o que é ser ágil.
Nesse contexto, gostaria de dizer o que NÃO é ser ágil, para eliminar alguns absurdos que ouvimos por aí e auxiliar no melhor entendimento.
Ser ágil NÃO É
deixar de documentar: seja o software em si, a arquitetura, os testes. Não precisamos ter manuais do tamanho dos senhor dos anéis, com 500 páginas para explicar como iniciar um pagamento em nosso sistema. O sistema deve ser intuitivo e levar ao usuário o que ele precisa da forma mais forma possível. Mas isso não signigica que não precisamos fazer qualquer tipo de documentação. Documentação é necessária, e ao nível que a equipe concordará que será útil. Seja em testes que documentam como o software funciona, documentação automática baseada no código, ou mesmo diagramas, desde que sejam úteis para a equipe.
deixar de ter um processo: desenvolver software sem processo, mesmo que ágil, significa apenas que sua empresa será uma bagunça mais rápida. Ser ágil não significa a ausência de processos e métodos de trabalho. Pelo contrário. É justamente primando por essa agilidade, que todos devem saber exatamente como trabalhar e em que fase cada tarefa está claramente para agir de acordo com a necessidade do momento.
deixar de ter fazer testes, principalmente os end-to-end: “Ahh aqui a gente é ágil, então o programador mesmo já codifica e testa. A gente não precisa de quality assurance nem tester não, isso é perda de tempo”. A qualidade, como um todo, deve ser pensada desde o início do produto. Devemos pensar em teste desde a concepção do que queremos fazer no software. Vamos discutir sobre a nova funcionalidade? chama os testers, QAs, QEs, pra conversa e discussão. A pirâmide de teste deve ser levada em consideração.
ter uma arquitetura má definida: “Vamos começar a desenvolver logo, mostrar pro cliente e ouvir o feedback”. Lindo essa idéia de design sprint. E concordo que funciona muito bem para alguns contextos. Mas serve para tudo? Se o software é complexo e crítico, inevitavelmente precisamos gastar um tempo definindo a arquitetura dele e discutindo os detalhes e limitações. Dificilmente teremos tudo definido no início (coisa de método cascata), mas pelo menos precisamos ter alguma consistência ao começar a construir o software.
evitar reuniões a todo custo: sim, sabemos que em muitas empresas gastamos muito tempo com reuniões infinitas que saem de lugar nenhum para nenhum lugar. Mas isso não significa que todas elas são inúteis ou irrelevantes. Uma das dicas do agile é colocar um tempo limite para elas. Sempre ter uma agenda e mediador também ajuda muito.
colocar qualquer coisa em produção: a ideia dos métodos ágeis é colocar um produto em produção o mais rápido possível, para que com isso, consigamos reunir as experiências e feedbacks dos usuários e evoluir o produto. No entanto, essa corrida para colocar o código em produção não significa despachar algo ruim, mal feito, cheio de defeitos básicos e que não cumpra o que os usuários querem. Idealmente, começamos com funções simples, mas que façam um mínimo de fluxo que agregue valor para os clientes. A partir do uso e respostas, evoluímos o produto para a maturidade.
ficar mudando os requisitos durante a sprint: usar métodos ágeis significa “abraçar mudanças” e se adaptar a elas quando aparecem. Mas nem por isso significa que iremos cumprir todo e qualquer requisito que aparece durante uma sprint. Se estamos usando scrum, devemos blindar a equipe durante as sprints para que consigamos entregar o que foi acordado no planejamento da sprint. Caso precisemos mudar o escopo ou cancelar o que está sendo feito, devemos entrar em acordo com a equipe (pois todos concordaram quanto ao que seria feito anteriormente).
Para saber mais
https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#44ba30034bbe
