■ Retrospectivas

...

Os itens de melhoria devem ser classificados pela equipe e, assim, serem

selecionados para serem implementados no próximo ciclo. Quando o tempo permitir, a
equipe poderá trabalhar na próxima oportunidade de melhoria da lista

■ Preparação de Backlog
O Backlog do Produto é a lista ordenada de todo o trabalho que deverá ser realizado
para garantir a entrega de valor ao cliente, apresentado em forma de história. O
Backlog do Produto deve ser desenvolvido pelo Product Owner e/ou pelas partes
interessadas no produto

■ Refinamento do Backlog
Durante o desenvolvimento do projeto, o Product Owner geralmente trabalha em
conjunto com o Time de Desenvolvimento, de forma a definir quais os itens do
Backlog que serão trabalhados na próxima iteração, considerando o trabalho
necessário para o desenvolvimento de cada item.

■ Reuniões Diárias
As reuniões diárias têm como objetivo fazer um alinhamento com os membros da
equipe, se comprometendo com o trabalho a ser desenvolvido, apresentando potenciais
problemas e garantindo que o trabalho irá fluir sem problemas pela equipe.

A reunião diária não deve durar mais do que 15 minutos. A equipe pode utilizar o
Kanban ou o quadro de tarefas para guiar a reunião. No ágil baseado em iteração,
como é o exemplo do Scrum, todos respondem a perguntas que orientam as atividades a
serem desenvolvidas:
■ O que eu completei desde a última exibição?
■ O que pretendo concluir na próxima etapa?
■ Quais são os meus impedimentos (ou riscos ou problemas)?
O ágil baseado em fluxo tem uma abordagem diferente, com foco no rendimento da
equipe. Perguntas comuns são:
■ O que precisamos fazer para avançar neste trabalho?
■ Alguém está trabalhando em algo que não está no quadro?
■ O que precisamos para terminar?
■ Existem gargalos ou impedimentos no fluxo de trabalho?

ágil baseado em iteração X ágil baseado em fluxo????

■ Demonstração/Review
À medida que o time de desenvolvimento conclui os incrementos de produtos, baseados
nas histórias do Backlog do Produto, o resultado deve ser apresentado para as
partes interessadas. Pelo menos uma vez a cada duas semanas

UNIDADE 3 - CONTEXTO DA ORGANIZAÇÃO ÁGIL

estratégias baseadas apenas em modelagem, análise e conhecimento são mais
propensas a falhar do que as baseadas
em ação.

A estrutura Cynefin é uma ferramenta de solução de problemas que auxilia a entender

e posicionar as situações em domínios definidos por relacionamentos de causa e
efeito

■ Contexto Óbvio: Melhores Práticas

Contextos simples/óbvios são caracterizados por relações claras de causa e efeito
que são facilmente compreendidas por todos.
■ Contexto Complicado: Boas Práticas
Já os contextos complicados podem conter várias respostas corretas e, embora exista
umarelação clara entre causa e efeito, nem sempre é clara a todos
■ Contexto Caótico: Práticas Inéditas
Em um contexto caótico, a busca por respostas corretas é inútil, já que é
impossível deter-
minar as relações entre causa e efeito, porque elas mudam constantemente e não
existem padrões gerenciáveis. No domínio caótico, o maior foco deve ser em resolver
os problemas,
e o estilo de liderança envolve as decisões de cima para baixo, sem envolvimento do
time nas decisões.
■ Contexto Complexo: Práticas Emergentes
Em um contexto complexo, as respostas corretas não podem ser encontradas. Nesse
domínio, é possível entender as
causas do que acontece apenas quando a análise é realizada a posteriori. Os
paradigmas tradicionais de gerenciamento são insuficientes. Os líderes devem
reconhecer que, em um domínio
complexo, o ideal é implementar um modelo de gerenciamento mais experimental, com
tolerância a falhas. Nesse contexto, a flexibilidade da mentalidade ágil se
fortalece e representa a melhor resposta para guiar o desenvolvimento de atividades
e o
gerenciamento de equipes.

- características comuns às organizações ágeis:

■ Visão sistêmica
As organizações ágeis entendem que são sistemas compostos por indivíduos
autoconscientes e seus membros entendem que cada uma de suas interações pode afetar
esse sistema de maneiras potencialmente imprevisíveis. colaboração intensa de
equipes e unidades multifuncionais
■ Liderança
Nas organizações ágeis, os líderes devem inspirar os demais membros sem perder a
coesão dentro de todo o sistema. É necessário ao líder ágil compreender que pode
demorar um longo tempo até que os valores ágeis sejam praticados em todos os níveis
da organização.
■ Aprendizado
É inegável que o processo de aprendizado, em qualquer organização, representa um
forte ativo em um mercado altamente dinâmico. as organizações ágeis tornam a falha
uma experiência positiva, que possibilita o aprendi-
zado para todos os membros. Isso só é possível graças ao modelo de transformar
grandes mudanças em uma série de experimentos menores, permitindo que o impacto
dessa falha possa ser convertido em aprendizado contínuo.
■ Ambiente aberto
Para ter a capacidade de lidar com eventos inesperados, as organizações ágeis devem
fornecer um ambiente de abertura e transparência, com culturas que estimulam que as
pessoas
colaborem e compartilhem conhecimento, inclusive com espaços físicos abertos.
Eliminar os silos facilita que a colaboração organizacional ocorra de forma natural
e fluida.
■ Governança a longo prazo
nas organizações ágeis, o mais importante são os resultados de negócios de longo
prazo, adicionado aprendizado de curto
prazo.
■ Construção
Os membros das organizações ágeis se orgulham de seu trabalho e buscam domínio em
suas habilidades.

UNIDADE 4 - O PMBOK® E O GERENCIAMENTO ÁGIL: QUANDO APLICAR?

Embora o Guia PMBOK® não especifique uma metodologia de desenvolvimento de
projetos, é comum que o método cascata (waterfall) seja associado como uma
estrutura que suporta
as práticas do Guia PMBOK®.

Ciclo de desenvolvimento de software, em cascata. Quando uma etapa estiver

concluída, a equipe de desenvolvimento
passa para a próxima etapa.
1. Requisitos: durante a fase inicial, os requisitos potenciais do aplicativo são
analisados e
escritos em um documento de especificação, que expõe o que produto deverá fazer, e
que servirá de base para o desenvolvimento;
2. Projeto: o sistema é analisado para gerar adequadamente os modelos de
arquitetura e componentes que serão utilizados no produto;
3. Implementação: os modelos desenvolvidos nas etapas anteriores são executados e,
caso necessário, integrados em um produto único;
4. Teste: realização de testes identificam problemas no produto, que são resolvidos
através de novos desenvolvimentos;
5. Lançamento: após a realização de testes, o produto funcional é implantado no
ambiente do cliente ou liberado no mercado;
6. Manutenção: possíveis modificações que ocorrem devido a solicitações de
alteração solicitadas pelo cliente ou defeitos descobertos durante o uso do
produto. Essa etapa envolve também suporte e manutenção subsequentes que podem ser
necessários para manter o produto funcional e atualizado.

A principal diferença que o desenvolvimento ágil apresenta para projetos

desenvolvidos utilizando o modelo cascata é que, apesar de os requisitos serem
definidos ao início do projeto, eles podem estar sujeitos a alterações em todas as
fases seguintes.

Capítulo 2 - MÉTODOS ÁGEIS

UNIDADE 1 - DESENVOLVIMENTO LEAN E KANBAN

Lean Development, mais conhecido como desenvolvimento enxuto
minimizar o desperdício e maximizar o valor para o cliente.
Os sete desperdícios tradicionais
da manufatura foram adaptados para o desenvolvimento de software e projetos, sendo:
■ Código ou funcionalidade desnecessária: aumenta o tempo de entrega do produto e
diminui os ciclos de feedback;
■ Iniciar mais do que pode ser concluído: adiciona complexidade desnecessária ao
sistema, necessitando de alternância entre atividades e prejudicando as entregas
previstas;
■ Atraso no processo de desenvolvimento: aumenta o tempo de entrega do produto e
diminui os ciclos de feedback;
■ Requisitos pouco claros ou em constante mudança: resultam em retrabalho e
possível falta de foco;
■ Burocracia: dificulta o desenvolvimento rápido;
■ Comunicação lenta ou ineficaz: resulta em atrasos e frustrações, o que pode
ocasionar atrito entre a área de desenvolvimento e o cliente, seja interno ou
externo;
■ Trabalho parcialmente realizado: não agrega valor ao cliente e impede que a
equipe aprenda com o trabalho;
■ Defeitos e problemas de qualidade: resulta em retrabalho e baixa satisfação do
cliente;
■ Troca de tarefas: resulta em diminuição do tempo disponível para o
desenvolvimento efetivo, podendo prejudicar a qualidade da entrega.

Uma forma de evitar os desperdícios apresentados e aumentar a fluidez do trabalho é

utilizar o Kanban. O termo japonês Kanban significa “sinal visual”.
O quadro Kanban é um mecanismo que facilita a implementação do método Kanban. Esse
mecanismo pode ser físico, com a utilização, principalmente, de post-its
representando os cartões Kanban, ou criado em um ambiente online.
O quadro deve ter colunas diversas para as etapas de acompanhamentos dos trabalhos;
as mais comuns são: a executar, em andamento e concluídas, nas quais é possível
monitorar o
trabalho em andamento (work in progress).

O método, em sua totalidade, deve ser apoiado por uma série de encontros,
conhecidos como cadências do Kanban.
■ Reunião diária: destinada para sincronização diária da equipe, com objetivo de
identificar novos eventos no nível da equipe e apresentar novas informações;
■ Reunião de reabastecimento: possui o objetivo de reabastecer as tarefas no Kanban
e garantir que a equipe tenha a quantidade correta de atividades;
■ Reunião de planejamento de entrega: é especialmente importante quando o processo
de entrega do produto deve ser planejado com mais cuidado;
■ Revisão da entrega de serviço: é o momento de reflexão sobre o estado atual e o
as decisões passadas tomadas pela equipe para atender as expectativas do cliente;
■ Revisão de operação: abrangendo uma parte maior da organização, avalia como as
dependências entre os sistemas Kanban estão sendo balanceadas pela organização com
relação à demanda e capacidade;
■ Revisão de riscos: é uma oportunidade de discutir e avaliar os riscos
relacionados a determinadas tarefas que podem afetar a capacidade de entrega ao
cliente;
■ Revisão da estratégia: é a reunião de mais alto nível que analisa e ajusta a
estratégia com base no equilíbrio entre demanda por serviços e capacidade.

UNIDADE 2 - SCRUM
é “um framework dentro do qual pessoas podem tratar e resolver problemas complexos
e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto
valor possível.”.

A palavra Scrum significa uma das formações em que as equipes em um jogo de rúgbi
se colocam para a reposição de bola, em que todos os membros da equipe estão
unidos.
o Scrum baseia-se em três pilares principais:
■ Transparência: os aspectos relevantes do projeto devem ser bem definidos e
visíveis para todos da equipe, que compartilha a responsabilidade por esses
aspectos;
■ Inspeção: os artefatos do Scrum devem ser inspecionados com frequência para
garantir o progresso em direção às metas da Sprint;
■ Adaptação: se um aspecto do projeto está prejudicando o alcance dos objetivos
pretendidos, esse aspecto precisa ser ajustado o mais rápido possível.

Os papéis de um time Scrum envolvem:

■ o Time de Desenvolvimento;
■ o Scrum Master; e
■ o Product Owner.

Valores do Guia Scrum

■ Compromisso - Em cada ciclo de desenvolvimento, o time se compromete em alcançar
a meta acordada com o Product Owner.
O Scrum Master deve reforçar o compromisso do time quando facilitam o planejamento
da Sprint, além de proteger a equipe de eventuais mudanças durante a Sprint.
■ Coragem - As equipes do Scrum devem se sentir seguras o suficiente para dizer
não, pedir ajuda e aceitar a mudança como parte natural do processo de
desenvolvimento do produto.
O Scrum Master deve promover a coragem da equipe, criando segurança para que os
membros da equipe tenham conversas difíceis entre si, com o proprietário do produto
e com os stakeholders, além de remover impedimentos que atrasam a equipe. O Scrum
Master também deve defender as partes interessadas para evitar mudanças ou projetos
paralelos durante a Sprint, além de ajudar as equipes a se adaptarem quando as
prioridades mudam entre as Sprints.
■ Foco - Os times mais produtivos trabalham em apenas um projeto de cada vez,
evitando a multitarefa. O foco significa que, o que as equipes Scrum iniciam, elas
devem terminar, sempre atentando para limitar a quantidade de trabalho em processo
(limited WIP).
O Scrum Master deve incentivar o foco da equipe, reafirmando na equipe a definição
de pronto, incentivando a participação completa da equipe no Scrum diário e
garantindo que os membros da equipe apenas apresentem o trabalho que está completo
na revisão da Sprint.
■ Abertura - Permitir inspeção e adaptação. O progresso do trabalho deve ser
visível, de forma a antecipar possíveis problemas no desenvolvimento do projeto. O
time deve entrar em contato com o Product Owner para esclarecer dúvidas e com o
Scrum Master para remover impedimentos o mais cedo possível.
O Scrum Master deve facilitar a transparência nos Scrums diários, para que a equipe
esteja sempre ciente do andamento exato da Sprint. O Scrum Master deve incentivar a
receptividade nas revisões de Sprint, garantindo que o feedback das partes
interessadas seja construtivo e que os membros da equipe possam ouvi-lo.
■ Respeito - As equipes ágeis se distinguem por sua intensiva colaboração. Os
membros devem respeitar as ideias dos demais, bem como reconhecer as realizações um
do outro. Além disso, o Product Owner respeita as decisões técnicas dos membros do
time, que respeitam suas decisões de negócios.
O Scrum Master deve promover o respeito em suas equipes. Ele ajuda os membros do
time a se ouvirem durante as reuniões diárias e incentiva o compartilhamento de
desafios e ideias.

O Scrumban combina os princípios do Scrum e Kanban em um sistema puxado de tarefas.

A equipe planeja o trabalho que foi estabelecido
durante o alinhamento e monitora continuamente da lista de pendências. A parte mais
importante do Scrumban é garantir que os limites do trabalho em andamento
sejam respeitados. O Scrumban pode se parecer mais com o Scrum no nível técnico,
mas no nível cultural é mais próximo ao Kanban. Em vez de grandes mudanças
em um momento, o Scrumban incentiva mudanças incrementais. Se uma equipe está
procurando migrar do Scrum para o Kanban, o Scrumban pode fornecer uma transição
suave.

UNIDADE 3 - DESIGN THINKING

O Design Thinking não é só uma mentalidade, mas também um conjunto de ferramentas
que pode ser aplicado em qualquer contexto ou problema, com o objetivo de
estabelecer várias potenciais soluções. Enquanto o ágil é uma abordagem para a
solução de problemas, o Design Thinking é uma abordagem para a identificação
correta de problemas, que demanda muita compreensão dos usuários finais e um
processo iterativo de desenvolvimento de ideias e soluções alternativas que podem
não ser aparentes.

Cinco estágios para determinação do problema:

1. Empatia - Compreensão das pessoas e de seus comportamentos, desejos,
necessidades e motivações.
2. Definição do Problema - Desenvolvimento de uma declaração escrita do problema,
com o objetivo de definir corretamente o desafio a ser abordado, bem como as
necessidades importantes, com base na organização e na perspectiva dos usuários
finais.
3. Ideação - Agora, já com um sólido entendimento dos usuários e uma clara
definição do problema em mente, é o momento de começar a trabalhar em possíveis
soluções. A aplicação de técnicas como brainstorming, mapa mental e criação de
protótipos de papel, entre outros.
4. Protótipo - Criação de protótipos funcionais de forma a colocar um produto real
em funcionamento para a coleta de informações.
5. Teste - Após a prototipagem, vem o teste do usuário. O aprendizado a partir da
experiência dos usuários deve servir como insumo para a repetição do processo
sempre que necessário, até que seja possível estabelecer um MVP (Produto Mínimo
Viável).

Embora o Design Thinking e o ágil possam ser aplicados de forma independente, as

duas abordagens funcionam muito bem em conjunto, criando um ambiente focado no
usuário e na iteração rápida como forma de alcançar os melhores resultados.

UNIDADE 4 - OUTROS MÉTODOS

Programação Extrema (eXtreme Programming - XP) - é uma estrutura de desenvolvimento
de software ágil que visa produzir softwares de melhor qualidade e com maior
satisfação da equipe de desenvolvimento.
http://www.extremeprogramming.org/
As práticas podem ser descritas como:
■ Sentar-se próximo: a conversa face a face é estimulada se a equipe estiver
alocada em um espaço único, sem barreiras à comunicação;
■ Equipe completa: um grupo multifuncional com todas as funções necessárias para o
desenvolvimento e entrega de um produto;
■ Espaço de trabalho informativo: o espaço de trabalho da equipe deve facilitar a
comunicação, tornando o trabalho transparente entre os membros da equipe e com as
partes interessadas, ao mesmo tempo em que deve permitir que as pessoas tenham
privacidade quando necessário;
■ Trabalho energizado: os membros devem ser capazes de estarem totalmente focados
em suas atividades, principalmente sem sobrecarga de tarefas;
■ Programação em pares: a programação deve ser desenvolvida por duas pessoas que
ocupam a mesma estação de trabalho, de forma a resolver problemas de forma mais
rápida e eficiente;
■ Histórias: descrições dos recursos que o produto deve apresentar, servindo como
insumo para o planejamento das tarefas;
■ Ciclo semanal: corresponde a cada iteração. A equipe deve se reunir no primeiro
dia da semana para discutir o progresso até o momento e programar as histórias que
serão entregues naquela semana;
■ Ciclo trimestral: o cliente estabelece os recursos desejados dentro de um
trimestre específico, que fornece à equipe uma visão de como planejar os ciclos
semanais;
■ Slack: adicionar algumas tarefas ou histórias de baixa prioridade nos ciclos
semanais e trimestrais que podem ser descartadas se a equipe se atrasar em tarefas
ou histórias mais importantes;
■ Construção de dez minutos: executar todos os testes em dez minutos, de forma que
sejam executados com frequência, reduzindo o tempo entre possíveis erros;
■ Integração contínua: alterações de código devem ser imediatamente testadas quando
adicionadas a um código maior.

Desenvolvimento Orientado a Recursos (Feature-Driven Development - FDD)

O FDD é um método focado em recursos (em oposição aos métodos focados em entrega).
Os recursos são uma parte fundamental do FDD - eles são para o FDD o que as
histórias de usuários são para o Scrum. as equipes utilizam a documentação para
comunicar informações importantes e, por isso, tendem a se reunir com
uma frequência menor. Outra diferença importante é o usuário final - no FDD, o
usuário real é visto como o usuário final, enquanto no Scrum é normalmente o
Product Owner que é visto como o usuário final.
Uma feature é uma funcionalidade pequena, que possui valor para o cliente no
contexto do seu domínio de negócio.

Crystal
Os métodos Crystal são uma família de metodologias de desenvolvimento de software.
A família Crystal define que cada projeto pode exigir um conjunto de políticas,
práticas e processos adaptados para atender às características exclusivas do
projeto.
A família de metodologias Crystal consiste nas seguintes variantes: Crystal Clear,
Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal
Maroon, Crystal Diamond e Crystal Sapphire. O Crystal Clear é mais apropriado para
projetos de curto prazo, gerenciados por uma equipe de seis desenvolvedores
trabalhando em um único espaço de trabalho. O Crystal Orange, por exemplo, é
adequado para projetos que exigem uma equipe de 10 a 40 membros e uma vida útil de
1-2 anos. Já os métodos Crystal Sapphire ou Crystal Diamond são usados em grandes
projetos que envolvem risco potencial para a vida humana.

Capítulo 3 - FRAMEWORK SCRUM