Métodos Ágeis

Desafios do Desenvolvimento 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 último 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 precisem aprender novas habilidades
  • Não há títulos
  • Sem subtimes
  • Autogerenciáveis
  • Sinergia
  • Tamanho ótimo: 7 mais ou menos 2
  • Times grandes geram muita complexidade
  • Os times podem 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

Gestão Visual (Kanban)

• Kanban é uma abordagem de abastecimento para alcançar o just-in-time
• Nessa abordagem, o fornecimento é ditado pela demanda
• O Kanban se desenvolveu a partir do domínio da produção enxuta e está sendo aplicado como um Método Ágil chave, hoje em dia, na gestão de projetos
• Por isso, o Kanban é um método ágil de desenvolvimento de software baseado nas práticas Lean e que tem como objetivo otimizar o processo de desenvolvimento de software
• Kanban significa Kan - visual e Ban - quadro ou cartão
• Na imagem temos um exemplo de um quadro KanBan utilizado para gerenciamento e controle das estórias e tarefas de um sprint Scrum
• KanBan funciona com tres princípios básicos:
  • Visão do fluxo de trabalho
  • WIP - Limitação do trabalho em curso
  • Cálculo do lead time
• Visão do fluxo de trabalho:
  • Por ser um método japonês traz consigo a gestão a vista de como algo essencial onde todo o trabalho a ser executado é dividido em partes menores escritos em papéis coloridos e auto-adesivos que são colocados em um quadro (Ban)
• Estes cartões são movimentados no quadro de acordo com o que as pessoas executam seu trabalho
• O quadro possui também uma divisão de colunas simbolizando cada estágio do processo:
  • ToDo | Doing | Done
• Limitação do trabalho em curso (WIP):
  • Work in progress consiste em limitar o trabalho com o máximo de trabalho em cartão a ser feito no processo
  • Essa técnica permite que gargalos sejam observados dentro do processo e que algumas pessoas não fiquem sobrecarregadas no trabalho a ser feito, ou seja, possuam vidas próprias
  • Na imagem, os WIP são representados por números em vermelho e em alguns modelos são criados slots dentro das colunas de trabalho
• Cálculo do lead time:
  • Trata-se do tempo médio para se executar um trabalho e mede desde a entrada do cartão na primeira coluna até a saída dele na última coluna
• Uma das funções na tecnologia Kanban é reduzir cada vez mais este tempo médio para que o trabalho seja feito mais rápido
• ScrumBan:
  • Como dito antes, o KAnBan é uma ferramenta que está dentro da tecnologia Lean e já existia muito antes do Scrum. Na concepção do Scrum, as pessoas viram a necessidade de uma ferramenta como tal e tomaram a mesma emprestada do Lean
  • Assim, quando usamos o quadro KanBan no Scrum e aplicamos pelo menos alguns de seus benefícios como WIP e Lead Time podemos dizer que estamos utilizando um ScrumBan
• Trello é bastante conhecido por ser uma ferramenta de gerenciamento de projetos e listas extremamente versátil e pode ser ajustada de acordo com as necessidades do usuário
• Incentiva-se o uso de ferramentas digitais para times remotos. Para times locai, priorizamos o uso do quadro físico. Este além de proporcionar maior visibilidade para todos que estão no ambiente também deve ser colocado num local onde as Dailys acontecem para garantir um maior engajamento de todos

Raízes do Scrum

• Em 1996, Takeuchi e Inonaka, ambos graduados em Berkeley, Califórnia, esccreveram um artigo publicado na Business Review, chamado "The new product development game", o novo jogo de desenvolvimento de produto. Apresentaram o termo Scrum da maneira que nós agora utilizamos no desenvolvimento de software.
• Jeff Sutherland os vê como padrinhos do Scrum. Quando o Scrum foi criado, Jeff estava trabalhando no grupo, Object Technologies e mais especificamente numa empresa chamada Easel Corporation com o produto SmallTalkm, chamado Enphin??. Livro: The Art doing twice the work in half time.
• O Scrum e o rugby:
  • A imagem mostra como é o Scrum no Rugby. Quando a bola é colocada no jogo, todos estão alinhado e atacam ao mesmo tempo, então essa é uma boa metáfora, porque o desenvolvimento de software tornou-se um esporte em equipe. Nos dias de hoje, o desenvolvimento de software é muito mais uma coisa que se faz em equipe do que um esforço individual
• Regras no Scrum:
  • As regras fazem um elo entre as durações fixas (timeboxes), os papéis e os artefatos do Scrum
  • 01. Somente os membros da equipe de desenvolvimento podem falaar durante a Reunião Diária
    • Tem como objetivo proteger o time de pessoas que não são comprometidas com a meta do Sprint e que podem querer dar suas opinições próprias, pontuais e parciais
  • 02. A equipe deve possuir Auto-Gestão
    • Equipes ágeis devem ser auto-gerenciáveis. Pririza-se que não haja uma hierarquia formal mas que todos se sintam responsáveis pela entrega do produto
  • 03. Somente o PO pode definir e alterar a prioridade dos itens do Product Backlog
    • O PO tem esse papel porque ele é uma pessoa de negócio, mais próxima do cliente ou é o próprio cliente
  • 04. Uma pessoa não pode desempenhar o papel de PO e de Scrum Master no mesmo projeto
    • O PO é responsável por conceitos e ideias, por exemplo, o Backlog enquanto o Scrum Master é responsável pela execução e qualidade, por isso, o PO quer mais recursos enquanto o Scrum Master é focado em fazer porém diferentes pontos de vista são apenas a metade dos problemas. A outra metada é o tempo de dedicação, ou seja, uma única pessoa não terá tempo suficiente para executar bem os dois papéis
  • 05. Somente o PO pode cancelar uma Sprint
    • Mais uma vez aqui entra a responsabilidade do PO em fazer o papel de cliente e ser o Porta-Voz mesmo.

Roadmap

• Se você não souber por onde está caminhando, dificilmente chegará ao seu destino final
• Roadmap é uma espécie de mapa, uma poderosa ferramenta visual descritiva que apontará como será o seu produto ou projeto a cada período de sua evolução
  • Essa bússola gerencial alinhará todos os stakeholders, os interessados no projeto em torno dos mesmos passsos sequenciais rumo à construção integral do produto
  • Deixará todos os envolvidos cientes do processo de evolução e quais variáveis envolvem este caminho
• No exemplo de um plano de roadmap pode-se perceber o produto final dividido em 3 frentes de trabalho:
  • Website
  • Mobile
  • Plataforma
• Além dessa divisão por temas, existe a divisão temporal que são os meses ao longo de um ano ou mais
  • Cada linha representa o requisito a ser implementado em um determinado tema e em um determinado espaço de tempo
• O roadmap mostra que após a conclusão dos requisitos de registro Mobile Web, IoS App, Google, FAcebook Login e a API Rest, em Fevereiro de 2015 será lançada uma versão beta do produto
  • Todas as funcionalidades ficam prontas no final de Maio e lá teremos o produto final
• Dicas:
  • Defina seus objetivos:
  • "Se você não souber para onde sua empresa quer ir nós próximos meses, ou até mesmo nos próximos anos, nem comece a fazer o seu roadmap".
  • Mantenha as histórias a nível de negócio
  • Defina um horizonte, podendo ser de 3, 6 a 12 meses e não mais que isso
  • Seja simples! Quanto mais simples for seu roadmap melhor para permitir que faça sua função principal: comunicar ao mundo o seu produto
  • Diga não quantas vezes for preciso. Independente da situação é necessário proteger o seu produto e garantir que ele está indo na direção planejada

Testes Ágeis

• Independentente da metodologia de desenvolvimento, um dos problemas mais recorrentes na criação de software é a alta incidência de defeitos.
• Softwares defeituosos, causam:
  • Lentidão no desenvolvimento
  • Efeitos colaterais
  • Custos altos
• Na metodologia ágil, conhecida como eXtreme Programming (XP), o teste guia o desenvolvimento. Por meio da prática chamada TDD - Test-Driven Development, o desenvolvedor escreve o código de teste antes de escrever o código que implementa a funcionalidade
  • Nesta filosofia, o desenvolvedor é induzido, primeiro a pensar nas regras e restrições da funcionalidade para não mapear estas regras e restrições em testes unitários
  • Depois o desenvolvedor escreve o código da funcionalidade de forma a atender o comportamento esperado que é determinado pelos testes
• O teste ágil é conhecido por ser uma atividade desempenhada por todos os membros do time que ocorre em todas as etapas do ciclo de vida de desenvolvimento através de mecanismos automatizados quando possível e que ocorre frequentemente em ciclos contínuos
• Nas metodologias ágeis, todos são responsáveis pelos testes:
  • A qualidade do software é responsabilidade de todos os membros do time
  • Cada membro do time contribui para a qualidade do software realizando testes sob sua perspectiva
• Dessa forma, os testes ocorrem de maneira colaborativa e complementar da seguinte maneira:
  • Os clientes testam sob a perspectiva da funcionalidade (estória por estória)
  • Os desenvolvedores testam sob a perspectiva do código (método por método)
• Testes sob a perspectiva do cliente
  • Toda a história deve incluir os critérios de aceitação para assegurar que a funcionalidade foi implementada corretamente e atende às necessidades do cliente
  • Para atingir este objetivo, o cliente é responsável por escrever testes de aceitação - Acceptance Tests, para cada história
• Testes sob a perspectiva do desenvolvedor:
  • Enquanto nas metodologias tradicionais, o desenvolvedor apenas escreve código, nas metodologias o desenvolvedor também é responsável pelos testes
  • No entanto, os testes do desenvolvedor tem o objetivo de prevenir e detectar defeitos na perspectiva do código, ou seja,
  • O desenvolvedor deve garantir a qualidade de cada unidade de código individualmente
• Testes unitários:
  • Para demonstrar se a unidade atende seus requisitos, o desenvolvedor escreve testes unitários (Unit Tests)
  • Os testes unitários são normalmente escritos usando o mesmo ambiente e a mesma linguagem de programação utilizada para a implementação da unidade que está sendo testada
  • Em linhas gerais, os desenvolvedores escrevem testes unitários usando bibliotecas especializadas que fornecem um ambiente padronizado, mecanismos para apresentar os resultados da execução dos testes e etc
  • Dentre as bibliotecas mais conhecidas, podemos destacar:
    • JUnit
    • NUnit
    • DUnit
• Testes sob a perspectiva do testador - Agile Testers:
  • # Apontam na direção do testes de aceitação
  • # Apoiam os desenvolvedores e pode até fazer pair programming com eles
  • # Têm uma visão sistêmica e entendem o processo como um todo
  • # Realizam testes exploratórios
  • # São focados em Usabilidade e Qualidade da Usabilidade
• Qualidade de Software:
  • Não está ligada apenas em encontrar mais defeitos. É uma questão de não introduzir defeitos
  • Por isso, é essencial que as equipes de desenvolvimento sejam capazes de reduzir a incidência de defeitos e os custos associados à depuração e correção dos mesmos

Requisitos Ágeis

• Para desenvolver um software ou produto, os métodos ágeis são altamente recomendados
  • Já descobrimos que podemos usar diversos métodos juntos
  • O Scrum pode ser usado para diversos projetos, contudo, ele não faz abordagem sobre engenharia de software
  • O FDD pode ser usado para Engenharia de Software, requisitos de software e também para arquitetura
  • Engenharia de Software 100% ágil
  • O Scrum é utilizado para Gestão de Projetos, já para as práticas de Engenharia de Software podemos utilizar o FDD, para os requisitos de software e a arquitetura e também as práticas do XP para o desenvolvimento de software, codificação, testes e refactoring
• O que é o FDD - Feature Drive Development?
  • Desenvolvimento guiado por funcionalidades é uma metodologia ágil para o gerenciamento e desenvolvimento de software
  • Ela combina as melhores práticas de gerenciamento ágil de projetos com abordagem completa para a Engenharia de Software orientada por objetos conquistando os 3 principais públicos de um projeto de software
    • Clientes
    • Gerentes
    • Desenvolvedores
• Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionais e as mais extremas proporcionando uma transição mais suave para a organização mais conservadora e a retomada da responsabilidade para organizações que se desiludiram com as propostas mais radicais
• O lema da FDD é "resultados frequentes, tangíveis e funcionais"
  • A FDD é uma tecnologia muito objetiva e possui apenas duas fases:
    • Concepção:
      • Pensar um pouco antes de fazer
    • Planejamento:
      • Tipicamente varia entre 1 a 2 semanas
      • Construção - fazer de forma iterativa, tipicamente em iterações de duas semanas
• Os cinco processos são bem definidos e integrados:
  • DMA (Desenvolver um modelo abrangente) - Análise orientada a objetos
  • CLF (Construir a lista de funcionalidades) - Decomposição funcional
  • PPF (Planejar por funcionalidade) - Planejamento incremental
  • DPF (Detalhar por funcionalidade) - Desenho (projeto) orientado por Objetos
  • CPF (Construir por funcionalidade) - Programação e teste orientado a objetos
• A FDD possui características peculiares:
  • Resultados úteis a cada duas semanas ou menos
  • Blocos bem pequenos de funcionalidades valorizada pelo cliente chamadas de "Features"
  • Planejamento detalhado e guia para medição
  • Rastreabilidade e relatórios
  • Monitoramento detalhado dentro do projeto com resumos de alto nível para clientes e gerentes, tudo em termos de negócio
  • Fornece uma forma de saber dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos
• A FDD nos conduz a uma gestão ágil como um todo, desde a engenharia de requisitos aliada ao planejamento até na construção onde os artefatos são produzidos nas demais fases são verdadeiramente implementados

MVP - Minimum Viable Product

• MVP é um conjunto de testes primários feitos para validade a viabilidade do negócio
  • São diversas experimentações práticas que serão desenvolvidas levando o produto a um seleto grupo de clientes mas não é o produto final
  • Estamos falando em um produto com o mínimo de recursos possíveis desde que em sua totalidade, estes mantenham sua função de solução do problema para o qual foi criado
  • Não vale ser apenas funcionalidades soltas, juntas elas devem configurar um produto ainda que em forma de protótipo
• Por que ela é útil?
  • O MVP parte do princípio que é o feedback quem irá nortear o desenvolvimento de um produto fazendo com que a empresa dê apenas o pontapé inicial para uma construção coletiva que virá em seguida
• Como definir o MVP?
  • De início, o que deve ficar claro é que Minimum Viable Product, produto minimamente viável não tem nada a ver com entregar um produto mal-feito antes de terminá-lo e jogá-lo definitivamente ao mercado
  • Não é entregar um software cheio de falhas para saber o que os clientes acham dele ou apontem os problemas
  • É entregar um software que represente o produto final que está para ser entregue mas que trará apenas uma função mais clean, mais enxuta
  • No entanto, já é suficiente para resolver o problema para o qual foi desenvolvido
• Passos para realização de um MVP:
  • 1. A dica é apostar em uma Land Page
  • 2. Tirar a partir das primeiras manifestações de seus Leads, as hipóteses de testes, referenciais ou métricas que serão usados para desenvolver seu MVP
• Só após estas duas etapas iniciais é que sua empresa ou departamento, poderá pensar na criação de um MVP para ser submetido a testes
• Lembre-se de que o objetivo é gastar o mínimo recurso possível sem permitir que o produto deixe de ser um produto para ser só um conjunto de funções sem sentido

Retrospectiva do curso

• Nosso curso abordou os valores e princípios ágeis, sua importância para o mundo do desenvolvimento ágil
• Falamos dos principais desafios de desenvolvimento de software, porque precisamos das tecnologias ágeis
• Discorremos sobre os artefatos do Scrum:
  • Product Backlog
  • Sprint Backlog
  • Sprint Burndown
  • Release Burndown
• Abordagem iterativa e incremental
  • Incremental significa que irá desenvolver seu software em pedaços, em partes
  • Iterativa começa com o esboço e vai mudando a forma e o visual do seu produto
• Cerimônias do Scrum:
  • Reunião de planejamento da versão para a entrega
  • Sprint
  • Reunião diária
  • Revisão das Sprints
  • Retrospectiva da Sprint
• Estórias de usuários
  • Uma estória pode ser caracterizada por uma curta e simples descrição da necessidade do cliente
  • Uma estória precisa ser INVEST
• Estimativas:
  • Planning poker => como as pessoas usam baralho para fazer estimativas
  • Story points => como chegamos até eles e como eles influeciam na velocidade e na capacidade do time
  • Fibonacci
  • Pontos comprometidos no Sprint
• Papéis
  • Cada times Scrum possui 3 papéis:
    • Scrum Master (SM) => Tem a finalidade de representa a garantia de fluidez na organização do processo
    • Product Owner (PO) => Única pessoa responsável pelo gerenciamento do backlog do produto e por garantir o valor do trabalho realizado pelo time
    • Team Member => O time e seus membros transformam o backlog do produto em incrementos de funcionalidades potencialmente entregáveis em cada sprint
• Kanban:
  • Método ágil de desenvolvimento de software baseado nas prátivas Lean e tem como objetivo otimizar o processo de desenvolvimento de software
  • Também representa um quadro onde o time organiza e mantém suas estórias e tarefas
• Outros assuntos:
  • Quebrando estórias
  • Agile Tests
  • Requisitos ágeis
  • Pilares do Scrum
  • Regras
  • Raízes do Scrum

Treinamento presencial

• Métodos Ágeis
  • Daniel Carrara, MBA. CSM e Green Belt
    • 1 de Setembro de 2016
  • Workshop Scrum
    • 14 de Agosto de 2018
    • Ministrado por Leandro Rezende (Scrum Master Brain)
    • Participantes: Luiz Henrique de Oliveira