Metodologias Light: Problemas, Princípios, e Práticas Gerência de Processos Francilene Garcia...
-
Upload
katia-bayer-faro -
Category
Documents
-
view
224 -
download
1
Transcript of Metodologias Light: Problemas, Princípios, e Práticas Gerência de Processos Francilene Garcia...
Metodologias Light: Problemas, Princípios, e Práticas
Gerência de ProcessosFrancilene Garcia
Ágeis
Domínios de Problemas: Investigação vs. Exploração
Investigação (descoberta do conhecimento)
Produção (apropriação do conhecimento)
O caminho do futuro
Inovação radicalDesenvolvimento exploratórioColaboraçãoMudanças rotineiras
“Radical innovation is the competitive advantage for the new millenium” – Gary
Hamel, Leading the Revolution
O desafio do desenvolvimento moderno de software
Obter rapidamente a conclusão de projetos de software caracterizados como inovadores e críticos em ambientes turbulentos de negócios e tecnologias, implica em lidar com: funcionalidades atrativas entrega rápida alta qualidade muitas mudanças
Survey conduzido pelo Cutter IT
Amostra da pesquisa 40 empresas 37 projetos por empresa
Importância 9 (20%) e-Projects por empresa 31% do orçamento gasto com e-Projects
Tendência 20 novos e-Projects sendo iniciados a cada
ano
Survey conduzido pelo Cutter IT
Tamanho do e-Project 11 meses (em média) 40 pessoas (staff técnico)
Três atividades centrais suportadas 60% serviço ao cliente 42% MIS/DSS (gestão conhecimento, data
mining, CRM, etc) 40% solicitação/fechamento serviço
Estudos da Harvard Business School
4 práticas de desenvolvimento de software sinalizam sucesso: liberação rápida de uma versão do produto ao cliente incorporação diária de novo código e feedback sobre
mudanças no projeto um time com ampla bagagem na condução de múltiplos
projetos foco no projeto da arquitetura do produto
“Product-Development Practices that Work: How Internet Companies Build Software” MIT Sloan Management Review, Winter 2001.
“Now there is proof that the evolutionary approach to software development results in a speedier process and higher-quality products”
Survey HBS
Maior número de versões – produzir versões com menor número de funcionalidades resulta em ganhos significativos de desempenho
Abordagem evolucionária reduz riscosQuanto mais rápido o feedback (horas)
maior a qualidadeIncertezas ditam projetos menores –
reduzir o nível de funcionalidades
Projetos agéis/pesados – Qual?
HBS – Estudo Sistemas ERP – Rob Austin Histórias de terror
Grandes produtores – US$ 175 a 300 M Dell – acima US$ 200 M
Características muito grande muito arriscado – técnico, organizacional, negócio
“The old projects approaches do not work in this new space” – Rob Austin
HBS – Estudo Sistemas ERP – Características de sucessoEles são iterativos?Eles dependem de ciclos rápidos e
insistem na entrega frequente?Eles coletam funcionalidades diretamente
dos usuários em etapas iniciais do projeto?
Eles fazem uso de alguma análise de ROI do projeto como um todo?
Soluções emergentes
Extreme Programming – Kent BeckCrystal Methods – Alistar CockburnLean Development – Bob CharetteSCRUM-K – SchwaberAdaptive Software Dev – Jim Highsmith
“I predict that Kent Beck and his XP movement will as much a symbol of our times as Watts Humphry and CMM were a symbol of the ’80
and ’90.” Tom DeMarco
Manifesto por desenvolvimento ágil
Valores Indivíduos e interações na frente de processos
e tools Produto operacional é melhor que
documentação Colaboração do cliente é mehor que
negociação de contrato Responder as mudanças ao invés de seguir
planos
Princípios chaves das metodologias agéis
Gerar valor para o cliente – foco em resultados
Capacidades individuais – focar na experiência de cada indivíduo
Colaboração – foco em inovação via interação entre grupos
Adaptação – foco em feedback & mudanças
Minimalismo – foco na simplicidade
Imaginar-Explorar, ao invés de Planejar
Mission driven Feature driven Iterativo (exploratório) Timeboxed Risk driven Tolerante a
mudanças
ESPECULAR-Colaborar-AprenderA - Início B – Resultado planejado
Num ambiente extremo, seguir um plano irá produzir um produto que você projetou, porém este produto poderá não ser
o que você (mercado) necessita.
C – Resultado desejado
Pessoas vs. colaboração
Deliverables Decisões Conhecimento
InterpessoalCulturalEstrutural
“O ato de colaboração é um ato de compartilhar criação e/ou
descobertas” – Michael Schrage, No More Teams
COLABORAÇÃO cultural
Comando -- Controle
Liderança -- Colaboração
Comandar Controlar é muito lento:A informação não circula na velocidade necessáriaAs decisões não são tomadas no momento oportuno
Regrinhas simples – Dee Hock
“Simple, clear purpose and principles give rise to complex, intelligent behavior”
“Complex rules and regulations give rise to simple, stupid behavior”
Metodologias agéis procuram identificar algumas práticas chaves (regras) e então deixá-las alcançar soluções para problemas específicos através de feedbacks
individuais e de grupo.
Liderança - Colaboração
Estabelce uma visão e propósito Define condições aceitáveis para os
limites Encoraja a inovação e colaboração Poder compartilhado (tomada de
decisão) líderes motivam times times motivam líderes
Macro gestão sim, micro gestão não
Principais Metodologias Agéis
Um Overview
As novas metodologias
Paper do Martin Fowler (www.martinfowler.com) foco em condutas adaptativas foco nas pessoas e não no processo
Foco naquilo que funciona na prática e não no que deveria funcionar
Foco em práticas chaves e não em TODAS as práticas
Veja também www.crystalmethodologies.com
As principais metodologias agéis
Home-made, sem nome no mercadoCrystal methodsSCRUMDSDMLean developmentFeature-drives developmentXPAdaptive software development
Crystal Methods
Proposto por Alistar CockburnReferências
www.crystalmethodologies.com members.aol.com/acockburn/ Surviving OO Practices, Addison-Wesley, 1998 Writting Effective Use Cases, Addison-Wesley,
2000 Software Development as a Cooperative
Game, Addison-Wesley, 2002
Como selecionar uma metodologia
V6 V20 V40 V100 V200 V500 V1000
E6 E20 E40 E100 E200 E500 E1000
R6 R20 R40 R100 R200 R500 R1000
C6 C20 C40 C100 C200 C500 C1000
Vida útel (V)
$$ Essencial (E)
$$ sem Restrições (R)
Conforto (C)
1-6 -20 -40 -100 -200 -500 -1000Número de pessoas envolvidas (± 20%)
Crit
ical
idad
e(d
feito
s ca
usam
per
das
de ..
.)
Priorizar produtividade e tolerância
Priorizar responsabilidade legal
Família de Metodologias Crystal
Prioridades alta produtividade, alta tolerância
Filosofia comum forte em comunicação, light nos deliverables
O desenv. de s/w é um jogo cooperativo Práticas chaves:
canais de comunicação rápidos, simples e informais
versões frequentes c/ poucas funcionalidades motiva as pessoas fazerem uso de suas
habilidades naturais (argumentação, comunicação) e estarem alertas aos defeitos (pouca disciplina, baixa cautela)
V6 V20 V40 V80
E6 E20 E40 E80
R6 R20 R40 R80
C6 C20 C40 C80
Clear Yellow Orange Red
SCRUM
Proposto por Ken Schwaber Diferencia processos definidos e empíricos Baseado na teoria da complexidade Foco em projetos:
Cujo ambiente de negócios apresenta crescente complexidade e é repleto de incertezas
A gestão do projeto procura maximizar a flexibilidade e capacidade de entregar bons produtos
Referências www.controlchaos.com http://jeffsutherland.com Existe um livro a caminho...
Overview do Processo SCRUM
Gráfico de sucesso/complexidade do SCRUM
Probabilidade (sucesso)
0,9
0,1
0,5
complexidade
baixa média alta
Probabilidade crescente (sucesso)
Resposta flexível às incertezas melhora p(sucesso) numa relação de complexidade
Caos
Feature-driven development (FDD)
Proposto por Peter CoadCapítulo 6 do livro Java Modeling in Color
with UML: Enterprise Component and Process, de Peter Coad (1999)
Processo minimalista (5 passos)www.togethersoft.com
Projetar uma
funcionali-dade
Construir uma
funcionali-dade
FDD Overview
Desenvol-ver um modelo genérico
Listar as funcionali
-dades
Planejar funcionali
-dades
Projetar uma
funcionali-dade
Construir uma
funcionali-dadeProjetar
uma funcionali
-dade
Construir uma
funcionali-dade
Um modelo objeto
Funcionalida-des chaves
Plano de desenvolvi-
mento
Diagrama de sequência
Funcionalida-de avalida pelo cliente
Mais forma, menos detalhes
Mais detalhes, menos formas
Tradicionais vs. Agéis
Documentação não significa entendimento (tácito) Documentação típica: 15% completa, 7%
correta (Elemer Magaziner) Formalidade não é disciplina
Alta qualidade requer disciplina Processo não significa competência
Muitas mudanças derrubam qq processo
Debate continua
X
X
Metodologia ágil típica
Metodologia rigorosa típica
Otimização
Adaptação
Alta
Baixa
Leve DensaCom
petê
ncia
, dis
cipl
ina,
ent
endi
men
to
Processo, documentação, formalidade
Por quê metodologias agéis?
Inovação Radical Comunidade
“Companies fail to create the future not because the fail to predict it but because they fail to imagine it.” Gary Hamel
“People and relationships are the new bottom line of business, not simply for humanistic reasons, but as a way to promote adaptability and business sucess”. Roger Lewin