Os, assim chamados, "métodos ágeis" possuem contraindicações e efeitos colaterais muito graves, mas que são menosprezados pelas equipes, gestores e clientes de desenvolvimento de software.
Minha experiência, em vários cursos e projetos desenvolvidos, somente confirma essa convicção, que gostaria de compartilhar com vocês.
Ágil está na moda
É, infelizmente, está sim! Criou-se um "amálgama" de técnicas subjetivas, de resultado questionável, que foram denominadas pelos fornecedores de: "Métodos ágeis". E, como toda prática subjetiva e questionável, há muita emoção em torno do assunto. Tanto que, questionar os "métodos ágeis" o transforma imediatamente em um E.T.
Scrum, Kanban e Planning Poker se transformaram em sinônimos de métodos ágeis. É triste constatar isso, pois, na verdade, são apenas parte de um todo (uma parte muito questionável, para ser sincero).
Os métodos ágeis começaram com Engenheiros de Software, profissionais experientes que, revoltados com o formalismo excessivo de outros processos, como: PMI, RUP e CMMI, resolveram adotar práticas que resgatassem o que é mais fundamental em desenvolvimento de software: A satisfação do Cliente.
São também métodos ágeis:
- XP: Extreme Programming. Uma metodologia ágil de projeto e construção de software;
- TDD: Test-driven Development. Uma técnica para desenvolvimento, baseada em testes, que visa produzir software com maior acurácia e menor risco;
- FDD: Feature-driven Development. Um processo de desenvolvimento de software que se situa entre o formalismo do RUP e a liberalidade do Scrum;
Por que Scrum? Por que Kanban? E, pelo Amor de DEUS: POR QUE PLANNING POKER? Por que são SUBJETIVOS o suficiente, o que evita questionamentos, são lúdicos o suficiente, o que os torna palatáveis para todos. E a Comunidade envolvida se tornou tão arraigada na defesa do SKPP, que jamais admite utilizar outras técnicas, mesmo que sejam consideradas "ágeis".
Duvida? Bem, tente conversar com um adepto do Scrum sobre XP. Ele reagirá como se você tivesse xingado a progenitora dele!
Assim, algo que começou com a intenção de produzir software melhor, com menor custo e risco, se transformou em um DOGMA, onde a SUBJETIVIDADE comanda todo o desenvolvimento, e o produto final se deve mais a HEROÍSMO do que à ENGENHARIA. Em outras palavras:
ESTAMOS VOLTANDO AOS ANOS 70 NO DESENVOLVIMENTO DE SOFTWARE!
Bem, eu já cansei de falar, escrever e discutir isso, mas precisava colocar essa primeira parte para relembrar o contexto das minhas objeções aos "Métodos ágeis".
Contraindicações e efeitos colaterais
Métodos ágeis, em particular o "coquetel" SKPP (Scrum+Kanban+PlanningPoker) possuem contraindicações e efeitos colaterais graves, os quais vou tratar agora.
Agora é que você vem me dizer isso?!
De acordo com os cursos que já fiz, os livros que já li e a experiência prática que tive com "Métodos ágeis", posso afirmar que SKPP não se presta a todo tipo de projeto nem a todo tipo de equipe, em especial:
- Projetos desenvolvidos por equipes grandes ou pouco experientes;
- Projetos críticos (tanto no prazo como no risco);
- Projetos complexos;
Por que essas contraindicações?
Equipes muito grandes possuem talentos diferenciados, em níveis igualmente diferenciados de experiência. Profissionais mais Juniores, precisam de especificações formais e de orientação próxima, enquanto os Seniores dispensam isso tudo.
Equipes pouco experientes na Tecnologia ou no Modelo de negócio do Projeto, acabam compreendendo mal os requisitos (funcionais e não funcionais), acabando por entregar software com baixa qualidade.
Projetos críticos são um baita problema, pois já começam com "DATA ENTREGA" estipulada, logo, não há margem para erros. A tendência do SKPP é gerar um número variável de Sprints que, a cada etapa, não necessariamente entregam algo "implantável". Sem um cronograma bem elaborado, que considere a disponibilidade dos recursos e um diagrama de rede, que demonstre o "Caminho crítico", fica difícil dar transparência e gerenciar tais projetos.
Finalmente, em projetos complexos, há uma grande interdependência entre conceitos, estados e operações no modelo de negócios, o que não casa muito bem com o planejamento "ad-hoc" do Scrum. Nem sempre é fácil, prático ou viável separar os "Épicos" em "Histórias" independentes. E, da mesma forma, projetos complexos exigem modelagem mais detalhada, o que não casa muito com o "entendimento da equipe", apregoado pelos "agilistas". Acabam havendo distorções e desentendimentos entre a equipe e com o Cliente, gerando retrabalho e alto custo.
Eu não estou escrevendo isso de maneira puramente "teórica'", mas com base em experiência prática.
Efeitos colaterais
Nervosismo é o efeito colateral mais comum em projetos "ágeis"
Eu desenvolvo software há mais de 30 anos. E já trabalhei com todos os tipos de processo de desenvolvimento existentes: Cascata, RAD, Iterativo e Ágil. E posso afirmar, com certeza, que os projetos "ágeis" deixam as pessoas mais nervosas, gerando um estresse enorme e desnecessário.
As entregas passam a ser o foco da Equipe, e não a satisfação do Cliente ou a qualidade do Produto. Entregar, de qualquer forma, passa a ser o "Santo graal" e dedos começam a ser apontados, nas, assim chamadas: "Retrospectivas". Não há margem para erros, mesmo que tenham sido causados pelo próprio processo. Logo, as pessoas passam a se esforçar em um nível muito maior do que o necessário, trabalhando e se preocupando em excesso, o que leva a mais desatenção e mais erros.
- Microgerenciamento;
- Nervosismo da Equipe;
- Dificuldade de adaptação às mudanças;
- Problemas de comunicação;
- Baixa qualidade do software;
- Inconsistências entre produtos de Sprints diferentes;
É fundamental para o sucesso de um projeto ágil, que a equipe se autogerencie, ou seja capaz de administrar o andamento do Sprint, sem a necessidade de tarefas formais e cobranças. O que vemos no Scrum é justamente o oposto disso.
Os requisitos não são adequadamente mapeados nem compreendidos. Cada membro da equipe tem uma visão limitada e particular do que é necessário fazer, e geralmente se privilegia "o entendimento da equipe" sobre o registro das histórias, logo, nem sempre está escrito o que é necessário e nem sempre está sendo feito o que foi solicitado, o que somente é descoberto ao final do Sprint.
Com isto, não sobra tempo para práticas consagradas de engenharia de software, como o Teste, por exemplo.
Mas por que isso acontece?
Os agilistas jogarão a culpa na Equipe. É sempre o Desenvolvedor, que não sabe trabalhar, ou o Analista de Requisitos, que não se adapta a um Time Ágil. Jamais admitirão as falhas estruturais do SKPP (Scrum+Kanban+PlanningPoker).
Vamos começar pelo PlanningPoker... Você já viu algo mais sem noção do que isso? Na verdade, o PP (PlanningPoker) foi utilizado para DESEMPATAR estimativas baseadas em "feeling", em equipes MUITO EXPERIENTES. Com quatro ou cinco pessoas, experientes na tecnologia e no modelo de negócios, é fácil estimar com base em sentimento. Mas, ocasionalmente, podem ocorrer divergências, e um desenvolvedor pode acabar sendo influenciado pelo sentimento de outro. Isto se chama "viés". O PP serve para obter sentimentos sem "viés" dos programadores. Não é, nunca foi e jamais será uma técnica de estimativa de tamanho de backlog.
Os itens de backlog simples, em uma equipe experiente, são bem fáceis de estimar com base em sentimento. No mínimo, é possível pensar em itens implementados anteriormente e fazer uma extrapolação. Mas, quando temos histórias realmente grandes, o processo se complica. Ninguém se entende, e não existe objetividade a ser discutida, logo, há um jogo de empurra entre desenvolvedores, P.Os. E Scrum Master.
E sempre ganha o mais forte, logo, o desenvolvedor acaba "engolindo" tarefas, para as quais sente que são grande demais para o tamanho do Sprint, gerando nervosismo e ansiedade.
Para piorar, esses pontos obtidos de PP (PlanningPoker) carecem de qualquer fundamento teórico e não podem ser utilizados para efeitos de cálculo de produtividade. Pelo menos não podem ser utilizados de maneira séria.
E o "Kanban"? Cara, essa é a coisa mais idiota que eu já vi. Os agilistas dirão que serve para "dar visibilidade" ao trabalho. Mas a visibilidade que eles mostram é o caminho florido, com tudo correndo muito bem. E, como não mostram os espinhos, acabam deixando os desenvolvedores em maus lençóis... "Fulano, você já está há dois dias nessa tarefa e ainda não terminou?"
Kanbans não mostram algumas coisas importantíssimas, como:
- Interdependência entre atividades;
- Impedimentos e problemas;
- Disponibilidade de recursos.
Finalmente, o Scrum... Em seus fundamentos, o Scrum vai CONTRA o manifesto ágil, pois privilegia o PROCESSO em vez do PRODUTO. Tanto é, que exige um "Scrum Master", para garantir que o PROCESSO seja seguido. Não é isso?
Ao gerenciar o escopo e o prazo com Sprints, ele acaba criando um baita problema, que é: "Como dividir os requisitos para caberem nos Sprints?" A bem da verdade, o Scrum é apenas uma filosofia de trabalho em equipe, e não prescreve as técnicas que devam ser utilizadas nas várias etapas, como por exemplo, a coleta e registro de requisitos.
Outro grave problema do SKPP é a carência de Análise e Projeto. Não se modela mais nada! Parte-se das histórias para implementação, sem pensar em problemas e decisões de projeto. O que importa é entregar e não perder tempo com coisas que não agreguem valor.
Ora, meu caro, você está exagerando...
Será? Pode até ser. Mas a verdade é que eu tenho vivido isso e discutido com várias pessoas que pensam da mesma maneira, tanto no Brasil como no exterior. Meus artigos críticos aos "métodos ágeis" são lidos e curtidos no mundo inteiro.
O uso de SKPP (Scrum+Kanban+PlanningPoker) pode até dar certo, reservadas as contraindicações. Na verdade, este tipo de processo costuma funcionar na primeira vez em que é utilizado, pois, como é novidade, as contraindicações não estão presentes. O problema é repetir a mesma solução em problemas diferentes, e aí os problemas se agravam.
Você pode ser "ágil" sem depender exclusivamente de SKPP! Existem outras técnicas e métodos ágeis, que você pode considerar. Por que limitar o cardápio de soluções?
Nenhum comentário:
Postar um comentário