Uma questão recorrente que leio em listas e outros blogs é sobre a necessidade ou não de adotar as práticas do XP quando se utiliza o SCRUM. Será que é necessário, ou isso é apenas uma birra de agilistas xiitas?
Eu tenho uma opinião um pouco diferente disso que gostaria de compartilhar com vocês.Em primeiro lugar, quem defende o NÃO tem uma razão bastante razoável para isso. O SCRUM trata do projeto, enquanto o XP trata mais de questões de engenharia. Note que muitas práticas mencionadas no SCRUM (como Planning Poker) é oriundo do XP.
Aplicar SCRUM em um ambiente onde não existe uma orientação a testes, pair programming, sprints, etc. leva normalmente ao fracasso. As pessoas continuarão produzindo seus produtos com bugs, sem testar, e o que normalmente acontece é a perda da fé no processo (por todos envolvidos, seja equipe, gerente/scrum master, cliente, sponsor). Uma das premissas principais do SCRUM é o “software entregue”. E isso significa sem bugs, testado, “in a box”.
Sim, há situações onde a equipe estará produzindo um release (software pronto) ou um releasable (um módulo que não poderá ser entregue ainda).
Os que defendem que sim, pode-se usar o SCRUM dizem que essas questões técnicas irão emergir durante o processo. Aos poucos todos perceberão que pair programming, TDD (test driven development) e afins são importantes e correrão atrás. São aqueles que confiam muito num dos pré-requisitos de qualquer método ágil: coragem. Ninguém ficará acomodado sem pensar em melhorar sempre.
Minha opinião é bem próxima aos que defendem que sim, mas minha justificativa é bem diferente.
A popularização do SCRUM não me assusta, sinceramente. Desde que ele seja visto com todos os valores que o rodeiam. Conheci empresas que diziam de boca cheia que tinham SCRUM, mas não praticavam UM VALOR SEQUER dos pré-requisitos. Isso é que deve ser combatido.
Os valores ágeis, bem como os seus princípios, já causam uma revolução enorme dentro da empresa. Se incorporado da forma correta, o ambiente se torna colaborativo, os problemas de comunicação são minimizados a quase zero, o clima organizacional tende a crescer, a retenção de talentos se torna mais natural e, principalmente, todos os processos internos começam a se tornar mais transparentes. É o fim da “setorização”, um dos principais problemas que resultam em conflitos nas empresas.
A popularização do SCRUM tende a popularizar estes valores também. Sim, eu acredito nisso. Pois ninguém conseguirá explicar o simples processo do SCRUM (aí está outro ponto extremamente positivo – a simplicidade) sem defender no mínimo os quatro valores principais do manifesto ágil.
:: Pessoas e comunicações são mais importantes do que processos e ferramentas
:: Software entregue e funcional é mais importante do que documentação extensiva
:: Colaboração do cliente é mais importante do que negociação de contrato
:: Responder às mudanças é mais importante do que seguir o plano
Note, só um destes itens aborda mais o aspecto técnico (software entregue). Os três demais são essencialmente comportamentais.
E daí voltamos àquela velha questão sobre as competências, o chamado C . H . A .
C – conhecimento : capacidade de adquirir conhecimento
H – habilidade : capacidade de transformar o conhecimento em prática
A – atitude : capacidade de pôr em prática
Empresas que não atuam no âmbito ágil, costumam ter um foco no CH. Possuem ótimos técnicos, excelentes gestores, grandes CEO’s, CFO’s, etc. mas confiança, transparência e colaboração não são a palavra da ordem.
Empresas que adotam os valores ágeis, dão o foco no A. Querem pessoas que sim, tenham conhecimentos e habilidades, mas que tenham, principalmente, atitude! Pois são estas pessoas que fazem a diferença nas organizações. E quando conseguem trabalhar com confiança, transparência e colaboração, potencializam demais os resultados.
Sim, o SCRUM do jeito que vem sido apresentado por alguns pode ser problemático. Mas por outro lado, querendo ou não, eles estão apresentando valores modernos para empresas que atuam no modelo fordista ou taylorista.
Minha opinião se SCRUM funciona sem XP? Como um processo a ser praticado corretamente, não. Como um agente de mudança cultural, sem dúvida. E, algumas vezes, só isso já basta.
Um abraço!
Loading ...
Pô achei bem legal o seu artigo, apesar de que acho que cada caso é um caso.
Existem empresas que sim, conseguem se sair bem usando apenas algumas práticas do Xp do se sairiam usando todas.
Porém acho válido sempre testar antes de dizer que determinada prática não funciona.
Flavio,
Muito bom seu artigo. A grande questão é combater o radicalismo e aplicar o melhor em cada caso.
Aqui nos damos bem aplicando o Scrum sem o uso do XP. Na verdade, até o utilizamos, mas em situações muito específicas.
Grande abraço,
Flavio
Eu acredito que Scrum pode funcionar sem XP.
A experiência de várias pessoas/empresas mostra que funciona muito melhor.
A grande questão, além do que tu mostrou no texto, é que é muito mais fácil conseguir implementar as práticas do Scrum do que do XP.
Desenvolvedores não suportam testar. Isso é muito complicado para conseguir colocar na cabeça deles. É fácil mostrar a importância disso, eles acham bacana, mas na hora de colocar a mão na massa, desenvolvedor não quer testar, tem uma resistência tremenda em relação a isso.
E como uma das condições básicas para se ter XP é ter desenvolvimento guiado a testes, dificulta muito a implementação disso.
Outra questão é a programação em pares. É dificil acostumar a trabalhar dessa forma. O cara não tem mais o controle total do PC dele, se quer dar uma relaxa, ler uma noticias ou emails, fica na dependencia do outro ou fica meio cabrero de sair e deixar o outro ali, sozinho. Eles nao se sentem a vontade.
(Fugindo um pouco do raciocínio… Alguem falou no Agiles2009 – talvez o Brian Marick, nao lembro – uma coisa muito bacana… muita gente não gosta de pair programming pelo fato de não poder fazer suas gambiarras… tem que pensar mais antes de fazer, o codigo tem que ficar bom… isso deveria ser uma pratica independente de pair programming, mas nao é assim que funciona)
São duas questões fundamentais para XP e que são muito dificeis de serem implementadas em equipes sem essa mentalidade. É uma mudança de cultura significativa.
Já o Scrum não afeta diretamente as atividades do pessoal. O cara continua com seu computador, continua desenvolvendo sem testar como deveria, mas pratica Scrum sem problemas.
Bom artigo.
Mas eu sou mais radical (ok, um xiita): acredito que a XP deve ser aplicada independente do processo (seja SCRUM, RUP e etc).
Não cheguei a trabalhar em mais de uma empresa, mas pela minha experiência e comentários de colegas, nós negligenciamos a qualidade do projeto. Digo código limpo, bem testado, documentado e versionado – coisas básicas. Em resumo, a mantebilidade é baixa.
Fora que dificilmente vemos outras áreas como IHC exploradas. Não saímos muito do arroz com feijão.
Gostei muito do artigo. Segue um link para um artigo do Martin Fowler traduzido que trata bem esta questão da necessidade de qualidade técnica para o bom funcionamento do Scrum.
http://www.akitaonrails.com/2009/02/03/tradu-o-scrum-fl-cido
Excelente artigo,
Concordo plenamente com sua exposição no sentido de que o Scrum pode e deve ser usado como agente de mudança cultural, a grande maioria das nossas empresas de tecnologia, principalmente as mais antigas, precisa e muito de uma “sacudida” nos seus processos e vejo o Scrum como uma ferramenta mais que perfeita pra isso.
Flávio, você continua mudando uma pequena empresa, agora mostrando o caminho.
Na comparação que vc fez sobre o CHA a questão não deveria ser orientada pelos métodos ágeis em si, mas como vc colocou, pelos valores ágeis. A confusão quanto ao CHA existe dentro de uma empresa com ou sem métodos. Portanto, o cenário é muito mais caótico e conflitante. E se torna pior quando a empresa enxerga o método e não a cultura que precisa para adotar o método. Quero dizer que o empreendedor precisa respeitar antes de tudo a cultura do método, para depois tentar aprendê-lo.