Este é o primeiro artigo da série “Descomplicando o Scrum”, a metodologia ágil que não está mais apenas vinculada ao desenvolvimento de software e está presente também em outros mercados. Neste artigo que irá estrear a série, vamos fazer uma introdução ao o que é o Scrum e como é estruturado um time Scrum.

Então, se você tem dúvidas de como funciona essa incrível metodologia ágil ou fica perdido com as nomenclaturas utilizadas para descrever membros e funcionalidades, esse texto é para você!

O que é Scrum?

O Scrum foi criado em 1993 por Jeff Sutherland e Ken Schwaber e hoje é a metodologia ágil mais utilizada no mundo, principalmente no desenvolvimento de software. O Scrum é uma metodologia que propõe que pequenas equipes multidisciplinares sejam capazes de se organizar para atenderem demandas em um curto espaço de tempo. Fazendo, assim, entregas complementares a cada ciclo que (no Scrum) são chamadas de sprints. 

Metodologia tradicional

Em uma metodologia tradicional, o projeto é planejado na fase inicial, assim como a criação do seu escopo. Sendo assim, é criada uma documentação extensa de tudo o que o projeto precisa ter, suas funcionalidades e dependências. Para que, apenas depois, se inicie o desenvolvimento do projeto. Neste caso, o cliente só tem visão do produto ao término de todo o desenvolvimento, que é extenso e burocrático devido ao excesso de documentações.

Muitas vezes, um projeto desenvolvido na estrutura tradicional acaba ficando obsoleto ou já não atende mais às necessidades do mercado ao qual era necessário no momento do seu planejamento. Ou seja, ocasionando em desperdício de tempo e recursos monetários.

Mudanças

Um outro grande problema da metodologia tradicional diz respeito às mudanças. Geralmente, essas mudanças causavam grandes impactos no prazo do projeto. Além disso, em sua maioria, as mudanças eram rejeitadas por inviabilizar sua absorção no projeto.

Com o Scrum, o processo é descomplicado. O projeto é dividido em ciclos incrementais, como mencionamos em alguns parágrafos acima. Esses ciclos são denominados de Sprint. Ao término de cada Sprint, o cliente pode ter visão de uma parte funcional do sistema que poderá ser testada por ele. Caso haja alguma correção ou ajuste que não estava no escopo inicial, a alteração poderá ser realizado na próxima Sprint. Isso minimiza o impacto no prazo do projeto e permite uma proximidade entre o time de Scrum e o cliente que acompanhará as etapas de desenvolvimento de perto.

Dessa forma, o Scrum torna o desenvolvimento de projetos mais ágil e faz com que o produto tenha um acompanhamento detalhado em cada fase de desenvolvimento por todas as partes interessadas (também chamadas de stakeholders).

Time Scrum

Para que o Scrum seja de fato ágil, ele deve possuir times pequenos entre quatro e nove pessoas. Todos os membros do time devem ser multidisciplinares e auto gerenciáveis. Isso porque dentro do Scrum não deve existir um “chefe” (propriamente dito), pois todos devem ser capazes de organizar suas tarefas e cooperar com o avanço de cada Sprint do projeto.

Um time Scrum possui três papéis bem definidos e que devem ser obedecidos durante todo a fase de desenvolvimento do projeto, são eles: Product Owner; Scrum Master; e Time de Desenvolvimento.

É importante (sempre que possível) que o time seja mantido em todas as fases do projeto. Isso para que seja definido um padrão de velocidade. Quando um time trabalha junto durante um determinado período, todos os membros passam a conhecer sua velocidade e, assim, estimar melhor as entregas para cada Sprint.

Antes de mais nada, vamos nos aprofundar nos personagens do time Scrum:

Product Owner

O Product Owner ou Dono do Produto é o personagem responsável por definir as prioridades do produto. Sendo assim, esse profissional tem o papel de maximizar o valor do produto se balizando pelo ROI (Return of Investiment) ou Retorno do Investimento. Então, o Product Owner definirá com maior prioridade as demandas que trarão o retorno do investimento esperado do produto.

O ROI pode sofrer alterações a qualquer momento do projeto, por diversos fatores. Por exemplo, uma funcionalidade que fazia sentido no início do projeto pode deixar de fazer sentido durante a fase de desenvolvimento. Então, o Product Owner deve fazer o acompanhamento de perto do Backlog do Produto (que são as tarefas de desenvolvimento necessárias para concluir o desenvolvimento do produto) e sempre alterar a priorização dos itens conforme o ROI.

Sendo assim, o Product Owner pode ser o próprio cliente (que terá o produto ao término do desenvolvimento) ou alguém do Time Scrum que está sempre próximo ao cliente, entendendo de perto as regras de negócio e gerenciando todos os Stakeholders do projeto.

Com isso, o Product Owner é único que tem autoridade para gerenciar o Backlog do Produto. Assim, o Product Owner poderá definir quais tarefas têm maior relevância dentro do Backlog do Produto, as que têm menor importância e até mesmo as que não devem estar presentes no Backlog do Produto.

O Product Owner (também conhecido como PO) deverá traduzir os itens do backlog de forma que fique claro para todos, principalmente para o time de desenvolvimento. A descrição dos itens e funcionalidades não deverá incluir termos técnicos ou dizer quais tecnologias deverão ser utilizadas pelo time. Aliás, tecnologias a serem utilizadas são determinadas pelo time de desenvolvimento.

O time de desenvolvimento

O time de desenvolvimento é o responsável por fazer as entregas incrementais dos projetos e estimar os itens do backlog definindo a dificuldade de execução de cada um dos itens. Os membros do time devem ser capazes de auto gerenciar o próprio trabalho e terem o conhecimento necessário para tornar cada incremento funcional. 

Dentro do time Scrum, não existe hierarquia. Poderão haver especialistas em determinado assunto (como um especialista em banco de dados), mas a responsabilidade das entregas incrementais é do time como um todo.

Assim como podemos ver no Guia do Scrum, um time de desenvolvimento deve ser pequeno o suficiente para ser ágil e grande o bastante para completar uma parcela significativa do processo de desenvolvimento.

O time de desenvolvimento junto do Product Owner determina o esforço necessário para cada item do backlog.

Uma Sprint de desenvolvimento que não deve ultrapassar quatro semanas. Geralmente, um time que não tem entrosamento tem mais dificuldade para estimar com precisão por não terem conhecimento da sua velocidade. Sendo assim, é normal que se criem Sprints mais longas e, nas próximas Sprints, o time ganhará entrosamento e a estimativa de esforço se torna mais assertiva.

O time de desenvolvimento não poderá definir a prioridade do Backlog do Produto, sendo essa tarefa apenas do Product Owner. Da mesma forma que o Product Owner não pode definir de qual forma será desenvolvido um determinado item do backlog, dizendo qual será a tecnologia ou métodos utilizados. O Product Owner deve apenas assegurar que o time siga a regra de negócio e atenda o propósito do produto.

Scrum Master

O Scrum Master é como se fosse um técnico de futebol. Durante um jogo, o técnico é responsável por garantir que as definições técnicas e táticas sejam seguidas para que o time consiga ganhar do adversário, não é mesmo?

O Scrum Master precisa garantir que o Scrum seja entendido e que todas as suas regras e ritos sejam seguidos por todos os integrantes do time.

Esse profissional não deve ser visto como um líder ou “chefe”, e sim como um facilitador que estará sempre disponível para tirar um impedimento. Sendo assim, o Scrum Master deve sempre trabalhar com o Product Owner para facilitar o entendimento do Backlog do Produto, definir técnicas para facilitar o gerenciamento do backlog e comunicar o objetivo e a visão dos itens do backlog ao time de desenvolvimento.

Dentro de uma organização, o Scrum Master é responsável por tornar o Scrum viável. Assim, treinando todas as pessoas para a adoção da metodologia ágil Scrum e permitindo que todos entendam os benefícios da aplicação do Scrum.

A trindade do Scrum

A definição clara de cada papel dentro de um Time Scrum permite melhor visualização do seu funcionamento e faz com que a metodologia de fato funcione. É fundamental entender também que a função de cada um dos papéis deve ser respeitada, para que não haja complicações ou falsas interpretações. 

Com a clara definição dos papéis e um time auto gerenciável e multidisciplinar, o Scrum poderá ser utilizado em sua máxima potência. Assim, os projetos serão entregues com excelência de qualidade e prazos incríveis!

Agora que temos a visão de um time Scrum, podemos nos aprofundar e entender melhor os elementos e ritos do Scrum. Por isso, fique ligado e não perca as novidades aqui no Blog da Luby.

Leia também:

O que é e como funciona o Planning Poker?

Hard Skills e Soft Skills: o que é e como elas podem te ajudar?

Luby Software recebe R$14 milhões de investimento da Multilaser

Estágio de programação: Luby contrata estudantes para desenvolver talentos