Palestras/Eventos

Agilidade na Praça

Curte agilidade, métodos ágeis e outras boas práticas de programação? Cara, a gente precisa conversar! Durante a semana a vida de todo mundo é bem corrida, com muito trabalho, estudo e outras coisas que complicam a gente parar e refletir um pouco sobre como melhorar, trocar experiências e descobrir novas maneiras de trabalhar.

Eis o meu plano. Ao invés de tentar montar um grande evento, com palestrantes, inscrições e tudo o mais, vamos só marcar de tomar uma cerveja na praça, com um flipchart do lado pra ajudar e bater um papo sobre agilidade? Cada encontro a gente pega um tema diferente e vai debatendo. Cada semana um pode conduzir a conversa e quem sabe a gente pode ir variando as praças. A ideia é que seja um encontro leve, simples, sem frescura, onde possamos trocar ideias e crescer pessoal e profissionalmente!

Para iniciar, essa semana vamos começar com uma conversa aparentemente leve: o manifesto ágil!
Venha, vai ter cerveja 🙂

Extreme Pair Programming

É importante destacar, antes de mais nada, que programação em pares é uma das responsabilidades sua como desenvolvedor em XP. Não cabe ao seu chefe, à sua organização muito menos ao seu cliente interferir nessa sua decisão de qual dessas práticas no centro do diagrama você vai utilizar ou não. Então da próxima vez que alguém disser: “eu não faço programação em par porque meu chefe não deixa” mostre esse desenho abaixo e peça para ele repensar o assunto.

xp practices

Eu sempre começo meus textos com definições. Elas ajudam a entender melhor do que estamos falando e quando eu for contar os meus causos a coisa fica um pouco mais clara. Já que é assim, precisamos entender dois conceitos importantes antes de continuar. O de par e o de programação. Para começar, o par é um conjunto com dois elementos de mesma natureza, mesma espécie. Duas criaturas semelhantes juntas então formam um par. Já programação é o ato de elaborar um programa de computador. Assim, criamos código para solucionar os problemas do mundo. De maneira mais bonita é mais ou menos isso o que fazemos. Bom, então estamos falando de duas criaturas da mesma espécie trabalhando na mesma solução de um problema, no caso através de um código de computador.

Uma das maneiras que mais vejo o pessoal usando para explicar é a metáfora do piloto e navegador. O piloto, responsável pelo controle da aeronave, deve ficar atento aos controles, como dirigir para que tudo flua bem. Já o navegador é o responsável pela rota, verifica o caminho, observa aqueles controles que estão fora do campo de visão do piloto e ajuda na difícil tarefa de levar a aeronave em segurança. Na nossa prática é muito semelhante. A diferença fica que fazemos alternancias entre os papéis de tempos em tempos. Ora você é o piloto, ora você é o navegador. Usualmente o que tenho visto são duplas fazerem isso em ciclos de 15 minutos para a troca, mas não há um consenso sobre o assunto então combine entre vocês qual o tempo que lhes é mais confortável.

A prática em si é essa, alternancia de controles entre piloto e navegador, enquanto navega o desenvolvedor tem um foco um pouco mais amplo ao mesmo tempo que o piloto está focado na escrita da sua ideia de melhoria no código. Existem alguns mitos sobre programação em pares. Vamos falar de alguns.

  • Improdutivo: se medido num curto espaço de tempo, a impressão que se tem é que realmente programar em par é improdutivo e portanto mais caro para a empresa. Afinal você coloca dois “recursos” para resolver uma única tarefa, portanto estaríamos custando o dobro nesse cenário. Essa é uma visão de curto prazo e já está mais do que provado que a longo prazo esse custo se paga, com a redução da quantidade de bugs e elevada manutenabilidade do software. O código tende a ficar mais limpo e compreensível, entre outras vantagens que falarei mais a seguir.
  • Invasão de privacidade: certamente que sim. Você divide parte do seu tempo com outro desenvolvedor num espaço físico mais restrito (o espaço de uma mesa). Assim, aquela notificação que chegou para você no cantinho da tela inevitavelmente vai ser percebida pelo colega. Aquele assunto pessoal que você tinha para resolver pelo celular também agora já tem um expectador extra. Parte da sua vida será sim compartilhada.
  • Cansativo: muito! Trabalhar focado em par gera um cansaço acima da média. É recomendável o uso de outras técnicas auxiliares como pomodoro para garantir que não se exagere quando estiver trabalhando demais.
  • Sagrado: de maneira alguma! Se em algum momento você julgar que a tarefa é demasiadamente simples para colocar desenvolvedores nela então não faça programação pareada. Somente tenha cuidado para agora não usar isso como desculpa para não experimentar essa técnica.

As principais vantagens dessa técnica são:

  • Aprendizado: as duplas tendem a colaborar em experimentar novas técnicas e novas maneiras de escrever soluções para os problemas do dia à dia.
  • Motivação Mútua: pode parecer piegas, mas quando o problema que se está tentando resolver for complicado demais, você tem um amigo ao seu lado com o mesmo objetivo que você lhe motivando a seguir em frente.
  • Padronização: o código após a adoção da programação pareada migra de ter a “cara” de determinado programador para ter a “cara” da equipe. É difícil identificar qual o indivíduo dentro da equipe escreveu aquela funcionalidade, o diminui os dedos apontados em caso de falha e distribui o mérito em caso de sucesso. Fortalece o espírito de identidade do time.
  • Redução de Bugs: você tem dois cérebros, duas máquinas pensantes, duas threads abertas para resolver um problema. Enquanto um está focado no micro escopo, olhando aquela função ou aquela parte dela o outro tem uma visão mais macro, pensando nos impactos e se o restante do código fica bem com aquela alteração. Suas chances de criar algo que venha a dar defeito diminuem drasticamente dessa maneira.
  • Proximidade: sim, saímos do nosso mundinho fechado e começamos a conversar uns com os outros e em alguns casos até de coisas não relacionadas à software. Descobrimos novas afinidades, marcamos mais churrascos e confraternizações simplesmente porque começamos a ver mais fortemente mais interseções do que divergências.
  • Comunicação: aprendemos a nos comunicar, temos de expressar nossas ideias ao par antes de implementar para validar se existe alguma brecha de problema nela.
  • Foco: as distrações são bem menos percebidas quando você não está sozinho. Aquela notificação você deixa para ler depois, aquela mensagem do whatsapp que chegou provavelmente pode esperar até a próxima pausa. É mágico perceber que até mesmo o ambiente de trabalho respeita o par, pois sabe que ele está focado resolvendo um problema e interfere menos no seu trabalho.
  • Disseminação do conhecimento: deixei esse para o final pois é, na minha opinião, a mais importante das vantagens. Você reduz drásticamente o tempo de treinamento, pois agora você tem o suporte de alguém muitas vezes mais experiente para realizar a tarefa. Não existe mais o dono de uma parte do código, no mínimo existe uma dupla que é dona. Assim, se você rodar (trocar os pares) de tempos em tempos (algo como quinzenal) é visivelmente a maneira mais interessante de fazer o conhecimento circular dentro da sua equipe e quem sabe até da sua organização.

Com todas essas vantagens, fica difícil se posicionar contra uma prática tão difundida e tão bem defendida na comunidade. Se você ainda não tentou, experimente hoje mesmo e veja o seu código melhorar além é claro, de você crescer muito como profissional.

O problema não é da arquitetura

Estive recentemente palestrando na XP Conf BR, iniciativa muito legal dos meus amigos gaúchos para falar um pouco sobre “agilidade de raiz”. Essa agilidade de quem realmente faz o código, de quem escreve código e quer fazer bem feito. Falamos muito sobre as práticas da programação extrema e algumas outras coisas correlatas. É legal que, de uns tempos para cá, eu ando muito reflexivo e questionando quase tudo e todos. Talvez seja só um mal (ou bem) da idade mas o fato é que toda situação que me deparo tem me puxado um pensamento e esses eu tenho compartilhado por aqui. Foi muito bom rever meus amigos falando de Pair Programming, de Histórias de Usuário, de metáforas, entre outros assuntos legais. Assuntos teóricos, outros com casos reais de implantação, enfim, tudo ótimo. Mas a reflexão que isso me puxou é a seguinte: o problema realmente está na arquitetura?

Eu por vezes me vi tentado a pensar que sim, que como desenvolvedor eu via meus pares criando códigos de maneira quase irresponsável. Sim, irresponsável, afinal, a responsabilidade pelo código que escreviam era do gestor, do dono da empresa, ou ainda da criatura maligna do cliente que realmente não sabe o que quer, ou ainda não sabe pedir direito. Quando a gente vai num evento como esse, cheio de desenvolvedores, ávidos por escrever código de qualidade eu me questiono aonde estamos errando pois a realidade é bem distante da utopia que falamos nas palestras.

Nas palestras a gente fala de como deveria ser. De como nos fariam felizes que nossos ambientes de desenvolvimento fossem. De como seria legal que os valores ágeis, aqueles do manifesto, fossem seguidos como um código de conduta. É assim que baseio a minha vida e me parece plausível fazê-lo quando estou trabalhando. Pensar em pessoas e interações, software que funciona, colaboração com cliente e adaptação serem mais importantes que processos, documentos, contratos e planos parece fazer bastante lógica na cabeça de todo mundo que eu converso. Mas aonde estamos errando? Por que temos tanta dificuldade de convencer gestores sobre isso? Uma ideia que vem martelando na minha cabeça há tempos é que nós não entendemos o manifesto. Não entendemos a profundidade da mudança de pensamento exigida para fazer aquilo ali ser real. Vejo usualmente os desenvolvedores traduzindo “indivíduos” como “minha equipe”. É fácil se esquecer que em todos os níveis da nossa organização existem indivíduos, pessoas, seres humanos, de nossa espécie, e que esses são afetados se fizermos um trabalho mal feito.

De novo, não acho que o problema seja de arquitetura, tenho plena fé que meus amigos desenvolvedores são extremamente hábeis técnicamente para resolver os problemas que surgem e se não forem são capazes de evoluir a ponto de superar os obstáculos. Eventos como o XP Conf me mostram isso. O problema é que nós não nos importamos com as pessoas. Nem mesmo aquelas dentro da nossa organização, quem dirá aqueles que vão usar o nosso código para solucionar problemas em suas vidas.

O sonho, o fluxo e o pássaro

Em alguns Agile Tour, apresentei em quase todas as cidades o meu workshop, buscando o estado de fluxo. O que se segue aqui é uma descrição do mesmo, para que você também o possa aplicar em sua equipe, talvez levando um pouco mais de entendimento sobre Lean-Kanban ou ao menos, fazendo-os pensar sobre o assunto.

No começo é necessário lembrar de uma lenda japonesa que diz que se você tiver um sonho, algo que você deseje muito, basta produzir 1000 (mil) tsurus (pássaros ou garças de origami) e pendurá-los em uma cerejeira que esse desejo é atendido. Bom, eu desejo uma Harley-Davidson, qualquer modelo (preferencia pela FatBoy), portanto peço aos que atenderam para esse workshop que me ajudem.

O processo para fabricar o tsuru é bem simples e não exige nenhum conhecimento prévio de dobradura. Ele pode ser apresentado nas sete etapas que podem ser observadas nas fotos abaixo:

tsuru_step1 tsuru_step2 tsuru_step3 tsuru_step4 tsuru_step5 tsuru_step6 tsuru_step7 tsuru

Assim, dividido em 7 etapas distintas, necessita-se de uma equipe de 7 pessoas no mínimo para executar essa atividade. Organize-os em uma sequência de mesas, mais ou menos como uma linha de produção.

IMG_2932

DSCN1674

Além dos papés de quem vai efetivamente executar o trabalho, precisamos de pessoas que monitorem o processo, observem-o e foquem em aperfeiçoa-lo. Claro que os inputs podem vir de qualquer membro da equipe, mas se não houver com o foco nisso, equipes inexperientes podem ter dificuldade para gerir as mudanças no princípio. Assim, precisamos de uma pessoa para anotar os dados em duas planilhas, a primeira é bem simples, com um número para cada etapa em cada um dos ciclos. Nela devem ser anotados quantos itens ficaram em cada etapa ao final do tempo dado.

tsuru_tracking

Um último detalhe que as imagens não descrevem, o primeiro membro da equipe, aquele que corta o papel para ser um quadrado, deve anotar em qual ciclo/lote aquele papel foi cortado. Isso será usado na outra planilha onde vamos montar um gráfico de dispersão. Essa planilha é opcional (portanto a anotação também), somente para o caso de você querer ensinar sobre Lead time e quanto tempo as tarefas podem estar paradas dentro do seu processo. Eu costumo faze-lo direto no Excel, ferramenta excelente e necessária para esse workshop.

Muito bem, equipe treinada no processo, observadores a postos, trackers alinhados sobre o que deve ser medido, iniciemos o trabalho, que se realizará em ciclos de 4 minutos. Correndo o primeiro ciclo (ou sprint, iteração, o que você achar melhor) algumas disfunções já são visíveis. A primeira é que o processo está desbalanceado, com etapas muito simples e outras muito complexas. Isso visivelmente vai gerar gargalos, mas não podemos chegar no processo final ainda, então muita disciplina é necessária nesse momento. Outra observação que se pode fazer é que existem pessoas que tem mais afinidade com algumas atividades, outras com outras e ainda temos aquelas que não se adaptam a trabalhos manuais. Normal, não somos todos iguais e as diferenças, quando assumidas, devem ser respeitadas.

O ideal é executar o ciclo de desenvolvimento umas 7 vezes aproximadamente, dando sempre um tempo entre os ciclos para que as pessoas parem, reflitam e implementem modificações. Ao final, muitas equipes foram capazes de compreender aonde estão os seus gargalos e agir para tratá-lo. Já outras colocaram mais e mais recursos da platéia na equipe até perceberem que essa era uma das piores soluções. A seguir alguns dos gráficos gerados por essas equipes. Neles os gargalos ficam muito claros a partir de um tempo. Algumas equipes souberam lidar com seus problemas em tempo, outras precisaram de ajuda, ainda houveram outras em que nem com ajuda o tempo foi suficiente para resolver.

Uma coisa que pode se fazer para lembrar o quanto trabalho em progresso é ruim é, no meio do processo, lá pelo 4º ou 5º ciclo, avisar que o mercado mudou e não se interessa mais por pássaros, mas sim por aviões de papel. Isso fica especialmente evidente caso a equipe não tenha se preocupado em limitar o WIP (Work in progress) pois todo os itens começados e não acabados agora terão de ser ou jogados fora ou vendidos à preço de banana. De qualquer forma, sua produção teve um prejuízo.

Seguem alguns gráficos de equipes que realizaram esse workshop.

cfd01

cfd02

cfd03

dispersao03

dispersao05

dispersao01

Essa obviamente é uma descrição bem superficial, ao final ainda conversamos sobre teoria das restrições, como promover mudanças e outras observações que o público apontar.

O importante é que no final, todos perceberam a importância de observar o sistema como um todo, de tratar os gargalos de seu processo produtivo, como medir de maneira justa e ainda como a limitação de trabalho em progresso pode ser uma ótima opção para tudo isso.

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.