Agile Practice Guide - Agile Practice Guide - PMI-1
Agile Practice Guide - Agile Practice Guide - PMI-1
Agile Practice Guide - Agile Practice Guide - PMI-1
Este livro foi impresso utilizando uma tecnologia patenteada de anti-falsificação impressão visa
evitar reproduções não autorizadas. A cor do papel é cinza em vez de branco. Quando as
páginas do livro são copiadas ou digitalizadas uma mensagem oculta de aviso aparecerá em
segundo plano. Esse recurso de segurança destina-se a desencorajar ninguém de tentar
ilegalmente reproduzir ou falsificadas este livro.
Catalogação-em-publicação da Biblioteca do Congresso foi aplicado.
ISBN: 978-1-62825-199-9
Publicado Por:
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA
Phone: +1 610-356-4600
Fax: +1 610-356-4647
Email: [email protected]
Internet: www.PMI.org
©2017 Project Management Institute, Inc. Todos os direitos reservados.
Project Management Institute, Inc. O conteúdo é protegido por direitos autorais pela lei de
propriedade intelectual dos EUA que é reconhecida pela maioria dos países. Para republicar ou
reproduzir o conteúdo do PMI, você deve obter nossa permissão. Por favor, vá
http://www.pmi.org/permissions para mais detalhes.
Para colocar uma Ordem Comercial ou para obter informações sobre preços, entre em contato com
o Grupo de Editores Independentes:
Grupos de Editores Independentes
Departamento de Compra
1. INTRODUÇÃO
2. UMA INTRODUÇÃO DO ÁGIL
2.1 Trabalhos Definíveis vs Trabalho De Alta Incerteza
2.2 O Manifesto Ágil e Mentalidade
2.3 Método Lean e Kanban
2.4 Incerteza, Risco e Seleção do Ciclo de Vida
3. SELEÇÃO DO CICLO DE VIDA
3.1 Características dos Ciclos de Vida do Projeto
3.1.1 41/5000 Características dos Ciclos de Vida
Preditivos
3.1.2 Características dos Ciclos de Vida Iterativos
3.1.3 Características dos Ciclos de Vida Incrementais
3.1.4 Características dos Ciclos de Vida Ágeis
3.1.5 Filtros de Adequação Ágil
3.1.6 Características dos Ciclos de Vida Híbridos
3.1.7 Abordagens Cmbinadas Ágeis e Preditivas
3.1.8 Abordagem Predominantemente Preditiva com
Alguns Componentes Ágeis
3.1.9 A Abordagem Ágil em Grande Parte com Um
Componente Preditivo
3.1.10 Ciclos de Vida Híbridos como Feitos por um
Propósito
3.1.11 Ciclos de Vida Híbridos como Estratégia de
Transição
3.2 Misturando Abordagens Ágeis
3.3 Fatores de Projeto que Influenciam a Adaptação
4. IMPLEMENTANDO ÁGIL: CRIANDO UM AMBIENTE
AGILIZADO
4.1 Comece com Uma Mentalidade Ágil
4.2 A Liderança que Serve Capacita a Equipe
4.2.1 Responsabilidades do Líder que Serve
4.2.2 Papel do Gerente de Projeto em um Ambiente
Ágil
4.2.3 Os Gerentes de Projeto Usam a Liderança de
servir
4.3 Composição de Time
4.3.1 Times Ágeis
4.3.2 Papéis Ágeis
4.3.3 Especialistas em Generalização
4.3.4 Estruturas de Equipes
4.3.5 Membros da Equipe Dedicada
4.3.6 Espaços de Trabalho da Equipe
4.3.7 Superando Silos Organizacionais
5. IMPLEMENTANDO ÁGIL: ENTREGANDO EM UM
AMBIENTE AGILIZADO
5.1 Charter O Projeto e a Equipe
5.2 Common Práticas Ágeis
5.2.1 Retrospectivas
5.2.2 Preparação de Atrasos
5.2.3 Refinamento de Atrasos
5.2.4 Levantamentos Diários
5.2.5 Demonstrações/Revisões
5.2.6 Planejando o Ágil Baseado em Iteração
5.2.7 Práticas de Execução que Ajudam as Equipes a
Oferecer Valor
5.2.8 Como as Iterações e Aumentos Ajudam a
Fornecer Produto de Trabalho
5.3 Solução de Problemas de Desafios de Projetos Ágeis
5.4 Medições em Projetos Ágeis
5.4.1 Medir Resultados de Equipes Ágeis
6. CONSIDERAÇÕES ORGANIZACIONAIS PARA A
AGILIDADE DO PROJETO
6.1 32/5000 Gestão de Mudanças Organizacionais
6.1.1 Condutores Para Mudança de Gestão
6.1.2 Prontidão Para A Mudança
6.2 Cultura Organizacional
6.2.1 33/5000 Criando Um Ambiente De Segurança
6.2.2 Avaliando Cultura
6.3 Aquisição e Contratos
6.4 Práticas De Negócios
6.5 Coordenação e Dependências De Equipes Múltiplas
(Escala)
6.5.1 Estruturas
6.5.2 Considerações
6.6 Práticas Ágeis e o Escritório de Gerenciamento de
Projetos (PMO)
6.6.1 Uma PMO Ágil é Orientado Para O Valor
6.6.2 An Uma PMO Ágil é Orientado Para
Convidados
6.6.3 Uma APMO Ágil é Multidisciplinar
6.7 Estrutura Organizacional
6.8 Desenvolvendo a Organização
7. UM CHAMADO PARA A AÇÃO
ANNEX A1
MAPA DO GUIA PMBOK®
ANNEX A2
MANIFESTO - MAPA ÁGUIL
ANNEX A3
PANORÂMA DOS QUADROS ÁGEIS E LEAN
APPENDIX X1
COLABORADORES E REVISORES
APPENDIX X2
ATRIBUTOS QUE INFLUENCIAM IMPLANTAÇÃO
APPENDIX X3
FERRAMENTAS DE FILTRO DE ADEQUAÇÃO ÁGEIS
REFERENCIA
BIBLIOGRAFIA
GLOSSARIO
LISTA DE TABELAS E FIGURAS
Figure X3-
Avaliação de entrega incremental
10.
Figure X3-
Classificação de adequação Gráfico de Radar
11.
Figure X3-
Projeto Drogaria
12.
Figure X3-
13. Exemplo de mensagens militares
INTRODUÇÃO
Bem-vindo ao Guia De Práticas Ágeis! Este guia foi desenvolvido
como um esforço colaborativo pelo Project Management Institute (PMI) e
Agile Alliance®. Os membros da equipe principal de redação que
desenvolveram este guia de prática incluíam voluntários de ambas as
organizações, aproveitando a experiência em matéria de assuntos de uma
ampla gama de praticantes atuais e líderes de uma variedade diversificada
de origens, crenças e culturas. developed this practice guide included
volunteers from both organizations, drawing on subject matter expertise
from a broad range of current practitioners and leaders from a diverse
range of backgrounds, beliefs, and cultures.
Este guia de prática fornece orientação prática orientada para líderes de
projetos e membros da equipe adaptando-se a uma abordagem ágil no
planejamento e execução de projetos. Enquanto a nossa equipe principal
de redação reconhece que há um suporte firme para usar abordagens
preditivas e, ao contrário, a paixão em torno de mudar para uma
mentalidade ágil, valores e princípios, esse guia de prática abrange uma
abordagem prática da agilidade do projeto. Este guia de prática representa
uma ponte para entender o caminho de uma abordagem preditiva para uma
abordagem ágil. Na verdade, existem atividades semelhantes entre elas,
como o planejamento, que são tratadas de forma diferente, mas ocorrem
em ambos os ambientes.
Nossa equipe principal de redação usou uma mentalidade ágil para
colaborar e gerenciar o desenvolvimento desta primeira edição do guia de
prática. À medida que a tecnologia e a cultura mudam, futuras atualizações
e aprimoramentos para o guia de prática refletirão abordagens atuais.
Nossa equipe principal adotou um estilo de escrita mais informal e
relaxado para este guia de prática do que o típico para padrões PMI. O
guia incorpora novos elementos, como dicas, barras laterais e estudos de
caso para melhor ilustrar pontos e conceitos fundamentais. Nossa equipe
pretende que essas mudanças tornem este guia de prática mais legível e
fácil de usar.
Este guia de prática vai além de abordar o uso do ágil no setor de
desenvolvimento de software de computador, porque o ágil se expandiu
para ambientes de desenvolvimento não-software. Fabricação, educação,
saúde e outras indústrias estão se tornando ágiles em graus variados e esse
uso além do software está dentro do escopo deste guia de prática.
Então, por que um Guia De Práticas Ágeis e por que agora? As equipes
do projeto usaram técnicas e abordagens ágeis em várias formas por pelo
menos várias décadas. O Manifesto Ágil[1]1 expressou valores definitivos
e princípios de ágil à medida que o uso de agilidade ganhou impulso
substancial (see Section 2.1). Hoje, os líderes e equipes de projetos se
encontram em um ambiente interrompido por avanços exponenciais em
tecnologia e demandas dos clientes para uma entrega de valor mais
imediata. Técnicas e abordagens ágeis efetivamente gerenciam tecnologias
disruptivas. Além disso, o primeiro princípio de ágil coloca a satisfação do
cliente como a mais alta prioridade e é fundamental na entrega de produtos
e serviços que deliciam os clientes (see Section 2.1). Os links de feedback
rápidos e transparentes dos clientes estão prontamente disponíveis com o
uso generalizado das mídias sociais. Portanto, para permanecer
competitivo e relevante, as organizações não podem mais estar focadas
internamente, mas precisam se concentrar externamente na experiência do
cliente.
As tecnologias disruptivas estão mudando rapidamente o campo de
jogo, diminuindo as barreiras à entrada. As organizações mais maduras
estão cada vez mais propensas a ser altamente complexas e potencialmente
lentas para inovar e ficam atrasadas na entrega de novas soluções aos seus
clientes. Essas organizações se encontram competindo com organizações e
startups menores que são capazes de produzir rapidamente produtos que
atendam às necessidades do cliente. Essa velocidade de mudança
continuará a conduzir as grandes organizações a adotar uma mentalidade
ágil para se manterem competitivas e manter sua participação de mercado
existente.
1 TOs números entre parênteses referem-se à lista de referências no final deste guia prático.
2
CASO
TIP
Nenhum ciclo de vida pode ser perfeito para todos os projetos. Em vez
disso, cada projeto encontra um ponto no continuum que fornece um
equilíbrio ótimo das características para seu contexto. Especificamente,
MISTURANDO ABORDAGENS
Como um exemplo de adaptação de estruturas ágeis, uma das
misturas mais comuns em uso generalizado envolve um uso coordenado
da estrutura Scrum, o Método Kanban e elementos do método de
Programação eXtreme (XP). O Scrum fornece orientação sobre o uso de
um backlog de produtos, um proprietário de produto, um mestre de
scrum e uma equipe de desenvolvimento multifuncional, incluindo
planejamento de sprint, avaliações diárias de scrum, sprint e sessões
retrospectivas de sprint. Um painel kanban ajuda o time a melhorar
ainda mais a sua eficácia, visualizando o fluxo de trabalho, tornando
visíveis os impedimentos e permitindo que o fluxo seja gerenciado
ajustando os limites do trabalho no processo. Além disso, as práticas de
engenharia inspiradas no XP, como o uso de cartões de histórias,
integração contínua, refatoração, testes automatizados e
desenvolvimento orientado por testes, aumentam ainda mais a eficácia
da equipe ágil. Em resumo, a combinação de práticas dessas várias
fontes produz um resultado sinérgico de desempenho superior ao de
cada componente individual isoladamente.
3.3 FATORES DE PROJETO QUE INFLUCIAM
NA ADEQUAÇÃO
Às vezes, os atributos do projeto requerem uma abordagem para um
melhor ajuste. Table 3-2 identifica alguns fatores do projeto e opções de
customização para considerar.
Table 3-2. Adaptando Opções para Melhorar o Ajuste
IMPLEMENTANDO AGILE:
CRIANDO UM AMBIENTE
AGILIZADO
4.1 INICIAR COM UM AGIL MINDSET
Gerenciar um projeto usando uma abordagem ágil exige que a equipe do
projeto adote uma mentalidade ágil. As respostas às seguintes questões
ajudarão a desenvolver uma estratégia de implementação:
DICA
DICA
Atributo Objetivo
Maior foco e produtividade
Pessoas dedicadas
Equipe pequena, menos de dez pessoas
Melhor comunicação
Colocação ou capacidade Melhora na dinâmica da equipe
de gerenciar qualquer Compartilhamento de conhecimento
desafio de localização Custo reduzido de aprendizagem
Capaz de comprometer-se a trabalhar um com o outro
Função Descrição
As equipes multifuncionais consistem em membros da equipe
com todas as habilidades necessárias para produzir um produto
funcionando. No desenvolvimento de software, as equipes
multifuncionais são tipicamente composta por designers,
desenvolvedores, testadores e quaisquer outras funções
Membro da equipe
necessárias. As equipes de desenvolvimento multifuncional
multifuncional
consistem em profissionais que oferecem produtos
potencialmente liberáveis em uma cadência regular. As equipes
multifuncionais são críticas porque podem entregar o trabalho
terminado no menor tempo possível, com maior qualidade, sem
dependências externas.
CASO
DICA
CASE
DICA
Nem todas as equipes têm todos os papéis que eles precisam. Por
exemplo, algumas equipes precisam de suporte de administradores de
banco de dados ou analistas de pesquisa. Quando uma equipe
temporariamente atribuiu especialistas, é importante garantir que
todos tenham o mesmo conjunto de expectativas. Esse especialista é
100% alocado para a equipe e por quanto tempo? Configure
expectativas com todos (o especialista e a equipe) para esclarecer o
nível de compromisso para que a equipe possa entregar. As
atribuições a tempo parcial criam riscos para o projeto.
DICA
IMPLEMENTANDO O ÁGIL:
ENTREGANDO EM UM AMBIENTE
AGILIZADO
5.1 CARTA, O PROJETO E A EQUIPE
Todo projeto precisa de uma carta de projeto para que a equipe do
projeto saiba por que este projeto importa, onde o time está indo e qual é o
objetivo do projeto. No entanto, a própria carta do projeto pode não ser
suficiente para a equipe. As equipes ágeis requerem normas da equipe e
uma compreensão de como trabalhar em conjunto. Nesse caso, a equipe
pode precisar de uma carta de equipe.
TO processo de fretamento ajuda a equipe a aprender a trabalhar em
conjunto e a coaltar em torno do projeto.
No mínimo, para um projeto ágil, a equipe precisa da visão ou
finalidade do projeto e de um conjunto claro de acordos de trabalho. Uma
carta de projeto ágil responde a estas perguntas:
Por que estamos fazendo esse projeto? Esta é a visão do projeto.
Quem se beneficia e como? Isso pode fazer parte da visão do
projeto e / ou propósito do projeto.
O que significa para o projeto? Estes são os critérios de
lançamento do projeto.
Como vamos trabalhar juntos? Isso explica o fluxo pretendido
de trabalho.
Um líder servIdor pode facilitar o processo de fretamento. Uma equipe
pode se unir ao trabalhar em conjunto, e a carta do projeto é uma ótima
maneira de começar a trabalhar. Além disso, os membros da equipe podem
querer colaborar para entender como eles vão trabalhar juntos.
As equipes não precisam de um processo formal de fretamento, desde
que as equipes compreendam como trabalhar em conjunto. Algumas
equipes se beneficiam de um processo de fretamento da equipe. Aqui estão
algumas idéias de fretamento para que os membros da equipe usem como
base para seu contrato social:
Valores da equipe, como ritmo sustentável e horas centrais;
Contratos de trabalho, como o que "pronto" significa para que a
equipe possa trabalhar; o que "feito" significa que o time pode
julgar a integridade de forma consistente; respeitando a caixa de
tempo; ou o uso de limites de trabalho em processo;
Regras básicas, como uma pessoa que fala em uma reunião; e
Normas de grupo, como a forma como a equipe trata os horários
das reuniões.
O líder servidor junto com a equipe pode decidir abordar outros
comportamentos.
Lembre-se de que o contrato social da equipe - sua carta de equipe - é
como os membros da equipe interagem uns com os outros. O objetivo da
carta da equipe é criar um ambiente ágil em que os membros da equipe
possam trabalhar ao máximo de suas habilidades como equipe.
5.2.1 RETROSPECTIVAS
A prática mais importante é a retrospectiva porque permite que a equipe
aprenda, melhore e adapte seu processo.
Retrospectivas ajudam a equipe a aprender com o trabalho anterior
sobre o produto e seu processo. Um dos princípios por trás do Manifesto
Ágil é: "Em intervalos regulares, a equipe reflete sobre como se tornar
mais efetiva, depois melhora e ajusta seu comportamento de acordo".
Muitas equipes usam iterações - especialmente iterações de 2 semanas -
porque a iteração mostra uma demonstração e uma retrospectiva no final.
No entanto, a equipe não precisa de iterações para retrospectiva. Os
membros da equipe podem decidir retrospectiva nestes momentos-chave:
Quando a equipe completa um lançamento ou envia algo. Não
precisa ser um incremento monumental. Pode ser qualquer
versão, não importa quão pequena.
Quando passaram mais de algumas semanas desde a
retrospectiva anterior.
WQuando a equipe parece estar presa e completa, o trabalho não
está fluindo pelo time.
Quando o time atinge qualquer outro marco.
As equipes se beneficiam da alocação de tempo suficiente para
aprender, seja a partir de uma retrospectiva interina ou uma retrospectiva
final do projeto. As equipes precisam aprender sobre seu produto de
trabalho e processo de trabalho. Por exemplo, algumas equipes têm
problemas para terminar o trabalho. Quando as equipes planejam tempo
suficiente, elas podem estruturar sua retrospectiva para coletar dados,
processar esses dados e decidir o que tentar mais tarde como um
experimento.
Em primeiro lugar, uma retrospectiva não é culpa; A retrospectiva é um
momento para a equipe aprender com o trabalho anterior e fazer pequenas
melhorias.
A retrospectiva é analisar os dados qualitativos (sentimentos das
pessoas) e quantitativos (medições), depois usar esses dados para encontrar
as raízes, projetar contramedidas e desenvolver planos de ação. A equipe
do projeto pode acabar com muitos itens de ação para remover
impedimentos.
Considere limitar o número de itens de ação à capacidade da equipe para
corrigir a melhoria na próxima iteração ou período de trabalho. Tentando
melhorar muitas coisas de uma só vez e não terminar nenhuma delas é
muito pior do que planejar para completar menos itens e completá-los com
êxito. Então, quando o tempo o permitir, a equipe pode trabalhar na
próxima oportunidade de melhoria na lista. Quando o time seleciona as
melhorias, decide como medir os resultados. Então, no próximo período de
tempo, mire os resultados para validar o sucesso ou o fracasso de cada
melhoria.
Um facilitador da equipe leva-os através de uma atividade a classificar a
importância de cada item de melhoria. Uma vez que os itens de melhoria
são classificados pela equipe, a equipe escolhe o número apropriado para
trabalhar na próxima iteração (ou adiciona trabalho ao fluxo se for baseado
em fluxo).
DICA
DICA
DICA
DICA
DICA
CONSIDERAÇÕES
ORGANIZACIONAIS PARA A
AGILIDADE DO PROJETO
DICA
6.5.1 QUADROS
A orientação dos métodos ágeis mais difundidos, como Scrum e
eXtreme Programming, concentra-se nas atividades de uma equipe única,
pequena, geralmente colocada e multifuncional. Embora isso seja muito
útil para os esforços que exigem uma equipe única, pode fornecer
orientação insuficiente para iniciativas que exigem a colaboração de várias
equipes ágeis em um programa ou portfólio.
Uma variedade de estruturas (como Escala Quadros Ágeis, Scrum em
Grande Escala e Ágil Disciplinado) e abordagens (por exemplo, Scrum de
Scrums) surgiram para atender apenas a tais circunstâncias. Mais detalhes
sobre isso podem ser encontrados em Annex A3.
6.5.2 CONSIDERAÇÕES
Há mais de uma maneira de escalar o trabalho. A equipe pode precisar
escalar o trabalho de vários projetos ágeis em um único programa ágil.
Alternativamente, a organização pode projetar uma estrutura que suporte
abordagens ágeis em todo o portfólio.
Por exemplo, é útil começar pequeno e aprender o mais rápido possível
o que funciona bem no contexto organizacional. As equipes podem
alcançar resultados bem-sucedidos, mesmo quando tudo não é
completamente transformado em uma abordagem ágil.
Independentemente da abordagem, um fator crítico de sucesso é a
equipe ágil e saudável. Se o uso de uma abordagem ágil para uma única
equipe não for bem-sucedido, não tente aumentar o uso de forma mais
ampla; em vez disso, abordar os impedimentos organizacionais que
impedem as equipes de trabalhar de forma ágil.
O objetivo dos projetos ágeis de larga escala é coordenar os esforços de
diferentes equipes para agregar valor aos clientes. Há mais de uma maneira
de fazer isso. As equipes podem usar uma estrutura formal ou aplicar o
pensamento ágil para ajustar as práticas existentes de gerenciamento de
programas.
Tabela A2-2. Guia de práticas ágeis Mapeamento de princípios por trás do manifesto ágil
A3.2 SCRUM
O Scrum é uma estrutura de processo de equipe única usada para
gerenciar o desenvolvimento de produtos. A estrutura consiste em funções,
eventos, artefatos e regras do Scrum e usa uma abordagem iterativa para
entregar o produto em funcionamento. O Scrum é executado em timeboxes
de 1 mês ou menos com durações consistentes chamadas sprints, nas quais
um incremento de produto potencialmente liberável é produzido. Table
A3-1 lista eventos e artefatos do Scrum utilizados para execução de
projetos.
A equipe do Scrum consiste em um proprietário de produto, equipe de
desenvolvimento e mestre de scrum.
O product owner é responsável por maximizar o valor do
produto.
A equipe de desenvolvimento é uma equipe multifuncional e
auto-organizada composta de membros da equipe que têm tudo
o que precisam dentro da equipe para entregar o produto em
funcionamento sem depender de outras pessoas fora da equipe.
O scrum master é responsável por garantir que o processo
Scrum seja mantido e trabalha para garantir que a equipe do
Scrum siga as práticas e regras, bem como treina a equipe na
remoção de impedimentos.
Table A3-1. Scrum Events and Artifacts
Eventos Artefatos
Sprint Backlog do Produto
Planejamento de Sprint Backlog da Sprint
Scrum diário Incrementos
Review do Sprint
retrospectiva do Sprint
Área de Prática do
Primário Secondário
XP
Organizacional • Sente junto • Envolvimento real do cliente
• Equipe inteira • Continuidade da equipe
• Espaço de trabalho
informativo • Ritmo sustentável
• Código compartilhado /
Técnico • Programação par
propriedade coletiva
• Programa de teste
• Documentação de código e testes
inicial
• Design Incremental • Refatoração
Planejamento • Histórias de usuários • Análise de causa raiz
• Ciclo semanal • Equipes encolhendo
• Ciclo trimestral • Pagar por uso
• Folga • Contrato de escopo negociado
• Standups Diariamente/td>
• 10 minutos de
Integração • Base de código único
compilação
• Integração contínua • Iimplantação incremental
• Teste primeiro • Implantação diária
A3.6 SCRUMBAN
O Scrumban é uma abordagem ágil originalmente projetada como uma
forma de transição do Scrum para o Kanban. À medida que novas
estruturas e metodologias ágeis surgiram, ela se tornou uma estrutura
híbrida em evolução em si mesma, onde as equipes usam o Scrum como
uma estrutura e o Kanban para melhoria de processos.
No Scrumban, o trabalho é organizado em pequenos “sprints” e
aproveita o uso de quadros kanban para visualizar e monitorar o trabalho.
As histórias são colocadas no quadro Kanban e a equipe gerencia seu
trabalho usando limites de trabalho em andamento. Reuniões diárias são
realizadas para manter a colaboração entre a equipe e remover
impedimentos. Um acionador de planejamento é definido para que a
equipe saiba quando planejar em seguida, normalmente quando o nível de
trabalho em andamento é menor do que um limite predeterminado. Não há
papéis pré-definidos no Scrumban - a equipe mantém seus papéis atuais.
X2.1 INTRODUÇÃO
Este apêndice fornece orientação de alto nível sobre quando e como
adaptar abordagens ágeis. Ele pode ser usado para determinar
circunstâncias que possam justificar a mudança ou a introdução de novas
técnicas e, em seguida, oferece algumas recomendações a serem
consideradas..
Uma resposta comum quando se luta para adotar uma prática ágil é
considerar se deve ser feito ou não. Uma declaração como “Retrospectivas
foram impopulares, então decidimos soltá-las” ilustra essa questão e indica
um problema mais fundamental na equipe que provavelmente não será
abordado pela adaptação do método. A situação será agravada pela
omissão da atividade retrospectiva que visa melhorar o processo.
Finalmente, a adaptação deve ser realizada em colaboração com os
colegas de equipe ou quem quer que a mudança possa impactar. As
pessoas precisam estar engajadas no processo de pensamento e tomada de
decisão sobre a mudança de processos para que elas se comprometam e
aceitem as mudanças, a fim de obter uma transição bem-sucedida. Omitir
pessoas de adaptar um processo provavelmente resultará em resistência e
ressentimento com a mudança, mesmo que faça sentido tecnicamente.
Muitas vezes, treinadores ou líderes experientes podem ajudar a envolver
as pessoas de forma eficaz.
X3.1 INTRODUÇÃO
A literatura ágil contém muitas ferramentas de filtro de adequação ágil
para ajudar a avaliar sob quais circunstâncias uma abordagem ágil é
apropriada para uso. Em 1994, o Método de Desenvolvimento de Sistemas
Dinâmicos (DSDM) desenvolveu um Questionário de Adequação de
Projetos Ágeis e um Questionário de Adequação Organizacional para
ajudar a avaliar possíveis áreas de problemas de ajuste e potenciais.
A família de abordagens Crystal também empregou critérios de
adequação, classificando os projetos por tamanho de equipe e a criticidade
do produto ou serviço que está sendo desenvolvido. Crystal recomenda
que projetos menores e menos críticos sejam realizados com controles
mais leves e abordagens mais simples. Recomenda-se que projetos críticos
de grande porte, missão ou vida usem mais rigor e validação.
Desde o desenvolvimento dessas abordagens, muitos modelos foram
criados para ajudar a determinar onde e quando empregar abordagens
ágeis. Boehm e Turner adotaram alguns dos elementos do DSDM e do
Crystal para desenvolver um modelo de avaliação popular para ajudar a
determinar se os projetos devem ser realizados com abordagens ágeis ou
mais tradicionais..
Com base nesses modelos anteriores e ampliado para considerar o meio
termo das abordagens híbridas, o modelo a seguir é proposto. Ele
representa uma síntese de vários atributos de filtro de adequação para
ajudar as organizações a avaliar e discutir se os projetos devem ser
realizados usando abordagens preditivas, híbridas ou ágeis..
X3.6 RESUMO
Agile suitability filters are useful tools for identifying potential fits and
gaps for agile approaches. They should not be used as definitive inclusion
or exclusion gates, but instead as topics for objective discussion with all
interested parties.
REFERENCES
[1] Manifesto for Agile Software Development. (2001). Retrieved from
http://agilemanifesto.org/
[2] Project Management Institute. 2013. Managing Change in
Organizations: A Practice Guide. Newtown Square, PA: Author.
[3] Project Management Institute. 2017. A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) – Sixth Edition.
Newtown Square, PA: Author.
[4] Project Management Institute. 2013. Software Extension to the
PMBOK® Guide Fifth Edition. Newtown Square, PA: Author.
BIBLIOGRAPHY
The following are suggested additional reading materials, subdivided by
section and/or topic: SECTION 2—AN INTRODUCTION TO AGILE
Briggs, Sara. “Agile Based Learning: What Is It and How Can It
Change Education?” Opencolleges.edu.au February 22, 2014,
retrieved from
http://www.opencolleges.edu.au/informed/features/agile-based-
learning-what-is-it-and-how-can-it-change-education/.
Manifesto for Agile Software Development, 2001,
http://agilemanifesto.org/.
Peha, Steve. “Agile Schools: How Technology Saves Education
(Just Not the Way We Thought it Would).” InfoQ. June 28, 2011,
retrieved from https://www.infoq.com/articles/agile-schools-
education.
Principles behind the Agile Manifesto, 2001,
http://agilemanifesto.org/principles.html.
Rothman, Johanna. 2007. Manage It! Your Guide to Modern,
Pragmatic Project Management. Raleigh: Pragmatic Bookshelf.
Sidky, Ahmed (Keynote). 2015.
https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz.
Stacey Complexity Model. 2016. http://www.scrum-
tips.com/2016/02/17/stacey-complexity-model/.
SCALING:
Disciplined Agile 2.X—A Process Decision Framework. 2016.
http://www.disciplinedagiledelivery.com/.
Kniberg, Henrik. “Scaling Agile @ Spotify with Tribes, Squads,
Chapters & Guilds,” Crisp, November 14, 2012,
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-
spotify.
“Overview—Large Scale Scrum,” LeSS. 2016. http://less.works/.
“SAFe® for Lean Software and System Engineering,” SAFe®.
2016. http://www.scaledagileframework.com/.
SKILLS:
Beck, Kent. Paint Drip People, August 4, 2016,
https://www.facebook.com/notes/kent-beck/paint-drip-
people/1226700000696195/.
“Generalizing Specialists: Improving Your IT Career Skills,” Agile
Modeling, (n.d.),
http://www.agilemodeling.com/essays/generalizingSpecialists.htm.
Hunter, Brittany. “Of Software Designers & Broken Combs,”
Atomic Object, June 27, 2013,
https://spin.atomicobject.com/2013/06/27/broken-comb-people/.
BACKLOG:
Adzic, Gojko, Marjory Bissett, and Tom Poppendieck. 2012. Impact
Mapping: Making a Big Impact with Software Products and
Projects. Woking, Surrey: Provoking Thoughts.
Patton, Jeff, and Peter Economy. 2014. User Story Mapping:
Discover the Whole Story, Build the Right Product. Sebastopol:
O'Reilly Media.
Rothman, Johanna. “We Need Planning; Do We Need Estimation?”
Rothman Consulting Group, Inc., January 21, 2015,
http://www.jrothman.com/mpd/project-management/2015/01/we-
need-planning-do-we-need-estimation/.
STANDUPS:
Brodzinski, Pawel. “Effective Standups around Kanban Board,”
Brodzinski.com, December 30, 2011,
http://brodzinski.com/2011/12/effective-standups.html.
Fowler, Martin. “It's Not Just Standing Up: Patterns for Daily
Standup Meetings,” Martinfowler.com, February 21, 2016,
http://martinfowler.com/articles/itsNotJustStandingUp.html.
Hefley, Chris. “How to Run Effective Standups and Retrospectives,”
Leankit, September 15, 2014, https://leankit.com/blog/2014/09/run-
effective-standups-retrospectives/.
EARNED VALUE:
Griffiths, Mike. “A Better S Curve and Simplified EVM,” Leading
Answers, June 6, 2008,
http://leadinganswers.typepad.com/leading_answers/2008/06/a-
better-s-curve-and-simplified-evm.html.
SECTION 6—ORGANIZATIONAL
CONSIDERATIONS FOR AGILE PROJECTS
Bankston, Arlen, and Sanjiv Augustine. Agile Team Performance
Management: Realizing the Human Potential of Teams, June 14,
2010, www.lithespeed.com/transfer/Agile-Performance-
Management.pptx.
Browder, Justin, and Brian Schoeff. Perfect Strangers: How Project
Managers and Developers Relate and Succeed. CreateSpace
Independent Publishing Platform, 2016,
https://www.createspace.com/.
Griffiths, Mike. “Agile Talent Management,” Leading Answers,
October 14, 2015,
http://leadinganswers.typepad.com/leading_answers/2015/10/agile-
talent-management.html.
Kohn, Alfie. 1999. Punished by Rewards: The Trouble with Gold
Stars, Incentive Plans, A's, Praise, and Other Bribes. New York:
Mariner Books.
Mar, Kane. “How to do Agile Performance Reviews,” Scrumology,
(n.d.), https://scrumology.com/how-to-do-agile-performance-
reviews/.
McChrystal, Stanley, Tantum Collins, David Silverman, and Chris
Fussell. 2015. Team of Teams: New Rules of Engagement for a
Complex World. New York: Portfolio, Penguin Random House.
Pink, Daniel. 2011. Drive: The Surprising Truth About What
Motivates Us. New York: Riverhead Books.
1. ACRONYMS
ATDD acceptance test-driven development
BDD behavior-driven development
BRD business requirement documents
DA Disciplined Agile
DoD definition of done
DoR definition of ready
DSDM Dynamic Systems Development Method
Evo evolutionary value delivery
LeSS Large-Scale Scrum
LSD Lean Software Development
PDCA Plan-Do-Check-Act
PMO project management office
ROI return on investment
RUP rational unified process
SAFe® Scaled Agile Framework®
SBE specification by example
XP eXtreme Programming
2. DEFINITIONS
A3. A way of thinking and a systematic problem-solving process that
collects the pertinent information on a single A3-size sheet of paper.
Acceptance Test-Driven Development (ATDD). A method of
collaboratively creating acceptance test criteria that are used to create
acceptance tests before delivery begins.
Agile. A term used to describe a mindset of values and principles as set
forth in the Agile Manifesto.
Agile Coach. An individual with knowledge and experience in agile who
can train, mentor, and guide organizations and teams through their
transformation.
Agile Life Cycle. An approach that is both iterative and incremental to
refine work items and deliver frequently.
Agile Manifesto. The original and official definition of agile values and
principles.
Agile Mindset. A way of thinking and behaving underpinned by the four
values and twelve principles of the Agile Manifesto.
Agile Practitioner. A person embracing the agile mindset who
collaborates with like-minded colleagues in cross-functional teams. Also
referred to as agilist.
Agile Principles. The twelve principles of agile project delivery as
embodied in the Agile Manifesto.
Agile Unified Process. A simplistic and understandable approach to
developing business application software using agile techniques and
concepts. It is a simplified version of the Rational Unified Process (RUP).
Agilist. See Agile Practitioner.
Anti-Pattern. A known, flawed pattern of work that is not advisable.
Automated Code Quality Analysis. The scripted testing of code base for
bugs and vulnerabilities.
Backlog. See Product Backlog.
Backlog Refinement. The progressive elaboration of project requirements
and/or the ongoing activity in which the team collaboratively reviews,
updates, and writes requirements to satisfy the need of the customer
request.
Behavior-Driven Development (BDD). A system design and validation
practice that uses test-first principles and English-like scripts.
Blended Agile. Two or more agile frameworks, methods, elements, or
practices used together such as Scrum practiced in combination with XP
and Kanban Method.
Blocker. See Impediment.
Broken Comb. Refers to a person with various depths of specialization in
multiple skills required by the team. Also known as Paint Drip. See also T-
shaped and I-shaped.
Burndown Chart. A graphical representation of the work remaining
versus the time left in a timebox.
Burnup Chart. A graphical representation of the work completed toward
the release of a product.
Business Requirement Documents (BRD). Listing of all requirements
for a specific project.
Cadence. A rhythm of execution. See also Timebox.
Collective Code Ownership. A project acceleration and collaboration
technique whereby any team member is authorized to modify any project
work product or deliverable, thus emphasizing team-wide ownership and
accountability.
Continuous Delivery. The practice of delivering feature increments
immediately to customers, often through the use of small batches of work
and automation technology.
Continuous Integration. A practice in which each team member's work
products are frequently integrated and validated with one another.
Cross-Functional Team. A team that includes practitioners with all the
skills necessary to deliver valuable product increments.
Crystal Family of Methodologies. A collection of lightweight agile
software development methods focused on adaptability to a particular
circumstance.
Daily Scrum. A brief, daily collaboration meeting in which the team
reviews progress from the previous day, declares intentions for the current
day, and highlights any obstacles encountered or anticipated. Also known
as daily standup.
Definition of Done (DoD). A team's checklist of all the criteria required to
be met so that a deliverable can be considered ready for customer use.
Definition of Ready (DoR). A team's checklist for a user-centric
requirement that has all the information the team needs to be able to begin
working on it.
DevOps. A collection of practices for creating a smooth flow of delivery
by improving collaboration between development and operations staff.
Disciplined Agile (DA). A process decision framework that enables
simplified process decisions around incremental and iterative solution
delivery.
Double Loop Learning. A process that challenges underlying values and
assumptions in order to better elaborate root causes and devise improved
countermeasures rather than focusing only on symptoms.
Dynamic Systems Development Method (DSDM). An agile project
delivery framework.
Evolutionary Value Delivery (EVO). Openly credited as the first agile
method that contains a specific component no other methods have: the
focus on delivering multiple measurable value requirements to
stakeholders.
eXtreme Programming. An agile software development method that
leads to higher quality software, a greater responsiveness to changing
customer requirements, and more frequent releases in shorter cycles.
Feature-Driven Development. A lightweight agile software development
method driven from the perspective of features valued by clients.
Fit for Purpose. A product that is suitable for its intended purpose.
Fit for Use. A product that is usable in its current form to achieve its
intended purpose.
Flow Master. The coach for a team and service request manager working
in a continuous flow or Kanban context. Equivalent to Scrum Master.
Framework. A basic system or structure of ideas or facts that support an
approach.
Functional Requirement. A specific behavior that a product or service
should perform.
Functional Specification. A specific function that a system or application
is required to perform. Typically represented in a functional specifications
document.
Hoshin Kanri. A strategy or policy deployment method.
Hybrid Approach. A combination of two or more agile and non-agile
elements, having a non-agile end result.
IDEAL. An organizational improvement model that is named for the five
phases it describes: initiating, diagnosing, establishing, acting, and
learning.
Impact Mapping. A strategic planning technique that acts as a roadmap to
the organization while building new products.
Impediment. An obstacle that prevents the team from achieving its
objectives. Also known as a blocker.
Increment. A functional, tested, and accepted deliverable that is a subset
of the overall project outcome.
Incremental Life Cycle. An approach that provides finished deliverables
that the customer may be able to use immediately.
Information Radiator. A visible, physical display that provides
information to the rest of the organization enabling up-to-the-minute
knowledge sharing without having to disturb the team.
I-shaped. Refers to a person with a single deep area of specialization and
no interest or skill in the rest of the skills required by the team. See also T-
Shaped and Broken Comb.
Iteration. A timeboxed cycle of development on a product or deliverable
in which all of the work that is needed to deliver value is performed.
Iterative Life Cycle. An approach that allows feedback for unfinished
work to improve and modify that work.
Kaizen Events. Events aimed at improvement of the system.
Kanban Board. A visualization tool that enables improvements to the
flow of work by making bottlenecks and work quantities visible.
Kanban Method. An agile method inspired by the original Kanban
inventory control system and used specifically for knowledge work.
Large Scale Scrum (LeSS). Large-Scale Scrum is a product development
framework that extends Scrum with scaling guidelines while preserving
the original purposes of Scrum.
Lean Software Development (LSD). Lean software development is an
adaptation of lean manufacturing principles and practices to the software
development domain and is based on a set of principles and practices for
achieving quality, speed, and customer alignment.
Life Cycle. The process through which a product is imagined, created, and
put into use.
Mobbing. A technique in which multiple team members focus
simultaneously and coordinate their contributions on a particular work
item.
Organizational Bias. The preferences of an organization on a set of scales
characterized by the following core values: exploration versus execution,
speed versus stability, quantity versus quality, and flexibility versus
predictability.
Organizational Change Management. A comprehensive, cyclic, and
structured approach for transitioning individuals, groups, and
organizations from the current state to a future state with intended business
benefits.
Paint-Drip. See Broken Comb.
Pairing. See Pair Work.
Pair Programming. Pair work that is focused on programming.
Pair Work. A technique of pairing two team members to work
simultaneously on the same work item.
Personas. An archetype user representing a set of similar end users
described with their goals, motivations, and representative personal
characteristics.
Pivot. A planned course correction designed to test a new hypothesis about
the product or strategy.
Plan-Do-Check-Act (PDCA). An iterative management method used in
organizations to facilitate the control and continual improvement of
processes and products.
Plan-Driven Approach. See Predictive Approach.
Predictive Approach. An approach to work management that utilizes a
work plan and management of that work plan throughout the life cycle of a
project.
Predictive Life Cycle. A more traditional approach, with the bulk of
planning occurring up-front, then executing in a single pass; a sequential
process.
Project Management Office (PMO). A management structure that
standardizes the project-related governance processes and facilitates the
sharing of resources, methodologies, tools, and techniques.
Product Backlog. An ordered list of user-centric requirements that a team
maintains for a product.
Product Owner. A person responsible for maximizing the value of the
product and who is ultimately responsible and accountable for the end
product that is built. See also Service Request Manager.
Progressive Elaboration. The iterative process of increasing the level of
detail in a project management plan as greater amounts of information and
more accurate estimates become available.
Refactoring. A product quality technique whereby the design of a product
is improved by enhancing its maintainability and other desired attributes
without altering its expected behavior.
Retrospective. A regularly occurring workshop in which participants
explore their work and results in order to improve both process and
product.
Rolling Wave Planning. An iterative planning technique in which the
work to be accomplished in the near term is planned in detail, while the
work in the future is planned at a higher level.
Scaled Agile Framework (SAFe®). A knowledge base of integrated
patterns for enterprise-scale lean–agile development.
Scrum. An agile framework for developing and sustaining complex
products, with specific roles, events, and artifacts.
Scrumban. A management framework that emerges when teams employ
Scrum as the chosen way of working and use the Kanban Method as a lens
through which to view, understand, and continuously improve how they
work.
Scrum Board. An information radiator that is utilized to manage the
product and sprint backlogs and show the flow of work and its bottlenecks.
Scrum Master. The coach of the development team and process owner in
the Scrum framework. Removes obstacles, facilitates productive events
and defends the team from disruptions. See also Flow Master.
Scrum of Scrums. A technique to operate Scrum at scale for multiple
teams working on the same product, coordinating discussions of progress
on their interdependencies, and focusing on how to integrate the delivery
of software, especially in areas of overlap.
Scrum Team. Describes the combination of development team, scrum
master, and process owner used in Scrum.
Self-Organizing Team. A cross-functional team in which people fluidly
assume leadership as needed to achieve the team's objectives.
Servant Leadership. The practice of leading through service to the team,
by focusing on understanding and addressing the needs and development
of team members in order to enable the highest possible team performance.
Service Request Manager. The person responsible for ordering service
requests to maximize value in a continuous flow or Kanban environment.
Equivalent to product owner.
Siloed Organization. An organization structured in such a way that it only
manages to contribute a subset of the aspects required for delivering value
to customers. For contrast, see Value Stream.
Single Loop Learning. The practice of attempting to solve problems by
just using specific predefined methods, without challenging the methods in
light of experience.
Smoke Testing. The practice of using a lightweight set of tests to ensure
that the most important functions of the system under development work
as intended.
Specification by Example (SBE). A collaborative approach to defining
requirements and business-oriented functional tests for software products
based on capturing and illustrating requirements using realistic examples
instead of abstract statements.
Spike. A short time interval within a project, usually of fixed length,
during which a team conducts research or prototypes an aspect of a
solution to prove its viability.
Sprint. Describes a timeboxed iteration in Scrum.
Sprint Backlog. A list of work items identified by the Scrum team to be
completed during the Scrum sprint.
Sprint Planning. A collaborative event in Scrum in which the Scrum team
plans the work for the current sprint.
Story Point. A unit-less measure used in relative user story estimation
techniques.
Swarming. A technique in which multiple team members focus
collectively on resolving a specific impediment.
Technical Debt. The deferred cost of work not done at an earlier point in
the product life cycle.
Test-Driven Development. A technique where tests are defined before
work is begun, so that work in progress is validated continuously, enabling
work with a zero defect mindset.
Timebox. A fixed period of time, for example, 1 week, 1 fortnight, 3
weeks, or 1 month. See also Iteration.
T-shaped. Refers to a person with one deep area of specialization and
broad ability in the rest of the skills required by the team. See also I-
Shaped and Broken Comb.
User Story. A brief description of deliverable value for a specific user. It
is a promise for a conversation to clarify details.
User Story Mapping. A visual practice for organizing work into a useful
model to help understand the sets of high-value features to be created over
time, identify omissions in the backlog, and effectively plan releases that
deliver value to users.
UX Design. The process of enhancing the user experience by focusing on
improving the usability and accessibility to be found in the interaction
between the user and the product.
Value Stream. An organizational construct that focuses on the flow of
value to customers through the delivery of specific products or services.
Value Stream Mapping. A lean enterprise technique used to document,
analyze, and improve the flow of information or materials required to
produce a product or service for a customer.