Em seu artigo, Mayer escreveu:
...who (or what) is the Scrum Alliance? There is no leadership, no guidance. There is no purpose, no vision, no direction. The SA appears to exist to certify new trainers who will teach more CSM classes so the membership grows, and the demand for more CSM classes grows, so more trainers can be certified, and so on ad infinitum. Each trainer, each certification adds more money to the SA bank account. And I don’t see where anything is being given back to the community. ...Com isso, as cartas foram colocadas na mesa. A maioria dos agilistas brasileiros que conheço são contra certificações, pois afirmam ser uma máquina de dinheiro e que, na verdade, não certificam nada, pois não colocam o candidato para pensar, fazendo com que seja necessário "apenas" decorar e conhecer algumas regras, exatamente como nossos vestibulares e concursos públicos. Claro que existem exceções, mas esta parece ser a regra. Compartilho desta opinião.
E o artigo do Uncle Bob vai exatamente nesta direção. Ele diz que em meados dos anos 90, o processo chamado waterfall dominava o mundo do desenvolvimento. A engenharia de software era definida pelo waterfall e pela gama de documentação de análise e desenho. Código era detalhe.
Com isto, foi formada uma elite de engenheiros, arquitetos e analistas de sistema que eram responsáveis pela engenharia "real", satisfazendo as duas primeiras fases do waterfall.
No Scrum, o time manda. O "elitismo" do waterfall havia sido atacado. Nem Scrum ou o XP (eXtreme Programming) tinham papeis para cargos de autoridade sem responsabilidade. No Scrum, o poder do time é maior que o poder do arquiteto. Contribuições são bem vindas, mas não necessariamente seguidas.
Uncle Bob segue explicando que no Scrum, existe a figura do coach. A responsabilidade desse cara é defender o processo. Ele deve lembrar todos de seu comprometimento. Quando o cronograma escorrega e o cliente está chateado, é responsabilidade do coach lembrar o time de que será possível voltar ao cronograma e tranquilizar o cliente mantendo a disciplina. No Scrum esse é o papel do Scrum Master. O coach tem a responsabilidade de lembrar e não de comandar.
O problema, segundo Uncle Bob, foi a criação do CSM (Certified Scrum Master). Lembrando que o ideal é o SM emergir do próprio time, disse que na prática, os CSMs já possuem um background gerencial e, em essencia, adicionaram o CSM ao PMBOK.
O problema, na verdade, está onde quase todas as certificações falham: como em um passe de mágica, um CSM já será capaz de gerenciar um time Scrum. Ele tem autoridade para gerenciar times Scrum. E isso vai de contra o real significado do papel do SM, que deveria ser o de um "gentle reminder" do processo e da disciplina.
Um verdadeiro coach no XP não gerencia o processo. Na verdade, esse papel torna-se opcional, quando a equipe já amadureceu o suficiente para não depender mais de lembranças.
O problema do Scrum, segundo Bob, é que o papel do SM se tornou tão importante que passou a ser necessário uma certificação. Se o seu time não tem um Certified Scrum Master, provavelmente tem alguma coisa errada com você.
Isso é muito grave pois, em primeiro lugar, arrumaram mais uma máquina de dinheiro. E ainda mais grave pois, para conseguir fazer a máquina gerar mais dinheiro, elevaram a importância de um papel que deveria ser opcional.
Concordo com quase todo o texto. Só não concordo com a conclusão, onde Uncle Bob diz que isso pode ameaçar o movimento ágil. Acredito que o movimento é mais forte que a Scrum Alliance e até mais forte que o próprio Scrum. Acredito que suas técnicas, principalmente as de desenvolvimento, como o TDD e integração contínua, vieram para ficar. Se a metodologia que você está adotando está entregando rapidamente mais valor de qualidade para o cliente, pouco importa o nome que ela tem.
http://cleancoder.posterous.com/what-killed-waterfall-could-kill-agile
Respondendo a pergunta do titulo, não acho que a exigencia das certificações pode tornar o elitismo regra nas metodologias ágeis. Acredito que as empresas irão notar o erro e voltar suas atenções novamente para o ROI.
ResponderExcluirA mesa Redonda aqui em Fortaleza te fez refletir bastante coisa eim? :)
ResponderExcluirExcelente o post!!
Agora tira uma dúvida:
"Se a metodologia que você está adotando está entregando rapidamente mais valor de qualidade para o cliente, pouco importa o nome que ela tem."
E se essa metodologia for WATERFALL?
Abraço!!
Se ela está entregando valor de QUALIDADE rapidamente? Pouco importa. Lembre-se que qualidade não é "funcionando".
ResponderExcluirO problema é que o waterfall é naturalmente contra duas palavras: qualidade e rapidamente.
Sem o cliente presente, podendo priorizar e despriorizar, é dificil até de garantir a correção, quanto mais os outros princípios da qualidade de software.
Sem ciclos curtos, que tem como objetivo entregar software funcionando a cada iteração, você não tem "rapidamente".
Por isso acho que as "grandes" fases do waterfall dificultam muito a entrega de valor de qualidade rapidamente para o cliente.
Além disso temos as práticas como o próprio TDD que não costuma ser adotado pelos "cascateiros".
Abraços
Não tinha visto o comentário sobre a mesa redonda no Maré Fortaleza. =)
ResponderExcluirMas é verdade, ajudou bastante ver tanta gente boa discutindo em alto nível.
Abraços
Belo post, mas discordo completamente do seu comentário sobre waterfall.
ResponderExcluirCada cliente, cada projeto, cada equipe tem a sua realidade. Scrum ou qualquer outra metodologia ágil pode ser uma maravilha onde o waterfall falha, porém, waterfall pode ser a tábua de salvação em projetos onde o agile não daria nem pra saída.
Acho que temos que nos libertar do pensamento Flamengo x Vasco, onde um é bom e outro é ruim.
@Cotta,
ResponderExcluirPois é, foi o que falei pro Matheus e, na verdade, disse que se o waterfall está agregando valor, ok, sem problemas.
Só acho difícil uma metodologia com grandes fases e que, uma vez na fase seguinte não é permitido voltar a fase anterior, que fecha a equipe de desenvolvimento em uma caixa preta, que é completamente reativa a mudanças, agregar tanto valor rapidamente quanto os valores das metodologias ágeis permitem.
Mas pode acontecer. Pode ter cliente que diga: cara, ok, posso ter módulos do meu sistema FUNCIONANDO de 2 em 2 semanas (ou 30 em 30 dias), posso estar sempre validando, desde o início do processo, se o caminho está correto, mas não quero isso não. Quero minha aplicação daqui a 8 meses, mesmo que esteja tudo errado e não tenham implementado nada do que eu pedi.
@Cotta, na verdade você falou isso por me conhecer pessoalmente e saber que prego os métodos ágeis pelos quatro cantos da empresa (inclusive tenho o manifesto colado na baia, como você sabe). No comentário anterior, disse que o waterfall pode funcionar em algumas ocasiões. Só nunca vi como e nem porque.
As pessoas que defendem o waterfall não fornecem um exemplo de onde poderia funcionar. Não citam uma empresa, cliente, nicho sei lá. Mas dizem que funciona, mesmo com todos os projetos estourando prazos e orçamentos.
Abraços