Fork me on GitHub

Keep Learning Conhecimento nunca é o bastante

Postado em
20 July 2009 @ 15:44

Tag(s)
Agile, Desenvolvimento, Opinião

Como falhar com métodos ágeis

É comum vermos guias de como fazer algo da maneira correta. A meu ver, muitas vezes, um guia de como fazer tudo errado acaba sendo mais últil, pois mostra o outro lado da moeda e acaba servindo melhor de indicador de sucesso (ou falta de).

Dada alguma experiência que possuo com métodos ágeis, aqui vai um guia 100% garantido de como falhar utilizando-os. Todas as recomendações foram vistas em prática e são ótimas receitas para o fracasso, ainda mais quando utilizadas em conjunto:

  • Não utilize equipes multi-funcionais
    Separe os membros em equipes de Criação, Desenvolvimento, Infra-estrutura e várias outras, assim como setores em grandes empresas. Mantenha-os distantes, de preferência em salas separadas, dificultando a comunicação (o pilar central dos métodos ágeis) ao máximo – sabemos que basta ficar em mesas separadas para que as pessoas se comuniquem apenas via e-mail, quando muito. Crie processos para que as equipes façam requisições umas às outras, faça com que isso seja demorado: com isso você desestimula qualquer resquício de colaboração.
  • Espere até o final da iteração para avaliar as histórias
    Crie um processo de QA intrincado e lento. Faça com que a avaliação das histórias fique para o último dia da iteração – desta forma, se uma história não for aprovada, não haverá tempo para correção, garantindo assim mais um passo rumo ao fracasso.
  • Não abrace a mudança
    Crie processos burocráticos com várias etapas, dificulte a resposta rápida e limite os profissionais o mais que puder. Deixe o caos reinar sob a desculpa de que não fará micro-gerenciamento quando, na verdade, não há gerenciamento nenhum. Não escute o que a equipe tem a dizer, esse bando de programadores, designers e administradores de sistemas não tem experiência com gerenciamento de verdade e não sabe o que está dizendo.
  • Centralize o controle e as (in)decisões
    Crie comitês para qualquer problema, dos mais simples aos mais complexos. Responsabilize uma pessoa pelo controle de cada comitê, que deve fazer inúmeras reuniões, coletar muita informação e repassar ao responsável. Esse tem a tarefa de levar toda a informação ao “chefe” que, por sua vez, não decidirá nada e criará mais comitês. Dessa forma você garante que nenhuma decisão será tomada e todos os problemas se arrastarão até que se combinem no caos completo.
  • Utilize “Agile by the book”
    Leia vários livros sobre Extreme Programming, Scrum, Lean e o que mais estiver na moda. Adote todos os processos do jeito que são descritos – o que, num primeiro momento, é bom, já que não há experiência. No entanto, recuse-se a modificar qualquer detalhe, mesmo que as coisas não estejam funcionando e que a experiência adquirida pela equipe aponte em uma direção diferente. Sempre refute qualquer argumentação com uma citação ao estilo “Ken Schwaber diz que…” (vale qualquer nome “de peso”), afinal Ken Schwaber está trabalhando junto à equipe todos os dias e conhece suas necessidades, correto?

Este é um trabalho em progresso. Quais práticas você adicionaria ao guia?


6 Comentários

Comentário por
Diego Carrion
20 July 2009 @ 16:14

Não escute às pessoas 🙂


Comentário por
Henrique Bastos
20 July 2009 @ 16:59

Continuando a lista para falhar:

“Use a dedução, mais que a observação!”


Comentário por
Bruno Dulcetti
20 July 2009 @ 19:29

Muito boa a abordadem. Exatamente isso para fracassar com qualquer equipe, tanto pequenas quanto as maiores.

Uma que eu acho que acontece muito é Criar o design do projeto sem estar focado no Agile. Muitos designers (quase todos) criam pensando em UX somente e esquecem da Agilidade, ao invés de pensarem algo como Agile UX.


Comentário por
PotHix
21 July 2009 @ 9:48

Æ!!

Muito legal cara! Acho que mostrou muita coisa que realmente *Não* deve ser feita, e assim talvez alguns entendam melhor, por que se colocar as coisas que devem ser feitas isso vai violar a ultima coisa ( todo mundo vai seguir o que vc escreveu…hahah ).

Há braços


Comentário por
Willian Fernandes
21 July 2009 @ 11:15

O que mais me importo para fracassar é:

Contrate apenas amigos, principalmente aqueles que nunca trabalharam com nenhuma tecnologia e/ou ferramentas próximas a que a empresa usa.
E mesmo assim não dê treinamento para essas pessoas, afinal, ta na web, elas aprendem! E se não aprenderem, é mais um motivo para se criar um comitê e discutir o problema…


Comentário por
Alessandro Martins
2 August 2009 @ 18:41

Você é o dono do seu tempo. Prometo tudo aos clientes sem consultar programadores e analistas. Afinal, o que eles sabem sobre gerenciamento de tempo? Tudo pode ser entregue em apenas “dois palitos” de tempos. Depois, se houver algum atraso, a culpa será dos desenvolvedores que não se dedicaram o suficiente para um prazo mais que suficiente ao seu ver.


Deixe um comentário