Vídeos Agile Tour 2013 – Maringá

logo Agile Tour 2013

Demorou mas saiu finalmente. Estive procrastinando isso pois estava tentando conseguir um tempo para editar, colocar uma vinheta, coisas assim.
Aconteceu que já estamos quase fazendo a edição desse ano e nada dos vídeos, então resolvi que vai como está. Portanto, material sem edição, bruto mesmo.
Perdoem as tremidas e imagens desfocadas, ainda não conhecia bem a câmera e nem sempre era eu filmando.
Continue reading

Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.

Quando os rótulos não atendem às suas necessidades

ler-rotuloAntes de começar esse artigo, eu preciso esclarecer. Eu não pretendo que esse seja o compêndio definitivo tal qual um comparativo entre os principais métodos (ou frameworks, ou práticas) ágeis disponíveis hoje. Nem tampouco quer determinar se existe uma resposta definitiva para as suas preces em decidir qual é a melhor, ou ainda, qual dessas visões está correta. O objetivo aqui é mostrar o quanto queremos adaptar as soluções às nossas realidades, políticas e culturas, sem ao menos entender o porque de cada uma das propostas.
Continue reading

DevCamp – Os desafios da entrega contínua – Atualizado

Amanhã (16/maio) estarei em Campinas, no DevCamp apresentando minha palestra sobre entregas contínuas. É uma das minhas palestras que fala do lado técnico do desenvolvedor ágil, mas sem deixar os não desenvolvedores boiando. Eu tive a oportunidade de apresentar uma prévia dela ano passado no TDC de Floripa, mas agora com mais tempo vai ficar muito mais tranquilo explorar esse tema.

A sessão começa às 13:30, logo após o almoço. Não vão se atrasar. A grade completa do evento você encontra no seu site.


Atualizado em: 3 de junho de 2014

Como esperado, o evento foi ótimo, meus mais sinceros parabéns aos organizadores.
Seguem os slides da palestra, como de costume:


Agile Trends 2014 – foi show!

agile_trends_02 agile_trends_01 agile_trends_03Esse post nem é muito informativo. É um post para falar de um evento que foi muito bom, show de bola mesmo, por falta de adjetivo melhor para descrever. Vi várias talks muito boas, com gente de altíssimo nível. Outra coisa que chamou muito a atenção foi o nível das perguntas e o engajamento não só de quem foi como talker, mas para quem foi participar. Excelentes questões, elevando em muito a discussão. Adorei o formato, virei fã.

É claro, rever os amigos, fazer novos, tomar uma geladinha e ter altos papos pós evento ajuda em muito para fixar essa imagem de evento que vale muito ser lembrado.

Parabéns aos organizadores, nem vou citar um só para não ser injusto.

Nos vemos de novo no Agile Brazil.

Algumas fotos do evento no facebook

Agile Trends 2014

agile_trends_2014
Muito feliz porque em algumas horas parto para São Paulo para participar do Agile Trends.
Serão dois dias de ótimas discussões em altíssimo com a nata da agilidade. A minha conversa está programada para na quinta-feira, às 12:30, onde divido o palco com Glaucia Peres, da Globo.com. Para conferir a programação toda, acesse esse link.
Nem preciso dizer o quanto estou honrado pelo convite (obrigado Alex, Dairton e Tiago) e estou certo de que teremos uma excelente sessão.

Quem quiser saber mais corre lá no site do evento e acho que ainda dá tempo de se inscrever.