Quando 1 + 1 > 2

Tesoura: duas laminas que são mais eficientes juntas que cada uma individualmente

É difícil explicar o motivo de parear em algo seja mais vantajoso que fazer cada um a sua atividade. Concordo que depende muito do contexto de cada equipe e de cada pessoa. Tem outras coisas que são praticamente impossíveis imaginar sem fazer em par. Eu não consigo imaginar educar um filho sem ser em par, no caso com a minha esposa, obviamente. Não imagino e acredito ser um processo ágil, inclusive já escrevi sobre isso. Outras, nunca tinha imaginado, como ensinar em par (Par Teaching) ou Pair Researching. E por fim, outros pares são obrigatórios, como em voos comerciais com o Piloto e co-Piloto.

Já no desenvolvimento de software, temos algumas vantagens em programar em par:

Visões diferentes: Enquanto um programa outro pode ver o arredor do fonte e ter uma visão mais ampla do que está sendo desenvolvido

Comunicação: É impossível ficar ao lado de alguém sem conversar e trocar experiências, visões e etc.

Aprendizado: Sempre há algo para aprender, para se desenvolver.

Eu ainda acrescentaria duas que para mim são muito importantes:

Foco: Para sair do foco, precisa de duas pessoas percam o foco, não apenas 1.

Segurança: Senti-se apoiado com outra pessoas compartilhando as ideias e etc.

 

OK, funciona em desenvolvimento de software (claro, dependendo do contexto), em alguns casos realmente é imprencidível. Mas Par Coaching?

O interessante dessa prática é que acabamos tendo 3 entidades envolvidas. Cada um dos indivíduos formadores do par e mais os dois juntos, que acaba formando uma terceira entidade.

Esse é um resumo da apresentação do Rodrigo Toledo e do Daniel Teixeira.

Link da apresentação: http://prezi.com/hdlyyblytasf/pair-coaching/

Imagem: http://www.flickr.com/photos/azriadnan/1818312422/

Read Full Post »

Técnica de Pareamento e TDD

Surpreendeu-me saber que muitas das técnicas dos Métodos Ágeis não têm estudo cientifico que comprova sua eficácia e que 90% dos agilistas são estudantes e não tem conhecimento das práticas anteriores.

Algumas considerações que achei interessante e são resultado de estudos científicos que foram mencionadas nas palestras.

• Técnica do pareamento
  • Empregar em equipes grandes com nível de conhecimento distinto.
  • Empregar em equipes com alta rotatividade.
  • Empregar em soluções difíceis de resolver.
  • Empregar em casos Forever Alone: Situações que ninguém gostaria de pegar.
  • Não parear em tarefas simples.
  • Não parear em tarefas de estudo ou pesquisa.
  • Não parear em tarefas corriqueiras.
  • Difícil coordenação

• TDD
  • Qualidade do software não é melhor com aplicação do TDD e sim igual.
  • O uso do TDD não guia o desenvolvedor.
  • Usar quando se sabe o que se quer fazer, porém não se sabe como.
  • Auxilia em programas complexos no que tande ao projeto de classes.
  • Não utilizar quando se tem claro o que deve ser feito.
  •  Auxilia na qualidade externa.
  • Relação mínima para aplicar TDD 20.hrs (Desenvolvimento) X 1.hrs (Testes)

Read Full Post »

Last Day

Diferenças entre as gerações no ambiente corporativo é algo inevitável. Mas, ambos os lados da trincheira baby boomers, membros da geração X e Y têm muito a aprender uns com os outros.

Infelizmente a grande maioria das palestras que fui parece não compartilhar deste pensamento quando falamos em metodologias de suporte ao desenvolvimento de software. AGILE na terra e Deus no céu. É como se a tal bala de prata que falam não existir sim existisse.

PMI, PMBOK, casos de uso entre outros foram motivo de piada em muitas das palestras, parecem não perceber que podem tirar muito proveito das práticas e técnicas que estas entre outros podem oferecer. Um dos palestrantes chegou a brincar que tinha vergonha de ter certificação em PMI.

Na palestra do pessoal da DB-Server “Eduardo Meira e André Piegas” e na palestra do “Mauricio Aniche” que fez seu Mestrado e esta finalizando o Doutorado em Métodos Ágeis com maior foco em TDD, escutei o mesmo conselho “Analise o contexto”. Estes palestrantes foram uns dos poucos que não idolatraram as metodologias ágeis embora muito admiradores de algumas das práticas existentes e empregadas na mesma.

Meu ponto de vista é que o mix de algumas das práticas ágeis com as utilizadas até então é o caminho mais sensato a ser seguido. Muitas pessoas devem tirar a viseira do lado do rosto e abrir a mente. Fiquei surpreso com o número de seguidores dos métodos ágeis que parecem ter viseiras que os impedem de analisarem o contexto como um todo e tirarem um proveito maior das práticas e situações já vivenciadas anteriormente pensando como se a solução para o mundo fosse ser AGIL e não percebem que temos muita coisa boa nas metodologias anteriores que podem nos auxiliar e ajudar de alguma forma.

De modo geral achei muito legal e interessante o encontro e percebo que pode-se tirar muito proveito de muitas das práticas ágeis no que tange o desenvolvimento de software.

Read Full Post »

TOP 10 – Agile Brazil 2012

Após o segundo dia de palestras pego meu Tablet de papel, vulgo bloco de anotações e vejo o resumo dos principais itens mencionados nas palestras que participei. O que percebi foi um padrão de 10 itens mencionados em praticamente todas apresentações.

Mindset

Temos de permitir mudar a maneira de ver as coisas, um bom exemplo foi a palestra do Neal Ford, sobre a comparação de PASTAS de arquivos e TAGS’s utilizada no gmail.

Modo fácil ou difícil

O apoio executivo de uma empresa é um forte indicativo no sucesso da implantação de métodos ágeis. Participei de quatro cases a respeito da implantação de métodos ágeis e dois foram implantados TOP/ DOWN (RBS e MODULO “Empresa que controla a segurança das informações da Receita Federal, Bancos e outros”) e dois cases BUTTON/TOP (não recordo as empresas). Os dois casos que tiveram o apoio do executivo obtiveram um resultado melhor e menos traumático. O maior desafio é a implantação de uma nova cultura e não o uso de novas ferramentas ou técnicas de trabalho.

Dica – Primeiro convença os GRANDES.

Priorizar

• Maior dificuldade é decidir o que não será atendido, mas quando definido acaba valorizando o que será feito.
• Métricas de priorização: Primeiro o que é mais fácil, impactante e urgente, estes são os principais parâmetros a serem utilizados.

Retrospectiva

Faça valer apena, defina se você INICIA, PARA ou CONTINUA algo. Momento de definir futuras ações.

Seja simples

Faça parte do time, não seja vaidoso.

AboLIÇÕES aprendidas

• Se servir para mim serve para você
• O processo ágil não depende do estágio da evolução da equipe.
• Não podemos utilizar processos e artefatos adicionais das propostas no MA.
• O importante é seguir as cerimônias ou processos.
• Métodos ágeis exigem menos disciplina.
• Mesmo que o cliente não tenha interesse, utilize métodos ágeis.
• Somente podemos aplicar as práticas com sucesso se o cliente tiver envolvimento frequente.
• Vamos abolir os aprendizados anteriores. (MMI, PMBOK e outros).

 Equipe Canivete Suíço

Equipes multidisciplinares. Permita o compartilhamento do conhecimento entre desenvolvedores, funcionais, gerente de projeto. Estimule o PAR FUNCTION e melhore o entendimento do todo, crie novos suplentes e permita-se colocar-se na situação do outro.

Alocações

Considere entre 55% e 70% do tempo, ideal 63%.

Estimativas

Uma das grandes armadilhas. Obteve um grande número de erro na maioria dos casos apresentados. Também poderá a variação é o multiplicador 4, ou seja, você pode errar 4 vezes para cima ou para baixo.

Equipe

• Interesses coletivos devem ser maiores que os Interesses individuais.
• Perfil de equipe deve ser mais valorizado que o perfil técnico.
• Ter como meta principal a satisfação do cliente. Considere esta a principal métrica.
• Não forçar modelos. Experimentar, testar e adaptar um modelo existente ou criar um novo.
• Trabalhar com software é mais que trabalhar com máquinas.
• Lideres não constroem times apenas possibilitam a formação destes.

Papel do líder

• O líder deve auxiliar a entender o processo, pode ser através de:

– Mini palestras

– Mesa redonda ( dúvidas compartilhadas )

– Material escrito.

Read Full Post »

Gestão e Cultura

Hoje, praticamente segui a agenda por essa trilha específica, dedicada à gestão de equipe e de projetos. São sessões que abordam temas como formação de equipes, facilitação de projetos, coaching, cultura empresarial, valores e princípios ágeis, gestão democrática, auto-organização, gestão de produtos, processos e projetos. Em resumo, muito se falou sobre os desafios e as oportunidades na formação de times. Nesse sentido, penso que vale salientar alguns aspectos essenciais, por mais óbvios que possam parecer à primeira vista, dada a sua merecida importância.

O trabalho em equipe é fundamental para os projetos terem êxito e as pessoas envolvidas é que fazem a diferença, desde que o senso coletivo prevaleça sobre os interesses individuais. No entanto, considerando a diversidade de personalidades e de culturas, por exemplo, em um mesmo grupo, precisamos atentar especialmente para a comunicação, e assegurar que todos compreendam com clareza o que se espera de cada um e onde exatamente que se quer chegar. Os momentos críticos e a pressão em determinadas situações podem gerar conflitos e alterar comportamentos. Por isso, às vezes é necessário medir a temperatura e manter no radar as percepções do time (por exemplo: confiança, foco, performance, engajamento, decisões, fairness e liderança), antes que seja tarde demais, e o sucesso do projeto possa restar comprometido. Um conselho que me surpreendeu: não construa um time, apenas seja um facilitador para a sua formação natural.

Read Full Post »

Implantando a cultura ágil

No decorrer desse primeiro dia no evento, um tanto intenso e super corrido (parece que estamos entrando no ritmo desta grande cidade), pude assistir alguns interessantes relatos de experiências com respeito à implantação das metologias ágeis. O case do Grupo RBS, apresentado pelo Luiz Parzianello e pela Thais Dalcin, merece destaque. Para alcançar as mudanças propostas, que foram apoiadas por executivos do alto escalão, houve uma forte transformação cultural, de uma forma gradativa (kaizen), com vistas aos seguintes valores: fazer o que é certo, o nosso coração pulsa, todos pelos clientes, conexão com as pessoas, realizar crescimento sustentável e desenvolvimento coletivo. De fato, o grande desafio é implantar uma nova cultura e convencer as pessoas sobre o modelo agile, e não aplicar o uso de técnicas ou de ferramentas diferentes.

Lições aprendidas:

1. Mantenha-se calmo e fracione o problema.

2. Aceite a imprevisibilidade.

3. Estabeleça sua visão de futuro.

4. Faça mais análises de negócios.

5. Maximize o ROI (Product Owner).

6. Get out of the building.

7. Evite o uso de terminologia ágil.

8. Mantenha-se disciplinado ao Scrum.

9. Teste, teste, e teste.

10. Evolua com seu time!

Read Full Post »

O primeiro dia de Agile Brazil 2012

Buenas? Não vou falar especificamente de uma palestra, o dia foi de construção de conhecimento quebrado em várias palestras, então vou escrever da mesma forma que absorvi todo esse conhecimento.

A primeira palestra foi o Keynotes do Neal Ford. O que tirei de toda aquela informação? É mudar o mindset que temos. Um exemplo? A estrutura de arquivos hierárquico que na maioria da vezes queremos implementar. Pessoas não pensam dessa forma (como se eu não fosse uma pessoa), e há vantagens em pensar de outra forma. Um exemplo disso também? A organização dos e-mails do gmail.com através de tags ao invés de hierarquia de pastas. Por que isso pode ser melhor? Um e-mail pode ter mais que uma tag, mas não pode estar em duas pastas sem ser duplicados.

A outra palestra foi do Alberto Bastos, intitulada Onze Times e Um Destino – Case de Integração Scrum de Scrums. O que deu para tirar daí? Uma dor que é comum em muitos times que tentam implantar algum método Ágil. A vaidade das pessoas, principalmente de quem já tem cargos de chefia. Como convencer essa pessoa essa pessoa que ela será apenas um membro do time? Como remunerar as pessoas? Já discutimos isso em um post o ano passado, Enterro de anão e desenvolvedor de cabelos brancos, tu já viu? Outra conceito bem interessante foi o de priorizar e escolher o que realmente deve ser feito. Fiquei feliz, pois é algo que já conseguimos fazer esse ano, mas vou plagiar a frase: “Descartar o que não vai ser feito, valoriza o que vai ser feito”. Por último, queria também ressaltar uma métrica que se trabalha para escolher se um teste deve ou não ser automatizado. A regra é 20×1, ou seja, se a automatização levará menos que 20x o tempo de execução do teste, ele deve ser automatizado.

Por último, uma apresentação que chamou-me muito a atenção foi Importância da Gestão Visual!!! Como incluir o deficiente visual na gestão visual? Foi demonstrado um case do TRE do Rio de Janeiro que estava implantando Métodos Ágeis e havia um desenvolvedor cego. A decisão mais óbvia seria implementar a Gestão Visual através de meio eletrônico. Porém, o próprio desenvolvedor cego preferiu a Gestão Visual utilizando um Taskboard físico. Deu para sentir as vantagens dessa abordagem, eu já tinha a intuição, mas fiquei com a absoluta certeza das inúmeras vantagens do quadro físico. A principal delas é que a própria imperfeição do quadro em relação a perfeição de linhas e etc de um quadro eletrônico nos ajuda a memorizar as tarefas contidas nele. No final, fizemos uma dinâmica com duas pessoas vendadas e mesmo assim elas tinha absoluta certeza das posições de cada card no quadro, inclusive mais certeza do que outras pessoas que estavam enxergando.

 

Read Full Post »

Kit de atividades para retrospectivas

Nosso primeiro dia no Agile Brazil 2012! Na abertura, anunciaram que somos em torno de 800 pessoas provenientes de 300 empresas. O evento realmente é imenso, com opções variadas de assuntos: análise e planejamento, gestão e cultura, inovação e empreendedorismo, desenvolvimento e teste, relatos de experiência, e lightning talk!

Pela manhã, tive a satisfação de participar de um workshop do tipo mão na massa, conduzido pelo Paulo Caroli, que compartilhou muitas das suas experiências (e lições aprendidas) como facilitador em reuniões de retrospectiva de sprints e de releases. Gostei muito da abordagem proposta e das orientações recomendadas! Algumas dicas podem ser encontradas em http://agileretroactivities.blogspot.com, mas tenho algumas anotações valiosas comigo, por enquanto secretas! De qualquer modo, saibam que teremos muitas novidades nas nossas próximas reuniões, que não serão mais focadas apenas nas lições aprendidas!

Read Full Post »

Como identificar o que os clientes não gostam sobre seu produto ou serviço

Um dos itens abordados no treinamento de Requisitos Ágeis do Agile Brazil 2012 que achei muito interessante foi a técnica do Speed Boat, abaixo coloquei uma breve explicação do que é e de como utilizar a mesma.

S P E E D    B O A T

Muitas vezes flocos de neve inofensivos podem tornar-se uma avalanche de queixas. Corremos este risco caso simplesmente se peça aos clientes para que listem suas queixas a respeito de um produto ou serviço.  Uma técnica utilizada para se evitar incômodos e descobrir as angústias do cliente de modo que permita que você fique no controle de como as reclamações são apresentadas e discutida é a técnica do SPEED BOAT.

A técnica consiste praticamente em desenhar um barco em um quadro ou folha. Imagine que seu barco é o produto ou serviço que você oferece. O que o cliente vislumbra é um barco que se locomova rápido e de maneira ágil, porém infelizmente existem algumas âncoras que não permitem que ele se locomova desta maneira impedindo ou reduzindo a velocidade da viagem. Estas âncoras devem ser descritas pelos clientes e nada mais é do que os produtos ou serviços que não satisfazem seus desejos. Os clientes podem estimar o quanto de ganho se teria caso uma destas âncoras fosse içada.

O jogo metafórico pode ser personalizado para atender às suas necessidades. Exemplo: O uso de um avião, em vez de um barco e substituir âncoras por bagagem. Personalizando o jogo podemos torná-lo mais compreensível para o negócio de modo a termos um resultado mais valioso.

Poucos clientes são contra o produto porem a maioria têm queixas, muitas vezes estas queixas expressão um alto grau de frustração, porem a realidade é que querem o sucesso do produto.

O que os clientes querem é uma forma de expressar a frustração sem deixar que uma mentalidade de grupo ou uma pessoa domine a discussão. A técnica do Speed ​​Boat permite criar um ambiente seguro, onde se pode dizer o que está errado.

Expressar frustrações de maneira verbal não é algo que deixa as pessoas à vontade. Um processo seguro de contribuição é através da escrita dando a oportunidade de reflexão sobre o que é trivial ou realmente importante. Esta reflexão é importante para aqueles clientes que se queixam muito sobre os pequenos detalhes. Pedindo-lhes para verbalizar seus problemas, especialmente na escrita, motivamos a pensar sobre essas questões. Quando eles se acostumam a pensar sobre suas queixas, especialmente quantificar o impacto eles são mais razoáveis para contribuir para o sucesso.

Em muitos casos o grande número de queixas triviais pode ser acrescentado a uma queixa grande não impedindo o funcionamento do Speed Boat porque este não restringe aos participantes o tamanho, forma, peso ou número de âncoras a serem adicionas ao barco.

Read Full Post »

Otimizando o Fluxo de Trabalho

Esse foi o meu curso escolhido para a Virada Ágil nesse ano, e para início de conversa, estava demais. Ministrado pelo Paulo Caroli e pelo Guilherme Motta.

Foi um conjunto de Dojos visualizando o fluxo de trabalho de uma equipe de desenvolvimento de software. Rodamos o fluxo completo com 20 histórias e vimos onde poderíamos oportunizar mudanças nesses fluxos.

O interessante para mim, além de ver em um curto espaço de tempo um fluxo completo de Kanban, foi complementar o curso de Lean que fizemos no Agile Brazil 2011.

Entendi melhor ainda a importância de mapear o Work in Progress, o Lead Time e o Cycle Time. Além disso, entender como essas variáveis se relacionam e podemos melhorar nossos fluxos de trabalhos com simples mudanças. Essas duas fórmulas matemáticas bem simples estão pipocando na minha cabeça:

Lead Time = WIP x Cycle Time

WIP = Throughput x Lead time

Como tudo na minha vida, acabo formalizando as minhas ideias em cursos. Uma das coisas que já pensava há algum tempo é a importância de ter um fluxo para dar vazão aos requerimentos que podem ser resolvidos rapidamente, em um curto espaço de tempo. Já estamos trabalhando nisso e me dá mais certeza que estamos no caminho certo, precisamos apenas ajustar um pouco esse fluxo.

Outras ideias de Kanban surgiram na minha cabeça, quem sabe voltamos a desenhar um para nós?

Todos os arquivos do workshop estão ai:

https://sites.google.com/site/optimizingtheflow/examples/files

Read Full Post »