Nemawashi

1.579 visualizações

Publicada em

Aprofundando meus estudos sobre a cultura japonesa,

0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.579
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
24
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Nemawashi

  1. 1. Nemawashi (Implementando mudanças)Nemawashi (根回し?) significa um processo informal de estabelecer as bases dealguma proposta de mudança ou projeto, falando com as pessoas envolvidas,conseguindo apoio e feedback e assim por diante. É considerado um elementoimportante em qualquer grande mudança, antes de quaisquer medidas formais, sendoque o Nemawashi bem sucedido é aquele que possibilita mudanças com o consenso detodos os lados envolvidos. Ele normalmente é realizado em pequenos grupos, váriasvezes e com diferentes pessoas, a fim de captar os elementos chaves que podeminfluenciar 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 redordas 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 demuitas vezes ser traduzida como lançando as bases.Nemawashi nas empresas: O Nemawashi começou a ser difundido nas empresasjaponesas, mais precisamente na Toyota em meados do século XX quando o seuengenheiro-chefe Taiichi Ohno percebeu que o principal fator de falta de sinergiadurante um processo de mudanças era a falta de comunicação. Então os colaboradoresda Toyota tinham de, antes de fazer alguma nova alteração no processo, conversar comtodos os envolvidos em busca de informações relevantes. Hoje o Nemawashi é um pilarimportante da filosofia lean (ou Toyota Production System), codificado por John Shooke James Womack durante um estudo mundial do MIT que, subsequentemente,fundaram o Lean Enterprise Institute, berço da disseminação cultura lean ocidentaljuntamente 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 epara 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 algonegativo, como a hesitação.Já nas culturas orientais, aguardar até o último momento para tomar uma decisãorepresenta 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, asestimativas de tempo nos projetos Scrum seguem os preceitos do Nemawashi.Se você não está familiarizado com estimativas em projetos ágeis, deve estar curioso
  2. 2. 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 demandardiscussões prolongadas, está longe de ser chato. Na verdade, definimos estimativas paraos requisitos do Backlog do Produto jogando cartas e o nome desse jogo é “PlanningPoker”.É 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 deconsenso. Sei que parece esquisito, principalmente para quem está habituado a engolirestimativas, normalmente empurradas “goela-abaixo” pelo gerente do projeto ou algumespecialista da equipe (felizmente no mundo ágil não existe espaço para essas “boaspráticas”). Sendo assim, vamos ao jogo.Se vamos jogar cartas, precisamos de um baralho certo? Exato, e temos um específicopara 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 muitoparecidos 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 oustory-points (unidade utilizada especificamente em projetos de desenvolvimento desoftware). 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 é quatrovezes 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úmerosevolui através da soma do número anterior com o número seguinte e assimsucessivamente. Esta sequência foi desenvolvida por Fibonacci na idade média, paradescrever 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. Porexemplo: para um requisito com esforço de desenvolvimento 3, pode ocorrer uma
  3. 3. variação de estimativa entre 2 e 5 (utilizando as cartas), o que corresponde à umaoscilação baixa. Já para um requisito com esforço 20, pode ocorrer uma variação bemmaior, entre 13 e 40. Dessa forma, o Time de Projeto é encorajado a trabalhar comrequisitos 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 osintegrantes do Time. Escalas lineares tendem a favorecer discussões mais rápidas esuperficiais, uma vez que os impasses tendem a ser resolvidos através da adoção demédias, por exemplo: uma discussão entre estimativas de 13 e 20 pode resultar em umconsenso entre 16 ou 17.Legal, mas e aquelas três últimas cartas da seqüência, o que representam? Bem, vamoscomeçar pelo ponto de interrogação. Quando alguém apresenta esta carta para umaestimativa, está dizendo aos demais integrantes do Time que não tem a menor idéia doesforço para construção do requisito, na prática, está abstendo-se de votar. A carta coma xícara de café (pode ser de chá ou chocolate, se preferir), quer dizer que está sendosolicitada uma interrupção no jogo (intervalo), para descanso ou atendimento doschamados da natureza. A carta com “E” representa um Épico. Épicos são estórias ourequisitos muito grandes que, segundo o proponente da carta, não pode ser estimado daforma 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 PokerPara começar, estabeleça um timebox de 4 horas para esta atividade. Todos os Porcospodem participar: componentes do Time de Projeto, Dono do Produto e ScrumMaster.Galinhas e Vacas, se presentes, serão meros expectadores. É importante reforçar que oDono do Produto e o ScrumMaster participam para assessorar o Time com informaçõesque poderão auxiliar na definição das estimativas, entretanto, somente os responsáveisdiretos pelo desenvolvimento do produto podem jogar.Sentados ao redor de uma mesa, cada integrante do Time segura um baralho com as 14cartas apresentadas anteriormente. Um requisito é selecionado do Backlog do Produtopara estimativa. Normalmente, costumo começar pelos requisitos menores, mas comprioridade 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 doProduto. A partir do momento que o Time acredita possuir as informaçõesnecessárias, o processo de definição das estimativas é iniciado da seguinte forma:
  4. 4. 1) Cada integrante do Time escolhe uma carta que corresponde à sua estimativa parao 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ãoviradas e apresentadas ao mesmo tempo;4) Se as estimativas foram iguais, adota-se o número como esforço de construçãoestabelecido para o requisito;5) Se houver divergência de estimativas, cada integrante do Time apresenta seusargumentos para justificar o número escolhido;6) Encerradas as argumentações, o processo de votação é repetido, até que umaestimativa de consenso seja alcançada pelo Time.Cabe ao Time de Projeto estabelecer as regras para alcance de consenso sobre asestimativas, durante as rodadas do Planning Poker (unanimidade, 3 rodadas, 2 rodadasetc.).
  5. 5. 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/NemawashiRoberto Simõeshttp://scrumex.com.br/blog/?p=1239&goback=%2Egde_2379511_member_51150242Por: Jose Donizetti Moraes - 02/09/2012

×