História (Português)

Histórias de agir como uma “língua crioula”, onde ambos os lados (usuários e desenvolvedores) pode concordar suficiente para trabalhar em conjunto de forma eficaz.

—Bill Wake, co-inventor de programação extrema

São descrições curtas de uma pequena peça de funcionalidade desejada, escrita na linguagem do Usuário. Equipes ágeis implementam pequenas fatias verticais de funcionalidade do sistema e são dimensionadas para que possam ser concluídas em uma única iteração.,

As histórias são o artefato primário usado para definir o comportamento do sistema em ágil. São descrições curtas e simples da funcionalidade geralmente contadas a partir da perspectiva do Usuário e escritas em seu idioma. Cada um destina-se a permitir a implementação de uma pequena fatia vertical do comportamento do sistema que suporta o desenvolvimento incremental.

As histórias fornecem apenas informação suficiente para as pessoas de negócios e técnicas para entender a intenção. Os detalhes são adiados até que a história esteja pronta para ser implementada., Através de critérios de aceitação e testes de aceitação, as histórias ficam mais específicas, ajudando a garantir a qualidade do sistema.

As histórias do utilizador fornecem a funcionalidade directamente ao Utilizador Final. Histórias facilitadoras trazem visibilidade aos itens de trabalho necessários para apoiar a exploração, arquitetura, infraestrutura e conformidade.o modelo de requisitos de SAFe descreve uma hierarquia de quatro níveis de artefatos que delineiam o comportamento funcional do sistema: Epic, Capability, Feature, and story. Coletivamente, eles descrevem todo o trabalho para criar o comportamento pretendido da solução., Mas o trabalho de implementação detalhado é descrito através de histórias, que compõem o Backlog da equipe. A maioria das histórias emergem de recursos de negócios e facilitadores no Backlog do programa, mas outros vêm do contexto local da equipe.

cada história é um comportamento pequeno e independente que pode ser implementado incrementalmente e fornece algum valor para o usuário ou a solução. É uma fatia vertical de funcionalidade para garantir que cada iteração oferece um novo valor. As histórias são pequenas e devem ser completadas em uma única iteração (veja a seção de histórias splitting).,

muitas vezes, histórias são escritas pela primeira vez em um cartão de índice ou nota pegajosa. A natureza física do cartão cria uma relação tangível entre a equipe, a história, e o usuário: ele ajuda a envolver toda a equipe na escrita de histórias. Notas pegajosas também oferecem outros benefícios: elas ajudam a visualizar o trabalho e podem ser facilmente colocadas em uma parede ou mesa, rearranjadas em seqüência, e até mesmo passadas quando necessário., Histórias de permitir uma melhor compreensão do âmbito e do progresso:

• “Uau, olhe para todas essas histórias que estão prestes a assinar” (âmbito de aplicação)
• veja todas as histórias que nós realizamos nesta iteração” (o progresso)

Enquanto qualquer pessoa pode escrever histórias, aprovando-os em equipe e a lista de pendências de aceitá-los no sistema de linha de base são de responsabilidade do Proprietário do Produto. É claro que os stickies não escalam bem em toda a empresa, então as histórias muitas vezes se movem rapidamente para ferramentas ágeis de gerenciamento de ciclo de vida (ALM).,

Existem dois tipos de histórias em histórias seguras, histórias de usuários e histórias facilitadoras, como descrito abaixo.

Fontes de histórias

histórias são tipicamente impulsionadas pela divisão de negócios e características facilitadoras, como a Figura 1 ilustra.

histórias de utilizador

as histórias de Utilizador são o principal meio de expressar a funcionalidade necessária. Substituem, em grande medida, a especificação tradicional dos Requisitos., (Em alguns casos, no entanto, eles servem para explicar e desenvolver o comportamento do sistema que é posteriormente registrado para apoiar a conformidade, rastreabilidade, ou outras necessidades.)

porque eles se focam no usuário como sujeito de interesse, e não no sistema, histórias de usuário são centradas em valor. Para isso, a forma recomendada de expressão é o usuário-formulário de voz, da seguinte forma:

Como (papel de usuário), eu quero (atividade), de modo que o valor do negócio)

usando este formato, as equipes são orientados a compreender o que está usando o sistema, o que eles estão fazendo com ele, e porque eles estão fazendo isso., A aplicação do formato ‘voz do usuário’ normalmente tende a aumentar a competência de domínio da equipe; eles vêm a entender melhor as necessidades reais de negócios de seu usuário. A figura 2 apresenta um exemplo.

‘Personas’ descrevem características específicas de usuários representativos que ajudam as equipes a entender melhor seu usuário final. Exemplos de personagens para o piloto na Figura 2 podem ser “Jane” e “Bob”, um tímido piloto., As descrições de histórias, em seguida, referenciam essas personagens (como Jane eu quero…).enquanto a voz da história do Usuário é o caso comum, nem todos os sistemas interagem com um usuário final. Algumas vezes o “Usuário” é um dispositivo (por exemplo, impressora) ou um sistema (por exemplo, servidor de transação). Nestes casos, a história pode assumir a forma ilustrada na Figura 3.

Enabler Histórias

as Equipes deverão desenvolver a arquitetura ou a infra-estrutura para implementar algumas histórias de usuário ou componentes de suporte do sistema. Neste caso, a história não pode tocar diretamente em nenhum usuário final. Estas são histórias facilitadoras e elas suportam a exploração, arquitetura ou infraestrutura. As histórias facilitadoras podem ser expressas em linguagem técnica e não centrada no utilizador, como a Figura 4 ilustra.

Existem muitos outros tipos de Ativador de histórias, incluindo:

• Refactoring e Picos (como tradicionalmente definido no XP)
• a Construção ou a reforma de desenvolvimento/implantação de infra-estrutura
• Execução de trabalhos que requerem a interação humana (por exemplo, índice de 1 milhão de páginas web)
• Criar o produto ou componente de configurações para diferentes propósitos
• a Verificação do sistema de qualidade (e.g.,, performance and vulnerability testing)

Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up.

escrever boas histórias

boas histórias requerem múltiplas perspectivas. Em ágil, todo o time – proprietário do produto, desenvolvedores e testadores – criam um entendimento compartilhado sobre o que construir para reduzir a retrabalho e aumentar o rendimento. As equipes colaboram usando o desenvolvimento orientado ao comportamento( BDD) para definir testes de aceitação detalhados que descrevem definitivamente cada história., Boas histórias necessitam de várias perspectivas:

• os Proprietários do Produto oferece ao cliente a pensar para a viabilidade e a conveniência
• os Desenvolvedores a fornecer viabilidade técnica
• Testadores fornecer pensamento abrangente de exceções, casos extremos, e outras formas inesperadas os usuários podem interagir com o sistema

Colaborativa história escrita, garante que todas as perspectivas são abordados e todos concordam sobre a história do comportamento com os resultados representados na história da descrição, critérios de aceitação e testes de aceitação., Os testes de aceitação são escritos usando a linguagem de domínio do sistema com desenvolvimento orientado ao comportamento (BDD). Os testes BDD são então automatizados e executados continuamente para manter a qualidade incorporada. Os testes BDD são escritos contra os requisitos do sistema (histórias) e, portanto, pode ser usado como a declaração definitiva para o comportamento do sistema, substituindo especificações baseadas em documentos.,

The 3Cs: Card, Conversation, Confirmation

Ron Jeffries, one of the inventors of XP, is credited with describing the 3Cs of a story:

• Card – Captures the user story of intent using an index card, sticky note, or tool. Os cartões de índice fornecem uma relação física entre a equipe e a história. O tamanho do cartão limita fisicamente o comprimento da história e sugestões prematuras para a especificidade do comportamento do sistema., Os cartões também ajudam a equipe a’ sentir ‘ o escopo próximo, uma vez que há algo materialmente diferente em segurar dez cartas na mão de uma pessoa contra olhar para dez linhas em uma planilha.Conversação-representa uma “promessa de uma conversa” sobre a história entre a equipe, o cliente (ou o proxy do cliente), o PO (que pode estar representando o cliente), e outras partes interessadas. A discussão é necessária para determinar o comportamento mais detalhado necessário para implementar a intenção., A conversa pode gerar especificidade adicional na forma de critérios de aceitação (a confirmação abaixo) ou anexos à história do Usuário. A conversa abrange todas as etapas do ciclo de vida da história:
  • refinement Backlog
  • planeamento
  • implementação
  • Demo

estas discussões just-in-time criam uma compreensão partilhada do âmbito que a documentação formal não pode fornecer. A especificação por exemplo substitui a documentação detalhada. As conversas também ajudam a descobrir lacunas em cenários de usuário e NFRs.,confirmação

• – os critérios de aceitação fornecem a informação necessária para garantir que a história é implementada corretamente e abrange os funcionais e NFRs relevantes. A figura 5 apresenta um exemplo. Algumas equipes muitas vezes usam a seção de confirmação do cartão de história para escrever o que eles vão demo.

equipas ágeis automatizam testes de aceitação sempre que possível, muitas vezes em linguagem de negócios legível, domínio específico., A automação cria uma especificação executável para validar e verificar a solução. A automação também oferece a capacidade de testar rapidamente a regressão do sistema, aumentando a integração contínua, refactoração e manutenção.,>Investir em Boas Histórias

A INVESTIR modelo, desenvolvido por Bill serviço de Despertar , descreve as características de boas histórias de usuário:

• I – Independente (entre outras histórias)
• N – Negociável (flexível declaração de intenção, não de um contrato)
• V – Valor (proporcionando uma valiosa fatia vertical para o cliente)
• E – Calculável (pequenas e negociável)
• S – Pequeno (cabe dentro de uma iteração)
• T – Testável (entendeu o suficiente para saber como testá-lo)

a Estimativa de Histórias

equipes Ágeis usar pontos de história e “estimar poker’ para o valor de seu trabalho ., Um ponto de história é um número singular que representa uma combinação de qualidades:

• Volume-quanto existe?complexidade-quão difícil é?conhecimento-o que se sabe?incerteza-o que é Desconhecido?

os pontos de história são relativos, sem ligação a qualquer unidade de medida específica. O tamanho (esforço) de cada história é estimado em relação à menor história, que é atribuído um tamanho de ‘um.”Sequência de Fibonacci modificada(1, 2, 3, 5, 8, 13, 20, 40, 100) é aplicado que reflete a incerteza inerente na estimativa, especialmente números grandes (E.,g., 20, 40, 100).

estimar o Poker

as equipas ágeis usam frequentemente “estimar o poker”, que combina a opinião de peritos, analogia e desagregação para criar estimativas rápidas mas fiáveis. Desagregação refere-se a dividir uma história ou características em menores, mais fácil de estimar peças.

(Note que existem vários outros métodos utilizados também.) As regras para estimar o poker são:

• Os participantes incluem todos os membros da equipe.cada estimador recebe um baralho de cartas com 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, e?
• o PO participa, mas não estima.,
• O mestre Scrum participa, mas não estima, a menos que eles estão fazendo trabalho de desenvolvimento real.
• Para cada item de backlog a ser estimado, o PO lê a descrição da história.perguntas são feitas e respondidas.cada estimador seleciona privadamente um cartão estimativo que representa sua estimativa.
• Todas as cartas são viradas ao mesmo tempo para evitar enviesamentos e para tornar todas as estimativas visíveis.estimadores altos e baixos explicam as suas estimativas.após uma discussão, cada estimador re-estima selecionando um cartão.,as estimativas provavelmente convergirão. Caso contrário, o processo é repetido.

alguma quantidade de discussão preliminar do projeto é apropriada. No entanto, gastar demasiado tempo em discussões sobre design é muitas vezes um esforço desperdiçado. O valor real de estimar o poker é chegar a um acordo sobre o escopo de uma história. Também é divertido!

velocidade

a velocidade da equipe para uma iteração é igual à soma dos pontos para todas as histórias completadas que atendem à sua definição de Done (DoD)., À medida que a equipe trabalha em conjunto ao longo do tempo, sua velocidade média (pontos de história completados por iteração) se torna confiável e previsível. A velocidade previsível ajuda com o planejamento e ajuda a limitar o trabalho em processo (WIP), já que as equipes não assumem mais histórias do que sua velocidade histórica permitiria. Esta medida também é usada para estimar quanto tempo leva para entregar épicos, recursos, capacidades e facilitadores, que também são previstos usando pontos de história.

capacidade

capacidade é a parte da velocidade da equipe que está realmente disponível para qualquer iteração dada., Férias, treinamento e outros eventos podem tornar os membros da equipe indisponíveis para contribuir com os objetivos de uma iteração para uma parte da iteração. Isso diminui a velocidade máxima potencial para a equipe para essa iteração. Por exemplo, uma equipe que em média 40 pontos entregues por iteração ajustaria sua velocidade máxima para 36 Se um membro da equipe estiver de férias por uma semana. Sabendo isso com antecedência, a equipe só se compromete a um máximo de 36 Pontos de história durante o planejamento da iteração., Isso também ajuda durante o planejamento da PI a prever a capacidade real disponível para cada iteração na PI para que a equipe não se comprometa demais na construção de seus objetivos de PI.

início da linha de base para estimativa

no Scrum padrão, a estimativa do ponto de história de cada equipa—e da velocidade resultante—é uma preocupação local e independente. Em escala, torna-se difícil prever o tamanho do ponto da história para épicos maiores e características quando a velocidade da equipe pode variar muito., Para superar isso, as equipes seguras inicialmente calibram um ponto de partida da história, onde um ponto de história é definido aproximadamente o mesmo em todas as equipes. Não há necessidade de recalibrar a estimativa da equipa ou a velocidade. A calibração é realizada uma vez ao lançar novos trens de liberação ágil.

pontos de história normalizados fornecem um método para chegar a uma linha de partida acordada para histórias e velocidade como segue:

• dar a cada desenvolvedor-testador na equipe oito pontos para uma iteração de duas semanas (um ponto para cada dia de trabalho ideal, subtraindo 2 dias para despesas gerais).,subtrai um ponto por cada membro da equipa dia de férias e férias.
• encontre uma pequena história que levaria cerca de Meio dia para codificar e Meio dia para testar e validar. Chama-lhe um.”
• estimar todas as outras histórias em relação a essa”.’

exemplo: assumindo uma equipe de seis pessoas composta por três desenvolvedores, dois testadores, e um PO, sem férias ou férias, então a velocidade inicial estimada = 5 × 8 pontos = 40 pontos/iteração. (Nota: ajustar um pouco mais baixo pode ser necessário se um dos desenvolvedores e testadores também é o mestre Scrum.,)

desta forma, os pontos de história são um pouco comparáveis entre as equipes. A gerência pode entender melhor o custo de um ponto de história e determinar com mais precisão o custo de um recurso ou epic próximo.enquanto as equipes tendem a aumentar sua velocidade ao longo do tempo—e isso é uma coisa boa— na realidade, o número tende a permanecer estável. A velocidade de uma equipe é muito mais afetada pela mudança do tamanho da equipe e do contexto técnico do que pelas variações de produtividade.,histórias menores permitem uma implementação mais rápida e confiável, já que pequenos itens fluem através de qualquer sistema mais rápido, com menor variabilidade e menor risco. Portanto, dividir histórias maiores em pequenas é uma habilidade obrigatória para cada equipe ágil. É tanto a arte como a ciência do desenvolvimento incremental. Dez maneiras de dividir histórias são descritas nos requisitos ágeis de software de Leffingwell ., Um resumo destas técnicas segue:

• passos do fluxo de trabalho
• variações da regra de Negócio
• esforço importante
• simples/complexos

variações dos dadosmétodos de introdução de dados

• qualidades diferidas do sistema

operações (ex., Create, Read, Update, Delete )

• cenários de caso de Uso
• pico de quebra

a Figura 6 ilustra um exemplo de divisão por cenários de caso de uso.

Histórias do Seguro Requisitos do Modelo

Conforme descrito na Segurança de Requisitos Modelo de artigo, o Enquadramento aplica-se um extenso conjunto de artefatos e relações para gerenciar a definição e testes de sistemas complexos em um corpo magro e Ágil de moda. A figura 7 ilustra o papel das histórias neste quadro maior.

At scale, stories are often (but not always) created by new features. E cada história tem testes de aceitação e testes de unidade prováveis. Os testes de unidade servem principalmente para garantir que a implementação técnica da história é correta. Além disso, este é um ponto de partida crítico para a automação de testes, uma vez que os testes unitários são prontamente automatizados, como descrito no artigo de desenvolvimento de testes (TDD).

Saiba mais

Leffingwell, Dean., Requisitos de Software ágil: práticas Lean Requirements para equipes, programas e a empresa. Addison-Wesley, 2011. Cohn, Mike. Histórias De Usuário Aplicadas: Para O Desenvolvimento De Software Ágil. Addison-Wesley, 2004.

última atualização: 17 de dezembro de 2019