7 motivos para adotar o Scrum
O Scrum é um considerado um framework e não um método, porque descreve apenas diretrizes de gestão. Ele não nos diz o que fazer, nem dá muitos detalhes sobre como gerenciar, foca apenas em algumas “cerimõnias” e artefatos. Costumo dizer que o Scrum busca o maior valor agregado no menor tempo possível, pois de todas as práticas, essa é a que mais faz a diferença.
Projetos de software mudam constantemente. Levante a mão quem já conseguiu fazer um projeto desses sem precisar alterar nada, é praticamente impossível. Sempre há um relatório, um campo, uma cor e seja lá qual for a alteração, se usarmos um método muito pesado, irá requerer uma análise de impacto detalhada.
O framework não funciona apenas em projetos de software, mas em qualquer projeto que precise de agilidade para tratar mudanças. Vejamos alguns princípios que fazem o Scrum funcionar
- Planejamento iterativo-incremental – Ao invés de fazer um planejamento detalhado antes de começar, o Scrum prega o “macro planejamento”, ou seja, que se planeje superficialmente o projeto. A partir desse planejamento, detalham-se apenas as entregas mais prioritárias, uma a uma, em cada sprint. Isso dá maior agilidade e obriga a empresa a priorizar.
- Prioridade de negócio – O Scrum tem foco no que é mais importante para o negócio e não no que é mais importante tecnicamente. Isso, às vezes, gera retrabalho, mas permite que um conceito seja testado antes de se continuar o projeto. a decisão do que é prioridade deve ser determinada por um Product Owner, que é alguém que representa os interesses de todos os stakeholders.
- Timebox – No Scrum quem manda é o tempo, não a entrega. Se o tempo acabar, é bom que se tenha uma entrega pronta. A Sprint pode levar de 3 a 30 dias, depende de quão rápido se deseja ter o resultado.
- Entrega completa em cada Sprint – No Scrum não há atrasos de projeto, mas pode haver atrasos de entrega. A equipe trabalha para finalizar o máximo possível do trabalho no tempo disponível. Isso as obriga a trabalhar colaborativamente para finalizar uma entrega funcional.
- Daily meeting – Todos os dias a equipe se reúne para discutir o trabalho sendo realizado. Isso gera pressão no grupo e faz com que os menos produtivos se adaptem aos mais produtivos (ou vice-versa). Cabe ao Scrum Master “bater o tambor” para dar o ritmo.
- Review meeting – Ao final de cada timebox (Sprint) é realizada uma reunião de avaliação do produto com o Product Owner. Ele aprovará, em nome de todos os stakeholders, se a entrega foi satisfatória ou não e irá, na fase de planejamento, determinar quais são as novas prioridades. Isso evita a mudança desordenada de prioridades ao longo do desenvolvimento do projeto, pois determina um período fixo para reavaliação.
- Retrospective meeting – Sempre que o timebox termina é realizada a reunião de revisão e, em seguida, a retrospectiva. Nessa reunião, seguindo o modelo PDCA (Plan, Do, Check e Act), o processo de trabalho é reavaliado buscando formas de melhorar a qualidade e a produtividade. Isso faz com que a equipe reflita sobre as potenciais melhorias, criando novas formas de trabalhar.
Já houve, no passado, muita polêmica entre os “tradicionais” e os “ágeis”. Os primeiros preocupados com a documentação e a gestão do projeto como um todo, julgavam o Scrum como um método sem formalidades. Ora, o Scrum nunca excluiu as formalidades, ele apenas simplificou o modelo de gestão adicionando princípios que trazem resultados mais rápidos e favorecem o controle num ambiente de mudanças. Pode-se adicionar ao Scrum o processo que se desejar, desde que seus pilares sejam preservados.
Como cada empresa deseja implantar sua própria forma de trabalhar, cunharam-se os termos “Scrum And” e “Scrum But”. Enquanto um adiciona processos, métodos, avaliações e entregas mantendo as diretrizes gerais do framework, o segundo as altera. O Scrum vem sendo discutido há muitos anos por milhares de pessoas e alterar seu “jeitão” traz consequências (Vide links relacionados). Minha sugestão é que se busque entendê-lo profundamente antes de fazer alterações, afinal, se nossas visões fossem tão amplas assim, o método tradicional de desenvolvimento de software jamais teria mudado e até hoje estaríamos preenchendo “task lists” para realizar projetos milionários.
Eli Rodrigues
Links relacionados:
