Capítulo I

Introdução à Metodologia Ágil

Fundamentos da Agilidade

Você conhece alguém que se julga sábio? Há mais esperança para o insensato do que para ele.

Provérbios 26:12

A História da Agilidade

• Avançar em pequenos passos é da natureza humana
• Administração Cientifica (Taylorismo)
• 1970 Winston Royce - Waterfall (cascata)
• 80' 90' Smaltalk OOD Crystal Design Patterns
• 1995 Scrum
• 1999 uncle Bob encontra Kent Beck (XP)
• 2000 uncle Bob encontra Martin Fowler
  • Light Weight Process Summit
• 2001 - Snowbird - http://agilemanifesto.org/

Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, não há sucesso no que não se gerencia.

William Edwards Deming,

considerado como “filósofo do movimento de qualidade”.

Visão Geral do Ágil

Restrição Tripla

Bom, rápido, barato, concluído: escolha um dos três!

 

Ágil é um framework que ajuda os desenvolvedores e gerentes

Visão Geral do Ágil

Gráficos na Parede

• Gráfico de Velocidade
• Gráfico de Burndown

Visão Geral do Ágil

A Primeira Coisa que Você Sabe!

• Prazo congelado
• Requisitos mudam constantemente

Visão Geral do Ágil

A Reunião 

A Fase de Análise

A Fase do Design

A Fase de Implementação

Fase: Marchando para a Morte

• O poderoso chefão!
• Definição de análise: é o que os analistas fazem!
• Alterações na analise são jogadas para o design (projeto).
• Implementação tem critérios de conclusão bem definido!
• Primeira comunicação de contratempo.
• Só desgraça!
• Inflação Desenfreada do Processo

Visão Geral do Ágil

Exagero?

Visão Geral do Ágil

Uma Ideia Melhor

• Waterfall: Simples. Direto. Óbvio. E errado!
• Iterações!

Visão Geral do Ágil

Iteração Zero

• Pequena lista de funcionalidades (histórias ou Backlog inicial*)
• traçar um panorama inicial baseado nessas histórias
• Em um projeto ágil estamos sempre analisando e projetando

Visão Geral do Ágil

A Agilidade Gera Dados

• Iteração 1 começa com uma estimativa de quantas histórias serão concluídas
• Premissa: "nós, programadores simplesmente não sabemos quanto tempo as coisas levarão"
• Ao final da iteração uma parte das histórias que planejamos será concluída
• Primeira avaliação - dados!

Visão Geral do Ágil

Esperança versus Gerenciamento

• A perda de esperança é um dos principais objetivos da agilidade.
• O ágil é uma forma de proporcionar uma bela dose precoce e contínua da realidade nua e crua no lugar da esperança.
• Agilidade não é ser rápido.
• A metodologia ágil é saber, o mais cedo possível, o quanto estamos ferrados!

Visão Geral do Ágil

Gerenciando a Restrição Tripla

• Negociar as mudanças no cronograma antecipadamente
• Adição de Pessoal (Lei de Brooks)
• Agilidade não é ser rápido.
• Diminuindo a Qualidade?
  • A única forma de avançar rápido é fazer as coisas bem-feitas.
• ​Mudanças no Escopo - nós temos os dados!

Visão Geral do Ágil

Valor de Negócio Agregado

• A cada iteração peguntamos aos stakeholders quais histórias devem ser implementadas!
• É eles quem decide!

Visão Geral do Ágil

Valor de Negócio Agregado

• A cada iteração peguntamos aos stakeholders quais histórias devem ser implementadas!
• É eles quem decide!

Visão Geral do Ágil

"Resumo"

• Projeto subdividido em iterações
• Saída de cada iteração é calculada para avaliação do planejamento
• As funcionalidades são implementadas de acordo com o valor de negócio
• Máximo de qualidade
• Cronograma gerenciado pela manipulação do escopo

Ciclo de Vida

Conclusão

 Se o software domina o mundo, é a
metodologia ágil que melhor possibilita o desenvolvimento desse
software.

Capítulo II

O Porquê da Metodologia Ágil

Declaração de direitos

O desenvolvimento ágil é
importante por motivos éticos e filosóficos mais enraizados. Eles têm a
ver com profissionalismo e expectativas razoáveis de nossos clientes.

Profissionalismo

Para mim, o desenvolvimento ágil é um compromisso para o
autoaperfeiçoamento.

Comprometimento sólido com a disciplina!

Profissionalismo

O Software Está em Tudo Quanto É Lugar

• + 30 computadores em casa
• Não se faz nada em nossa sociedade sem um software.
• Todos os momentos em que estamos acordados são  monitorados por algum software.
• Muitos deles monitoram até o nosso sono.

Profissionalismo

Nós Comandamos o Mundo!

• E quem desenvolve os softwares? Você e eu. Nós, programadores, comandamos o mundo
• E estamos deixando e muito a desejar a respeito disso
• Case da Toyota

Profissionalismo

O Desastre

• Case da Volkswagen
  • “Não foi uma decisão corporativa, do meu ponto de vista, e até onde eu sei. Por algum motivo, alguns engenheiros de software colocaram o programa nos carros.”
• As disciplinas do desenvolvimento ágil de software é nosso primeiro passo para transformar a programação de computadores em uma profissão fidedigna e honrada.

Expectativas Razoáveis

Os princípios e práticas ágeis atendem diretamente à maioria das expectativas desta lista.

Os comportamentos listados a seguir são o que qualquer diretor de tecnologia (CTO) competente deve esperar de sua equipe.

• "Acho justo dizer que qualquer sistema que exija que seus usuários pensem como programadores para inserir os dados no formato esperado é uma bela de uma porcaria."

Expectativas Razoáveis

Nós Não Entregaremos Merda!

• "Uma fonte dos atrasos é a noção de estabilização. As equipes frequentemente reservam um período de testes durante o qual observam o sistema com o intuito de detectar as falhas. Se nenhuma falha for detectada após X dias, os desenvolvedores se sentirão seguros em recomendar o sistema para a implementação."
• A agilidade resolve esses problemas com a simples regra de que o sistema deve ser tecnicamente implementável ao final de cada iteração.

Expectativas Razoáveis

Disponibilidade Técnica Contínua

• "Caso o sistema esteja tecnicamente pronto para a implementação ao
  final de cada iteração, essa implementação é uma decisão de negócios, não uma decisão técnica.

Expectativas Razoáveis

Disponibilidade Técnica Contínua

• Com o passar do tempo, as desordens no "código" (artefatos do projeto) podem se acumular. Se o código não estiver sempre limpo e ordenado, a equipe será pressionada e isso atrasará as coisas.
• “Refazer o design do sistema, do zero”, respondem eles"

Expectativas Razoáveis

Produtividade Estável

• Software é uma palavra composta. A palavra “ware” significa “mercadoria, produto”.  A palavra “soft” designa a fácil mudança.
• Portanto, o software é um produto fácil de mudar

Expectativas Razoáveis

Adaptabilidade Econômica

• "Quanto mais antigo for o seu sistema, melhor ele deve ser."
• A evidência mais óbvia de nosso fracasso como profissionais: nós
  pioramos as coisas com o passar do tempo.

Expectativas Razoáveis

Melhoria Contínua

• Por que a maioria dos sistemas de software não melhora com o tempo?
• Pelo medo da mudança!

Expectativas Razoáveis

Competência Destemida

Expectativas Razoáveis

Competência Destemida

• Sempre que algum problema for detectado, a equipe de desenvolvimento deve descobrir o que saiu de errado no processo e corrigir!

Expectativas Razoáveis

A QA Não Deve Encontrar Nada

• Resultado inexorável do teste manual, eles são sempre eliminados!
• Testes manuais são caros
• Teste manual deve-se limitar ao que não pode ser validado automaticamente e aos teste exploratório

Expectativas Razoáveis

Automação de Testes

• Exemplo do time de futebol (retaguarda)!
• Exemplo do navio! Abordo do navio, todas tarefas devem ser concluídas.

Expectativas Razoáveis

Um Ajuda o Outro

• A estimativa mais honesta é “não sei”
• Estimativas relativas
• Estimativas com probabilidades (média)

Expectativas Razoáveis

Estimativas Realistas

• Vocês, programadores, são as pessoas que sabem se algo é possível ou não.
• Não importa quantos gerentes exijam
  resultados, você diga “não” quando a resposta realmente for “não”.

Expectativas Razoáveis

Você Precisa Dizer “Não”

• As vezes a empresa auxilia na aprendizagem (PDI**)
• Mas devemos encontrar formas de continuar aprendendo mesmo sem depender da empresa.

Expectativas Razoáveis

Aprendizagem Determinante Contínua

• Aprendam a ensinar uns aos outros.

Expectativas Razoáveis

Mentoria

• Nós Não Entregaremos Merda!
• Disponibilidade Técnica Contínua
• Produtividade Estável
• Adaptabilidade Econômica
• Melhoria Contínua
• Competência Destemida
• A QA Não Deve Encontrar Nada
• Automação de Testes

Expectativas Razoáveis

RESUMO

• Um Ajuda o Outro
• Estimativas Realistas
• Você Precisa Dizer “Não”
• Aprendizagem Determinante Contínua
• Mentoria

Declaração de Direitos

Kent Beck disse que o objetivo da
agilidade era restaurar a divisão entre negócios e desenvolvimento.

direitos do cliente e os direitos do
desenvolvedor se complementam.

Objetivo é estabelecem um equilíbrio de expectativas entre os dois grupos

Declaração de Direitos

Declaração de Direitos do Cliente

• Você tem direito a um planejamento geral...
• Você tem o direito de agregar o máximo de valor possível a cada iteração.
• Você tem o direito de ver o progresso da implementação...
• Você tem o direito de mudar de ideia, substituir e alterar as prioridades...
• Você tem o direito de ser informado sobre mudanças no cronograma...

Declaração de Direitos

Declaração de Direitos do Cliente

O direito dos clientes se limita ao gerenciamento do cronograma no que diz respeito à mudança do escopo. A coisa fundamental que esse direito concede é saber que o cronograma está em risco, de modo que possa ser gerenciado em tempo
hábil.

Declaração de Direitos

Declaração de Direitos do Desenvolvedor

• Você tem o direito de saber o que é necessário por meio de declarações de prioridade transparentes.
• Você tem o direito de desenvolver trabalhos da mais alta qualidade o tempo todo.
• Você tem o direito de solicitar e receber ajuda de colegas, gerentes e clientes.
• Você tem o direito de efetuar e atualizar suas próprias estimativas.
• Você tem o direito de aceitar suas responsabilidades em vez de ter alguém que lhes atribua.

Declaração de Direitos

Declaração de Direitos do Desenvolvedor

Trabalho em equipe envolve profissionais juniores e seniores. A equipe tem o direito de decidir colaborativamente quem fará o quê. Um líder técnico pode solicitar que um desenvolvedor execute uma tarefa, mas não tem o direito de obrigar alguém a fazê-la.

Conclusão

A metodologia ágil não é um processo, não é modismo e não é um conjunto de regras.

Capítulo III

Práticas de Negócios

Maestro Ágil

Existe um conjunto de práticas orientadas aos negócios que o
desenvolvimento deve seguir para dar resultado. Elas englobam
Planejamento, Pequenas Versões, Testes de Aceitação e

Equipe como um Todo.

Projeto

Nós queremos um BI para o Marketing Digital!

• O usuário do BI será o gerente de Mkt;
• Queremos acompanhar o desempenho e indicadores de nossas redes sociais (Linkedin, Facebook e Instagram):
  • posts, visualizações, comentários, compartilhamentos, crescimento e engajamento;
• Toda semana é feito um investimento X em mkt social. Queremos saber qual é o ROI (Return of Investment) de semana. Seria possível ver por dia?

Planejamento

Como estimar um (esse) projeto?

Planejamento

1° Execício

Dividir o projeto em partes constitutivas e depois estimá-las

Planejamento

Estimativa de 3 pontos. O problema!

"é uma abordagem imprecisa para o gerenciamento diário"

Planejamento

2° Exercício

Criar Histórias de usuário (User Store)

Planejamento

INVEST

Diretrizes para User Stores

Planejamento

3° Exercício

Estimando User Store

Técnica Pontos de História
Lei dos grandes números*

https://pt.wikipedia.org/wiki/Lei_dos_grandes_n%C3%BAmeros

Planejamento

Tempo ≠ Esforço

1° Iteração: determinar a História de Ouro

Planning Poker - Escala de Fibonacci

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?

Escala de Fibonacci

O esforço deve ser mais ou menos linear

Planejamento

Tecnicas complementares

Decompor, Mesclar e Spike