Arquivo do autor:dwildt

03.06.13
por

Minha equipe / empresa quer adotar Metodologias Ágeis. Quais os benefícios?

O principal? Uma mudança de atitude na organização. Ter pessoas que estão interessadas em mudar e melhorar. E neste ponto, as empresas começam a encontrar e buscar um perfil profissional com características de trabalho em equipe, atitude, pessoas focadas em melhorar continuamente. Em colaborar.

O grande ponto é criar mecanismos nas organizações que ajudem na fomentação, criação e realização de mudanças. E que estas mudanças ocorram pela equipe de trabalho. Não por alguma gerência específica ou consultores externos. Através de ciclos curtos de revisão e adaptação, as equipes podem validar se a mudança foi válida ou se uma nova estratégia precisa ser definida. Falhar faz parte do processo de aprendizado. Seu contexto é diferente do contexto de outras empresas. Copiar nem sempre é opção.

As empresas que não possuírem um ambiente propício para mudanças vão em breve ver uma série de pessoas deixando e buscando empresas que valorizem isto. Ser infeliz no ambiente de trabalho não é mais uma opção.

Se a organização criou mecanismos de mudança, é agora hora de ensinar as pessoas do poder que elas tem. Criar autonomia. Com isto, as empresas terão braços de inovação crescendo, pouco a pouco. Um ritmo de trabalho começa a ser formado. As pessoas começam a achar normal sair da zona de conforto e buscar resolver problemas internos e a trabalhar harmonia e colaboração com toda a equipe.

E aqui tem outro detalhe. As pessoas que não entrarem neste ritmo de mudanças e melhoria contínua, de querer ajudar e focar no trabalho em equipe, serão levadas a se retirarem da organização. De forma natural. Elas deixam de ter a identidade do time. Vão acabar por buscar uma organização compatível com as suas expectativas de dedicação (envolvimento / comprometimento). Não é que tenha algo errado. Afinal, como dizia Deming, a mudança não é obrigatória, afinal de contas, sobreviver é opcional.

No final o sistema se ajusta como um todo. E a atitude positiva é o que vai valer.

Em resumo? Melhorar continuamente. Através deste caminho, as empresas se tornarão  “organizações em contínuo aprendizado“. A criação de conhecimento se torna meta. Ou melhor ainda, um hábito. Definir um ritmo para que este aprendizado possa ser discutido e evoluído. Aí se tem reuniões de retrospectiva e outras dinâmicas que permitem as equipes terem alinhamento e reflexão. A melhoria de comunicação vai minimizar riscos, conflitos e aumentar a possibilidade de sucesso da organização olhando a evolução da sua cultura.

Aproveite o caminho, e saboreie as mudanças!

02.29.12
por

Qual a melhor estimativa usada em ambientes Ágeis?

03082012TrenaFotoMarcosSantos009

Qual funciona melhor, qual é mais precisa?

E a minha resposta é ao mesmo tempo nenhuma e todas. O ponto não é este.

O que seu time deve buscar em uma reunião de estimativa não é uma certeza, mas sim conseguir entender que o time está alinhado e aprendendo sobre o negócio. Em uma brincadeira com planning poker, onde os números possíveis são 1,2,3,5,8,13… se uma pessoa indica o número 1 e outra pessoa indica o número 13, você tem um momento para discussão, para nivelar conhecimento ou conhecer um risco que estava “escondido” no sistema.

Todas as técnicas funcionam para guiar o time e criar um modelo de pensamento… conforme o time evolui em conhecimento de negócio e tecnologia, a tendência é a estimativa funcionar melhor e ajudar o time a visualizar questões que estejam “fora de padrão”.

O principal benefício dos exercícios de classificação/estimativa é gerar discussão e basear o conhecimento das pessoas sobre as funcionalidades a serem desenvolvidas. Ou seja, se você usa uma técnica de estimativa, deveria ser para crescer conhecimento da equipe. Não para poder culpar alguém depois.

E se você precisa estimar algo que é nebuloso? Você vai precisar seguir no conceito do 3C, para poder conhecer mais sobre a funcionalidade e possivelmente adicionar Spikes no planejamento, assim poderá experimentar e aprender mais sobre algo antes de fazer a definição da funcionalidade por completo.

Você deveria conversar até ter visão de que o que precisa ser feito é algo factível. Eu gosto de quebrar coisas e entender que elas cabem no máximo em três dias (idealmente no máximo 1 dia). No fim, isso é uma “regra de dedão“, ou seja: vamos aprender mais se o que temos para fazer ainda não está sendo percebido por todos da equipe. Vamos nos manter em modo descoberta, até que possamos caminhar para o modo entrega.

Se o seu time chegar nesta regra de que tudo tem um tamanho pequeno para executar, você não precisa mais estimar! Tudo vira “1”. E isso só quer dizer que o seu time tem um objetivo de “até quando vamos nos manter em modo descoberta” antes de iniciar a executar / entregar algo.

02.14.12
por

A reunião da manhã – melhoria contínua

8135229928_de131d8c4d

Seth Godin fala duas coisas que eu acho muito legal. Uma delas é porque perguntar porque? E a outra é sobre a qualidade das nossas perguntas. Nós crescemos e evoluímos e cada vez mais aprendemos a perguntar de forma especializada, sobre como está o tempo hoje.

Melhoria contínua será um processo muito melhor e simples se aprendermos a fazer perguntas diferentes, além de perguntar sobre o tempo durante a manhã.

Além de melhorar a qualidade das perguntas, precisamos estar presentes no local dos problemas, para poder ver de perto e sugerir melhorias, com o devido contexto. Estar presente no Gemba, e poder trabalhar com o conceito de Genchi Genbutsu é o que precisamos.

Mas o objetivo é falar de melhoria contínua e sobre uma prática da Fastcap, sobre a reunião da manhã para puxar melhoria contínua.

Prática simples, que busca criar uma cultura de aprendizado, diário, e que permite as pessoas exercitarem inovação, permite as pessoas trabalharem em equipe, melhorando o sistema e o ambiente de trabalho como um todo.

Na sua empresa, como sua equipe exercita a melhoria contínua?

11.22.11
por

Cartão, Conversação e Confirmação! O conceito 3C.

3879260297_dfc867d531
Fichas de papel, cartões de papel ou index cards, são uma excelente forma de manter a vista novas ideias para um produto de software. E a melhor característica delas é o espaço limitado. Hein?

Sim.

Você não vai conseguir colocar toda informação necessária na ficha. E isto é bom, pode acreditar.

Em 2003 quando eu estava estudando eXtreme Programming, ouvi uma história do Ron Jeffries sobre 3C. E desde então eu aplico e ensino isto, pelo valor que esta prática agrega no dia a dia de um projeto.

O conceito do 3C é baseado em iniciar com a escrita de uma ideia em um cartão, para que possamos lembrar. O cartão é o primeiro C. E ele leva ao próximo, gerando um “lembrete para a conversação”.

Que é o que precisamos gerar, conversas. O objetivo com isto é validar as ideias, com pessoas que podem ajudar no tópico. O melhor nestas conversas é criar exemplos que ajudem a validar a mesma. Estes exemplos acabam virando depois cenários de aceitação da história. Se é um cálculo, exemplos de cálculos. Através deste processo, criamos um “cartão executável“. E este é o nosso segundo C. Ah, um cartão normalmente possui um documento auxiliar, onde o requisito em questão é documentado seguindo os padrões que a equipe utiliza.

Estas conversas ajudam o time a identificar alguns atributos para os cartões, exemplo?
– senso de valor
– prioridade
– risco associado
– qualquer-atributo-que-o-time-consiga-ver-valor.

O terceiro C é sobre confirmação. Através das conversas com o time e clientes poderemos entender como validar o cartão e confirmar que o que temos definido é o necessário para “fazer acontecer“. E então é isto que precisamos buscar, confirmação! E dos nossos clientes! Eles irão confirmar sua ideia e ajudar a mesma a crescer.

O que mais sobre cartões?


Jessica Hagy do site Indexed, que conheci por indicação da minha irmã. Você encontra o livro da Jessica na Amazon.

O negócio é o seguinte: um cartão pode fazer muito por você. Até mesmo ajudar você a manter uma conversa com seus clientes. Tente e teste!

11.15.11
por

O poder de mudança e as pessoas

5362273271_7499632c24

No dia 19 de outubro de 2011, eu escrevi no Twitter: “Cuidado, as vezes mesmo em estrutura flat de empresa você pode criar um mundo dilbert. Evite, dê poder de verdade as pessoas! #empowerment”

Gostaria de evitar ver nas empresas qualquer coisa que se relacione com um post que fiz no primeiro de abril, onde trago a tona uma expectativa sobre como não viver no ambiente de trabalho. Enfim, parece que alguns não dão risada e ainda ficam imitando.

O principal é manter as coisas simples.

É poder trabalhar e criar um ambiente onde as pessoas se sintam responsáveis e com vontade de funcionar não apenas como profissionais que executam tarefas, mas também como profissionais que criam e puxam iniciativas, que estão presentes quando o time precisa de ajuda.

Que encontram na equipe um ambiente que se identificam e que querem ajudar a ficar melhor sempre.

Ao centralizar o poder no ambiente de trabalho, você dá a chance das pessoas criarem uma zona de conforto, e isto não deve ser alimentado, nunca. Steve Jobs falou uma vez, “Stay hungry, stay foolish“.

A moral de tudo isto é que você precisa se perguntar o quanto você é capaz de mudar algo onde está trabalhando. Será que a cultura de aprendizado existe mesmo ou você só pode e deve fazer o que está na descrição do seu cargo? E de quem é a responsabilidade sobre isto? #pense

11.01.11
por

Precisamos de prática!

8182308742_11e245507e

Henry Mintzberg disse “You cannot create a manager or leader in a classroom“. O contexto vem de uma discussão sobre o mercado precisar de gerentes e não de MBAs. Que os cursos são muito bons para ensinar as práticas que gerentes vão precisar no mercado, pensando em “o que” aplicar… mas isto é diferente das situações de como aplicar, que se ganha com a prática do dia a dia.

Mintzberg também trabalha a questão que todos deveriam conhecer gerenciamento, para então buscar um cargo onde a necessidade de gestão seja um requisito.

O ponto é que a prática é o que nos leva a experiência e a realmente conhecer algum assunto.
Não é a teoria. É a prática. É a experimentação. É o trabalho em campo.

Então, da próxima vez que você entrar em uma sala de aula, lembre-se disto: um treinamento, o trabalho em sala de aula, serve para consciência e reflexão!

Para ganhar experiência, seja em projetos, em técnicas de apresentação e escrita, você precisa enfrentar situações no seu dia a dia. Existem formas de criar estas situações de realidade, exemplo:

  • Realizar melhorias na sua vída e no seu trabalho
  • Participar de projetos open source
  • Escrever artigos para blogs, revistas, portais
  • Criar produtos novos, sejam eles produtos de software ou não
  • Organizar eventos
  • Realizar trabalho voluntário para ONGs

O simples fato de participar de ações como estas, vão resultar em experiência. Prática. Esta prática vai ajudar a criar cultura. A criar um ambiente, de puro aprendizado, mas lembre, prático!

01.21.11
por

O que é Agilidade? Revisitando o conceito… (por Daniel Wildt)

daniel-wildt-small

No dia 26 de junho de 2010, o Rafael Helm publicou aqui mesmo no Pingos de Agilidade o que era para mim Agilidade. O Rafael pediu para eu mandar em uma frase.

E eu mandei: Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua.

Só que como todo desenvolvedor Clean Code, tudo pode ser refatorado. 🙂

E nesta declaração, se eu for refatorar, como já vi o @KlausWuestefeld fazer com os valores do eXtreme Programming, chegando no Learning and Coolness, entendo que atitude e foco em entrega fazem o resto acontecer.

Vejamos:

Trabalho em equipe não é opcional. Você nunca vai ser melhor do que uma equipe em sinergia. Não quer uma equipe? Pense em um par, pense nos benefícios de ter conhecimento navegando e se tornando algo consciente e consistente entre as pessoas que fazem parte da equipe.

Melhoria contínua também não é opcional. Se sua equipe não melhora, ela sempre vai piorar. Simplesmente não se consegue “manter” a qualidade porque conforme o aumento da base de código, prazos, decisões mal feitas no projeto, novos problemas relacionados a modularidade e outros aspectos no desenvolvimento de software vão ficar mais visíveis. Então melhorar continuamente é algo que se faz sempre.

É a continuidade do processo de questionar aquilo que está sendo feito e buscar sempre melhorar, faz parte da atitude.

E é o que sobra e ao mesmo tempo faz a diferença. A atitude da equipe perante os obstáculos e como ela encara as situações de planejar novas funcionalidades para um produto, como ela encara o feedback ao cliente depois de um problema na operação do produto. Ou ainda como cada pessoa que faz parte da equipe vê a resolução de um defeito.

Se eu foco na entrega de software, quero garantir que o trabalho será o melhor possível, pois ninguém quer ter que trabalhar a noite ou final de semana ajustando algum problema de produção, causado na liberação de versão.

Então focar em entrega exige busca por qualidade, exige melhoria contínua. Só que sem atitude e foco em entregar aquilo que o cliente precisa, pensando em simplicidade, nada ocorre.

Exige aprender novos truques, em buscar novos conceitos como DevOps e Continuous Delivery.

01.19.11
por

Contrate apenas quando doer!

4129400323_03d17b79b0

Para quem conhece o pessoal da 37Signals, e já leu o livro Rework, deve se lembrar do tópico: “Hire when it hurts“.

Eu particularmente gosto deste tópico, por gostar de trabalhar com equipes pequenas e por entender que as restrições são excelentes para mostrar como somos capazes de ir além e de nos superar.

Demonstra como podemos realmente ser multidisciplinares e como conseguimos crescer como equipe.

Então a dica é sempre esperar o máximo possível antes de partir para uma nova contratação. Trabalhe com o time as restrições, garanta qualidade e excelência técnica do seu time. Garanta o aprendizado e gestão de conhecimento. Garanta a colaboração e práticas que fazem o time crescer.