Boas Práticas para a Melhoria do Processo de Desenvolvimento de Software

Dando continuidade ao post 3 Palavras-Chave Para a Melhoria do Processo de Desenvolvimento de Software, vamos falar sobre algumas práticas e ferramentas que têm nos ajudado (bastante) a melhorar a eficiência, segurança e produtividade na nossa equipe.

Este post é uma compilação do trabalho de melhoria do processo de desenvolvimento de software e do setor (de desenvolvimento) como um todo, que temos feito nos últimos anos.

A intenção aqui é de compartilhar a nossa experiência, de forma que sirva de inspiração também para outros colegas de profissão, discuti-las e evolui-las.

O aviso inicial é que o post ficou longo. Em vários momentos pensei em dividí-lo em vários pequenos posts, porém em todas as vezes que pensei isto, achei que a divisão não mostraria a mesma sinergia entre as práticas e ferramentas.

Então ficou assim mesmo, mas pelo menos ficou dividido em tópicos menores pra facilitar a leitura…

Alguns tópicos já foram mostrados neste blog em outros posts, mas mesmo assim achei melhor reproduzi-los aqui para deixar mais explícito a importância deles no processo como um todo.

CODING STANDARDS

Para falar sobre a importância dos coding standars e os benefícios que eles trouxeram ao processo, vou “surrupiar” um trecho do livro “Building Scalable Web Sites”, de Cal Henderson:

“Um benefício é que o código já escrito vai ser fácil de ser encontrado. Por exemplo, se eu quiser encontrar a função que adiciona uma tag para uma foto no Flickr, eu sei imediatamente aonde procurá-la, mesmo sem estar familiarizado com o código escrito por quem a implementou. Usar uma convenção uniforme para nomes de variáveis significa que, quando eu encontro uma variável $foto, eu sei exatamente o que ela contém. Em um sistema sem uma boa padronização, um programador pode usar $foto para armazenar um código, outro pode usá-la para armazenar o título da foto convertido para XML, enquanto um terceiro pode usá-la para armazenar o registro da foto no banco de dados.

O ponto chave a ser lembrado é que o mais importante não é encontrar o melhor formato para a sua estrutura de código e layout, o mais importante é que a aplicação mantenha um padrão consistente. Quando o seu formato e estrutura são consistentes, isso elimina o espaço de pequenos erros e drasticamente reduz o overhead cognitivo ao entender o código escrito por outros membros da equipe.”

SENTAR JUNTOS

Para quem não conhece, “Sentar-se Junto” é uma das práticas da Extreme Programming (XP), que sugere que a equipe de desenvolvimento deve sentar-se junta em uma sala aberta, onde todos possam trabalhar e comunicar-se de forma eficiente. Onde um consiga ouvir o outro e discutir os assuntos do projeto.

A melhoria na comunicação entre a equipe tende a motivar a colaboração entre o time, maximizando a qualidade do projeto e minimizando os erros originados por falhas de comunicação.

DESENVOLVIMENTO ORIENTADO A TESTES (TDD)

O Desenvolvimento Orientado a Testes (Test Driven Development) tem melhorado o processo de desenvolvimento principalmente em dois pontos:

• Melhoria da qualidade interna do código, uma vez que o TDD força o programador a pensar antecipadamente sobre o que precisa ser codificado. Isto acaba levando a um código mais legível, com nomes mais claros, e melhor componentizado;
• Agilidade na resposta às mudanças, uma vez que a equipe passa a trabalhar em uma aplicação melhor componentizada e testável, as respostas às mudanças tendem a ser mais rápidas e precisas.

CONTROLE DE QUALIDADE (QUALITY ASSURANCE)

Quando me refiro a Controle de Qualidade eu quero dizer: “Ter uma equipe destinada exclusivamente a esta atividade”.

A questão é que o desenvolvedor, normalmente, tem uma forma de testar diferente de um profissional de testes.
O primeiro normalmente busca certificar-se que a programação está funcionando corretamente.
O segundo normalmente busca certificar-se que entradas inválidas ou diferentes do convencional, serão devidamente tratadas.

Por melhor que seja o desenvolvedor em testes de software, ele sempre vai deixar algumas lacunas.
Um bom profissional de testes sempre oferecerá um algo mais. Ele vê a aplicação com outros olhos, tem uma visão mais de usuário (se comparado a um desenvolvedor) e saberá testar a aplicação em busca de potenciais erros, além de outras melhorias textuais e de usabilidade.

É importante salientar que a existência do Controle de Qualidade não exclui a importância dos testes (automatizados ou não) feitos pela equipe de desenvolvimento.

O grande valor vem da dos testes feitos (a partir de diferentes visões) por ambos os setores (Programação e Controle de Qualidade).

INSPEÇÃO DE CÓDIGO

Vamos ser realistas: Inspeção de Código é uma tarefa árdua e custosa.
Exige um bom tempo de um bom profissional, que poderia estrar produzindo outros requisitos de valor para o negócio.
Porém, os resultados são valiosíssimos, tanto para a equipe quanto para o projeto.

É na Inspeção de Código onde os pontos fortes e fracos do profissionais ficam mais evidentes.
Com isso, tanto podemos trabalhar a capacitação do profissional diretamente nas suas maiores deficiências, quanto podemos conhecer os seus pontos fortes e melhor aproveitá-los em outras tarefas ou projetos, além de aprendermos com eles.

É na Inspeção de Código onde quaisquer divergências (ou ausência) de coding standards são detectadas e, “imediatamente tratadas”.
Com isso conseguimos manter a aplicação padronizada e disseminar o conhecimento sobre os padrões internos adotados, discuti-los, analisá-los e evoluí-los.

É na Inspeção de Código onde quaisquer divergências sobre a arquitetura da aplicação são detectadas e, “imediatamente tratadas”.
Com isso conseguimos manter um melhor padrão de arquitetura e, ao mesmo tempo, disseminar este conhecimento para a equipe de forma rápida, no momento em que todos os detalhes ainda estão frescos na mente da equipe.

Penso que este é o melhor momento para se rever o código, discuti-lo, refatorá-lo e evoluí-lo.

Conforme dito anteriormente, o custo do procedimento é alto, mas o seu valor para o processo (de melhoria do código, capacitação da equipe e disseminação de conhecimento) é altíssimo.

CONTROLE DE VERSÕES

Lembro da época que tínhamos uma equipe de uns quatro desenvolvedores e webdesigners e o acesso ao Servidor de Desenvolvimento era feito via FTP.

Sempre que alguém fazia um upload de arquivos, tínhamos que acessar diretório por diretório, enviar arquivo por arquivo, e enviar um e-mail para a equipe para todos ficarem cientes que determinada área do sistema foi atualizada.

Lá ia a equipe acessar diretório por diretório, atualizar arquivo por arquivo, e mesmo assim a sobreposição de arquivos por versões mais antigas, era inevitável.

Não posso dizer que isso sempre acontecia, mas também não posso dizer que esses momentos eram raros.
O que eu posso dizer é que eles realmente incomodavam, e que, por algumas vezes precisamos refazer uma programação que já estava pronta, porque alguém a sobrepôs com uma versão mais antiga.

Depois que passamos a trabalhar com Controle de Versões, para a felicidade geral da equipe, esses problemas acabaram. E olha que isso é apenas “uma” das vantagens do Controle de Versões.

Entre as outras vantagens eu posso citar:

• Possibilidade de vários membros da equipe trabalharem no mesmo arquivo (em partes diferentes), ao mesmo tempo;
• Rapidez e precisão tanto para enviar os arquivos para o Servidor de Desenvolvimento (commit), quanto para atualizar a cópia local (update) – O Controle de Versões envia cada arquivo para o seu devido diretório;
• Facilidade de correção de conflitos (quando dois desenvolvedores alteram o mesmo bloco de código, do mesmo arquivo, ao mesmo tempo);
• Rastreabilidade sobre quem alterou o que, e quando;
• Maior controle sobre as versões do software, disponibilizadas publicamente.

Realmente esta foi uma ferramenta que agregou um enorme valor ao processo de desenvolvimento e eliminou uma série de “probleminhas” que tínhamos internamente.

AMBIENTE DE DESENVOLVIMENTO

Uma coisa é certa: Não dá pra trabalhar diretamente nos Servidores de Produção.
Testar a aplicação em um ambiente a parte é algo básico para qualquer aplicação que se preze.

O Ambiente de Desenvolvimento, idealmente, deve contemplar que testes sejam feitos reproduzindo o Ambiente de Produção: sistema operacional, softwares e versões utilizadas, etc.

No nosso caso, onde em vários momentos temos diferentes desenvolvedores trabalhando em diferentes funcionalidades, é comum uma tarefa gerar dependência em outra (alterações nos mesmos arquivos).

Com isso, uma outra ideia que tem trazido bons resultados foi a disponibilidade de um Servidor de Homologação (Stage) – que pode até estar no mesmo hardware do Servidor de Desenvolvimento.

O Servidor de Homologação contém uma cópia fiel do Ambiente de Produção e nos permite fazer testes simulando o ambiente “real”.

BUILD DE UM CLIQUE

A ideia aqui é que seja possível fazer o deploy da aplicação em apenas um clique.
Da mesma forma, é importante que seja possível reverter a aplicação ao estado anterior (recuperar o backup) em apenas um clique.

A maneira mais comum de fazer isto é publicando a aplicação como uma working copy do Controle de Versões.

Neste caso, o ambiente de desenvolvimento de cada desenvolvedor passa a ser a sua própria máquina.
Após concluído o trabalho, ele faz um merge (Controle de Versões) para o Servidor de Homologação (Stage), que funciona como uma cópia do ambiente de produção.

A partir daí os testes são executados e, após concluído o trabalho, gera-se uma TAG do estado atual da aplicação e faz-se o deploy (também conhecido como build, release ou publicação) para o ambiente de produção.

No nosso caso, por algumas características do nosso projeto, temos feito isto de uma forma diferente.
Trabalhamos com um Servidor de Desenvolvimento onde cada desenvolvedor trabalha em cima de uma working copy deste projeto, mas todos atualizam e testam diretamente no Servidor de Desenvolvimento.

Após concluído o desenvolvimento e os testes, geramos um build para o Servidor de Homologação (um clique), que é uma cópia do ambiente de produção.
Novos testes são feitos, simulando o ambiente de produção, e só então é feito o deploy para produção (um clique).

Esta forma de trabalho parece ser mais prática para a nossa realidade, porém, o deploy de um clique é essencial, uma vez que perde-se muito tempo no processo de deploy manual.

Uma outra melhoria a ser feita neste processo é a adição de um Servidor de Integração Continua.
Ainda não chegamos neste estágio, mas pretendemos, assim que possível, dar continuidade a esta melhoria.

ISSUE TRACKING (CONTROLE DE SOLICITAÇÕES)

Outra forma de organizar o trabalho, é manter uma relação das solicitações e suas devidas prioridades, e poder acompanhá-las.

A maneira mais comum de gerenciar as solicitações é através de uma ferramenta de Issue Tracking (ou Bug Tracking).

A nossa experiência mostra que manter uma ferramentas destas melhora tanto o gerenciamento e a priorização das solicitações, quanto a rapidez na atribuição de tarefas para a equipe de desenvolvimento.

Além disso, esse tipo de ferramenta também auxilia a equipe quando é preciso resgatar algum histórico sobre o que, e como, foi atendido uma ocorrência.

KANBAN

Kanban é uma ferramenta herdada do Sistema Toyota de Produção, que é utilizada principalmente (em desenvolvimento de software) para registrar e acompanhar o estado de Requisitos e/ou tarefas, dentro do fluxo de desenvolvimento (ou produção).

Um dos grandes valores do acompanhamento por Kanban é a visibilidade dos gargalos no processo (ou seja, as tarefas que estariam prejudicando o fluxo de desenvolvimento) e, com isso, estimulando a multidisciplinaridade do time em unir-se para “empurrar” esta(s) tarefa(s) para produção e desafogar o processo.

Para quem é novo no assunto, isso quer dizer o seguinte:
Se a equipe tem várias tarefas que já foram desenvolvidas, e ainda não podem ser publicadas por não terem sido testadas, este é o gargalo do momento: testes.

Neste momento, se a equipe desenvolver novas tarefas, apenas estará aumentando o gargalo do processo (fila de testes).
O que é preciso fazer, então, é priorizar os testes das tarefas pendentes, para liberar o fluxo de desenvolvimento/produção.

A utilização do Kanban torna estas informações mais visíveis e facilita a pró-atividade na eliminação de gargalos no processo.

Para quem ainda não conhece, e se interessou pelo assunto, recomendo a leitura do post a seguir:
Amadurecendo o workflow do projeto com práticas do Kanban

FOCO NO PROJETO

Quando uma equipe precisa trabalhar em vários projetos, a mudança de contextos entre um projeto e outro é um dos fatores que quebram a produtividade.

Quando um profissional precisa mudar de um projeto para outro, ele(a) “precisa” mover o foco do projeto atual para um novo domínio (de problema e de solução).

Uma vez que o profissional está focado em gerar soluções para a aplicação em desenvolvimento, é comum que a mudança de foco para outro projeto não aconteça por inteiro.
Mesmo contra vontade, o profissional ainda fica com a mente parcialmente focada nos problemas do projeto anterior.

Este processo de “desintoxicação” do projeto atual e “reabsorção” do novo contexto não costuma acontecer imediatamente, e é uma fonte bastante comum de queda de produtividade.

Em outra situação, como no meu caso, que trabalho em uma empresa com foco em SaaS (Software as a Service), é comum termos projetos representando novas funcionalidades do produto.

Neste caso, não temos uma mudança total de contexto, afinal, dois Requisitos do mesmo projeto costumam compartilhar muita coisa (lógica e códigos). E é exatamente aí que mora o problema:

A probabilidade de um segundo (ou terceiro) projeto (funcionalidade) gerar dependências no primeiro, é bastante alta.

Isso quer dizer que:

• Se o seu processo de desenvolvimento NÃO está munido de boas ferramentas, é provável que os dois (ou três) projetos só possam ser publicados simultaneamente. Fato que retarda o lançamento das novas funcionalidade (resposta ao mercado), atrasa o processo de publicação (que se torna mais complexo e toma mais tempo) e aumenta a probabilidade de erros (devido a maior complexidade);
• Se o seu processo está munido de boas ferramentas e a sua equipe consegue trabalhar em branchs diferentes para cada funcionalidade, ainda assim haverá a perda de tempo para se fazer múltiplos merges para o mesmo produto e, a maior probabilidade de erros (uma vez que, com dois ou três projetos em paralelo é provável que a equipe de Controle de Qualidade não consiga tempo hábil para dedicar-se de forma integral a cada projeto).

Além disso, o fato de quebrar a equipe para trabalhar em vários projetos simultâneos, tira parte da sinergia da equipe, abrindo mão de novas visões e opiniões. Fato que muitas vezes pode custar o re-trabalho de alguns requisitos.

O mais importante a ser entendido aqui é que o tempo e dinheiro perdidos com a pluralidade de projetos cresce exponencialmente, e não quantitativamente, com a adição de projetos simultâneos.

Em outras palavras: Trabalhar em três projetos simultâneos não irá somar as dificuldades dos três projetos, mas duplicar ou triplicar esta soma (dependendo do caso e da complexidade dos projetos).

Manter a equipe focada em apenas um projeto é uma forma de maximizar a produtividade da equipe e reduzir prazos e custos do projeto.

REUNIÕES DIÁRIAS

O fato de todos os profissionais da equipe chegarem no inicio do dia, analisar suas pendências e definirem: “Hoje eu vou trabalhar na tarefa X. Estou com tal dificuldade (ou, Não tenho nenhum impedimento)”, já inicia o dia de outra forma, focado nas necessidades daquele dia, para o projeto.

O fato de cada membro da equipe ter conhecimento sobre todas as tarefas em execução e seus devidos responsáveis, mantém a sincronização sobre todo o projeto com toda a equipe.

Esta sincronização tende a estimular a sinergia da equipe em se ajudar a finalizar suas tarefas da melhor forma possível.
A sincronização do conhecimento sobre o projeto também evita erros do tipo: “Eu não sabia que você estava trabalhando nesta tarefa” ou “Estou a uma semana esperando o retorno do cliente”.

Definir o que deve ser feito “naquele dia”, juntamente com a equipe,  é uma das formas de manter o foco  no projeto e aumentar a produtividade naquele dia.

Conforme Frederick Brooks diz em seu livro “O Mítico Homem-Mês”:

“Como um grande projeto atrasa um ano? Um dia de cada vez.”

Por tanto, organize o seu trabalho, diariamente.

DESENVOLVIMENTO ITERATIVO E INCREMENTAL

Não vou me estender neste assunto, uma vez que já existe uma gama de informações disponíveis na Internet.

Resumidamente:
A melhor forma de se resolver um problema é quebrando-o em partes menores.

Em um projeto de software, mantendo-se um ciclo periódico de entregas (iterações) irá tanto possibilitar que a equipe técnica priorize os processos mais críticos ao negócio, quanto possibilitar que o cliente acompanhe e avalie a evolução (incremental) da solução entregue até aquele momento.

É importante entender que o processo iterativo e incremental tanto possibilita o melhor aprendizado sobre o negócio, por parte da equipe técnica (através do envolvimento do cliente e sua avaliação e retorno sobre as entregas), quanto possibilita o melhor aprendizado, por parte do cliente (através da avaliação frequente da solução e seu envolvimento mais profundo com o projeto).

O desenvolvimento iterativo e incremental é uma forma de equipe técnica e cliente utilizarem o aprendizado que ocorre ao longo do projeto, para buscar uma solução ainda mais eficiente.

BUG NÃO TEM PRIORIDADE

Para comentar a importância de se priorizar a correção de bugs, eu vou citar a resposta que o Guilherme Chapiewisky deu no evento Edted de 2009, em Florianópolis, quando questionado sobre como eles faziam, na Globo.com, para priorizar bugs no meio de um projeto:

“Bug não tem prioridade, precisa ser corrigido.
Não tem como você evoluir a sua aplicação em cima da uma base falha.”

E vou complementá-la com mais um trecho do livro “Building Scalable Web Sites”:

“Corrigir erros em um código que você não mexeu a um tempo é uma tarefa minuciosa e demorada, e quanto maior a sua aplicação fica, mais tempo leva para localizar cada erro.”

Portanto, erro não tem prioridade. Precisa ser corrigido.

EQUIPES MULTIDISCIPLINARES

Para que um Requisito flua pelo processo de desenvolvimento é importante que a equipe esteja munida de pessoas que possam atuar em cada um destes estados, ou melhor, que possam executar várias tarefas dentro de um processo de desenvolvimento.

Sem uma equipe multidisciplinar, fatalmente o Requisito irá atrasar em algum estado (planejamento, programação, teste, inspeção, publicação e etc.) “congestionado”.

Normalmente, congestionamentos de tarefas em uma determinada etapa do processo são comuns. O que a equipe precisa, então, é de profissionais multidisciplinares. Profissionais que percebam estes gargalos e atuem ativamente para “empurrá-los” até a produção e liberarem o fluxo de tarefas.

Para chegar a um processo de desenvolvimento eficiente, no entanto, é preciso das pessoas certas.
Um bom processo de desenvolvimento, sem uma boa equipe, certamente não apresentará a eficiência desejada.

PROTEGER A EQUIPE DE INTERFERÊNCIAS EXTERNAS

Um ponto importante para um processo eficiente é que a equipe consiga trabalhar, de fato, no projeto.

A empresa pode ter um processo eficiente, com bons procedimentos, regras, ferramentas e pessoas certas, porém, se a equipe não estiver protegida de interferências externas, boa parte da eficiência do processo cai por água abaixo.

A razão disto é a mesma citada anteriormente no tópico “Foco no Projeto”: A mudança de contextos.

Para evitar a mudança de contextos e a perda de produtividade gerada por ela, é preciso manter o foco no projeto.

Para isso é importante que clientes de projetos anteriores não tenham contato direto com a equipe de desenvolvimento, ou seja, a equipe de desenvolvimento não deve ser transformada em uma equipe de suporte. São tarefas distintas.
Preferencialmente o pessoal do Service Desk deve fazer o contato com a equipe técnica (através de um suporte nível 2) – Isso fará que a equipe seja interrompida apenas quando necessário.

A equipe de desenvolvimento deverá trabalhar em iterações fixas. Isso aumentará as chances para que diretoria e gerência respeitem o planejamento da iteração e evitem as mudanças de contexto.

Mas, um ponto que eu ainda preciso amadurecer é sobre quem deverá fazer o contato com o Service Desk.

O problema que vejo é que, mesmo que apenas o Service Desk tenha acesso completo à equipe de desenvolvimento, isto ainda poderá ser uma interferência externa e gerar muitas tarefas extras e mudanças de contexto (na análise, ajustes e correção de erros).

Com isso penso que, “idealmente”, este contato com o Service Desk deve ser coordenado por alguém que tenha conhecimento sobre todo o projeto e todas as tarefas em execução. Alguém que conheça as necessidades do negócio e as devidas prioridades, alguém que conheça os pontos fortes e fracos da equipe técnica.

Esta pessoa terá maiores condições de saber:

• Se tal solicitação deve, realmente, ser atendida naquele exato momento, ou seja, se ela é mais importante que todas as outras tarefas em execução;
• Qual profissional poderá atender tal solicitação, gerando o menor prejuízo para o negócio.
  Em outras palavras: Se alguém tem que parar para atender a solicitação, quem está trabalhando no Requisito de menor valor?;
• E ainda criar, se necessário, uma estratégia de capacitação, de forma que aquele conhecimento seja disseminado para outros membros da equipe.

O ponto negativo que vejo nessa abordagem é o fato de a empresa ter que direcionar um profissional mais qualificado (com grande conhecimento do negócio e do projeto – normalmente um Coordenador de Equipe ou Gerente de Projetos) para ficar atendendo e priorizando solicitações.

Ainda não consegui pensar em uma alternativa melhor. Se alguém tiver uma dica, por favor me avise…

De qualquer maneira, seja lá qual forma você encontrar, mantenha a equipe protegida das interferências externas e o foco no projeto.

Para quem se interessar sobre o assunto, sugiro a leitura do artigo do Phillip Calçado, que parece ter passado pelo mesmo problema:
Derrubaram as Paredes Erradas

INICIO

Bem, em desenvolvimento de software o fim de um ciclo (de desenvolvimento ou melhoria) é sempre o inicio de um outro.

Espero que as dicas acima sejam de grande valia a você, assim como são para mim.

PS: Críticas e/ou sugestões são sempre bem vindas.

Agora… se você chegou até aqui, é porque você é bom mesmo (pelo menos em leitura… )
E vou aproveitar e pedir, por favor, deixe um comentário, afinal é muito gratificante pra mim saber que alguém conseguiu ler esse post inteiro.

Ronan Lucio Pereira

« Especialista ou Generalista?

Porque Coldfusion »