→ Apresentação

• As estratégias ágeis são cada vez mais utilizadas devido a demanda do mercado

• Nenhuma delas, no entanto, é utilizado exatamente como foi concebido, pois o que realmente importa é a preservação dos valores e dos princípios definidos pelo Manifesto Ágil em 2001

  Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:

• Reconhecer os elementos de um cenário de desenvolvimento ágil.

• Identificar os elementos de uma história de usuário./

• Aplicar histórias de usuário para especificar requisitos funcionais.

  

Desenvolvimento ágil de software Métodos ágeis

• Os princípios de agilidade começaram a ser fortemente difundidos a partir do Manifesto Ágil

• O foco está nas pessoas e a comunicação com o cliente mais do que sobre o formalismo de processos, planos e contratos

• Essa metodologia prioriza processos que agregam valor ao produto final entregue ao usuário

  

• Mindset ágil: atitudes que o time deve ter diante das tarefas que ele precisa desempenhar

O método SCRUM

• Método SCRUM é atualmente considerado o método mais utilizado no mundo ágil

• SCRUM: framework para desenvolver, manter e entregar produtos complexos

• O desenvolvimento é o organizado em torno das sprints

  • O backlog é o repositório de todas as requisições dos clientes e é gerenciado pelo Product Owner (PO)

  • Um item de backlog geralmente é uma história de usuário

  • Só pode ser alocado à sprint um item do backlog que já esteja em um nível de detalhe suficiente para que a equipe possa implementar

• Cerimônias: reuniões com propósito específico e duração máxima estipulada

  • Sprint Planning Meeting (Reunião de Planejamento da Sprint): planejamento de como será realizada a sprint

    • Duração máxima: 8 horas para uma sprint de um mês

  • Daily SCRUM Meeting (Reunião Diária do SCRUM): reuniões curtas que acontecem todos os dias para que a equipe avalie o que fez, o que fará e o que não está andando. No XP elas são chamadas de standup meetings

  • Sprint Review (Revisão da Sprint): visa a reunir equipe e os principais stakeholders para avaliar o que estava planejado, o que foi realizado e quais as perspectivas para as próximas sprints

    • Duração máxima: 4 horas para sprint de um mês

  • Sprint Retrospective (Retrospectiva da Sprint): o objetivo é que o time SCRUM faça uma avaliação interna de como as coisas ocorreram dentro da sprint. A partir daí são propostas as melhorias para as próximas sprints

    • Duração máxima: 3 horas para sprint de um mês

• Product Owner (PO): uma pessoa (que pode representar um comitê ou grupo de pessoas) que gerencia o backlog

• SCRUM Master: remove os impedimentos que atrapalham a realização de uma sprint

• Time SCRUM: desenvolvedores e testadores

Identificação dos elementos da história do usuário

• O conceito de história de usuário foi criado por Kent Beck, na metodologia ágil XP

• História do Usuário: é um cenário de uso de um produto por um tipo específico de usuário

  • XP: é escrita pelo próprio cliente

  • SCRUM: é escrita pelo PO

• 3 Cs da História de Usuário:

  • Cartão (Card): afirmações escritas em primeira pessoa, contendo o papel (quem), a atividade (o que) e o resultado da ação ou o valor de negócio da história (porque)

    • 

    • Papel (quem): quem se beneficiará da funcionalidade ( tipo de usuário)

      • Não use o termo genérico usuário

      • Mapeamento de persona: identifica diferentes perfis que irão interagir com o software

    • Atividade (o quê): descreve a funcionalidade

      • Descrição breve do que o softwar deve fazer

    • Resultado (porque): mostra o problema que a funcionalidade resolve

  • Conversa (Conversation): Nada substitui uma boa conversa para que os requisitos sejam discutidos, interpretados, compreendidos. O objetivo da história de usuário é ser, justamente, o ponto de partida dessa conversa.

    • O que se espera dos stakeholders em ambientes ágeis é o seguinte:

      • As decisões precisam ser tomadas pelos stakeholders no momento adequado em que são necessárias, especialmente as referentes ao escopo e às prioridades.

      • A participação ativa dos stakeholders é necessária.

      • As equipes precisam ter uma visão organizacional e enxergar a necessidade de integração com outros sistemas.

      • Profissionais de produção e suporte precisam ser envolvidos desde o início.

      • Profissionais que atuarão na manutenção do produto (caso seja um time diferente do time de desenvolvimento) deverão ser envolvidos também no início.

  • Confirmação ou Critérios de aceitação (Confirmation ou Acceptance Criteria): se refere aos critérios de aceitação, ou seja, critérios complementares que ajudam a esclarecer como será validada a história. Podemos entender que são uma espécie de complemento da especificação da história

    • Critérios de aceitação não devem ser confundidos com testes funcionais ou testes unitários

      • Esses critérios de testes de aceitação da história

• Boas Histórias de Usuário

  • Bill Wake criou o acrônimo em inglês INVEST

    

  • Independente (Independent): ela pode ser identificada, discutida, implementada e até mesmo liberada para uso de forma independente de outras histórias

  • Negociável (Negotiable): o usuário pode mudar de ideia e a história poderá ser adaptada

    • Mais uma forma de melhorar a comunicação entre o negócio e a equipe de desenvolvimento.

  • Valiosa (Valuable): ela deve agregar valor para alguém. Se ela não agrega valor, ela não deveria estar alocada à sprint

  • Estimável (Estimable): possível estabelecer uma estimativa da complexidade da história para saber se ela é compatível com a duração da sprint ou se precisa ser dividida

  • Pequena (Small): Uma história tem que ser pequena o suficiente para caber em uma única sprint.

    • Quando uma história é grande demais, ela é considerada um épico e deve ser particionada em histórias menores, que podem ser implementadas em uma sprint

  • Testável (Testable): a ideia é que uma história não deve entrar em uma sprint se ela não puder sair e, para sair, ela deve estar testada

• Mapeamento das histórias de usuário

  • De acordo com Patton (2014), os seguintes passos devem ser utilizados para construir a história de usuário:

    • Delimite o problema: para quem o produto está sendo desenvolvido e por que está sendo desenvolvido.

    • Mapeie a visão geral: faça um mapa que seja abrangente em largura, mas raso em profundidade.

    • Explore: aprofunde, entendendo como as outras pessoas fazem a mesma coisa.

    • Gere uma estratégia de entrega: sempre existe muita coisa para ser construída, então, priorize o que agrega mais valor.

    • Gere uma estratégia de aprendizagem: construa o produto mínimo viável e teste com o público-alvo para aprender.

    • Gere uma estratégia de desenvolvimento: divida o que deverá ser desenvolvido em o que deverá ser desenvolvido agora e depois. Desenvolva o que oferece os maiores riscos primeiro