Você está na página 1de 6

Gestáo Ágil com Scrum, Kanban e Nexus

Seção 1

Projeto – É um esforço temporário empreendido para criar um produto, serviço ou


resultado exclusivo.

Mindset – Modelo Mental em quatro pilares: biologia, linguagem, cultura e experiência


pessoal. É a maneira como vemos o mundo.

Modelo tradicional de gerenciamento de projeto(Cascata) – Requerimento > Projeto >


Implementação > Verificação > Manutenção. Esse modelo tem poucas alterações,
chamado de water fall, onde uma etapa só é avançada após a conclusão da atual.

Modelo Ágil para Software – dividido em iterações onde em todas as iterações se


entrega uma pequena parte de todas as etapas do projeto:
Iteração 1:
Análise
Projeto
Implementação
Teste

Iteração 2:
Análise
Projeto
Implementação
Teste

E assim por diante.

Framework Cynefin(Cunevin) – dividdo em cinco modelos: Simples, Complicado,


Complexo, Caótico e Desordenado.

Ser ágil é eliminar o desperdício. Muitos acreditam que a agilidade deveria trazer, antes
de mais nada, mais velocidade. Mas o que adianta ser rápido e não saber exatamente o
que está sendo feito? Dessa forma o único que se vai conseguir fazer é entregar algo
sem nenhum valor de forma mais rápida.

O modelo cascata é utilizado principalmente quando os requisitos de um determinado


problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando
precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por
exemplo, quando temos um sistema já pronto e precisamos fazer uma adaptação porque
alguma lei governamental foi alterada ou criada.
Também podemos utilizar o modelo cascata quando um software necessita de uma nova
funcionalidade e os requisitos estão bem definidos e são estáveis.
O modelo cascata tem sido usado a séculos na construção civil e sempre com resultados
muito satisfatórios.
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.

Parte superior do formulário


A Simplicidade é um dos 12 princípios ágeis, e ela diz respeito a:
A Arte de maximizar a quantidade de trabalho que não precisou ser feito.

As melhores arquiteturas, requisitos e designs ewmergem de times auto-organizados.

Seção 2

Empirismos = Experiência
Todo conhecimento depende da prática e experimentação no dia a dia.
Possui idéias simples e compstas. Exemplo home e cavalo é uma ideia simples.
Centauro é uma ideia composta que une duas ideas simples.
Em um processo empírico que se ajusta muito bem ao scrum, uma informação é obtida
por observação ao invés de previsão, utilizando a tentativa e erro. Muito utilizado para
problemas complexas entregrando pequenas partes ao longo do projeto, dividos em
pequenas equipes para sempre se ter algo a entregar, acumulando experiência.

3 pilares do Scrum

Scrum é baseado no empirismo, com isso não fixado o escopo do produto e nem os
processos de como construí-lo. Ao invés disso, são criadas iterações onde pequenas
partes utilizáveis do produto são entregues, analisadas, adaptadas e criamos mecanismos
de inspeção. Desta forma os pilares do scrum são:
Transparência, adaptação e inspeção.
Para garantir credibilidade e aplicação dos 3 pilares, o scrum é ocorrido em 5 etapas,
são elas: Sprint, Planejamento da Sprint, Reunião Diária, Revisão da Sprint e
Retrospectiva da Sprint.

Sprints – curtos intervalos de tempo onde certa quantidade de trabalho tem que ser
realizada.É aonde o ciclo se inicia.

Roadmap do produto – Geralmente realizado pelo product Owner, é uma representação


gráfica das entregas parciais ao longo de uma linha do tempo.
Backlog do produto – É gerado no processo de roadmap pelas diversas interações com o
cliente(coleta de requisitos) e pessoas interessadas, escritas pelo dono do produto.
Backlog da Sprint – Concebido em reuniões de planejamento e Sprint onde são
escolhidas as histórias de usuários de alta prioridade são escolhidas para serem
trabalhadas em cada Sprint. São divididas pelos desenvolvedores em tarefas menores e
mais facilmente gerenciáveis com duração máxima de 4 semanas por Sprint.
Normalmente são realizadas reuniões diárias de 15 minutos onde são discutidas os
progressos diários.
Reunião de revisão da Sprint. São reuniões cujo objetivo é realizar a revisão das
entregas potencialmente já utilizáveis com o Product Owner e os interessados para
verificar o andamento e atendimento das expectativas.
Autogerenciamento: A equipe precisa ser autogerenciável no scrum, o que significa que
cada um deve gerenciar suas próprias atividades, eliminando a ideia de um gestor que
cuide das atividades de todos, diminuindo custo e incentivando a equipe a ter
responsabilidades. Para tanto cobra-se que a equipe tenha: Competência, Colaboração,
Respeito e Continuidade. É importante formar um time ao redor de um propósito.

O que é um framework

O Scrum não é uma metodologia, ele é um framework. A metodologia é um passo a


passo para se obter certo resultado. O Framework é a estrutura que proporcionará que
esse resultado seja obtido, e muitas vezes é utilizado para resolver um problema
específico. Uma analogia seria uma receita de ingredientes e passos de como fazer um
pudim, que seria a metodologia. O framework seria a forma que possibilita que o
pudim fique no formato desejado. O Scrum deve ser empregado em sua totalidade caso
contrário, sua funcionalidade será comprometida.

Seção 3 – Papéis e responsabilidades

Um time Scrum é dividido em três papéis: Product Owner, Scrum Master e


Desenvolvedores.

Scrum master – tem o papel identificar quais os impedimentos que bloqueiam a equipe
de realizar as entregas e definir se será necessário recrutar novos desenvolvedores para
resolver os problemas ou treinar os existentes. É um coach. Tem a responsabilidade de
liderar os projetos e não as pessoas.

Product Owner - responsável pela coordenação das necessidades e desejos dos clientes
de um produto junto a equipe de desenvolvimento. Responsável para que a equipe
entrega valor. O único que pode alterar as prioridades. Nem o Scrum máster ou
desenvolvedores podem alterar as prioridades.

Desenvolvedores – Responsáveis pelas entregas e concretização do produto. É ideal que


trabalhem em tempo integral no mesmo projeto e que a composição do time não seja
alterada. Se houver a necessidade de retirar alguém da equipe, o ideal é que não seja
realizado durante o andamento de uma Sprint. Sempre haverá uma queda de
performance quando um membro for alterado, pois outros membros terão que parar para
treinar o novo integrante.

Não existe o papel de Gerente de Projetos no Scrum.

Seção 4 – Scrum Artefatos

Backlog do produto – uma lista ordenada e emergente do que é necessário construir para
entregar um produto. Produto é um veículo para entregar valor. Pode ser um serviço, um
produto físico ou algo mais abstrato. Enquanto existir um produto, o backlog também
existirá.
Backlog da Sprint – é um plano de trabalho criado pelos desenvolvedores. O backlog do
produto é composto por três itens: Meta da Sprint, o que iremos desenvolver para
entregar a Sprint e por último o plano de ação da Sprint. Tarefas só existem no backlog
da Sprint e podem ser alteradas, incluídas e excluídas casos os desenvolvedores achem
necessárias. Já os itens do backlog da Sprint que vem do backlog do produto não devem
ser alterados durante o curso da Sprint. O Backlog da Sprint pertencem aos
desenvolvedores e somente eles devem alterá-los.

História do Usuário: é uma descrição resumida que deve ser fornecida com base no que
deve ser entregue no produto final de acordo com a perspectiva do usuário final.
Quando uma história fica abrangente, ela é chamada de épico. Um épico deve ser
quebrado em histórias menores para serem absorvidas pelo time de scrum. A definição
de uma história ou um épico não é simples e exige bom senso.
Dicas:
Se não cabe em uma Sprint, é um épico;
Se consigo quebrar em mais de um post-it, é um épico;
Se na estimativa gerou muita divergência, é um épico.

Gráfico de Burndown

É a métrica gráfica do andamento do projeto.

Seção 5 – Eventos

Time box – é ter um tempo determinado para executar um trabalho e não ultrapassar
esse tempo. Pode ser do tipo duração fixa e duração máxima.

Perguntas a serem feitas nas reuniões diárias de scrum:


O que eu fiz desde a última reunião?
O que irei fazer até a próxima reunião?
Quais são os impedimentos?

Seção 6 – Iniciando um projeto

Seção 7 – Criando o backlog do produto

Coleta de Requisitos: São divididos em requisitos funcionais e requisitos não


funcionais.

Requisitos Funcionais: define a função de um software ou parte dele. Conjunto de


entradas, seu comportamento e suas saídas. Envolve cálculos, lógicas de trabalho,
manipulação e processamento de dados.
Requisitos Não Funcionais: são relacionados ao uso da aplicação em termos de
desempenho, usabilidade, confiabilidade, disponibilidade, segurança e tecnologias
envolvidas.

Ferramentas de requisitos : Wireframe – Mockup – Protótipo


Wireframe: são ilustrações básicas da estrutura e componentes de uma página ou
aplicativo. Geralmente o primeiro passo do design, depois da concepção mental.

Mockup ou modelo: geralmente focam sobre os elementos de design visual do site ou


aplicativo. São muitas vezes muito próximos do design final do aplicativo ou site e
incluem todos os elementos gráficos, tipografia e outros elementos da página. São
geralmente apenas arquivos de imagem.

Protótipos: são layouts semi-funcionais das páginas e aplicativos e servem para dar um
preview de maior fidelidade do resultado final.

Personas: aproximação de um possível usuário do produto que será desenvolvido.


Definir antes da primeira Sprint.

Ferramentas de requisitos história do usuário: “como um <tipo usuário>, eu quero um


<objetivo>, para que <atenda a uma necessidade>”.
Além da história do usuário é necessário descrever também os critérios de aceitação.

Por exemplo:
História exemplo: Como cliente da loja esportiva, quero poder procurar por uma
determinada peça de roupa para que possa escolher a que melhor se adapte ao esporte
que gosto.

Critério de aceitação:
1- O João poderá informar o nome parcial do tipo de roupa que está procurando.
2- Uma lista de peças deve ser mostrada com base no nome informado.
3- Uma mensagem deverá ser mostrada caso nenhuma peça seja encontrada.

Técnica INVEST de história de usuário: vem do acrônimo em inglês


Indepente(Independente), negotiable(negociável), valuable(valiosa),
estimable(estimável), small(pequeno) e testable(testável).

Você também pode gostar