quarta-feira, março 31, 2010

Por que Agile e Lean funcionam? Ou como explicar para seus executivos e líderes a hiperprodutividade que esses tais de agilistas conseguem!

Analisando as pesquisas sobre sucesso de projetos encontramos números interessantes. De acordo com o Chaos Report de 2009, em torno de 30% dos projetos de TI são bem sucedidos. Enquanto isso, surveys sobre Agilidade mostram que em torno de 80% dos projetos Ágeis terminam com sucesso. E mais que isso: empresas como a SalesForce.com obtiveram uma melhoria de quase 400% no valor gerado após a adoção da cultura Ágil, em torno de 70% de redução nos defeitos e 50% de redução no time to market para lançamento de novas versões de seus produtos.

Será mágica? Será Bala de prata? Não. Então como explicar os números impressionantes acima?

Vou tratar um pouco dos 'segredos' do Agile / Lean funcionar tão bem quando ocorre uma mudança de paradigma real dentro da organização.

Os dois pilares do Lean (e que podem ser encontrados também embutidos no Manifesto Ágil) são:
- Respeito pelas pessoas
- Melhoria contínua

Podemos resumir esses dois pontos nessa frase: "A raiz do Lean/Agile é ser um eterno insatisfeito com o status quo. Você tem que se perguntar continuamente: 'Por que estamos fazendo isso?' ". Portanto é possível compreender que o princípio de Eliminar desperdícios do Lean está umbilicalmente relacionado com o pilar positivo da melhoria contínua e da eterna insatisfação com a mesmice.

Mas vocês devem estar se perguntando: Como isso explica a hiperprodutividade Agile? Vamos explicar agora, mas lembre-se de não tirar de sua cabeça os pilares: Respeito pelas pessoas e melhoria contínua com eliminação de desperdícios.

Quando ocorre uma mudança de paradigma para o Lean, as pessoas da organização voltarão seus esforços para eliminar tudo aquilo que não agrega valor na cadeia produtiva. O livro dos Poppendieck levanta uma série de elementos para identificar os geradores de desperdícios na área de desenvolvimento de software. Mas eu vou focar nos dois mais importantes e que geram o maior impacto inicial na produtividade da empresa:

- Projetos desnecessários
- Requisitos desnecessários

A adoção estratégica de Lean deve iniciar pelo esforço de Gestão Ágil de Portfólio de Projetos. Pela elaboração de business cases enxutos e continuamente avaliados para cada projeto da empresa. Conforme descrito por Donald Reinertsen em seu livro Desenvolvendo Produtos na Metade do Tempo: eliminar projetos com baixo retorno vai gerar mais velocidade no time to market dos projetos restantes. Apesar de contra-intuitivo, quando você corta projetos você entrega mais projetos num time to market menor! Esse nível mais estratégico do portfólio de projetos é pouco tratado em processos ágeis como Scrum, XP, OpenUP, etc. Porém é fundamental para a busca da hiperprodutividade.

O próximo nível é o de requisitos desnecessários. É aí em que os processos ágeis possuem práticas e mecanismos orientados para que o desperdício de criar requisitos de pouco valor não ocorra. Aí também entra a necessidade de boas pessoas e bom time. Um bom product owner (desgraçado ganancioso, como meu amigo Yoshima gosta de resumir) é fundamental para que o desperdício (quase uma hemorragia, já que segundo o Chaos Report quase metade dos requisitos não agregam valor maior que o custo para produzí-los) estanque.

Além disso, a filosofia e práticas da Agilidade/Lean focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. Nas palavras do próprio Peter Drucker: "Knowledge workers must take responsibility for managing themselves".

No tocante à gestão de projetos também temos efeitos benéficos. O PMBOK já fala sobre o clássico ou quadrante mágico de variáveis do projeto. Ele é composto por escopo, custo, prazo e qualidade. Há também uma lei em relação a esse quadrante: das quatro variáveis, você só pode fixar três... uma irá variar.

Num projeto tradicional cascata e com preço fixo (ainda no Brasil esse é o modelo mais usado, portanto o chamo de tradicional por causa disso) é fixado o custo, o prazo e o escopo. Acho que é fácil entender agora porque a maioria dos projetos de TI falha do ponto de vista dos stakeholders: o que varia é a qualidade... e ela varia lá pro fundo do buraco!

Uma empresa Ági/Lean, entendendo que defeitos são o terceiro grande gerador de desperdícios, muda isso. Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo. Essa mudança fundamental também ajuda a resolver o segundo desperdício: requisitos desnecessários. Quando o prazo e o custo são fixos, o product owner e os stakeholders terão que se esforçar ao máximo para atingir os objetivos de negócio almejados pelo projeto realizando apenas os requisitos importantes e de maior valor agregado, despriorizando ou eliminado requisitos de baixo valor. Veja como é exatamente isso que o cara que paga (sponsor) e outros stakeholders querem: um resultado (produto) de alta qualidade contendo o mínimo necessário de funcionalidades que resolvam seus problemas e necessidades de negócio, e ainda com a facilidade de mudar de idéia no decorrer do projeto.

Algumas pessoas orientadas ainda pelo paradigma preço fixo costumam imediatamente perguntar o seguinte: isso significa que um projeto Ágil entrega menos escopo que um cascata? E respondo: Muito pelo contrário, ele entrega um escopo de maior qualidade e valor agregado para o negócio. E é isso que o faz ser visto como bem sucedido pela organização.

Em resumo: Por que Agile / Lean funciona? Porque o respeito pelas pessoas e a busca da melhoria contínua levam à hiperprodutividade. Mas como essa hiperprodutividade ocorre quando ocorre a mudança de paradigma? Ela ocorre porque eliminam-se desperdícios das mais variadas formas e devido ao foco no resultado com ritmo sustentável. Os principais itens que geram isso no início são:
- Eliminação ou redução de projetos de baixo valor agregado.
- Eliminação ou redução de requisitos de baixo valor agregado.
- Em relação ao quadrante de variáveis do projeto: fixar custo, prazo e qualidade e deixar variar o escopo.

Não é fácil resumir o segredo do sucesso de algo, mas precisamos tentar. Esses segredos é que explicam a executivos e stakeholders porque adotar a filosofia Ágil os levará a outro patamar e também esclarecerá que só o 'processo' Ágil e suas práticas não resolverão o cerne do problema. A organização precisa de um choque cultural para que a hiperprodutividade se torne uma realidade, assim como ocorreu na Salesforce e em outras empresas que precisam do desenvolvimento de software e sistemas para manter seus negócios.


Um breve pensamento para fechar: "O Modelo tradicional cascata é errado e perigoso. Nós temos que superá-lo." - Frederick Brooks, autor do livro 'The Mythical Man-Month', em seu novo livro 'The Design of design'

27 Comentários:

At 10:50 AM, Anonymous Pedro Bachiega disse...

Parabéns José Paulo, ÓTIMO artigo!
Abraços

 
At 12:00 PM, Blogger Israel Santiago disse...

Parabéns, Papo ! muito bom o artigo !

 
At 1:54 PM, Blogger MRobalinho disse...

Belo texto. Boa fus]ao de ideias em torno dos m[etodos ágeis.

 
At 5:38 PM, Blogger Samuel Crescêncio disse...

excelente pensamento - parabéns...

 
At 8:14 PM, Blogger Roberiton disse...

Artigo muito interessante José Paulo. Mas, ajude-me a compreender melhor a passagem no texto "Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo".
Como manter o custo fixo se o escopo é variável?
Como manter o prazo se o escopo é variável?
Fixar a qualidade eu consegui compreender, pois pode ser definido um padrão e critérios de qualidade para os produtos a serem desenvolvidos.

 
At 8:29 AM, Blogger José Papo, MSc disse...

Oi Roberiton, o conceito é o seguinte. Seu cliente vai chegar para você e dizer: Preciso fazer o projeto X e preciso entregar algo em 6 meses. O custo da equipe nesses 6 meses você consegue calcular e será de X reais. Como você citou a qualidade é fixada devido às boas práticas da engenharia Ágil.

Portanto você tem um custo fixo e um prazo fixo. O que não é fixo é o escopo que será entregue no final desses 6 meses. A prática Ágil do product backlog priorizado garantirá que o seu cliente receberá nesses 6 meses o maior valor possível pois a equipe entregará os requisitos mais importantes e de maior valor agregado ao negócio.

 
At 10:04 AM, Blogger Mauricio disse...

Muito bom!
O grande desafio é mesmo devido ao choque cultural que esta mudança representa. Por exemplo: tratarem pessoas como "recursos" e desenvolvimento de software como linha de produção ("fábrica").

 
At 10:33 AM, Blogger Paulo Vasconcellos disse...

Oi Papo, parabéns pelo artigo.

Só queria acrescentar uma coisinha: Jim Highsmith (Agile Project Management - Second Edition. Addison-Wesley, 2010) e Roman Pichler (Agile Product Management with Scrum. Addison-Wesley, 2010) tratam o triângulo de restrições (prazo, custo e escopo) de forma ainda mais flexível. Chegam a sugerir que o cliente poderia fixar apenas uma das três.

Entendo que não é fácil "vender" tamanha abertura. Por outro lado, ganhamos a possibilidade de entregar mais e melhores projetos.

Highsmith propõe um novo triângulo, o "Agile Triangle". As restrições citadas acima são apenas uma das pontas. Valor e Qualidade são as duas novas.

Abraços,

 
At 10:35 AM, Blogger Claudio Renato disse...

Fixando custo, prazo e qualidade e flexibilizando escopo é possivel que vc entregue menos, se vc entregar menos, estará aumentando o custo, pois a principio era combinado entregar mais...

 
At 1:08 PM, Blogger Designa Soluções disse...

Este comentário foi removido pelo autor.

 
At 1:11 PM, Anonymous Michel Amaral disse...

Olá Papo!

Parabens pelo artigo, uma bela explicação e ainda citando dados e referências.

Muitas vezes o que as pessoas não entendem é "fixar" o "custo". Vale lembrar que o "custo" é "fixado" por "sprint" ou pelo período contrato pelo cliente. E o cálculo é o número de pessoas da equipe * o valor/hora de cada pessoa.

Muito bom!

 
At 1:31 PM, Blogger Celso Martins disse...

É a grande fórmula do escopo variável. Incrivel como algumas pessoas ainda acham que variando o escopo, jogando fora o desnecessário, para ter o produto funcionando no prazo e com qualidade, aumente custo. Da mesma forma que funcionalidades desnecessárias são retiradas, outras, importantes para o negócio, que foram deixadas de fora anteriormente, são adicionadas. Isso torna o projeto flexível e possível de ser entregue no prazo.
O escopo variável, permite que tanto a entrega quanto a qualidade sejam o foco do projeto. Infelizmente, a maioria das empresas só focam na entrega, desprezando a qualiadade. E o que é mais irônico é que, a maioria dos projetos, falham quanto ao prazo. É um contra-senso.

Parabéns pelo artigo.

 
At 1:54 PM, Blogger Claudio Renato disse...

Entendi... e como ter escopo variavel qdo o objetivo da solução é estar aderente a uma norma que pede integração entre um Sitema GIS e o SAP e posterior entrega de dados para Aneel? Não vejo possibilidades de reduzi-lo e acho que esses mundos andam juntos e não há certo e errado, depende do contexto.

 
At 2:00 PM, Blogger José Papo, MSc disse...

Oi Claudio, como você mesmo disse o objetivo da solução é fazer essa integração. O papel do dono do produto é então identificar o conjunto MÍNIMO de funcionalidades que atenda esse objetivo. É esse o ponto: passar a entender cada requisitos como tendo um custo distinto e priorizá-los conforme os ganhos para o negócio.

 
At 2:04 PM, Blogger Celso Martins disse...

Eu trabalho com normas que solicitam sistemas que integram Siebel e Arbor e geram dados para a Anatel.

Acho que você está confundindo objetivo do sistema com escopo.

 
At 2:18 PM, Blogger Claudio Renato disse...

O objetivo deste exemplo é estar aderente a uma norma, o escopo está em integrar GIS x SAP e gerar uma documentação em moldes específicos.
Entendi o pensar lean e abraçei a idéia... Só que neste caso o escopo não poderá variar, terá de ser entregue exatamente cada detalhe...

 
At 2:28 PM, Blogger Paulo Vasconcellos disse...

Me permitam entrar no papo, caros Papo e Claudio. Taí um típico exemplo que pede aquela flexibilidade sugerida pelo Highsmith: o escopo é fixado, prazo e custos poderiam flutuar dentro de uma faixa pré-fixada.

Abraços,

 
At 2:35 PM, Blogger José Papo, MSc disse...

É Paulo, quando já há um conjunto mínimo de requisitos que não pode ser diminuído então a organização precisa entender que terá que deixar variável custo, prazo ou qualidade (sendo que não é recomendável deixar a variabilidade na qualidade, mas é possível, desde que a empresa fique ciente dos riscos).

 
At 10:31 PM, Blogger Roberiton disse...

Olá pessoal, a discussão está em alto nível. José Paulo, PARABÉNS pelo blog. Realmente ele está contribuindo para o crescimento e amadurecimento de nossos conhecimentos através desta prazerosa discussão.

Vou colocar mais lenha na fogueira. Continuo sem compreender como alterar o escopo e manter prazo, custo e valor para o cliente.

José Paulo, você escreveu: “Seu cliente vai chegar para você e dizer: Preciso fazer o projeto X e preciso entregar algo em 6 meses. O custo da equipe nesses 6 meses você consegue calcular e será de X reais. Como você citou a qualidade é fixada devido às boas práticas da engenharia Ágil”. Com isto, podemos entender que:
- Projeto X = Projeto
- Algo = Escopo
- 06 meses = Tempo
- Custo equipe em 06 meses = Custo de X Reais
- Qualidade fixada = Critérios de qualidade prédefinidos

No cenário acima, podemos ver ver o trio da restrição (Escopo, Custo e Tempo). Maurício, a prática de “poder fixar” a restrição em apenas uma das restrições já é utilizada há muito tempo. Praticamente todas as literaturas da área de gerenciamento de projetos, inclusive as de propriedade do PMI (Project Management Institute) abordam sobre esta “flexibilidade” que você mencionou como se fosse de tais autores. O livro Gerência de Projetos (Best Seller), da Kim Heldman (ed. 2003 – página 103), você pode encontrar a seguinte passagem de texto, quando discutido sobre gerenciamento de mudança: “Em geral, as mudanças afetam uma, senão, todas as restrições do trio”. Além da Kim Heldman, outros grandes autores de livros de gerenciamento de projetos , como exemplo cito Kerzner, falam sobre as variáveis de um projeto.

Criei um exemplo fictício para tentar mostrar o que penso sobre o que estamos discutindo. Segue:

Nome da Empresa - JPRR
Nome do Projeto – XPTO
Escopo – Letras do alfabeto, conforme:
- 01(uma) letra A
- 01(uma) letra U
- 02 (duas) letras T
- Todas as demais letras do alfabeto estão fora do escopo. “As melhores práticas de gerenciamento de projetos recomendam deixar claro o que NÃO faz parte do escopo para evitar o “mais eu achava que...”
Prazo de entrega – 04 (quatro) meses (foi estimado um mês de desenvolvimento para cada letra)
Custo – R$ 400,00 (foi estimado que cada letra custaria R$ 100,00 para ser construída)
Benefício esperado pelo cliente, ou seja, VALOR para o negócio – formar a palavra TATU.

Ao finalizar o planejamento deste projeto, salvamos o baseline para possíveis comparações e análises.



MUDANÇA DE ESCOPO
Cenário A
Depois de 1 mês de desenvolvimento, o cliente pediu para incluir mais uma letra no escopo (letra S). Com isto o benefício esperado mudou, ou seja, a palavra agora é TATUS

A JPRR fez uma análise da solicitação de mudança de escopo e concluiu que para incluir mais uma letra no escopo é preciso:
- Visando entregar todo o escopo dentro dos critérios de qualidade pre-estabelidos é preciso aumentar em mais 01 mês o prazo do projoeto. Com isto, o custo de desenvolvimento passará a ser R$ 500,00, ou seja, R$ 100,00 mais caro.

Ao final dos 05 meses do projeto, todas as letras (produtos) foram entregues e o benefício foi alcançado (palavra TATUS).

Podemos perceber que a mudança do escopo alterou:
- Prazo: de 04 meses para 05 meses
- Custo: de R$ 400,00 para R$ 500,00
Permaneceu inalterado os critérios/padrões de qualidade predefinidos.

 
At 10:32 PM, Blogger Roberiton disse...

Continuação...

Cenário B
Depois de 1 mês de desenvolvimento, o cliente pediu para incluir mais uma letra no escopo (letra S). Com isto o benefício esperado mudou, ou seja, a palavra agora é TATUS. Porém, o prazo é restrito (RESTRIÇÃO DE PRAZO), ou seja, tem que ser entregue em 04 meses.

A JPRR fez uma análise da solicitação de mudança de escopo e concluiu que, com esta restrição no prazo, para incluir mais uma letra no escopo é preciso aumentar a quantidade de recursos para aumentar a capacidade de entrega. Isto refletirá em:
- Aumento de Custo, pois teremos mais profissionais trabalhando. Em caso de hora extra, idem.
- Qualidade preservada. (Digamos que os novos recursos alocados, mesmo sem a experiência devida, conseguiram manter o padrão de qualidade ou então os recursos trabalhando em hora extra, durante todo o projeto, continuaram motivados e com o mesmo fôlego e conseguiram manter o padrão de qualidade exigido).

Ao final dos 04 meses do projeto, todas as letras (produtos) foram entregues e o benefício foi alcançado (palavra TATUS).

 
At 10:33 PM, Blogger Roberiton disse...

Continuação...

Cenário C
Depois de 1 mês de desenvolvimento, o cliente pediu para incluir mais uma letra no escopo (letra S). Com isto o benefício esperado mudou, ou seja, a palavra agora é TATUS. Porém, o prazo é restrito (RESTRIÇÃO DE PRAZO), ou seja, tem que ser entregue em 04 meses.

A JPRR fez uma análise da solicitação de mudança de escopo e concluiu que não vai aumentar a quantidade de recursos nem pagar hora extra. Com isto, teremos?
- Preservação do custo inical de R$ 400,00
- Perda de qualidade (Tivemos que trabalhar apressadamente para desenvolver todas as entregas no prazo acordado)

Porém, durante o processo de verificação da qualidade...foi identificado que:
Letra A – OK
Letra U – OK
Letra S – OK
Letra T – Fora dos padrões de qualidade exigidos. Motivo: O traço horizontal da letra T não conseguia ficar fixado no traço vertical. Com isto, o produto entregue foi uma Letra I e não T.

Ao final dos 04 meses do projeto, nem todas as letras (produtos) foram entregues e o benefício não foi alcançado, pois a palavra formada foi IAIUS e não TATUS.

Como o projeto tinha uma restrição no prazo, não adiantou a JPRR pedir mais 01 mês ao cliente para reparar a letra T, pois o cliente só teria o VALOR caso o projeto fosse entregue no prazo determinado e dentro do escopo solicitado.

Podemos descrever inúmeras situações, mas estes exemplos mostraram que, em caso de alteração de escopo, não tem como manter o custo e/ou prazo fixos. A não ser que deixe de lado os critérios de qualidade pre-estabelecidos. É por esta razão que o trio da restrição (tempo, custo, escopo) também são chamados de variáveis do projeto. A Qualidade também é considerada como uma variável, como pôde ser visto no exemplo. Por esta razão, dentro do triângulo das restrições, tem-se a variável qualidade.

José Paulo, concordo parcialmente com o que escreveu: “ O papel do dono do produto é então identificar o conjunto MÍNIMO de funcionalidades que atenda esse objetivo”. Pela minha experiência em gerenciamento de projetos, o dono do produto (vamos chamar de cliente) quer o “mundo” dentro do mesmo custo e tempo. É o Gerente do Projeto que tem que entender as necessidades do cliente e ajudá-lo a traduzir o que DE FATO deve ser desenvolvido.

José Paulo, concordo com o que escreveu: “ O papel do dono do produto é então identificar o conjunto MÍNIMO de funcionalidades que atenda esse objetivo”. O owner do produto deve ter esta habilidade de identificar o que realmente agregará valor mas, pelo que vejo, infelizmente muitos destes owners não tem esta habilidade. Por isso, defendo que o Gerente do Projeto, com apoio de sua equipe, tem que entender as necessidades do cliente (Owner do produto)e ajudá-lo a traduzir o que DE FATO deve ser desenvolvido.

Pessoal, não me interpretem mal. Apenas estou colocando o que penso. Não tenho e nem tive intenção de “agredir” alguém com o meu ponto de vista.

Espero estar contribuindo com a valorização da discussão. Tenho certeza que no final, todos nós sairemos vencedores.

Aproveito a oportunidade para divulgar o meu blog (www.2rprojetos.com ) que tem o objetivo de contribuir, compartilhar e disseminar teorias, práticas e experiências sobre todo e qualquer assunto relacionado a gerenciamento de projetos e governança de TI.

Até a próxima.

 
At 10:40 PM, Blogger Roberiton disse...

Ratificação

Desconsiderar o parágrafo 7 da Continuação Cenário C

 
At 1:57 PM, Blogger José Papo, MSc disse...

Oi Roberiton,

Sua contribuição foi boa. Reforçou o que eu disse sobre as quatro variáveis do projeto.

Mas só para esclarecer; No Scrum e em metodologias Ágeis é o dono do produto que é responsável pela priorização de negócio e pela definição de um conjunto mínimo de funcionalidades. Mas, apesar de ele ser responsável, a equipe e o Scrum Master podem e devem auxiliá-lo nessa empreitada.

Por isso hoje em dia os principais papas e experts em Agile dizem que o papel do product owner é fundamental e que ele merece uma forte atenção.

 
At 2:04 PM, Blogger José Papo, MSc disse...

Olá Roberiton,

Outro ponto é sobre escopo variável. Esse é um dos pontos sempre descritos pelos métodos Ágeis e pelos papas do desenvolvimento Ágil.

Como funciona: no início do projeto você não tem escopo detalhado definido. Ele não existe. O que existe é uma visão do produto e uma lista de funcionalidades (backlog de produto). No início do projeto você só terá uma estimativa bem de alto nível sobre o que talvez seja entregue.

O cliente então define em quanto tempo e quanto dinheiro ele tem para fazer a versão 1 do produto. A qualidade, lembrando, é fixa. Portanto, com prazo e custo fixo, o que será entregue de escopo vai variar. Pode ser que a equipe entregue 20 funcionalidades, pode ser que 30. O grande ponto é que o cliente sempre saberá do andamento do produto e também poderá trocar requisitos a cada iteração. Porém, o projeto termina quando o dinheiro e o prazo terminarem.

 
At 2:15 PM, Blogger José Papo, MSc disse...

Aproveitando, recomendo mais esses dois artigos do Scott Ambler:

Agile Requirements Change Management - http://www.agilemodeling.com/essays/changeManagement.htm

The "Broken Iron Triangle" - http://www.ambysoft.com/essays/brokenTriangle.html

 
At 2:20 PM, Blogger Samuka disse...

Este comentário foi removido pelo autor.

 
At 9:43 AM, Blogger Douglas Cristiano Pereira disse...

Parabéns Papo!!!
Mto bom artigo, como vc disse nas aulas que tive com vc, por que não usar Ágil.
abraços

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas