Os pragmáticos venceram? A norma é o Water-Scrum-Fall
O Water-Scrum-Fall ("Cascata-Scrum") seria a forma de adoção do Scrum atualmente mais comum nas organizações, de acordo com Dave West, diretor de Pesquisas e Vice-Presidente da Forrester. Dave escreveu sobre a análise da Forrester em um artigo recente da SD Times.
As organizações estão adotando cada vez mais as metodologias ágeis de desenvolvimento de software, através da combinação de uma adoção de baixo para cima e mudanças nos níveis estratégicos. Entretanto, a realidade na adoção do Agile tem divergido das ideias originais descritas no Manifesto Ágil, assemelhando-se muito ao que a Forrester tem chamado de Water-Scrum-Fall.
Segundo a Forrester, isso ocorre porque a adoção do Agile é geralmente conduzida por profissionais técnicos e estes se concentram no domínio com o qual estão mais familiarizados, o que, na maioria dos casos, significa desenvolvimento de software. Logo, áreas como gerenciamento de releases ou planejamento de projetos ainda são tratadas através de métodos tradicionais.
O artigo busca então elucidar o termo Water-Scrum-Fall:
Water - Define o processo de planejamento inicial do projeto que ocorre comumente entre o setor de TI e o negócio.
Scrum - Uma abordagem iterativa e adaptativa para realizar o plano geral que foi gerado da fase anterior ("Water").
Fall - Um ciclo de lançamentos controlados e pouco frequentes, que é regido por políticas organizacionais e limitações de infraestrutura.
O artigo também fornece dicas às equipes de desenvolvimento que estão enfrentando a realidade do Water-Scrum-Fall e buscam maior agilidade. Dentre as dicas citadas:
- Uma equipe Scrum devidamente preparada deve incluir todas as pessoas necessárias para a entrega de software funcional. Isso significa, basicamente, desenvolvedores, analistas de teste e analistas de negócio trabalhando em prol de um objetivo comum.
- Os desenvolvedores devem contestar o status quo de implantações pouco frequentes em produção e impulsionar a criação de melhores processos e práticas de liberação de releases dentro da equipe.
- Gastar muito tempo em detalhes no início do projeto não irá aumentar a qualidade da release; ao contrário, é um desperdício.
- Documentos são meios pouco eficazes para gerar software funcional. Além disso, todo documento criado deve conter somente o suficiente para apresentar o contexto do problema e permitir um planejamento de alto nível para que o trabalho de desenvolvimento comece.
No post de Mike Dwyer, de junho de 2011, no blog Big Visible, Dwyer argumenta que a comunidade Scrum pode ser dividida em três grandes grupos: os puristas, os arrogantes e os pragmáticos.
Será que as equipes Water-Scrum-Fall começam no grupo dos arrogantes e depois se tornam puristas, ou seria o Water-Scrum-Fall a essência de ser pragmático? O que você acha?
Pragmáticos, sem dúvida!
by
Ivan Almeida
Pragmáticos (Realistas), sem dúvida!
by
Ueide Santos
Mas o que está ocorrendo é que, assim como o RUP, o Srum está sendo mal entendido.
Ou melhor, não estamos sabendo onde e como utilizar Srcum.
E o mais importante, como COMPLEMENTAR o Scrum.
Scrum não diz como será sua gestão de configuração, você terá que implementar a seu modo.
Scrum não diz como será sua gestão de requisitos, qualidade, sub-contratados.
O Scrum é Framework, como você fará acima desta camada é escolha sua.
Caso você “implemente” RUP ao pé da letra, os problemas não acabarão. O mesmo acontece com Scrum, XP, WF, FDD, BDD, PSDB, PMDB, PT... WHATEVER!
Vou piorar, os problemas aumentarão. Pois todos os problemas que estavam debaixo do tapete serão jogados no ventilador.
Há cenários que podemos utilizar pura e simplesmente Scrum. Mas há cenários que não.
Em uma reunião de uma multinacional com um executivo m.f., um profissional não pode simplesmente dizer que não sabe quanto irá custar o projeto e/ou que não tem nem ideia de tempo. Este será demitido em “runtime” (minhas raízes de programador), e provavelmente o superior deste também ou ficará na corda bamba.
É inevitável que todos que trabalham construindo software, tenham nascido em Ti construindo software (PMP's recém-certificados que nunca trabalharam construindo software, ESQUEÇAM!).
O segredo está em, conhecer muito sobre engenharia de software (inevitável) e saber COMO, QUANDO e ONDE utilizar a sopa de letrinhas acima.
Essa é a minha opinião.
Falei d +.
À disposição para críticas, sugestões ou ameaças... rs
E tenho dito!
Ueide Santos - @usjunior
about.me/usjunior
Conteúdo educacional
Lean na Globo.com
Bernardo Heynemann 24 Mai, 2013
Mobilidade: Frameworks, SOs e o Mercado
Ricardo Ogliari 23 Mai, 2013
Caminhos de uma estratégia mobile
Sérgio Lopes 23 Mai, 2013
Complexidade organizacional no Século 21
Alexandre Magno 16 Mai, 2013

Olá visitante
Você precisa cadastrar-se no InfoQ Brasil ou Login para enviar comentários. Há muitas vantagens em se cadastrar.Obtenha o máximo da experiência do InfoQ Brasil.
Dê sua opinião