Scrum

Metodologias ágil x tradicional: Quais as diferenças?

Para qualquer coisa que queremos desenvolver hoje em dia precisamos fazer um projeto. Em meio ao processo do projeto, devemos ficar atentos a algumas especificações, como os prazos, custos, qualidade e satisfação do cliente, pois o não cumprimento destes pode nos trazer alguns problemas mais à frente. Por isso, cada vez mais damos a devida importância ao gerenciamento de projetos e em como a utilização de metodologias podem nos ajudar a gerir melhor tudo isso.
Atualmente temos dois tipos de metodologias que são bem conhecidas, principalmente se tratando de desenvolvimento de software: as metodologias tradicional e ágil.

Metodologia Tradicional

A metodologia tradicional tem etapas bem definidas sendo o planejamento do projeto, uma estimativa em termos de prazo e orçamento, a execução e entrega no final. Por exemplo, em um desenvolvimento de software financeiro, teríamos o seguinte fluxo:

  • Planejamento do software (como ele ficará no final)
  • Planejamento das atividades que serão necessárias (programação, design, etc)
  • Definição de prazos e custos
  • Execução
  • Testes
  • Implantação

A metodologia tradicional segue um modelo sequencial, ou seja, uma etapa deve ser executada após a outra, sendo assim, uma tarefa não pode ser iniciada enquanto a anterior não for concluída. Também se espera que seja executado exatamente o que foi planejado, focando no resultado final. Para ser um sucesso, não basta apenas seguir essa ordem, é importante entregar no prazo, dentro do orçamento e da qualidade esperada. Na metodologia tradicional o produto só irá “fazer sentido” e ter valor quando o projeto estiver 100% concluído. Dentro dessa metodologia a mais conhecida é o modelo cascata.

O principal receio dentro da metodologia tradicional é que ela não tem muita flexibilidade em relação a mudanças. Qualquer mudança no meio do caminho é vista com grande preocupação pelo gerente de projetos.

Para nos ajudar nesse quesito, entra uma outra metodologia: a ágil.

Metodologia Ágil

Apesar do nome, a palavra ágil aqui não significa agilidade e sim o poder de “quebrar” o projeto em partes menores. Ao contrário da metodologia tradicional que você faz apenas uma entrega já com o projeto final, aqui você faz entregas constantemente até entregar todo o projeto.

A preocupação com custo, qualidade e prazos são as mesmas da metodologia tradicional, porém você consegue controlar e gerenciar as mudanças que provavelmente irão aparecer no decorrer do projeto. Na metodologia ágil o foco principal é a entrega de valor ao cliente, por isso é priorizado a entrega à documentação, por exemplo. Mas isso não quer dizer que não é documentado, não planejado, assim como na tradicional. Na metodologia ágil também existem esses aspectos, mas de maneiras diferentes. Por exemplo, o planejamento da metodologia ágil é de forma iterativa e incremental enquanto a da tradicional planeja com muita antecedência como será cada etapa do projeto.
Dentro desta metodologia o mais utilizado e que provavelmente você já ouviu falar é o Scrum.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Como saber qual utilizar?

Isso vai depender muito do tipo de projeto e cultura da empresa. A própria empresa pode preferir a metodologia tradicional, ainda mais se os envolvidos do projeto não estão acostumados a trabalhar com uma metodologia ágil, ainda que ela se aplique a aquele projeto.

O ideal é estudar o projeto, conhecer os requisitos, tecnologias a serem utilizadas… tudo o que julgar necessário. E a partir disso tudo analisar se é melhor partir pela metodologia ágil ou a tradicional. Em um projeto onde as necessidades do cliente podem mudar a qualquer momento (o que é muito comum), você precisará ter a liberdade de poder fazer mudanças necessárias tanto pelo lado do cliente quanto de tecnologia, se precisar. Projetos que provavelmente terão mudanças constantes, precisa ter um planejamento mais flexível, sendo assim a metodologia mais viável seria a ágil.

A metodologia tradicional é uma boa opção em casos mais específicos, como por exemplo em algo que precisa ser planejado e decidido desde o início. Se o projeto tem poucas chances de ter mudanças e com baixo risco, o ideal é ter um plano de projeto mais detalhado antes de iniciar.

Concluindo…

Vale lembrar que a escolha da metodologia é importante não somente para se ter sucesso no processo, mas principalmente, na entrega do produto. As duas metodologias têm vantagens e podem ser utilizadas até mesmo de forma conjunta, convivendo perfeitamente bem, até mesmo porque o foco das duas é a otimização de projetos. A escolha entre a metodologia tradicional e ágil não precisa ser um conflito. Deve-se respeitar às premissas das duas metodologias e saber o que cada uma pode agregar aos objetivos de cada projeto.

Scrum como ferramenta de apoio ao gerenciamento de projetos

No post anterior, vimos como os projetos de TI podem ser beneficiados utilizando as técnicas do PMI. Foi citado também sobre a utilização de metodologias ágeis como forma de complemento para o sucesso nos projetos de TI. Veremos neste artigo mais profundamente sobre o Scrum, principal metodologia ágil utilizada no mercado.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

O que é e como funciona o Scrum?

O Scrum é uma metodologia ágil que permite manter o foco na entrega de valor para o negócio no menor tempo possível. Seu conceito principal é decompor um projeto em pequenas tarefas mais simples, chamadas de Sprints. Uma Sprint pode ser semanal ou mensal, tendo datas de início e fim bem definidas, possuindo as atividades que devem ser cumpridas dentro deste prazo.

Essa metodologia é composta basicamente por três papéis:

Product Owner ou Dono do Produto

Representa o negócio em si, além de ser o ponto central de liderança do projeto. É função dele comunicar a todos quais objetivos quer atingir. Para isso, ele precisa colaborar ativamente com o Scrum Master e toda a equipe de desenvolvimento, como por exemplo, participar das reuniões e responder rapidamente às questões realizadas pelo time. Ele é responsável por aceitar ou rejeitar o resultado dos trabalhos.

Scrum Master

O Scrum Master orienta a equipe para que as metas sejam cumpridas devidamente. É responsável para que o Scrum seja entendido e aplicado por todos da equipe. Ele também ajuda a desenvolver sua própria abordagem do Scrum, porém sempre respeitando as particularidades de cada organização.

Time de desenvolvimento

O time de desenvolvimento deve ser constituído por poucas pessoas, é recomendado no máximo 10. Aí você deve estar se perguntando o que fazer caso você tenha uma equipe de 15 ou 20 pessoas. A resposta é simples! Você sempre deve dividir sua equipe nesses casos. Uma equipe de 20 pessoas pode ser dividida em 3 equipes menores, podendo ser duas equipes com 7 pessoas e uma equipe com 6 pessoas.

Estas devem se programar para que a meta do Product Owner seja atingida. O time deve conter as habilidades e conhecimentos necessários para produzir com qualidade.

Principais artefatos da metodologia

Agora vamos fazer um passo a passo de como deve funcionar a metodologia Scrum. Primeiramente deve ser determinado quais são as funcionalidades a serem implementadas, estas ficarão em uma lista chamada “Product Backlog”, podendo ser requisitos funcionais, não-funcionais e até mesmo configurações do ambiente. A “Sprint Planning Meeting” é uma reunião na qual é decidido os requisitos, estes devem agregar valor de negócio do produto.

A Sprint deve começar com uma “Daily Scrum Meeting”, onde é priorizada as funcionalidades contidas na “Product Backlog”, selecionando as atividades que cada um da equipe irá realizar na Sprint que irá ser iniciada, priorizando as atividades mais importantes primeiro, porém devem ser tarefas que possam ser completadas durante a Sprint.

É importante ressaltar que não pode ter mudanças nas tarefas durante a realização da Sprint

Cada membro do time escolhe uma tarefa da “Product Backlog” e deve atualizar o status dessa tarefa a cada dia.

As tarefas escolhidas para a Sprint passarão do “Product Backlog” para um outro quadro, podendo ser chamado por exemplo de “Sprint 1”, “Primeira Sprint”, etc.

A comunicação é essencial no Scrum, por isso temos o “Daily Scrum”. Ele é um encontro diário rápido, normalmente de 15 minutos e geralmente realizado logo no início do dia. Basicamente todos do time respondem às seguintes perguntas:

  • O que você fez ontem?
  • O que vai fazer hoje?
  • Quais foram os problemas encontrados?

A reunião é de grande importância pois a partir daí o Scrum Master pode medir os avanços e caso tenha algum problema, pode ser resolvido de forma imediata.

Depois que a Sprint acaba ocorre a “Sprint Review”, onde a equipe apresenta seus resultados. Nesta etapa os resultados devem ser comparados com o início da Sprint. O Product Owner identifica o que foi finalizado e o que não foi, e discute com a equipe o atual “Product Backlog” onde todos colaboram sobre o que deve ser feito a seguir, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma Sprint. A “Sprint Review” fornece dados importantes para a reunião da próxima Sprint.

A “Sprint Retrospective Meeting”, a retrospectiva da Sprint, tem o objetivo de verificar o que funciona e o que não funciona, caso necessite será realizada adaptações no processo de trabalho. Essa reunião deve ser realizada depois de cada Sprint e todos devem participar, levantando as seguintes questões:

  • O que gostaria de começar a fazer?
  • O que gostaria de parar de fazer?
  • O que gostaria de continuar fazendo?

Após esses passos, tudo volta novamente, sendo iniciada uma nova Sprint.

Scrum Master X Gerente de Projetos

Então se eu tenho Scrum Master para gerenciar o time, eu não preciso de um gerente de projetos, certo?

Errado. O Scrum Master tem um papel de facilitador, de um líder, mas não substitui o gerente de projetos. A metodologia Scrum defende que o time deve ser auto-gerenciável, ou seja, não deve haver a necessidade de um gerente de projetos na equipe. Porém, a ideia é que isso mude e que a contribuição do gerente de projetos venha complementar o time Scrum.

O gerente de projetos e o Scrum Master tem papéis diferentes. O gerente de projetos é capacitado para liderar e trabalhar para garantir que todos os processos serão implementados corretamente. Além disso, também auxilia na prestação de contas, contribuindo para a resolução de conflitos em relação ao que é esperado pelos usuários e protege a equipe de influências externas.

Já o Scrum Master tem o seu papel de orientador, sendo que as tarefas de planejamento e execução do projeto ficam a cargo do Product Owner e da equipe do projeto. Apesar disso, ele enfrenta diversos desafios como por exemplo, a gestão do tempo para garantir a execução das atividades da melhor forma.

Quando se trata de Agile, por mais que o termo “time auto gerenciado” esteja na moda, a figura do gerente de projetos ainda é fundamental, pois um gerente de projetos pode auxiliar o Scrum Master, não o sobrecarregando com outros tipos de tarefas.

O fato é que a figura do gerente de projetos continua existindo no papel de apoiador e não de controlador. A responsabilidade total do projeto e de integração com todas as outras frentes continua sendo do gerente de projetos.

Concluindo

Apesar de tudo isso e todas as vantagens que a metodologia tem a nos oferecer, sabemos que sua aplicação é um pouco complexa, ademais, você estará lidando com pessoas. Porém, se a metodologia for aplicada corretamente e houver comunicação e planejamento entre absolutamente todos da equipe (incluindo o gerente se projetos, se houver) há grandes chances de o produto final sair conforme o planejado e em um curto prazo de tempo.

O que achou dessa metodologia? Já participou de um projeto onde o Scrum foi utilizado? Conta pra gente. =)

Microsoft Project Básico
Curso de Microsoft Project Básico
CONHEÇA O CURSO