O Agile Day 2010 POA, começou oficialmente as 09:00h, com o Daniel Wildt que apresentou a idéia do evento e seu formato com aquele entusiasmo agilista que sempre vemos nele! Para este ano foram 114 inscritos e 1 palestrante faltante, o André Nascimento não foi. Logo em seguida o Klaus foi apresentado e começou um dos keynotes planejados para o dia.
A palestra iniciou-se às 09:20h com o Klaus questionando quais dos congressistas efetivamente trabalhavam com desenvolvimento de software, e destes quais já haviam colocado software em produção! Ele disse que estes eram os caras que ele respeitava.
Logo em seguida o Klaus começou a apresentar um pouco da sua historia, desde a casa dos amigos com o código do caça-níquel, escapando de métodos formais após a ida ao evento XP na Itália em 2000 e passando pelo plug-in Byecycle – fractal feito com o Kent beck em uma semana até o dia de hoje e o agile day e o dilema a ser tratado nesta palestra… Como e até quanto ponderar qualidade de um projeto mediante o pedido imediatista de urgencia de seu P.O.. pois se temos duas variáveis e teoricamente só podemos aumentar uma, diminuindo a outra…
Sem demora o Klaus atirou uma pergunta aos congressistas, quais de nós tinha ou conseguia discernir a qualidade dos seus códigos ou dos demais no dia-a-dia e quais de nós priorizavam um dos dois fatores temas da discussão mais que o outro… Poucos priorizam qualidade, muitos o prazo e um pouco menos em um bom equilíbrio entre ambos!
Logo em seguida impulsionada pelas respostas e fazendo referencia com a natureza fractal dos códigos o Klaus iniciou os trabalhos em exemplos para mostrar a similaridade inconsciente sobre as avaliações qualitativas! Fizemos algumas alterações e por coincidência chegamos em um método mais simples e coletivamente reflexivo como de maior qualidade. Em seguida realizamos uma segunda refatoração, que foi de imediato verificada a não necessidade de todo o método por alguns de nós, mas que calmamente o Klaus nós conduziu em baby steps em toda a refatoração até esta eliminação.
Dentro deste método existia um comentário um pouco inapropriado //METRO DE SAO PAULO, que só foi removido em um dos 5 baby steps sobre gargalhadas. Então o Klaus relatou os níveis de limpeza do metrô de são Paulo mediante a quantidade de passageiros transportados diariamente e nos mostrou um método inconsciente de manter a limpeza de códigos fazendo! Um código limpo de 4 linhas, assim como o metrô, subconscientemente induz o cidadão a pensar duas vezes o lugar que este irá sujar com mais duas linhas criadas de forma não pensada ou elaborada.
Em seguida tivemos questionamentos sobre qual a claridade de nossos códigos, de 0 100%, no qual, segundo o Klaus, 0% são códigos escritos por mil macacos e 100% como algo impecável, onde nada precisa ser mudado. A maior quantidade dos congressistas definiram entre 50 e 70% e pouquíssimas acima disto!
Segundo o Klaus uma equipe de formula 1 tem entre 98% e 99% de qualidade, assim como cozinhas profissionais tem limpeza suficiente para se lamber um balcão. Por um pensamento imediatista e impensado, temos que as atividades realizadas por estas equipes poderiam ter sido feitas da forma aparentemente mais produtiva caso estas não se preocupassem tanto com a qualidade, fazer jantares sem “gastar tempo lavando louça” ou “pegando e guardando ferramentas”. Estudos provam que em longo prazo isto atrasa o processo e demanda muito mais tempo e esforço. Segundo o Klaus a preocupação com a qualidade pode ser momentaneamente aliviada mas nunca deve ser abandonada ou fortemente acumulada!
Foi apresentando em seguida um gráfico de produtividade de equipes de TI, no qual se tornou visível a semelhança comportamental em desempenho de equipes despreocupadas com débito técnico ao longo do tempo. Existirá sempre a dificuldade de realizar algumas tarefas citadas quando não estamos trabalhando com a qualidade suficiente.
O dilema não é prazo vs qualidade e sim produtividade hoje e produtividade sempre. Com qualidade para o Klaus beirando os 98% a equipe chega a sua máxima de produtividade!
Os congressistas estão bem longe disto, existem fatores, explicações e outras desculpas para isso, foram apresentadas a falta de capacidade para avaliação se esta ruim, não se vê a importância disto. overdesign e visão de curto prazo do negocio, como algumas delas.
Para o Klaus muita da sujeira em código esta ligada a dificuldade em se ver, diariamente e de forma simples, o código e sua dependências; uma falha é mais fácil de ver quando tudo está mais simples!
Por fim devemos nos preocupar com padrões e boas práticas técnicas ao invés de nos digladiarmos em dilemas como qualidade e prazo, com toda certeza qualidade sempre para que o prazo seja sempre mais real e a produtividade maior.
Klaus terminou sua palestra com um ditado do GO, “perca suas primeiras cem partidas a mais rápido possível”.
Navegação da Série
- Anterior: Anúncio - Prévia do Agile Day 2010
- Atual: Parte 1 - Klaus Wuestefeld sobre Qualidade vs. Velocidade
- Próximo: Parte 2 - Luiz Faias Jr. sobre Construindo uma Cultura de Aprendizagem
- Série completa: Série Agile Day 2010