Quando cunhei esse termo por volta de 2 anos atrás, o fiz pelo fato de ter observado a migração serelepe dos defensores do modelo “PMBOK de ser” para Scrum.
Um grande problema na compreensão sobre Scrum é justamente achar que ele serve para gerenciar projetos, dessa forma para ser confundido com um PMBOK ágil é um passo. Gerência de projetos é um campo distinto da direção do desenvolvimento de software e não vou tratar ou especificar nesse artigo porque já rascunhei em artigo passado.
Scrum é um modelo de desenvolvimento de software. A Scrum Alliance que é uma espécie de “organismo” que rege a maturação do Scrum, não o definiu como Project Management, mas como:
Scrum é similar ao XP ou FDD, guia a equipe com um modelo baseado em práticas para um melhor desenvolvimento de software. Como esse pessoal – que muitas vezes nunca foram técnicos – encontra em Scrum práticas fortemente ligadas ao controle das iterações, transmuta toda a cultura burocrática adquirida em metodologias de gerência de projetos e confunde atividades – como avaliação de riscos e aquisição e controle de recursos – com as necessidades do time jogando fora o que os incomoda – como práticas necessárias ao desenvolvimento – e ficando apenas com o que sentem confortáveis.
Quando James Shore escreveu seu famoso artigo “The Decline and Fall of Agile” ele definiu isso muito bem fazendo analogia que estavam correndo para a sobremesa mas jogando fora os vegetais. Martin Fowler em seu artigo Flaccid Scrum [Akita traduziu e comentou], escreveu ter notado que o problema técnico acontece mais com Scrum devido a não prescrição [omite] de práticas técnicas e ser centrado em técnicas de “gerenciamento de projetos”, ou seja, o problema é de qualidade técnica interna.
Hoje todo mundo se diz Scrum Master, todos entendem e usam Scrum e mesmo assim já estamos vendo projetos com Scrum caírem no mesmo erro e problema de modelos anteriores. Como disse o Martin Fowler em seu artigo: “Esses projetos de Scrum flácido em andamento prejudicarão a reputação não somente do Scrum mas de todo Agile”.
Scrum é uma metodologia maravilhosa que tem muito a engrandecer o XP e as outras metodologias, mas usando um Scrum transviado de PMBOK é um caminho natural ao fracasso retumbante.
Solução?
Eu poderia escrever dezenas de linhas aqui com conselhos e bla-bla-blas mas vou ser direto e lacônico: XP.
Categories: Engenharia de Software, Metodologia, Métodos Ágeis, Scrum ~ ~ Trackback
OPML Completo.
Texto Completo
March 14th, 2009 at 12:13 pm
um idiota anônimo comentou aqui, pwned!
March 14th, 2009 at 1:15 pm
Muito interesante o post. Isso mesmo acontece com quem teve pouco contato com tecnologias ágeis. Já vivi os dois mundos não sou nenhum expecialista mas busco o conhecimento de boas práticas, então vou ficar esperando o próximo post sobre a sua resposta: XP… Sei como RUP gerencia projetos, mas adoraria ver mais posts sobre gerência de projetos com métodos ágeis.
Muito bem escrito.
Abração Milfont.
March 16th, 2009 at 2:33 pm
Caro Milfont, muito bom seu post. Gostaria apenas de colocar algumas coisas.
Realmente Scrum não é um método ágil de gerenciamento de projetos, porém o mesmo é aplicado a algumas fases do gerenciamento, o que fez ou o tornou alvo de tanta “confusão”, como fala o Diego Pacheco aqui (http://diego-pacheco.blogspot.com/2008/05/scrum-no-subistitui-gerenciamento-de.html). A sua forma ágil que disciplina a equipe, facilita a gerência e compromete o desenvolvedor (ou qualquer outro) com a sua tarefa, uma vez que o mesmo participou da estimativa da mesma.
Fazendo um relaxo com o PMBOK, podemos dizer que os processos de Planejamento, Execução e Controle se fazem candidatos ao uso de Scrum nessas fazes, porém apenas o Scrum não vai cobrir todos os três.
Concluindo, você está correto quando fala que não é um método de gerenciamento de software, porém pega um pouco pesado quando afirma que “Scrum transviado de PMBOK é um caminho natural ao fracasso retumbante”.
Abraços, e excelentes posts.
June 17th, 2010 at 8:46 am
[...] Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se [...]
July 12th, 2010 at 6:18 am
[...] Separar gerenciamento de projetos do processo de desenvolvimento Pmbok de Jeans http://www.milfont.org/tech/2009/03/14/pmbok-de-jeans/ [...]