Saga do programador

O Evento

Crédito: agilebrazil.com

Eu tenho frequentado eventos sobre agilidade desde 2007, participando de pelo menos dois eventos por ano. O último que participei foi o Agile Brazil 2010 ocorrido em Porto Alegre. Apesar deste ter sido um evento excelente, confesso que este ano não estava com a mesma empolgação para encarar mais um evento sobre agilidade, pois achava que seria “mais do mesmo”. Entretanto, como os organizadores são bom agilistas, não esqueceram de um dos valores mais importantes de qualquer metodologia ágil: melhoria contínua.

O evento deste ano ocorreu na maravilhosa Fortaleza de 27/06 à 01/07.  Como no ano passado, os dois primeiros dias foram reservados a cursos. As palestras começaram no dia 29/06. O evento ofereceu 3 keynotes sensacionais (um em cada dia), diversas palestras, workshops, tutoriais, lightning talks e alguns open spaces. Houve mais expositores nesta edição. Destaque para os stands da ThoughtWorks e da Microsoft. O kinect foi a sensação em diversos stands. Senti falta apenas de stands com venda de livros.

Crédito: twitter.com/cghenriques

A estrutura do evento estava ótima. Bom coffee-break, spots para notebooks, uma “mini-central” de atendimento, achados e perdidos, etc. A organização registrava regularmente informações úteis e novidades via Twitter . Único ponto negativo ficou por conta dos dois stands maiores que ficaram bem no centro do salão principal dificultando, e muito, a circulação dos participantes. As salas das palestras eram ótimas. Todo palestrante tinha uma espécie de auxiliar para resolver eventuais problemas técnicos. Achei bastante interessante, não lembro de ter visto algo semelhante no evento de 2010.

Sem dúvida, a novidade que mais gostei foi a introdução de Lightning Talks (LT). LT é uma sessão divida em curtas apresentações de diversos temas. No Agile Brazil 2011, as sessões tinham mais ou menos 5 apresentações de 10 minutos. Em uma palestra tradicional, se esta não atender sua expectativa, você acaba perdendo aquele tempo. Tudo bem que você pode sair da palestra que não está gostando e ir para outra, mas não é bacana porque você acaba perdendo parte da palestra que entrou depois. Em um mesmo LT não existe, necessariamente, conexão entre os assuntos. Além disso, geralmente cada apresentação é feita por um palestrante diferente. Com isso, dificilmente você terá a sensação de tempo perdido em um LT. Além disso, em um evento como este, o que busco são pequenos insights para aplicar no meu dia-a-dia ou, então, saber como as pessoas resolvem um determinado problema. Não tenho a pretensão de sair de uma palestra dominando um tema. Neste contexto, penso que os LTs são mais eficientes. Então, a programação deveria ser composta apenas de LTs ? Não! Alguns assuntos merecem mais do que 10 minutos, porém poderia-se ter mais LTs o quê permitiria uma seleção melhor das palestras.

O que não gostei muito foi o excesso de palestras sobre TDD. Apesar deste ser um dos assuntos que mais aprecio, penso que deveria-se ter dado mais espaço a outros temas, até porque das 3 palestras que eu fui, duas estavam bem fracas. Por outro lado, não é de todo ruim, visto que TDD é essencial neste modelo de desenvolvimento de software e aqui no Brasil ainda existem dúvidas e muita resistência a este paradigma de programação.

Este post será dividido em três partes. Nesta primeira parte, falarei sobre os keynotes. Na segunda parte, abordarei as palestras e os lightning talks que assisti. Na terceira, e última parte, compartilharei minhas conclusões e sugestões para próxima edição.

Keynotes

Jim Highsmith

Ele é colaborador da Thought Works e possui diversos livros publicados. É também um dos autores do Manifesto Ágil e co-fundador da Agile Alliance. Trazer um nome desse peso dá bastante credibilidade ao evento. Jim baseou-se em um estudo da IBM que revelou que 80% dos executivos desejam que seu ambiente cresça consideravelmente mais complexo, mas menos da metade sabe como lidar com isso. Outro número importante apresentado por Jim, foi o de que organizações ágeis conseguem ganhos 30% maiores por ação do que empresas não-ágeis . Neste momento, os executivos presentes no local devem ter aberto um sorriso de orelha a orelha e eu me lamentando pelos executivos da empresa na qual trabalho não estarem lá. Entretanto, para atingir tal feito não basta tornar ágil apenas a área de desenvolvimento da organização. É necessário que toda a companhia esteja alinhada com os valores ágeis. Se pararmos para pensar isso faz todo o sentido. O principal objetivo de qualquer método ágil é responder o mais rápido possível às mudanças. Uma vez que as mudanças são motivadas pelo ambiente externo (riscos positivos, tendências de mercado, etc.), não faz sentido que os setores estratégicos da empresa não estejam alinhados com este pensamento. Para promover a agilidade além da área de desenvolvimento, Jim apresentou o conceito de liderança adaptável que nada mais é que “implementar” os valores ágeis na esfera do negócio. Ele chamou este processo de agilidade estratégica. Ao meu ver o “climáx” da apresentação de Jim foi quando ele colocou o seguinte gráfico:

Crédito: twitter.com/luty81

Em suma, o que esse gráfico diz é que o débito técnico aumenta o custo de mudança, este por sua vez afeta negativamente a velocidade de entrega (do produto) que se reflete em uma diminuição da capacidade de resposta de uma empresa (a seus clientes). Em outras palavras, o débito técnico diminui a agilidade da empresa. Percebam o poder destas informações. Nós conhecemos uma poderosa arma  para conter o crescimento do débito técnico: refactoring. Por mais que tenhamos boa cobertura de código e mesmo usando os melhores padrões de design, sem refactoring constante o débito técnico vai crescer, isto é fato. Como costumo dizer, código é como um jardim: mesmo usando uma boa terra com os melhores fertilizantes, se não regarmos todo dia, o jardim resistirá. Este gráfico, é um ótimo argumento para convencermos gestores e os executivos de nossas as empresas de que devemos colocar o pé no freio na hora de empurrar toneladas de novas funcionalidades em nosso produto (muitas vezes inúteis como veremos no keynote do Joshua logo adiante) . Em vez disso, devemos priorizar a “ordem na casa”. É o que Jim chamou de “Do Less” (faça menos) que na visão dele é um dos quatro elementos-chave da dimensão “Do Agile” da liderança adaptativa. Entretanto, estas informações não servem apenas para nossos executivos. Ela também deve ser usada por nós desenvolvedores para refletirmos a cerca do que andamos fazendo por aí. Antes de lançarmos aquele bacalhau “inofensivo” no código e sempre que negligenciarmos o refactoring, estamos assumindo que iremos diminuir a capacidade de resposta da empresa. Em outras palavras, estamos “assinando um contrato” onde concordamos que reagiremos mais lentos às mudanças externas e seremos menos ágeis em atender as novas necessidades de nossos clientes.

Crédito: twitter.com/cghenriques

Joshua Kerievsky

Crédito: twitter.com/cghenriques

Autor do livro “Refactoring to Patterns” e dono da Industrial Logic, uma empresa que vende treinamentos sob o formato e-Learning, Joshua parecia mesmo obstinado a cativar o público brasileiro: iniciou a palestra com um “Bom dia” com aquele sotaque gringo e depois falou alguma coisa que não entendi, mas que tinha a palavra “caipirinha” no meio, arrancando risos da plateira . A palestra de Joshua foi baseada na felicidade. Segundo ele, devemos focar nosso trabalho priorizando a felicidade, mas não apenas de quem desenvolve o produto, e sim de todos os indivíduos envolvidos no processo de desenvolvimento e entrega do software. Em última instância, estes indíviduos são representados pelos nossos clientes ou usuários do produto. Para mostrar como tornar seus clientes mais felizes, Joshua citou alguns valores do pensamento Lean e trouxe um número já conhecido por nós: mais de 60% de todas as funcionalidades da maioria dos softwares nunca foram utilizadas. Então, para fazer nosso cliente mais feliz, precisamos descobrir que funcionalidades ele espera ou deseja que o software possua. Para fazer isto, Joshua usou o conceito de “Fake Feature”.

Crédito: twitter.com/cghenriques

Ele e seu time colocaram na interface gráfica de seu produto, botões e links que representariam uma funcionalidade hipotética. Entretanto, quando o usuário tentava utilizá-la, o sistema informava que aquela funcionalidade não estava disponível e, em seguida, questionava se o usuário gostaria de ter essa funcionalidade no sistema. Joshua não entrou no mérito de como ele usou essas informações coletadas. Entretanto, é bem fácil imaginar que esse dado poderia compor (ou até mesmo representar por completo) o business value das user stories de um produto, permitindo assim, uma priorização mais eficiente do product backlog. Em linhas gerais, a mensagem que Joshsua tentou nos passar é que pessoas mais felizes trazem mais resultados para empresa. Um membro do time mais feliz vai produzir com mais qualidade, e um cliente mais feliz vai, não apenas comprar mais, mas colaborar com o desenvolvimento do produto (com sugestões, feedbacks, etc).

Crédito: twitter.com/cghenriques

Uma prova de que ele realmente se preocupa com isso, ele pediu para traduzir sua apresentação para Português! Toda sua apresentação, exceto as imagens, estavam em nosso idioma. Além disso, ele participou de um open space que irei falar mais na segunda parte deste post.

Vinicius Teles

O keynote do Vinícius pode ser resumido em um choque de realidade carregado de bom humor, como de praxe. Ele iniciou citando aquela “profecia” de que o mundo acabará em 2012. Mas, segundo ele, não será um cometa ou coisa parecida que detonará a Terra, mas sim uma grande tela azul. Para mostrar isso, Vinícius coletou alguns depoimentos em vídeo durante o próprio evento. Os depoimentos eram experiências de participantes do evento ao utilizarem sistemas on-line de empresas grandes empresas públicas, bancos e de telecomunicações. De problemas de usabilidade, passando por bugs, até questões sobre performance, Vinícius nos mostrou o quanto um software defeituoso atrasa nossa vida.

Crédito: twitter.com/cghenriques

De acordo com ele, só existe um culpado por isso: nós desenvolvedores. Em outras palavras, ele mostrou como nós, às vezes, atrasamos o mundo. Esse foi o choque de realidade da apresentação. É muito legal quando alguém influente na comunidade menciona algo que reflete o que você pensa. Vinícius falou de uma coisa que já conversei com alguns colegas de profissão: Temos que parar! Parar no sentido de querer absorver toda novidade (tecnologia, linguagens e etc) que aparece pela frente. Às vezes, nós parecemos poodle de apartamento quando vai à rua: corri para todo o lado, mas sem objetivo nenhum. De nada adianta aprender a linguagem do momento, se a gente continua entregando software de péssima qualidade. Faz muito mais sentido revermos como estamos desenvolvendo software do que aprender uma nova tecnologia. Outro momento marcante e polêmico do keynote foi um slide com a seguinte frase: “Talking is cheap. Show me the code.”.  Muitas pessoas levaram para um lado de que tudo o que importa é o código e resto que “se exploda”. Vi algumas pessoas postando no twitter que outras áreas também são importantes, outras falando que não apenas o código é importante, que a interface gráfica, por exemplo, tem importância também e coisas do gênero. Eu acho que não foi essa a mensagem que o Vinícius tentou passar. Antes de mostrar este “polêmico” slide, ele estava questionando as certificações. Mostrou o perfil de vários desenvolvedores sem certificação que são reconhecidos, pela nossa comunidade, como excelentes programadores . Ele também fez a seguinte indagação: “Quem te certifica desenvolve software?”. Quem assina seu certificado, sabe o que é programação? Logo em seguida, ele mostrou o slide em questão. Ao meu ver, ele quis passar a mensagem de que certificados não possuem tanto valor, uma vez que não é possível transformar papel (certificado) em código. Por exemplo, é como se ele dissesse: “Em vez de você falar que é certificado em Java, mostre o código Java que você é capaz de desenvolver.”. Se eu não me engano ele comentou em seguida que só código importa, mas isso foi somente em relação a certificação ao meu entender. Em outras palavras, não me diga o que você sabe e nem os certificados que possui, mostre o código que você é capaz de escrever. Pelo menos, essa foi a forma que eu entendi.

Aguardem a segunda parte onde irei falar sobre as palestras e os lightning talks que assisti.

Tags: AGILE, Kaban, LEAN, SCRUM, tdd

This entry was posted on Monday, July 4th, 2011 at 16:38 and is filed under Continuous Delivery, Continuous Inspection, Kaban, Metodologia, SCRUM, tdd, testes. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.