Metodologias Light: Problemas, Princípios, e Práticas Gerência de Processos Francilene Garcia...

Post on 07-Apr-2016

224 views 1 download

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