Martin Fowler escreveu um artigo polêmico para Scrummers, mas não pode ser visto como uma crítica ao Scrum e sim como uma crítica a quem aplica Scrum da maneira errada e a quem não se preocupa em tornar isso aparente. A seguir a tradução na íntegra do artigo.

Scrum Flácido

por Martin Fowler
Janeiro 29, 2009

Existe uma bagunça que ouço em muitos projetos recentemente. Funciona assim:

– Querem usar um processo ágil, escolhem Scrum
– Adotam as práticas Scrum, e talvez até os princípios
– Depois de algum tempo, o progresso é lento, porque a base de código é uma bagunça

O que acontece é que eles não prestaram atenção à qualidade interna de seu software. Se você cometer esse erro, irá rapidamente descobrir que seu progresso foi desacelerado, porque é muito difícil adicionar novas funcionalidades que você gostaria. Você caiu no problema de Débito Técnico e seu scrum caiu de joelhos. (E se você esteve num scrum real, saberá que isso é uma Coisa Ruim).

Mencionei Scrum, porque quando vemos esse problema, Scrum parece ser particularmente comum, como o processo nominativo que a equipe segue. Para muitas pessoas, a situação é exacerbada pelo Scrum, porque Scrum é um processo centrado em técnicas de gerenciamento de projetos e deliberadamente omite qualquer prática técnica, em contraste (por exemplo) com Extreme Programming.

Defendendo o Scrum, é importante apontar, que só porque ele não inclui nenhuma atividade técnica dentro de seu escopo, isso não deve levar ninguém a concluir que ele não acha isso importante. Sempre que ouvi Scrummers proeminentes, sempre enfatizaram que você deve ter boas práticas técnicas, para ter sucesso com um projeto Scrum. Eles não dizem quais práticas técnicas devem ser, mas você precisa delas. Afinal projetos enfrentam problemas por causa de qualidade interna pobre o tempo todo, e o fato que muitos entram abaixo da bandeira do Scrum, parece ser mais pelo fato de Scrum ser popular no momento, do que qualquer coisa particular no Scrum. Popularidade e Difusão Semântica tendem a andar juntos.

Então, o que fazer a respeito?

A comunidade Scrum precisa redobrar seus esforços, em garantir que as pessoas entendam a importância de práticas técnicas fortes. Certamente qualquer tipo de revisão de projeto deve incluir o exame de quais práticas técnicas estão presentes. Se você estiver envolvido ou conectado a esse tipo de projeto, faça barulho se o lado técnico estiver sendo negligenciado.

Se estiver apresentando Scrum, garanta que está prestando atenção às práticas técnicas. Tendemos a aplicar muitas do Extreme Programming e eles se encaixam muito bem. Os XPers costumam brincar que com alguma justificativa, Scrum é apenas XP sem as práticas técnicas que a fazem funcionar. De qualquer forma, as práticas de XP são um bom ponto para se começar – e certamente serão muito melhores do que nada.

Sempre gosto de apontar que não são metodologias que levam ao sucesso ou fracasso. Usar um processo pode ajudar uma equipe a subir no jogo, mas no fim é a equipe que importa e que carrega a responsabilidade de fazer o que funciona para elas. Estou certo que muitos dos projetos Scrum Flácidos em andamento, prejudicarão a reputação do Scrum, e provavelmente a reputação maior de Ágil. Mas já que vejo Difusão Semântica como algo inevitável, não estou desproporcionadamente alarmado. Equipes que fracassam, provavelmente vão fracassar seja lá qual metodologias elas – erradamente – apliquem. Equipes que tem sucesso, construirão suas práticas sobre boas idéias e o papel da comunidade scrum é espalhar essas boas idéias.

Muitas pessoas estão olhando para Lean como a Próxima Grande Coisa Ágil. Mas quanto mais popular lean se tornar, mais vai incorrer nos mesmos problemas que Scrum está enfrentando agora mesmo. Isso não torna Lean (ou Scrum) sem valor, apenas nos lembra que Indivíduos e Interações são mais valiosos que Processos e Ferramentas.

Trackback esse post | Subscreva os comentários pelo RSS Feed