Palestra proferida pelo Heptaman no Agile Day 2008, em Porto Alegre-RS

1. Agilidade com
Responsabilidade
Engº Adail Muniz Retamal
adail@heptagon.com.br

2. Roteiro
© 2008

3. Teoria das Restrições
Israel/EUA
Aplicações
Origem Eliyahu M. Goldratt
• Manufatura, Logística
• Cadeia de Suprimentos “A Meta”, 1984
• Marketing, Vendas
• Gerenciamento de Projetos
• TI, Operações, Educação
• Hospital, Governo TOC Estratégia
& Tática
Processo de 1. O que mudar?
Melhoria Contínua 2. Para o que mudar?
Princípios e 3. Como causar a mudança?
Ferramentas de 4. E o que garante a MCP?
1. Identificar
Raciocínio
2. Explorar
3. Subordinar
4. Elevar • Premissas
5. Voltar a 1 (inércia!) • ARA, EN, ARF, RN, APR, AT, E&T
• Medidas de Desempenho
© 2008

4. O Que Mudar?
© 2008

5. Processo de Produção
Processo de Produção
Idéias e Entender Pensar
Fazer
Necessidades o que fazer como fazer
Produto Verificar o que foi feito
Processo de Produção de Software
Requisitos Análise Desenho Construção
(Design)
Erro Erro Erro
Testes de Testes de Testes
Produto
Aceitação Integração/Sistema Unitários
© 2008

6. Má Qualidade
O produto não atende às
O Que Mudar? A Realidade Atual
Falta de Confiabilidade
Não poder contar com as
expectativas do cliente
Inflexibilidade
Incapacidade de
promessas da equipe acompanhar as mudanças
Para tentar cumprir
prazo e/ou custo,
corta-se escopo,
testes, documentação
O produto fica
Os projetos inchado, complexo O negócio e o
atrasam Falta de Visibilidade e inflexível aprendizado
Não saber como está são dinâmicos
o projeto/produto
Lei de Parkinson, Há funciona- Gostamos de arquitetar
Síndrome do Noção errônea de p/ o presente e p/ o futuro
lidades que não
Estudante, Multitarefa valor gera conflitos (real ou imaginário)
agregam valor
de prioridades
Os requisitos
Há pressão para se Os clientes pedem Forçamos os clientes devem ser
cumprir as tarefas tudo o que imaginam a pedirem tudo o que “congelados”
no prazo prometido que vão precisar querem no início do
projeto
Estimativas são Exigimos estimativas
tomadas como precisas para a Adotamos o ciclo
compromissos duração das tarefas de vida em série Devemos evitar
(cascata) mudanças nos
planos
Detalhamos bem o Queremos um forte
cronograma do projeto, controle sobre o
até ao nível das tarefas escopo, prazo e custo
© 2008

7. Má Qualidade
O produto não atende às
Falta de Confiabilidade Inflexibilidade
expectativas do cliente
Não poder contar com as Incapacidade de
promessas da equipe acompanhar as mudanças
Para tentar cumprir
prazo e/ou custo,
corta-se escopo,
testes, documentação
O produto fica
Os projetos inchado, complexo O negócio e o
atrasam Falta de Visibilidade e inflexível aprendizado
Não saber como está são dinâmicos
o projeto/produto
Lei de Parkinson, Há funciona- Gostamos de arquitetar
Síndrome do Noção errônea de p/ o presente e p/ o futuro
lidades que não
Estudante, Multitarefa valor gera conflitos (real ou imaginário)
agregam valor
O projeto demora e custa
de prioridades
Há pressão para se mais que o prometido, e
Os requisitos
Os clientes pedem Forçamos os clientes devem ser
cumprir as tarefas tudo o que imaginam a pedirem tudo o que
no prazo prometido entrega menos e pior do
que vão precisar querem no início do
“congelados”
projeto
que se esperava
Estimativas são Exigimos estimativas
tomadas como precisas para a Adotamos o ciclo
compromissos duração das tarefas de vida em série Devemos evitar
(cascata) mudanças nos
planos
Detalhamos bem o Queremos um forte
cronograma do projeto, controle sobre o
até ao nível das tarefas escopo, prazo e custo
© 2008

8. O Conflito da Empresa?
Meta Necessidades Ações/Vontades
B D
Responder às
mudanças mais rápido Ser ágil
A que a concorrência
Continuar lucrando,
mesmo num ambiente
turbulento de
negócios
Satisfazer os clientes
com promessas Ser responsável
confiáveis
C D’
© 2008

9. O Conflito do Desenvolvedor de Software?
Meta Necessidades Ações/Vontades
D
B
Sentir o gosto do Implementar “coisas
desafio legais” de se fazer
A
Ser um
desenvolvedor feliz
(motivado e
empregado)
Manter-se Implementar o que é
necessário importante para o
na empresa negócio
C
D’
© 2008

10. Processo de Produção
Processo de Produção
Idéias e Entender Pensar
Fazer
Necessidades o que fazer como fazer
Produto Verificar o que foi feito
Processo de Produção de Software
Requisitos Análise Desenho Construção
(Design)
Erro Erro Erro
Testes de Testes de Testes
Produto
Aceitação Integração/Sistema Unitários
© 2008

11. Estratégias de Desenvolvimento
Requisitos
Em cascata
Requisitos
(waterfall)
Análise
Desenho Versão 2
Teste Análise
Versão 1
Construção
Teste
Entrega
Incremental
Requisitos
Análise Análise Construção Desenho
Desenho Desenho
Construção Construção
Teste Teste
Evolucionário
Entrega
© 2008

12. Tecnologia: Necessária,
Mas Não Suficiente
A tecnologia pode trazer
benefícios se e somente se
ela diminui uma limitação.
Muito antes da tecnologia estar
disponível, nós desenvolvemos
modos de comportamento, Eliyahu Goldratt
políticas, métricas e regras para Criador da
Teoria das Restrições
nos ajudar a acomodar à limitação.
© 2008

13. Tecnologia: Necessária,
Mas Não Suficiente A nova tecnologia é
implantada, mas os
benefícios não aparecem
As pessoas continuam
se comportando sob as
mesmas regras
A nova tecnologia
As regras estão “na Uma nova tecnologia tem o potencial para
As regras não são
veia” das pessoas e é proposta para diminuir a limitação
reavaliadas
da organização melhorar a operação
A operação já Nós desenvolvemos
existe há algum regras para operar
tempo com a limitação
Nós temos uma Nós temos uma
operação limitação
© 2008

14. Para O Que Mudar?
© 2008

15. Agilidade!
a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil.
2. Desembaraço, ligeireza, presteza de movimentos.
3. Mobilidade, perspicácia, vivacidade.
Geralmente associa-se Agilidade com:
– Rapidez, Flexibilidade, Leveza
– Resumo: Habilidade para mudar
m
P = m.g
© 2008

16. Responsabilidade
Processo de Responsabilidade™
RESPONSABILIDADE cristopherAVERY.com
OBRIGAÇÃO
DESISTIR
VERGONHA Nenhum
aprendizado
JUSTIFICAR pessoal
ocorre
aqui.
CULPAR
PROBLEMA
NEGAÇÃO
© 2008

17. Os 7 Hábitos das
Pessoas Altamente Eficazes
Conhecimento
O que fazer?
Por que fazer?
Stephen Covey
Hábitos
Habilidade Desejo
Como fazer? Querer fazer
© 2008

18. Os 7 Hábitos das
Pessoas Altamente Eficazes
Dependência
1. Seja proativo Vitória
Particular
2. Comece com o objetivo em mente
3. Primeiro o mais importante
Independência
4. Pense ganha-ganha
5. Procure primeiro compreender,
depois ser compreendido Vitória
Pública
6. Crie sinergia
Interdependência
7. Afine o instrumento
© 2008

19. As Cinco Disciplinas da
Organização Que Aprende
5. Pensamento sistêmico
4. Domínio pessoal
3. Modelos mentais
2. Construção de uma visão Peter Senge
compartilhada
1. Aprendizagem em equipe
© 2008

20. As Leis da Quinta Disciplina
1. Os problemas de hoje vêm das “soluções” de ontem
2. Quanto mais você empurra, mais o sistema empurra
de volta
3. O comportamento melhora antes de piorar
4. A saída mais fácil normalmente nos leva de volta
para dentro
5. A cura pode ser pior do que a doença
6. Mais rápido significa mais devagar
7. Causa e efeito não estão próximos no tempo e
espaço
8. Pequenas mudanças podem produzir grandes
resultados, mas frequentemente as áreas de maior
alavancagem são as menos óbvias
© 2008

21. Uma Organização que Aprende é...
Onde as pessoas expandem continuamente
sua capacidade de criar os resultados que
elas verdadeiramente querem
Onde padrões de pensamento novos e
expansivos são nutridos
Onde a aspiração coletiva é libertada
Onde as pessoas estão continuamente
aprendendo a ver o todo juntas
Onde as pessoas são o principal meio de
alavancagem para os processos de mudança
© 2008

22. O Conflito do Fornecedor de Software
Meta Necessidades Ações/Vontades
D
B
Satisfazer a Implementar mudanças
percepção de que satisfarão os
valor pelos desejos dos clientes o
A
clientes mais rápido possível
Crescimento
sustentável
(Ganhar mais
dinheiro agora e no
futuro)
Não implementar
Continuar a ser
mudanças que
um fornecedor de
ameaçarão a capacidade
software confiável
de entrega
C
D’
© 2008

23. Evaporando a Nuvem
Porque...
Porque... • Existe concorrência
• Não há pressão nos clientes • Os clientes estão mais exigentes
para aceitar qualquer oferta • O ritmo do negócio exige
feita pelo fornecedor D
B
Satisfazer a Implementar mudanças
percepção de que satisfarão os
valor pelos desejos dos clientes o
A
clientes mais rápido possível
Crescimento
sustentável
(Ganhar mais
dinheiro agora e no
futuro)
Não implementar
Continuar a ser
mudanças que
um fornecedor de
ameaçarão a capacidade
software confiável
de entrega
C
D’
Porque... Porque...
• Quanto maior e mais complexa for a • Quanto mais complexo for o produto,
cadeia de entrega, maior o risco de uma maior o risco de uma mudança poder
mudança poder causar estragos causar estragos
© 2008

24. Uma Direção Para A Solução
Suposição:
As mudanças que aumentam a
satisfação do cliente ao mesmo tempo
ameaçam a capacidade de entrega
D
B
Satisfazer a Implementar mudanças
percepção de que satisfarão os
valor pelos desejos dos clientes o
A
clientes mais rápido possível
Crescimento
sustentável
(Ganhar mais
dinheiro agora e no
futuro)
Não implementar
Continuar a ser
mudanças que
um fornecedor de
ameaçarão a capacidade
software confiável
de entrega
C
1. A satisfação do cliente é atingida D’
2. A “venda de valor” prudente
principalmente através da venda e implantação
de sistemas orientados ao valor – entrega alivia a carga no
rápida e sistemática de melhorias desenvolvimento, implantação e
significativas no resultado financeiro serviços.
© 2008

25. Quais regras devemos usar agora?
Orientação por visão e valor para o cliente
– Requisitos mudam, à medida que se aprende
– Resposta à mudança é essencial para o sucesso
Desenvolvimento dirigido por funcionalidades
– Função completa com valor para o cliente
– Desenvolvidas e testadas rapidamente, e adaptadas
Ciclo de vida iterativo e incremental
– Plano de liberação, com ciclos de 2 a 4 semanas
– Cada iteração gera funcionalidades completas e testadas,
potencialmente entregáveis
Ambiente colaborativo
– Equipe trabalha muito próxima
– Documentação suficiente (suportar a iteração e evolução)
– Feedback freqüente, adaptação e aprendizado
© 2008

26. Ciclo de Vida da
Gestão Ágil de Projetos
Antevisão
Plano de
Liberação
Especular Explorar
Ação
Adaptativa Funcionalidades
Adaptar Completadas
Lista de
Funcionalidades
Produto
“Agile Project Management” Final
Fechar
Jim Highsmith, 2004
© 2008

27. Principais Benefícios da Gestão Ágil
Inovação Contínua
– Entregar de acordo com os requisitos atuais do cliente
Adaptabilidade do Produto
– Entregar de acordo com os requisitos futuros do cliente
Cronogramas Reduzidos de Entrega
– Satisfazer janelas de mercado
– Melhorar o Retorno Sobre o Investimento (RSI)
Adaptabilidade das Pessoas e Processos
– Responder rapidamente às mudanças no produto e no
negócio
Resultados Confiáveis
– Suportar o crescimento e a lucratividade do negócio
© 2008

28. Práticas Ágeis de Qualidade
Ciclos Curtos (Time Box) ou Fluxo Contínuo
Test Driven Requirements/Development
Domain Driven Design
Feature Driven Development
Testes Unitários
Integração e Testes Contínuos
Refactoring
Colaboração Entre Desenvolvedores
– Programação em Pares
– Revisão por Pares e Inspeções
Cliente/Dono do Produto mais Próximo
Retrospectivas
© 2008

29. Receitas de Agilidade
Decompor o trabalho em Entregar um fluxo estável de
elementos pequenos, bem software com valor e com sucesso,
granulados, com tamanhos por
similares Fortalecer equipes colaborativas,
Priorizar confiantes e motivadas;
Enfatizar qualidade por todo o Responder ao feedback e adaptar à
ciclo de vida mudança, e
Fazer freqüentes versões Construir com qualidade desde o
incrementais para produção início
Daniel Vacanti Karl Scotland
Modus Cooperandi Availagility
Focar na Qualidade David Anderson
AgileManagement.Net
Reduzir (ou limitar) o Trabalho em Progresso
Equilibrar a Demanda com relação ao Ganho (Vazão)
Priorizar
Crédito Extra: Reduzir a variação no processo e no seu fluxo
© 2008

30. Métricas, Estoques e Perdas
Matéria-Prima Trabalho em Progresso
Arquitetura
Requisitos Especificações Cenários
Alterações Alterações Alterações
Idéias e
Análise Desenho Construção
Necessidades (Design)
Perdas Erro Erro Erro
Testes de Testes de Testes
Produto Integração/Sistema
Aceitação Unitários
Código pronto Planos de Testes Planos de Testes Código
p/ liberação Cenários Gerais Cenários Localizados a testar
Produto Acabado Trabalho em Progresso
© 2008

31. Como Causar a Mudança?
© 2008

32. O Processo da Mudança
Idéia Modelo de Mudança de
transformadora Virgínia Satir
Catalisador
p/ mudança
Antigo Prática & Novo
Caos
Status quo Integração Status quo
Vale do Desespero
Produtividade
Ganho
Tempo
© 2008

33. Princípios Guias da
Gestão Ágil de Projetos
Entrega do Produto Liderança-Colaboração
Encorajar a
excelência Simplificar
técnica
Entregar Encorajar
valor para a
o cliente exploração
Utilizar
Construir
entrega
equipes
iterativa de
adaptativas
funcionalidade
© 2008

34. Planejamento em Camadas
Feito pela equipe de projeto Feito pela gerência superior
© 2008

35. Exemplos
© 2008

36. Scrum
7. Reuniões 6. Dia
Diárias (em pé)
5. Iteração
4. Tarefas (2 a 4 sem.)
3. Escopo da Corrida detalhadas 8. Incremento de Produto
pela equipe (pode ser liberado para uso)
(Sprint)
1. Visão
(RSI, marcos, 2. Lista de Espera (Backlog) de funcionalidades
versões) do produto, priorizada pelo Dono do Produto
© 2008

37. Feature Driven Development (FDD)
Requisitos Concepção e Planejamento
Desenvolver Construir Planejar
Mais forma que conteúdo um Modelo a Lista de por
Abrangente Features Feature
Plano de
Desenvolvimento
Modelo de Objetos
Construção
Detalhar Construir Progresso
Mais conteúdo na forma
por por
Feature Feature
Produto
Pacotes de Trabalho
© 2008

38. Scrum & FDD
Construção
7. Reuniões 6. Dia 4 5
Diárias (em pé) DPF CPF
5. Iteração
4. Tarefas (2 a 4 sem.)
3. Escopo da Corrida detalhadas 8. Incremento de Produto
pela equipe (pode ser liberado para uso)
(Sprint)
1. Visão 2. Lista de Espera (Backlog) de funcionalidades
(RSI, marcos, do produto, priorizada pelo Dono do Produto
versões)
Concepção e Planejamento
1 2 3
DMA CLF PPF
© 2008

39. Agile CMMI
Nível Foco Áreas de Processos Produtividade
Melhoria Qualidade
5: Em OID: Inovação e Implantação Organizacional
Contínua do
Otimização CAR: Análise e Prevenção de Defeitos
Processo
4: Gerenciado Gerência QPM: Gerenciamento Quantitativo de Projeto
Scrum + FDD + TOC
Quantitativam. Quantitativa OPP: Performance do Processo Organizacional
RD: Desenvolvimento de Requisitos
TS: Solução Técnica
PI: Integração de Produtos
VER: Verificação
VAL: Validação
Padronização
3: Definido OPF: Foco no Processo Organizacional
do Processo
OPD: Definição do Processo Organizacional
OT: Treinamento Organizacional
IPM: Gerência Integrada de Projeto
RSKM: Gerência de Riscos
DAR: Análise e Tomada de Decisão
REQM: Gerência de Requisitos
PP: Planejamento de Projeto
Gerência PMC: Monitoramento e Controle de Projeto
2: Gerenciado Básica de SAM: Gerência de Acordos com Fornecedores
Projetos MA: Medição e Análise
PPQA: Garantia da Qualidade do Processo e do Produto
CM: Gerência de Configuração
Risco
1 :Inicial Retrabalho
© 2008

40. Conclusão
Agilidade e Responsabilidade não são
antagônicos, mas mutuamente necessários
Agilidade busca entregar sistematicamente
um fluxo de valor para o cliente
Responsabilidade, uma via de mão dupla,
busca estabelecer a confiança necessária
entre cliente e fornecedor
A Gestão Ágil de Projetos é uma excelente
proposta para implantar uma cultura ágil
responsável
© 2008

41. Heptabraço!
Adail Muniz Retamal
adail@heptagon.com.br
www.heptagon.com.br
© 2008