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.

A sabedoria de Musashi

640px-Musashi_ts_pic
Estamos no Japão feudal, um tempo e local onde as pessoas buscavam fazer aquilo que lhes era atribuído buscando a máxima perfeição, tanto nos seus modos como em seus resultados. Muita coisa podemos aprender de lá. Nesse época, vivia por lá um homem chamado Miyamoto Musashi. Ele era um samurai.
Dentre diversos ensinamentos que esse sábio nos deixou, muitos podem ser aplicados a coisas do nosso cotidiano, inclusive, por que não, no desenvolvimento de equipes e pessoas de alto desempenho. Vou citar alguns aqui, extraídos do livro “Os cinco anéis”.

“There is nothing outside of yourself that can ever enable you to get better, stronger, richer, quicker, or smarter. Everything is within. Everything exists. Seek nothing outside of yourself.”

O paralelo que podemos fazer desse ensinamento seria que muitas vezes, pessoas, organizações, equipes buscam soluções mirabolantes e demandam que pessoas externas àquele grupo venham para lhe dizer obviedades. Ouça seu time, faça retrospectivas, sessões de brainstorming, a solução para seus problemas pode estar escondida dentro daquele cara mais tímido da sua equipe.

“Do nothing that is of no use”

Evite o desperdício. Desperdício em todas as suas formas. Mapeie o sua cadeie de valor e encontro as etapas em seu trabalho que realmente agregam valor ao seu processo produtivo. Reuniões inúteis, estoques sem propósito, processo sobrecarregados, defeitos, tudo isso é desperdício e deve ser evitado.

“You can only fight the way you practice”

Ou no português claro e atual, cada um no seu quadrado. É impossível para alguém opinar com propriedade sobre algo que não conhece ou mesmo que conhece apenas superficialmente. Só é possível dar testemunho (novamente, com propriedade) de algo que se viveu. Se me propor a falar sobre as experiências de outros certamente soará falso e minha credibilidade se porá a perder. É importante entendermos que um time deve ter dentro de si todas as habilidades necessárias para completar suas tarefas. Veja bem, o time, não o indivíduo. Aceitar que existem áreas de conhecimento que fogem ao meu domínio me permite aprender mais sobre elas e evitar problemas.

“To know ten thousand things, know one well”

Hoje muitas pessoas se gabam de seu conhecimento horizontal, conhecer muitas coisas mas todas de maneira superficial. Isso leva a diversas coisas das mais bizarras como um consultor, que foi treinado por uma consultoria, não fez cursos, não participou de eventos ou coisa semelhante e muito menos participa da comunidade para poder debater suas idéias. Tal “profissional” afirma coisas como que o papel do ScrumMaster deve ser rotativo, sendo trocado o papel entre os membros do time. Esse, entre outros absurdos, são apregoados por profissionais rasos, que não buscam aprofundar o conhecimento em nada e dizem conhecer tudo que há para se conhecer. Caso você queira ser um profissional com alto conhecimento horizontal isso não é negativo. Mas é importante que antes de se tornar um generalista, seja especialista em pelo menos uma! Escolha uma área que você realmente gosta e aprenda essa pra valer! Depois vá e amplie seus conhecimentos, mas não sem antes ser reconhecidamente um especialista em alguma área.

“You must understand that there is more than one path to the top of the mountain”

Não negue as outras linhas de pensamento. Já vi isso dezenas, se não centena de vezes. O cara aprende Java e começa a descer o pau em .NET, aprende Kanban e começa a malhar em Scrum. Acontece todo o momento, muito, por medo dos profissionais. Muitos profissionais, por medo da contestação partem para o ataque e começam a detonar os outros métodos. Como eu sempre digo, não é porque você descobriu o martelo que agora tudo se tornou prego.

Assim meus amigos, nem preciso o quanto sabedoria pode vir de onde se menos espera e quanto isso é aplicável em nosso cotidiano, especialmente num mundo tão “dogmático” como esse de gestão ágil de projetos.

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: