Metodologias Ágeis

Processos Planejados ou Métodos Ágeis?

  • Métodos ágeis são mais adaptáveis que previsíveis;Métodos ágeis são mais orientados a pessoas que a processos;

  • Pessoas Colocando as pessoas em primeiro lugar; Unidades de programação substituíveis? Gerenciando processo orientado a pessoas; Cargo de líder de Negócio;

  • Processo adaptável;

Princípios do Manifesto

“Nós estamos descobrindo melhores maneiras de desenvolver software, por fazer isso e ajudar outros a fazerem.”

Nós valorizamos:

Indivíduos e interações acima de processos e ferramentas;

Trabalho no software acima de documentação;

Colaboração com o cliente acima de contratos;

Resposta a mudanças acima de seguir um plano;

Isto é, enquanto há valor nos itens da direita, nós valorizamos os itens da esquerda.

Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave Thomas


Metodologias

eXtreme Programming (XP)

Criado por Kent Beck e Ward Cunningham;

Características:

  • Disciplina de desenvolvimento de SW, voltada para equipes pequenas e médias (até 12 pessoas);

  • Projetos com requisitos vagos ou que mudam com frequência;

  • Desenvolvimento de sistemas orientados a objetos;

  • Desenvolvimento incremental;

  • Principal tarefa é a codificação;

Ênfases:

  • Menor em processos formais de desenvolvimento;Maior em disciplina rigorosa;

Programação Extrema! Por quê?

  • Se revisar código é bom, revisaremos o código o tempo todo;

  • Se testar é bom, todos vão testar o tempo todo;

  • Se o projeto é bom, ele fará parte das funções diárias de todos;

  • Se simplicidade é bom, sempre o projeto será o mais simples possível para as funcionalidades atuais;

  • Se arquitetura é importante, todos trabalharam para definir e refinar a arquitetura;

  • Se testes de integração são importantes, então vamos testar e integrar várias vezes ao dia;

  • Se iterações curtas são boas, faremos iterações muito, muito pequenas;


Scrum

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum itself is a simple framework for effective team collaboration on complex products. Scrum co-creators Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain Scrum clearly and succinctly. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

Scrum is:

  • Lightweight

  • Simple to understand

  • Difficult to master

Fonte: https://www.scrum.org/index.php/resources/what-is-scrum?gclid=EAIaIQobChMIn-q9seqX5wIVA4CRCh0H8gAeEAAYBCAAEgJcr_D_BwE

A abordagem Scrum (SCHWABER,2004; SCHWABER e BEEDLE,2001) é um método ágil, mas seu foco está no gerenciamento do desenvolvimento iterativo, ao invés das abordagens técnicas específicas da engenharia de software ágil.

No Scrum, existem três fases. A primeira é a fase de planejamento geral, em que se estabelecem os objetivos gerais do projeto e da arquitetura de software. Em seguida, ocorre uma série de ciclos de sprint, sendo que cada ciclo desenvolve um incremento do sistema. Finalmente, a última fase do projeto encerra o projeto, completa a documentação exigida, como quadros de ajuda do sistema e manuais do usuário, e avalia as lições aprendidas com o projeto.

No Scrum podemos separar o seu conteúdo da seguinte forma:

  • Times Scrum

  • Time-Boxes (Eventos com duração fixa)

  • Artefatos

  • Regras

Times Scrum

  • Autogerenciáveis

  • Interdisciplinares

  • Trabalham em iterações

  • Papéis:

  • ScrumMaster: garantir sucesso

  • Product Owner: aumentar o valor do trabalho

  • Time: desenvolvedores com todas as habilidades necessárias

Time-Boxes

  • Regularidade

  • Eventos:

  • Planejamento da Versão para Entrega

  • Sprint: 1 a 4 semanas

  • Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho;

  • Reuniões de Revisão da Sprint e de Planejamento da Sprint são utilizadas para inspecionar o progresso em direção à Meta da Versão para Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint.

  • Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

Artefatos

  • Backlog do Produto

  • Lista priorizada de tudo que o produto necessita

  • Backlog da Sprint

  • Lista de tarefas para a Sprint

  • Burndown de Versão para Entrega

  • Mede itens restantes do Backlog do Produto

  • Burndown de Sprint

  • Mede itens restantes do Backlog da Sprint

Os Papéis

  • Product Owner

  • Irá passar o escopo e aceitar o produto

  • Scrum Master

  • Não poderá produzir. Deverá cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima

  • Times

  • Produzirá o produto e avaliará o processo

Reunião de planejamento da versão para entrega

  • Estabelecer plano, metas e prováveis resultados

  • “Como podemos transformar a visão em um produto vencedor da melhor maneira possível? “

  • “Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?”

  • Estimar e priorizar o Backlog do Produto para a Versão

Sprint

  • Iteração

  • Composição do time e metas permanecem constantes

  • Desenvolvimento do Backlog da Sprint

  • Incremento para a versão

  • Consiste em:

  • Reunião de planejamento da Sprint

  • Desenvolvimento

  • Revisão da Sprint

  • Retrospectiva da Sprint

Reunião de Planejamento da Sprint

  • Planejamento da iteração

  • O que será feito?

  • Como será feito?

  • Product Owner apresenta o que é mais prioritário no Backlog do Produto

  • Meta da Sprint

  • Quebra dos itens em pequenas tarefas

    • Backlog da Sprint

Reunião Diária

  • 15 minutos em pé

  • O que foi feito desde a última reunião diária?

  • O que vai ser feito antes da próxima reunião diária?

  • Quais são os impedimentos?

  • Inspeção do progresso na direção da Meta da Sprint

Revisão da Sprint

  • Final da Sprint

  • Apresentação da funcionalidade:

    • O que foi feito?

    • O que não foi feito?

    • Próximas coisas a serem feitas?

  • O que correu bem? Houve Problemas? Como resolveram?

  • Estimativas de conclusão

  • Entradas para a Reunião de Planejamentos seguintes

Retrospectiva da Sprint

  • Revisar o processo de desenvolvimento

    • Pessoas

    • Relações entre pessoas

    • Processos

    • Ferramentas

  • Adaptação

  • Tornar a próxima Sprint mais eficaz e gratificante

  • O que correu bem?

  • O que poderia ter sido melhor?

  • Identificação de medidas e melhorias

Pronto ?

  • Incremento deve ser um pedaço completo do produto. Deve estar “pronto”

  • O que “pronto” significa? O que o time quer dizer quando se compromete a “aprontar” um item do Backlog do Produto?

  • Integração a cada novo incremento

  • Testes exaustivos

  • Possibilidade de implantação e utilização

  • Sprints de entrega: terminar os trabalhos “não prontos”


Acessa o material: Metodologias Ágeis