Agile

Quem lembra de acessibilidade?

Anos atrás eu estava em um evento sobre Design para Web (sim, eu já fiz de tudo um pouco) e assistindo um dos renomados palestrantes que lá falavam. No momento das perguntas alguém questionou se a acessibilidade começaria a então entrar firme no desenvolvimento de sites. O exemplo do palestrante foi fantástico:

O buffet hoje servido no café estava excelente, cheio de petiscos e doces deliciosos. O problema é que eu não podia comer. Sou diabético. E muito provavelmente não havia nenhum diabético no buffet, pois isso não foi uma preocupação para aqueles que fizeram o buffet. Não que as pessoas que escolheram o cardápio sejam pessoas ruins, apenas não se deram conta de que haviam pessoas com necessidades especiais, provavelmente por nunca ter experimentado isso. As pessoas se tocam das necessidades dos outros quando sentem compaixão ou na própria pele essas necessidades.

Esse palestrante, do alto de sua sabedoria não poderia estar mais certo. Eu já me preocupava com questões desse tipo nos eventos que organizo pelos anos em que vivi com minha avó, que tinha algumas dificuldades de locomoção. Mas era algo superficial, não era uma preocupação forte, mas algo que se houvesse como, faria algo para melhorar a vida desses caras. Porém, esse ano tive uma experiência mais profunda.

No começo do ano, tive uma torção média no pé, repetindo a mesma torção (igualzinha, sem tirar nem por) meses depois, dessa vez com bastante seriedade. Por essa razão andei de muletas por várias semanas, seguidas de outras tantas com bengala. Só então pude perceber detalhes, que antes passavam desapercebidos. Notei o quanto é difícil para alguém com dificuldades de locomoção uma calçada irregular. O quanto é difícil descer de degraus fora do padrão. Entre outras coisinhas que fui aprendendo pelo caminho.

Se você está pensando “o que eu tenho a ver com isso?” ou ainda “ótimo para você parceiro, mas em que isso muda a minha vida?” eu posso ajudar a esclarecer. Sendo você desenvolvedor (e aqui eu abranjo todos que desenvolvem uma solução para um cliente, independente de programadores, testers, analistas…) passa os seus dias dentro de um escritório recebendo papéis e devolvendo soluções, você está fazendo isso errado. Você precisa viver a vida do seu cliente! Você precisa conhecer as suas dores de perto, ver os problemas acontecendo, sentir onde o calo aperta no sapato para saber como corrigir. Só assim você vai ter uma visão plena e realista daquilo que realmente resolve os problemas do seu cliente.

Para ficar mais claro ainda, deixo um pequeno bom exemplo, onde o pessoal levou isso ao extremo, vivendo as dores e pensando em soluções para isso.

A necessidade da visão externa

Fico feliz quando visito algum cliente, novo ou antigo, e encontro um ambiente no qual eu invejo.

Experiências centradas no usuário, foco nas pessoas, alta capacidade técnica são só algumas características que vejo por aí nessa galera.

Por isso sempre me causa espanto por que eles precisam de mim ou de meus colegas. Está tudo ali, todas as ferramentas necessárias para melhorar aquele ambiente. Até mesmo a vontade de fazê-lo está presente. Mas ainda assim, precisam de alguém que lhes aponte a direção certa.

O meu palpite é que nós estamos tão imersos em nossos problemas do dia-a-dia que não deixamos um tempo para melhorias. Mesmo times com bons conhecimentos de agilidade esquecem de deixar um tempo para se melhorar, se aprimorar. É a eterna luta para continuar cortando árvores e nunca amolar o machado.

Eficácia versus eficiência.

Bom, tem muito assunto aí. Numa próxima oportunidade falaremos mais sobre isso.

Como avaliar a agilidade da sua empresa?

Essa semana meus colegas e eu entregamos mais um trabalho de assessment ágil em uma grande empresa em SP. Foi muito interessante como sempre poder olhar para um outro ambiente diferente do seu, sem as paixões do dia a dia no intuito de ajudar outro a não cometer os mesmos erros que você já fez. Esses momentos sempre me fazem pensar em coisas que vi e coisas que vivi. Vou comentar algumas nesse texto.

Ah, como é bom fazer esse tipo de trabalho! Você se torna um avaliador, passando para aquela empresa contratada a sua visão sobre o seu processo atual. O quão legal é isso? É fantástico! Afinal é sempre mais legal ajudar os outros a resolver os seus problemas do que resolver os seus próprios. O modelo de avaliação que usamos eu criei baseado em outros que vi por aí, juntando um pouco de cada um que vi, colocando um pouco de meu próprio estilo e passando para o resto do time ágil validar. Considero um bom modelo, pois avalia quatro aspectos que considero importante para uma empresa possa ser considerada ágil: cultura, organização, técnica e negócio. O número quatro não é a toa e tem forte influência do manifesto ágil e como a empresa endereça cada um dos quatro valores ali presentes. Em textos futuros pretendo escrever um pouco mais sobre cada aspecto.

Um diferencial que a Objective tem sobre as demais empresas do mercado parece até meio contraditório porém depois que eu conto a história toda passa a fazer sentido. Não somos uma empresa de consultoria. Ou ao menos não éramos. A empresa nasceu como desenvolvimento e assim se mantém até hoje. Porém temos resolvido muita coisa, tivemos muitas dores no caminho é isso nos tornou mais fortes. Contando essas histórias de guerrilhas para os amigos, esses nos pediram para contar mais e então passamos a palestrar. As palestras nos aproximaram de pessoas que queriam saber de como resolvemos nossos problemas e então passamos a oferecer-lhes consultorias e assessments. Veja, todo esse empirismo não quer dizer que não estudamos e não buscamos conhecimentos de fontes externas. Muito pelo contrário. Estamos buscando conhecimento a todo tempo, lendo livros, blogs, conversando com outras referências e participando ativamente de eventos. Nós mantemos em constante evolução e gostamos disso. Porém, somos desenvolvedores como a maioria de vocês (eu particularmente trabalho com iOS) e compreendemos os problemas que vocês passam pois passamos por eles também em algum ponto da estrada. O Agile que falo não é algo que simplesmente li num livro ou vi numa palestra, mas sim algo que vivi e vivo a todo tempo, é como solucionei os meus problemas e como sanamos nossas dores. Enfim, falar de agilidade é um enorme prazer, contar meus casos é algo que realmente me fascina. Ser pago para isso é melhor ainda.

O processo de assessment é relativamente simples. Vamos até a empresa, conversamos com pessoas chaves no processo, observamos algumas evidências é baseado no que vimos e ouvimos redigimos um relatório mostrando os principais pontos de alavancagem, aqueles que com o menor esforço geram o maior resultado. Isso é extremamente pessoal e depende da avaliação de cada agilista. Tento ser imparcial e para isso sempre busco um par que me complete nesse trabalho. Minha visão pessoal busca sempre aspectos culturais e de negócio, por isso preciso de alguém técnico para me ajudar. Esse meu par tem o trabalho de olhar para onde eu não olhei, fazer as perguntas que eu não fiz, olhar os aspectos que eu deixei passar. É belo ver que o mesmo princípio do pair programming são aplicáveis aqui também. Já escrevi algo sobre isso por aqui, recomendo a leitura.

Após essa avaliação inicial vamos até a empresa e de posse do relatório, explicamos ponto a ponto da nossa visão sobre o processo para os membros da equipe e discutimos as diferenças de visão. Expomos então um plano de ação que consideramos ser o mais interessante. Esse é um aspecto que julgo ser um dos mais legais. Normalmente, quem trabalha com consultoria já faz isso como parte do processo. Você não chega numa empresa e joga um modelo pronto. Você avalia os pontos em busca da onde se pode atuar. A diferença é que numa consultoria isso funciona como uma venda casada, você coloca essas horas dentro do seu trabalho de consultor e as vende num pacote só. Gosto mais de como fazemos porque se você se sentir capaz de implementar essas melhorias propostas vá em frente! Se sentir que precisa de ajuda com alguma delas estamos aqui de qualquer forma. Nem precisa nos contratar para ajudar em todas, somente para os aspectos que sentirem que precisam de apoio. Isso sai muito mais barato para o cliente e logo estamos livres para pegar um próximo projeto e aprender e ensinar mais em um novo contexto.

Você pode estar pensando nesse momento que serviços assim devem ser caros e contratar profissionais de uma empresa de consultoria pode ser um passo grande em direção à melhoria contínua portanto, podemos deixar para depois. A parte legal é que caso queira começar com um modelo mais simplificado e auto aplicável o meu amigo Klaus Wuestefeld escreveu um template chamado os 9 registros da agilidade. Nesse trabalho, disponível aqui, você encontra uma planilha para compartilhar com sua equipe e tem 9 aspectos que vocês devem dar notas entre 1 e 5, dependendo de como a equipe se avalia. É importante que se visualize o modelo como sendo um grande cano é que os nove registros estão ao longo desse cano. Com esse modelo em mente pode se ter certeza que a vazão desse cano se limita pelo registro que está mais fechado. Assim se em vários aspectos a sua nota for 4, mas em colaboração por exemplo a sua nota for 1, então a nota final do seu processo é 1. O seu sistema se limita pelo elo mais fraco e esse é o ponto de alavancagem, pois ele desobstrui o seu sistema para crescer.

Querendo conversar sobre avaliações de sua equipe ou querendo conhecer um pouco mais sobre os modelos da torneira, me procure que terei o maior prazer em explicar.

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.

Como classificar a agilidade?

Certa vez um programador de uma equipe que eu estava treinando me perguntou “O que é ser ágil?”. Eu fiquei surpreso que depois de tanto tempo pensando dessa forma eu ainda não sabia como descrever a minha maneira de pensar em poucas palavras. Aqueles segundos correram bem longos na minha cabeça quando finalmente me veio a resposta que eu costumo dar em eventos e palestras. É buscar a excelência no seu campo de domínio, o desenvolvimento de software. Mas isso acendeu uma luz em minha cabeça que precisava de atenção. Foi então que percebi que esse ponto precisava ser melhor trabalhado.

Eu costumava dividir os aspectos da agilidade em dois somente. Existem ferramentas muito ricas para a área de gestão. Gestão de projetos, de processos, de métricas, de fluxo de atividades. Não vou nominar para não ser injusto com nenhum, além do que nem é o meu objetivo aqui. Existem outras que são para o trabalho do desenvolvedor, que eu chamo de arquitetura. Ali temos especialmente as práticas do Extreme programming, a entrega contínua só para citar algumas. Resumindo, no meu entender haviam apenas duas grandes áreas, gestão e arquitetura. Isso atendia bem minhas necessidades e me ajudou a fracionar aquela resposta. Assim, se depois dessa divisão na minha cabeça alguém me perguntasse novamente sobre o que é agilidade eu diria que existem a agilidade para a gestão, que é a melhoria dos processos, reduzindo o tempo de feedback e aprendizado sobre o produto da empresa e existe também a agilidade para desenvolvimento que seriam o conjunto de práticas e ferramentas que usamos para nos permitir atender essa necessidade da gestão.

A parte legal é que sendo ágil, eu posso até criar uma definição que me atende hoje, mas se aprender uma melhor eu não preciso me apegar na minha ideia original. Posso usar a nova com seus devidos créditos, obviamente. Eu vi isso acontecer bem recente no Gathering do Rio de 2015. Participando da sessão de ScrumMaster 3.0 do Rodrigo de Toledo (o cara!) vi que ele, junto com seus amigos/sócios criou uma classificação de Agile em quatro grandes áreas. Isso é certo ou errado? Não sei, mas faz sentido em seu contexto e provalvemente tem funcionado para ele desde então e pode ser que também funcione para você. Basta que você experimente e valide a ideia em seu contexto.

O segredo da agilidade é o seu pensamento. Pensando de maneira ágil e evoluindo esse pensamento conseguiremos chegar à um novo patamar e quem sabe até a um novo pensamento que substitua o ágil. Domine o pensamento ágil a ponto de, um dia, poder criar o seu próprio modelo que atenda as necessidades, sem perder os valores iniciais.