Resumão – Metodologia Ágil de Gerenciamento de Projetos

Unidade 1 (Conceitos Ágeis e Contextualização)

As metodologias de desenvolvimento ágil surgiram para desburocratizar os processos

de desenvolvimento de projetos/sistemas.

=> Seu aparecimento: Toyota com o Lean Manufacturing (produção enxuta): fazer o que
importa, descartar o que não importa, eliminando o desperdício – soluções simples –
fazer o certo na hora certa – aceitar mudança – fluxo contínuo de entregas.

=> Gestão de projetos clássica X gestão ágil: métodos ágeis não precisam de
padrões e por isso são mais flexíveis:

=> Histórico dos métodos ágeis:

=> Anos 90: algumas metodologias ágeis: XP (Kent Beck e Ron Jeffries): 5
valores, 14 princípios e TDD - Tecnologia; Scrum (Sutherland, Schwaber, Beedle):
Foco Gerencial; Crystal (AlistairCockBurn): mais flexível que o XP e
Lean(manufatura): estoque 0, conceito de produção enxuta.
=> A partir de 2000: ampla divulgação do SCRUM e algumas experiências são
relatadas;
=> Em 2001: divulgação do Agile Manifesto e a criação da Agile Alliance
(principal detentora dos principais certificados ágeis);
=> Em 2008: modelos tradicionais de referências como CMMI, MPS.BR e
PMBOK, lançam guias para utilização dos seus modelos com práticas ágeis.
=> A partir de 2010: relatos de empresas essencialmente ágeis que obterem
com sucesso certificações de modelos tradicionais como CMMi, MPS.BR e ISO.

=> Principais mitos dos métodos ágeis:

=> Ambientes ágeis são ad hoc, caóticos e indisciplinados.

=> Agilidade significa nenhuma documentação (contém sim documentação, mas uma
documentação útil, não excessiva).
=> Processos ágeis são imaturos e não são rigorosamente seguidos.
=> Não funcionam para equipes geograficamente distribuídas (essa dificuldade
também ocorre em métodos tradicionais).
=> Não funcionam com equipes grandes (funciona melhor em equipes pequenas mas
também é possível aplicar em equipes grandes).
=> Não funcionam em empresas que não são de software (hoje é utilizado em
vários tipos de negócios).
 => Notas: ambientes ágeis costumam ser bem mais silenciosos e
disciplinados que as equipes tradicionais e as equipes são mais maduras e, por isso,
sabem da importância que deve ser dada as cerimônias e aos indicadores e
acompanhamento do projeto.

=> Principais mitos dos métodos tradicionais:

=> Exigem documentos inúteis.

=> São lentos e burocráticos.
=> Só funcionam para projetos grandes em cascata.

=> Manifesto Ágil (2000): priorização sobre questões comuns em projetos, inserindo
pensamento de colaboração, simplificação e ação.

=> Valores do Manifesto:

=> Indivíduos e interações mais que processos e ferramentas: usa-se

ferramentas o tempo todo MAS o foco da importância volta-se para as pessoas.

=> Trabalhar no software mais que documentação abrangente: dar mais

atenção à especificidade do software do que à documentação.

=> Colaboração do cliente mais que negociação contratual.

=> Responder às mudanças mais que seguir um plano.

=> Princípios do Manifesto: baseados em Aprendizado (em ciclos – melhoria contínua),

Feedback (constante) e Desenvolvimento Iterativo (fazer aos poucos):

1. A maior prioridade é satisfazer o cliente por meio da entrega cedo e

frequente de software com valor. (Mudar sempre que necessário - entregar algo de valor é mais
importante que seguir um planejamento inicial.)

2. Mudanças de requisitos são bem-vindas, mesmo em fases tardias do

desenvolvimento. (Ciclos curtos de feedback propiciam melhor aceitação e aplicabilidade da mudança
– processos burocráticos para mudanças são desencorajadores.)

3. Entregar software em funcionamento com frequência, desde a cada duas

semanas até a cada dois meses, com uma preferência por prazos mais curtos.

4. As pessoas do negócio e os desenvolvedores devem trabalhar em conjunto

diariamente ao longo do projeto. (O trabalho em equipe e a constante comunicação é motivada e
incentivada a ser frequente, objetiva e diária.)

5. Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o

suporte que precisam e confie neles para realizarem o trabalho.

6. O método mais eficiente e efetivo de se transmitir informação é a conversa

face a face.

7. Software em funcionamento é a principal medida de progresso. (A

documentação deve ser útil e com o objetivo de aumentar o valor agregado ao cliente traduzido).
 8. Processos ágeis promovem o desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter
indefinidamente um ritmo constante.

9. Atenção contínua à excelência técnica e a um bom projeto aumentam a

agilidade. (A preocupação com a qualidade deve ser única e constante. A qualidade deve ser mais
prioritária que o prazo e a produtividade).

10. Simplicidade - a arte de se maximizar a quantidade de trabalho não feito - é

essencial. (Evita-se o desperdício no desenvolvimento ao não se realizar trabalho que não é necessário
- elaborar documentação útil que vai ser utilizada e planejar com os detalhes que se conhece).

11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se

auto-organizam.

12. Em intervalos de tempo regulares, a equipe reflete sobre como se tornar

mais efetiva e então refina e ajusta seu comportamento.

=> Princípios Adicionais: Modelo iterativo ao invés de cascata – reduz riscos /

Tempo fixo ao invés do Escopo fixo / Mudanças de requisitos fazem parte! / Melhoria
contínua - orientado a pessoas mais que a processos / Desenvolvimento em fatias.

=> Empresas que utilizam conceitos ágeis: Google / Yahoo / Borland / Chemtech /
Petrobrás / Spotify / ProMove / Globo– Horizonte / Caelume LocalWeb / Mc Donalds´s.

Unidade 2 (Agilidade na Gestão de Projetos – Principais Metodologias)

NOTAS / CONCEITOS

=> Frameworks: abordagens.

=> Scrum, Kanban e Scrumban: frameworks ágeis que objetivam facilitar o

gerenciamento de demandas de novos projetos e de operação.

=> Termos e Conceitos do Scrum:

=> Times-boxes: duração de eventos/cerimônias/ciclos.

=> Tasks: tarefas com duração máxima de 1 dia (8 horas).

=> User Storie: requisitos elaborados em uma ou duas frases na linguagem

natural do usuário / escrita pelo PO, com ajudado SM e Team / inseridas e priorizadas
no product backlog, considerando o VA / cada user story é quebrada em tasks / cada
task vira um post-it no task board (conceitos à frente).

=> Formato: Who (user role): é um cliente, um colaborador ou o

administrador do Sistema? / What (goal): qual é o objetivo especifico do projeto que
esta funcionalidade vai alcançar / •Why (reason): qual o motivo desta Story.

=> Todas as stories devem ser I.N.V.E.S.T: Independent / Negotiable /

Valuable / Estimatable / Small / Testable

=> Backlog OU Product Backlog: uma lista que traz o escopo a ser
trabalhado / os requisitos a serem produzidos em um projeto.
 => Sprint: um ciclo de trabalho com time-boxes regulares de 2 ou 4 semanas.

=> Sprint Backlog: escopo de uma sprint específica (conjunto de tasks de cada uma
das stories - conceitos à frente)

=> Sprint Planning Metting OU Estimation Meeting: reunião de

planejamento de uma sprint – se olha o backlog e se forma a sprint backlog

=> Sprint Review: avaliação do projeto em relação aos objetivos da Sprint que
foi determinada na Sprint Planning Meeting.

=> Sprint Retrospective: onde são discutidos os pontos de melhoria e ações

para a próxima sprint.

=> Release: entregas

=> Task Board: quadro usado no monitoramento – to do (a fazer) / doing

(fazendo) / done (feito).

=> BurnDown Chart: gráfico ou figura que mostra a quantidade de stories e o

quanto a equipe (team) está entregando / funciona como um indicador.

=> Stand Up Meeting OU Daily Scrum: reuniões diárias, rápidas e em pé.

=> Product Owner (PO): certo e mais efetivo que seja o cliente / garantir o
ROI (Retorno Sobre Investimento) / conhecer necessidades do cliente, manter os itens do
backlog atualizados e priorizados / aceitar ou rejeitar o que foi produzido / ter alta
participação no início e no fim do sprint / gerenciar os requisitos e planejar entregas
(releases) / disponível para esclarecer dúvidas.

=> Scrum Master (SM): remover os impedimentos do time / remover as

barreiras entre o desenvolvimento e o cliente / garantir o uso do Scrum / proteger o
time de interferências externas / ensinar a maximização do valor agregado / melhorar
o dia-a-dia dos membros do time / combater a ilusão do comando-controle / priorizar
os impedimentos e removê-los / facilitar reuniões.

=> Team (time): multidisciplinar / auto-gerenciado / auto-organizado / produzir

com qualidade e valor para o cliente / ter no máximo 9 integrantes / comprometidos e
responsáveis pelo alcance do objetivo / comunicativos e responsáveis pela resolução
de conflitos.

=> Cerimônias: eventos/reuniões.

=> Termos e Conceitos do Kanban:

=> WIP (Work in Process): o trabalho em andamento / WIP limitado= o ritmo

da equipe se torna equilibrado - não se compromete com muito trabalho de uma só
vez - reduz o tempo gasto em um item - o estabelecido em cada raia = o quanto sou
capaz de realizar em cada raia.

=> Limite Wip: número que representa o limite de trabalho em andamento que
pode estar numa coluna.

=> Hierarquias de itens:

 => Épicos (Epics): estória grande.

=> Estória de usuário (User Story): uma curta e simples descrição de

um recurso.

=> Tarefas (Tasks): os elementos de uma estória.

=> Priorização de itens: itens que estão mais acima tem prioridade de
execução. Também pode ser identificada por cores ou por pontos.

=> Colunas: etapas do processo.

=> Raias: forma de controlar demanda, onde em cada raia um fluxo é distinto
do outro.

=> Buffer / Buffer stage: fila antes do gargalo, ou seja, é o que antecede a
atividade e está aguardando para ser puxado – uma atividade de espera (faz com que a
equipe mantenha um ritmo e priorize melhor o trabalho).

=> Lead Time: desde a chegada até entrega (conta tempo a partir da solicitação do
cliente).

=> Tempo de Ciclo: desde a seleção até a entrega (conta tempo a partir do
momento que você iniciou efetivamente o trabalho).

=> Sistema Puxado: define que a equipe deve terminar mais do que começar,
ou seja, realizar as tarefas que estão mais perto do lado direito do que do lado
esquerdo. Na ordem de prioridade de cima para baixo.

=> Outliers: pontos fora do padrão, acontecimentos atípicos.

=> SLA: Service Level Agreement: Acordo de Nível de Serviço.

=> Exemplos de Kanban:

O SCRUM: processo iterativo e incremental para o desenvolvimento de qualquer
produto e gerenciamento de qualquer projeto.

=> Características: não é metodologia / é um framework / é adaptável / promete alta

qualidade e produtividade / é atitude!

=> Pilares:

=> Transparência: tudo que afeta o resultado final deve ser visível para aqueles
que gerenciam os resultados.

=> Inspeção: o processo deve ser inspecionado com uma frequência suficiente
para identificar variações inaceitáveis. (Inspeções demais podem atrapalhar)

=> Adaptação: caso aspectos do processo ou produto estejam fora dos limites,
ajustes devem ser feitos o mais rápido possível.

=> Bases:

=> Times de Scrum (Papéis): Product Owner (PO), Scrum Master (SM) e Team
(Time).

=> Time-Boxes: as cerimônias devem ter um time-box de no máximo 4 horas

(no caso de planejamento de sprints de 4 semanas).

=> Artefatos: User Story, Task Board, Product Backlog, Sprint Backlog e
BurnDown Chart são utilizados ao longo de todo o ciclo do Scrum.
 => Regras: as regras como critérios de done, aceitação e regras de time são
estabelecidas e seguidas ao longo do ciclo Scrum (seja de 2 ou 4 semanas).

=> O fluxo: ciclos/sprints evolutivos (à medida que incrementos são executados, o conhecimento
sobre os requisitos evolui) / regulares de 2 ou 4 semanas

=> Explicação do fluxo:

1 => pré-game: preparação / sprints, premissas, infra necessária=> Temas /

Épicos / Product Backlog / Arquitetura / Planejamento da Release.

2 => pega-se o product backlog mais importante

3 => lança-o para ser trabalhado no sprint backlog (4 semanas)

4 => no sprint: reuniões diárias Stand Up Meeting ou Daily Scrum

5 => a entrega / o produto / o serviço=> testes de aceitação via sprint review=>

documentação

6 => pós-game: retrospectiva, base histórica...

=> Rotina do Fluxo:

=> Planejamento: quais stories são viáveis de serem movidas do product

backlog para o sprint backlog

=> Sprint: o team deve produzir as stories (o product owner pode estar presente nos
“daily scrums” se for realmente o desejo a obtenção de um status mais detalhado do projeto ).

=> Review: o time apresenta o trabalho que foi feito na Sprint e verifica a
satisfação do cliente e se o valor agregrado que foi atingido

=> Em detalhes:

=> no início de cada Sprint, faz-se um Sprint Planning Meeting 1 e 2

(reunião de planejamento) na qual o Product Owner prioriza os itens que estão no
 Product Backlog (Sprint Planning 1) e a equipe define e estima as tarefas que será
capaz de implementar.

=> As tarefas alocadas em um Sprint são incluídas no Sprint Backlog.

=> Diariamente, ao longo da Sprint, a equipe faz uma breve

reunião/cerimônia (normalmente de manhã), chamada Daily Scrum/Stand up
Meeting) para tornar visível o andamento das tarefas e identificar impedimentos
e priorizar o trabalho do dia que se inicia.

=> Ao final de um Sprint, a equipe apresenta o que foi produzido ao

Product Owner em uma cerimônia chamada de Sprint Review Meeting.

=> Finalmente, faz-se uma Sprint Retrospective, onde são discutidos os

pontos de melhoria e ações para a próxima Sprint (melhoria contínua). Em
seguida, a equipe parte para o planejamento do próximo Sprint. Assim reinicia-
se o ciclo.

=> Planejamento no Scrum:

=> Planejamento com quadros: vários exemplos:

=> Cerimônias de Planejamento:

=> Sprint Planning 1 ou Estimation Meeting: se olha o backlog e se forma o

Sprint backlog, preenchidos com os itens de maior prioridade. ProductOwner propõe
alterações. Define o objetivo da Sprint. Participantes: PO, Team, SM.

=> Sprint Planning 2: definir tarefas a partir das histórias selecionadas.

Participantes: Team + SM + PO (opcional).

=> Execução no Scrum:

=> Execuções demonstradas através de movimentação no task board:

=> Monitoramento no Scrum:

=> Acompanhamento via Burndown Chart:

=> Cerimônias de Monitoramento:

 => Daily Scrum ou Stand up meeting: usando o BurnDown Chart, para:
comunicar progresso (status diário) / identificar impedimentos / manter foco / noção de
time / comprometimento individual / participantes: Team +SM (opcional).

=> Encerramento no Scrum:

=> Cerimônias de encerramento:

=> Sprint Review: revisar último Sprint e andamento global do projeto /

participantes: Team, SM e PO.

=> Sprint Retrospective: melhoria Continua (rediscutir o processo de desenvolvimento)

/ participantes: Team, SM / Mini Avaliação 180.

=> Para ter sucesso no scrum: Times pequenos / Objetivos claros / Product Owner
conhecedores do negócio / Scrum Masters influentes na organização / Garantia da
disponibilidade dos recursos / Auto-gerenciamento fluente / Práticas de Engenharia de
Software presentes (Arquitetura, Gerência de Configuração, Verificação, Validação).

=> O KANBAN: proporciona uma visão ampla do que está sendo feito, em qual etapa,
o que está pronto, quanto está pronto e o quanto a equipe consegue entregar, lhe
concedendo previsibilidade.

=> Mitos e Verdades:

=> O KANBAN e SCRUM são opostos: MITO. O Scrum usa um quadro Kanban
com as opções To-Do , Doing e Done. Logo a utilização das duas abordagens já
acontece e pode ser maximizada com a utilização de outros conceitos do Kanban.
=> O KANBAN é vítima da Lei de Parkinson: o trabalho se expande... / É uma
preocupação válida, mas como estamos sempre medindo, o foco no controle é
mantido, evitando que o time seja improdutivo. 
=> Não existe o time box: não existe, mas deve ser utilizado sempre que o
fluxo for otimizado.
 => Não existe estimativa: não existe, mas deve ser utilizada sempre que
apropriado e fizer sentido.
=> O KANBAN substitui outras metodologias: ele é um complemento às outras
metodologias, pode ser utilizado com várias tecnologias e não substitui o Scrum.

=> Papéis e características: não existem papéis definidos (defina os seus papéis) /
respeite o processo atual, seus papéis, responsabilidades e cargos.

=> O Kanban e o conceito Kaizen: melhoria contínua / mude devagar e sempre.

=> O Fluxo: Focar no “todo” / gerar transparência / possibilitar a identificação de

desperdícios.

=> Passo 1: visualizar o fluxo de trabalho / ciclo de vida / mapear a cadeia de valor
(vide exemplo de Kanban em Notas e Conceitos).

=> Planejamento no Kanban:

=> Passo 2: limitar o WIP, determinar o lead time e o tempo de ciclo.

=> Passo 3: estabelecer a política de qualidade (as mesmas podem estar explícitas no
quadro do kanban).
=> PokaYoke (Pocáioquê): evitar que erros sejam realizados, incluindo por
exemplo, fluxos e regras automatizados.
=> Padrões e Check lists antes de completar as tarefas.
=> Analisar cada defeito (Stop the Line, conceito lean para prevenir).

=> Monitoração e Exceução no Kanban:

=> Passo 4: ajustar as cadências (diminuir/aumentar o Wip) - sequência, ritmo, sucessão

regular - ajustar o tempo todo.

=> Custos associados a entregas de um produto ou serviço / Custo de espera

(aprovação, planejamento, qualidade, verificação...) = prejudicam o feedback.

=> Passo 5: medir o fluxo através de:

=> Diagrama de Fluxo Cumulativo: mostra o tempo da chegada, a fila de feitio

e o tempo que você gastou pra entregar:
=> se a distância entre duas linhas em progresso aumentarem é um
sinal de gargalo;
=> se a linha de backlog estiver mais inclinada que a linha do “Done”
significa que está entrando mais coisas que podemos entregar;
=> pode-se medir tempo médio de ciclo e a quantidade de itens na fila.
 => Tempo de Ciclo: ao analisar o Tempo de Ciclo Individual: “os números
indicam consistência ?”, “como está a tendência?”, ”É possível analisar outliers ?”, “ A
data de entrega está aceitável (90% entregues em 1 semana)?”.

=> Índice de Defeitos: “Por que o número de novos defeitos tem aumentado?” e
“Como o índice alto de defeitos afetou o tempo do ciclo?”. É importante definir metas
para o Índice de Defeitos considerando os objetivos estratégicos e objetivos
estabelecidos ou não em contrato.

=> Itens Bloqueantes: devem ser observados ao longo do tempo. Podem ser
analisados outliers e a causa de médias maiores do que estabelecido na meta.
=> Passo 6: priorização / a maior prioridade deve ser o item com mais alto nível de
atraso ou mais complexo / o mais prioritário é o que está mais acima / ao priorizar,
considerar: maior risco e incerteza / necessidades básicas (infraestrutura) / tamanho
equilibrado / tipo de estória equilibrado / dependências.

=> Passo 7: identificação de classes de serviços:

=> Classe Padrão: defeitos Cosméticos e Estórias;

=> Classe Prioritária: defeitos Críticos e Estórias de Alta Prioridade;
=> Classe de Prazo Fixo: estórias com prioridade se o prazo estiver
próximo;
=> Classe Urgente: defeitos impeditivos que rompem limites do WIP.

=> Passo 8: gerenciamento do fluxo:

=> filtro de decisões Agile: Estamos obtendo progresso? / Estamos

encorajando a cultura baseada em confiança? Estamos tratando o WIP como risco e
não como um ativo?
=> filtro de Decisões Lean: O valor é mais importante que o fluxo / O fluxo é
mais importante que eliminação de desperdícios / Elimine desperdícios para melhorar
a eficiência.
=> alivie Gargalos / introduza buffers / planeje entregas / otimize o Fluxo.
=> Passo 9: estabeleça SLA: considera a base histórica / deixe visível.

=> Encerramento no Kanban:

=> Passo 10: melhoria contínua: mude / experimente / ajuste os Wips / ajuste o
quadro / aumente a visibilidade.

=> O SCRUMBAN: uso das abordagens Srcum e Kanban juntas. É possível perceber
que ao adotar o SCRUMBAN os progressos tornam-se ainda mais rápidos.

=> Vantagens: Qualidade / Inspeções / Análise de causas de problemas/defeitos /

Diminui o desperdício.

=> Planejamento no Scrumban: use os papéis do SCRUM / mudanças fazem parte

do escopo / sistema puxado / planeje pequenas iterações de planejamento (todos os
dias) / crie outros papéis / aumente o quadro, inclua raias de atividades e buffer / não
indique o nome das pessoas nos cartões / limite o Backlog (WIP) / use regras de
priorização.

=> Monitoração no Scrumban: ache os bloqueadores do fluxo analisando os WIPs /

use o Diagrama de Fluxo Cumulativo / utilize métricas de Tempo de Ciclo / repriorize
diariamente / faça reuniões do tipo Short Kaizen / Stop theline, follow-up, planning

=> Encerramento no Scrumban: use Restrospectiva (Scrum) / use Reviews, se

necessário / analise a causas dos defeitos ao longo do tempo.

=> Diferenças Básicas entre Scrum, Kanban e Scrumban:

1) O ciclo de vida: no SCRUM e no SCRUMBAN o ciclo de vida é evolutivo

incremental, no KANBAN não tem um ciclo de vida definido, é de acordo com o
processo estabelecido na empresa. No SCRUMBAN o quadro Kanban pode ser mais
do que só o TO DO, DOING e DONE refletindo mais o processo do projeto e/ou da
empresa.

2) Os artefatos e papéis: no SCRUM e SCRUMBAN temos papéis definidos

(Scrum Master, PO e Time) já no KANBAN os papéis são livres de acordo com a
organização. No SCRUMBAN é possível adotar também os papéis da empresa não se
limitando aos papéis do SCRUM.

3) As cerimônias: no SCRUM e SCRUMBAN as cerimônias são definidas como

a de Planejamento (-Sprint Planning 1 e 2), Monitoração (daily Meeting) , Reviews-
(Reuniões de aprovação com o cliente) e Retrospectivas - Reuniões de Lições
Aprendidas e melhorias de processo. No KANBAN as cerimônias não são obrigatórias,
mas podem ser usadas como no SCRUM, por exemplo, ou como as reuniões do
Kaizen (Stop the line). O SCRUMBAN usa todas as cerimônias do SCRUM.

4) Indicadores - no Scrum, existe o BDC (BurnDown Chart) e a produtividade

por estória. No KANBAN existem indicadores referente ao Diagrama de Fluxo
Cumulativo e Defeitos. O SCRUMBAN usa os indicadores de ambos os frameworks.

Unidade 3 (A Ferramenta Lean PB)

=> Conceitos Lean de Produção (Toyota): foco na produção enxuta guiados por 7
princípios:

=> 1- Eliminar Perda: qualquer atividade que não agrega diretamente valor ao
produto acabado é desperdício – eliminação de perdas reduz o tempo!

=> 2- Construir com Qualidade: o processo, não deve permitir que os defeitos
ocorram, mas quando isso não for possível, o trabalho para validar ao longo e corrigir
o erro deve ser o menor possível – deve-se realizar inspeções para não permitir a
entrada de erros (via checklists, critérios de done e automação).

=> 3- Criar Conhecimento: o aprendizado é essencial. O desenvolvimento iterativo

de um produto é a estratégia mais adequada para ajudar as equipes a descobrir o que
as partes interessadas realmente querem. Também é importante para uma equipe
refletir regularmente sobre o que eles estão fazendo e, em seguida, agir para melhorar
a sua abordagem (via retrospectivas/melhoria contínua, reuniões diárias, reviews/feedback contínuo ).
=> 4- Adiar o Compromisso: BEM VINDO ÀS MUDANÇAS - Esperar o máximo
possível para começar a produzir algo = ciclos curtos: pois precisar ter valor agregado
para o cliente.

=> 5- Entregar Rapidamente: é possível produzir um produto ou software com alta

qualidade e rapidamente. Ao limitar o trabalho de uma equipe à sua capacidade, que é
refletida pela velocidade da equipe. Uma organização eficaz não exige que as equipes
façam mais do que são capazes, mas pede-lhes que se auto-organizem e determinem
o que podem realizar. Para isso, é imprescindível focar nas entregas de valor.
(Metodologias ágeis ajudam com: uso do WIP e “Sistema Puxado” / gamification / auto-gerenciamento
SCRUM / indicadores de Velocidade)

=> 6- Respeitar Pessoas: a vantagem sustentável quando lidamos com pessoas é

obtida quando elas são comprometidas e cabeças pensantes. A estratégia de
governança deve ser enxuta e concentrada em mover e capacitar equipes e não em
controlá-las. (na metodologia ágil: cultura ágil / kaizen-melhoria contínua / retrospectiva / Management
3.0: gerenciamento de expectativas, visibilidade de limites, valorização e empoderamento das pessoas).

=> 7- Otimizar o Todo: se o objetivo é a eficácia de uma solução é imprescindível

olhar para o todo. É preciso entender os processos de negócios de alto nível e os
projetos individuais que os suportam. As medições devem abordar o quanto a sua
equipe está entregando o valor do negócio, porque essa é a única razão para um
projeto estratégico. (na metodologia ágil: mapeamento de toda a cadeia de valor e identificação de
gargalos e métricas associados ao valor do negócio que está sendo entregue, métricas aderentes aos
valores do negócio e ter o product owner).

=> A ferramenta Lean PB: pode ser utilizada para planejar o Kanban dos projetos
escolhendo um modelo de KANBAN ou criando o seu próprio. (não contempladas as
funcionalidades pois segundo Analia, não serão cobradas na prova ).

Unidade 4 (Conclusão e Encerramento)

=> Fatores de Sucesso em Metodologias Ágeis: Times pequenos / Objetivos claros

/ Product Owner conhecedores do negócio / Scrum Masters influentes na organização
/ Garantia da disponibilidade dos recursos / Auto-gerenciamento fluente / Práticas de
Engenharia de Software presentes (Arquitetura, Gerência de Configuração, Verificação,
Validação) ou Especialistas / Ambiente propício a falhas / Valores da empresa
permitirem a cultura ágil / Ferramentas e técnicas: Redmine, Jira, Trello, LeanB,
Management 3.0.

=> Principais diferenças entre metodologias Ágeis e Tradicionais: ocorre na

agilidade:

=> Envolvimento do PO (específico da agilidadade).

=> Múltiplas interações para conhecer e evoluir o produto (não ocorre nas
tradicionais).
=> Cliente comprometido em compartilhar decisões e riscos (não ocorre nas
tradicionais).
=> Planejamento inicial de Alto Nível: os maiores riscos e marcos são
conhecidos - restrições e premissas também são conhecidas – planejamento com
mais detalhes e feito ao longo das sprints/planejamento e replanejamento.
=> Reflexão de como realizar uma iteração e o perfil do time envolvido e alguns
fatores como: esforço, recursos e riscos.
=> O planejamento é revisado/refinado durante as reuniões diárias e ao final
das iterações
 => O comprometimento é obtido ao “pegar a tarefa” (time, durante o sprint) /
Estimativas: estórias são elaboradas ou estimadas e as iterações são realizadas por
meio de um conjunto de tarefas / Sprint Backlog é derivado de um Product Backlog (na
agilidade).
=> É crucial garantir que o PO e os usuários finais estejam envolvidos nas
atividades de desenvolvimento.
=> Planejar no início do projeto: como as avaliações objetivas serão realizadas
para garantir objetivos organizacionais.
=> De que forma o resultado das avaliações serão incorporados ao time ( parte
do daily meeting, checklists, peer reviews, tools, integração contínua, restrospectivas).

=> A estratégia de riscos está “embutida” na própria metodologia ágil: algumas

técnicas de mitigação de riscos podem ser adotadas, como: experimentação (early
failures) ou spike (fora da iteração).

=> Casos de Sucesso: uso do Kanban (sistema puxado, cadeia de valor)

=> NOTAS / DICAS DE PROVA: os itens que a professora considerou nos tópicos de
dicas de prova foram marcados em amarelo. CONSIDERAR TODAS AS
CERIMÔNIAS (EVENTOS/REUNIÕES) QUE OCORREM NAS 3 ABORDAGENS
ÁGEIS.