fbpx

Skip links

SCRUM

Scrum é uma forma ágil de administrar um projeto, normalmente no desenvolvimento de software. Desenvolvimento ágil de software com Scrum é muitas vezes visto como uma metodologia; mas em vez de ver Scrum como uma metodologia, pensem nele como uma estrutura para administrar um processo.

O que é o Scrum?

No mundo ágil do Scrum, em vez de implementar descrições completas e detalhadas sobre como tudo está pendente num projeto, a maior parte são deixadas para a equipa de desenvolvimento de software Scrum. Isto acontece porque a equipa sabe melhor como resolver o problema com  que serão apresentados.

É por isto que no desenvolvimento Scrum, por exemplo, uma reunião de planeamento sprint é descrita segundo o desfecho desejado em vez de um conjunto de critérios de entrada, definições de tarefas, critérios de validação, critérios de saída, etc… como está implementado na maioria das metodologias.

Scrum baseia-se numa equipa auto-organizadora, no sentido de que não existe um líder de equipa geral que decida que elemento deve fazer que tarefa ou como será resolvido um problema. Essas situações deverão ser decididas pela equipa como um todo.

O Scrum necessita também uma equipa “cruzadamente-funcional”, o que significa que os elementos são todos necessários para levar uma característica de ideia a implementação.

Dentro de um desenvolvimento ágil, as equipas Scrum são apoiadas por dois papéis específicos. O primeiro é de ScrumMaster, o qual pode ser comparado a “treinador” da equipa, ajudando membros da equipa a usar processos do Scrum ao mais alto nível.

O outro papel é de proprietário do produto e, no desenvolvimento de software Scrum, representa o negócio, clientes ou usuários, e guia a equipa para construir o produto correto.

Desenvolvimento Scrum: O que está envolvido?

O modelo Scrum sugere que os projetos progridem através de uma série de sprints. Ao manter-se com um metodologia ágil, os sprints são limitados a não mais de um mês, normalmente duas semanas.

A metodologia Scrum defende uma reunião de planeamento ao começo do sprint, onde membros da equipa descobrem a quantos itens se podem dedicar, e então criar um registo de sprint – uma lista de tarefas a concretizar durante o sprint.

Durante um sprint Scrum, a equipa Scrum pega num pequeno conjunto de características de ideia a funcionalidade codificada e testada. No final estas características estão terminadas, o que significa que foram codificadas, testadas e integradas no produto ou sistema em evulução.

Em cada dia de sprint, todos os membros da equipa deveriam atender uma reunião Scrum diária, incluindo o ScrumMaster e o propietário do produto. Esta reunião está limitada a anão mais de 15 minutos.. Durante este tempo, os membros da equipa partilham o que trabalharam no dia anterior, trabalharam nesse dia, e identificam os impedimentos do progresso.

O modelo Scrum considera Scrums diários como uma forma de de sincronizar o trabalho de membros da equipa à medida que discutem o trabalho do sprint.

No final de um sprint, a equipa leva a cabo uma revisão sprint durante o qual a equipa demonstra a nova funcionalidade ao proprietário do produto ou a qualquer outro acionista que deseje dar um feedback que possa melhorar a influencia do próximo sprint.

Esta roda de feedback dentro do desenvolvimento de software Scrum pode resultar em mudanças à funcionalidade recentemente entregue, mas também pode resultar numa revisão ou adição de itens no registo do produto.

Outra atividade na administração de projeto Scrum é a retrospetiva sprint no final de cada sprint. A equipa completa participa nesta reunião, incluindo o SrcumMaster e o proprietário do produto. A reunião é a opurtunidade de refletir sobre o sprint que terminou, e de identificar opurtunidades para melhorar.

Processo Scrum: Os Artefactos Principais

O artefacto principal no desenvolvimento Scrum é, claramente, o próprio produto. O modelo Scrum espera que a equipa leve o produto ou o sistema a um estado potencialmente exportável no final de cada sprint Scrum.

O relatório do produto é outro artefacto do Scrum. Este é a lista completa da funcionalidade que falta ser adicionada ao produto. O proprietário do produto prioritiza o registo para que a equipa trabalhe sempre primeiro nas características mais valiosas.

A forma mais popular e mais bem sucedida de criar um registo de produto usando metodologia Scrum é popular o registo com histórias de usuário, que são descrições curtas da funcionalidade descrita desde a perspetiva de um usuário ou cliente.

Na administração de projeto Scrum, no primeiro dia de um sprint e durante a reunião de planeamento, os membros da equipa criam o registo de sprint. O registo de sprint pode ser considerado uma lista de a-fazeres para o sprint da equipa,  sendo que o registo de produto é uma lista de características a ser feitas (escritas em forma de historias de usuários).

O registo de sprint é a lista de tarefas que a equipa precisa de executar para poder entregar a funcionalidade que se responsabilizou a entregar durante o sprint.

Os artefactos adicionais resultantes da metodologia ágil Scrum são o gráfico de cansaço do sprint e o gráfico de cansaço de lançamento. Os gráficos de cansaço mostram a quantidade de trabalho restante num sprint ou num lançamento, e são uma ferramenta efetiva no desenvolvimento de software Scrum para determinar se um sprint ou lançamento estão dentro do horário para ter todo o trabalho planeado terminado para a data desejada.

O Projeto Ágil Scrum: Papéis Principais

Mesmo sendo novo no Scrum, pode ter ouvido falar de um papel chamado ScrumMaster. O ScrumMaster é o treinador da equipa, e ajuda os praticantes Scrum a chegar ao seu mais alto nível de desempenho.

No processo Scrum, um ScrumMaster difere de um administrador de projetos convencional em muitas maneira, incluindo o facto deste papel não oferece direção à equipa dia-a-dia e não atribui tarefas a indivíduos.

Um bom ScraimMaster protege a equipa de distrações exteriores, permitindo assim aos membros da equipa concentrarem-se  magnanimamente durante o sprint no objetivo que escolheram.

Enquanto o ScrumMaster se concentra em ajudar a equipa a ser o melhor que pode, o proprietário do produto trabalha para direcionar a equipa para o objetivo correto. O proprietário do produto fá-lo ao criar uma visão do produto apelativa, que depois transporta essa visão para a equipa através do registo do produto.

 

O proprietário do produto é responsável por prioritizar o registo durante o desenvolvimento Scrum, para assegurar que está em ordem enquanto se aprende mais sobre o sistema que está a ser construído, os seus usuários, a equipa, etc.

O terceiro e último papel na administração de projeto Scrum é a própria equipa Scrum. Mesmo que outros indivíduos possam juntar-se à equipa com vários títulos de emprego, no Scrum, esses títulos são insignificantes. A metodologia Scrum dita que cada pessoa contribui como puder para completar o trabalho de cada sprint.

Isto não significa que é expectável que um testador re-arquitete o sistema; os indivíduos irão gastar a maioria (e às vezes todo) do seu tempo a trabalhar na disciplina em que trabalharam antes de adotar o modelo ágil Scrum. Mas com o Scrum,  espera-se que os indivíduos trabalhem para além das suas disciplinas de preferência sempre que seja para o benefício da equipa.

 

Uma forma de pensar na natureza “interfechável” destes três papéis nesta metodologia ágil é como um carro de corridas.

A equipa Scrum é o próprio carro, pronto para acelerar em qualquer direção em que é apontado. O proprietário do produto é o condutor, assegurando-se que o carro vai sempre na direção correta. E o ScrumMaster é o mecânico-chefe, mantendo o carro bem configurado e a desempenhar ao seu melhor.

 

Return to top of page