Como trabalham os desenvolvedores profissionais?

Esses dias estive pensando a respeito de práticas de programação que são comuns a todos os desenvolvedores profissionais que conheço. Apesar de haver estilos e características diferentes em cada um deles, há um conjunto de atividades que eles compartilham quase sempre. Portanto, resolvi agrupar uma "lista" dessas atividades principais e divulgá-las aqui no blog.

Vamos à lista:

Desenvolvedores profissionais...

Estudam muito, sempre. 

Eles bebem de várias fontes. Fazem cursos, leêm as obras mais relevantes da área, frequentemente conhecem mais de uma linguagem (e plataforma), gostam de "fuçar" para obter mais conhecimento e estão sempre praticando e testando novas ideias. Para esses profissionais, o importante é aprender sempre e estar  em constante evolução. 

Gostam de compartilhar conhecimento. 

Desenvolvedores profissionais, geralmente, são membros ativos de blogs, grupos de discussão e comunidades. Ajudam seus colegas de trabalho a entenderem técnicas e conceitos importantes, disseminando o conhecimento por todos da equipe. São definitivamente pessoas altruístas e com grande sentimento de colaboração e cooperação. 

Escrevem seus próprios testes.

Desenvolvedores profissionais escrevem seus próprios testes. Como Phillip Calçado expôs nesse excelente post , é bobagem achar que um desenvolvedor profissional não deva produzir seus próprios testes unitários automatizados. Pior ainda é considerar que ninguém deva produzir esses testes alegando questões de prazo e/ou custo. Leia esse post do José Papo e entenda por que isso é um contra-senso  econômico.

Escrevem código para pessoas e não para máquinas.

Qualquer um pode escrever alguma coisa que compile e funcione. Entretanto, somente os profissionais escrevem código limpo, claro e organizado que pessoas conseguem entender e manter. O design é feito pensando nos outros programadores - os que irão passar a maior parte do ciclo de vida do sofware mantendo o produto.

Refatoram de forma disciplinada e habitualmente. 

Na vida real todos nós sempre temos um prazo e um budget. Desenvolvedores sérios sabem disso e são comprometidos com as necessidades de seus clientes. Para respeitar esse prazo, muitas vezes entregam uma solução que ainda não consideram como "excelente" e, para resolver esse problema, assumem e se responsabilizam pelo "débito técnico" gerado, refatorando o código de forma habitual e controlada (obviamente, sempre possuem uma suíte de testes automatizados para tornar a tarefa possível).

Evoluem com o design tendo o business em mente.

Desenvolvedores profissionais criam soluções, de forma incremental, que reflitam o negócio da empresa (e do cliente) em primeiro lugar. Desenvolvedores sérios trabalham com técnicas que facilitem a criação de uma aplicação que contenha elementos comuns a todos os stakeholders do projeto da organização. Geralmente indicam o livro do Eric Evans, "Domain Driven Design", como leitura  obrigatória (e realmente considero um excelente livro).

Enfim, essas são as atividades que considero comuns aos desenvolvedores profissionais. Servem como uma "luz" para o nosso próprio desenvolvimento profissional.

E você? Acredita que há mais atividades importantes?

Comente...

As 10 melhores práticas para se construir software.

1 - Desenvolva uma visão do produto.

2 - Trabalhe de modo iterativo e evolutivo.

3 - Envolva o cliente no processo.

4 - Gerencie requisitos.

5 - Acolha mudanças.

6 - Construa o design e a arquitetura incrementalmente.

7 - Diminua o tempo de feedback.

8 - Gerencie riscos.

9 - Aplique técnicas de engenharia.

10 - Confie na equipe.

Devagar com o Andor que o Santo é de Barro

Recebi vários emails de pessoas que ficaram confusas com meu último post... Muitos acharam que havia uma incoerência em defender uma prática comum no PMBOK - a gestão de riscos- já que sou um estudioso e propagandeador de métodos ágeis de gestão e desenvolvimento de software.

Deixe-me esclarecer melhor: por mais que eu escreva coisas como nesse post aqui, não é a minha intenção desmerecer um trabalho de anos realizado pela comunidade do PMI. Em qualquer método, framework e guia de práticas, sempre haverá pontos positivos e negativos, relativizados de acordo com o contexto de  aplicação em cada organização ou projeto. O próprio Scrum, que sou entusiasta como muitos na comunidade agile, é cheio de lacunas em áreas como engenharia e risco.

O que aprendi é que realmente não existe uma "bala de prata" em processos da área de TI. É preciso conhecer (e estudar) vários deles para obter aquilo que melhor se encaixa ao ambiente em que estamos trabalhando e que irá contribuir para o resultado do negócio.

Logo, por mais que gostemos de Agile, Scrum, XP, Lean e Kanban não podemos ignorar que RUP, CMMI, PMBOK, SWEBOK têm grande valor e que devem ser considerados por qualquer profissional sério da área de software e/ou TI.

O Poder do Pensamento Negativo

Recentemente, li um artigo intrigante sobre o poder do pensar negativamente a respeito das coisas. Esse autor defende uma tese muito interessante: de que ter uma visão mais pessimista nos torna mais preparados diante das situações do dia a dia, devido ao comportamento "pé atrás" que passamos a assumir ao agir. Em vários pontos do texto, ele mete o malho nos "polianas" de plantão e nos propagadores de ideias como "lei da atração", o "segredo" e outras baboseiras clássicas. 

De fato, esse "pessimismo defensivo" é um excelente neutralizador de surpresas desagradáveis. Ao pensar no que pode dar errado, bolamos maneiras de contornar o problema e proteger nossas atividades dos inevitáveis imprevistos.

Em gestão de projetos essa atitude tem um nome: chama-se Gestão de Riscos.

E o que seria um risco para o projeto? Segundo o PMBOK, a definição é a seguinte:

"Evento ou condição incerta que, caso ocorra, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade."

Esssa definição é interessante pois mostra que há também riscos positivos para qualquer projeto. Muitos acreditam que o risco é sempre algo negativo e que sempre resultará em efeitos adversos à atividade realizada. Obviamente, não estamos preocupados com os efeitos positivos inesperados e sim com os de efeito negativo.

Métodos e frameworks como RUP, PMBOK e CMMI encorajam uma abordagem disciplinada a respeito dos riscos de um projeto. A ideia é listar, tão cedo quanto possível, os riscos principais do projeto e tratá-los logo nas primeiras iterações. Entretanto, frequentemente essa prática é sumariamente ignorada pelas equipes, em prol da realização de atividades que mostrem "mais serviço pronto" ao chefe, como o desenvolvimento dos cadastros de uma aplicação. Essa atitude é a que provoca falsos inícios em um projeto, postergando as atividades de maior risco que podem gerar surpresas desagradáveis mais à frente (e é o que geralmente acontece).

Por isso, entre sempre com o "pé atrás" em qualquer projeto.

Ajuda a evitar dores muito fortes de cabeça...

Scrum e a Gestão Ágil

É consenso de que em projetos ágeis de software não há lugar para o gestor do tipo sabe-tudo,  aquele que controla o projeto por completo, assumindo a total responsabilidade pelo seu sucesso ou fracasso. Esse papel é frequentemente desempenhado pelos profissionais que seguem a cartilha do PMI, criando pouco (ou nenhum) espaço para adaptação e colaboração.

Por outro lado, há sim a necessidade de um modelo de gestão. É um erro achar que projetos ágeis se auto-gerenciam, como corretamente apontam Mike Cohn e Ken Schweber no artigo "The Need for Agile Project Management":

"One of the common misperceptions about agile processes is that there is no need for project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception."

Para gerenciar projetos, o Scrum trabalha com o modelo de gestão compartilhada, distribuindo responsabilidades entre os vários papéis presentes na equipe do projeto, a saber:

1 - Product Owner 

• Responsável pela Visão do produto.
• Controla o Product Backlog.
• Monitora o projeto contra os objetivos de ROI e Visão.
• Prioriza e refina o Product Backlog, medindo o seu sucesso.

2 - Scrum Master

• Monitora o processo para garantir o sucesso da equipe.
• Permite que o time se auto-organize.
• Remove obstáculos.
• Blinda o time contra perturbações externas.
• Promove rápidas reuniões diárias.
• Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint.

3 - The Team

• Seleciona e desenvolve as estórias do Sprint Backlog
• Expande as estórias em tarefas mais detalhadas.
• Completa 100% de cada tarefa escolhida.
• Gerencia e auto-organiza o próprio trabalho.
• Diariamente inspeciona o projeto para atingir os objetivos do Sprint

Cada papel dentro da Gestão Ágil direciona esforços para entrega frequente de valor e antecipação do ROI do projeto. Em projetos tradicionais espera-se a finalização completa do projeto para se ter retorno sobre o investimento aplicado; em Scrum gera-se valor a cada pequeno incremento durante o tempo, retornando o investimento muito antes da entrega do release final e oferecendo oportunidades reais de lucro antecipado.

 

Na Gestão Ágil a responsabilidade pelo sucesso de cada projeto depende da colaboração e do comprometimento de cada um dos papéis da equipe, o que diminui o risco de se ter o destino da empreitada nas mãos de uma única pessoa.

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."