Nemawashi

(Implementando mudanças)

Nemawashi (根回し

?) significa um processo informal de estabelecer as bases de alguma proposta de mudança ou projeto, falando com as pessoas envolvidas, conseguindo apoio e feedback e assim por diante. É considerado um elemento importante em qualquer grande mudança, antes de quaisquer medidas formais, sendo que o Nemawashi bem sucedido é aquele que possibilita mudanças com o consenso de todos os lados envolvidos. Ele normalmente é realizado em pequenos grupos, várias vezes e com diferentes pessoas, a fim de captar os elementos chaves que podem influenciar o projeto em questão.

Nemawashi pode ser traduzido literalmente como dando voltas na raiz, de 根 (ne, raiz) e 回す (mawasu, dar volta em algo). Seu significado original era literal: cavar ao redor das raizes de uma árvore para prepará-la para um transplante.

Nemawashi é frequentemente citado como um exemplo de palavra japonesa que é difícil de traduzir efetivamente, pois é muito intrínseca à cultura japonesa, apesar de muitas vezes ser traduzida como lançando as bases.

Nemawashi nas empresas: O Nemawashi começou a ser difundido nas empresas japonesas, mais precisamente na Toyota em meados do século XX quando o seu engenheiro-chefe Taiichi Ohno percebeu que o principal fator de falta de sinergia durante um processo de mudanças era a falta de comunicação. Então os colaboradores da Toyota tinham de, antes de fazer alguma nova alteração no processo, conversar com todos os envolvidos em busca de informações relevantes. Hoje o Nemawashi é um pilar importante da filosofia lean (ou Toyota Production System), codificado por John Shook e James Womack durante um estudo mundial do MIT que, subsequentemente, fundaram o Lean Enterprise Institute, berço da disseminação cultura lean ocidental juntamente do Lean Institute Brasil.

O princípio Lean do Nemawashi, estabelece que as decisões sejam tomadas lentamente, através de consenso, para que todas as alternativas relacionadas possam ser avaliadas e para que haja amplo comprometimento com relação ao que for decidido.

Isso soa um tanto estranho quando confrontado com o imediatismo dos tempos atuais. Nas culturas ocidentais, a demora do processo decisório costuma ser associada a algo negativo, como a hesitação.

Já nas culturas orientais, aguardar até o último momento para tomar uma decisão representa sabedoria, por isso saber o momento certo para se tomar uma decisão torna-se importante e para isso estimar tempo em projetos é fundamental. Por este motivo, as estimativas de tempo nos projetos Scrum seguem os preceitos do Nemawashi.

Se você não está familiarizado com estimativas em projetos ágeis, deve estar curioso

para saber como isso funciona na prática, certo? Então vamos lá. Como tudo no Scrum, é bem simples, desde que feito da forma correta e com a ajuda das ferramentas certas. Mas fiquem calmos, mesmo sendo um processo lento, uma vez que pode demandar discussões prolongadas, está longe de ser chato. Na verdade, definimos estimativas para os requisitos do Backlog do Produto jogando cartas e o nome desse jogo é “Planning Poker”.

É isso mesmo, você não entendeu errado. Aliás, em minha opinião, o Planning Poker é uma das melhores abordagens, senão a melhor, para definição de estimativas através de consenso. Sei que parece esquisito, principalmente para quem está habituado a engolir estimativas, normalmente empurradas “goela-abaixo” pelo gerente do projeto ou algum especialista da equipe (felizmente no mundo ágil não existe espaço para essas “boas práticas”). Sendo assim, vamos ao jogo.

Se vamos jogar cartas, precisamos de um baralho certo? Exato, e temos um específico para essa finalidade. Abaixo apresento um modelo bastante utilizado em projetos ágeis:

Existem vários modelos de baralhos para jogar Planning Poker, na verdade, são muito parecidos e o que muda é a quantidade de cartas (normalmente variam de 12 a 14).

A escala de números, de 0 a 100, é utilizada para determinação das estimativas. Podemos utilizar essa escala para representação de horas, dias, pontos de função ou story-points (unidade utilizada especificamente em projetos de desenvolvimento de software). Os números também podem ser utilizados como unidades de comparação, por exemplo: um requisito 40 é duas vezes maior que um requisito 20, o qual é quatro vezes maior que um requisito 5 e assim por diante.

Observe que a seqüência numérica das cartas não é linear. Isso ocorre por que está baseada na escala do matemático italiano Leonardo Fibonacci. A série de números evolui através da soma do número anterior com o número seguinte e assim sucessivamente. Esta sequência foi desenvolvida por Fibonacci na idade média, para descrever o crescimento de uma população de coelhos.

A utilização desta escala para estimativa de requisitos tem duas finalidades principais:

1) Mostrar que quanto menor o requisito, menor será a variação da estimativa. Por exemplo: para um requisito com esforço de desenvolvimento 3, pode ocorrer uma

variação de estimativa entre 2 e 5 (utilizando as cartas), o que corresponde à uma oscilação baixa. Já para um requisito com esforço 20, pode ocorrer uma variação bem maior, entre 13 e 40. Dessa forma, o Time de Projeto é encorajado a trabalhar com requisitos menores, com o objetivo de reduzir a variação das estimativas.

2) Forçar a discussão e a análise mais aprofundada das estimativas entre os integrantes do Time. Escalas lineares tendem a favorecer discussões mais rápidas e superficiais, uma vez que os impasses tendem a ser resolvidos através da adoção de médias, por exemplo: uma discussão entre estimativas de 13 e 20 pode resultar em um consenso entre 16 ou 17.

Legal, mas e aquelas três últimas cartas da seqüência, o que representam? Bem, vamos começar pelo ponto de interrogação. Quando alguém apresenta esta carta para uma estimativa, está dizendo aos demais integrantes do Time que não tem a menor idéia do esforço para construção do requisito, na prática, está abstendo-se de votar. A carta com a xícara de café (pode ser de chá ou chocolate, se preferir), quer dizer que está sendo solicitada uma interrupção no jogo (intervalo), para descanso ou atendimento dos chamados da natureza. A carta com “E” representa um Épico. Épicos são estórias ou requisitos muito grandes que, segundo o proponente da carta, não pode ser estimado da forma como está. Se o Time concordar com essa opinião, o requisito será “quebrado” em unidades menores, até que possa ser adequadamente estimado.

Jogando Planning Poker

Para começar, estabeleça um timebox de 4 horas para esta atividade. Todos os Porcos podem participar: componentes do Time de Projeto, Dono do Produto e ScrumMaster. Galinhas e Vacas, se presentes, serão meros expectadores. É importante reforçar que o Dono do Produto e o ScrumMaster participam para assessorar o Time com informações que poderão auxiliar na definição das estimativas, entretanto, somente os responsáveis diretos pelo desenvolvimento do produto podem jogar.

Sentados ao redor de uma mesa, cada integrante do Time segura um baralho com as 14 cartas apresentadas anteriormente. Um requisito é selecionado do Backlog do Produto para estimativa. Normalmente, costumo começar pelos requisitos menores, mas com prioridade mais alta. Caso ainda exista alguma dúvida com relação ao item escolhido, os integrantes do Time de projeto pedem esclarecimentos adicionais ao Dono do Produto. A partir do momento que o Time acredita possuir as informações necessárias, o processo de definição das estimativas é iniciado da seguinte forma:

1) Cada integrante do Time escolhe uma carta que corresponde à sua estimativa para o desenvolvimento do requisito;

2) À medida que são escolhidas, as cartas são colocadas sobre a mesa, com a face (estimativa) virada para baixo;

3) Após todos os integrantes do Time terem definido suas estimativas, as cartas são viradas e apresentadas ao mesmo tempo;

4) Se as estimativas foram iguais, adota-se o número como esforço de construção estabelecido para o requisito;

5) Se houver divergência de estimativas, cada integrante do Time apresenta seus argumentos para justificar o número escolhido;

6) Encerradas as argumentações, o processo de votação é repetido, até que uma estimativa de consenso seja alcançada pelo Time.

Cabe ao Time de Projeto estabelecer as regras para alcance de consenso sobre as estimativas, durante as rodadas do Planning Poker (unanimidade, 3 rodadas, 2 rodadas etc.).

Definido o esforço de construção do requisito, outro item é selecionado do Backlog do Produto e o ciclo é repetido até que todos os requisitos estejam estimados.

Considerações Importantes:

A definição de estimativas não precisa, nem deve, ocorrer em um único evento. O processo de desdobramento, o qual também podemos chamar de refinamento de requisitos, ou grooming, deve considerar inicialmente os itens de maior prioridade do Backlog. Os demais requisitos (de menor prioridade) podem receber estimativas de alto-nível, até chegar o momento de serem desenvolvidos, quando então o desdobramento será necessário. A figura abaixo ajuda a explicar essa dinâmica:

Estimativas são como um bom vinho, melhoram somente com o tempo. À medida que o Time acumula ciclos de entrega, utiliza a experiência adquirida para aprimorar o processo e a qualidade das estimativas. É extremamente importante que o Time adote sempre estimativas consideradas reais, sem contar com milagres ou margens de segurança (gorduras). Somente dessa forma haverá condições para melhoria contínua das estimativas ao longo do tempo.

Por fim, vale reforçar que as estimativas nos projetos Scrum são determinadas exclusivamente pelo Time de Projeto, através de consenso. Em nenhuma hipótese os integrantes devem aceitar números que não considerem viáveis, impostos por pressão do Dono do Produto ou qualquer usuário-chave.

Por outro lado, o time não pode utilizar essa condição para trabalhar somente com estimativas “confortáveis”, sem nenhum desafio. Trata-se de um equilíbrio delicado, que exige profissionalismo, maturidade e muita transparência. Nesse contexto, cabe ao ScrumMaster exercer sua liderança, através do método Socrático, para assegurar a qualidade e a eficácia do processo.

Créditos do texto a:

http://pt.wikipedia.org/wiki/Nemawashi

Roberto Simões

http://scrumex.com.br/blog/?p=1239&goback=%2Egde_2379511_member_51150242

Por: Jose Donizetti Moraes - 02/09/2012