Saltar para: Post [1], Pesquisa e Arquivos [2]

Profissional Moderno

Profissional Moderno

22
Abr20

Scrum em projetos de grande dimensão

Luís Rito

Olá!

 

Ao longo do tempo, tenho-vos escrito alguns artigos sobre como pode uma empresa reinventar-se e começar a trabalhar de uma forma menos tradicional e mais ágil. A agilidade organizacional é hoje uma característica quase obrigatória em qualquer empresa que se queira destacar no século XXI. Claro que não se aplica a todo e qualquer tipo de projetos. Existem projetos onde a agilidade compensa largamente, enquanto noutros uma gestão de projetos mais tradicional continua a ser uma mais valia. Metodologias mais tradicionais favorecem muito a previsibilidade, enquanto metodologias mais ágeis favorecem a velocidade. Quanto a vocês não sei, mas na construção de um edifício ou de uma ponte prefiro sempre previsibilidade a velocidade. É por isso que neste tipo de projetos ainda se utiliza muito metodologias tradicionais de gestão de projetos (também conhecidas como waterfall). Contudo, diria que na esmagadora maioria dos projetos que hoje se iniciam, a velocidade é um fator determinante e obrigatório, seja porque o contexto muda constantemente, seja porque se quer ser mais rápido que um concorrente, seja porque os clientes assim o exigem. É por isso que nos últimos anos, metodologias ágeis como o Scrum têm florescido e prosperado junto dos gestores de projeto e organizações.

 

Uma das críticas que o Scrum é normalmente alvo, é que funciona muito bem em equipas e projetos pequenos, mas para aplicar em projetos de grande dimensão torna-se insuficiente. Esta afirmação revela algum desconhecimento, já que hoje em dia existem várias formas de utilizar metodologias ágeis mesmo em grandes projetos. Existem frameworks específicas para quem quer utilizar metodologias ágeis em organizações de grande dimensão ou em projetos/programas que envolvam centenas de pessoas. Algumas delas são:

 

 

Pela sua simplicidade e facilidade de implementação, hoje quero focar-me especificamente no scrum of scrums. Na realidade, trata-se de fazer algo muito semelhante ao que já acontece numa iteração normal de scrum. Para aprenderes mais sobre scrum, dá uma vista de olhos neste artigo.

De forma resumida, o trabalho é realizado por iterações (sprints), normalmente de 2 ou 3 semanas. Antes de cada sprint a equipa compromete-se com uma quantidade de trabalho que é retirado de um backlog (trabalho em falta) de acordo com as prioridades definidas pelo product owner (ponto de contacto com o cliente). Diariamente acontecem as daily scrums, que são reuniões de 15m com o objetivo da equipa partilhar o que fez, o que vai fazer e que impedimentos está a ter. No fim do sprint deve ser apresentado o seu output ao cliente, permitindo também obter feedback de uma forma constante e regular. Finalmente a equipa evolui na sua forma de trabalhar através das retrospetivas, onde se analisa o que correu bem, o que correu menos bem e coisas que a equipa pode melhorar na próxima iteração.

 

Scrum of Scrums

 

Se deres uma vista de olhos na imagem acima, encontras 4 equipas, equipa A, B, C e D. Cada uma dessas equipas tem um backlog específico que representa o trabalho que tem para executar (via sprints), e tem também um product owner e um scrum master. Já falámos que um Product Owner é o ponto de contacto com o cliente, efetuando ainda a gestão das prioridades de execução, enquanto o scrum master é a pessoa responsável por garantir as boas práticas do scrum e agir como um servant leader para a equipa, desbloqueando todo o tipo de problemas. Vamos assumir que todas as equipas da imagem têm responsabilidade sobre uma área específica do projeto, trabalhando cada uma delas dentro da sua própria bolha. Por se encontrarem de certa forma isoladas, as equipas selecionam uma pessoa que servirá como embaixador (normalmente o product owner ou o scrum master), que fará parte de outra equipa de scrum um nível acima. Essa equipa terá igualmente um backlog e uma daily scrum (que pode por exemplo ser semanal ao invés de diária) onde é partilhado o que foi feito, quais os próximos passos e quais os impedimentos com que a equipa se está a deparar. Normalmente nos níveis mais acima, os impedimentos são mais focados em temas relacionados com problemas de coordenação entre as equipas.

A ideia é que essas equipas mais acima tenham uma pessoa de cada equipa individual de scrum, para que com isso consigam ter uma ideia mais global do projeto como um todo. Isso ajudará com questões como dependências entre equipas ou desbloqueio de problemas. Caso necessário, ainda é possível ir mais níveis acima (uma espécie de pirâmide como podes ver na imagem acima), tudo depende da complexidade do projeto. Assumindo uma estrutura como a da imagem, e com reuniões diárias de 15m, seria possível comunicar com todas as partes em apenas 45m (15m por cada nível).

Reforço que em todos os níveis deve existir um backlog de trabalho a realizar. A grande diferença é que mais acima fala-se de features ou epics (grandes blocos de trabalho), e há medida que se vai descendo o trabalho é partido em blocos mais pequenos até chegar ao nível das equipas que o estão a executar.

 

Caso o número de pessoas que compõem o projeto seja muito elevado, deve-se aumentar o número de equipas de scrum, já que o tamanho ideal das equipas ronda as 6-8 pessoas. Assumindo que cada uma das equipas tem no máximo 7 pessoas, caso estejamos a falar de 10 equipas, teríamos 70 pessoas, o que já é um número considerável. Nestas estruturas começa a fazer sentido ter um chief product owner e um chief scrum master a quem reportam todos os outros product owners e scrum masters das equipas individuais. Dependendo da dimensão, pode também fazer sentido aplicar umas das metodologias que te falei acima (SAFe, DAD ou LeSS).

 

Em outros artigos espero vir a poder-te falar um pouco mais sobre todo este mundo.

 

Até à próxima :)

 

 

 

 

 

 

 

 

 

Subscrever por e-mail

A subscrição é anónima e gera, no máximo, um e-mail por dia.

Livro Liberdade Financeira

Livro PMP Questions to Conquer the Exam