Uma empresa não se faz somente de capital inicial e nem apenas de conhecimento técnico. Uma empresa é composta por pessoas. Cada pessoa conta com crenças, limitações e experiências que contribuem para a formação de seu caráter e perfil profissional.
Na Crafters nós buscamos reunir um grupo de pessoas que tenham interesses comuns, crenças compatíveis e muita experiência real. Não nos interessa apenas buscar currículos impressionantes com muitos números. Queremos pessoas reais, que conhecemos e que estejam envolvidas com as comunidades das quais participamos. Isso nos permite manter um grau de expertise e alinhamento raro no mercado.
Proposta Inicial da Wareline
Há mais ou menos 2 anos atrás, uma empresa chamada Wareline nos procurou para que ajudássemos a migrar seu ambiente de desenvolvimento para a plataforma Java com foco na web. Apesar de continuar no suporte e evolução da aplicação desktop, eles queriam desenvolver um produto inovador. Algo novo e que sobrepusesse à concorrência. Queriam algo muito além do que já tinham feito.
Decidiram assim que iriam desenvolver seu principal produto, um ERP hospitalar, mas agora, voltado para o ambiente Web. Dentre as diversas tecnologias, escolheram a plataforma Java. Propusemos a utilização da linguagem Groovy e do framework Grails, visando assim minimizar a curva de aprendizado.
Considerando que boa parte dos desenvolvedores não conheciam a nova tecnologia, havia o risco de atrasos e erros nas estimativas de forma que um processo tradicional de desenvolvimento só prejudicaria o projeto. Não havia margem para erros e desperdícios. O projeto precisava ser impecável.
Nesse contexto, sugeri a adoção de algumas práticas de engenharia mais atuais. Práticas que surgiram conforme a necessidade do cliente e não porque faziam parte de alguma metodologia, mas porque agregavam valor naquele momento.
O processo
Iniciou-se então a definição de um processo de desenvolvimento de software customizado e adequado para a Wareline. Muitos dos envolvidos nem sabiam que era um processo baseado em premissas do Agile. Só ficaram sabendo muito tempo depois. Isso porque conseguimos chamar a atenção apenas para aquilo que era importante. Desenvolver software que funciona.
Neste processo haviam práticas de Scrum, Feature Driven Development, Extreme Programming, Domain Driven Design, Behavior Driven Development e algumas outras coisas. O objetivo era que o processo minimizasse os riscos e aumentasse a visibilidade sobre o andamento do projeto. Isso foi alcançado.
O levantamento de requisitos era feito utilizando conceitos do BDD. Utilizando user stories que se transformavam em especificação executáveis dentro do framework. Havia ainda um quadro kanban que determinava um processo puxado de desenvolvimento. O uso de iterações e algumas das cerimonias do Scrum, como Daily Scrum, Review e Retrospectiva também são utilizados.
Do FDD, trouxemos o conceito de inspeção de código, muito útil pra alinhamento e nivelamento do código produzido, já que nem todos eram muito acostumados com a tecnologia. Para que a inspeção tivesse um efeito mais adequado, utilizado uma definição de pronto, ou DoD (Definition of Done). Consistia num checklist que determinava quando uma funcionalidade poderia ser considerada pronta.
Problemas no andar da carruagem
Com a aplicação da inspeção, a equipe começou a perder muito tempo inspecionando o que estava pronto. O tempo de inspeção consumia várias horas da equipe, pois após a inspeção, havia muita discussão sobre qual seria a forma correta de se fazer algo. Isso começou a prejudicar a velocidade da equipe.
Para resolver esse problema, começamos a utilizar algumas práticas. Uma delas foi a programação em par. Agora os profissionais deveriam programar com um co-piloto ao lado. Além disso, os pares deveriam ser trocados a cada período de 4 horas. Isso garantia mais alinhamento sobre o que deveria ser feito e sobre qual era a melhor solução para cada funcionalidade.
Mesmo com a programação em par, acontecia de alguns pares caminharem em direções diferentes do que os outros achavam. Isso refletia um problema no entendimento do domain que estava sendo tratado. Iniciamos então o uso de diagramas de fluxo de informações similares aos propostos pelo Domain Driven Design. Esses diagramas deveriam ser elaborados de forma colaborativa entre os membros da equipe, buscando o alinhamento no que diz respeito ao que o Domain realmente é. Essas duas práticas fizeram total diferença no projeto.
Adaptação acima de tudo
Implementar agile não é algo que requer experiência e estudo. Não basta termos uma certificação e muito menos basta ler o Scrum Guide (apesar de necessário). É preciso vivência. Os profissionais da Crafters tem vivido de agile há um bom tempo já. Participaram de implementações grandes e pequenas de processos. Isso é fundamental.
Minha primeira implantação de agile aconteceu por volta de 2005 em um projeto da IBM e foi totalmente baseado em XP. Antes disso eu já estava atento às mudanças de paradigma propostas pelo Agile e participava de alguns projetos que já utilizavam desse paradigma.
Com essa experiência já vi muitos projetos irem por água abaixo ao tentar implantar agile. Alguns porque focaram muito em práticas de engenharia e esqueceram da gestão. Outros fizeram o oposto, focaram em gestão e esqueceram da engenharia. É preciso ter equilíbrio. Não basta seguir as regras “by the book”, é preciso se adaptar muito rápido e, a adaptação já começa a partir da concepção do processo. Só assim para termos sucesso em um ambiente tão complexo quando esse do desenvolvimento de software.
