Arquivo para Tag: refinar histórias

User Story – O que preciso saber sobre histórias de usuário

/0 Comentários/em /por

User Story (histórias de usuários) fazem parte de uma abordagem ágil que ajuda a mudar o foco de escrever sobre requisitos para falar sobre eles. Cada história ágil do usuário inclui uma ou duas frases escritas e, mais importante, desencadeia uma série de conversas sobre os recursos e funcionalidades que a história do usuário representa.

As histórias do usuário são uma maneira de descrever a funcionalidade desejada dos itens de lista de pendências do produto. Histórias de usuários de alta prioridade tendem a ser mais detalhadas; histórias de usuários de baixa prioridade tendem a ser menos detalhadas.

As equipes adicionam detalhes à medida que as histórias aumentam em prioridade, criando critérios de aceitação ou dividindo grandes histórias em pedaços menores ( ou ambos ).

O que é uma User Story?

Uma história de usuário é uma descrição curta e simples de um recurso contado da perspectiva da pessoa que deseja o novo recurso, geralmente um usuário ou cliente do sistema. As histórias do usuário geralmente seguem um modelo simples:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Historicamente, as histórias dos usuários eram deliberadamente mantidas informais, escritas em cartões de índice ou notas adesivas, armazenadas em uma caixa de sapatos e dispostas em paredes ou mesas para facilitar o planejamento e a discussão.

Sua impermanência facilitou rasgá-los, jogá-los fora e substituí-los por novas histórias, à medida que se aprendeu mais sobre o produto que está sendo desenvolvido.

Atualmente, as histórias dos usuários podem ser facilmente armazenadas em um problema de Jira ou no quadro de Trello.

Não deixe que o fato de uma história de usuário existir em uma ferramenta o torne menos disposto a descartar histórias quando elas não forem mais necessárias!

As histórias de usuários são projetadas para mudar fortemente o foco, da escrita de recursos para a discussão deles. De fato, essas discussões são mais importantes do que qualquer texto escrito.

O que é uma boa User Story?

As histórias ágeis dos usuários são compostas por três aspectos que Ron Jeffries nomeou em 2001 com a maravilhosa aliteração de cartão, conversa e confirmação:

  1. Cartão: Descrição escrita da história, usada para planejamento e como lembrete
  2. Conversa: Conversas sobre a história que servem para detalhar os detalhes da história
  3. Confirmação: Testes que transmitem e documentam detalhes que podem ser usados para determinar quando uma história está concluída.

As histórias de usuários têm muitas vantagens, mas o mais importante pode ser que toda história de usuário seja um espaço reservado para uma conversa futura.

Como escrever uma história de usuário

Escrever boas histórias de usuários no Scrum requer uma compreensão do modelo básico de história do usuário, um foco no usuário ou cliente e uma imagem clara da funcionalidade desejada.

Modelo de história do usuário

Ao escrever uma história de usuário, lembre-se de que as histórias de usuário seguem um modelo padrão:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Exemplos de histórias de usuários

Uma das melhores maneiras de aprender a escrever uma história de usuário em ágil é ver exemplos. Abaixo está um exemplo de história ou duas de usuário. Estes são alguns exemplos reais de histórias de usuários que descrevem a funcionalidade desejada em uma versão inicial do site da Scrum Alliance.

  • Como membro do site, posso preencher um aplicativo para me tornar um instrutor certificado de scrum para poder ensinar  e certificar outros Scrum Masters ( PSM ) e Product Owners ( PSPO ).
  • Como treinador, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma, para que os possíveis participantes possam encontrar meus cursos.
  • Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para poder acessar as coisas que me lembro do passado ou que outras pessoas mencionam para mim.
  • Como visitante do site, posso ver uma lista de todos os próximos cursos de certificação “ ” e posso paginar por eles se houver muito, para que eu possa escolher o melhor curso para mim.

Observe que você não vê nenhuma história de usuário: “Como proprietário do produto, quero uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário / cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.

Quem escreve histórias de usuários?

Quem escreve histórias de usuários? Qualquer pessoa pode escrever histórias de usuários.

O proprietário do produto escreve histórias de usuários?

É responsabilidade do proprietário do produto garantir a existência de um acúmulo de histórias ágeis de usuários, mas isso não significa que o proprietário do produto seja quem as escreve. Ao longo de um bom projeto ágil, você deve esperar ter histórias de usuários escritas por cada membro da equipe.

Observe também que quem escreve uma história de usuário é muito menos importante do que quem está envolvido nas discussões.

Quando as histórias dos usuários são escritas?

As histórias dos usuários são escritas em todo o projeto ágil. Normalmente, um workshop de redação de histórias é realizado perto do início do projeto ágil.

Todos na equipe participam com o objetivo de criar um backlog do produto que descreva completamente a funcionalidade a ser adicionada ao longo do projeto ou um ciclo de lançamento de três a seis meses dentro dele.

Algumas dessas histórias ágeis de usuários serão, sem dúvida, épicas. Mais tarde, as épicas serão decompostas em histórias menores que se encaixam mais rapidamente em uma única iteração.

Além disso, novas histórias podem ser escritas e adicionadas ao backlog do produto a qualquer momento e por qualquer pessoa.

Você pode mostrar outros exemplos de user history?

Como um exemplo mais genérico de escrever histórias de usuários no Scrum, essas são algumas histórias típicas de usuários para um site de postagem e pesquisa de empregos:

  • Um usuário pode postar seu currículo no site.
  • Um usuário pode procurar empregos.
  • Uma empresa pode postar novas vagas.
  • Um usuário pode limitar quem pode ver seu currículo.

Como os detalhes são adicionados às user historys?

Os detalhes podem ser adicionados às histórias do usuário de duas maneiras:

  • Dividindo uma história de usuário em várias histórias menores de usuário.
  • Adicionando condições de satisfação: Critérios de aceitação ( ).

Quando uma história relativamente grande é dividida em várias histórias de usuários ágeis menores, é natural supor que os detalhes foram adicionados. Afinal, mais foi escrito.

As condições de satisfação são simplesmente um teste de aceitação de alto nível que será verdadeiro após a conclusão da história ágil do usuário. Considere o seguinte como outro exemplo ágil da história do usuário:

Como vice-presidente de marketing, quero selecionar uma temporada de férias a ser usada ao revisar o desempenho de campanhas publicitárias anteriores, para que eu possa identificar as lucrativas.

Detalhes podem ser adicionados a esse exemplo de história do usuário adicionando as seguintes condições de satisfação:

  • Certifique-se de que funcione com as principais férias de varejo: Natal, Páscoa, Dia do Presidente, Dia das Mães, Dia dos Pais, Dia do Trabalho, Dia de Ano Novo.
  • Suporte a feriados que abrangem dois anos civis ( nenhum intervalo três ).
  • As estações de férias podem ser definidas de um feriado para o próximo (, como Ação de Graças ao Natal ).
  • As estações de férias podem ser definidas para vários dias antes do feriado.

As user history substituem um documento de requisitos?

Projetos ágeis, especialmente os Scrum, use um backlog do produto, que é uma lista priorizada da funcionalidade a ser desenvolvida em um produto ou serviço. Embora produto itens de lista de pendências pode ser o que a equipe deseja, as histórias dos usuários surgiram como a melhor e mais popular forma de itens de lista de pendências de produtos.

Enquanto um atraso do produto pode ser considerado um substituto para o documento de requisitos de um projeto tradicional, é importante lembrar que a parte escrita de uma história de usuário ágil ( “ Como usuário, Eu quero … ” ) está incompleto até que as discussões sobre essa história ocorram.

Muitas vezes, é melhor pensar na parte escrita como um ponteiro para o requisito real. As histórias do usuário podem apontar para um diagrama que descreve um fluxo de trabalho, uma planilha mostrando como executar um cálculo ou qualquer outro artefato que o proprietário ou a equipe do produto deseje.

Vantagens do “ Como, quero, para, ”

“Como um , Eu quero,  Para que que .” Embora eu considere a cláusula opcional, eu realmente gosto desse modelo. Em uma conferência, alguém me perguntou o porquê. Como recebo essa pergunta com bastante frequência, quero dar três razões pelas quais aqui:

Razão 1

Algo significativo e estou tentado a dizer que mágico acontece quando os requisitos são colocados na primeira pessoa. Obviamente, dizendo “Como tal e tal, eu quero …”, você pode ver como a mente da pessoa se move instantaneamente para imaginar que ela é uma pessoa assim. Quanto à mágica, Paul McCartney foi entrevistado e perguntado sobre por que as músicas dos Beatles eram tão incrivelmente populares. Uma de suas respostas foi que suas músicas foram as primeiras a usar muitos pronomes.

She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. Seu argumento era que isso ajudava as pessoas a se identificarem mais de perto com as músicas.

Você pode ler mais sobre o Uso de pronomes pelos Beatles neste artigo.

Razão 2

Ter uma estrutura nas histórias realmente ajuda o proprietário do produto a priorizar. Se o backlog do produto for uma mistura de coisas como:

  • Entrega de exceção fixa
  • Deixe os usuários fazerem reservas
  • Os usuários querem ver fotos
  • Mostrar opções de tamanho do quarto

… e assim por diante, o proprietário do produto precisa trabalhar mais para entender qual é o recurso, quem se beneficia e qual é o valor dele.

Razão 3

Ouvi um argumento de que escrever histórias com esse modelo suprime o conteúdo informativo da história, porque há muito texto comum. Se você achar isso verdade, corrija-o na maneira como apresenta a história. Vi atrasos no Word que apresentam o texto comum em texto acinzentado com as partes exclusivas em preto.

Criei backlogs de produtos no Excel que usam títulos de colunas para filtrar o texto comum.

Olhe aqui e verá o que quero dizer:

COMO / UM EU QUERO… PARA QUE ENTÃO…
moderador criar um novo jogo digitando um nome e uma descrição opcional Posso começar a convidar jogadores
moderador convidar os jogadores, dando-lhes um URL onde eles possam acessar o jogo podemos começar o jogo
jogador participar de um jogo digitando meu nome na página em que recebi o URL Eu possa participar
moderador iniciar uma rodada inserindo um item em um único campo de texto com várias linhas podermos estimar
jogador ver o item que estamos estimando eu dê minha estimativa para o item
jogador ver todos os itens que tentaremos estimar nesta sessão coletar o tamanho dos vários itens
moderador ver todos os itens que tentamos estimar nesta sessão Eu possa responder perguntas sobre a história atual, como “isso inclui _____”
moderador selecionar um item a ser estimado ou reestimado a equipe veja esse item e poder estimá-lo

Sério, dê uma olhada na tabela acima antes de continuar … Eu vou esperar … Por favor, olhe para ela antes de ler mais.

OK, aqui está como eu aposto que você leu a planilha

Aposto que, ao ler a maioria das linhas que você adicionou no texto “Como um …”, “Eu quero …” e “para que então…”, possivelmente até olhando para o cabeçalho enquanto você lê em cada linha. Eu experimentei perguntando às pessoas, e é isso que a maioria das pessoas faz.

Se esse texto é desnecessário, por que mentalmente expressamos as palavras para nós mesmos ou até olhamos para o cabeçalho enquanto lemos a linha? Talvez não seja tão não essencial, afinal.

Por enquanto, e provavelmente por muito tempo, continuarei com o modelo “Como um …”, “Eu quero …” e “para que então…” por esses e outros motivos.

Por que o modelo de história de usuário de três partes funciona tão bem

Não há modelo mágico que deva ser usado para histórias de usuários. Eles podem ser escritos de várias maneiras. Mas a maneira mais popular de escrever histórias de usuários é com este modelo:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Esse modelo se originou com a treinadora ágil Rachel Davies em uma empresa inglesa, Connextra, no início dos anos 2000. Desde então, tornou-se um padrão reconhecido para expressar histórias de usuários.

Os três elementos do modelo padrão

Descrevi as três partes do modelo padrão de várias maneiras ao longo dos anos. No Livro Histórias de usuários aplicadas de Mike Cohn1, ele descreve os três elementos desta maneira:

  • Como um papel ( ), quero uma função ( ) para que ( valor comercial ).

Mais tarde, ele mudou para que ao se referir aos três elementos como papel, objetivo e razão. Por fim, decidiu apenas se referir a eles de maneira muito mais simples como quem, o quê e por quê. Os três elementos do endereço do modelo de história do usuário padrão:

  • Quem quer a funcionalidade
  • O que eles querem
  • Por que eles querem

Vejamos cada uma dessas partes do modelo de história do usuário.

Quem: o primeiro elemento do modelo de história do usuário

Os usuários de um produto ou sistema típico geralmente podem ser categorizados. Como exemplo, estou digitando isso no Google Docs agora. Eu poderia ser considerado um usuário casual de Docs.

Não uso a maioria de seus recursos. Nunca cliquei no menu Complementos para ver o que há lá. Não faço muita formatação sofisticada porque a maior parte do que escrevo é movida para o meu site e é formatada lá. Então, vamos me chamar de Usuário casual.

Outros que usam esses recursos podem ser chamados Usuários de energia.

Normalmente, envio meus rascunhos de blog para um editor. E assim, Editor poderia ser outra função ao identificar os vários tipos diferentes de usuários do Google Docs.

Essas funções de usuário formam a primeira parte do modelo padrão de história do usuário. Portanto, alguém que desenvolve um processador de texto pode ter uma história de usuário de “ Como um usuário de energia, Eu quero um corretor ortográfico … ”

O que: o segundo elemento do modelo de história do usuário

A segunda parte do modelo padrão indica o que é desejado ou necessário. Isso é comumente declarado como “ eu quero …. ” De fato, durante anos minhas apresentações em conferências e outros treinamentos sobre histórias de usuários tiveram um slide dizendo “ Eu quero … ”

Acabei percebendo que isso era impreciso. Às vezes, a funcionalidade descrita não é algo que a função do usuário deseja. Por exemplo:

  • Como membro, sou obrigado a inserir uma senha forte….

Nenhum usuário ( normal ) quer para inserir uma senha com muitos caracteres, três símbolos especiais, sem caracteres repetidos e pelo menos algumas letras maiúsculas. Na melhor das hipóteses, entendemos por que é necessário, mas pessoalmente prefiro que o sistema saiba magicamente que sou eu e deixe-me entrar.

Então, hoje em dia eu não incluo mais quer ao mostrar o modelo em cursos ou apresentações. Em vez de sempre ser eu quer, às vezes sou eu necessário, forçado, precisa ou mais.

Por que: o terceiro elemento do modelo de história do usuário

A parte final do modelo padrão é porque o usuário deseja que a funcionalidade seja descrita na história do usuário. Isso é fornecido após o para que parte do modelo. Por exemplo, uma versão totalmente expressa da história anterior do verificador ortográfico pode ser “ Como usuário de energia, quero um verificador ortográfico para não precisar me preocupar com erros ortográficos. ”

O para que a cláusula de uma história é importante porque entender por que um usuário deseja o que é descrito no o que parte da história ajuda a equipe a decidir qual a melhor forma de implementar a funcionalidade.

Como exemplo, não procure mais do que a nossa história de corretor ortográfico. Suponha que tenha sido fornecido a uma equipe sem uma cláusula simples: Como usuário de energia, quero um corretor ortográfico. Isso provavelmente levaria uma equipe a desenvolver o que eram todos os verificadores ortográficos iniciais: As ferramentas posteriores são executadas em um documento após a escrita.

Mas nosso usuário de energia não deseja um passo extra depois de terminar de escrever um documento. Em vez disso, o usuário de energia quer o que parece mais padrão hoje: correção em tempo real dos erros à medida que são cometidos. O que o usuário realmente deseja é dado pela cláusula: o usuário não quer se preocupar com erros de ortografia.

A cláusula ‘para que’ deve ser opcional?

Quando apresento histórias de usuários durante cursos presenciais, Muitas vezes me pedem para justificar minha visão aparentemente contraditória de que a cláusula é a parte mais importante de uma história, mas não deve ser obrigatória.

Não considero obrigatório porque, às vezes, simplesmente não agrega valor. Considere uma história sobre o login: Como membro, sou obrigado a fazer login.

Que cláusula você pode adicionar a essa história que agrega valor ou esclarece a intenção da história? Alguma dessas coisas realmente ajuda ou são apenas texto supérfluo adicionado para cumprir um modelo:

  • Como membro, sou obrigado a fazer login para que somente eu possa acessar meus dados pessoais.
  • Como membro, sou obrigado a fazer login para que outras pessoas não possam acessar meus dados pessoais, a menos que eu tenha fornecido minhas credenciais.
  • Como membro, sou obrigado a fazer login para que o sistema saiba que sou eu.
  • Como membro, sou obrigado a fazer login para que os hackers sejam mantidos de fora.

Enquanto eu não considero o para que cláusula obrigatória, eu escrevo quase o tempo todo. Revisei um atraso recente que escrevi e 62 de 64 histórias ( 97% ) tiveram cláusulas para que. Um pequeno número de ocasiões me impede de considerá-lo obrigatório.

Pontos fortes do modelo de história de usuário de três partes

Então, o que há de tão bom nesse modelo que ele resistiu ao teste do tempo? Afinal, uma prática introduzida no início dos anos 2000 e crescendo em aceitação tantos anos depois deve ter algo a seu favor. Eu acho que existem quatro pontos fortes principais no modelo.

Abrange três dos cinco Ws

Comecei a universidade como especialista em jornalismo. Acho que romantizei filmes cheios de repórteres de jornais que mastigam charutos e filmes como Ás no buraco, cidadão Kane, aconteceu uma noite, e Todos os homens do presidente. Os jornalistas são treinados para que qualquer artigo de jornal precise responder cinco perguntas que começam com um W:

  • Quem? (Who?)
  • O que? (What?)
  • Quando? (When?)
  • Onde? (Where?)
  • Por quê? (Why?)

As histórias dos usuários abordam três dos cinco – Quem, O quê e Por quê. Ao discutir os requisitos do produto ou sistema, parece razoável deixar Quando e Onde, pois as respostas geralmente seriam “ agora ” e “ no produto. ”

Os elementos são apresentados na ordem certa

Eu acho que os elementos – quem, o quê e por quê – são apresentados na ordem certa. Pense em qualquer história – não em uma história de usuário, mas em um filme, um romance ou uma anedota ou piada que você deseja contar a um amigo. A coisa mais importante nessa história é quase sempre quem está fazendo isso. Chamamos essa pessoa de protagonista.

Quando assistimos a um filme, precisamos nos preocupar com o protagonista antes de nos preocuparmos com a trama. Eu não me importo de um jeito ou de outro com a Estrela da Morte sendo explodida até me ver um pouco em Luke, Han ou Leia e posso relacionar para eles.

Só depois que eu sei quem, eu me preocupo com o que e porque. O modelo padrão de história do usuário os coloca nessa ordem.

A história é contada a partir de uma perspectiva de primeira pessoa

Nós gostamos de histórias sobre nós mesmos. ( Bem, a menos que sejamos adolescentes e nossos pais estejam contando histórias sobre as coisas não tão fofas que fizemos quando éramos bebês. ) A próxima melhor coisa para uma história sobre mim é uma história sobre você.

O menos interessante é uma história sobre o cara do outro lado da cidade que eu nunca conheci.

Histórias sobre eu e você e nós e ela e ele são interessantes.

Os Beatles sabiam disso. Eles deliberadamente colocaram o maior número possível de pronomes pessoais em seus títulos de músicas. E se eles não conseguissem encaixar um pronome pessoal no título da música, colocariam o máximo que pudessem nas letras da música.

O primeiro álbum britânico dos Beatles ’ teve pronomes em 8 dos 14 títulos de músicas ( 57% ). Nos 19 minutos e 30 segundos dessas oito músicas, os Beatles usavam 325 pronomes pessoais, um pronome a cada 3,6 segundos.

Isso funcionou tão bem que seu segundo álbum teve pronomes em 64% dos títulos. Os Beatles então aumentaram para 79% em seu terceiro álbum.

Em entrevista à revista Billboard, o Beatle Paul McCartney disse que isso era muito deliberado: “ Todas as nossas primeiras músicas continham ‘eu’ ou ‘você.’ Fomos completamente diretos e sem vergonha para os fãs: Me ame, por favor, por favor, eu quero segurar sua mão.”

O modelo padrão de história do usuário começa com eu, o mais pessoal dos pronomes pessoais. Não tenho base para essa afirmação – não sou neurologista -, mas juro que algo acontece quando temos uma história de usuário que começa com eu.

Nos relacionamos com essa história mais de perto do que se o mesmo fosse escrito como um tradicional O sistema deve… declaração.

Paul McCartney e John Lennon sabiam disso e o usavam para impulsionar suas carreiras. As equipes ágeis fazem o mesmo ao usar o modelo de história de usuário em três partes.

Nossas partes interessadas são imediatamente confortáveis preenchendo

Os espaços em branco Antes das histórias dos usuários aparecerem, adorei usar casos. Ou tentei amar casos de uso. Eu realmente os amava. Mas nunca consegui convencer as partes interessadas com quem trabalhei para amá-las tanto quanto eu.

Eles estavam muito longe de como as partes interessadas pensavam sobre seu trabalho. As partes interessadas não pensam em atores secundários, pré-condições ou pós condições. E assim, os casos de uso nunca funcionaram tão bem na prática quanto eu pensava que deveriam.

Eu nunca tive esse problema com histórias de usuários. Posso realizar um workshop de redação de histórias com as partes interessadas simplesmente escrevendo Como um _____, Eu ______ para que _______ em um quadro branco e dizendo a eles que nos reunimos para preencher os espaços em branco o máximo que pudermos.

As partes interessadas entendem. É uma maneira natural de falar por eles.

Outros modelos para expressar histórias foram propostos, e alguns têm vantagens, mas a maioria são maneiras menos naturais de falar. Por exemplo, o desenvolvimento orientado a comportamentos é uma ótima maneira de expressar testes ou especificar por exemplo. Martin Fowler descreve sua sintaxe dada quando e depois como “ um estilo de representação de testes. ” E é fantástico para escrever especificações de teste mas não é tão bom para se comunicar com os clientes.

Em parte, isso ocorre porque seu modelo é menos natural. Falo desde os 2 ou 3 anos. Não sei se já iniciei uma frase com dado. Definitivamente nunca usei dado, quando e então nessa ordem em uma frase. Eu disse sem conta “ eu quero isto de modo que aquilo.”

Desvantagens do modelo de user story de três partes

Há duas desvantagens no modelo padrão de história do usuário que merecem destaque.

Muitas histórias são escritas apenas como “ Como usuário … ”

Com demasiada frequência, os membros da equipe têm o hábito de iniciar cada história de usuário com “ Como usuário…” Às vezes, esse é o resultado de um pensamento preguiçoso e os escritores de histórias precisam entender melhor os usuários do produto antes de escrever tantas histórias “ como usuário … ”.

Mas outras vezes, pode indicar um sistema não adequado para histórias de usuários. Isso acontece porque muitas pessoas associam ser ágil com a escrita de histórias de usuários. Para ser ágil, eles raciocinam, você precisa escrever histórias de usuários, mesmo quando não há usuários.

Eu trabalhei em um sistema de rastreamento de conformidade financeira. A grande maioria do que o sistema fez nunca seria vista ou relatada. Se um problema de conformidade fosse descoberto, no entanto, os relatórios seriam gerados e os indivíduos seriam notificados. Esse sistema se beneficiou de histórias de usuários para esse pequeno subconjunto da funcionalidade geral do produto. Mas as histórias dos usuários eram inadequadas para o resto do sistema.

Em casos como esses, as equipes precisam usar maneiras alternativas de expressar o que o produto precisa fazer. A sintaxe usada por histórias de trabalho ou desenvolvimento orientado a recursos recursos podem ser melhores escolhas.

O modelo é muito frequentemente seguido de maneira eslava

Por todos os meios, o senso comum precisa ser um princípio norteador para equipes ágeis. Ao expressar algo no modelo de história do usuário padrão, não faz sentido, não use esse modelo. Escreva de outra maneira, incluindo muito possivelmente apenas texto de forma livre.

Hoje cedo, escrevi um item de lista de pendências do produto “ Altere como os lembretes de reprodução de webinar são enviados no último dia da maneira como discutimos na ligação de sexta-feira. ”

Como um item de lista de pendências do produto, isso é péssimo. Não é uma história de usuário. Não é BDD ou mesmo uma história de trabalho. É horrível. E se não for corrigido em breve, ninguém se lembrará do bug que foi discutido em uma ligação esquecida.

Mas eu sabia que a equipe iria consertar isso em breve e, portanto, o que escrevi foi bom o suficiente. A última coisa que eu preciso seria de um Scrum Master insistindo em escrevê-lo para seguir um modelo criado na virada do milênio, não importa o quão bem esse modelo funcione para a maioria dos itens de lista de pendências do produto.

Vantagens das histórias de usuários sobre requisitos e casos de uso

A programação extrema ( XP ) introduziu a prática de expressar requisitos na forma de histórias de usuários. A história do usuário é uma breve descrição da funcionalidade – contada da perspectiva de um usuário – que é valiosa para um usuário do software ou para o cliente do software, e normalmente assume a forma de um Modelo de 3 partes.

A caso de uso, por outro lado, é uma descrição generalizada de um conjunto de interações entre o sistema e um ou mais atores, onde um ator é um usuário ou outro sistema. Os casos de uso podem ser escritos em texto não estruturado ou em conformidade com um modelo estruturado.

Requisitos são tipicamente uma lista de instruções “ O sistema deve … ”, como:

  • O sistema deve permitir que uma empresa pague por um anúncio de emprego com cartão de crédito.
  • O sistema deve aceitar cartões Visa, MasterCard e American Express.
  • O sistema cobrará o cartão de crédito antes que o anúncio de emprego seja colocado no site.
  • O sistema deve fornecer ao usuário um número de confirmação exclusivo.

Histórias de usuários normalmente (mas nem sempre e não em todos os casos) são a melhor escolha para equipes que usam Scrum porque oferecem várias vantagens em casos de uso, requisitos e outras opções.

Benefícios das histórias de usuários

As histórias de usuários exibem algumas das mesmas características dos casos de uso ou declarações de requisitos tradicionais, mas são as maneiras pelas quais elas são diferentes que dão tantas vantagens às histórias de usuários.

User Story Benefício 1: Exigem conversas

Talvez o benefício mais importante das histórias dos usuários no desenvolvimento ágil de produtos seja que, diferentemente dos requisitos ou casos de uso, as histórias dos usuários não devem se sustentar por si mesmas.

Em vez disso, cada história de usuário é um espaço reservado para uma conversa futura com a equipe de desenvolvimento.

O texto de alto nível armazenado em um cartão de índice, problema de Jira, célula de planilha ou nota adesiva pode ser a manifestação mais visível de uma história de usuário, mas não é a mais importante.

A parte mais importante de qualquer história de usuário é que um entendimento compartilhado do que é necessário é elaborado em uma conversa futura.

User Story Benefício 2: São verbais, muito mais precisas

As histórias dos usuários enfatizam a comunicação verbal, para que sejam mais precisas. O idioma escrito geralmente é muito impreciso e não há garantia de que um cliente e desenvolvedor interpretem uma declaração da mesma maneira.

Agimos como se as palavras escritas fossem precisas, mas geralmente não são. Por exemplo, no almoço recentemente, li isso no meu menu: “ Entrada: vem com uma escolha de sopa ou salada e pão. ”

Essa não deveria ter sido uma frase difícil de entender, mas foi. Qual deles você escolhe?

  • Sopa ou ( salada e pão )
  • ( Sopa ou salada ) e pão

Compare as palavras escritas nesse menu com a garçonete ’ palavras faladas: “ Você gostaria de sopa ou salada? ” Melhor ainda, ela removeu toda a ambiguidade colocando uma cesta de pão na mesa antes de fazer meu pedido.

User Story Benefício 3: Têm estimativas e priorização fáceis

Uma terceira vantagem de escrever histórias de usuários é que elas recebem estimativas que tornam a priorização e o planejamento mais tranquilos. Cada história de usuário pode receber uma estimativa do esforço necessário para desenvolvê-lo; os casos de uso, por outro lado, são geralmente grandes demais para receber estimativas úteis.

Da mesma forma, quando você considera as milhares ou dezenas de milhares de instruções em uma especificação de requisitos de software ( e os relacionamentos entre elas ) para um produto típico, é fácil ver a dificuldade inerente em priorizá-los.

Se os requisitos não puderem ser priorizados além do alto, médio e baixo comuns, eles não serão adequados para um processo de desenvolvimento altamente iterativo e incremental que fornecerá software de trabalho a cada duas a quatro semanas.

User Story Benefício 4: Incentive as equipes a adiar detalhes

Uma quarta vantagem é que as histórias dos usuários incentivam a equipe a adiar detalhes da coleta.

Uma história inicial  épica – de nível ( “ Um recrutador pode postar uma nova vaga ” ) pode ser escrita, estimada e colocada no backlog do produto. Mais tarde, ele pode ser substituído por várias histórias menores, mais detalhadas, com DoR, DoD e Critérios de aceitação que é quando se torna importante ter esses detalhes.

Essa técnica torna as histórias dos usuários perfeitas para projetos com restrição de tempo – Uma equipe pode escrever rapidamente algumas dezenas de histórias de usuários para dar uma sensação geral pelo sistema. Eles podem mergulhar nos detalhes de algumas histórias e começar a codificar muito mais cedo do que uma equipe que se sente compelida a concluir uma especificação de requisitos funcionais.

User Story Benefício 5:  Oferecer um entendimento geral do produto

A quinta vantagem é um pouco mais sutil. As listas de requisitos que um analista de negócios pode apresentar não dão ao leitor o mesmo entendimento geral de um produto que as histórias de usuários fazem.

É muito difícil ler uma lista de requisitos sem considerar automaticamente as soluções em sua cabeça enquanto você lê.

Por exemplo, considere os seguintes requisitos, adaptados dos de Alan Cooper2 The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity 1ª Edição.

  • O produto deve ter um motor a gasolina.
  • O produto deve ter quatro rodas.
  • O produto deve ter um pneu de borracha montado em cada roda.
  • O produto deve ter um volante.
  • O produto deve ter uma carroceria de aço.

A essa altura, suponho que imagens de um automóvel estejam flutuando em torno de sua cabeça. Obviamente, um automóvel atende a todos os requisitos listados acima. O da sua cabeça pode ser um conversível vermelho brilhante, enquanto eu posso imaginar uma picape azul. Presumivelmente, as diferenças entre o seu conversível e a minha picape são cobertas por declarações de requisitos adicionais.

Mas suponha que, em vez de escrever uma especificação de requisitos de estilo IEEE 830 –, as histórias foram escritas da perspectiva do usuário.

  • Como proprietário de casa, quero algo que facilite e agilize a cortar a grama.
  • Como proprietário de casa, quero uma maneira de cortar a grama, onde possa me sentar, em vez de me levantar.

Ao olhar para as metas, temos uma visão completamente diferente do produto: o cliente realmente quer um cortador de grama, não um automóvel!

Histórias descrevem os objetivos de um usuário. Ao focar nos objetivos do usuário para o novo produto, em vez de uma lista de atributos do novo produto, podemos criar uma solução melhor para as necessidades do usuário.

User Story Benefício 6: Sugerem um custo

Um benefício final das histórias do usuário sobre as especificações de requisitos é que o custo de cada requisito não seja visível até que todos os requisitos sejam escritos.

O cenário típico é que um ou mais analistas passam dois ou três meses ( geralmente mais ) escrevendo um documento de requisitos demorado. Este documento é entregue aos programadores, que informam aos analistas ( que transmitem a mensagem ao cliente ) que o projeto levará 24 meses, em vez dos seis meses que eles esperavam.

Nesse caso, perdeu-se tempo escrevendo os três quartos do documento que a equipe não terá tempo para desenvolver e mais tempo será desperdiçado como desenvolvedores, analistas, e iterar o cliente sobre qual funcionalidade pode ser desenvolvida a tempo.

Na boa prática de histórias de usuários, um estimativa está associada a cada história. O cliente / proprietário do produto conhece a velocidade da equipe e o custo relativo de cada história, e pode decidir rapidamente se o produto que eles desejam pode ser entregue no tempo que eles tiverem.

Kent Beck me disse uma vez que essa diferença era como se registrar para presentes de casamento. Quando você se registra, não vê o custo de cada item. Você apenas faz uma lista de desejos de tudo o que deseja.

As listas de desejos cegas podem funcionar para casamentos, mas não funcionam para o desenvolvimento de produtos. Quando um cliente, proprietário do produto ou parte interessada coloca um item em sua lista de desejos do projeto, ele precisa saber seu custo.

Requisitos não funcionais como histórias de usuários

Um desafio comum com a escrita histórias de usuários é como lidar com os requisitos não funcionais de um produto. Esses são requisitos que não tratam de funcionalidade específica ( “Como usuário de um processador de texto, quero inserir uma tabela no meu documento”. ), mas são mais sobre um atributo ou característica do sistema.

Os exemplos incluem confiabilidade, disponibilidade, portabilidade, escalabilidade, usabilidade, manutenção.

Como você pode ver nessa lista de exemplos, os requisitos não funcionais são frequentemente referidos como “-ilidade.” Obviamente, nem todos os requisitos não funcionais terminam em “-ilidade.” Também temos segurança, desempenho, robustez e assim por diante.

Pensando na idade das trevas, lembro-me de quando li pela primeira vez sobre “requisitos não funcionais.” O termo me deu um nó. Se não é funcional, por que me preocupo com isso? Tenho certeza de que o autor desse livro esclareceu isso para mim uma página mais tarde, mas o termo sempre me pareceu estranho.

Prefiro pensar em requisitos não funcionais como “restrições” que colocamos no sistema.

Quando o proprietário do produto diz: “este sistema deve ter um desempenho adequado com 100.000 usuários simultâneos”, o proprietário do produto está colocando uma restrição no equipe.

O proprietário do produto está efetivamente dizendo: “Desenvolva este software da maneira que desejar, desde que alcance 100.000 usuários simultâneos.”

Cada restrição que colocamos em um sistema restringe um pouco as opções de design; chamar essas “restrições” em vez de “requisitos não funcionais” nos ajuda a lembrar disso. Felizmente, restrições / requisitos não funcionais podem ser facilmente expressos como histórias de usuários:

  • Como cliente, quero poder executar seu produto em todas as versões do Windows a partir do Windows 95.
  • Como CTO, quero que o sistema use nosso banco de dados de pedidos existente em vez de criar um novo, para que não tenhamos mais um banco de dados para manter.
  • Como usuário, quero que o site esteja disponível 99.999% do tempo em que tento acessá-lo, para não ficar frustrado e encontrar outro site para usar.
  • Como alguém que fala um idioma latino, talvez eu queira executar seu software algum dia.
  • Como usuário, quero que as instruções de direção sejam os melhores 90% do tempo e razoáveis 99% do tempo.

Como você pode ver nesses exemplos de histórias de usuários, eu pude facilmente ficar com o “Como um , Eu quero , de modo que ” modelo de história do usuário, que eu prefiro para a maioria das histórias de usuários. Faço isso por algumas razões, mas quero comentar mais sobre apenas uma delas aqui.

Considere o exemplo do CTO que restringe a equipe a usar o banco de dados de pedidos existente. ( Esta era a situação real; a equipe estava considerando um banco de dados de segundos pedidos que seria sincronizado à noite. O CTO ouviu isso e disse: “Não!” )

Se escrevêssemos esse requisito da mesma forma: “Deve usar o banco de dados de pedidos existente,” seria inteiramente possível que, alguns meses depois, não nos lembrássemos por que deveríamos ser restringidos dessa maneira. Perguntaríamos ao proprietário do produto se ela se importava se usássemos um banco de dados secundário e ela diria que não tinha objeções. E cometeríamos um erro de usar um.

Incorporar a pessoa que quer algo pode ser muito útil. Mas, tome cuidado para não ficar obcecado com esse modelo. É apenas uma ferramenta de pensamento.

Tentar colocar uma restrição no modelo de história de usuário em três partes é um bom exercício, pois ajuda a entender quem quer o quê e por quê. Se você terminar com uma instrução confusa, largue o modelo. Você pode achar que o modelo de história de trabalho funciona melhor para o seu contexto. Ou você pode achar que os modelos não funcionam. Se você não conseguir encontrar uma maneira de expressar a restrição, basta escrever a restrição da maneira que parecer natural.

Product Backlog, tudo o que você precisa saber

/1 Comentário/em /por

Para ter ideia de tudo que você precisa saber sobre Product Backlog neste artigo, vamos contextualizar e balizar nossos conhecimentos um pouco.

O que é um Product Backlog? Definição

Uma das características importantes do Scrum é que há um, e apenas um, backlog de trabalho aguardando para ser priorizado, desenvolvido e concluído.

Um Backlog é uma lista de requisitos e requisitos de negócios que ainda não foram implementados. Um Backlog ajuda a entender melhor o produto, além de garantir que cada recurso necessário seja listado.

No desenvolvimento de software, um Product Backlog é uma lista abrangente de tudo o que pode ser necessário no produto. Ele inclui todos os recursos que serão implementados, bem como todos os bugs e problemas que devem ser corrigidos.

Um Product Backlog eficaz ajuda o gerenciamento de produtos e a equipe de desenvolvimento a priorizar tarefas e colaborar.

O objetivo de usar um backlog de produto é garantir que os recursos desenvolvidos sejam priorizados em termos de tempo e importância de valor para o usuário final.

Quem é responsável pelo Product Backlog?

O Product Owner é o responsável e mantenedor do backlog do produto. Além disso, é responsabilidade do Product Owner entender, avaliar e selecionar os itens de backlog individuais que serão adicionados a um sprint ou release atual.

É o PO que  deve receber informações de todas as partes interessadas, incluindo clientes, membros da equipe, executivos, tendências atuais e outras funções internas, mas, em última análise, ele é o tomador de decisão final.

O Product Owner é a pessoa que determina o trabalho que será realizado em cada iteração . O trabalho real atribuído à iteração requer um diálogo colaborativo entre o Product Owner e a equipe ágil.

O PO geralmente pede que a equipe assuma mais trabalho, e a equipe do projeto – deve se comprometer apenas com o nível de trabalho que pode ser totalmente concluído durante a iteração. Em última análise, a equipe Agile é responsável por decidir sobre o trabalho exato que compõe a iteração.

O que é Sprint Backlog? E como ele é planejado?

Em um projeto ágil, a carga de trabalho é determinada no início de cada iteração (sprint). O Product Owner avalia e prioriza o trabalho que precisa ser feito, enquanto a equipe determina a quantidade de trabalho que pode ser concluída e a meta da sprint.

A reunião de planejamento de iteração (Sprint Planning) define o cenário e deve ser executada como um diálogo colaborativo,.

Um dos aspectos exclusivos de um projeto Agile é que a carga de trabalho é determinada no início de cada iteração. Ao contrário dos projetos tradicionais, a carga de trabalho não é definida com meses e meses de antecedência.

Há apenas a necessidade de um planejamento detalhado para a próxima iteração. (O  Product backlog pode ser mapeado em alto nível para iterações futuras, mas o planejamento detalhado ocorre uma iteração por vez.) Isso permite que um projeto ágil seja flexível em sua carga de trabalho e sensível às mudanças nas necessidades e prioridades do cliente.

No início de cada iteração, o Product Owner e a equipe do projeto se reúnem para determinar a carga de trabalho para essa iteração. Durante a reunião, o Product Owner avalia o backlog do produto e simplesmente extrai o próximo conjunto de histórias de usuário que são de maior prioridade.

Esse nível de esforço para concluir a história do usuário pode já ter sido estimado quando a história foi adicionada. Caso contrário, a equipe estima o trabalho na reunião de planejamento.

Essa estimativa pode assumir a forma de horas de esforço real, mas é mais provável que a estimativa seja baseada em “pontos da história” – vamos falar sobre eles depois – A estimativa inclui o trabalho necessário para implementar totalmente a história do usuário, incluindo a análise, design, construção, teste e integração.

Essa separação de histórias, para um pedaço do projeto é chamado de Sprint Backlog.

Legal! até aqui você já entendeu que o Product Backlog (backlog do produto) é a lista de tudo que consta dentro de um produto com os desejos e regras de negócios, enquanto o Sprint Backlog é uma lista priorizada que vai ser executada já na próxima iteração.

Documentação de projeto e o Product Backlog

Em um projeto ágil, você não cria documentos grandes para atender aos requisitos do usuário; na verdade, você não precisa de um documento tradicional. A técnica preferida é usar um backlog do produto, que representa uma coleção priorizada de trabalho restante no projeto em um determinado momento.

Em um projeto Agile, você não cria documentos grandes para atender aos requisitos do usuário. Na verdade, você não precisa de um documento tradicional. A técnica preferida é criar um backlog do produto.

O backlog não é um documento tanto quanto é simplesmente a coleção priorizada de trabalho que permanece em um projeto. Pode ser uma planilha ou tabela que contém uma lista de histórias de usuários. Também pode ser uma pilha de cartões de índice, cada um contendo uma história de usuário ou um item exclusivo de trabalho.

O backlog inicial do produto é gerado no início de um projeto Agile. O tempo pode coincidir com uma fase de iniciação do projeto ou durante uma iteração inicial de configuração (às vezes chamada de iteração 0). O backlog inicial do produto consiste em todo o trabalho facilmente identificado que é conhecido quando o projeto é iniciado.

À medida que cada iteração começa, uma reunião de planejamento é realizada entre o proprietário do produto e a equipe do projeto. O proprietário do produto identifica o trabalho no backlog do produto que ele gostaria que fosse concluído na iteração.

A equipe do projeto valida que pode concluir o trabalho. As negociações são realizadas se houver uma diferença de opinião sobre o trabalho que pode ser concluído durante a iteração. O trabalho mutuamente acordado é então retirado do backlog do produto e implementado durante a iteração.

O que mais existe no backlog do produto?

O backlog do produto representa a totalidade do trabalho restante no projeto em um determinado momento. A maior parte do backlog consiste em histórias de usuários que implementam funcionalidades de benefício para o usuário. No entanto, outros trabalhos também estarão na lista de pendências. Isso inclui.

Entregas do usuário Nem todos os itens do backlog do produto requerem codificação de software. Por exemplo, o proprietário do produto pode querer um Manual do Usuário, conteúdo de treinamento, perguntas frequentes etc. Se as entregas devem ser criadas pela equipe do projeto, o trabalho precisa ser priorizado e incluído na iteração apropriada.

Entregas de TI Essas são entregas exigidas pela organização de TI. Isso pode incluir um Manual de Recuperação de Desastres, documento de retenção de registros, documentação de controle de alterações, etc. Alguns deles podem ter valor para o usuário, mas às vezes são necessários para a organização de TI.

Defeitos e correções de bugs Se erros críticos e bugs surgirem durante uma iteração, eles precisam ser resolvidos para que o código do produto seja viável no final de uma iteração. No entanto, muitos bugs se enquadram na categoria de incômodos.

Eles precisam ser corrigidos, mas há discrição quanto ao momento das correções. Esses tipos de correções podem ser colocados no backlog e priorizados em uma iteração subsequente. Em alguns casos, a equipe espera até o final do projeto para uma limpeza final de bugs e erros.

Como são escritas as histórias no backlog?

As histórias de usuários são escritas de forma vaga e não contêm necessariamente muitos detalhes. As histórias devem conter detalhes suficientes para que tanto o cliente quanto a equipe do projeto se lembrem a que a história se refere.

A história também pode incluir outras informações, como uma estimativa do trabalho necessário para implementar a história. Quando a história é priorizada para uma iteração específica, deve haver informações suficientes para que o proprietário do produto e a equipe possam lembrar o contexto e possam trabalhar juntos para definir os requisitos detalhados.

Na iteração de configuração, o proprietário do produto cria quantas histórias de usuário ele conhece no momento. Não é necessário descobrir todas as histórias de uma só vez. As histórias podem ser adicionadas, modificadas e excluídas continuamente durante o projeto.

Em um projeto tradicional, as mudanças nas histórias de usuários seriam adicionadas usando o gerenciamento de mudanças de escopo. Em um projeto Agile, o proprietário do produto pode adicionar, alterar e remover quaisquer histórias.

O conceito de fluência de escopo não ocorre durante uma iteração. A quantidade de trabalho em uma iteração é fixada pela velocidade da equipe. Se o proprietário do produto continuar a adicionar novos itens à lista de pendências, pode ocorrer aumento de escopo exigindo iterações adicionais para implementar o trabalho em áreas que não faziam parte do escopo original do projeto.

Esse tipo de desvio de escopo deve ser controlado para garantir que o projeto Agile não se desvie.

Se o Product Owner é dono do Backlog, como fica o time?

Embora a equipe de desenvolvimento possa certamente expressar suas opiniões sobre o que deve ser trabalhado, eles não podem realmente agir de acordo com essas opiniões sem o consentimento do Product Owner.

Isso pode levar a uma sensação de “desempoderamento” por parte da equipe de desenvolvimento. Embora uma equipe de alto desempenho deva ser muito colaborativa e permitir que todas as vozes sejam ouvidas, a equipe pode sentir que as necessidades da tecnologia ou os sistemas não estão sendo suportados, ou talvez até valorizados.

Isso pode causar a sensação de “nós contra eles”, que é exatamente o cenário que Scrum e/ou  Agile deveriam evitar. Na verdade, algumas organizações tentam dividir o backlog entre “produto” e “tecnologia” e, às vezes, dão a cada um seu próprio Product Owner. Esta é a maneira errada de resolver este problema.

Dividir ou separar as pendências só causará confusão e interrupção, e não fornecerá transparência sobre o que está sendo trabalhado pela equipe.

O processo funciona melhor quando há um único backlog de trabalho priorizado contendo tudo o que deve ser desenvolvido e há uma maneira altamente visível (física ou eletrônica) para qualquer parte interessada ver o que está em andamento em uma iteração atual.

De qualquer forma, fazer qualquer outra coisa não é necessário – o Agile possui mecanismos para impedir que esse tipo de desempoderamento aconteça, embora o ônus seja da equipe de desenvolvimento para usá-los.

Usar esses mecanismos é a abordagem certa para manter a equipe se sentindo capacitada.

Itens chave para um bom backlog

Há seis itens chave para procurar em uma história de backlog saudável. Ao classificar cada história nessas facetas, você pode ter uma noção fácil de quão pronta a história está para ser escolhida e desenvolvida. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

O processo de refinamento do backlog e consequentemente dos requisitos até o ponto em que eles estejam prontos para serem trabalhados é conhecido como ‘limpeza do backlog’.

Mas essa tarefa realiza mais do que esclarecer requisitos; informa as partes interessadas, contribui para o plano do projeto e reforça os princípios ágeis em geral. Aqui está a orientação sobre como e quando isso deve ser feito.

Uma das inovações mais úteis da família de práticas Agile é o conceito de backlog do produto. No passado, o acúmulo de requisitos existia em um documento – geralmente chamado de Documento de Requisitos de Negócios (BRD – Bussiness Requirements Document) – que continha necessidades totalmente especificadas para o produto com base em qualquer informação que o proprietário da empresa tivesse na época.

O backlog, então, era o que estava no documento que ainda não estava concluído. Isso é realmente muito simples; se o documento contiver 50 itens e três deles estiverem completos, a lista de pendências consistirá em mais 47 itens. É melhor a equipe começar a trabalhar!.

Praticantes ágeis acreditam que duas coisas são verdadeiras: os produtos são melhores quando trabalhamos juntos e devemos abraçar a ideia de que os requisitos estão mudando o tempo todo.

O simples processo de passar semanas ou meses criando um documento enorme que é então entregue aos desenvolvedores não apenas viola os dois princípios, mas perde completamente o objetivo de como criar ótimos produtos. (além de que esse documento enorme acaba na gaveta).

Em vez de despender esforço criando um documento longo que é inferior (devido à falta de colaboração) e desatualizado (devido às necessidades de mudança do negócio), o Agile sugere a criação de algo chamado product backlog.

Esse backlog do produto é uma lista priorizada de requisitos, histórias de usuários, tarefas e atividades que a equipe do produto precisa realizar para levar o produto ao mercado.

Ele difere substancialmente do antigo BRD, pois a lista de requisitos teve diferentes níveis de energia colocados neles, e a lista é fixa e adaptável às necessidades do produto e da equipe do produto.

O processo de transformar esse backlog em algo excelente é chamado de Backlog Refinement (antigamente era grooming) e é um conceito fácil de ser mal interpretado ou usado indevidamente, tanto do ponto de vista do produto quanto do desenvolvedor.

Por que se preocupar com a limpeza no refinamento?

Existem duas dimensões que um backlog de produto Agile traz para o produto que o antigo BRD não trazia: prioridades e a capacidade de alterar ou inserir novos requisitos com o passar do tempo.

No entanto, há mais uma faceta oculta para trabalhar com um backlog priorizado: como algumas das histórias de usuários acabarão no final da lista, não há necessidade de gastar muito tempo com elas.

Acontece que é uma ideia melhor “deixar de lado” essas histórias e reorientar seu tempo nas histórias de usuários que estão no topo da pilha. Em vez de obter os requisitos “suficientemente bons” em geral, o proprietário do produto é responsável por obter os requisitos que estão no topo da pilha “prontos para a iniciar” – mesmo às custas das histórias na parte inferior da pilha.

Um backlog devidamente preparado é o ativo mais importante que uma equipe Agile pode ter. Para que seja o mais útil possível, deve ser capaz de fazer três coisas :

  1. Fornecer itens prontos para o trabalho para a equipe de desenvolvimento:
  2. Ser flexível e conter todas as informações disponíveis sobre o produto e
  3. Fornecer insights para todas as partes interessadas sobre o que está no pipeline a ser trabalhado.

O objetivo principal do backlog é dar trabalho à equipe de desenvolvimento que está pronta para começar. Isso significa que:

  • Ele está totalmente especificado,
  • Suas perguntas são respondidas,
  • O dimensionamento está completo e os critérios de sucesso registrados.

Um membro da equipe deve ser capaz de pegar um item da lista de pendências e começar a trabalhar imediatamente, não importa se é engenheiro de software, testador ou designer.

Isso realmente exige muito esforço do proprietário do produto e da equipe do produto – esforço que foi desviado dos itens na parte inferior do backlog.

Não há nada que um proprietário de produto possa fazer que afete mais a eficiência da equipe do que ter as próximas tarefas prontas para serem executadas.

Se um desenvolvedor de qualquer tipo tiver que passar por um intervalo de até meio dia enquanto espera para começar a trabalhar em algo, isso custará significativamente ao produto no final.

Enquanto isso, o backlog deve ser flexível, tanto em conteúdo quanto em prioridade. Quando o backlog inicial foi criado, ele foi feito com todas as informações, análises e inteligência que o product owner tinha.

Agora que a lista de pendências foi aberta para desenvolvedores, partes interessadas, clientes e outros proprietários de produtos, novas ideias surgirão e uma nova prioridade surgirá.

Por exemplo, trabalhei recentemente em um produto em que o proprietário do produto decidiu intencionalmente não priorizar uma parte inteira do aplicativo em favor de criar uma experiência mais rica nas outras partes.

O feedback foi instantâneo e intenso; sem a funcionalidade que faltava, o produto era inútil. Em vez de esperar um ano ou mais para recuperar essa funcionalidade, o proprietário do produto conseguiu colocar essas histórias de usuários de volta no topo da lista, prepará-las completamente, e levá-los para a próxima versão.

É assim que o Agile deve funcionar!

O backlog também deve ser usado como documentação externa. Todas as partes interessadas querem saber o que está por vir, quando seu caso de uso será criado e o que mais está na lista.

Um backlog devidamente preparado pode servir a essa função. Ao apontar as pessoas para a lista de pendências, elas podem ver o que está perto do topo, o que está na parte inferior e onde sua solicitação está em prioridade relativa.

Eles também podem ter informações ou feedback sobre as prioridades atuais, requisitos futuros ou podem até ter ideias brilhantes que não estão na lista.

Em suma, o backlog pode servir como documento de requisitos, plano de projeto e comunicação com as partes interessadas, tudo ao mesmo tempo. Mas só se for bem feito.

Itens de prioridade de um backlog antes do refinamento

Repare que existem seis itens que são prioridade num product backlog. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

Para criar um backlog saudável, ao classificar cada história em uma escala de zero a três, você obterá uma pontuação total entre zero e 18, permitindo que a equipe saiba, de relance, quais histórias estão em boa forma e quais não estão e, assim, quais a forma do backlog está no todo. Aqui está uma olhada em cada um dos fatores que compõem a “saúde da história”.

1. Prioridade.

Isso parece quase óbvio, pois as tarefas no topo do backlog são as de maior prioridade e as de baixo são as mais baixas. Isso não significa que a razão por trás da prioridade seja compreendida, o que é ainda mais importante.

A equipe de desenvolvimento geralmente prioriza mentalmente o trabalho com base em sua própria compreensão de por que algo é necessário. O papel do proprietário do produto é garantir que a equipe entenda o valor do trabalho; os desenvolvedores não precisam necessariamente concordar com ela, mas precisam entendê-la.

Desenvolvedores trabalhando em algo que não entendem é ruim para todos.

2. Requisitos.

Quase igualmente importante é a compreensão da obra em si, que, mais uma vez, parece óbvia. A parte difícil é que os requisitos nunca são completos; eles só são bons o suficiente por enquanto.

Mesmo depois que um recurso está disponível nas mãos do cliente, ainda há refinamentos, alterações e melhorias que podem ser feitas e provavelmente estão sendo constantemente adicionadas ao backlog.

No entanto, uma vez que uma história de usuário recebe um ou dois sprints de desenvolvimento, é hora de garantir que os requisitos sejam entendidos o suficiente para que um desenvolvedor possa pegá-lo e trabalhar nele.

Os requisitos não precisam ser definitivos – nunca são – mas precisam estar prontos.

3. Estimativas.

Uma parte da preparação do backlog é dimensionar as histórias, usando um mecanismo como pontos de história ou qualquer estratégia que a equipe se sinta confortável em usar.

Histórias que ainda são desconhecidas em relação ao nível de esforço, risco ou complexidade, ou histórias que têm estimativas grandes demais para serem concluídas, trazem muitos problemas para os desenvolvedores.

Quando chega a hora de planejar um sprint, um release ou até mesmo um único dia, é importante saber o tamanho do trabalho que está sendo considerado.

Sem um bom dimensionamento, a equipe fica apenas adivinhando o que pode ser concluído e nunca saberia responder se as coisas estão dentro do prazo ou não.

Estamos trabalhando com um projeto não com adivinhações.

4. Dependências.

Uma das causas frequentes de atraso envolve histórias sendo “bloqueadas” – ou seja, há uma dependência que não foi resolvida que está impedindo o desenvolvedor de progredir.

Se uma história for bloqueada durante o desenvolvimento ou, pior, entrar em um sprint já bloqueado, então é uma história inútil. Essas dependências podem estar em outras equipes de desenvolvimento, equipes fora do desenvolvimento, como criação, marca ou marketing, ou até mesmo o proprietário do produto tomando uma decisão sobre algo.

Como parte da preparação de uma história, é importante descobrir se o desenvolvedor tem tudo o que é necessário para começar o trabalho ou se o terá quando o sprint começar. Alguns podem ser resolvidos da noite para o dia; alguns podem levar vários meses para resolver.

É importante saber onde uma história está quando ela se aproxima do topo da lista de pendências.

5. Definição de Pronto. DoR – Definition of Ready

O que está sendo feito nas tarefas também tem “critérios de aceitação” – ou seja, quais casos de uso e funcionalidades devem existir e poder ser mostrados em uma demonstração para que a história seja considerada completa.

Nesse caso, está associado a cada item de trabalho individual que flui por uma equipe ágil.

Se você estivesse praticando Scrum, então seria no nível do item do backlog do produto (PBI).

Se você estiver operando como uma equipe de programação extrema (XP) ou Kanban (ou simplesmente alavancando histórias de usuários), então seria para cada história que entrasse em uma equipe.

Os critérios de prontidão seriam uma definição clara do que conota uma história de usuário ou PBI que está “pronta” para execução dentro da iteração ou sprint.

Os itens são executados desde a funcionalidade voltada para o usuário até requisitos de latência e desempenho, condições de erro e testes negativos. Quanto mais um desenvolvedor souber o que será necessário para que a história seja aceita, melhor será para todos.

Na verdade, uma metodologia de desenvolvimento requer escrever os testes de aceitação primeiro e depois fazer o desenvolvimento.

6. Definição de Feito. DoD – Definition of Done

Espero que todos estejam familiarizados com a terminologia “definition of done” (DoD), ou “done-ness”, do ponto de vista dos métodos ágeis. É uma frase comum e incrivelmente importante para a saúde e maturidade da equipe ágil. É essencialmente um critério de saída, se você preferir, para o trabalho de sprint das equipes.

No nível da história do usuário, é comum referir-se aos critérios de aceitação de cada história como a verificação de conclusão da completude da história.

Em um nível de sprint completo, é comum se referir ao objetivo do sprint como o ponto de verificação para o que a equipe estava tentando entregar. E o acabamento também permeia a forma como os membros da equipe entregam seu trabalho.

Por exemplo, as revisões de código fazem parte dos critérios de conclusão de uma equipe? Nesse caso, ele planejará e executará revisões de código consistentemente como parte do desenvolvimento e entrega de cada história.

Portanto, a definição de “feito” é um critério de saída, que determina a condição de completude para o trabalho que está sendo entregue. Mas há outro critério que é útil em equipes ágeis na outra ponta do fluxo de trabalho – a entrega a DoR.

Acontece que impedir que histórias mal definidas (ou trabalho) entrem em cada sprint em primeiro lugar é uma maneira incrivelmente saudável de evitar os desafios que descrevi na introdução. Mas vamos explorar a prontidão com um pouco mais de detalhes.

O outro lado do DoD: Descrevendo “Pronto”

Pessoalmente, gosto de uma abordagem de lista de verificação para descrever os critérios de prontidão das equipes para o trabalho. Aqui está um exemplo dos tipos de verificações que eu vi serem valiosas para as equipes aproveitarem ao amadurecer suas histórias:

  • A história é bem escrita; e tem um mínimo de cinco testes de aceitação definidos.
  • A história foi dimensionada para se ajustar à velocidade das equipes e à duração do sprint; por exemplo, algo entre 1-13 pontos.
  • A equipe examinou a história em várias sessões de preparação – seu escopo e natureza são bem compreendidos.
  • A equipe tem o conjunto de habilidades e experiência necessários para implementar a história e entregá-la para atender à definição de “pronto” da organização e da equipe.
  • Se necessário, a história teve um pico de pesquisa para explorar (e refinar) suas implicações de arquitetura e design; ou para explorar os desafios de testabilidade associados a ele.
  • A história descreve o comportamento de ponta a ponta no sistema.
  • A equipe entende como abordar o teste dos aspectos funcionais e não funcionais das histórias.
  • Quaisquer dependências de outras histórias e/ou equipes foram “conectadas” para que a história seja sincronizada e entregue como parte do “todo maior”.
  • A história se alinha com o objetivo do sprint e é claramente demonstrável.

Portanto, não há fases distintas neste caso. Uma nova história de usuário simplesmente precisa atender a todas as verificações acima para que seja considerada pronta para execução.

Como cada história fica pronta depende do proprietário do produto para cada backlog do produto, colaborando com sua equipe. Pode levar um ou 50 passos para chegar lá.

Pode ser rápido ou lento. Mas trabalhando juntos, eles decidem como conduzir uma história até a prontidão para execução.

Criando um semáforo do seu Backlog Refinado

Levando em consideração que vamos utilizar o DAP (Detalhar, Avaliar e Priorizar) para as histórias que serão refinadas, podemos criar também um semáforo com estes Seis itens que falamos acima para seu backlog, dessa forma vamos avaliar as histórias: A, B e C

História Prioridade Requisitos Estimativas Dependências DoD DoR Total
A 1 2 2 1 1 1 8
B 3 3 2 3 2 2 15
C 2 1 1 1 1 1 7

 

Neste ponto, as histórias no backlog devem ser avaliadas ao longo dos Seis vetores acima: Prioridade, Requisitos, Estimativas, Dependências, DoR e DoD.

O ideal, para se ter uma boa métrica, fazer a média de até cerca de seis sprints de histórias é suficiente, embora esse número possa ser potencialmente um pouco maior ou menor, dependendo da cadência de lançamento da organização ou do tamanho do incremento de planejamento.

Histórias classificadas entre 11 e 18 estão prontas (verde); as histórias que estão entre 6-10 ainda não estão prontas (amarelo); e qualquer coisa abaixo de seis não está pronta (vermelho). Isso fornece um mecanismo rápido de semáforo para verificar rapidamente o status do backlog da equipe.

Ter algumas histórias vermelhas não é uma coisa ruim, especialmente se elas estiverem mais abaixo na lista de prioridades. Se você estiver três meses antes da chegada dos pintores, há muitos momentos de responsabilidade antes de precisar escolher seu esquema de cores.

No entanto, histórias vermelhas, ou mesmo muitas histórias amarelas, planejadas para inclusão nos próximos dois sprints, podem sinalizar um problema ou uma lista de pendências que não está em boa forma.

Na verdade, eu sugiro que um backlog perfeito tenha principalmente histórias verdes nos próximos dois sprints, principalmente amarelos nos dois seguintes e principalmente vermelhos nos dois seguintes.

Ao fazer essa avaliação, a equipe pode dizer rapidamente quão saudável é o plano e, portanto, quão certo eles estão de que a equipe está “no caminho certo” para entregar.

Nunca haverá um caso em que não haja incógnitas; na verdade, um dos pontos do Agile é admitir que você não pode saber tudo antes do tempo.

Mas quanto mais você conseguir entender as coisas, especialmente as coisas que estão ao alcance da equipe, mais confiante ela poderá começar a investir no caminho para entregar valor ao cliente e à organização.

Expresse o valor do cliente

A primeira maneira pela qual uma equipe de desenvolvimento pode priorizar seu trabalho técnico é expressar o valor do trabalho em termos de benefício para o cliente.

Afinal, se não houver uma boa razão para fazer o trabalho em primeiro lugar, é lógico que ele não deve ser feito.

Mesmo coisas aparentemente mundanas podem ser enquadradas de forma a ajudar o cliente.

Já ouvi gerentes de desenvolvimento dizerem: “A estabilidade e a segurança de nossos sistemas é um recurso que lançamos todos os dias para nossos usuários”. Quando visto por essa lente, não é difícil descobrir quanto valor para o cliente seria criado e como a prioridade se compara a outros itens.

Esse tipo de determinação pode ser feito para muitas melhorias que parecem técnicas por natureza, mas na realidade são voltadas para o cliente.

Isso inclui itens como melhorias de desempenho, correções de bugs, dimensionamento de carga e até itens invisíveis, como a aplicação de hotfixes ou patches de segurança a uma estrutura de aplicativo.

Todas essas tarefas podem ser vistas como boas para todos e, portanto, devem ser priorizadas junto com novos recursos ou novas funcionalidades. Qualquer bom Product Owner seria capaz de entender o valor que está sendo criado e colocar isso em contexto com todo o resto.

O desafio é que esse tipo de cálculo não é natural para a maioria dos profissionais de produtos; embora reconheçam que há boas razões para fazer esses itens, muitas vezes têm dificuldade em quantificá-los.

É aqui que a equipe de desenvolvimento precisa agir como se estivesse na organização do produto, determinando o quanto os tempos de resposta serão mais rápidos ou quantas vezes um determinado defeito e acionado por um cliente ajudará a calcular o valor do trabalho.

As melhores práticas do setor podem ser citadas quando se trata de atualizações de estrutura, assim como eventos nas notícias que expõem vulnerabilidades que devem ser fechadas.

Qualquer que seja o caminho escolhido pela equipe, deve ser em termos de criação de valor; chamar as coisas de “devem ser feitas” sem fundamentação não é uma maneira útil de colaborar.

Refinar como parte da estimativa

Muitas das atividades que compõem um projeto ágil devem ser feitas em equipe, com todos no mesmo lugar. De fato, no Manifesto Ágil, um dos princípios afirma que as interações cara a cara são a maneira mais eficiente e eficaz de se comunicar.

Isso apresenta um problema para um gerente de projeto executando um projeto em que a equipe é distribuída, no todo ou em parte. Embora ter todos na mesma sala possa ser o ideal, não é realista se as pessoas trabalharem a quilômetros ou países de distância, ou se todos forem forçados a trabalhar em suas casas.

E enquanto a tecnologia pode ajudar a nos aproximar e imitar a interação face a face, há outras logísticas, como fusos horários e conectividade, a serem superadas.

Na prática, quase tudo o que pode ser feito em Agile pode ser feito de forma distribuída, desde o Daily Scrum até demonstrações e retrospectivas. É preciso apenas um cuidado extra para torná-los eficazes.

Uma atividade ágil importante que as equipes distribuídas podem realizar sem muita perda é o refinamento do backlog.

É importante para um scrum master, product owner ou mesmo um gerente de projeto que se encontra gerenciando uma equipe distribuída não tentar substituir os processos existentes pelo mesmo usando tecnologia.

Não é “o mesmo, apenas em vídeo”.

O seu objetivo é encontrar uma maneira de obter o mesmo valor de uma atividade sem necessariamente fazê-la exatamente da mesma forma que a equipe fez no passado.

O mesmo vale para o refinamento do backlog. Para uma equipe que costumava se reunir na mesma sala toda quinta-feira à tarde, simplesmente mudar para fazer a mesma coisa por videoconferência não terá os mesmos resultados.

O resultado desejado de uma sessão de refinamento é que os itens do backlog passem de ideias para itens acionáveis ​​que são compreendidos, dimensionados e priorizados.

Isso é possível, mesmo que todos estejam presos trabalhando em seus “escritórios domésticos”.

Na verdade, mesmo que todos estejam trabalhando na mesma mesa, certas partes de uma sessão de refinamento devem ser feitas em particular.

Para garantir que todos entendam um requisito, todos devem passar algum tempo sozinhos, certificando-se de que o entendem e que há informações suficientes sobre a história para que alguém possa pegá-lo e ter uma boa ideia do que precisa ser feito.

O escopo, ou determinar quanto esforço algo exigirá, também deve ser feito em particular. O conceito de “planning pôquer” é uma forma de prevenir o pensamento de grupo, e como uma forma de garantir que os desenvolvedores mais experientes, ou mais falantes, não se sobreponham a todos na sala.

Ambas as partes do refinamento devem ser feitas separadamente e, em um ambiente distribuído, às vezes pode ser feita mais facilmente.

Aqui está um exemplo de como seria uma sessão de refinamento de backlog distribuído.

Cada um analisa o refinamento por conta própria

O refinamento começa com o dono do produto ou a pessoa que possui a história introduzindo os requisitos, objetivos e resultados desejados da história.

Isso pode ser feito ao vivo por meio de discussão ou pode ser algumas linhas escritas dentro da própria história. O dono do produto deve incluir requisitos detalhados, cenários, casos de falha, regras de negócios e outros itens importantes para completar a história.

Cada membro da equipe de produto deve analisar a história por conta própria, para garantir que a história conforme escrita corresponda à compreensão do que estão discutindo.

É muito fácil em uma situação de grupo presumir que outros membros da equipe têm o mesmo entendimento, ou eles entendem ambiguidades ou partes da história que não são claras.

Façam perguntas juntos no refinamento

Ao ler a história, cada desenvolvedor deve fazer perguntas esclarecedoras. Cada membro da equipe terá uma lista de itens que precisam de mais informações ou mais detalhes e devem estar preparados para perguntar ao dono do produto.

Esta parte deve ser feita em grupo, pois haverá perguntas de outros membros da equipe, e uma pergunta provavelmente gerará mais algumas. Os desenvolvedores devem fazer perguntas ao dono do produto até sentirem que entendem bem a história e todos concordarem que todas as perguntas foram respondidas, incluindo novas perguntas que surgiram durante a própria discussão.

Isso não significa que a história seja tão detalhada a ponto de não ter mais nada a ser considerado, mas sim que a história atendeu à “definição de pronto” para a equipe.

Reunião de backlog produtiva

Estimar o refinamento separadamente

Uma vez que a história atende à definição de pronto, cada desenvolvedor decide por si mesmo sobre o tamanho da história. Diferentes metodologias usam diferentes mecanismos para decidir como definir o escopo de uma história; a maioria dos projetos ágeis usa pontos de história.

Esses pontos pretendem representar uma visão geral da dificuldade de uma história, incluem complexidades desconhecidas, riscos, dependências e esforço real para completá-la.

Quando as estimativas são feitas ao vivo em uma reunião, cada desenvolvedor as descobre por conta própria, seja usando o planning poker ou por algum outro método.

Cada desenvolvedor terá uma visão diferente sobre o quão difícil será concluir uma história, seja devido à experiência passada, ou usando uma solução da qual apenas alguns membros da equipe estão cientes, ou talvez conhecendo um ponto de discórdia da última vez que a equipe lidou um pedido como este.

Seja qual for a causa, mesmo quando feito ao vivo, cada membro da equipe cria o que pensa por conta própria. Esse valor é então revelado à equipe, de uma só vez, o que leva a uma discussão e a um resultado final.

Fazer isso de maneira distribuída, na verdade, torna essa etapa mais fácil. Cada desenvolvedor pode levar seu tempo para entender o espaço do problema, e sua solução.

Quando todos dizem que estão prontos, a discussão final pode começar e podem chegar a sua própria determinação quanto ao escopo, sem ter uma sala cheia de pessoas olhando para eles enquanto ponderam.

Discutir o refinamento e finalizar em equipe

Uma vez que as estimativas de esforço de todos são conhecidas, a equipe deve se reunir novamente e discutir o resultado. É raro que todos na equipe tenham a mesma opinião; alguns serão mais altos ou mais baixos do que outros, e pode haver um ou dois valores atípicos.

Nesse ponto, a equipe analisa os processos de pensamento uns dos outros e como eles acabaram com seu valor. A equipe pode então voltar a votar em particular ou simplesmente decidir chegar a um acordo que todos possam aceitar.

Uma vez que isso seja resolvido, a equipe pode dividir a história em tarefas que podem ser feitas individualmente. Ser distribuído pode facilitar essa parte; todos precisam estar confortáveis ​​com o valor final por conta própria.

Estar separado pode ajudar a impor isso e evitar que as pessoas concordem simplesmente em concordar ou permitir que uma pessoa domine a discussão.

A pessoa que lidera a sessão de refinamento deve garantir que os pensamentos de todos sejam ouvidos e que todos entendam o resultado final.

Pessoalmente, o líder provavelmente olharia ao redor da sala e tentaria julgar com base em acenos de cabeça ou talvez até mesmo julgando o silêncio.

Como todos estão separados, todos precisarão dizer em voz alta que estão alinhados.

Sobre fazer refinamento remoto

Em vez de tentar ler os rostos das pessoas, fazer com que as pessoas falem tornará os sentimentos das pessoas muito mais claros, o que pode realmente levar a uma equipe melhor coordenada no final.

Mais e mais empresas estão executando seus projetos de maneira distribuída. Isso é especialmente verdadeiro durante uma pandemia mundial, mas também estava se tornando cada vez mais verdadeiro devido à natureza global da indústria e aos avanços da tecnologia.

Algumas das atividades e cerimônias associadas à execução de um projeto Agile precisam de um esforço extra para garantir que ainda possam atingir seus objetivos sem que todos precisem estar na mesma sala.

O refinamento da lista de pendências, no entanto, se presta facilmente ao trabalho com uma equipe que não está reunida.

Certas partes dele, certificando-se de que as histórias sejam compreendidas e chegando a estimativas de escopo e esforço, devem ser feitas individualmente.

Outras partes, como fazer perguntas e elaborar um plano final, podem ser feitas em conjunto, com todos se revezando, tomando os devidos cuidados

Como saber quando realizar o refinamento?

Você já entrou em um sprint assumindo uma história de usuário da qual se arrependeu mais tarde? Por exemplo:

  • Uma que você deveria ter dividido um pouquinho mais?
  • Uma que a equipe não tinha uma “pista de bola de neve” de como implementar tecnicamente?
  • Uma em que o valor não era claro do ponto de vista do negócio?
  • Uma onde a estimativa e a realidade não eram iguais?
  • Uma que, quando você “fez”, você não tinha certeza de como determinar que foi feito?

Eu estou supondo, é claro que você tem. Eu encontro essas cenas em equipes que estou treinando o tempo todo. E verdade seja dita, não é um evento terrível. Equipes cometem erros… o tempo todo. E eles geralmente aprendem com eles.

O verdadeiro problema, da minha perspectiva, é com as equipes que continuam fazendo esse sprint sobre sprint sobre sprint. Sim, a dinâmica muda um pouco, mas o resultado final é o mesmo. A equipe está aceitando histórias de usuários que realmente não estão prontas para o sprint!

Então a pergunta é: o que pode ser feito para evitar isso? Existe alguma técnica que impeça que isso aconteça, ou essas equipes estão condenadas a continuar repetindo seus erros? Estou feliz que você perguntou.

Relação com o refinamento do backlog

Então, você pode estar se perguntando: como uma história de usuário fica pronta? Do meu ponto de vista, é parte da preparação ou refinamento contínuo e em tempo real do backlog que uma equipe assume como parte natural do amadurecimento de seu backlog.

Reuniões regulares de preparação fornecem um local para essas discussões, e é simplesmente uma parte de preparar seus backlogs suficientemente para uma execução eficaz.

As equipes geralmente agendam até 10% de seu tempo em cada sprint para refinamento do backlog. Cerca de metade disso é focado em reuniões, talvez duas reuniões de 1 hora por semana.

O restante do tempo é gasto em refinamento individual ou em pequenos grupos. O ponto é que a equipe mergulhe continuamente em seus backlogs de produtos.

O refinamento geralmente examina:

  • Estimativa de história
  • Decomposição da história
  • Definição da história
  • Investigação da história
  • Aceitação da história

Você continua refinando cada história de usuário até que a equipe tenha alcançado um nível sólido de compreensão e a história tenha sido dimensionada adequadamente para caber em um sprint.

Muitas vezes, as equipes estão antecipando vários sprints, de modo que o refinamento não é apenas em torno do que vem a seguir, mas principalmente focando em um fluxo de trabalho para a próxima versão ou mais.

Como eu “Preparo” meu Backlog

Este artigo não pretende ser uma cartilha sobre o processo passo a passo sobre como fazer a preparação do backlog, mas as etapas gerais são as mesmas.

No Agile, existe um acrônimo chamado DEEP que é frequentemente usado. Significa: Detalhado, Emergente, Estimado e Priorizado. Cada um desses quatro poderia ser assunto de seu próprio artigo, mas vamos dar uma olhada em cada um e entendê-los melhor.

O D é para Detalhado

E muitas vezes você verá isso chamado “Detalhado apropriadamente”.

O que isso significa é que cada história de usuário ou item no backlog precisa ser detalhada o suficiente para a posição em que está e que o nível de atenção  esteja pronto para quando um desenvolvedor a pegar.

Dependendo da história, isso pode significar que todos os ativos estão prontos, todos os equipamentos adquiridos ou todos os casos de exceção são conhecidos e descritos.

Se uma história está na parte inferior, pode ser explicada com menos precisão, pois não há necessidade de prepará-la ainda.

O primeiro E é geralmente para Emergente

A ideia é que o backlog mude com o tempo e esse comportamento deve ser adotado, não resistido.

O backlog inicial vem dos pensamentos iniciais do proprietário do produto; é raro que uma pessoa trabalhando sozinha vá acertar tudo na primeira tentativa.

Na verdade, se o backlog mantiver a mesma priorização em todo o projeto, isso é mais um sinal de que algo está dando errado do que um sinal de que as coisas estão dando certo.

À medida que a equipe aprende mais sobre o produto (geralmente chamado de “discovery do produto”), novas coisas serão adicionadas, algumas serão removidas e muitas coisas mudarão de prioridade. Este é um sinal de um backlog saudável.

O segundo E é para Estimativa

Falamos acima que não se espera apenas que o backlog seja uma listagem de requisitos, mas também uma ferramenta para o planejamento do projeto.

Para que isso funcione, os itens precisam ser estimados adequadamente. A estimativa ágil é uma arte e também uma ciência, mas a mesma coisa vale tanto para a estimativa quanto para o detalhamento.

Quanto mais próximo um item estiver do topo da lista de pendências, mais detalhadamente ele deve ser estimado. Os itens na parte inferior podem ter estimativas como “grande” ou “muito grande”.

Mas para fazer um planejamento adequado, os itens no topo devem ter estimativas que ajudem a fazer um plano que funcione. Cada equipe usa um mecanismo diferente, de pontos de história a dias de esforço ou qualquer outra coisa.

O mecanismo real não importa, o que importa é que o que é usado realmente ajuda a criar um plano útil.

Finalmente, o P é para Priorizado

Embora já tenhamos falado sobre isso, o conceito de criar uma lista priorizada pode ser difícil para novos proprietários de produtos. Às vezes, os proprietários de produtos dividem os recursos em listas que não alteram o comportamento, como “obrigatório”, “crítico” e “bloqueador de lançamento”.

Dependendo do seu ponto de vista, todas essas três coisas são as mesmas. 

O Agile propõe uma classificação literal da pilha de prioridades, de um ao infinito, o que ajuda a responder às perguntas sobre o que fazer a seguir, o que está no próximo sprint e o que está fazendo o lançamento.

Se um proprietário do produto não puder priorizar, ou pior, criar várias prioridades principais, a lista de pendências se tornará inútil.

A preparação adequada do backlog o torna DEEP; os itens são devidamente detalhados, novas ideias e novos pensamentos podem surgir, estimativas são criadas e definidas e as prioridades são claras e comunicadas. Sem isso, a equipe terá um desempenho inferior.

Resumo e Conclusão

O backlog deve ser preparado constantemente; histórias de usuários devem ser esclarecidas, especificadas e preparadas para o trabalho. E os itens que estão em desenvolvimento ativo devem ficar o mais estáveis ​​possível.

Isso significa que o ato de preparar o backlog nunca deve parar; muitas equipes reservam tempo para fazer isso semanalmente, incluindo todos da equipe.

O impacto dessa preparação deve ser sentido em intervalos regulares, seja a cada sprint, a cada lançamento ou em algum outro intervalo especificado. Aderir a um cronograma beneficiará a equipe e o produto, que é a essência do Agile.

O backlog do produto serve a muitos propósitos. É a lista canônica de requisitos que são totalmente especificados, em ordem de prioridade, e estão prontos para um desenvolvedor pegar e trabalhar.

Ele também serve como uma ferramenta de planejamento que mostra quais itens estão sendo trabalhados, quais são os próximos itens e fornece algumas informações sobre os recursos que estão em baixa na lista de prioridades.

As partes interessadas podem visualizar a lista de pendências e entender para onde o produto está indo e quando podem esperar ver a funcionalidade pela qual estão esperando. É uma ferramenta poderosa.

Mas além de ser um artefato útil para executar um projeto, também é uma boa maneira de incorporar os princípios do Agile.

Ter a equipe de desenvolvimento como atores completos na preparação dos requisitos e ter o proprietário do produto envolvido no design e na estimativa ajuda a unir a equipe e remove a situação “nós contra eles” com a qual todos lutamos no passado.

A preparação adequada ajuda o produto, a equipe e a organização.

Embora pareça sem importância, pode ser a coisa mais importante que você precisa para acertar.

Estes não são tipicamente parte da definição do “core Scrum”. No entanto, como histórias de usuários e preparação de backlog, são práticas incrivelmente úteis para muitas equipes.

Se você refletir de volta à introdução, essas equipes em dificuldades perderam de vista como pré-definir adequadamente seu trabalho.

Mas, para ser muito mais sucinto: é sempre uma boa prática para equipes ágeis garantir que suas histórias estejam prontas antes de colocá-las em um sprint.