Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Tópicos do exame EXIN ASF by Mind Map: Tópicos do
 exame EXIN ASF
5.0 stars - 1 reviews range from 0 to 5

Tópicos do exame EXIN ASF

Mentalidade Ágil

Conceitos de Ágil e Scrum

Agile/Ágil, Refere-se a vários frameworks usados para o desenvolvimento e gerenciamento de iniciativas (projetos ou programas), Principal objetivo desses frameworks é o desenvolvimento rápido e suave para criar uma entrega que satisfaça o cliente, Usa ciclos de vida adaptativos em vez de preditivos, É diferente do modelo Cascata no qual tudo precisa ser definido antecipadamente e os estágios de desenvolvimento são executados sequencialmente, A característica principal do ciclo de vida adaptativo é o desenvolvimento incremental e iterativo, No ciclo de vida adaptativo há várias iterações que geram incrementos que permitem feedback do cliente mais cedo, Os frameworks ágeis somente podem ser aplicados no desenvolvimento de produtos que podem ser construídos de maneira interativa e incremental

Principais frameworks ágeis, Scrum, Nome tem como origem o Rugby, Vantagem principal é que o time irá demonstrar software funcionando a cada poucas semanas, Para adotá-lo é importante que o cliente aceite o seu "valor", O comprometimento da gerência sênior ajuda na transformação cultural necessária para a sua adoção, XP, DSDM Atern, Crystal

4 Valores do Manifesto Ágil, Indivíduos e interações mais que processos e ferramentas, Software em funcionamento mais que documentação abrangente, Colaboração com o cliente mais que negociação de contratos, Responder a mudanças mais que seguir um plano

12 Princípios do Ágil, Nossa maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software de valor., Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente., Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo., Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto., Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho., O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face., Software funcionando é a medida primária de progresso., Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente., Contínua atenção à excelência técnica e bom design aumenta a agilidade., Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial., As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis., Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Escopo do produto em ambientes ágeis, Não forçamos o cliente a especificar tudo antecipadamente, ele pode decidir as coisas ao longo do projeto, Ajudamos o cliente e entender o valor de negócio de cada funcionalidade para evitar desenvolver algo que não seja útil, Em projetos ágeis geralmente o tempo, custo e qualidade são fixos e o escopo (funcionalidades) é variável. Desta forma serão desenvolvidas somente as funcionalidades realmente úteis dentro do custo e tempo e sem comprometer a qualidade.

Práticas do Scrum

Papéis no Scrum

Time Scrum, Refere-se a todos os membros do projeto incluindo o Scrum Master, Time de Desenvolvimento e Dono do Produto, Faz parte da organização executora do projeto, Principais características, Auto-organizado, Gerencia seu esforços em vez de ser gerenciado por outros, Multifuncional, Tem todas as competências necessárias para fazer seu trabalho sem depender de ninguém de fora do time

Product Owner, Responsável pelo Backlog do Produto, Tem mais conhecimento nos aspectos do negócio que conhecimentos técnicos, Preocupado em maximizar o valor do produto e do trabalho do Time De Desenvolvimento, Prioriza os itens do Backlog do Produto com base no retorno sobre o investimento, mas pode utilizar outros critérios de priorização também, É sempre uma pessoa e não um comitê, Pode representar um comitê, mas será uma única pessoa a interagir com o Time de Desenvolvimento, Assume todas as comunicações sobre o conteúdo do projeto com partes internas e externas, Tem que assegurar que cada item do backlog do produto é entendido pelo Time Scrum e outras partes interassadas, Deve se comunicar de forma eficiente com o cliente e com o Time de Desenvolvimento, Deve medir o desempenho do projeto, fazer previsões de data finalização do projeto e comunicar isto para todas as partes interessadas, Pode ser influenciado pelos outros, mas a decisão final é sempre dele, Pode delegar algumas de suas atividades, mas ele continua sendo o prestador de contas delas (por exemplo, escrever os itens do Backlog do Produto)

Scrum Master, É quem mais entende de Scrum e ajuda o Time Scrum no uso de suas práticas, É uma posição gerencial, Gerencia o processo Scrum em vez do Time Scrum, É um líder-servo, Resolve impedimentos (questões) do Time de Desenvolvimento, facilita seus eventos e atua como um coach (treinador), Ajudar o Product Owner no uso de técnicas e facilita eventos relacionados a ele, Pode ajudar pessoas de fora do Time Scrum a interagirem com este time, Ajuda a adotar o Scrum na organização, É possível que a mesma pessoa seja Scrum Master e também membro do Time de Desenvolvimento, mas isto não é recomendado, Não se envolve com o conteúdo da Sprint (estimativas, valor de negócio, histórias, incrementos), Assume todas as comunicações no que se refere ao Processo Scrum, Pode assumir temporariamente a posição do Product Owner em situações específicas (por exemplo, férias)

Time de Desenvolvimento, Inclui os desenvolvedores responsáveis por entregar os itens do Backlog e gerenciar seus próprios esforços, Tamanho ideal de 3 a 9 membros, Mais do que isto tem que usar um modelo escalado, É recomendado que os membros trabalhem em tempo integral em um único projeto, É recomendado não alterar a sua composição frequentemente porque isto diminui sua produtividade, Os membros devem ser capazes de fazer tudo que estiver envolvido em cada item do Backlog do Produto

Gerente de projetos tradicional, Não existe este papel no Scrum, A gestão do projeto é distribuída entre o Product Owner e o Scrum Master

Eventos no Scrum

Timebox, Significa duração de tempo máxima predefinida, Nunca devemos estender a duração de uma timebox porque não terminamos algo, Todos os eventos no Scrum são timeboxed, Ajuda a criar regularidade e disciplina

Sprint, É uma iteração que ocorre no projeto com Scrum, É um evento time-boxed, É um contêiner dentro do qual ocorrem os outros quatro eventos do Scrum, São gerados incrementos ao seu final, São soma de todos os itens do Backlog do Produto no final de uma Sprint, Cada incremento precisa estar "Ponto" e precisa ser potencialmente liberável no final da Sprint, embora a liberação só vai ocorrer com a decisão do Dono de Produto, Não existe Sprint 0, toda Sprint deve ter entrega de incrementos potencialmente liberáveis, Só finaliza quando o seu time-box termina, Cancelamento da Sprint, Somente o Dono de Produto tem autoridade para isto, Pode ocorrer porque o objetivo da Sprint se tornou obsoleto devido a mudanças no Backlog do Produto, estratégias, etc., Quando ocorre, o que estiver "Pronto" será revisado e aceito e o resto volta para o Backlog do Produto, Duração da Sprint, Não pode ter duração maior que um mês, Recomenda-se não fazer alterações nas durações das Sprints frequentemente, A duração pode ser ajustada se identificado que ela não é apropriada para o projeto

Planejamento da Sprint, É o primeiro evento dentro da Sprint, Serve para definir o objetivo da Sprint e selecionar itens para desenvolver a partir do topo do Backlog de Produto, Resulta no Backlog da Sprint que é um comprometimento do que o Time de Desenvolvimento irá entregar ao final, É uma time-box de 8 horas para uma Sprint de um mês, Todos os integrantes do Time Scrum participam

Scrum Diário, Vai ocorrer diariamente durante a Sprint, exceto quando ocorrem outros eventos do Scrum, Sempre uma time-box de 15 minutos, Serve para o Time de Desenvolvimento inspecionar o trabalho feito deste a última reunião e sincronizar seu plano para as próximas 24 horas, Membros respondem a 3 perguntas, O que foi feito deste da última reunião?, O que será feito antes da próxima reunião?, Quais são os obstáculos no caminho?, Recomenda-se que seja sempre no mesmo local e horário para minimizar sua complexidade, Não é recomendado a participação de outras pessoas que não fazem parte do Time de Desenvolvimento, Se outras pessoas participarem, será apenas como ouvintes, Não deve ser vista como uma reunião de status para as partes interessadas

Revisão da Sprint, Ocorre antes do final da Sprint, Serve para demonstrar o incremento "Pronto" da Sprint para o cliente e outra partes interessadas e para receber o feedback, Tem 4 horas de duração para uma Sprint de um mês, Todos os integrantes do Time Scrum participam, Somente devem ser apresentados itens 100% completos de acordo com a definição de "Pronto", Itens que não estiverem "Prontos" devem voltar para o Backlog do Produto e o Product Owner irá definir uma prioridade novamente

Retrospectiva da Sprint, Ocorre depois da Revisão da Sprint, Serve para fazer melhorias no processo de desenvolvimento e coletar lições aprendidas, O Time Scrum inspeciona o que foi feito na Sprint em relação a pessoas, relações, processos e ferramentas, e identifica formas de melhorar para a próxima Sprint, Reunião de 3 horas para uma Sprint de um mês, Todos os integrantes do Time Scrum participam

Backlogs

Backlog do Produto, Características, É uma lista ordenada de tudo que é necessário no produto final do projeto, Em outras palavras, é o escopo do projeto, Todos os itens são descritos de maneira simples, de preferência em linguagem não técnica, Inclui todos os requisitos do cliente, É dinâmico, pode mudar e nunca estará completo, O Dono do Produto é o responsável por mantê-lo, Deve haver apenas um único Backlog de Produto para o projeto, independente do número de times envolvidos, Ordenação dos itens, Feita pelo Dono de Produto, Principais critérios, Benefícios, Pode ser monetário ou não, Custo, Relacionado a quantidade de recursos necessários para desenvolver o item, Pode ser relativo ao tamanho do item, pois o custo do item é proporcional ao seu tamanho, Risco, A ordenação dos itens pode ser uma forma de gerenciar os riscos do projeto, ROI (Return on Investimento), Período de tempo para retornar em benefícios o que foi gasto no item, NPV (Net Present Value), Quantia total investida menos os benefícios ganhos em um período específico descontando a inflação, Payback, Quantidade de tempo necessário para obter de volta o dinheiro investido sem considerar a inflação, Técnica MoSCoW, M (Must Have), Funcionalidade que precisa ter no produto final, S (Should Have), Funcionalidade muito importante para o produto final, sem ela teremos problemas, C (Could Have), Funcionalidade útil, mas não vai criar problemas se ela não existir no produto, W (Will not Have This Time), Funcionalidade interessante, mas não precisamos investir nela agora, Grooming/Refinamento, É o ato de revisão dos itens, o que tipicamente envolve adicionar detalhes, estimativas e prioridades, O Product Owner adiciona prioridade, Time de Desenvolvimento fornece as estimativas, Não deve consumir mais de 10% do tempo do Time de Desenvolvimento, É uma atividade contínua durante a Sprint, não é uma time-box, Itens do Backlog do Produto, Informações Básicas, Valor para o negócio, Baseado no retorno de investimento, Estimativa, Fornecida pelo Time de Desenvolvimento, Usada para determinar quantos itens podem ser desenvolvidos em uma Sprint, Ordem/Prioridade, Definida pelo Product Owner, Histórias de usuário, É o tipo mais comum, Características INVEST, Independentes, Cada item precisa ser independente para determinar sua prioridade e valor para o negócio, Negociáveis, Os itens são negociados com as partes interessadas. Toda história deve ser vista como um convite para uma conversa., Valiosos, Tem valor para o negócio, Estimáveis, Deve ser possível estimar a história de usuário. Se não for possível estimá-la é sinal que ela precisa ser ajustada/reescrita, Pequenos (Small), Os itens no topo do Backlog do Produto tem que ser pequenos e claros (não podem ser maiores que a duração de uma sprint), Testáveis, Toda história de usuário precisa ser testável. Se não for possível testá-la, então precisa ser reescrita, Critérios de aceitação, São escritos atrás do cartão da história de usuário, Auxiliam no esclarecimento das regras e funcionamento do item, Servem para verificar se o item atende as necessidades dos usuários

Backlog da Sprint, É criado durante a reunião de Planejamento da Sprint, Inclui itens selecionados do Backlog do Produto para serem entregues durante uma Sprint e o plano para transformar os itens selecionados em incrementos, Pode ser visto como um plano para a entrega dos itens e realização do Objetivo da Sprint durante a Sprint, O Time de Desenvolvimento é dono deste Backlog e somente ele pode fazer atualizações, O Time de Desenvolvimento pode fazer atualizações ao longo da Sprint, Recomenda-se que os itens do backlog do produto que foram selecionados para a sprint fiquem congelados durante a Sprint, Recomenda-se não fazer inclusão ou remoção de itens durante a Sprint, mas se isto ocorrer é necessário consultar o Dono do Produto, Pode ser representado por um quadro, Spikes, São itens adicionados no Backlog da Sprint quando precisamos investir um tempo de estudos em algo, Podem ser criadas para achar uma forma de desenvolver algo ou para entender melhor uma funcionalidade requerida, Geralmente tem duração máxima de 1 a 2 dias

Definição de "Pronto"

Entendimento compartilhado do significado para um pedaço de trabalho ser considerado "pronto" ou "finalizado"

Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem segui-la como um mínimo

Se “pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto

Se há múltiplos Times Scrum trabalhando no lançamento do sistema ou produto, os times de desenvolvimento de todos os Times Scrum devem mutuamente definir a definição de “pronto”.

Esta definição contém:, Processos de desenvolvimento a serem realizados para cada item do backlog (especificação, desenho, programação, teste, documentação, etc.), Processos organizacionais necessários, Requisitos não-funcionais que precisam ser atendidos (desempenho, segurança, usabilidade, etc.), se estes forem aplicados a todas as histórias de usuário, Exemplo: toda pesquisa não pode demorar mais de 2 minutos, Critérios de qualidade (padrões de código, por exemplo)

Métodos e práticas associadas ao Scrum

Documentação, O Scrum prefere entregar software em vez de documentação, Scrum prega que a documentação seja somente do que for realmente necessário, Haverá certos documentos que continuam sendo indispensáveis, tais como manuais de operação, documentação de configurações

Testes ágeis, Os testes podem fazer parte dos critérios da Definição de "Pronto", Exemplo: teste de aceitação, No ambiente ágil, geralmente os testes são mais frequentes, Sempre que possível, buscar a automação dos testes

Programação em pares, Consiste em ter dois desenvolvedores trabalhando no mesmo computador, Um é chamado de Driver (escreve o código), E outro de navegador (observa e fornece comentários)

Desenvolvimento orientado a testes (TDD), Prática na qual os cenários de teste são preparados antes de escrever o programa, assim o programador sabe o que os outros esperam dele

Refatatoração contínua, Processo de modificar um sistema de software para melhorar a estrutura interna do código sem mudar suas funções externas

Interação contínua, O desenvolvedor integra o código alterado e/ou desenvolvido ao projeto principal na mesma frequência com que as funcionalidades são desenvolvidas, sendo feito muitas vezes ao dia ao invés de apenas uma vez

Propriedade coletiva do código, Ninguém em um time ágil é dono de um código, todos são responsáveis por tudo e todos podem mudar qualquer parte do código

Comunicação osmótica, Os membros do time são colocados para trabalhar na mesma sala, o que favorece ouvir o que se fala e colaborar com a discussão

Times colocalizados, Sempre que possível colocar os times trabalhando na mesma sala

Espaço de trabalho adequado, Importante ter espaço adequado para os eventos do Scrum, Melhor ter um time colocalizado em vez de ter membros espalhados pelos departamentos

Ambiente sustentável, Evitar exigir horas extras do time, Criar um ambiente alegre

Lidando com bugs, Bugs podem ser identificados durante a demonstração na reunião de Revisão da Sprint ou após a liberação do produto para o cliente, Podem ser criadas histórias para os bugs e adicionar ao Backlog o Produto e então o Dono de Produto define em que Sprint os bugs serão corrigidos, Defeito escapado, Defeito que foi descoberto pelo cliente

Planejamento e Estimativas Scrum

Planejamento no Scrum

Cebola do planejamento (Planning Onion), Parecido com os anéis de uma cebola, Os níveis são os momentos que devemos realizar os planejamentos, Em um projeto Ágil há quatro níveis, Planejamento de produto, Planejamento de release(versão), Planeja quando os incrementos serão liberados para os usuários, Planejamento de iteração, Refere-se a reunião de Planejamento da Sprint, Planejamento diário, Refere-se a reunião diária, onde o time avalia os planos de trabalho e o ajusta caso necessário

Planejamento de Release, Produz um plano de quando serão liberadas as funcionalidades (histórias) para os clientes, Realizado pelo Dono do Produto em colaboração com o cliente e outras partes interassadas, A priorização do que deve ser liberado fica por conta do Dono do Produto, Não existe um artefato ou um evento formal no Scrum Guide para isto

Estimativas no Scrum

São fornecida somente pelo Time de Desenvolvimento

Pontos por história, Unidades de esforço que mostram a quantidade de trabalho requerido para uma história comparada com outras ou com uma simples história de referência

Planning Poker, Primeiro, o Dono do Produto explica a história de usuário. Então, o time discute a abordagem de desenvolvimento. E, finalmente, cada membro vota aprentando um cartão com a sua estimativa, Favorece discussão útil no time, Usa a sequência de Fibonacci nas cartas para apresentar as estimativas

Triangulação, Envolve comparar um história com várias outras para aumentar a confiança das estimativas, As histórias podem ser agrupadas por pontos por história para facilitar a comparação (igual a estimativa por afinidade)

Estimativa por afinidade, Agrupam-se as histórias por pontos, Utilizada quando há um grande número de histórias para serem estimadas

Horas ideais / dias ideais, Alguns times ágeis usam esta forma de estimativa porque ela é mais fácil de entender e explicar, Consiste em estimar o esforço de desenvolvimento de uma história em horas / dias úteis de trabalho, descontando horas não produtivas, como tempo para o café, responder e-mails, reuniões administrativas, etc.

Monitorando projetos com Scrum

Monitoramento do projeto

Pode ser acompanhado por um gráfico burn-down

É responsabilidade do Dono do Produto monitorar o projeto em direção ao seu objetivo

O Dono do Produto determina a quantidade de trabalho restante e faz previsões para a data de finalização do projeto

Radiadores de informação

Podem ser qualquer display de informação grande e altamente visível

Servem para acompanhar o status do projeto ou qualquer outro tipo de informação

É necessário que o espaço de trabalho tenha lugar (paredes) para expor radiadores de informação

Todos na organização podem ter acesso

Diagramas comuns, Gráfico Burn-Down, Mostra a quantidade de trabalho restante em vez do trabalho completado, Pode mostrar trabalho restante da Sprint ou do Projeto, Eixo vertical mostra o total de trabalho e o eixo horizontal o tempo que se passou, Linha do desempenho atual acima da linha do planejado mostra que o time está atrasado, Linha do desempenho atual abaixo da linha do planejado mostra que o time está adiantado, Burn-down com barras, Serve para visualizar as mudanças no Backlog, A linha mostra o desempenho atual e cada barra o volume de histórias restantes, Se forem adicionadas novas histórias no backlog, a parte inferior da barra vai descer. Se remover histórias, então a barra vai ficar menor., Gráfico Burn-up, Mostra o volume de histórias "Prontas" em vez de histórias restantes, A linha azul mostra o volume total de histórias no backlog e a linha preta o volume de histórias "Prontas", Calendário niko-niko, Mostra o humor e moral dos membros do time através de emoticons

Monitorando o progresso das Sprints

É de responsabilidade do Time de Desenvolvimento

A reunião Diária do Scrum facilita isto

O progresso pode ser representado por um gráfico burn-down e este pode fazer parte do quadro da Sprint

Velocidade

É o número de pontos de história completados em um certo intervalo

É calculado a partir da média de pontos de histórias prontas em Sprints anteriores

Exemplo: Sprint 1: 80 pontos Sprint 2: 70 pontos Sprint 3: 90 pontos Velocidade: (80 + 70 + 90)/3= 80 pontos

Quadros Kanban

Quadro visual para acompanhar o progresso das atividades

Ajuda a criar transparência e controle

Conceitos avançados no Scrum

Escalando o Scrum

Necessário escalar o Scrum quando o projeto necessita de mais de 9 desenvolvedores

Cada time de desenvolvimento deve ficar com 3 a 9 pessoas

Escalação de Papéis, Scrum Master, Cada Time de Desenvolvimento deve contar com um Scrum Master, Uma única pessoa pode ser Scrum Master local de vários times ao mesmo tempo, Quando existir diferentes Scrum Masters locais, recomenda-se existir um Scrum Master Chefe para a coordenação deles, Product Owner, Cada Time de Desenvolvimento deve contar com um Dono de Produto, Uma única pessoa pode ser Dono de Produto local de vários times ao mesmo, embora na prática dificilmente conseguirá ser Dono de Produto de mais de 2 ou 3 times, Quando existir diferentes Donos de Produtos locais, recomenda-se existir um Dono de Produto Chefe para a coordenação deles

Propriedade do Produto, Deve haver um único Backlog de produto independente da quantidade de times que estão trabalhando no projeto, Os times de desenvolvimento geralmente são distribuídos de acordo com o grupo de funcionalidades, Recomenda-se que todos os times adotem a mesma definição de "pronto" ou pelo menos compatível já que os incrementos precisam ser integrados

Scrum of Scrums, Reunião diária com um representante de cada time para coordenação do trabalho entre eles, Perguntas respondidas nesta reunião, No que o meu time tem trabalhado desde a última reunião?, O que o meu time vai fazer até a próxima reunião?, O que os outros times estavam esperando o nosso time concluir que ainda não foi feito?, O que o nosso time está planejando fazer que poderá afetar os outros times?, Esta é a única pergunta diferente da 3 feitas na reunião Diária de cada time

Sincronização de eventos, Recomenda-se sincronizar os eventos do Scrum entre os times, Por exemplo, iniciar suas Sprints ao mesmo tempo

Estratégias de Divisão de Times, Formar times completamente novos, Dividir os times, Split-and-Seed, Os times originais são divididos em vários times e novos membros são adicionados, Grow-and-Split, Igual ao modelo anterior, mas aqui os novos membros são adicionados gradualmente até cada time ficar com capacidade de 9 membros

Tipos de contratos no Scrum

Tempo & meios ou unidade fixa, É o tipo preferido de contrato no ambiente ágil, Mais compatível com a natureza adaptativa do projeto, O cliente é cobrado por horas trabalhadas ou por Sprint

Preço fixo, Não é indicado para o ambiente ágil, O preço fixo é baseado na definição inicial do escopo que tende a ser fixa, Oferece menos risco para o cliente

Pré-requisitos para adotar o Scrum

Um time Ágil, Scrum Master experiente, Dono do Produto experiente, Time de Desenvolvimento experiente, multifuncional e auto-organziado

Um produto capaz de ser produzido incrementalmente e interativamente

Uma empresa Ágil, A organização também deve entender e respeitar os princípios do Ágil

Um cliente Ágil, Deve estar disponível para colaboração com o time, Deve entender as diferenças entre o ambiente Ágil e o tradicional, Deve estar pronto para adoção de contratos de tempo & meios em vez de contratos de preço fixo

Informações sobre este mapa

Este mapa resume os principais tópicos para o exame EXIN Agile Scrum Foundation usando como referência o livro EXIN Agile Scrum Foundation Workbook

Os tópicos não estão na sequência do conteúdo do curso, mas sim na sequência do currículo do exame

Entendendo o conteúdo deste mapa provavelmente você conseguirá responder a maior parte das questões do exame