BT

Os pragmáticos venceram? A norma é o Water-Scrum-Fall

por Christopher Goldsbury , traduzido por Rafael Buzon em 11 Jan 2012 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Pragmáticos, sem dúvida! by Ivan Almeida

Os densenvolvedores entendem o desenvolvimento de software por isso lutam para implantar as metodologias ágeis, mas esbarram em barreiras culturais e departamentais que fogem a sua alçada, fazem o que podem dentro de contexto, o importante é não desistirem pessoal...

Pragmáticos (Realistas), sem dúvida! by Ueide Santos

Sou adepto ferrenho das práticas do Framework Scrum. Utilizá-lo traz retorno SIM e rápido.
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

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT