O desenvolvimento de software é conhecido por ser um processo criativo. A falha dos métodos tradicionais, onde o ambiente dinâmico da programação era ignorado, tornaram os métodos ágeis muito populares. Atualmente há uma crescente adoção das metodologias ágeis, particularmente Scrum. Entretanto, tudo corre bem com métodos ágeis? Kai Glib não acha isso. Ele indica que há sérios problemas com eles.
Kai diz que apesar de toda a glória do Ágil, existem algumas falhas sérias,
A maior parte dos agilistas falam sobre suas vantagens, aqui eu escreverei sobre os problemas: problemas que são tão sérios, que se não forem resolvidos irão garantir que o seu método Agile favorito vai se tornar moda do ano passado.
Kai menciona que o foco do Ágil e Scrum está errado. Eles não estão preocupados em entregar valores de negócios para o usuário final. Ele afirma que todas as idéias no manifesto ágil são soluções para o que é 'conveniente aos desenvolvedores'. O manifesto está fortemente voltado para desenvolvedores. Ele não fala nada sobre os stakeholders. Kai diz que com base no diagrama das atividades padrões do Scrum, não há nada que agregue valor aos stakeholders.
Além disso, segundo ele, o Ágil foca muito em software de trabalho, que é considerada a maior prioridade, enquanto que agregar valor de negócio aos interessados fica, no máximo, em segundo plano.
Então eles juntaram isso com alguns outros principios. Isso está crescendo, mas num segundo plano. Isso precisa ser prioritário, provavelmente sozinho, e mais bem formulado, não misturando a meta e a solução.
Kai salienta o seguinte:
Isso não é sobre software de trabalho. Não é sobre sua prática favorita. Não é sobre histórias. Não é apenas sobre o seu cliente ou usuário. Isso é sobre entregar, para o grupo de interessados, melhorias de valor, que sejam interessantes, que façam seus mundos melhores.
Comentando sobre o assunto, pschwarz diz que XP adiciona valor de negócio ao ciclo de vida. De acordo com ele,
O valor do negócio depende do que você quer, quando você quer e o quanto isso custa. Para decidir o que fazer, e quando, os clentes precisam saber o custo daquilo que eles querem. Os programadores, experientes, fornecem essa informação. Então os clientes decidem o que eles querem, e os programadores fazem. O processo se parece com isso
- Cliente: define o valor
- Programador: estima o custo
- Cliente: escolhe o valor
- Programador: constroi o que foi escolhido
- Reincia-se o ciclo
A cada vez que nós percorremos esse ciclo, nós aprendemos. Clientes aprendem o quão valorosa as suas features realmente são, enquanto programadores aprendem o quão difícil essas features realmente são.
Kai retruca sugerindo que mesmo isso não adiciona valor ao usuário final, dado que isso está claramante sob a visão do programador. Ele afirma que a menos que os desenvolvedores foquem em valor, e não features, o ciclo de vida deveria existir apenas com o intuito de agregar valor.
Além disso, menciona que os "baby steps" do Ágil mata a criatividade do desenvolvedor. Ele diz que o Ágil não dá espaço aos desenvolvedores para serem criativos dado que foca em soluções e não funcionalidades. Complementa que ninguém do Ágil pode produzir um produto competitivo. Diz,
Scrum é praticado como uma grande lista corporativa de coisas a fazer. Por não focar nos críticos "quão melhor" atributos do sistema, Scrum está reduzindo os "SW DEVELOPMENT" a tarefas, sem a necessidade de desenvolvedores com habilidades criativas. Aos programadores é dito o que codar, ao invés de qual a melhor forma de satisfazer as qualidades de um produto.Há pouco ou nenhum conhecimento de como criar um produto competitivo. Pelo contrário, o oposto está acontecendo, exigindo "soluções" (feito por amadores (usuários), não arquitetos), mais opções competitivas que são sistematicamente censuradas.Essa prática de "baby talk" torna os populares métodos Ágeis inúteis a qualquer um que queira criar sistemas competitivos, que requerem alto valor, e para as empresas.
Kai dá um exemplo sobre como muitos times Ágeis trabalham com as histórias. 'Como um comprador, eu quero colocar um livro no carrinho de compras'. Segundo ele, o usuário está completamente errado.
O quê está errado? Tudo está errado! Dê-me um segundo.
De acordo com Kai, a criatividade do desenvolvedor e o entusiasmo para construir um produto digno foram tirados dessa história, dado que nesse caso ela não propõe uma função, mas sim uma solução a ser implementada.
A função crua é 'comprar um livro'. Uma forma específica para fazer a compra acontecer, como "carrinho de compras" restringirá as opções para o desenvolvedor encontrar uma solução, isso fará a função "comprar livro" ter melhor qualidade e performance.
Ele diz que as histórias perderam completamente o campo "Quão melhor" para o desenvolvedor. "Quão melhor" a funcionalidade deveria ser melhor que a do concorrente, "Quão melhor" ela deveria ser do que a do sistema que a está substituindo, quão pode ser melhor que a UI sugerida para ser mais amigável. Kai sugeriu que com a atual abordagem feita pelo Ágil e Scrum, os desenvolvedores são apenas pedreiros que recebem ordens sobre o que devem fazer.
O poderoso framework Scrum está reduzido a uma grande lista cooperativa de coisas a fazer que diz aos desenvolvedores o que fazer, e você programador apenas deve cumpri-la.
Siga a série, onde Kai se propõe a revelar as mais sérias falhas nos dias atuais. E você, leitor, o quê acha sobre essas falhas específicas do Ágil e Scrum apontadas por Kai?