Show
Esse artigo teve como base o Scrum Guide 2020, com o propósito de apresentar uma visão geral de toda a abordagem que compõe o framework Scrum.A Definição do SCRUMJeff Sutherland em conjunto com Ken Schwaber, criaram o Scrum em 1993 com o intuito de mudar a forma como o desenvolvimento de Software era gerenciado. É um framework que ajuda pessoas e organizações a gerar valor através de soluções adaptativas para problemas complexos. Teoria do SCRUMO Scrum tem como base o empirismo e lean thinking.Empirismo é todo o conhecimento que vem da experiência e tomada de decisões baseado no que é observado. Lean Thinking reduz o desperdício e se concentra apenas no essencial. Scrum tem uma abordagem iterativa e incremental, para otimização da previsibilidade e controle de riscos. Existem três pilares empíricos no Scrum: transparência, inspeção e adaptação. TransparênciaOs processos e o trabalho devem ser visíveis para todos, tanto para quem executa o trabalho quanto para quem recebe o trabalho. A transparência permite a inspeção, e uma inspeção sem transparência é enganosa, gerando desperdícios. InspeçãoArtefatos Scrum e progresso em direção às metas devem ser inspecionados com frequência, para detectar variações ou problemas indesejáveis. A inspeção é realizada no Scrum por meio de seus cinco eventos, projetados para promover mudanças. A inspeção permite a adaptação, uma inspeção sem adaptação é considerada inútil. AdaptaçãoCaso algum processo desvie fora de seus limites aceitáveis, ou se o resultado do produto for inaceitável, o processo que está sendo executado, ou os materiais que estão sendo produzidos devem ser ajustados. Os ajustes devem ocorrer o mais rápido possível, para minimizar novos desvios. A adaptação se torna mais difícil caso as pessoa envolvidas não sejam auto-gerenciadas, pois é esperado que o Scrum Team se adapte no momento em que aprende algo novo por meio da inspeção. Valores do SCRUMO Scrum é baseado em 5 valores:
SCRUM TeamDentro do Scrum Team não há sub-times ou hierarquias, tendo como principais integrantes um Scrum Master, um Product Owner e Developers. Membros do Scrum Team são multifuncionais, ou seja, possuem todas as habilidades necessárias para criar valor a cada Sprint. Também são autogerenciáveis, decidindo internamente quem faz o quê, quando e como. O Scrum Team deve ser pequeno o suficiente para ser ágil e grande o suficiente para concluir um trabalho dentro de uma Sprint, geralmente são formados por 10 pessoas ou até menos.
A responsabilidade do Scrum Team está em todas as atividades relacionadas ao produto, desde a colaboração e interação com os stakeholders, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e qualquer outra coisa que venha a ser necessária. DevelopersSão as pessoas que estão comprometidas em criar o incremento utilizável a cada Sprint. Os Developers sempre são responsáveis por:
Product Owner(PO)É o responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma de como isso é feito pode variar para cada organização, Scrum Team e indivíduos. Ele é uma pessoa que representa as necessidades de vários stakeholders, fazendo a ligação entre a área de negócios e tecnologia. O Product Owner também tem como responsabilidade, gerenciar o Product Backlog, que inclui:
Para que os PO’s tenham sucesso, toda a organização deve respeitar suas decisões, decisões essas que são visíveis no conteúdo e na ordem do Product Backlog, e por meio do incremento inspecionável na Sprint Review. Scrum MasterÉ o responsável por estabelecer o Scrum conforme definido no Scrum Guide. Eles fazem isso ajudando todos a entender a teoria e prática do Scrum, tanto no Scrum Team quanto na organização. Também é responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas dentro do framework Scrum. Os Scrum Masters são líderes servidores do Scrum Team e da organização como um todo. Ele serve ao Scrum Team de várias maneiras:
O Scrum Master serve ao Product Owner de várias maneiras:
O Scrum Master serve a organização de várias maneiras:
Eventos do SCRUM
SprintSprints são o coração do Scrum, onde ideias são transformadas em valor, e o container para todos os outros os eventos. Com duração de 2 a 4 semanas, uma nova Sprint começa imediatamente após a conclusão da Sprint anterior. Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints. Durante a Sprint:
Sprints permitem a previsibilidade, garantindo a inspeção e adaptação do progresso em direção a meta do produto. Cada Sprint pode ser considerada um projeto curto. Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative flows. Uma Sprint pode ser cancelada se sua meta se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint. Sprint PlanningÉ realizada antes de se iniciar uma Sprint. Todos os membros do Scrum Team devem participar, e através desse evento é definido todo o trabalho necessário e objetivo para a próxima Sprint.
A Sprint Planning aborda os seguintes tópicos: Tópico um: Por que esta Sprint é valiosa? O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual. Todo o Scrum Team então colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint deve ser finalizada antes do final da Sprint Planning. Tópico dois: O que pode ser feito nesta Sprint? Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança. Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto, quanto mais os Developers sabem sobre seu desempenho anterior, sua capacidade futura e sua Definição de Pronto, mais confiantes eles estarão em suas previsões quanto a Sprint. Tópico três: Como o trabalho escolhido será realizado? Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor. A Meta da Sprint, os itens do Product Backlog selecionados para a Sprint, mais o plano para entregá-los são chamados juntos de Sprint Backlog. A Sprint Planning tem um timebox definido com duração máxima de de oito horas para uma Sprint de um mês. Daily ScrumO propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado. é um evento timebox com duração fixa de 15 minutos para os Developers do Scrum Team, sempre realizado no mesmo local e horário, todos os dias úteis da Sprint. Se o Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como Developers. As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões, por meio de 3 perguntas:
A Daily Scrum não é o único momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint. Sprint ReviewSeu propósito é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido. Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir. O Product Backlog também pode ser ajustado para atender a novas oportunidades. A Sprint Review é uma sessão de trabalho e o Scrum Team deve evitar limitá-la a uma apresentação. A Sprint Review é o penúltimo evento da Sprint e tem um timebox com prazo máximo de quatro horas para uma Sprint de um mês. Sprint RetrospectiveSeu propósito é planejar maneiras de aumentar a qualidade e a eficácia. O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto. Os elementos inspecionados geralmente variam com o domínio de trabalho. As suposições que os desviaram são identificadas e suas origens exploradas. O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvidos. O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint. A Sprint Retrospective conclui a Sprint. É limitada pelo timebox de no máximo três horas para uma Sprint de um mês. SCRUM ArtifactsOs artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais informações. Assim, todos os que os inspecionam têm a mesma base para adaptação. Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido:
Product BacklogÉ uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de trabalho realizado pelo Scrum Team. Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de transparência após as atividades de refinamento. O Product Backlog refinement é o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os Developers que farão o trabalho são responsáveis pelo dimensionamento. O Product Owner pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs (trocas de itens). Sprint BacklogO Sprint Backlog é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como). O Sprint Backlog é um plano feito por e para os Developers. É uma imagem altamente visível, em tempo real do trabalho que os Developers planejam realizar durante a Sprint para atingir a Meta da Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo da Sprint conforme mais é aprendido. Deve ter detalhes suficientes para que eles possam inspecionar seu progresso na Daily Scrum. IncrementoUm incremento é um trampolim concreto em direção a Meta do produto. Cada incremento é adicionado a todos os incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos. A fim de fornecer valor, o incremento deve ser utilizável. Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor. O trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto. A Definição de Pronto é uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade exigidas para o produto. No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura. Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os Scrum Teams devem segui-la como mínimo. Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para o produto. Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de Pronto. Quando o horizonte de uma Sprint é muito longo a meta da Sprint pode se tornar inválida?Quando o horizonte de uma Sprint é muito longo, a meta da Sprint pode se tornar inválida, a complexidade pode aumentar e o risco pode aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor.
Quando o horizonte de uma Sprint é muito longo?Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido.
Quais são as três responsabilidades no Scrum Team Guia do Scrum?Este artigo descreve tarefas e responsabilidades do ScrumMaster junto ao projeto e a equipe, demonstrando como este papel pode auxiliar em um processo de desenvolvimento voltado realmente para uma metodologia ágil. Existem três funções fundamentais na metodologia ágil Scrum: o Product Owner, o ScrumMaster, e a equipe.
São responsáveis por maximizar o valor do produto resultante do trabalho do Scrum Team?O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma como isso é feito pode variar amplamente entre organizações, Scrum Teams e indivíduos.
|