It`s Only Rock `n Roll (But I Like It)

Simplicidade é uma ideia poderosa. Capaz de transformar o ruído em comunicação, o desarrumado em elegante, o complicado no fácil. O Rock, gênero musical de maior sucesso e impacto cultural da atualidade, ergueu suas bases nessa ideia genial, como definido pela Wikipedia: "sua forma pura tem alguns poucos acordes, um forte e insistente contratempo e uma melodia cativante."

Essa economia é misteriosamente cativante e sedutora. A relação criada entre a música e o ouvinte é direta e íntima. Visceral. Ela acontece, por exemplo, quando cantamos a melodia de uma peça que gostamos ou quando colocamos a nossa trilha sonora predileta para tocar no celular.

Porém, atingir tamanho grau de simplicidade não é nada fácil. É necessário trabalho duro. Suor.

Veja uma das mais famosas fórmulas da Física:




Espantosamente simples, não? A fórmula relacionando massa com energia parece que esteve sempre ali, apenas esperando para ser descoberta... Entretanto, para chegar a essa elegância, foi preciso muito trabalho para "polir" as arestas e jogar fora tudo o que estava atrapalhando (obviamente, com um "empurrãozinho" da mente brilhante de um dos maiores cientistas do século XX).

Seguindo esse raciocínio, para desenvolvermos software que seja fácil manter, atualizar e compreender, é preciso prestar atenção aos mestres da simplicidade, como Albert Einstein e Keith Richards. Para esses monstros sagrados, o que é deixado de fora é tão (ou mais) importante do que aquilo que será utilizado.

Atualmente, devido ao vasto arsenal de patterns e frameworks disponíveis no mercado, é muito comum o desenvolvedor pecar pelo excesso na codificação, seja para tornar o código mais "elegante" ou simplesmente numa tentativa de impressionar os seus pares e mostrar "serviço".

Por exemplo, veja aqui o famoso "Hello World", totalmente redesenhado utilizando vários padrões de projeto [GoF] como AbstractFactory, Strategy e State. É uma caricatura interessante de como a "sobre-engenharia" do código pode resultar, paradoxalmente, em código ruim e de difícil manutenção.

É claro que não sou contra a utilização de padrões, na verdade é exatamente o oposto:  encorajo e apoio a sua adoção. Porém, assim como um guitarrista não faz música apenas subindo e descendo escalas, um desenvolvedor de software não irá criar peças de qualidade apenas copiando e entupindo o código com padrões sem sentido.

É preciso um equilíbrio entre técnica, arte, sensibilidade, experiência e talento.

Uma dica de como começar?

Dê uma espiada aqui.

"Life is what happens to you while you're busy making other plans..."

Esta frase, de "Beautiful Boy", mostra que John Lennon sabia muito bem que é inútil tentar planejar nossas vidas em cada mínimo detalhe. No máximo poderíamos ter um plano básico, do tipo que diria que faculdade cursar ou quando seria a melhor hora para financiar uma casa bacana. A vida é muitíssimo mais poderosa que os nossos planos, várias vezes modificando o rumo que pensávamos ser o mais correto a tomar.

Uma oportunidade de emprego inesperada, um filho não planejado, um romance casual que se transforma em casamento, um hobby que vira profissão, tudo pode acontecer num instante e nos desviar de nossa "infalível" rota, tão meticulosamente traçada...

Sim, o controle é uma ilusão!

Mas o que Lennon não sabia é que essa ideia poderosa também é válida para o mundo do software. Há um processo de desenvolvimento que foca exageradamente na ideia do "plano perfeito", no detalhamento precoce da solução antes de qualquer codificação, de modo a termos maior "controle" sobre o que será desenvolvido, após extenso período de reflexão e análise.

Esse processo ficou conhecido como waterfall (cascata) e é representado graficamente assim:

Parece fazer sentido, não? Planejar tudo antes e implentar com segurança depois... Entretanto, o tempo mostrou que a adoção desse processo foi toda baseada em boatos e suposições, em vez de evidências claras da eficácia do método. As pessoas adotaram essa visão achando que era a "coisa certa a fazer" e não mediram os resultados que estavam obtendo. Conclusão: vários projetos engordando as estatísticas já obesas de fracassos empresariais em TI.


Contrapondo essa visão surgiram os métodos iterativos e evolutivos. RUP, OpenUP, Scrum, eXtreme Programming, são alguns exemplos de métodos que adotam o modulo iterativo de desenvolvimento. Em vez de fases passamos a trabalhar com pequenas iterações curtas (2-4 semanas, em média), agindo de forma adaptativa e sempre produzindo software com qualidade de release final. A cada dia, inspecionamos o trabalho para termos a certeza de que o objetivo da iteração será alcançado.

Esse modelo, graficamente, pode ser representado (resumidamente) da seguinte forma:

Cada release da iteração é software potencialmente entregável. Passou pelas etapas de análise, planejamento, construção e testes e está pronto para ser integrado às outras partes já produzidas do sistema. Os insights adquiridos são debatidos nas retrospectivas e servem de baseline para as próximas iterações, um processo que se retro-alimenta todo o tempo.

O Cliente, presente em todas as etapas do projeto - em pessoa ou como um papel específico, ajuda a refinar o entendimento do negócio, apoiando para que o desenvolvimento agregue o máximo valor à empresa e acelere o ROI. O feedback é obtido cedo e ajuda a corrigir a rota para que esteja de acordo com as necessidades dos stakeholders.

Esse fluxo se repete por várias vezes, fazendo a equipe evoluir e aprender com erros e acertos...

É provável que você hoje trabalhe em uma empresa que utilize o modelo waterfall de desenvolvimento. Caso os projetos estejam sendo entregues no prazo, satisfazendo os clientes e gerando grande valor ao negócio não há nenhuma razão para mudar. Caso contrário, considere a adoção do modelo iterativo de desenvolvimento na empresa em que você trabalha.

Seja uma empresa privada ou empresa pública certamente haverá desafios para mudar a cultura como um todo. Não desanime, pois o processo é lento. É necessário tempo para que as pessoas - clientes e fornecedores - aprendam a trabalhar de uma maneira totalmente diferente do que estão acostumadas.

Be patient!

"All you need is love."

Só pode brincar no seu quarto...

Todo mundo que tem criança em casa conhece o dilema: como dar a liberdade necessária para que seu filho ou sobrinho exercite a criatividade sem colocar em risco os móveis, quadros e paredes da casa?

Uma solução comum é criar o famoso "quarto da bagunça" - que pode ser o próprio quarto da criança. Nesse espaço (e somente nele), ela irá fazer desenhos, brincar com jogos que estimulem a criatividade, inventar personagens, enfim, fazer o que vier à cabeça. Crianças precisam de limites. Caso fiquem "soltas" vão colocar em risco tudo que estiver em volta...

Um dos mantras do mundo ágil é a auto-organização (self-organization) das equipes. É um conceito frequentemente mal interpretado pelos iniciantes em agile. De fato, as equipes têm liberdade para se auto-organizar, mas isso só acontece dentro dos limites do processo e do negócio em que estão inseridas.

Em "The Biology of Business", Philip Anderson diz enfaticamente:

"Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is."

As equipes, por exemplo, não escolhem o produto que irão construir e nem podem livremente escolher quais itens irão priorizar do Product Backlog. Quem tem essa responsabilidade é a gerência do produto e/ou o Product Owner (no caso do Scrum).

Entretanto, elas podem se auto-organizar para investigar soluções para problemas existentes, decidir qual o melhor par para executar uma determinada tarefa, distribuir as tarefas de acordo com o skill de cada membro e escolher que estórias implementar do sprint backlog. Essa lista, obviamente, não é final. Há outras atividades que são definidadas através da auto-organização.

Mike Cohn ajuda a iluminar esse ponto em "Succeeding with Agile":

"Self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This is referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges."

Esse container que Mike Cohn explica é justamente o espaço que é dado para que o Time se auto-organize. É uma linha tênue entre a liberdade e o mínimo de controle necessário para que as coisas não apontem em direção ao caos.

Funciona mais ou menos como as cordas da minha guitarra: se afrouxar demais não tocam, se apertar demais arrebentam...

Afinal, para que servem as reuniões diárias?

O objetivo principal da prática da reunião diária no Scrum e no XP é o de fornecer um momento para que cada membro da equipe saiba como está o andamento da iteração e se o trabalho está fluindo de acordo com o planejado para o sprint.

Cada membro do time responde a apenas 3 perguntas:

- O que fez ontem?
- O que irá fazer hoje?
- Houve algum bloqueio/impedimento?

As reuniões devem ser rápidas (10 -15 min, em média) e, por isso, são sempre realizadas em pé. Desse modo, evita-se o alongamento desnecessário e improdutivo.

Alguns cuidados, porém, devem ser tomados em sua condução:

- Ela não é uma reunião de prestação de contas com o "chefe". Ela é feita para o time! Deve acontecer todos os dias, no mesmo horário, independente da presença do líder ou qualquer papel parecido (aliás, é um bom termômetro faltar a uma reunião para saber se ela acontece mesmo sem a sua presença - caso você esteja no papel do Scrum Master);

- Não se deve perder muito tempo discutindo os pontos apontados. O objetivo é trazer visibilidade das tarefas e bloqueios para, após a reunião, o líder tomar as medidas necessárias para sua resolução;

- As perguntas não devem ser feitas, apenas as respostas serão dadas. Assim, as respostas são direcionadas a todos e não apenas a quem fez as perguntas.

- O melhor horário para sua realização é pela manhã. Caso seja impossível a realização nesse horário pode ser feita à tarde (sugiro que apenas como última opção).

Essas reuniões são de vital importância para o sucesso de um projeto evolutivo e ágil. A inspeção diária substitui a necessidade de uma documentação mais "pesada" para o projeto. Apenas os artefatos essenciais serão atualizados, como o status das tarefas e o Burndown Chart.

Muitas equipes iniciantes no mundo ágil negligenciam as reuniões diárias. Não caia nessa!

Veja o que diz James Shore:

"você deveria seguir o processo à risca antes de começar a adaptá-lo. Todas as práticas ágeis existem por razões bem fundamentadas. Entenda a essência de cada uma delas para poder, em um momento mais avançado, adaptar o processo à sua própria realidade."

Agilidade em Empresas Públicas

Como professor, tenho tido oportunidade em treinar pessoas de várias empresas públicas e autarquias federais. Gente do BNDES, da Petrobrás, da Finep, do IBGE, que vem dedicar seu tempo para aperfeiçoar habilidades em várias assuntos de software e TI.

Durante um desses cursos, em uma discussão sobre Scrum , uma questão apareceu para gerar uma certa polêmica : é possível aplicar métodos ágeis nessas empresas?

O primeiro impulso seria naturalmente responder não à pergunta, porém vamos analisar um pouco mais...

É certo que em muitas dessas empresas a burocracia pode ser excessiva e as pessoas podem estar paralisadas por processos antiquados. Também é verdade que a estrutura de poder nessas organizações, fortemente montada sobre uma estrutura hierárquica, pode dificultar o papel do Scrum Master em blindar "blindar" a equipe contra interferências externas.

Meu aluno Gilberto Martiniano, que trabalha com muitos contratos governamentais, expõe bem essa questão:

"Muito provavelmente será necessário a criação oficial desse cargo na estrutura funcional (com os devidos adicionais e descrição de obrigações, deveres, direitos e poderes) de forma a viabilizar as funções desse papel. No entanto, a ameaça da interferência externa é sempre um risco a se considerar nos projetos dentro de organizações do Governo."

Incentivos para a equipe também são difíceis de implementar, já que são de responsabilidade de "chefias" constituídas em "feudos", com constantes disputas de poder.

Porém, há vantagens também...

O horário mais tranquilo, por exemplo, favorece as práticas ágeis energizadas. O profissional sabe que raramente fará horas extras e pode se dedicar mais dentro do período de 8 horas de trabalho. No setor bancário a carga horária é ainda mais reduzida, ficando em 7 horas diárias. Dentro desse período mais "humano", as pessoas poderiam programar em par com muito mais frequência, pois o cansaço do trabalho mais concentrado é compensado pela certeza que haverá tempo para a vida após o trabalho.

No mundo privado é normal as pessoas trabalharem 11/12 horas por dia (às vezes até mais do que isso, como em bancos de investimento). Não há como implementar o trabalho energizado nessas condições...

Outra vantagem do setor público é o maior incentivo para treinamento e capacitação - na maior parte das vezes feito no próprio horário de trabalho. Meus alunos de empresas públicas chegam descansados - no período matutino - para absorver novos conhecimentos e depois vão para seus trabalhos cumprir a jornada restante de trabalho (sim, conta tempo de trabalho normal o dia de aula). Os cursos são pagos pelas empresas e contam, inclusive, para a ascensão na carreira da organização.

Enquanto isso, seus colegas do mundo privado chegam exaustos para o curso da noite (alguns dormem de bater com a cabeça na mesa), depois de uma jornada intensa de atividades. Pagam os cursos do próprio bolso e têm muita dificuldade para chegar no horário estipulado para as aulas.

Concluindo, percebemos que implantar a agilidade em empresas públicas pode ser perfeitamente possível. Haverá resistências e problemas para enfrentar, da mesma forma que há desafios a serem enfrentados em empresas privadas.

Apenas serão outros desafios...