Month: julho 2014

A sabedoria de Musashi

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.