Quem é responsável por gerenciar o progresso dos trabalhos durante a Sprint?

0% acharam este documento útil (0 voto)

199 visualizações17 páginas

Simulado 3

Título original:

SIMULADO 3

Pular para a página

Você está na página 1de 17

You're Reading a Free Preview
Pages 7 to 15 are not shown in this preview.

Recompense a sua curiosidade

Tudo o que você quer ler.

A qualquer hora. Em qualquer lugar. Em qualquer dispositivo.

Sem compromisso. Cancele quando quiser.

Muitos desenvolvedores passaram a adotar metodologias ágeis para aumentar a velocidade de entrega de suas soluções de TI. Trabalhando com rotinas como o Scrum, eles se tornaram capazes de atuar lado a lado em busca de uma estratégia mais robusta, segura e que permitisse a entrega contínua de partes do produto, todas completamente funcionais.

Neste cenário, o sprint se integra ao método Scrum como uma forma de facilitar a divisão de um projeto em etapas ao longo do tempo. Com reuniões diárias, definição de metas e um bom fluxo de trabalho, o time de desenvolvimento pode criar um software diferente com a agilidade necessária para os tempos modernos.

Além disso, o uso de sprints permite uma melhor classificação de prioridades, hábito extremamente útil em atividades mais complexas ou que envolvam um número maior de pessoas. A classificação de prioridades, no caso do Scrum, tem a participação de toda a equipe, em diferentes partes do processo de planejamento, o que democratiza e torna mais eficiente o processo.

Quer saber mais sobre sprints e como essa prática da metodologia Scrum pode ajudá-lo no seu dia a dia? Acompanhe:

Afinal, o que é um sprint?

Um dos pilares de um projeto de desenvolvimento baseado na metodologia Scrum consiste em sua divisão em etapas. Cada uma dessas fases possui um tempo definido, que pode ser um ciclo com duração de uma semana, duas semanas ou até um mês.

O sprint pode ser considerado o principal evento do método Scrum, porque é nele que serão aplicados os demais eventos, utilizados os artefatos produzidos anteriormente e desenvolvido de fato o produto. É nele que ocorre a produção de um produto ou parte dele.

Esses são os sprints! Eles não só devem possuir um conjunto de requisitos e metas a serem implementados pelos desenvolvedores, como também, precisam buscar o desenvolvimento de funções, de acordo com a ideia de sistema do cliente.

E como realizar um sprint?

A criação de um sprint envolve um trabalho constante de comunicação entre os times de desenvolvimento, o Scrum Master e o Product Owner. Eles devem compartilhar suas necessidades, sua capacidade de produção e sua evolução no alcance das metas, a fim de evitar a quebra de expectativas ao final de cada etapa.

No entanto, antes de se criar os sprints de um projeto, é preciso definir quais são as funcionalidades do produto a ser desenvolvido e que são desejadas pelo Product Owner. Para isso, constrói-se um artefato chamado Product Backlog, que contém as principais características do produto a serem desenvolvidas.

O Product Owner também tem a função de definir as prioridades do Product Backlog feito por ele. Assim, uma vez que todas as funções do backlog estejam classificadas de acordo com as prioridades de cada parte, a primeira reunião do time de desenvolvimento com o Product Owner é realizada.

Alinhamento

Compartilhando informações, os profissionais deverão alinhar com o Project Owner quais funções serão implementadas, assim como as tarefas a serem executadas. Essa parte é chamada de Sprint Planning. Ele é o primeiro evento realizado no sprint, e deve responder duas perguntas primordiais para o decorrer do método Scrum: o que será feito? Como será feito?

Logo, o Sprint Planning é dividido em duas partes, cada uma com tempo sugerido de quatro horas. A primeira definirá quais os itens do Product Backlog serão desenvolvidos no sprint. Enquanto a segunda parte, definirá como esses itens serão abordados durante o trabalho, ou seja, quais serão as tarefas executadas para que os elementos selecionados sejam entregues no fim dessa etapa.

O resultado é um novo Backlog, que se caracteriza por ser uma parte do Product Backlog, porém, com maior detalhamento de tarefas e funções para cada item selecionado. Esse novo artefato gerado a partir da reunião inicial do sprint é chamado de Sprint Backlog.

Normalmente, a atribuição de prioridades nos Backlog é feita por pontuação. Tarefas mais importantes para o Product Owner, mais difíceis de executar, mais demoradas ou que possuem alguma incerteza ou risco técnico recebem maior pontuação.

Cada Scrum Team tem uma pontuação limite aferida, com base na produtividade da equipe. Com isso, o grupo fica limitado a pegar um conjunto de tarefas que não exceda o limite. Esse parâmetro é criado para diminuir o número de tarefas não entregues devido ao sobrecarregamento da equipe.

Assim que o Product Owner define os itens do Backlog a serem desenvolvidos, fica a cargo do Scrum Team dizer o que é possível de ser entregue dentro do prazo final do sprint. Nesse ponto, é necessário que o time aceite apenas uma quantidade de tarefas que não exceda a pontuação máxima que a equipe é capaz de desenvolver.

Em alguns casos, pode ser mais interessante dar prioridade para as atividades que envolvem um maior risco técnico ou de segurança. Em outros casos, os gestores podem optar por priorizar os trabalhos que agregam mais valor ao produto. Nesse momento, a opinião do Product Owner deve ser levada em consideração.

Duração

No método Scrum, todo evento ou processo é Time-boxed. Ou seja, tudo que será realizado no método tem uma duração, um prazo pré-definido, determinado com base em uma análise anterior ou a um padrão já conhecido de trabalho.

Assim, cada sprint deverá ter sua duração de acordo com a capacidade de trabalho do Scrum Team, responsável pelo desenvolvimento da arquitetura do produto. Normalmente, em equipes que estão no início da implantação do método, é adotado um período de 30 dias para a execução da carga de tarefas padrão.

Assim que ela passar a dominar o método, esse período pode ser reduzido para 21 dias e em seguida para 14 dias. É importante que a duração do sprint seja dada em semanas exatas, o que facilita a organização da equipe. Da mesma forma, as tarefas a serem feitas devem ter no máximo 8 horas, ou seja, um dia de trabalho.

Se o sprint contar com muitas tarefas, será necessário reduzir a quantidade de atividades do Product Backlog que a equipe tentará executar. Caso o número de trabalhos seja baixo, mais itens do Product Backlog podem ser adicionados ao sprint.

Trabalho

Uma vez finalizado o Sprint Backlog, as atividades são efetivamente iniciadas. Nesse momento, o Product Owner deverá se afastar um pouco do time de desenvolvimento, que subdividirá as tarefas de modo a conseguir um maior controle sobre os trabalhos a serem realizados.

O método Scrum procura criar um ambiente de trabalho que facilite a solução de problemas por meio da cooperação coletiva. Para isso, é sugerido que o Scrum Team seja composto por pessoas de diferentes áreas técnicas, a fim de criar um grupo multidisciplinar, o que estimula novas ideias e soluções.

Além disso, a comunicação interpessoal e acompanhamento de resultados devem ser bastante motivados dentro do sprint, para que não haja atrasos ou tarefas não realizadas.

Acompanhamento

Regularmente, a equipe de produção deve efetuar reuniões para discutir os avanços dos trabalhos, promover brainstorms a fim de encontrar soluções para eventuais falhas e compartilhar informações. Essas reuniões são chamadas de Daily Scrum.

Sugere-se que as Daily Scrum sejam realizadas todos os dias, durante o sprint. Nelas serão discutidos o andamento do projeto. Assim, fica mais fácil identificar rapidamente gargalos e se reorganizar para eliminá-los. Nesses encontros, o Project Owner pode até estar presente, mas não deve realizar intervenções a não ser que seja solicitado.

Progresso

A partir do Daily Scrum é possível analisar o progresso e desempenho do trabalho da equipe, buscando as soluções necessárias para os problemas. Para verificar o progresso de cada sprint, um gráfico de burndown pode ser utilizado a partir de três perguntas:

• O que foi realizado no dia anterior?
• O que será realizado hoje?
• Quais são os obstáculos que impedem o avanço do projeto?

A partir do resultado apresentado no gráfico, a equipe pode identificar se está ou não cumprindo com as obrigações firmadas no início do sprint. Caso não esteja, ela analisa o motivo desse desempenho inferior ao esperado. A equipe pode buscar solução em conjunto com o Product Owner, para que todas as etapas desejadas sejam entregues.

Teste

Para que um item seja considerado completo, ele deve ser codificado, testado e devidamente documentado. Falhas de segurança devem ser rastreadas para garantir a confiabilidade do produto, assim como bugs.

Além disso, todo código deve ser otimizado, para garantir o melhor funcionamento possível na máquina do usuário final. É no teste que o time garante que a funcionalidade está bem desenvolvida e o valor esperado será gerado. Isso vale para qualquer tipo de projeto.

Revisão

Ao final de cada sprint, o time de desenvolvimento realiza uma reunião de revisão, conhecida como Sprint Review. Essa reunião deve incluir o time de desenvolvimento, o gerente do projeto e o Product Owner para compartilhar as funções implementadas durante o sprint e apresentar os resultados obtidos.

Na Sprint Review, a equipe de desenvolvimento apresenta o tudo o que foi desenvolvido do Backlog, o que não foi desenvolvido e as dificuldades presenciadas. Normalmente, é feita uma apresentação formal em slides e reservado um tempo para o teste das plataformas já desenvolvidas.

De acordo com a avaliação do Project Owner, a equipe de desenvolvimento pode efetuar melhorias no projeto ou implementar novas funções. O que for reprovado deverá retornar ao Product Backlog, onde ficarão disponíveis para consulta futura.

Com o Sprint Review passa-se transparência ao cliente, ao mostrar o que já foi executado e o que falhou e será refeito, além de permitir que ele acompanhe as etapas de desenvolvimento, sem correr o risco de um produto final indesejado ou malfeito.

Reflexão

Após o encontro de revisão, a equipe de desenvolvimento deve se reunir com o Scrum Master para compartilhar sua opinião sobre o projeto e refletir sobre as práticas adotadas. Esse evento é chamado de Sprint Retrospective e tem o objetivo de analisar o processo de desenvolvimento do produto, não o produto em si.

• Será que podem ser empregadas em outras iniciativas?
• Quais foram os pontos positivos e negativos verificados?
• O que pode ser melhorado?

É importante que o Scrum Master encoraje todos os membros a darem a sua opinião sobre o trabalho realizado. Esse é momento de corrigirem qualquer falha processual detectada. Com isso, é possível tanto reforçar os métodos que devem ser repetidos, desde que alterados ou mesmo, abandonar de vez determinado procedimento.

As metodologias de desenvolvimento evoluíram bastante nas últimas décadas, sempre com o objetivo de atender às diversas necessidades da comunidade. Assim, seja para criar produtos mais seguros ou reduzir prazos de entrega de resultados, é sempre possível encontrar um método que atenda ao perfil de um projeto.

No caso da metodologia Scrum, os sprints são indispensáveis para garantir a qualidade dos trabalhos, pois permitem que tanto os gestores quanto os clientes acompanhem diariamente a evolução de um projeto.

Quanto mais próximos da execução do produto estão os stakeholders (os interessados no desenvolvimento do produto), quanto mais oportunidades eles têm de avaliar e participar das etapas de criação do produto, maior a chance de satisfação e sucesso do produto final.

Além disso, o método permite uma rápida mudança de foco, que auxilia na resolução de problemas, no atendimento a uma mudança repentina no mercado e na redução de retrabalhos e problemas de comunicação. Tudo isso, influencia no tempo de execução e na satisfação do cliente.

Junto aos pontos positivos externos estão também os internos. As Daily Scrum, as reuniões diárias, são ótimas chances para que as equipes identifiquem e melhorem suas práticas, implementando novas rotinas, apontando soluções para problemas críticos e aumentando a qualidade final do produto.

Além disso, a Sprint Review dá espaço para a crítica externa, dos stakeholders, que passam a ser parte fundamental do processo de construção do produto. A Sprint Retrospective fecha o sprint, sendo o mecanismo de correção de erros, discussão de novos procedimentos e afirmação do método.

Quer dicas para aliar o Scrum às boas práticas do PMBoK? Então, você gostará deste e-book.

E você, como trabalha com seu time de desenvolvimento para aumentar a eficiência dos trabalhos? Já conhecia o poder dos sprints para o Scrum? Compartilhe suas experiências e impressões conosco!

• Sobre
• Últimos Posts

Quem é responsável por gerenciar o progresso do trabalho durante um Sprint?

Quem é responsável pelo Sprint Backlog?