menu

Gestão de Riscos e #NoEstimate — Agilistas brasileiros comentam

Por

O evento #LeanCoffee, além da troca de experiências em gestão e do networking, ainda serve como bom termômetro de assuntos talvez ainda pouco entendidos na comunidade ágil.

Dois assuntos têm chamado a atenção por aparecerem de forma recorrente nas discussões. Por essa razão decidimos entrevistar alguns dos nomes mais importantes da comunidade ágil do Brasil — André Faria, Manoel Pimentel e Rodrigo Yoshima — para saber como eles encaram os seguintes temas: “Gestão de riscos no Agile” e o movimento do “No Estimate”.

Vamos lá?

André Faria

andre-fariaAndré Faria Gomes (@andrefaria) é Sócio-Diretor de Produtos e Tecnologia na Bluesoft em São Paulo e Associated Trainer na Adaptworks. André é autor do livro “Agile: Desenvolvimento de software com entregas frequentes e foco no valor de negócio” e é também tradutor do livro “How to Change the World” de Jurgen Appelo para Português.

A gestão tradicional de projetos (PMBOK) traz a gestão de riscos como uma área de conhecimento que permeia praticamente todas as fases do projeto. Você adota alguma(s) prática(s) específica(s) para gerir os riscos em suas implementações?

Acredito que a melhor forma de lidar com riscos é não apenas reconhecer que eles existem, mas também reconhecer que nem sempre podemos nos prevenir de todos eles. Em software há muita incerteza. Incerteza de custo, de prazo, de escopo de funcionalidade e incertezas de tecnologia, só para citar algumas. Nesse sentido concordo com o PMBOK, os riscos são transversais.

O desenvolvimento ágil de software trabalha ciclos curtos de feedback e, isso, ao meu ver, é uma das melhores ferramentas para se lidar com riscos e diminuir o impacto de todas essas incertezas que temos.

Uma prática bem simples e eficiente apresentada no Agile Brazil 2013 por Paulo Carolli e Tainã Caetano, é criar uma matriz de riscos técnicos e funcionais nas reuniões de planejamento. Basicamente, o time posiciona cada uma das histórias planejadas em um nível de incerteza técnica e funcional. Se o nível de incerteza for alto, podemos tomar alguma atitude para reduzir o risco, como entrevistar especialistas de negócio ou fazer code spikes para conhecer melhor a tecnologia a ser aplicada.

Um movimento que vem ganhando força é o do “no estimate”, que alega ser um desperdício estimar o esforço do trabalho. Qual seu pensamento a respeito?

Eu penso que é preciso estimar se houver valor em se ter previsibilidade ou se trouxer algum outro benefício, seja para o time de desenvolvimento, seja para outros interessados (marketing, executivos, etc.). Fora isso é desperdício.

Na Bluesoft, por exemplo, há alguns anos estimávamos utilizando story points nos planejamentos quase que semanalmente, isso demandava algum tempo, mas nos trazia alguma previsibilidade, e isso nos era útil para planejarmos releases futuras.

Atualmente conseguimos uma previsibilidade aceitável (para nós), basicamente acompanhando a vazão (throughput) semanal de cada equipe, e procurando manter as histórias sempre pequenas para reduzir um pouco a variabilidade. Ou seja, apesar de não estimarmos, conseguimos ter a previsibilidade que precisamos, de forma que agora estimar, para nós, seria desperdício.

Acredito que estimativas, quando tratadas como estimativas e não como compromissos, ou seja, quando é reconhecido o alto grau de incerteza que, geralmente existe, podem ser úteis em alguns contextos sim, mas é importante tornar explícito qual é o valor que se está buscando com essas estimativas, e considerar se não há outras formas mais eficientes de se alcançar esse mesmo valor.

Manoel Pimentel

manoel-pimentelManoel (@manoelp) é Agile Coach na Adaptworks e um dos pioneiros no movimento ágil no Brasil. É também blogueiro, revisor e palestrante. Ele é o fundador da Revisa e Blog Visão Ágil e do blog stoosians.org.

A gestão tradicional de projetos (PMBOK) traz a gestão de riscos como uma área de conhecimento que permeia praticamente todas as fases do projeto. Você adota alguma(s) prática(s) específica(s) para gerir os riscos em suas implementações?

Particularmente, acho que é uma visão míope pensar que no Agile não há tratamento de riscos.   Claro que no Agile não há uma cultura de fazer isso por intermédio de algum artefato ou de processo formal. No Agile, reconhecemos a complexidade inerente ao ecossistema social e tecnológico de desenvolver software (na verdade, inerente a contextos de knowledge work). Dessa forma, os riscos são identificados também de maneira emergente e aos poucos. Nesses casos, o time vai aprendendo quais dimensões de risco deve considerar a cada planejamento de um novo ciclo. Em minhas experiências em clientes, com Scrum, sempre estimulo os times Scrum (PO, Dev Team e SM) a terem nojo dos impedimentos. Isso significa que para evitar os impedimentos,  a cada Sprint Planning os times precisam incluir novas dimensões de risco identificadas nas Retrospectivas das Sprints passadas.  O mesmo funcionamento se aplica em tempo de Release, caso essa seja diferente e maior do que o tempo das Sprints.

Na minha visão, essa estratégia é bastante assertiva para lidar com a incerteza e a imprevisibilidade de ambientes complexos.  Nesse ponto, concordo bastante com Jim Highsmith quando fala que em ambientes complexos, qualquer forma de planejamento, no fundo, é uma especulação. Esse mesmo raciocínio vale para a dimensão risco. Então a grande reflexão que precisamos fazer é: Quanto tempo e dinheiro queremos investir para criar esse estoque de especulações?

Particularmente,  a extensibilidade do Scrum pode ajudar bastante nessa hora, pois, se o time achar que é importante, é possível adicionar alguma prática emergente, para resolver os problemas que aconteceram nos ciclos passados.

Um movimento que vem ganhando força é o do “no estimate”, que alega ser um desperdício estimar o esforço do trabalho. Qual seu pensamento a respeito?

Mais uma vez, em função do caráter especulativo que qualquer planejamento tem em ambientes complexos, no fundo, a ideia do #NoEstimates me é bastante sedutora. Claro que o mercado não está preparado ou afim de reconhecer que isso é válido.  Daí, preferem acreditar numa ilusão de previsibilidade ou de estimabilidade :-). É importante lembrar que em ambientes complexos e adaptativos, nós temos os chamados “desconhecidos não-conhecidos” (pensa em alguma coisa que você não sabe que não sabe… – doidera não?). Sendo assim, mesmo que nossas estimativas sejam sustentadas por bases históricas e estatísticas dos ciclos passados, isso no fundo continua sendo um mega exercício de especulação. Observe que ser uma especulação não é necessariamente algo ruim. Toda boa especulação, hora se erra, hora se acerta. Só não dá para generalizar e prever que o sistema sempre se comportará na mesma forma.

Agora se considerarmos que, talvez haja ambientes de trabalho (ou até mesmo alguma parte de um ambiente complexo) que não são complexos (por exemplo, ambientes simples de acordo com modelo Cynefin), aí fazer estimativas, identificar riscos, planejar detalhamente, faça sentido! Observe que a questão não é ser a favor ou contra o #NoEstimates, mas sim, entender e dançar conforme a natureza dos sistemas complexos.

Rodrigo Yoshima

rodrigo-yoshimaRodrigo (@rodrigoy) é Accredited Lean-Kanban University Trainer, consultor e instrutor Lean/Agile na Aspercom. É um dos pioneiros na aplicação da abordagem Kanban em ambientes complexos de desenvolvimento de software para grandes empresas no Brasil.

A gestão tradicional de projetos (PMBOK) traz a gestão de riscos como uma área de conhecimento que permeia praticamente todas as fases do projeto. Você adota alguma(s) prática(s) específica(s) para gerir os riscos em suas implementações?

Concordo com o PMBOK, mas não com a estratégia de riscos que geralmente os PMBOKers seguem (basicamente documentar e usar isso pra CYA — Cover your *). Por incrível que pareça, em 1999 o RUP já tinha uma estratégia de riscos que me parece convincente. Sistematicamente, através das fases do RUP, 4 grandes riscos eram atacados: risco do que o usuário quer; risco arquitetural; risco do “tamanho do projeto” e risco de transição. Apesar de não ser o foco, o RUP já dizia em sua fase de Iniciação que para “reduzir riscos, selecione alguns requisitos críticos para prototipação”. Eu vejo isso como Lean Startup.

Por outro lado, a estratégia: “o Product Owner é meu pastor e os riscos mitigará (priorização)” definitivamente me parece a mais pobre de todas.

Em 2012, no Kanban Coaching Masterclass aqui no Brasil, David Anderson mostrou a forma como ele tem ajudado empresas a lidar com riscos por meio de de Classes de Serviço em um Sistema Kanban. Basicamente é um modelo classificatório que leva em consideração Cost-of-Delay (Custo de Atraso), dificuldade arquitetural, estratégia de mercado (Table Stakes, Differentiator, Spoiler, Cost-Saver) entre outras coisas. Veja o vídeo Lean Risk Management sobre isso.

Um movimento que vem ganhando força é o do “no estimate”, que alega ser um desperdício estimar o esforço do trabalho. Qual seu pensamento a respeito?

Creio que o Corey Ladas reportou uma vez que algumas equipes Kanban abandonaram estimativas. Isso gerou um frenesi. Por incrível que pareça, a bandeira do #NoEstimates não é algo que está nas mãos da comunidade Kanban hoje.

Infelizmente o No Estimates tem um discurso inflamado que gera um impacto emocional grande nas pessoas. Na comunidade Kanban, o que tem ganhado tração é o que chamamos de Probabilistic Forecast (a obtenção de previsibilidade estatística – dentro de certos ranges de variabilidade – através da observação do sistema). Sem fazer muito alarde, em várias implementações Kanban minhas, as equipes não estimam.

Recentemente a equipe do Oppa.com.br deixou de estimar em pontos as demandas. É bastante comum isso acontecer em empresas de produto, em que  o custo de coordenação das estimativas (imagine um planning de 4 horas com aproximadamente 10 pessoas contando story points) não se paga.

Custo de Coordenação sobre estimativas x Necessidade econômica de previsibilidade é um Trade-off muitas vezes ignorado.

O mindset atual sobre previsibilidade é interessante. Gestores pensam que previsibilidade é uma função linear simples entre esforço e capacidade. Se essa função está errada o ônus cai sobre quem estimou. Essa aritmética simples se baseia em duas premissas muito duvidosas: (a) quem estima tem uma precisão aceitável nas suas previsões e (b) há pouca ou nenhuma variabilidade na capacidade, isto é, no nosso mercado as pessoas trabalham todos os dias com o mesmo humor e motivação. Há fatores emocionais envolvidos em questionar essas premissas, mas, creio que a maioria dos gestores sensatos questionaria ambas. Essa aritmética simples “Esforço Estimado x Capacidade” é reforçado por uma crença básica: (c) “Quanto maior o esforço, mais tempo levará para ficar pronto.”, e assim, é imprescindível saber se coisas são “grandes” ou “pequenas” no trabalho do conhecimento.

Vamos para a ciência. Teoria das Filas e a Lei de Little destacados por Don Reinertsen no “Principles of Product Development Flow” nos afirma que o impacto do WIP é determinante para o Lead Time (Cycle Time, no vocabulário dele) e para a Variabilidade. Essa é uma maneira de dizer que filas que emergem, gerando trabalho parado e alto WIP são mais danosas para a previsibilidade do que o tamanho do lote, afinal, lotes pequenos e grandes param numa fila da mesma forma. Assim, chegamos a outra métrica que é a Eficiência do Processo (Poppendieck’s): EP = Touch Time / Lead Time, sendo Lead Time = Queue Time + Touch Time. Touch Time é simplesmente o tempo que de fato o trabalho está nas mãos de alguém. Queue Time é o tempo que o trabalho está esperando numa fila. Me dá mais um parágrafo que vou voltar para o No Estimates.

Por que estimar pode ser considerado desperdício? Basicamente porque estimar é baseado no esforço (tamanho do lote), porém, o esforço só é determinante para a previsibilidade se a eficiência do seu processo é altíssima (acima de 60%) e ISSO É EXTREMAMENTE RARO em um ambiente em TI. Em 5-6 equipes que mensurei isso o recorde foi 15% de EP (e note, era uma equipe Scrum, sim, no Scrum as filas também se formam dentro de uma Sprint e para a Release). Alguns coaches em Kanban no mundo tem reportado números entre 3% a 5% de EP (destacando Zsolt Fabok e Hakan Forss).

A principal razão de se estimar hoje é para se obter previsibilidade, e previsibilidade é uma razão da variabilidade e não da calibragem da bola de cristal do desenvolvedor. Bola de Cristal + Gordura não é uma boa política de previsibilidade. É um mito achar que uma variabilidade de 10x no esforço entre 2 demandas diferentes irá gerar 10x de variabilidade no Lead Time. Não há correlação entre esforço e Lead Time se sua EP é baixa. Vou dar um exemplo:

Imagine um processo cujo estudo da EP evidencie que o Queue Time é de ~10 dias. Você tem 2 demandas. Uma (X) cujo esforço se configura em um Touch Time de 1 dia e outra (Y) cujo Touch Time é de 10 dias. Você pensa que por conta dessa diferença haverá 10x de variabilidade no Lead Time. O fato é que a X tem ~11 dias de Lead Time e a Y tem ~20 dias nesse sistema. Note, a variabilidade de 10x no esforço não reproduziu nem em 2x a variabilidade no Lead Time.

Isso por conta da EP. A variabilidade no esforço costuma se anular com outras variabilidades no sistema. Quase nunca o tamanho das demandas é a causa raiz da variabilidade. O que eu tenho visto nas minhas equipes Kanban é a própria compreender o que é variabilidade e com isso elas criam um sistema imunológico. Geralmente elas não ligam para o tamanho das demandas, mas, evitam “elefantes e ratos”. Isto é, não deixam entrar no sistema demandas grandes demais e nem pequenas demais. Cortam o elefante e juntam os ratos. Um mito que se espalhou (patrocinado pelo FUD da comunidade ágil) é que para as métricas do Kanban funcionarem (basicamente Lead Time e Throughput) as demandas “tem que ter o mesmo tamanho”. Isso é bullshit. As equipes Kanban geralmente evitam elefantes e ratos, e isso tem um custo baixo de coordenação. Qualquer coisa que entre no sistema entre coelhos e cavalos terá variabilidade sobre controle estatístico, pois o esforço se anula dentro do sistema, principalmente se WIP estiver limitado.

Tudo isso nos ensina que para se obter previsibilidade é necessário lutar contra a variabilidade. Num processo de trabalho a variabilidade tem diversas causas raízes. Os “usual suspects” são WIP e Filas, mas também pode ser bloqueios, indisponibilidades temporárias, silos entre muitos outros. No Treinamento Kanban da Aspercom eu criei o Kaizen Game basicamente para demonstrar para gestores e equipes que mesmo com 50% de variabilidade no tamanho dos lotes do jogo e com 75% de variabilidade no “humor” dos trabalhadores é possível ter um sistema previsível. No Treinamento costumo dizer que você deve investir em minimizar a variabilidade do sistema ao ponto de atender as necessidades econômicas de previsibilidade do seu mercado ou empresa em particular.


Acreditamos, no Kudoos, que a troca de experiências acelera muito o amadurecimento de ideias. Por isso, fizemos o convite para os entrevistados acima, que muito generosamente contribuíram com suas opiniões, as quais refletem seus estudos e suas vivências.

Convidamos você também a deixar sua opinião sobre os temas, ou a vir participar de um de nossos Lean Coffees para que novos temas possam emergir e, quem sabe, novas entrevistas sejam realizadas ;-).

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

10 comments

  1. Rafael Buzon

    Fantástico! Agradecemos carinhosamente cada um dos entrevistados pela generosa contribuição ao responder as perguntas! Kudoos!

    Posted on agosto 22, 2013
    • Leonardo Campos

      Obrigado, Luan.

      Nós aqui de Kudoos fomos uns dos primeiros cobaias do Rodrigo com o Kaizen Game, hehehe.
      Ele deve ter evoluído bastante o jogo já, mas mesmo quando jogamos já estava fantástico 😉

      Posted on agosto 23, 2013
  2. Pingback: Entrevista para o Kudoos sobre Riscos e Estimativas | André Faria

  3. Romulo Aguiar

    Post sensacional, nunca pensei em tratar o risco desta forma , como foi exposto nas entrevistas.

    Equipe Kuddos, Parabens

    Posted on agosto 28, 2013
    • Leonardo Campos

      Opa Rômulo, você tratava risco de alguma forma diferente? Quer compartilhar conosco?

      Ah, obrigado pelos parabéns 😉

      Posted on agosto 30, 2013
  4. Pingback: 6 passos: Da ideia ao planejamento e execução | Kudoos

  5. Pingback: Calibrando nossa "Bola de Cristal" - Scrum, Estimativas e Datas de Entrega | MATERA Systems

  6. Pingback: O que é Eficiência do processo? | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top