Agile Projeto

Scrum: Mitos e Verdades

Não há planejamento de Projeto com Scrum

Mito: Muitas pessoas dizem que no Scrum, assim como em muitas outras abordagens ágeis, não há planejamento. Isso se deve em parte ao fato que, não há uma fase de planejamento prolongada, assim como há no RUP, Waterfall e outros. Verdade é que no Scrum, nós planejamos o horizonte mais curto, com ciclos que não ultrapassam 30 dias e todo o trabalho feito é revisado ao final de cada ciclo, assim como o Processo em si é revisado. Considerando que durante 01 mês, ao menos 8 horas são para planejamento da Sprint, 4 horas para revisão do Incremento de Software, 16 horas com o Grooming dos Product Backlog Items, 3 horas para retroalimentar o processo na Sprint Retrospective, sem contar nos 15 minutos diários, veremos que planejamos muito, porém em escalas menores, mas que, ao final do nosso projeto teremos planejado pelo menos 20% do tempo gasto no decorrer dos trabalhos.

Não há documentação nos projetos com Scrum

Mito: O medo de muitas organizações é que criemos softwares sem documentação, visto que não há uma fase de coleta de requisitos, modelagem, prototipação e nem construção e implantação. Verdade é que o Framework não é prescritivo, mas boas praticas de engenharia são sempre bem vindas. Evitamos sim a criação de documentação que é de difícil ou inexistente manutenção, pois acreditamos que tais agregam pouco ou quase nenhum valor ao cliente. Usar histórias de usuário já pode ser considerado uma documentação, simples, objetiva e não menos importante, testável na sua amplitude, BPMN também, embora sua manutenção não seja a mais ágil, ajuda muito no fluxo dos processos do negócio do nosso cliente.

Scrum reduz drasticamente os prazos do projeto

Mito: O Scrum irá transparecer a tendência do termino com maior assertividade, já que o próprio Product Backlog será constantemente revisado e melhorado. Uma ilusão comum é acreditar que, porque se adota Scrum, os projetos como num passe de mágica irão terminar sempre dentro do prazo estimado no início do projeto. Algo que não é incomum de ocorrer é devido à necessidade de ordenar os itens conforme valor de negócio, o cliente acaba por perceber que algumas funcionalidades agregam pouco ou nenhum valor ao Produto final e optam por não construir em sua aplicação. Com Scrum a entrega de incremento de software é antecipada, ou seja, não esperamos o final do projeto para entregar todo o trabalho para nosso cliente. Esta mudança faz com que coletemos feedback mais cedo e possíveis alterações são sempre bem vindas e fazem com que nosso software tenha mais aderência junto ao negócio do nosso cliente.

Projetos com Scrum também falham

Verdade: Assim como qualquer um, um projeto com Scrum também pode falhar, a questão é, quanto tempo eu preciso para perceber ou evidenciar que um determinado projeto tem que ser abortado. Em projetos gerenciados de forma clássica, não era incomum encontrar projetos que depois de anos de desenvolvimento e muito dinheiro gasto, percebia-se que não eram mais viáveis. Segundo o Standish Group que publica o Chaos Report, em 2011, 20% dos projetos falharam, outros 42% foram considerados desafiados (custo, prazo ou escopo alterado) e 37% foram considerados sucesso. Houve melhoria nos indicadores se comparados ao Report de 2009, mas de fato ainda estamos longe de números aceitáveis de entrega. Scrum irá te ajudar a definir metas atingíveis e trazer transparência, mas não é garantia de sucesso. Fazendo uma analogia simples, imagine se uma montadora de automóveis entregasse 37% dos veículos perfeitos, 42% faltando uma roda ou algo mais caro que o previsto e 21% de seus produtos sequer chegassem a ser entregues.

A gestão com Scrum é uma anarquia

Mito: O Scrum exige que tudo seja planejado, o time é responsável pela organização e execução do trabalho, e se compromete a realizar o melhor trabalho possível em prol a meta da Sprint. As releases são planejadas, o Product RoadMap é traçado. O Product Owner é responsável pelo ROI, já o Scrum Master é responsável pela produtividade do time de desenvolvimento, bem como remover qualquer obstáculo que possa prejudicar o time. As fases do Scrum muito se parecem com o ciclo do PDCA da administração, o processo é simples e enxuto justamente para que seja de fácil aderência. Boas práticas de engenharia, qualidade e padrões de projetos são requisitos da qualquer método ágil, e com Scrum não poderia ser diferente.

Embora as “regras do jogo” sejam simples, adotar Scrum nem sempre será uma tarefa fácil, requer disciplina, comprometimento e coragem para encarar as dificuldades e entender que superá-las irá fazer com que o time Scrum amadureça. Lembre-se antes do Scrum ou qualquer outro método ágil, vem o Manifesto Ágil, que deve ser sempre seguido.

Gostou do artigo e que saber mais sobre Scrum. Que tal começar pelo Guia do Scrum no site da Scrum.org.

Wladimir Farias Tenório Filho

Deixe seu comentário