Tutorial SCRUM – Parte 4

Scrum

Como dito nos posts anteriores, as Histórias do Usuário são comumente usadas para descrever os recursos do produto e farão parte dos Artefatos do Scrum – Backlog do Produto e Backlog do Sprint.

Histórias dos Usuários

No desenvolvimento de software, os recursos do produto desempenham um papel crucial. São os recursos que o usuário finalmente gosta de usar no produto final. Eles são conhecidos como Requisitos na terminologia geral. O sucesso do projeto de desenvolvimento de software está em entender os requisitos do usuário de forma precisa e apropriada e, em seguida, implementá-los no produto final. Assim, os requisitos ou recursos do produto precisam ser totalmente conhecidos para a equipe do projeto de desenvolvimento.

Em 1999, Kent Beck criou um termo User Stories para as características do produto. Ele descreveu que uma história do usuário é narrada da perspectiva do usuário em relação ao que ele quer ter, e não o que o sistema pode fazer por ele. Assim, a visão mudou completamente de produto para usuário e as Histórias de Usuários tornaram-se padrão de fato para os Requisitos em todas as estruturas Ágeis.

Em projetos Scrum, o Backlog de Produto é uma lista de histórias de usuários. Essas Histórias de Usuários são priorizadas e incluídas no Backlog da Sprint na Reunião de Planejamento da Sprint.

A estimativa também é baseada em histórias do usuário e o tamanho do produto é estimado em Pontos do Histórico do Usuário.

Escrevendo Histórias de Usuários

O Product Owner é responsável pelo Backlog de Produto e, portanto, pelas Histórias de Usuários. No entanto, isso não significa que apenas o proprietário do produto grave as histórias do usuário. Qualquer um no Time Scrum pode escrever as histórias do usuário, e a atividade pode ser espalhada pelo projeto conforme os requisitos são refinados e novas funcionalidades são adicionadas.

Requisitos não Funcionais nas Histórias de Usuários

É possível incorporar os requisitos não funcionais também nas histórias do usuário. No exemplo de ATM fornecido, o ATM disponível para o usuário 24X7, 365 dias é um requisito não funcional, que pode ser descrito por um caso de uso.

Gerenciando Histórias de Usuários

As Histórias de Usuários são gerenciadas no Backlog do Produto. As Histórias de Usuários são ordenadas de acordo com a prioridade. As histórias de usuários mais priorizadas são refinadas em nível granular, enquanto as histórias de usuários com menos prioridade são mantidas em um nível de detalhes menor. Para cada sprint, as Histórias de Usuários mais priorizadas e, portanto, mais granuladas são incluídas no Backlog da Sprint. Se uma História do Usuário deve ser adicionada ao Backlog do Produto, sua prioridade é determinada primeiro e ela é posicionada de acordo com seu local de acordo com a prioridade. As histórias do usuário podem ser redimensionadas a qualquer momento. Também é possível remover qualquer uma das histórias do usuário, se necessário.

Benefícios com Histórias de Usuários

  • O principal benefício da História do Usuário está na própria definição centrada no usuário. Isso porque, em última análise, é o usuário que usará o produto nos cenários de usuário relevantes. Ele conecta os usuários finais aos membros da equipe.
  • A sintaxe da História do usuário garante a captura da meta ou benefício ou valor que o usuário deseja alcançar.
  • Como os critérios de aceitação fazem parte da própria história do usuário, isso será uma vantagem adicional para o Time Scrum.
  • É possível fazer alterações em uma história do usuário no decorrer da execução do projeto. Se o escopo da história do usuário se tornar grande, ele precisará ser dividido em Histórias de Usuários menores. As condições no critério de aceitação também podem ser alteradas.
  • À medida que os incrementos de produtos de trabalho são entregues aos usuários ao final de cada sprint, a equipe de scrum pode obter feedback dos usuários na reunião de revisão de sprint. Isso permite a incorporação de feedback no produto continuamente.

Estimativa

n Projetos Scrum, a estimativa é feita por toda a equipe durante a Reunião de Planejamento da Sprint. O objetivo da Estimativa seria considerar as Histórias de Usuários para o Sprint por Prioridade e pela Habilidade da equipe para entregar durante a Caixa de Tempo do Sprint.

O Product Owner garante que as Histórias de Usuários priorizadas sejam claras, possam ser submetidas a estimativas e levadas para o início do Backlog do Produto.

Como o Time Scrum no total é responsável pela entrega do incremento do produto, seria preciso ter cuidado ao selecionar as Histórias de Usuários para o Sprint com base no tamanho do Incremento do Produto e no esforço necessário para o mesmo.

O tamanho do Incremento do Produto é estimado em termos de Pontos de História do Usuário. Depois que o tamanho é determinado, o esforço é estimado por meio dos dados passados, ou seja, esforço por Ponto de História do Usuário, chamado Produtividade.

Técnicas de Estimativas Scrum

O Scrum Estimation of User Stories é em termos do grau de dificuldade de cada uma das Histórias de Usuário. Para avaliar o grau de dificuldade, uma escala particular é usada.

A técnica de estimativa é normalmente escolhida de tal forma que toda a equipe do scrum esteja familiarizada e confortável com os valores da escala. A técnica mais comumente usada e mais popular é o Planning Poker, que é baseado na sequência de Fibonacci.

Técnica Planning Poker

Na técnica Planning Poker, estimativas para as Histórias de Usuários são derivadas jogando Planning Poker. Todo o Time Scrum está envolvido e resulta em estimativas rápidas, mas confiáveis.

O Planning Poker é jogado com um baralho de cartas. Como a seqüência de Fibonacci é usada, as cartas têm números – 1, 2, 3, 5, 8, 13, 21, 34, etc. Esses números representam os Pontos da História. Cada estimador tem um baralho de cartas. Os números nos cartões devem ser grandes o suficiente para ficarem visíveis para todos os membros da equipe, quando um dos membros da equipe tiver um cartão.

Um dos membros da equipe é selecionado como o moderador. O moderador lê a descrição da História do Usuário para a qual a estimativa está sendo feita. Se os estimadores tiverem alguma dúvida, o Product Owner responde a eles.

Cada avaliador seleciona em particular um cartão representando sua estimativa. Os cartões não são mostrados até que todos os estimadores tenham feito uma seleção. Nesse momento, todas as cartas são simultaneamente viradas e retidas para que todos os membros da equipe possam ver cada estimativa.

Na primeira rodada, é muito provável que as estimativas variem. Os estimadores alto e baixo explicam o motivo de suas estimativas. Deve-se tomar cuidado para que todas as discussões sejam destinadas apenas à compreensão e nada seja levado a cabo pessoalmente. O moderador tem que garantir o mesmo.

A equipe pode discutir a história e suas estimativas por mais alguns minutos.

O moderador pode tomar notas sobre a discussão que será útil quando a história específica for desenvolvida. Após a discussão, cada estimador estimar novamente selecionando um cartão. Os cartões são novamente mantidos em sigilo até que todos tenham estimado, quando são entregues ao mesmo tempo.

Repita o processo até as estimativas convergirem para uma única estimativa que possa ser usada para a história. O número de rodadas de estimativa pode variar de uma história do usuário para outra.

Benefícios do Planning Poker Estimation

Planejar poker combina três métodos de estimativa –

Opinião de Especialista: Em uma abordagem de Estimativa Baseada na Opinião de Especialista, um perito é perguntado quanto tempo vai levar algo ou quão grande será. O especialista fornece uma estimativa baseada em sua experiência, intuição ou intuição.

A estimativa de opinião de especialistas normalmente não leva muito tempo e é mais precisa em comparação com alguns dos métodos analíticos.

Analogia: Analogia Estimativa usa comparação de Histórias do Usuário. A História do Usuário em Estimativa é comparada com Histórias de Usuários semelhantes implementadas anteriormente. Isso resulta em resultados precisos, pois a estimativa é baseada em dados comprovados.

Desagregação: desagregação A estimativa é feita dividindo-se uma história do usuário em histórias de Usuários menores e mais fáceis de estimar. As Histórias de Usuários a serem incluídas em um Sprint estão normalmente no intervalo de dois a cinco dias para serem desenvolvidas. Portanto, as Histórias de Usuários que possivelmente demoram mais tempo precisam ser divididas em Casos de Uso menores. Essa abordagem também garante que haveria muitas histórias comparáveis.

Conclusão

O Scrum suporta colaboração contínua entre o cliente, membros da equipe e partes interessadas relevantes. Sua abordagem de caixa de tempo e feedback contínuo do proprietário do produto garante produto de trabalho com recursos essenciais todos os tempos. Além disso, o Scrum oferece benefícios diferentes para os diferentes papéis no projeto.

Benefícios Para o Cliente

Os Sprints são de duração mais curta e as histórias de usuários priorizadas são incluídas em todos os planejamentos de sprint. Ele garante que, a cada entrega de sprint, os recursos exigidos pelo cliente sejam incluídos imediatamente. Além disso, se um cliente fizer qualquer solicitação de alteração, ela será absorvida no sprint atual ou incluída no próximo sprint. Assim, a equipe de desenvolvimento responde rapidamente aos requisitos do cliente com muita rapidez.

Benefícios Para a Empresa

A organização pode se concentrar no esforço necessário para o desenvolvimento das histórias de usuários priorizadas e, assim, reduzir a sobrecarga e o retrabalho. Devido aos benefícios específicos do scrum para o cliente, maior eficiência da equipe de desenvolvimento, a satisfação do cliente e, consequentemente, a retenção de clientes e referências de clientes serão possíveis. Aumenta o potencial de mercado da organização.

Benefícios para gerentes de produto

O Product Manager desempenha o papel de Product Owner no projeto. A responsabilidade do proprietário do produto é garantir a satisfação do cliente. Como o Scrum facilita respostas rápidas, priorização de trabalho, absorção de mudanças, o gerente de produto pode facilmente garantir que o trabalho esteja alinhado com as necessidades do cliente, o que, por sua vez, garante a satisfação do cliente.

Benefícios para os gerentes de projeto

Gerente de Projeto desempenha o papel de Scrum Master no projeto. A natureza colaborativa do Scrum facilita o planejamento e o rastreamento fáceis e concretos. O uso de gráficos Burndown para entender o trabalho que resta e as reuniões diárias do Scrum dão ao gerente de projeto a consciência do estado do projeto em todos os momentos. Essa conscientização é essencial para monitorar o projeto e para detectar e solucionar problemas rapidamente.

Benefícios para a equipe de desenvolvimento

Devido à natureza de tempo dos sprints e entrega de incremento de produto de trabalho no final de cada sprint, a equipe de desenvolvimento fica entusiasmada para ver que seu trabalho é usado imediatamente. A colaboração interna da equipe faz com que a equipe aproveite o trabalho que faz. Como as histórias de usuários para cada sprint são baseadas nas prioridades do cliente, a equipe também entende que seu trabalho é valorizado.

*** A OctalMind é uma empresa especializada no desenvolvimento de sistemas de alta tecnologia.