Viagens, opiniões e afins

No post que anterior, no qual falei sobre TDD, recebi um comentário perguntando dentro de algumas situações se O TDD se encaixava ou não.  Como a dúvida é recorrente e o tema é bastante controverso, resolvi, ao invés de responder o comentário dele, escrever um post.

A primeira coisa, em minha opinião, que tem que ficar clara, que TDD é um metodologia de desenvolvimento e não de projeto. Usamos TDD para gerar código melhor e com isso aumentar a qualidade do que estamos fazendo.  Testar antes não é garantia de zero bugs, mas ajuda a construir uma solução melhor pensada, simples, concisa,  e, sim, com testes automatizados que irão evitar muitos bugs.

TDD é uma forma de trabalho que se encaixa em qualquer modelo de equipe/projeto.  Se o seu time está em algo mais ágil ou waterfall, não faz a mínima diferença. Sem o seu time, irá entregar complexidade, pontos por caso de uso ou pontos de função isso também não faz diferença.  Pois, como já disse, TDD é um filosofia de desenvolvimento e não de gestão.

Ela trabalha em cima de ciclos pequenos onde a gente escreve o teste com a necessidade; após escrevemos o código para atender a necessidade e fazer o teste passar e por fim revistamos a solução para melhorá-la buscando princípios de Clean Code ( SOLID).  Se no final desse ciclo temos uma história entrega (por exemplo uso de quadros – Kanban, etc) ou se temos um ponto de função, observe que não faz diferença.  O que pode acontecer, no caso de pf é que deverá prever isso ( eu acho – nunca trabalhei com pontos de função).

Uma boa dica é que procure um DOJO (acesse o site do DojoRio) e veja na prática isso acontecer e como ela não tem relação com a gestão.

Se quer entender mais sobre TDD leia o livro do Kent Beck. Existe uma infinidade de outros livros sobre tão bons, mas acredito que seja legal começar pelo início. Depois a medida que for se sentindo mais confortável …

Assim, sem mais rodeios vamos a resposta a pergunta que me fizeram:

1. Posso usar TDD com um projeto que me exija entregar 4 a 40Pf ou qualquer outra coisas?

SIM ! Se acha que estou exagerando, procure o Alex Gomes da SEA Tecnologias. Seu maior cliente é o governo federal.  Existem outros exemplos como por exemplo

2. Código legado ?

Sim dá para usar TDD. Para te ajudar recomendo a leitura do livro Working Effectively with Legacy Code do Michael Feathers. Ele é uma excelente forma de ver como você pode testar o seu código legado.

Por fim espero ter te ajudado. E caso tenham dúvidas podem comentar que irei responder.

A gente sabe quando está mais consciente de algo quando é capaz de ver as falhas dele. Hoje está na moda dizer que é ágil ou que sua empresa usa algum “método ágil”.  E por aí segue as diversas sopas de letrinhas e nomes pomposos.  A pouco tempo atrás a tábua de salvação era o Scrum que agora já é “jogado a fogueira” pelos seus antigos defensores e em seu lugar ouço muito de Kanban, lean, etc.  Eu pessoalmente não gosto de modas, prefiro seguir aquilo que me facilite a vida e torne-me mais produtivo, feliz, etc.

Antes de mais nada, deixem eu dizer qual é o significa, para mim, de ser ágil: Pelo dicionário, ser ágil é alguém que se move com facilidade e preteza; para mim ser ágil é ser rápido e resiliente as mudanças; é ir além de aceitar as mudanças… é entender que ela é uma característica da vida.  Quando falamos de TI isso fica mais focado ainda na questão de ser rápido. Gosto de usar a figura de barcos: ser ágil é ser como um pequeno veleiro que pode mudar de direção facilmente.

Frente a isso fica mais fácil entender o que vou dizer a seguir: acredito que nem 1% das empresas que dizem ser ágeis se encaixam na “minha definição”.  Penso, sinceramente, que elas apenas trocaram de nomes, no fim é exatamente as mesmas coisas só que trocaram suas roupas. Antes eram cronogramas, agora são cartões com bluetaks pelas paredes, burns downs e quadro brancos.  Antes tinhamos gerentes, agora temos os Scrum Masters.

Uma outra coisa que considero ruim é que as pessoas não conseguem entender que devemos fazer aquilo que nos torna mais feliz e produtivos. Se controle em cascata deixa a nossa equipe mais produtiva será isso que irei usar. Simples assim. Seguir os processos ips letri é bom quando a gente não está acostumado e ainda não está maduro nele. Entretanto, depois de certo tempo seguir o processo e fazer as coisas só por que dizem que deve ser feito não é nada inteligente.

Uma vez ouvi uma história dos macacos que são colocados numa jaula. Cada vez que algum deles tentava pegar uma banana, todos tomavam uma descarga elétrica. Assim, com o tempo, foram trocando os macacos um a um. Eles desenvolveram um comportamento interessante de bater naquele que tentasse acessar a banana para evitar os choques.  Mesmo tempos depois tendo desligado os choques, os novos habitantes da gaiola batiam naquele que tentava acessar as bananas reproduzindo o comportamente sem nem mais saber porque.

Isso acontece o tempo todo em nosso meio. As pessoas fazem daily meetings e nem sabem mais porque… fazem por que tem que ser assim e ponto final. Cara se na sua equipe já existe a comunicação o daily pode ser uma grande perda de tempo. Pense nisso.  Reviews e retrospectivas também podem ser perdas de tempo. O próprio XP diz que é interessante que os conflitos sejam resolvidos o quanto antes e que a comunicação deve ser permanete e fluída. Assim ter uma reunião para conversar, para mim, por si só é um contra senso.

Ultimamente, o meu time tem usado algo que se assemelha mais ao kanban: kanban é a ferramente visual e não o processo. O processo é algo mais Lean – tentamos sempre manter o fluxo de entregas de forma constante e sem interrupções.  Procuramos sempre o que é melhor para nossa produtividade. Eliminar desperdícios mesmo que isso seja parte do próprio processo como se diz no livro. Inteligência é usar algo e adaptá-lo a sua necessidades. Seguir processos sem questioná-los é escolher não evoluir e correr o risco de acertar.

Colar post it na parede não diz que você é ágil. Ser ágil, para mim, é ser adaptativo. Mudar e procurar sempre o gradiente máximo.  Toda vez que leio o manifesto ágil, vejo ali um pedido para sermos mais inteligentes e produtivos. Usar processos não é ser ágil.. trocar waterfall por scrum não vai magicamente fazer entregar mais. É algo mais perto da cultura que deve ser mexida.

Hoje a moda é dizer que sua empresa é ágil.  Todo mundo agora tem quadro branco nas paredes, um monte de  post-it coloridos espalhados por todos os lados,  etc.  Todo mundo faz Scrum, Kanban, entre outras coisas mais. A questão é quantas empresas de fato são ágeis. Quantas de fato estão trabalhando no sentido de mais qualidade (no produto e na vida dos funcionários)?

A um certo tempo atrás o “mercado”acreditava que deveria padronizar, engessar e burocratizar os seus processos como forma de agradar mais seus clientes. Assim nasceu uma miriade de teorias, livros, bíblias, padrões, siglas e etc. Qualquer empresa que quisesse competir teria que de alguma forma se adequar a algum deles.  Imagine então as consultorias que vivem de vender serviço? Me lembro bem das pilhas de papéis que eram feitos sem nem se questionar se valia a pena ou não. Lembro-me bem das inúmeras reuniões para fecharmos escopo antes de ter escrito ao menos uma linha de código, nem um protótipo para validarmos se havia razão em manter o investimento.  E nada disso acabou com o maior problema que temos no mercado de TI: clientes infelizes!

PAUSA : Isso mesmo que você leu. O maior problema do mercado de TI é que nossos clientes estão infelizes. Eles pagam caro por algo que não é bem o que eles queriam e que chega num prazo muito acima para ter algum valor.  Por isso, não é dificil de entender por que temos tantas empresas que simplesmente optam por não comprar ou desenvolver uma solução mesmo sabendo que ela poderá ajudar.

Trabalhei 3 anos em indústria num departamento de engenharia. Era responsável pela parte de TI mais próxima da máquina (chamado de supervisórios, scada, etc). Com isso tive a oportunidade de lidar com grandes projetos que envolviam números realmente impressionantes.  Os projetos, em todos, tinham ciclos de vida de até 4 anos… Isso mesmo os projetos duravam em média 2 a 3 anos desde a sua concepção até a sua entrega, devido a lidarmos com fabricação de máquinas, construção de prédios, e outros serviços parecidos.  Nesse tipo de ambiente é certo concluir que a pressão é grande e a margem de erro é pequena, por isso, muitos diriam que isso seria um “prato cheio” para processos rígidos, escopos fechados, etc.

Acredito que para a surpresa de todos, o que eu vi foi exatamente o contrário:  As coisas mudavam muito e isso era muito bem absorvido, pois todos sabíamos que isso poderia acontecer .  Não tínhamos quadros brancos, não tínhamos post-its (eu até tinha ) tudo era controlado por um cronograma.  Entretanto, sentia que de certa forma éramos ágeis.  Quando chegávamos mais perto da entrega (chamávamos de partida da fábrica), contávamos com uma reunião diária com todos os técnicos/engenheiros envolvidos onde discutíamos o que tinhamos feito, os problemas,  as soluções, etc.  O que realmente estragava toda a brincadeira era o fato dos administradores/diretores nos entupir de formulários a preencher e assim toda a agilidade de equipe ia “por água abaixo”.

Cito esse exemplo para dizer que agilidade nada tem a ver com a ferramenta ou processo adotado. Tem muito mais relação com RESIlÊNCIA, ou seja, a sua capacidade de aceitar um “porrada” sem se deformar; sua capacidade de aceitar que as coisas mudam e ser aberto a elas; sua capacidade de não esconder os problemas, entender que eles existem e fazem parte de tudo, e que o grande lance não é procurar culpados e sim formas de resolver. É entender que tudo é negociável (menos a qualidade por favor).

RÓTULOS SÃO BONS PARA EMBALAGEM NÃO PARA FAZER SOFTWARE

Tenho começado a vislumbrar que tudo não passa de rótulo. Empresa que antes eram CMM ou RUP doentes hoje dizem que usam SCRUM e são ágeis. O que mudou foi o  RÓTULO, nada mais.  Ainda tem um monte de gente fazendo coisas sem sentido (zero de valor para o cliente), equipes fazendo horas extras para caramba, chefes mega autoritários e por aí segue.  Tem uma palestra do Jeff Patton entitulada “Eu não quero seus processo estúpido” que fala algo nessa linha.

Dane-se o nome.  O que importa é gente feliz: cliente feliz, funcionário feliz, chefe feliz, enfim todos felizes. Não é o quadro branco ou a pilha de documentos que irá garantir isso É muito mais atitude!  O que importa que vamos entregar mais valor para o nosso cliente e com isso fazê -lo ganhar mais dinheiro. É termos um ambiente que propicie que o cara que está fazendo esteja feliz e motivado pois sei que com isso ele irá fazer o seu 100% para ter algo bom e de qualidade na ponta. E se tudo funciona todos ficam felizes.

Seus processo, solução ou de qualquer jeito que queira chamar, dever como um lubrificante: deve facilitar o funcionamento para obter o máximo rendimento.

NÃO IMPONHA PROVE QUE SERÁ MELHOR

Um dos maiores erros é impor. Nada imposto dura muito ou é feito com alegria. Prove que se fizer daquele jeito será melhor e esteja preparado para estar errado.  Não será em todos os lugares que fazer par para programar será a melhor coisa. Isso depende das pessoas quererem. Eu particularmente gosto.  Não será em todos os lugares que não ter cronograma será a melhor escolha.

Sugiro, experimente, erre, mude. Siga evoluindo. Um colega de trabalho, Bernardo Heynemann, num tech talk, falou que uma coisa legal da cultura japonesa que ajuda muito o jeito Toyota de fazer as coisa é que eles sempre buscam a excelencia e evolução continua. Isso para mim é ser ágil. Aceitar o movimento e fazer uso dele.

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.