Métodos Ágeis

Desafios do Desenvilvimento de Software

• 1. Responder ao cliente
• 2. Falta na comunicação das equipes
• 3. Entender as necessidades do cliente
• Exercício:
  • Pause o vídeo e analise a figura:
  • Figura da árvore e do balanço
• 4. Compreender porque os projetos falham
• 5. Aumentar a produtividade da equipe de desenvolvimento
  • Lei de Brooks
• 6. Escolher o framework certo para desenvolver o software
  • Metodologias ágeis mais comuns:
    • Extreme Programming
    • Scrum
    • Lean
    • Feature Drive-Programming (FDD)
    • Kanban
    • RUP
    • OpenUp
• Desenvolvimento ágil:
  • Scrum é de longe o mais simples e mais fácil
• 7. Como reter bons profissionais?
• Clientes x Desenvolvedores
• O que é Scrum?

Abordagem Interativa e Incremental

• Segundo Schauber ??:
  • O Scrum é baseado na teoria de controle dos processos empíricos emprega uma Abordagem Interativa e Incremental para otimizar a previsibilidade e reduzir riscos:
• Devido à complexidade, 3 pilares sustentam essa teoria:
  • Tamanho
  • Mudança de requisitos
  • Urgência e necessidade de demonstrar mais valor rapidamente
• É inconcebível, desenvolver sistemas usando o modelo cascata que implementa todo o software de uma única vez
• Abordagem incremental
  • Permite desenvolver o software em pedaços, em partes
  • Sozinhas não faz muito sentido mas através dela temos noção de como ficará o resto
• Abordagem iterativa
  • Começa com um esboço, um rabisco e aos poucos adiciona-se novas camadas até que se chegue ao produto final
  • No caso do software, pode-se começar desenhando o blueprint de uma tela, depois um protótipo e em seguida, o frontend para depois adicionar as funcionalidades
• Desenvolvimento iterativo e incremental é uma estratégia de planejamento que segue a linnha: "Dividir para conquistar"
  • O software é construído em partes, em ciclos
  • A cada iteração tem um novo incremento
• Duarte (2015)
  • Explica que é o produto que deve estar pronto após o sprint podendo ainda ser aperfeiçoado no próximo sprint
  • Importante que o incremento seja algo concreto e utilizável, uma demo ou uma página navegável
• Qual o propósito do Scrum?
  • Scrum vem sendo utilizado para o desenvolvimento de produtos complexo desde o início dos anos 90
  • Scrum não é um processo e nem uma técnica e sim um framework dentro do qual você pode usar várias técnicas ou processos
• Papel do Scrum:
  • Fazer transparecer a eficiência relativa de suas práticas de desenvolvimento para que você possa melhorá-las enquanto provê um framework através do qual os produtos complexos possam ser desenvolvidos
• Teoria do Scrum:
  • Fundamentado na teoria de controle de processos empíricos emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos
• Diferentemente de processos de linha de produção onde se tem um processo produtivo padrão, o Scrum é apropriado para processos empíricos onde não temos fórmulas e receitas prontas pois no meio do processo, desvios podem acontecer assim como em um processo artesanal
• Processo definido:
  • São processos onde se conhece todas as variáveis pois tem poucas ou nenhuma mudança ao longo do processo
  • São repetitivos e previsíveis
  • Geralmente existe uma documentação aplicada à execução do processo
• Processos empíricos
  • Processos onde não se conhece todas as variáveis, não são repetitivos e são imprevisíveis
  • Geralmente baseado no conhecimento e experiência
  • Às vezes, quando desenvolvemos um software não conhecemos todos os requisitos e os que são conhecidos mudam com certa frequência
  • Geralmente todas as estimativas são baseadas no conhecimento das pessoas
  • Isto quer dizer que no mesmo trabalho feito por equipes diferentes a duração pode varias pois a equipe mais experiente deve realizar o trabalho mais rápido
• O desenvolvimento de software é um problema complexo e se comporta de maneira imprevisível

Framework Scrum

• Consiste de um conjunto formado por times Scrum e seus papéis associados, eventos com duração fixa, timeboxes, artefatos e regras
• Times Scrum são projetados para otimizar flexibilidade e produtividade
• Para este fim, são auto-organizáveis, interdisciplinares e trabalham com interações
• O time consiste em desenvolvedores com todas as habilidades necessárias para transformar os requisitos do PO em um pedaço realmente entregável do produto ao final da Sprint
• Fundamentado na teoria dos processos empíricos, o Scrum faz uma abordagem experimental com o intuito de melhorar a previsibilidade e controlar o risco
• 3 pilares para a sustentação das implementações:
  • Transparência
  • Adaptação
  • Inspeção
• Schauber explica:
  • Transparência:
    • faz com que aspectos do processo atinjam resultado e sejam visíveis àqueles que tem o papel de gerenciar os resultados
    • Os aspectos não podem ser somente transparentes, ou sejam quem inspecionar o processo irá acreditar que algo está concluído
  • Inspeção:
    • Os diferentes aspectos que contém no processo devem ser inspecionados com frequência para detectar as variações que não serão aceitas
    • A habilidade e a aplicação com que as pessoas devem verificar os resultados dos trabalhadores são considerados como os outros fatores contidos no processo
• 3 pontos para adaptação e inspeção que verificam o progresso:
  • Daily meeting
  • Sprint review
    • Utilizadas para verificar o progresso em direção à meta para a versão para a entrega e para fazer as adaptações que otimizem o valor da próxima sprint
  • Sprint Planning ou Planning Poker
• Adaptação:
  • 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
• Timebox:
  • Duração fixa e imutável
  • Conceito que diz que a quantidade de tempo não poderá mudar
  • Evita-se atrasos e facilita o planejamento
• Sprint
  • Iteração que deve ser realizada de 2 a 4 semanas no qual a equipe de desenvolvedores deverá produzir um entregável de valor para o cliente
  • Durante a sprint são realizadas as reuniões de área que tem duração fixa de 15 minutos e não mais que isso
  • Ao final da sprint, é feita uma reunião de revisão da sprint
  • Para sprints de um mês, reuniões com duração fixa de 4 horas
  • Para sprints menores, esta reunião pode diminuir de tamanho
• Reunião de planejamento da Sprint (Planning Poker)
  • Pode levar de 4 a 8 horas de duração para sprints de 4 semanas
• Sprints Scrum de 2 semanas:
  • Os times ficam de 2 dias a 3 dias fazendo uma Plannig Poker => não está correto
  • Todos devem se preparar antecipadamente para reduzir este tempo
• Após a revisão da Sprint antes da próxima reunião de planejamento
  • A equipe Scrum tem a reunião de retrospectiva da Sprint
  • Essa reunião tem duração fixa de 3 horas

Cerimônias do Scrum

• Compoem os principais momentos do encontro no framework
• O Scrum emprega os eventos com duração fixa, timeboxes, para criar regularidade
• Entre os elementos do Scrum que tem duração fixa, temos:
  • A reunião de planejamento da versão para a entrega
  • A Sprint
  • A reunião de área
  • A revisão da Sprint
  • A retrospectiva da Sprint
• O coração do Scrum é a Sprint que é uma interação de um mês ou menos, de duração consistente com o esforço de desenvolvimento
• Todas as sprints utilizam o mesmo modelo de Scrum e todas as Sprints tem como resultados um incremento do produto final que é potencialmente entregável
• Cada Sprint começa imediatamente após a anterior
• Release Planning e Planning Poker (Sprint Planning)
• A cada dia do Sprint a equipe faz uma reunião de área chamada Daily Scrum ou Daily Meeting (Standup Meeting)
• Ela tem como objetivos:
  • disseminar conhecimento sobre o que foi feito no dia anterior
  • identificar impedimentos
  • Priorizar o trabalho a ser realizado no dia que se inicia
• Os Daily Scrum normalmente são:
  • realizados no mesmo lugar
  • na mesma hora do dia
  • idealmente na parte da manhã para ajudar a estabelecer as prioridades do novo dia de trabalho
• O Daily Scrum não deve ser usado como uma reunião para resolução de problemas
  • Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possa contribuir para solucioná-lo
• Durante o Daily Scrum cada membro da equipe provê respostas para cada uma das três perguntas:
  • O que você fez ontem?
  • O que você fará hoje?
  • Há algum impedimento no seu caminho?
• Ao final de cada Sprint é feito um Sprint Review Meeting
  • Durante esta reunião o time mostra o que foi alcançado no Sprint, tipicamente, isto tem o formato de um demo das novas funcionalidades
• Os participantes do Sprint Review tipicamente incluem:
  • PO - Product Owner
  • Scrum Team
  • Scrum Master
  • Gerência
  • Clientes
  • Engenheiros de outros projetos
• Durante o Sprint Review o projeto é avaliado em relação aos objetivos do Sprint determinados durante o Sprint Planning
• Idealmente o time completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint mas o importante mesmo é que a equipe atinja o objetivo geral da Sprint
• A última reunião de um Sprint no Scrum tem como objetivo avaliar o processo de trabalho em um Sprint, ou seja, adaptar o que não estiver permitindo a agilidade
• A reunião é conduzida pela equipe para a equipe
• Deste modo, o PO nunca vai à reunião somente se for convidado
• Uma das técnicas mais utilizadas na Retrospectiva é a WWW
  • What Went Well? (O que deu certo?)
  • What Went Wrong? (O que deu errado?)
• Cada membro anota em postites os pontos positivos e os pontos negativos de um Sprint podendo ser usado cores para os mesmos
• O SCrum Master é responsável por dar um limite de tempo para que a equipe fique focada no objetivo de avaliar individualmente o que considerou bom e o que considerou ruim para o Sprint em avaliação
• A fase de coleta leva em torno de 10 minutos
• Os pontos positivos são lifos e se discute os mais relevantes
• Depois, os pontos negativos são apresentados
• A equipe discute os problemas que tem causado maior dor e todos juntos propõem planos de ação
• Existem diversas outras técnicas de Retrospective

Regras da Sprint

Quebrando estórias em tarefa

• Estórias são trabalhos que podem ser entregues e o PO deve se preocupar
• As tarefas são atividades que não podem ser entregues ou atividades que o PO não precisa se preocupar
• Figura
  • Divisão de uma estória em tarefas
  • Quando dizemos que queremos quebrar uma estória em tarefas não significa que serão geradas estórias menores e sim as atividades de programação, teste, banco de dados e etc que são necessárias para que esta estória seja finalizada
  • No exemplo, a primeira tarefa, o Task, criada, é a consulta de reserva de apartamento, ou seja, isso é um pedaço da estória mas não é suficiente para o cliente
  • Às vezes, nem pode ser colocada em produção
• Quando você quebrar as estórias em tarefas durantes a reunião de planejamento do sprint, a equipe tende a pensar nas tarefas de programação
  • Perceba que além das taregas funcionais, ainda existem as tarefas técnicas como por exemplo, criar tabelas
• O cliente ou PO não se interessa no como essa tarefa é realizada, apenas deseja o resultado da funcionalidade pronta
• Esta é uma decisão arquitetural que cabe ao time de desenvolvedores juntamente com o arquiteto pensar na solução
• Com a quebra de tarefas exercitamos a famosa frase de César: "Dividir para conquistar", ou seja, conseguiremos melhores resultados e teremos a sensação de completude a cada dia
  • As tarefas devem ser decompostas para que possam ser feitas em menos de um dia
  • Outra vantagem de se quebrar estórias em tarefas é que a conclusão de cada tarefa menor ajudará a manusear o progresso do time e quando eles irão concluir ou terminar de queimar os pontos do sprint
• O gráfico de burn-down ajuda a visualizar isso e a cada tarefa de um ou meio ponto queimado, desmarcamos um ponto a menos no gráfico e com isso o acompanhamento e andamento do trabalho
• Por esse motivo, cada tarefa deve possuir o tamanho máximo de um dia
  • Se forem horas por exemplo, seria 8
  • Se medirmos em ideal days, seria 1
  • Ou poderia ser em Stor?? point que seria uma medida relativa

Definition of Done

• Acordo formal do Scrum Team que define claramente quais são os passos mínimos para a conclusão de um item potencialmente entregável
• Serve como um contrato entre o Scrum Team e o PO
• Garante que todo o produto gerado pelo projeto estará dentro dos padrões de qualidade estabelecido entre eles
• Criar um Definição de Pronto ou Definition of Done é um esforço colaborativo entre o Scrum Master, o Scrum Team e o PO
• O documento de Definitio of Done pode evoluir normalmente ao longo do projeto

Meta da Sprint

• Trata-se de uma breve descrição do propósito da Sprint, por exemplo:
  • problemas específico do negócio a ser resolvido
  • ou um agrupamento de funcionalidades afins

• Tipicamente, o trabalho durante a sprint é estarem alinhados com o objetivo de alcançar a meta do sprint
• A meta não deveria ser definida como algo que não demonstre o valor real do negócio a ser alcançado no final da sprint
• Portanto não procure definir a meta dessa sprint como algo do tipo:
  • Entregar todos os itens
  • Não gerar nenhum bug
  • Implementar as funcionalidades de pagamento
  • Colocar em produção as funcionalidades
• Seria muito melhor assim:
  • Aumentar o faturamento da loja com novas formas de pagamento
  • Evitar perder vendas e possíveis clientes fiéis por não suportar pagamento com cartão de crédito

Os papéis na Scrum

• Papéis no time Scrum:
  • Scum Master (SM)
  • Product Owner (PO)
  • Team Member
• Scrum Master:
  • Tem a finalidade de representar a garantia de fluidez na organização do processo verificando e fazendo os ajustes necessários para que o método se adapte ao projeto
  • Também serve como guia para toda a equipe aplicar corretamente as práticas do Scrum, afinal, reflete na gerência e o SM fica responsável por impactar as conquistas do produto
    • Realiza os ajustes do processo
    • É o guia de referência do framework Scrum
    • Remove impedimentos
    • Protege o time
    • Ajuda e orienta o PO
    • Pode ser um mebro da Equipe, por exemplo, um desenvolvedor mas pode levar a conflitos
    • Ele nunca deve ser o PO
    • Não é gerente, é um líder servidor, o time Scrum é auto-organizável

• Product Owner:
  • Responsável por manter o Backlog
  • É uma pessoa, não um comitê, este últim pode apenas aconselhar
  • Somente ele muda a prioridade de um item
  • Pode ser um membro do time mas não é aconselhável pois pode reduzir sua habilidade de lidar com partes interessadas
  • O PO nunca pode ser o Scrum Master
• Time:
  • Transformam desejo em produto
  • Intedisciplinares
  • Existem pessoas especialistas
  • Todos contribuem mesmo que precise aprender novas habilidade
  • Não há títulos
  • Sem subtimes
  • Autogerenciáveis
  • Sinergia
  • Tamanho ótimo: 7 mais ou menos 2
  • Times grandes geram muita complexidade
  • Os times pode mudar
  • SM e PO não estão incluídos nesta conta
  • Os membro do time são chamados Pigs, qualquer outra pessoa é chamada de Chicken
  • Galinhas não podem dizer aos porcos como eles devem fazer seu trabalho
  • Galinhas e Porcos vem da seguinte estória:
    • Uma galinha e um porco estão juntos quando a galinha diz:
    • - Vamos abrir um restaurante!
    • O porco reflete e então diz:
    • - Como seria o nome deste restaurante?
    • A galinha diz:
    • - Presunto com ovos"
    • O porco diz:
    • - Não obrigado, eu estaria comprometido, mas você estaria apenas envolvida
• E você em seu time, é um Chicken ou um Pig?

Artefatos do Scrum

• 4 Artefatos:
  • Product Backlog: Lista priorizada de tudo o que pode ser necessário para o produto
  • Sprint Backlog: lista de tarefas para transformar o Product Backlog por um sprint por um incremento do produto potencialmente entregável
  • Release Burndown: Medida do Backlog restante pelo tempo e release mede o product backlog restante ao longo do tempo de um plano de release de produto
  • Sprint Burndown: Mede os itens da sprint backlog restantes ao longo do tempo de uma sprint
• Product Backlog: lista com as devidas características, tecnologias, opções, melhoras apresentadas e possíveis correções para o produto futuro
• Sprint Backlog: Trata-se de uma parte do backlog de produto que o time juntamento com o PO seleciona para que a equipe trabalhe nele durante um sprint e entregue sw funcionando ao final
• Burndown Chart: quantidade restante de tabalho do sprint backlog em uma determinada sprint ao longo do tempo da mesm. Para criar este gráfico determine quanto trabalho resta somando as estimativas do backlog a cada dia da sprint.
• A quantidade de trabalho restante para uma sprint é a soma do trabalho restante para tudo da sprint backlog
• Exemplos:
  • Burndown com um time que estimou sua capacidade produtiva para entregar 33.5 stor points para aquela sprint. A sprint era composta de 15 dias úteis, começava no dia 20 de Julho e terminava no dia 7 de Agosto de um determinado ano
  • A equipe era composto de aproximadamente 9 pessoas. Para traçar a linha ideal, azul-claro, deve-se considerar o total inicial de pontos e dividir pela quantidade de dias ou seja, 33.5/15 = 2,23. Essa é a quantidade média de pontos que o time deve queimar a cada dia para chegar no final da sprint com o burndown na origem do eixo X.
  • Assim, para eu saber qual o ponto tem que marcar no gráfico hoje eu olho o realizado de ontem e debito o valor de pontos queimados no dia
  • Lembrando que estes pontos queimados significam tarefas done
  • Acompanhe estas somas diariamente e utilize-as para criar um gráfico que mostra o trabalho restante ao longo do tempo traçando uma linha através dos pontos do gráfico
  • A equipe pode gerenciar seu progresso para completar o trabalho de uma sprint
  • Uma dica é:
    • Sempre que possível desenho o sprint burndown em um quadro que esteja na área de trabalho da equipe
    • É mais provável que a equipe veja um quadro grande e visível do que um gráfico feito em uma planilha de cálculo
• O gráfico de release burndown registar a soma das estimativas dos esforços restantes do product backlog e coloca no tempo
• O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar
• As unidades de tempo geralmente são sprints
• As estimativas dos itens do product backlog são inicialmente calculadas durante o planejamento da release e posteriormente à medida em que os itens forem sendo criado
• Durante a preparação do product backlog, os itens são revistos e revisados entretanto eles podem ser atualizados em qualquer momento
• A equipe é responsável por todas as estimativas