Mais lidas:

Início Site Página 2

Descubra o Caminho Dourado (Golden Path) para uma experiência perfeita do produto

Você já se perguntou qual é o segredo para proporcionar aos usuários a melhor experiência com o seu aplicativo? Apresentamos o ‘Caminho Dourado’ (Golden Path), também conhecido como Key User Journey – o conjunto essencial de etapas que levará seus usuários ao verdadeiro valor do produto.

Diferente de outros caminhos, o Caminho Dourado é a rota ideal, livre de complicações e distrações. Ao invés de pensar em termos de páginas, enxergue-o como uma história fluida e envolvente. Focar nas experiências centrais do produto é fundamental; enquanto os caminhos secundários são importantes, o verdadeiro destaque está no fluxo principal.

Quer você esteja aperfeiçoando um produto já existente ou desenvolvendo algo novo, seguir o Caminho Dourado é a chave para o sucesso.

Como fazer isso?

  1. Liste as histórias de usuário para o uso do produto, caso ele já exista. Se for um novo produto, esboce o caminho ideal com base no seu entendimento.
  2. Destaque o Caminho Dourado entre essas histórias – sua jornada ideal do início ao fim.
  3. Designe um membro da equipe para digitalizar e utilizar o Caminho Dourado durante todo o processo do sprint.

Priorizar o Caminho Dourado irá impulsionar sua equipe na direção certa, proporcionando uma experiência inigualável aos usuários e trazendo ainda mais valor ao seu produto.

Lembre-se, cada etapa conta! O Caminho Dourado é a estrada para o sucesso, guiando-o em direção a uma experiência perfeita para seus usuários.

Vamos praticar!

Vamos supor que você é parte de uma equipe de desenvolvimento de um aplicativo de entrega de comida chamado “FastFoodXpress”. Seu objetivo é melhorar a experiência dos usuários ao fazerem pedidos através do aplicativo. Para isso, você decide aplicar a técnica do “Caminho Dourado” para encontrar a melhor jornada do usuário.

Etapa 1 – Listando as histórias de usuário

Você e sua equipe começam a listar as diferentes histórias de usuário relacionadas ao processo de fazer um pedido no aplicativo “FastFoodXpress”. Algumas dessas histórias podem ser:

  • História 1: Um usuário que já tem uma conta e sabe exatamente o que quer pedir.
  • História 2: Um novo usuário que precisa criar uma conta antes de fazer um pedido.
  • História 3: Um usuário que deseja explorar diferentes opções antes de tomar uma decisão.
  • História 4: Um usuário que quer rastrear seu pedido após fazer a compra.

Etapa 2 – Destacando o Caminho Dourado

Depois de listar todas as histórias, você e sua equipe analisam os fluxos e identificam o Caminho Dourado – a jornada ideal para os usuários que proporcionará a melhor experiência possível. No caso do “FastFoodXpress”, o Caminho Dourado pode ser a seguinte sequência de etapas:

  • O usuário abre o aplicativo e faz login na sua conta (História 1) ou cria uma nova conta rapidamente (História 2).
  • Em seguida, o usuário é direcionado para uma página com os destaques dos principais restaurantes e promoções em destaque (História 3).
  • O usuário seleciona um restaurante de sua preferência e navega pelo menu, escolhendo os itens que deseja pedir.
  • Depois de adicionar todos os itens ao carrinho, o usuário visualiza o resumo do pedido, confirma os detalhes e escolhe a forma de pagamento.
  • Após o pagamento ser concluído, o usuário recebe uma confirmação do pedido e um link de rastreamento para acompanhar o status da entrega (História 4).

Etapa 3 – Implementação e Acompanhamento

Com o Caminho Dourado identificado, sua equipe de desenvolvimento prioriza o aprimoramento dessas etapas para torná-las o mais eficiente e fácil possível para os usuários. Vocês trabalham em melhorias no design, usabilidade e velocidade de carregamento, garantindo que o Caminho Dourado seja a experiência mais fluida no aplicativo.

Após a implementação, vocês acompanham os resultados através de análises de dados e feedback dos usuários. Ao focar no Caminho Dourado, a equipe observa um aumento significativo na taxa de conversão de pedidos, uma redução nas taxas de abandono do carrinho e uma maior satisfação geral dos usuários.

Ao aplicar a técnica do Caminho Dourado, sua equipe foi capaz de otimizar a jornada do usuário no aplicativo “FastFoodXpress”, resultando em uma experiência mais atraente e efetiva para os usuários, além de um aumento no sucesso do negócio.

Princípios de Design

Os princípios de design ajudam a alinhar sua equipe com os valores que orientarão suas decisões de design de produto e, garantirão uma experiência consistente para seus usuários. Estabelecer princípios como uma equipe, ajudará em todo o processo de desenvolvimento de produto, para tornar as revisões e decisões de design mais fáceis. Este método deve ser usado durante a fase de Definição, para garantir que sua equipe esteja aquecida e confortável com o brainstorming.

Os princípios que sua equipe seleciona, devem ser sucintos, mas específicos. Por exemplo, muitos produtos são eficientes, mas poucos são fáceis. Aqui estão vários bons princípios de design e descrições de apoio:

  • Sem esforço: Torna as coisas fáceis mais fáceis e as difíceis possíveis.
  • Perspicaz: Usa várias fontes e sinais para antecipar necessidades e sugerir coisas que são surpreendentemente boas.
  • Atencioso: Aceita crianças. Eu sou amigável. Somos amigáveis. Atento.
  • Humilde: aberto a feedback, aprende com o tempo.

Como realizar?

  1. Apresente o desafio.
  2. Dê à equipe 5 minutos para listar tantos princípios quanto possível. Um por pegajoso.
  3. Tire 10 minutos para compartilhar e agrupar os post-its.
  4. Reserve 10 minutos para votar e decidir sobre os princípios mais fortes para orientar seu projeto ou produto.
  5. Designe um membro da equipe para digitalizar os princípios para uso posterior na fase de validação de seu sprint.
  6. Durante a fase de validação, teste se os usuários relatam as mesmas palavras ao descrever seu projeto ou produto

Métricas & Sinais de Sucesso

Definir um entendimento compartilhado das Métricas de Sucesso é uma etapa vital no Design Sprint para que a equipe resolva os problemas juntos de forma eficaz. Sua equipe concordou com métricas ou sinais de sucesso? Se sim, lembre a todos dos objetivos. Se não, use este tempo para listar e concordar com as métricas e sinais de sucesso.

Qual é a diferença entre indicadores e métricas de sucesso? Os sinais referem-se à presença geral de um comportamento desejável. As métricas são saídas numéricas quantificáveis ​​em relação ao comportamento desejado.

O Google costuma usar o método HEART, que divide o processo de criação de métricas. Ele incentiva a consideração de cinco categorias ao desenvolver metas e métricas correspondentes. Essas categorias são: Felicidade, Engajamento, Aquisição, Retenção e Conclusão de tarefas.

Como Realizar?

Meta

Como primeiro passo, comece pensando no quadro geral: o que você está tentando ajudar os usuários a fazer? Que problema você está tentando resolver?

Sinal

A seguir, considere que mudança no comportamento ou na opinião do usuário, indicaria que você teve sucesso em seus objetivos. Pode haver vários sinais para cada um de seus objetivos.

Métrica

Finalmente, determine como medir o tamanho de qualquer mudança no comportamento ou opinião do usuário. Isso pode ser por meio de pesquisas ou análise de registros.

Exemplificando…

Vamos utilizar como exemplo, a função de pagamento de contas. Sendo assim:

Meta – Os usuários começam a usar o “pagamento inteligente” para pagar suas contas;
Sinal – O usuário clica na ação de “pagar”;
Métrica – A proporção de cliques na ação de “pagar”, que resultam em uma conta paga.

Jornada do Usuário: Entendendo

O User Journey Mapping (mapeamento da jornada do usuário) é um método comum de Design Sprint que mapeia a experiência do usuário passo a passo conforme ele encontra seu espaço de problema ou interage com seu produto. Esse método permite que a equipe entre na mentalidade do usuário e ilumina os pontos fracos, identificando oportunidades para criar experiências de usuário novas ou aprimoradas.

Os mapas de jornada geralmente são para um tipo específico de usuário, também conhecido como persona. Se houver muitos usuários envolvidos no espaço de problema do Design Sprint, vários mapas de jornada podem ser necessários, um para cada tipo de usuário.

Como iniciar um mapa de jornada depende de onde você está no ciclo do produto. Se você está fazendo um Design Sprint para um novo produto e/ou está nos estágios iniciais do ciclo do produto, você pode querer explorar um determinado caso de uso para o seu produto e começar seu mapa de jornada com o ponto de entrada inicial do usuário.

Se você tem um produto existente e está mais adiantado no ciclo, pode começar seu mapa de jornada quando o usuário for apresentado ao seu produto pela primeira vez, quando estiver procurando por seu produto ou quando estiver integrando e/ou configurando uma conta.

Como iniciar?

  1. Comece com a primeira etapa do usuário ou ponto de entrada em sua experiência de produto;

  2. Adicione cada etapa da jornada até que a meta do usuário seja alcançada

  3. Inclua descrições para cada etapa e destaque os pontos problemáticos ao longo da jornada

Como criar uma boa User Story

Todos desejam adentrar nesse universo ágil e começar a escrever User Story. O teórico é de simples entendimento, mas ao começar as primeiras linhas, muitos acabam tendo muitas dificuldades de conseguir criar as histórias de maneira simples e clara. Vamos ajudar!

Usando o conceito INVEST

O acrônimo INVEST ajuda a lembrar de um conjunto de critérios ou lista de verificação amplamente aceito para avaliar a qualidade de uma User Story. Se a história não atender a um desses critérios, a equipe poderá reformulá-la ou até mesmo reescrevê-la (o que geralmente se traduz em rasgar fisicamente o cartão de história antigo e escrever um novo).

Uma boa história de usuário deve ser:

  • Independent (Independente): deve ser independente de uma maneira que permita ser liberada sem depender uma da outra.
  • Negotiable (Negociável): capture apenas a essência da necessidade do usuário, deixando espaço para conversas. A história do usuário não deve ser escrita como contrato.
  • Valuable (Valioso): entrega valor ao usuário final.
  • Estimable (Estimável): as histórias do usuário precisam ser estimadas para que possam ser adequadamente priorizadas e ajustadas aos sprints.
  • Small (Pequena): uma história de usuário é um pequeno pedaço de trabalho que permite sua conclusão em cerca de 3 a 4 dias.
  • Testable (Testável): uma história de usuário deve ser confirmada através de critérios de aceitação pré-escritos.

Como começar a escrever?

Ao começar a escrever User Story, um modelo pode ajudar a garantir que você não comece inadvertidamente a escrever tarefas técnicas.

Modelo de Escrita

As User Stories capturam apenas os elementos essenciais de um requisito:

  • Para quem é?
  • O que ele espera do sistema?
  • Por quê é importante?

Quem?

Define quem é o usuário que tem a necessidade. Pode ser representado por um tipo de usuário do produto, por uma persona ou até mesmo por um usuário específico.

“QUEM” ajuda a criar no leitor da User Story uma imagem mental desse usuário. User Stories que começam “Eu, enquanto um usuário…” ou “Eu, enquanto um cliente…”, portanto, não atingem esse objetivo e devem ser evitadas.

O que?

Define qual é a necessidade do usuário. Tradicionalmente, os requisitos do produto são representados apenas por essa parte.

Por quê?

Define qual o benefício do usuário ao ter a funcionalidade desenvolvida para atender a essa necessidade. Em outras palavras, qual o valor direto obtido pelo usuário.

As User Stories são escritas na linguagem cotidiana e descrevem um objetivo específico (o que) da perspectiva de um indivíduo (quem), juntamente com o motivo (por que) ele / ela deseja. No desenvolvimento de software, o objetivo geralmente é um novo recurso do produto, o indivíduo é algum tipo de usuário final e o motivo é o benefício que o usuário vê no recurso do produto de destino.

Exemplos

O ponto de vista do usuário é o de quem tem um problema (necessidade) ou uma solução? Um problema. Vejamos, a seguir, uma User Story:

“Eu, enquanto Comprador de Livros, quero buscar livros por nome para escolher o que vou comprar.”

Essa é a forma mais comum de se escreverem User Stories e é perfeitamente aceitável. No entanto, buscar livros por nome é um problema ou uma solução? É uma funcionalidade e, portanto, uma solução. Então essa User Story não está realmente expressa sob a perspectiva do usuário. Qual seria o problema do usuário então? Se a reescrevermos da seguinte forma:

“Eu, enquanto Comprador de Livros, quero encontrar um livro cujo nome sei para escolher comprá-lo.”

O problema do usuário nesse caso é encontrar um livro cujo nome conhece, e uma das possíveis soluções é buscar livros por nome. Outra seria mostrar simplesmente uma lista de todos os livros para que ele possa encontrar o que precisa. Não que uma lista seja melhor que uma busca, mas essa alternativa poderia, por exemplo, ser mais adequada para uma versão inicial do sistema devido a seu custo mais baixo.

Expressar a User Story a partir do problema e não de uma solução particular abre espaço para discussões sobre as possíveis soluções para o mesmo problema. Assim, pode fazer com que soluções mais adequadas sejam encontradas.

Detalhando as histórias com os 3Cs

Ron Jeffries, outro dos criadores do XP, descreveu o que se tornou a maneira favorita de pensar nas histórias de usuários. Uma User Story possui três componentes principais, cada um dos quais começa com a letra ‘C’: cartão, conversa e confirmação, para descrever os três elementos de uma história de usuário.

Cartão

O Cartão é a descrição da necessidade do usuário, ou seja, a própria User Story. Essa descrição é concisa, e assim suficiente para apenas identificar qual é e de que se trata essa necessidade. O nome “Cartão” é dado porque frequentemente as User Stories são escritas em cartões de índice ou fichas.

Conversa

São conversas sobre a User Story, por onde a solução de negócios e os detalhes dessa solução são discutidos, negociados, definidos e então documentados na forma de Critérios e Testes de Aceitação. Elas geram uma compreensão compartilhada sobre o que é necessário para que a funcionalidade gere valor de negócio e retorno ao investimento. As conversas são imprescindíveis para o trabalho do Time de Desenvolvimento, uma vez que o Cartão não possui detalhes que permitam que o item seja desenvolvido.

Em geral, participam dessas conversas o Product Owner, membros do Time de Desenvolvimento e outras pessoas de negócios envolvidas, caso haja, mas qualquer pessoa que possa contribuir com detalhes pode participar.

Tomemos como exemplo a User Story do exemplo anterior, “Um Viajante de Turismo quer mostrar sua viagem para seus amigos para lhes causar inveja”. O Time de Desenvolvimento e Product Owner, por meio de conversas, podem concluir que permitir o compartilhamento de fotos e vídeos na rede social do momento diretamente do aplicativo é a solução de negócios desejada, e a partir daí escrevem os Critérios de Aceitação, que serão transformados em Testes de Aceitação automatizados no decorrer do Sprint.

Confirmação

São critérios e testes deles derivados que documentam os detalhes da User Story, definindo seus limites. Ou seja, são regras que estabelecem como a funcionalidade deve se comportar uma vez implementada. Esses critérios são chamados de Critérios de Aceitação e os testes, de Testes de Aceitação.

Enquanto todas as User Stories devem satisfazer à mesma Definição de Pronto, cada User Story possui seu próprio conjunto de Critérios e Testes de Aceitação.

Critérios de Aceitação são expressos por enunciados pequenos e de fácil entendimento. São utilizados para determinar quando a funcionalidade produzida pelo Time de Desenvolvimento está completa e, assim, nada mais deve ser adicionado a ela.

Os Critérios de Aceitação ajudam o Product Owner a determinar para o Time de Desenvolvimento o que ele precisa para que essa funcionalidade propicie valor. A partir desses critérios, o Time de Desenvolvimento gera os Testes de Aceitação.

Os Critérios de Aceitação são negociados e definidos antes do desenvolvimento da funcionalidade, geralmente em sessões de Refinamento do Product Backlog.

Como refinar uma User Story?

As User Stories devem ser identificadas juntamente com as partes interessadas, de preferência por meio de uma reunião presencial. A User Story é um processo de descoberta de requisitos, em vez de um processo inicial de análise de requisitos.

Nas abordagens tradicionais de captura de requisitos, o analista de sistemas tenta entender as necessidades dos clientes e, em seguida, prepara uma especificação de requisitos para o sistema em detalhes. Não é assim que a abordagem da história do usuário funciona. Em vez de um processo de documentação, a identificação da história do usuário é mais como um processo de anotações. Listamos as principais etapas para identificar histórias de usuários da seguinte maneira:

  1. Através das discussões com os usuários, ouvimos e entendemos seus problemas e necessidades
  2. E então, anote suas necessidades como histórias de usuários ao mesmo tempo.
  3. Essas histórias de usuários se tornarão a fonte de requisitos.
  4. Os detalhes podem ser preenchidos posteriormente na hora certa, fornecendo à equipe referências de requisitos “suficientes” durante todo o processo de desenvolvimento do projeto.

Fonte:

O que é User Story?

No desenvolvimento de software e gerenciamento de produtos, uma User Story é uma descrição informal e em linguagem natural de um ou mais recursos de um sistema de software. É uma ferramenta usada no desenvolvimento ágil de software para capturar uma descrição de um recurso de software da perspectiva do usuário final.

Uma User Story descreve o tipo de usuário (Persona), o que eles querem e por quê. Ajuda a criar uma descrição simplificada de um requisito. São frequentemente registradas em cartões de índice, post-it ou em software de gerenciamento de projetos. Dependendo do projeto, podem ser escritas por várias partes interessadas, como clientes, usuários, gerentes ou membros da equipe de desenvolvimento.

Qual sua origem?

  • A sua primeira menção foi no livro de Kent Beck “Extreme Programming Explained”. O texto não estruturado era bastante semelhante aos casos de uso com restrição de tamanho.
  • Ron Jeffries introduziu os conceitos dos 3C’s: cartão, conversa, confirmação em 2001
  • 2003: a lista de verificação do INVEST para avaliar rapidamente as histórias de usuários se origina em um artigo escrito por Bill Wake, que também reformulou o acrônimo SMART (Específico, Mensurável, Alcançável, Relevante, com Prazo) para tarefas resultantes da decomposição técnica de histórias de usuários.
  • 2004: a sigla INVEST está entre as técnicas recomendadas nas “User Stories aplicadas” de Mike Cohn.

Quais ganhos eu terei?

Os requisitos sempre mudam à medida que equipes e clientes aprendem mais sobre o sistema e também à medida que o projeto avança. Não é exatamente realista esperar que as equipes de projeto trabalhem com uma lista de requisitos estáticos e depois entreguem software funcional meses depois.

Com a abordagem da User Story, substituímos o design inicial grande por uma abordagem “apenas o suficiente”. As histórias de usuários reduzem o tempo gasto na elaboração de documentação exaustiva, enfatizando as conversas centradas no cliente.

Consequentemente, as User Stories permitem que as equipes entreguem software de qualidade mais rapidamente, o que os clientes preferem. Existem alguns benefícios em adotar a abordagem da história do usuário no desenvolvimento ágil, como:

  • O formato simples e consistente economiza tempo ao capturar e priorizar requisitos, permanecendo versátil o suficiente para ser usado em recursos grandes e pequenos.
  • Mantenha-se expressando o valor comercial entregando um produto que o cliente realmente precisa
  • Evite introduzir detalhes cedo demais, para impedir opções de design e bloquear inadequadamente os desenvolvedores em uma solução.
  • Evite a aparência de falsa integridade e clareza
  • Obtenha pequenos pedaços que convidam a negociação e movimento na lista de pendências
  • Deixe as funções técnicas para o arquiteto, desenvolvedores, testadores e assim por diante

Conceitos básicos de uma User Story

Uma User Story é um método leve para capturar rapidamente o “quem”, “o quê” e o “porquê” de um requisito de produto. Em termos simples, são idéias declaradas de requisitos que expressam o que os usuários precisam. As User Stories são breves, com cada elemento geralmente contendo menos de 10 ou 15 palavras cada.

As User Stories são listas de “tarefas pendentes” que ajudam a determinar as etapas no caminho do projeto. Eles ajudam a garantir que seu processo, assim como o produto resultante, atenda aos seus requisitos. Ela é definida de forma incremental, em três estágios:

  • A breve descrição da necessidade
  • As conversas que ocorrem durante a preparação da lista de pendências e o planejamento da iteração para solidificar os detalhes
  • Os testes que confirmam a conclusão satisfatória da história

E estes, no entanto, são conhecidos como os 3C’s – Cartão, Conversa e Confirmação.

Métricas para o Scrum

Um dos grandes riscos ao utilizar ferramentas de métricas no ágil é de que o time acabe tendo seu comportamento moldado ao invés de um uso para benefício próprio. A idealização da utilização de métricas no ágil é para que o time possa acompanhar a situação dele dentro do todo.

Perguntas como: “O que já foi feito?” e “O que ainda falta fazer?”; são os principais gatilhos para coletarmos essas informações.

Sprint Burndown

O Sprint Burndown é um gráfico exibido publicamente, mostrando a evolução do trabalho baseado no Sprint Backlog. Atualizado todos os dias, fornece uma visão simples do progresso da sprint. Ele também fornece visualizações rápidas para referência. O eixo horizontal do gráfico mostra os dias em uma sprint, enquanto o eixo vertical mostra a quantidade de trabalho restante a cada dia (normalmente representando a estimativa de horas de trabalho restantes).

Durante o planejamento da sprint, o gráfico de Burndown ideal é plotado. Em seguida, durante a sprint, cada membro seleciona tarefas do backlog da sprint e trabalha nelas. No final do dia, eles atualizam as horas restantes para que as tarefas sejam concluídas. Dessa forma, o gráfico de Burndown real é atualizado dia-a-dia.

Burndown e Burnup no Scrum: como avaliar o desempenho da sua equipe
Gráfico Burndown

Release Burn-up

O Release Burn-up é uma maneira do time fornecer visibilidade e acompanhar o progresso em direção a um release. Atualizado no final de cada sprint, mostra o progresso na entrega de um escopo. O eixo horizontal do gráfico mostra os sprints em uma liberação, enquanto o eixo vertical mostra a quantidade de trabalho concluído no final de cada sprint (geralmente representando pontos acumulados da história do trabalho concluído).

O progresso é plotado como uma linha que cresce para atender a uma linha horizontal que representa o escopo da previsão; geralmente mostrado com uma previsão, com base no progresso até a data, que indica quanto escopo pode ser concluído em uma determinada data de lançamento ou quantas sprints serão necessárias para concluir o escopo especificado.

O Release Burn-up Chart facilita ver quanto trabalho foi concluído, quanto foi adicionado ou removido (se a linha do escopo horizontal se mover) e quanto resta para ser feito.

Burnup
Gráfico Burn-up

Velocidade por Sprint

O esforço total que uma equipe é capaz em uma sprint. O número é obtido pela avaliação do trabalho (normalmente nos pontos da história do usuário) concluído na última sprint. A coleta de dados históricos de velocidade é uma diretriz para ajudar o time a entender quanto trabalho eles provavelmente conseguirão entregar em uma sprint futura.

Velocity Chart Gadget — track sprint initial and final commitments ...
Gráfico de Velocidade

Modelos híbridos do Scrum

Cogwheels and businesspeople working among them. Business process, gear, teamwork. Management concept. Vector illustration can be used for presentation slide, posters, banners

A “hibridação” do Scrum com outras metodologias de desenvolvimento de software é comum, pois o Scrum não cobre todo o ciclo de vida de desenvolvimento do produto; portanto, as organizações encontram a necessidade de adicionar processos adicionais para criar uma implementação mais abrangente. Por exemplo, no início do desenvolvimento do produto, as organizações geralmente adicionam orientações de processo no caso de negócios, coleta e priorização de requisitos, design inicial de alto nível e previsão de orçamento e cronograma.

Vários autores e comunidades de pessoas que usam o Scrum também sugeriram técnicas mais detalhadas de como aplicar ou adaptar o Scrum a problemas ou organizações específicos. Muitos se referem a essas técnicas metodológicas como ‘padrões’ – por analogia com os padrões de design em arquitetura e software.

Scrumban

O Scrumban é um modelo de produção de software baseado em Scrum e Kanban (Leia também: “Kanban“). O método é especialmente adequado para manutenção de produtos com itens de trabalho frequentes e inesperados, como defeitos de produção ou erros de programação. Nesses casos, as sprints por tempo limitado da estrutura do Scrum podem ser vistos como menos benéficos, embora os eventos diários do Scrum e outras práticas ainda possam ser aplicados, dependendo do time e da situação em questão.

A visualização das etapas e limitações do trabalho para defeitos e trabalhos inacabados simultâneos é familiar do modelo Kanban. Usando esses métodos, o fluxo de trabalho da equipe é direcionado de forma a permitir um tempo mínimo de conclusão para cada item de trabalho ou erro de programação e, por outro lado, garante que cada membro do time seja constantemente alocado.

Para ilustrar cada estágio do trabalho, os times que trabalham no mesmo espaço geralmente usam notas post-it ou um quadro branco grande. No caso de times descentralizados, pode ser usado software de ilustração de palco, como Assembla, JIRA ou Agilo.

As principais diferenças entre Scrum e Kanban são que, no Scrum, o trabalho é dividido em sprints que duram um período fixo de tempo, enquanto no Kanban o fluxo de trabalho é contínuo. Isso é visível nas tabelas de estágio de trabalho, que no Scrum são esvaziadas após cada sprint, enquanto no Kanban todas as tarefas são marcadas na mesma tabela. O Scrum se concentra em equipes com know-how multifacetado, enquanto o Kanban possibilita equipes especializadas e funcionais.

Scrum of Scrums

O Scrum of Scrums é uma técnica para operar o Scrum em escala, para várias equipes que trabalham no mesmo produto, permitindo que elas discutam o progresso de suas interdependências, concentrando-se em como coordenar a entrega de software, especialmente em áreas de sobreposição e integração.

Dependendo da cadência (tempo) do Scrum of Scrums, a Daily Scrum relevante para cada time de scrum termina designando um membro como embaixador para participar do Scrum of Scrums. Dependendo do contexto, os embaixadores podem ser colaboradores técnicos ou o Scrum Master de cada equipe.

Em vez de simplesmente uma atualização de progresso, o Scrum of Scrums deve se concentrar em como os times estão trabalhando coletivamente para resolver, mitigar ou aceitar quaisquer riscos, impedimentos, dependências e suposições (RIDAs) identificados.

O método rastreia esses RIDAs por meio de um backlog próprio, como uma placa de risco (às vezes conhecida como placa ROAM após as iniciais de resolvido, de propriedade, aceito e mitigado), o que normalmente leva a uma maior coordenação e colaboração entre times.

Isso deve ser semelhante a uma Daily Scrum, com cada embaixador respondendo às quatro perguntas a seguir:

  • Quais riscos, impedimentos, dependências ou premissas sua equipe resolveu desde a última vez que nos encontramos?
  • Quais riscos, impedimentos, dependências ou suposições sua equipe resolverá antes de nos encontrarmos novamente?
  • Existem novos riscos, impedimentos, dependências ou premissas que tornam sua equipe mais lenta ou atrapalham?
  • Você está prestes a introduzir um novo risco, impedimento, dependência ou suposição que atrapalhará o de outra equipe?

Como Jeff Sutherland disse:

Desde que eu defini originalmente o Scrum of Scrums (Ken Schwaber estava na IDX trabalhando comigo), posso dizer definitivamente que o Scrum of Scrums não é um ‘meta Scrum’. O Scrum of Scrums, como eu o usei, é responsável por entregar o software de trabalho de todas as equipes à Definição de Concluído no final do sprint ou por lançamentos durante o sprint. O Ancestry.com entrega a produção 220 vezes por Sprint de duas semanas. O Hubspot fornece software ao vivo 100-300 vezes por dia. O Scrum of Scrums Master é responsável por fazer esse trabalho. Portanto, o Scrum of Scrums é um mecanismo operacional de entrega.

Os artefatos utilizados no Scrum

Os artefatos e as cerimônias são as características mais peculiares do mindset ágil. De reuniões a quadros cheios de post-it’s, eles estão por toda parte e são um símbolo do informalismo criativo e colaborativo que é a base da transformação cultural que eles trazem às empresas. Falando especificamente do Scrum e, ao contrário do que muita gente pensa, temos pouquíssimos artefatos.

Vamos conhecê-los!

Product Backlog

O Product Backlog é um detalhamento do trabalho a ser realizado e contém uma lista ordenada de requisitos do produto que uma equipe de scrum mantém para um produto. Formatos comuns incluem histórias de usuários. Os requisitos definem recursos, correções de bugs, requisitos não funcionais etc. – tudo o que deve ser feito para fornecer um produto viável. O Product Owner prioriza itens de lista de pendências (PBIs) com base em considerações como risco, valor comercial, dependências, tamanho e data necessários.

Você pode conhecer melhor este artefato extremamente importante é um outro artigo já escrito: “Product Backlog“.

Sprint Backlog

O Sprint Backlog é a lista de atividades que o time de desenvolvimento deve abordar durante a próxima sprint. A lista é derivada pela equipe do scrum que seleciona progressivamente os itens do Product Backlog em ordem de prioridade a partir da parte superior da lista de pendências até sentirem que têm trabalho suficiente para preencher o sprint.

O time de desenvolvimento deve ter em mente seu desempenho passado, avaliando sua capacidade para a nova sprint, e usar isso como uma diretriz de quanto ‘esforço’ eles podem concluir. Os itens do Product Backlog podem ser divididos em tarefas pelo time de desenvolvimento.

As tarefas no Sprint Backlog nunca são atribuídas (ou enviadas) aos membros do time por outra pessoa; em vez disso, os membros do time se inscrevem para (ou realizam) tarefas conforme necessário, de acordo com a prioridade do Product Backlog e suas próprias habilidades e capacidade. Isso promove a auto-organização do time de desenvolvimento e a adesão do desenvolvedor.

A Sprint Backlog é de propriedade do time de desenvolvimento e todas as estimativas incluídas são fornecidas pelo time de desenvolvimento. Muitas vezes, um quadro de tarefas que o acompanha é usado para ver e alterar o estado das tarefas da sprint atual, como fazer, em andamento e concluídas.

Depois que um Sprint Backlog é confirmado, nenhum trabalho adicional pode ser adicionado ao documento, exceto pelo time. Depois que uma sprint é entregue, o Product Backlog é analisado e priorizado, se necessário, e o próximo conjunto de funcionalidades é selecionado para a próxima sprint.

Definition of Ready (DoR)

Os critérios de Definition of Ready servem para determinar se as especificações e entradas estão maduras o suficiente para iniciar o item de trabalho, ou seja, uma história de usuário.

Definition of Done (DoD)

Os critérios de Definition of Done servem para determinar se um item do Product Backlog está completo. Por exemplo, o time de qualidade exige que todos os testes de regressão sejam bem-sucedidos.

A definição de concluído pode variar de uma equipe de scrum para outra, mas deve ser consistente dentro de um time.

As cerimônias do Scrum

Durante uma sprint acontecem uma série de cerimônias responsáveis por garantir a transparência (geralmente através da comunicação, mas também envolvendo artefatos) e proporcionar momentos de inspeção e adaptação tal qual pregam os pilares do Scrum. Estas cerimônias são: a Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.

Sprint Planning

No início de um sprint, o time realiza um evento de planejamento da sprint para:

  • Discutir e concordar mutuamente sobre o escopo do trabalho que deve ser realizado durante a sprint;
  • Selecionar itens de lista do Product Backlog que podem ser concluídos em uma sprint;
  • Preparar um Sprint Backlog que inclua o trabalho necessário para concluir os itens do Product Backlog selecionados;
  • Concordar com a meta da sprint, uma breve descrição do que eles estão planejando entregar no final da sprint;
  • A duração recomendada da cerimônia é de quatro horas para um sprint de duas semanas (proporcionalmente a outros períodos de sprint);
    • Durante o primeiro semestre, todo o time seleciona os itens do Product Backlog que eles acreditam que poderiam ser concluídos nessa sprint;
    • Durante o segundo semestre, o time de desenvolvimento identifica o trabalho detalhado (tarefas) necessário para concluir os itens do Product Backlog; resultando em um backlog confirmado da sprint;
      • À medida que o trabalho detalhado é elaborado, alguns itens do Product Backlog podem ser divididos ou recolocados na lista se o time não acreditar mais que pode concluir o trabalho necessário em um único sprint.
  • Depois que o time de desenvolvimento prepara seu Sprint Backlog, eles prevêem (geralmente por votação) quais tarefas serão entregues no sprint.

Daily Scrum

Todos os dias durante uma sprint, o time realiza um Daily Scrum com diretrizes específicas:

  • Todos os membros do time de desenvolvimento vêm preparados.
    • Começa precisamente na hora certa, mesmo que alguns membros do time de desenvolvimento estejam ausentes;
    • Deve acontecer no mesmo horário e local todos os dias;
    • É limitado a quinze minutos.
  • Qualquer um é bem-vindo, embora apenas os membros do time de desenvolvimento devam contribuir;
  • Durante a Daily Scrum, cada membro da equipe normalmente responde a três perguntas:
    • O que eu completei ontem que contribuiu para a equipe cumprir nosso objetivo de sprint?
    • O que pretendo concluir hoje para contribuir para que a equipe cumpra nossa meta de sprint?
    • Vejo algum impedimento que possa impedir a mim ou a equipe de atingir nossa meta de sprint?

Qualquer impedimento identificados na Daily Scrum devem ser recebidos pelo Scrum Master e exibidos no quadro do time ou em um quadro de risco, compartilhado, com um pessoa acordada designada para trabalhar em direção a uma resolução (fora da Daily Scrum).

Embora a moeda do status do trabalho seja de responsabilidade de toda o time, o Scrum Master geralmente atualiza o gráfico de Burndown do sprint. Onde o time não vê o valor nessas cerimônias, é responsabilidade do Scrum Master descobrir o porquê. Isso faz parte da responsabilidade de educar a equipe e as partes interessadas sobre os princípios do Scrum.

Nenhuma discussão detalhada deve acontecer durante a Daily Scrum. Quando a reunião termina, os membros individuais podem se reunir para discutir as questões em detalhes; essa reunião às vezes é conhecida como ‘sessão de grupo’ ou ‘pós-festa’.

Sprint Review

No final de uma sprint, o time realiza duas cerimônias: a Sprint Review e a Sprint Retrospective.

Na Sprint Review, o time:

  • Analisa o trabalho que foi concluído e o trabalho planejado que não foi concluído;
  • Apresenta o trabalho concluído para as partes interessadas (também conhecida como demo);
  • Colabora com as partes interessadas sobre o que trabalhar na próxima.

Diretrizes para Sprint Review:

  • Trabalho incompleto não pode ser demonstrado;
  • A duração recomendada é de duas horas para um sprint de duas semanas (proporcional a outras durações de sprint).

Sprint Retrospective

Na Sprint Retrospective, o time:

  • Reflete sobre o sprint passado;
  • Identifica e concorda em ações de melhoria contínua de processos;

Diretrizes para Sprint Retrospective:

  • Três questões principais surgem na Sprint Retrospective:
    • O que correu bem durante o sprint?
    • O que não correu bem?
    • O que poderia ser melhorado para alavancar a produtividade no próximo sprint?
  • A duração recomendada é de uma hora e meia para um sprint de duas semanas (proporcional a outras durações);
  • O Scrum Master facilita essa cerimônia.

Outras cerimônias

Backlog Grooming

O Backlog Grooming é o processo contínuo de revisar os itens do Product Backlog e verificar se estão adequadamente preparados e ordenados, de maneira a torná-los claros e executáveis ​​para os times. Os itens do Product Backlog podem ser divididos em vários itens menores. Os critérios de aceitação podem ser esclarecidos. Dependências podem ser identificadas e investigadas.

Embora não seja originalmente uma prática básica do Scrum, o Backlog Grooming foi adicionado ao Guia Scrum e adotado como uma maneira de gerenciar a qualidade dos itens do Product Backlog que entram em uma sprint, com um investimento recomendado de até 10% da capacidade da sprint de um time.

O Product Backlog pode incluir dívida técnica (também conhecida como dívida de design ou dívida de código). Esse é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil agora, em vez de usar uma abordagem melhor que levaria mais tempo.

Cancelamento de Sprint

O Product Owner pode cancelar um sprint, se necessário. Pode fazê-lo com informações do time, do Scrum Master ou da gerência. Por exemplo, a gerência pode desejar que o Product Owner cancele uma sprint se circunstâncias externas negarem o valor da meta da sprint. Se uma sprint for encerrada de forma anormal, a próxima etapa é realizar um novo planejamento da sprint, em que o motivo da rescisão é revisado.