Scrum - Guia Rápido

Agile se tornou uma das grandes palavras da moda na indústria de desenvolvimento de software. Mas o que exatamente é desenvolvimento ágil? Simplificando, o desenvolvimento ágil é uma maneira diferente de executar equipes e projetos de desenvolvimento de software.

Para entender o que há de novo, vamos recapitular os métodos tradicionais. No desenvolvimento de software convencional, os requisitos do produto são finalizados antes de prosseguir com o desenvolvimento.

Modelo de Cachoeira

O modelo de desenvolvimento de software mais comumente usado com essa característica é o modelo em cascata, conforme ilustrado no diagrama a seguir. No entanto, na maioria dos casos, novas funcionalidades são adicionadas e também os requisitos anteriores podem mudar. O modelo em cascata não está estruturado para acomodar essas mudanças contínuas nos requisitos. Além disso, o usuário não terá clareza sobre a funcionalidade do produto até que o produto esteja disponível em sua totalidade.

Modelo Incremental Iterativo

No modelo incremental iterativo, o desenvolvimento começa com um número limitado de requisitos finalizados e priorizados. A entrega é um incremento de trabalho do produto. Um conjunto de atividades que variam de requisitos a desenvolvimento de código é chamado de iteração. Com base na funcionalidade do incremento e qualquer um ou todos os novos requisitos modificados e pendentes, o próximo lote de requisitos é fornecido para a iteração subsequente. O resultado da iteração subsequente é um incremento de trabalho aprimorado do produto. Isso é repetido até que o produto atenda às funcionalidades exigidas.

O usuário geralmente não está envolvido no trabalho de desenvolvimento e isso pode causar falhas de comunicação resultando em funcionalidades incorretas. O envolvimento é positivo para a equipe de desenvolvimento, mas exige muito tempo da equipe e pode gerar atrasos. Além disso, quaisquer mudanças informais de requisitos durante uma iteração podem levar à confusão e também criar variações de escopo. Com essa premissa, o desenvolvimento Agile passou a existir.

Desenvolvimento ágil

O desenvolvimento ágil é baseado no desenvolvimento incremental iterativo, no qual os requisitos e soluções evoluem por meio da colaboração da equipe. Ele recomenda uma abordagem iterativa com limite de tempo e incentiva uma resposta rápida e flexível às mudanças. É uma estrutura teórica e não especifica nenhuma prática particular que uma equipe de desenvolvimento deva seguir. Scrum é um framework de processo ágil específico que define as práticas necessárias a serem seguidas.

As primeiras implementações de métodos ágeis incluem Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development (1997) e Dynamic Systems Development Method (DSDM) (1995). Esses agora são chamados coletivamente deagile methodologies, depois que o Manifesto Ágil foi publicado em 2001.

Manifesto Ágil

O Manifesto Ágil foi publicado por uma equipe de desenvolvedores de software em 2001, destacando a importância que deve ser dada à equipe de desenvolvimento, acomodando as mudanças de requisitos, o envolvimento do cliente.

O Manifesto Ágil é o seguinte:

“Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazerem. Por meio deste trabalho, chegamos a valorizar:

Indivíduos e interações sobre processos e ferramentas
Software que trabalha sobre uma documentação completa
Colaboração do cliente na negociação do contrato
Respondendo à mudança seguindo um plano

Ou seja, embora haja valor nos itens da direita, valorizamos mais os itens da esquerda. "

… Manifesto para Desenvolvimento Ágil de Software, Autores: Beck, Kent, et al. (2001)

Definição de itens do Manifesto Agile

Os itens do manifesto à esquerda podem ser descritos da seguinte forma:

Item Manifesto	Descrição
Indivíduos e interações	É necessário dar importância a: auto-organização e automotivação dos membros da equipe interação contínua para trabalho, esclarecimentos, informações entre os membros da equipe
Software de Trabalho	A entrega de software funcional em intervalos de curta duração ajuda a ganhar a confiança do cliente e segurança na equipe.
Colaboração do cliente	O envolvimento constante do cliente com a equipe de desenvolvimento garante a comunicação das modificações necessárias.
Respondendo à mudança	Foco na resposta rápida às mudanças propostas, o que é possível com iterações de curta duração.

O principal elemento do Manifesto Ágil é que devemos confiar nas pessoas e em sua capacidade de colaboração. Por esse motivo, as metodologias ágeis específicas desenvolvidas aproveitam as habilidades dos membros da equipe, enfatizando o trabalho em equipe e a colaboração ao longo do ciclo de vida do projeto.

Princípios Chave do Agile

O Manifesto Ágil é baseado nos seguintes princípios:

Princípio	Descrição
Satisfação e Entrega	Satisfação do cliente por meio de software de trabalho inicial e contínuo.
Acolhendo a mudança	Aceite as mudanças de requisitos, mesmo em estágios posteriores de desenvolvimento.
Entregar com frequência	Entregue software funcional com freqüência (semanalmente em vez de mensal).
A comunicação é a chave	Assegure a associação próxima dos desenvolvedores com os empresários diariamente.
Ambiente e confiança	Construa projetos em torno de indivíduos motivados. Dê-lhes o apoio necessário e confie neles.
Comunicação cara a cara	Incentive a conversa face a face para garantir uma comunicação eficiente e eficaz.
Software como medida de progresso	O software funcional é a principal medida de progresso.
Desenvolvimento sustentável	Promover o desenvolvimento sustentável com a capacidade de manter um ritmo constante ao longo do desenvolvimento.
Atenção aos detalhes	Atenção contínua à excelência técnica e bom design.
O poder de menos	Simplicidade é essencial.
Equipes auto-organizadas	Atenção regular da equipe em se tornar eficaz em circunstâncias variáveis.

Metodologias ágeis

Metodologia de Desenvolvimento de Sistema Dinâmico (DSDM)

É um framework ágil para projetos de software. Ele foi usado para ajustar as abordagens tradicionais. A versão mais recente do DSDM é chamada DSDM Atern. O nome Atern é uma abreviação de Arctic Tern - uma ave marinha que pode viajar grandes distâncias e que representa muitas características do método que são formas naturais de trabalho, como priorização e colaboração.

Scrum

É a estrutura ágil mais popular, que se concentra principalmente em como gerenciar tarefas em um ambiente de desenvolvimento baseado em equipe. Scrum usa modelo de desenvolvimento iterativo e incremental, com menor duração das iterações. Scrum é relativamente simples de implementar e foca em entregas rápidas e frequentes.

Programação Extrema (XP)

É um tipo de desenvolvimento ágil de software. Ele defende lançamentos frequentes em ciclos de desenvolvimento curtos, com o objetivo de melhorar a produtividade e introduzir pontos de verificação onde novos requisitos do cliente podem ser adotados. A metodologia leva o nome da ideia de que os elementos benéficos das práticas tradicionais de engenharia de software são levados a níveis extremos. (Extreme Programming é uma disciplina de desenvolvimento de software que organiza as pessoas para produzir software de alta qualidade de forma mais produtiva.) XP aborda as fases de análise, desenvolvimento e teste com novas abordagens que fazem uma diferença substancial na qualidade do produto final.

Desenvolvimento orientado a testes (TDD)

É um processo de desenvolvimento de software que se baseia na repetição de um ciclo de desenvolvimento muito curto: primeiro o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova função, em seguida, produz a menor quantidade de código para passar no teste, e finalmente traz o novo código para padrões aceitáveis.

Lean

É uma prática de produção que considera o dispêndio de recursos para qualquer objetivo que não seja a criação de valor para o cliente final como um desperdício e, portanto, um objetivo para eliminação. Trabalhando da perspectiva do cliente que consome um produto ou serviço, o termo valor é definido como qualquer ação ou processo pelo qual um cliente estaria disposto a pagar. Lean é centrado em preservar valor com menos trabalho.

Kanban

É um sistema para melhorar e manter um alto nível de produção. Kanban é um método pelo qual o Just-In-Time (JIT), a estratégia que as organizações empregam para controlar as despesas de estoque, é alcançado. Kanban se tornou uma ferramenta eficaz de suporte à execução de um sistema de produção como um todo e provou ser uma excelente forma de promover melhorias.

Conclusão

Nos últimos 10 anos, há um volume cada vez maior de histórias de sucesso, em que as empresas melhoraram drasticamente o sucesso e o desempenho de suas equipes e projetos de desenvolvimento de TI com práticas ágeis. Isso fez com que o Agile fosse amplamente adotado em uma variedade de setores, incluindo mídia e tecnologia, grandes corporações e até mesmo governo.

O Agile Framework ajuda as equipes a se beneficiarem de:

Tempo mais rápido de entrega / mercado
Reduza a incerteza e o risco
Aumente o retorno sobre o investimento (ROI) focando no valor do cliente

Dentre essas diferentes metodologias ágeis, Scrum provou ser extremamente bem sucedido em todo o mundo nos últimos 20 anos.

Scrum é uma estrutura para desenvolver e sustentar produtos complexos. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum. Juntos, eles defendem as Regras do Scrum.

Definição Scrum

Scrum é uma estrutura dentro da qual as pessoas podem resolver problemas adaptativos complexos, ao mesmo tempo que entregam produtos do mais alto valor possível de forma produtiva e criativa.

Scrum é uma estrutura de processo que tem sido usada para gerenciar o desenvolvimento de produtos complexos desde o início dos anos 1990. Scrum não é um processo ou técnica para construir produtos; em vez disso, é uma estrutura dentro da qual você pode empregar vários processos e técnicas. Scrum deixa clara a eficácia relativa de seu gerenciamento de produto e práticas de desenvolvimento para que você possa melhorar.

O framework Scrum consiste em equipes Scrum e suas funções, eventos, artefatos e regras associados. Cada componente dentro do framework serve a um propósito específico e é essencial para o sucesso e uso do Scrum.

As regras do Scrum unem os eventos, funções e artefatos, governando os relacionamentos e a interação entre eles. As regras do Scrum são descritas ao longo deste tutorial.

Note- Em todo o setor, existem conceitos errôneos de que Scrum significa nenhuma documentação, a equipe scrum consiste apenas em desenvolvedores e assim por diante. Não é inteiramente assim; daremos esclarecimentos sobre isso em seções posteriores.

Estrutura do Processo Scrum

No Scrum, os eventos prescritos são usados para criar regularidade. Todos os eventos são eventos cronometrados, de forma que cada evento tem uma duração máxima. Os eventos são descritos de forma mais elaborada nos capítulos subsequentes.

arrancada

O coração do Scrum é um Sprint, um time-box de duas semanas ou um mês durante o qual um incremento de produto potencialmente liberável é criado. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior. Sprints consistem no planejamento do Sprint, scrums diários, o trabalho de desenvolvimento, a revisão do Sprint e a retrospectiva do Sprint.

No planejamento do Sprint, o trabalho a ser executado no Sprint é planejado de forma colaborativa pelo Time Scrum.
O Daily Scrum Meeting é um evento de 15 minutos para o Time Scrum sincronizar as atividades e criar um plano para aquele dia.
Uma revisão do Sprint é realizada no final do Sprint para inspecionar o incremento e fazer alterações no Backlog do produto, se necessário.
A Retrospectiva da Sprint ocorre após a Revisão da Sprint e antes do próximo Planejamento da Sprint. Nesta reunião, o Time Scrum deve se inspecionar e criar um plano de melhorias a serem implementadas durante o Sprint subsequente.

Conclusão

Scrum é uma estrutura de processo que define certas regras, eventos e funções para trazer regularidade. No entanto, pode ser adaptado a qualquer organização, de acordo com as necessidades, desde que as regras básicas do scrum não sejam violadas.

O Time Scrum consiste em três funções, a saber, ScrumMaster, Dono do Produto e o Time.

Scrum Master

O ScrumMaster (às vezes escrito como Scrum Master, embora o termo oficial não tenha espaço após “Scrum”) é o guardião do processo scrum. Ele / ela é responsável por-

fazendo o processo funcionar sem problemas
removendo obstáculos que afetam a produtividade
organizando e facilitando as reuniões críticas

Proprietário do produto

O Product Owner é responsável por maximizar o valor do produto e o trabalho da equipe. A maneira como isso é feito pode variar amplamente entre organizações, equipes Scrum e indivíduos.

O Product Owner é a única pessoa responsável por gerenciar o Product Backlog. O gerenciamento do Backlog do produto inclui-

Expressar itens do Backlog do produto com clareza.
Solicitar os itens do Backlog do produto para melhor atingir as metas e missões.
Otimizando o valor do trabalho que a Equipe realiza.
Garantir que o Backlog do produto seja visível, transparente e claro para todos e mostre no que a equipe trabalhará posteriormente.
Garantir que a equipe compreenda os itens do Backlog do produto no nível necessário.

O Product Owner pode fazer o trabalho acima ou deixar que a equipe o faça. No entanto, o Product Owner permanece responsável por essas tarefas.

O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar os desejos de um comitê no Product Backlog, mas aqueles que desejam alterar a prioridade de um item do Product Backlog devem se dirigir ao Product Owner.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar suas decisões. As decisões do Product Owner são visíveis no conteúdo e na ordem do Product Backlog. Ninguém tem permissão para dizer à Equipe para trabalhar com um conjunto diferente de requisitos, e a Equipe não tem permissão para agir de acordo com o que os outros dizem. Isso é garantido pelo ScrumMaster.

O time

A equipe é auto-organizada e multifuncional. Isso significa que a equipe é composta por analistas, designers, desenvolvedores, testadores, etc., conforme apropriado e relevante para o projeto.

Algumas pessoas na indústria se referem a essa equipe como equipe de desenvolvimento. No entanto, essa referência está gerando polêmica de que a equipe pode ter apenas desenvolvedores e nenhuma outra função. É um entendimento óbvio de que é apenas um equívoco. Para desenvolver um produto de software, exigimos todas as funções e essa é a essência do scrum - a equipe funcionará em colaboração. As equipes multifuncionais têm todas as competências necessárias para realizar o trabalho sem depender de outras pessoas que não fazem parte da equipe e, assim, tempo e esforço podem ser economizados. O modelo de equipe no Scrum é projetado para otimizar a flexibilidade, criatividade e produtividade.

O tamanho ideal da equipe é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo em uma Sprint. O tamanho da equipe deve ser mantido na faixa de cinco a nove pessoas, se possível. Menos de cinco membros da equipe diminuem a interação e resultam em menores ganhos de produtividade. Ter mais de nove membros requer muita coordenação.

A equipe scrum trabalha em estreita colaboração, diariamente, para garantir o bom fluxo de informações e a rápida resolução de problemas. A equipe scrum entrega o produto de forma iterativa e incremental, maximizando as oportunidades de feedback. As entregas incrementais de um produto completo garantem que uma versão potencialmente útil do produto funcional esteja sempre disponível.

ScrumMaster é uma pessoa responsável treinada, que presta serviços conforme descrito abaixo -

Serviços ScrumMaster para o proprietário do produto

O ScrumMaster atende ao Dono do Produto de várias maneiras, incluindo -

Encontrar técnicas para gerenciamento eficaz do Backlog do produto.
Ajudar o Time Scrum a entender a necessidade de itens do Backlog do Produto claros e concisos.
Noções básicas sobre planejamento de produto em um ambiente empírico.
Garantir que o Product Owner saiba como organizar o Product Backlog para maximizar o valor.
Compreendendo e praticando agilidade.
Facilitando eventos Scrum conforme necessário.

Serviços ScrumMaster para a equipe Scrum

O ScrumMaster atende a equipe Scrum de várias maneiras, incluindo -

Treinar a equipe Scrum em auto-organização e funcionalidade cruzada.
Ajudando o Time Scrum a criar produtos de alto valor.
Removendo impedimentos para o progresso do Time Scrum.
Facilitar eventos Scrum conforme solicitado ou necessário.
Treinar o Time Scrum em ambientes organizacionais nos quais o Scrum ainda não foi totalmente adotado e compreendido.

Serviços ScrumMaster para a organização

O ScrumMaster atende a organização de várias maneiras, incluindo-

Liderar e treinar a organização na adoção do Scrum.
Planejando implementações de Scrum dentro da organização.
Ajudar os funcionários e partes interessadas a compreender e implementar o Scrum e o desenvolvimento empírico de produtos.
Causando mudanças que aumentam a produtividade do Time Scrum.
Trabalhar com outros ScrumMasters para aumentar a eficácia da aplicação do Scrum na organização.

Conclusão

O Scrum Process Framework pode ser visualizado por meio de uma sequência de eventos e os artefatos correspondentes. Os eventos Scrum são eventos cronometrados. Isso significa que, em um projeto, cada evento scrum tem uma duração máxima predefinida. Esses eventos permitem transparência sobre o andamento do projeto para todos os que estão envolvidos no projeto. Os eventos vitais do scrum são-

The Sprint
Sprint Planning
Reuniões diárias de Scrum
The Sprint Review
A Retrospectiva Sprint

The Sprint

Durante uma Sprint, um incremento de produto funcional é desenvolvido. Geralmente tem duração de duas semanas ou um mês, e essa duração permanece constante para todos os sprints do projeto. Não podemos ter durações variáveis para os diferentes sprints em um projeto. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

O objetivo do Sprint é um objetivo definido para o Sprint. Ele fornece orientação à equipe sobre o motivo pelo qual está construindo o incremento. Ele é criado durante a reunião de planejamento do Sprint. O escopo do sprint é esclarecido e renegociado entre o Dono do Produto e a Equipe à medida que mais informações sobre os requisitos são aprendidas. Assim, cada Sprint está associado a ele, uma definição do que deve ser construído, um design e o plano flexível que irá orientar a construção, o trabalho de desenvolvimento e o incremento do produto resultante.

Um Sprint deve ser cancelado se o objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se a organização mudar de direção ou se as condições de mercado ou tecnologia mudarem. Um sprint pode ser cancelado apenas pelo product owner, embora outros tenham influência sobre o mesmo.

Devido à natureza de curta duração dos Sprints, o cancelamento durante um sprint raramente faz sentido. Como os cancelamentos de sprint consomem recursos, por serem reorganizados em outro Sprint, eles são muito incomuns.

Se um Sprint for cancelado e parte do trabalho produzido durante o Sprint for potencialmente liberável, o Product Owner normalmente o aceita. Todos os itens do Sprint Backlog incompletos são colocados de volta no Product Backlog.

Sprint Planning

O trabalho a ser executado no Sprint é planejado na Reunião de Planejamento do Sprint. A Reunião de Planejamento de Sprint tem duração máxima de quatro horas para sprints de duas semanas e oito horas para Sprints de um mês. É responsabilidade do Scrum Master garantir que a reunião ocorra e que todos os participantes necessários estejam presentes e entendam o propósito da reunião agendada. O Scrum Master moderará a reunião para monitorar a sustentação da discussão e o encerramento no tempo.

O Sprint Planning se concentra nas duas questões a seguir -

O que precisa ser e pode ser entregue no incremento da sprint?
Como será realizado o trabalho necessário para a execução do Sprint?

As entradas para esta reunião são -

O Backlog do Produto
O incremento do produto mais recente
Capacidade projetada da equipe durante o Sprint
Desempenho anterior da equipe

O Time Scrum discute a funcionalidade que pode ser desenvolvida durante o Sprint. O Product Owner fornece esclarecimentos sobre os itens do Product Backlog. A equipe seleciona os itens do Product Backlog para a Sprint, pois são os melhores para avaliar o que podem realizar na Sprint. A equipe é composta por analistas, designers, desenvolvedores e testadores. O trabalho é realizado de forma colaborativa, minimizando o retrabalho.

O Time Scrum então apresenta o objetivo do Sprint. A meta do Sprint é um objetivo que fornece orientação à equipe sobre por que está construindo o incremento do produto. A equipe então decide como construirá a funcionalidade selecionada em um incremento de produto funcional durante a Sprint. Os itens do Product Backlog selecionados para este Sprint mais o plano para entregá-los são chamados de Sprint Backlog.

O trabalho durante um sprint é estimado durante o planejamento do sprint e pode ter vários tamanhos e / ou esforços. Ao final da reunião de Sprint Planning, o trabalho é dividido em tarefas de duração de um dia ou menos. Isso é para permitir a facilidade de alocação de trabalho e rastreamento da conclusão. Se a equipe perceber que tem muito ou pouco trabalho, ela pode renegociar os itens do Backlog do produto selecionados com o Product Owner.

O Time também pode convidar outras pessoas (não fazendo parte do Time Scrum) para participar da reunião de Planejamento do Sprint para obter conselhos técnicos ou de domínio ou ajuda na estimativa.

Reuniões diárias de Scrum

O Daily Scrum Meeting é uma reunião de 15 minutos para o Time, realizada diariamente para entender rapidamente o trabalho desde a última Daily Scrum Meeting e criar um plano para as próximas 24 horas. Esta reunião também é conhecida como Reunião Diária.

O Daily Scrum Meeting é realizado no mesmo horário e local todos os dias para reduzir a complexidade.

Durante a reunião, cada membro da equipe explica -

O que ele fez ontem que ajudou a equipe a cumprir a meta do Sprint?
O que ele fará hoje para ajudar a equipe a cumprir a meta do Sprint?
Ele vê algum impedimento que o impeça ou a equipe de cumprir a meta do Sprint?

O Daily Scrum é confundido com um evento de rastreamento de status, embora, na verdade, seja um evento de planejamento.

A entrada para a reunião deve ser como a equipe está se saindo em direção ao objetivo do Sprint, e a saída deve ser um plano novo ou revisado que otimiza os esforços da equipe para atingir o objetivo do Sprint.

Embora o Scrum Master coordene a Reunião Daily Scrum e garanta que os objetivos da reunião sejam alcançados, a Reunião é de responsabilidade do Time.

Se necessário, o Time pode se reunir imediatamente após a Reunião Diária do Scrum, para quaisquer discussões detalhadas, ou para replanejar o resto do trabalho do Sprint.

A seguir estão os benefícios das reuniões diárias Scrum -

Melhore a comunicação dentro da equipe.
Identificar impedimentos, se houver, de forma a facilitar a retirada antecipada dos mesmos, de forma a minimizar o impacto no Sprint.
Destaque e promova tomadas de decisão rápidas.
Melhorar o nível de conhecimento da equipe.

Revisão de Sprint

Uma revisão do Sprint é realizada no final de cada Sprint. Durante a Sprint Review, uma apresentação do incremento que está sendo lançado é revisada. Nesta reunião, o Time Scrum e os stakeholders colaboram para entender o que foi feito no Sprint. Com base nisso, e em quaisquer alterações no Backlog do produto durante a Sprint, os participantes chegam às próximas etapas necessárias que podem otimizar o valor. Assim, o objetivo da Sprint Review é obter feedback e progredir em conjunto.

A Sprint Review é normalmente realizada por duas horas para sprints de duas semanas e por quatro horas para sprints de um mês.

O Scrum Master garante que -

A reunião acontece.
Os participantes entendem o propósito.
A reunião é focada na agenda necessária e é concluída dentro da duração exigida.

A Sprint Review inclui os seguintes aspectos -

Os participantes incluem o Time Scrum e os principais interessados, conforme convidados pelo Dono do Produto.
O Product Owner explica quais itens do Backlog do Produto foram concluídos durante o sprint e quais não foram.
A Equipe discute o que deu certo durante a Sprint, quais problemas ocorreram e como esses problemas foram resolvidos.
A equipe demonstra o trabalho que concluiu e responde a perguntas, se houver, sobre o incremento.
Todo o grupo discute o que fazer a seguir. Portanto, a Revisão do Sprint fornece uma entrada valiosa para o Planejamento do Sprint do Sprint subsequente.
A equipe Scrum então analisa o cronograma, orçamento, recursos potenciais e mercado para o próximo lançamento antecipado do incremento do produto.
O resultado da Revisão do Sprint é um Backlog do Produto atualizado, que define os prováveis itens do Backlog do Produto para o próximo Sprint.

Retrospectiva de Sprint

A Retrospectiva da Sprint ocorre após a Revisão da Sprint e antes do próximo Planejamento da Sprint. Geralmente é uma reunião de uma hora para sprints de duas semanas e uma reunião de três horas para Sprints de um mês.

O objetivo da Retrospectiva Sprint é -

Combine os aprendizados do último Sprint, no que diz respeito a pessoas, relacionamentos, processos e ferramentas.
Identifique os principais itens que deram certo e melhorias potenciais.
Elaboração de plano de implantação de melhorias para aumento da qualidade do produto.

A Retrospectiva do Sprint é uma oportunidade para o Time Scrum introspectar e melhorar dentro da estrutura do processo Scrum de modo a tornar o próximo resultado do Sprint mais eficaz.

Reference

Os artefatos do Scrum fornecem informações importantes que o Time Scrum e as partes interessadas precisam estar cientes para compreender o produto em desenvolvimento, as atividades realizadas e as atividades sendo planejadas no projeto. Os seguintes artefatos são definidos no Scrum Process Framework -

Backlog do produto
Sprint Backlog
Gráfico Burn-Down
Increment

Esses são os artefatos mínimos necessários em um projeto scrum e os artefatos do projeto não são limitados por eles.

Backlog do produto

O Product Backlog é uma lista ordenada de recursos que são necessários como parte do produto final e é a única fonte de requisitos para quaisquer mudanças a serem feitas no produto.

O Product Backlog lista todos os recursos, funções, requisitos, aprimoramentos e correções que constituem as alterações a serem feitas no produto em versões futuras. Os itens do Backlog do produto têm os atributos de uma descrição, pedido, estimativa e valor. Esses itens são normalmente chamados de Histórias de usuários. O Product Owner é responsável pelo Product Backlog, incluindo seu conteúdo, disponibilidade e pedidos.

Um Product Backlog é um artefato em evolução. A versão mais antiga pode conter apenas os requisitos inicialmente conhecidos e mais bem compreendidos. O Product Backlog é desenvolvido à medida que o produto e o ambiente no qual será usado progridem. O Backlog do produto muda constantemente para incorporar o que é necessário para torná-lo eficaz. Enquanto um produto existir, seu Product Backlog também existirá.

À medida que o produto em construção é usado e ganha valor, o Product Backlog se torna uma lista maior e mais exaustiva. Mudanças nos requisitos de negócios, condições de mercado ou tecnologia causam mudanças no Backlog do Produto, tornando-o um artefato ativo.

O refinamento do Backlog do Produto significa adicionar detalhes, estimativas e ordem de prioridade aos itens do Backlog do Produto. Este é um processo contínuo executado pelo Dono do Produto e pela Equipe. O Time Scrum decide como e quando o refinamento deve ser feito.

Os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.

Os itens do Backlog do produto de maior ordem geralmente são mais claros e detalhados do que os de menor ordem. Estimativas mais precisas são feitas com base na maior clareza e detalhes aumentados. Quanto menor a ordem, menor é o detalhe.

Os itens do Backlog do produto que podem ser os requisitos candidatos para o próximo Sprint são refinados para que esses itens possam ser desenvolvidos durante o Sprint. Os itens do Backlog do produto que podem ser desenvolvidos pela equipe em um Sprint são considerados prontos para seleção em uma reunião de planejamento do Sprint.

Sprint Backlog

O Sprint Backlog é o conjunto de itens do Product Backlog selecionados para o Sprint, mais um plano para entregar o incremento do produto e atingir a meta do Sprint.

O Sprint Backlog é uma previsão da equipe sobre qual funcionalidade será disponibilizada no próximo incremento e o trabalho necessário para entregar essa funcionalidade como um incremento de produto funcional.

O Sprint Backlog é um plano com detalhes suficientes que pode ser entendido, mas o Time para acompanhar no Daily Scrum. A equipe modifica o Sprint Backlog ao longo do Sprint, e o Sprint Backlog surge durante o Sprint. Esse surgimento ocorre à medida que a equipe trabalha com o plano e aprende mais sobre o trabalho necessário para atingir a meta do Sprint.

Conforme um novo trabalho é necessário, a Equipe o adiciona ao Sprint Backlog. Conforme o trabalho é executado ou concluído, o trabalho restante estimado é atualizado. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente a equipe pode alterar seu Backlog da Sprint durante uma Sprint. O Sprint Backlog é uma imagem em tempo real altamente visível do trabalho que o Time planeja realizar durante o Sprint e pertence exclusivamente ao Time.

Incremento

O incremento é a soma de todos os itens do Backlog do produto concluídos durante uma Sprint combinada com os incrementos de todas as Sprints anteriores. No final de um Sprint, o novo incremento deve ser um produto funcional, o que significa que deve estar em condições de uso. Deve estar em condições de funcionamento, independentemente de o Dono do Produto decidir realmente liberá-lo.

O Time Scrum precisa ter consenso sobre o que é considerado um incremento. Isso varia significativamente por Time Scrum, mas os membros da equipe devem ter um entendimento compartilhado do que significa que o trabalho seja concluído. Isso é usado para avaliar quando o trabalho está concluído no incremento do produto.

O mesmo entendimento orienta a equipe a saber quantos itens do Backlog do produto ela pode selecionar durante um planejamento de sprint. O objetivo de cada Sprint é fornecer incrementos de funcionalidade potencialmente liberável.

As equipes fornecem um incremento da funcionalidade do produto a cada Sprint. Este incremento é utilizável, portanto, um Product Owner pode optar por liberá-lo imediatamente. Se o entendimento de um incremento faz parte das convenções, padrões ou diretrizes da organização de desenvolvimento, todos os Times Scrum devem segui-lo no mínimo. Se não for uma convenção da organização de desenvolvimento, o Time Scrum deve definir uma definição de incremento apropriada para o produto.

Cada incremento é adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Conforme os Times Scrum amadurecem, espera-se que suas definições de Incrementos se expandam para incluir critérios mais rigorosos para maior qualidade. Qualquer produto deve ter uma definição de incremento que seja um padrão para qualquer trabalho feito nele.

Sprint Burn-Down Chart

A qualquer momento em uma Sprint, o trabalho total restante no Backlog da Sprint pode ser somado. A equipe rastreia esse trabalho total restante para cada Daily Scrum para projetar a probabilidade de atingir a meta do Sprint. Rastreando o trabalho restante ao longo da Sprint, a equipe pode gerenciar seu progresso.

Sprint Burn-Down Chart é uma prática para a tendência do trabalho despendido pelo Time Scrum. Esta tem se mostrado uma técnica útil no monitoramento do progresso da Sprint em direção ao objetivo da Sprint.

O Product Owner acompanha este trabalho total restante, pelo menos, a cada Sprint Review. O Product Owner compara essa quantidade com o trabalho restante nas revisões anteriores do Sprint para avaliar o progresso em direção à conclusão do trabalho projetado no tempo desejado para a meta. Essas informações são compartilhadas com todas as partes interessadas.

Conclusão

As funções, eventos, artefatos e regras do Scrum são inevitáveis. Se apenas algumas partes do Scrum são implementadas, o resultado não é Scrum. Scrum precisa ser implementado em sua totalidade e funcionar bem se estiver alinhado com outras técnicas, metodologias e práticas.

Reference

Como você entendeu, as Estórias de Usuário são comumente usadas para descrever os recursos do produto e farão parte dos Artefatos Scrum - Product Backlog e Sprint Backlog.

Histórias de usuários

No desenvolvimento de software, os recursos do produto desempenham um papel crucial. São os recursos que o usuário mais gosta de usar no produto final. Eles são conhecidos como Requisitos na terminologia geral. O sucesso do projeto de desenvolvimento de software reside na compreensão dos requisitos do usuário de forma precisa e adequada e, em seguida, implementá-los no produto final. Portanto, os requisitos ou recursos do produto precisam ser totalmente conhecidos pela equipe do projeto de desenvolvimento.

Em 1999, Kent Beck criou o termo User Stories para os recursos do produto. Ele descreveu que uma história de usuário é narrada da perspectiva do usuário em relação ao que ele deseja ter, em vez do que o sistema pode fazer por ele. Assim, a visão mudou completamente de produto para usuário e as Estórias de Usuário se tornaram o padrão de fato para Requisitos em todos os frameworks Agile.

Em projetos Scrum, o Product Backlog é uma lista de histórias de usuários. Essas Estórias de Usuário são priorizadas e levadas para o Backlog da Sprint na Reunião de Planejamento da Sprint.

A estimativa também é baseada em histórias de usuários e o tamanho do produto é estimado em pontos de histórias de usuários.

A estrutura da história do usuário

A estrutura da história do usuário é a seguinte -

Como um <tipo de usuário> ,

Eu quero <para realizar alguma tarefa> ,

Para que <eu possa atingir algum objetivo / benefício / valor> .

Vejamos como uma história de usuário é estruturada para o cenário de um cliente bancário retirando dinheiro de um caixa eletrônico.

História do usuário: Retirada de dinheiro do cliente

Como um Customer,

eu quero withdraw cash from an ATM,

De modo a I don't have to wait in line at the Bank

Critérios de aceitação de história de usuário

Cada história de usuário também tem um critério de aceitação definido, de forma que a correção da implementação da história de usuário é confirmada passando no teste de aceitação que é baseado no critério de aceitação.

A seguir estão os exemplos de critérios de aceitação para o exemplo de Retirada de Dinheiro do Cliente de História de Usuário.

Acceptance Criterion 1:

Given que a conta tem crédito

E o cartão é válido
E o distribuidor contém dinheiro,

When o cliente pede o dinheiro

Then garantir que a conta seja debitada

E garantir que o dinheiro seja distribuído
E certifique-se de que o cartão seja devolvido.

Acceptance Criterion 2:

Given que a conta está a descoberto

E o cartão é válido

When o cliente pede o dinheiro

Then certifique-se de que a mensagem de rejeição seja exibida

E garantir que o dinheiro não seja distribuído
E certifique-se de que o cartão seja devolvido.

Escrever histórias de usuários

O Product Owner é responsável pelo Product Backlog e, portanto, pelas User Stories. No entanto, isso não significa que apenas o product owner escreve as histórias de usuário. Qualquer pessoa na equipe Scrum pode escrever as histórias de 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 em histórias de usuários

É possível incorporar os requisitos não funcionais também nas histórias de 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 do usuário são gerenciadas no Backlog do produto. As histórias de usuário são ordenadas de acordo com a prioridade. As histórias de usuário mais priorizadas são refinadas para um nível granular, enquanto as histórias de usuário de menor prioridade são mantidas em um nível de detalhe menor. Para cada sprint, as histórias de usuário mais priorizadas e, portanto, mais granuladas são incluídas no backlog do sprint. Se uma história de usuário for adicionada ao backlog do produto, sua prioridade é primeiro determinada e colocada de acordo com seu lugar de acordo com a prioridade. As histórias de usuário podem ser priorizadas a qualquer momento. Também é possível remover qualquer uma das histórias de 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 ocorre 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 própria história do usuário garante a captura da meta, benefício ou valor que o usuário deseja alcançar.
Uma vez que os critérios de aceitação fazem parte da própria história do usuário, será uma vantagem adicional para o Time Scrum.
É possível fazer alterações em uma história de usuário durante a execução do projeto. Se o escopo da história do usuário se tornar grande, ela precisará ser dividida em histórias de usuário menores. As condições no critério de aceitação também podem ser alteradas.
À medida que os incrementos do produto de trabalho são entregues aos usuários no final de cada sprint, a equipe scrum pode obter feedback dos usuários na reunião de revisão do sprint. Isso permite a incorporação de feedback no produto continuamente.

Conclusão

As Estórias de Usuário do Scrum aproximam os usuários da equipe Scrum e evita surpresas de última hora.

O rastreamento do sprint geralmente é feito usando o Burn-Down Chart. O Gráfico Burn-Down mostra o esforço restante em horas do dia. Por exemplo, vamos considerar um sprint de 2 semanas -

Sprint Duration: 2 semanas

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

Conseqüentemente, o esforço total restante no início do sprint é 2 * 5 * 6 * 6 = 360 horas.

Portanto, em um cenário ideal, 36 horas de trabalho são reduzidas no trabalho restante e o gráfico burn-down fica com o seguinte -

Se o trabalho de sprint for feito conforme planejado diariamente, o progresso do scrum estará quase alinhado à barra ideal.

Se o trabalho de sprint atrasar e o compromisso de tempo não for cumprido, o gráfico burn-down é o seguinte -

Mas, como o gráfico burn-down é desenhado diariamente e a derrapagem é conhecida antecipadamente, ações corretivas podem ser tomadas para cumprir a linha de tempo do sprint. Suponha que a equipe se estenda para cumprir a linha do tempo, o gráfico burn-down se parece com o seguinte -

Assim, em qualquer ponto no tempo em um Sprint, o trabalho total restante no Sprint pode ser visualizado e a possibilidade de cumprir o cronograma do Sprint pode ser melhorada.

Conclusão

Os gráficos de burn-down ajudam a equipe Scrum a manter o controle de seu progresso e o que precisa ser feito para cumprir a meta do sprint.

Em projetos Scrum, a estimativa é feita por toda a equipe durante a reunião de planejamento do Sprint. O objetivo da Estimativa seria considerar as Estórias de Usuário para o Sprint por Prioridade e pela Capacidade da equipe de entregar durante o Time Box do Sprint.

O Dono do Produto garante que as Estórias de Usuário priorizadas sejam claras, possam ser sujeitas a estimativa e sejam trazidas para o início do Backlog do Produto.

Como o Time Scrum no total é responsável pela entrega do incremento do produto, cuidado seria tomado ao selecionar as Estórias de Usuário 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 da história do usuário. Uma vez determinado o tamanho, o esforço é estimado por meio dos dados anteriores, ou seja, esforço por User Story Point denominado Produtividade.

Técnicas de estimativa de Scrum

O Scrum Estimation of User Stories é em termos do grau de dificuldade para cada uma das User Stories. Para avaliar o grau de dificuldade, uma escala particular é usada.

Existem vários tipos de escalas que são usadas na Estimativa do Scrum. A seguir estão alguns exemplos -

Dimensionamento numérico (1 a 10)
Tamanhos de camisetas (XS, S, M, L, XL XXL, XXXL)
Sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc.)
Raças de cães (Chihuahua, ………, Dogue Alemão)

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

Técnica de planejamento de pôquer

Na Técnica de estimativa do Planning Poker, as estimativas para as histórias do usuário são derivadas do jogo de planning poker. Todo o Time Scrum está envolvido e isso resulta em estimativas rápidas, mas confiáveis.

O Planning Poker é jogado com um baralho de cartas. Como a sequência de Fibonacci é usada, as cartas têm números - 1, 2, 3, 5, 8, 13, 21, 34, etc. Esses números representam os Story Points. Cada avaliador possui um baralho de cartas. Os números nos cartões devem ser grandes o suficiente para serem visíveis a todos os membros da equipe, quando um dos membros da equipe segura um cartão.

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

Cada avaliador seleciona em particular uma carta que representa sua estimativa. Os cartões não são exibidos até que todos os estimadores tenham feito uma seleção. Nesse momento, todos os cartões são virados e erguidos simultaneamente 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 a razão de suas estimativas. Deve-se ter cuidado para que todas as discussões sejam destinadas apenas para compreensão e nada seja para ser levado pessoalmente. O moderador deve garantir o mesmo.

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

O moderador pode fazer anotações sobre a discussão que serão úteis quando a história específica for desenvolvida. Após a discussão, cada estimador faz uma nova estimativa, selecionando novamente um cartão. Os cartões são mais uma vez mantidos em sigilo até que todos façam uma estimativa, momento em que são entregues ao mesmo tempo.

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

Benefícios do Planning Poker Estimation

O Planning Poker combina três métodos de estimativa -

Expert Opinion: Em uma abordagem de estimativa baseada em opinião de especialista, pergunta-se a um especialista quanto tempo algo levará ou quão grande será. O especialista fornece uma estimativa com base em sua experiência, intuição ou intuição.

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

Analogy: A estimativa de analogia usa a comparação de histórias de usuários. A história de usuário sob estimativa é comparada com histórias de usuário semelhantes implementadas anteriormente. Isso resulta em resultados precisos, pois a estimativa é baseada em dados comprovados.

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

Conclusão

O Planning Poker é uma abordagem divertida, mas produtiva para fazer estimativas. Como a sessão está aberta para discussões antes que a estimativa final seja atingida, seria fácil para a equipe chegar a um consenso e também ter uma visão ampla da implementação da User Story em questão.

As Ferramentas Scrum facilitam o planejamento e acompanhamento de projetos Scrum. Eles fornecem um único local para gerenciar o backlog de produto, sprint backlog, planejamento e rastreamento de Sprints, exibindo gráficos Burndown, conduzindo reuniões diárias do Scrum e conduzindo retrospectivas do Scrum.

Existem muitos tipos diferentes de Ferramentas Scrum disponíveis. Alguns são gratuitos (código aberto), alguns são pagos e, para alguns, você obtém uma versão destilada da ferramenta. No entanto, para obter todos os recursos e escalabilidade, você precisa comprar uma versão completa.

Ferramentas Scrum Disponíveis

A seguir está uma lista de algumas Ferramentas Scrum disponíveis no mercado atualmente. As ferramentas de código aberto são marcadas com asterisco.

Axosoft	Airgile	Agile Cockpit	Jira (GreenHopper)	Misturar-se
Scrumwise	Agilo For Scrum	Banana Scrum	Kunagi	OnTime Now
Versão Um	AgileWrap	Daily-Scrum	Intervals	Pango Scrum
Acunote	Ferramenta Agile Tracking *	Digaboard *	Agilidade iMeta	Pivotal Tracker
Agenda Agile	Tarefa Ágil	EasyBacklog	Ice Scrum *	pmScrum
Banco Ágil	Sopa ágil	Explicar PMT	Hansoft	Planejador Prj
Agile Buddy	Gerente Ágil	Agile Express *	GravityDev	Cartões de Projeto
Agile Fant *	Log Agile	Fire Scrum *	Fulcro*	Quantum Whisper
Quick Scrum	Retrospectiva *	Scrum'd	Scrum Factory *	Scrumpy
Rally Dev	Scrinch *	Painel Scrum *	Scrum Edge	Scrum Pad
Backlogs do Redmine	Scrum 2 Go	Scrum Desk	Scrum Do	Tweet Scrum
Scrumrf	Tempo de Scrum *	Scrumwise	Selecione Solution Factory	Enfrentar*
Tartaruga urbana	ScrumTool	Scrum funciona	Timebox	Tangy Orange Scrum

Conclusão

Ágil em geral, Scrum em específico não significa que não haja trabalho de documentação. Os artefatos do Scrum são definidos, o planejamento e o rastreamento do Scrum estão bem estabelecidos.

As Ferramentas Scrum facilitam a captura e rastreamento de informações sobre os Projetos Scrum. A escolha da ferramenta depende dos recursos exigidos pela organização, além da necessidade de qualquer outra ferramenta.

Scrum oferece suporte à colaboração contínua entre o cliente, membros da equipe e partes interessadas relevantes. Sua abordagem com limite de tempo e feedback contínuo do proprietário do produto garantem um produto funcional com recursos essenciais o tempo todo. Além disso, Scrum fornece benefícios diferentes para as diferentes funções no projeto.

Benefícios para o cliente

Os Sprints têm duração mais curta e as histórias de usuários priorizadas são consideradas em cada planejamento de sprints. Ele garante que a cada entrega de sprint, os recursos exigidos pelo cliente sejam incluídos imediatamente. Além disso, se um cliente levanta qualquer solicitação de mudança, ela será absorvida no sprint atual ou incluída no sprint seguinte. Assim, a equipe de desenvolvimento responde rapidamente aos requisitos do cliente.

Benefícios para a organização

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

Benefícios para gerentes de produto

O Gerente de Produto desempenha a função de Dono do Produto no projeto. A responsabilidade do product owner é garantir a satisfação do cliente. Uma vez que Scrum facilita respostas rápidas, priorização de trabalho, absorvendo mudanças, o gerente de produto pode facilmente garantir que o trabalho esteja alinhado às necessidades do cliente, o que por sua vez garante a satisfação do cliente.

Benefícios para gerentes de projeto

O Gerente de Projeto desempenha o papel de Scrum Master no projeto. A natureza colaborativa do Scrum facilita o planejamento e rastreamento fáceis e concretos. O uso de Burndown Charts para entender o trabalho restante e as reuniões do Daily Scrum dão ao Gerente de Projeto consciência sobre o estado do projeto o tempo todo. Essa consciência é essencial para monitorar o projeto e para detectar e resolver os problemas rapidamente.

Benefícios para a equipe de desenvolvimento

Devido à natureza limitada dos sprints e à entrega de incremento de produtos de trabalho no final de cada sprint, a equipe de desenvolvimento fica entusiasmada em ver que seu trabalho é usado imediatamente. A colaboração de equipe integrada faz com que a equipe aproveite o trabalho que realiza. 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.

As certificações Scrum são oferecidas pela Scrum Alliance. As seguintes certificações estão sendo oferecidas -

ScrumMaster certificado (CSM)
Dono do produto certificado Scrum (CSPO)
Profissional certificado em Scrum (CSP)
Coach Certificado de Scrum (CSC)
Treinador Scrum Certificado (CST)

ScrumMaster certificado (CSM)

Certified Scrum Master é a certificação básica para se tornar um membro da Scrum Alliance, desempenhar o papel do Scrum Master e ser elegível para outras certificações. A certificação exige a frequência do curso de CSM. Depois disso, o candidato recebe um e-mail especificando os detalhes da associação ao Scrum e do exame online do CSM. Depois de fazer o exame, o candidato recebe a certificação Certified ScrumMaster (CSM).

Dono do produto certificado Scrum (CSPO)

Certified Scrum Product Owner é a certificação básica para se tornar um membro da Scrum Alliance, desempenhar o papel de Product Owner e ser elegível para outras certificações.

Profissional certificado em Scrum (CSP)

O Certified Scrum Practitioner é a certificação para ScrumMasters e proprietários de produtos experientes. O candidato deve ser um ScrumMaster ou Dono do Produto por pelo menos um ano. O candidato deve enviar uma inscrição contendo uma descrição detalhada do que ele fez na função especificada.

É possível que um candidato adquira a certificação CSP imediatamente após a certificação CSM ou CSPO, desde que o candidato esteja praticando ativamente a função de ScrumMaster ou de Product Owner durante o período necessário.

Coach Certificado de Scrum (CSC)

O Certified Scrum Coach é a certificação para aqueles que se concentram em coaching. A certificação requer que o candidato tenha treinado Times Scrum por meio de sua adoção e domínio do Scrum por pelo menos 1.500 horas nos últimos 5 anos.

Treinador Scrum Certificado (CST)

Certified Scrum Trainer é a certificação para quem deseja dar aulas de CSM ou CSPO. Os candidatos devem ter um CSM ou CSPO, e devem ser um CSP por pelo menos um ano antes de se inscrever.

A seguir estão algumas perguntas frequentes sobre Scrum -

Question: What is the difference between Scrum and Agile Development?

Answer : Desenvolvimento Ágil é uma metodologia de software, enquanto Scrum é uma das estruturas de processo que segue o Ágil.

Question: Are Sprints and Iterations the same?

Answer: Ambos os Sprints de Scrum e Iterações de modelo Iterativo Incremental oferecem incrementos de produtos funcionais. No entanto, eles diferem porque:

Ciclos de vida de Sprint e Iteração são diferentes.
Sprints são time-box, enquanto Iterações não.
A duração dos Sprints é muito menor em comparação com a duração das Iterações.

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer: Scrum Master é uma função que alguém com um cargo preenche. A prática normal é que a pessoa que desempenha o papel de gerente de projeto também desempenhe o papel de ScrumMaster.

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer: Não, uma vez que a propriedade é diferente. O Product Owner cuida do Backlog do produto, da priorização das histórias do usuário e da validação do incremento do produto de trabalho com as histórias do usuário alocadas ao Sprint.

Question: Is it that Scrum Projects need not have any Documentation?

Answer : Não. Projetos Scrum, como quaisquer outros Projetos, requerem documentação, como histórias de usuários, design, casos de teste, etc.

Conclusão

Agile e Scrum não são iguais. Scrum é uma das estruturas de processo que se adaptam ao Agile. O Scrum é recomendado para equipes com membros experientes, pois o Framework requer grande colaboração e auto-organização também. Se as regras do Scrum não forem seguidas estritamente, um projeto pode levar ao fracasso. Portanto, é necessário ter um entendimento adequado dos conceitos do Scrum entre toda a equipe. Uma vez que os Sprints são de curta duração e time-boxed, não há tempo para aprender as especificações do Scrum no trabalho, mesmo quando um Scrum Master monitora continuamente o projeto.