Produtividade no Desenvolvimento de Software

O objetivo desta publicação é oferecer conhecimento para ajudar pessoas e empresas a melhorar significativamente a sua performance no desenvolvimento de soluções de software para uso próprio ou para terceiros.

Você já se deparou com um ou mais situações da relação abaixo?

1. Estouro de prazos de entrega.
2. Custos de desenvolvimento mais elevados do que era planejado.
3. Funcionamento inconsistente do que foi desenvolvido.
4. Excesso de bugs.
5. Resultado não atende as necessidades do usuário.
6. Novos desenvolvimentos injetam novos bugs no sistema.
7. Erros só são descobertos depois que vão para produção.

As dicas que vou apresentar se aplicam:

1. a qualquer tipo de software, feito em qualquer linguagem de programação ou plataforma de desenvolvimento.
2. em equipes que recebem muitas pequenas tarefas ou equipes com poucos grandes projetos.
3. nas situações em que as prioridades mudam constantemente.

Prepare-se Psicologicamente para o Desafio

Produzir software em equipe é difícil. Você e sua equipe precisam se conscientizar disso para estarem preparados para chegar até o final. As dificuldades serão:

1. Definir um processo que funcione e que consiga se adequar às necessidades e recursos que você possui.
2. Encontrar uma forma eficaz de comunicação e controle do processo.
3. Corrigir a cultura da empresa para que as pessoas estejam preparadas para se adequar ao processo.
4. Ser persistente porque a implantação de uma cultura depende da correção constante dos erros que acontecerão.

Linha de Produção de Software

Em outras áreas da engenharia, em que as coisas se repetem de forma estruturada, é possível somar os tempos, encontrar os caminhos críticos e definir o prazo de entrega.

Já acreditei que produzir software era uma ciência imprevisível porque teoricamente você não tem tarefas repetidas. Se o código for repetido então você copia e cola o código.

Mas se pensarmos em todo o processo, do momento em que o usuário define os requisitos até o momento em que o resultado da programação é colocado em produção, a parte que não se repete não é tão significativa assim.

Não Existem Fórmulas Mágicas

Este é um problema antigo e de difícil solução. A distância entre o problema a solução deixa espaço para o surgimento de muitas teorias e técnicas com nomes pomposos e que vendem milagres. Entre eles, os que estão na moda: métodos ágeis, scrum, entre outros. Mas o único método que realmente funciona é o bom senso, a inteligência e a experiência aplicada caso a caso. Bom senso significa usar a ferramenta certa, no lugar certo e no momento certo. Os casos em que as metodologias funcionaram foram porque elas foram aplicadas com bom senso. Ao ler esta publicação, você encontrará algumas coisas que também são pregadas pelas metodologias que citei, mas eu as apresentarei de uma forma que você entenderá quando e como ela deve ser utilizada.

Resumo do Processo

A visão global do processo de desenvolvimento de software com produtividade não é nenhuma surpresa. Na verdade é bastante simples, mas o segredo não está na visão global, está nos detalhes de cada parte.

1. Definição do que é chamado de escopo, requisito, objetivo, use cases, fluxo ou qualquer outra palavra que consiga indicar que é necessária uma documentação do que o usuário final precisa receber para considerar que o produto final foi um sucesso. Esta etapa é feita pelo cliente ou futuro usuário do recurso com a ajuda do Analista de Sistemas. Veja meu artigo sobre este assunto.
2. Descrição das tarefas que devem ser executadas para que o objetivo definido no item anterior seja atingido. Esta etapa normalmente é feita por um Analista de Sistemas.
3. Execução dos passos definidos no item anterior, normalmente é o desenvolvimento do código na linguagem de programação escolhida. Esta etapa é executada pelos desenvolvedores e/ou programadores.
4. Testes para verificar se o resultado do desenvolvimento está de acordo com o objetivo definido no primeiro passo. Esta etapa é executada por uma equipe de teste e também pelo cliente ou usuário final tomando como base o que foi definido no requisito.
5. Publicação do desenvolvimento para o ambiente de produção.

Cada passo será detalhado abaixo ou em um futuro artigo que postarei neste blog.

Definição do Escopo, Requisito, Objetivo, Use Cases, Etc

Para este item, consulte este artigo.

Descrição das Tarefas que Devem ser Executadas

Com os requisitos em mãos, o Analista de sistemas pode começar a descrever tecnicamente como os requisitos devem ser atendidos. Para fazer isso, ele precisará de conhecimento na seguintes áreas:

1. Capacidades e limitações sobre os recursos computacionais disponíveis para atender os requisitos: linguagens utilizadas, infraestrutura de hardware e comunicação, capacidade e limitações dos desenvolvedores disponíveis, etc. Este conhecimento vai evitar que o projeto defina a utilização de recursos que não existem.
2. Sobre padrões de projeto, sobre estruturas de armazenamento, notação UML, etc. Este conhecimento evitará que seja escolhida uma solução inadequada para o problema. Como por exemplo a utilização de registro soft coded para representar informação hard coded, um dos erros mais comuns que tenho presenciado.
3. Sobre o que já existe no sistema legado. Especialmente o conhecimento sobre a função de cada uma das tabelas e campos do banco de dados legado. Também é importante saber sobre a estrutura de componentização do sistema e a biblioteca de classes e métodos legada. Este conhecimento vai evitar que seja criado código novo repetindo outro que já existe.
4. Sobre o negócio da empresa e sobre os padrões de software que cada tipo de negócio deve utilizar. Por exemplo, existe uma forma correta de fazer registros de transações financeiras multimoeda, onde é necessário entender o que é moeda contratual, moeda de pagamento, moeda contábil, etc. Também é necessário entender que lançamentos que serão utilizados na contabilidade jamais podem ser alterados, chamamos isso de registro transacional.
5. Sobre as dificuldades que o programador terá no momento em que tiver que decidir sobre o nome de um pacote, classe, propriedade ou método, sua dificuldade para capturar um evento disparador, sua dificuldade de escolher o ponto certo onde colocar a chamada do recurso que foi solicitado, etc. Este conhecimento permitirá com que o analista de sistema possa descrever a solução com um alto índice de assertividade.

Pode ser muito conhecimento para uma pessoa só, mas não é necessário que seja uma única pessoa. É perfeitamente aceitável que o papel de analista de sistema seja assumido por um comitê ao invés de uma única pessoa.

Dividir para Conquistar

É normal que os requisitos de software possam ser atendidos de forma separada. Mesmo que os requisitos que não possam ser utilizados de forma separada em produção podem ser subdivididos em entregas menores. Por exemplo emissão e baixa de boletos de cobrança bancária pode ser dividido em duas etapas separadas. Se a etapa for muito demorada, ela deve ser subdividida novamente. Os métodos ágeis mais conhecidos definem que o tempo pode ser medido em dias, mas particularmente eu acho que o melhor é definir em horas de trabalho. Se a etapa não puder ser executada em até 10 horas então é melhor subdividi-la novamente. No caso da emissão e baixa de boletos, pode haver mais subdivisões: uma etapa para cada banco, por exemplo.

Mas a subdivisão só é necessária quando você precisa justificar o tempo e os recursos gastos no projeto, se a execução estiver sendo feita por uma equipe de confiança, então esta burocracia deixa de ser necessária ou pelo menos se torna menos importante.

Execução das Etapas Planejadas

Se você conseguiu chegar até este ponto, então está indo muito bem porque a execução costuma ser uma etapa que possui muita literatura e boas técnicas para que as coisas ocorram dentro da melhor técnica. Mas apesar de estarem bem documentadas, ainda existem muitas equipes que não as dominam. Além disso, um bom desenvolvedor poderá ter sua performance seriamente afetada se o ambiente de desenvolvimento não tiver sido bem construído pelos outros desenvolvedores que deixaram código legado. Relaciono os problemas que mais tenho encontrado:

1. Código repetido, isto é, estruturas diferentes que executam a mesma função ou armazenam a mesma informação.
2. Variáveis, métodos, classes e constantes criados com nomes inadequados e incompatíveis com a informação que armazenam ou que processam.
3. Falta de uma biblioteca de componentes e métodos padrões para tratar as informações.
4. Falta de aplicar os padrões de projeto de software.
5. Transgressão da hierarquia das classes e pacotes.
6. Falta de testes unitários automatizados.

Não se preocupe de não ter compreendido todos os itens que relacionei, mesmo uma equipe que não conheça todas as técnicas conseguirá desenvolver um bom software. Mas para desenvolver um software mas complexo e com uma equipe grande, é necessário entender e utilizar estas técnicas, caso contrário ocorrerão muitos problemas.

Criação dos Testes Automatizados

A maioria dos desenvolvedores não gosta de criar rotinas de teste automatizado. Mas acho que isso acontece porque eles não perceberam que o teste automatizado lhes possibilita serem mais rápidos no desenvolvimento, explico este meu ponto de vista.

O processo de desenvolvimento exige que as alterações sejam testadas. Como o desenvolvimento exige muitas alterações, significa que também exigirá muitos testes. Se o teste for manual, o desenvolvedor perderá muito tempo executando uma rotina repetida, quando ela deveria estar sendo feita por um computador que oferece muito mais rapidez e qualidade no processo.

Também já percebi que existem muitas dúvidas sobre o que deve ser testado, para responder a esta questão usamos ferramentas de coverage que simplesmente informa quais as linhas de código que não foram cobertas pelo teste automatizado.

Homologação dos Requisitos

Antes de publicar os resultados em produção, o usuário que descreveu os requisitos com ajuda do analista de sistemas deverá verificar para saber:

1. se os requisitos foram atendidos
2. se os requisitos realmente descreveram o problema que se desejava solucionar.
3. se a forma de solucionar definida pelo analista efetivamente resolve o problema.

Se o problema era muito complexo, dificilmente esta etapa passará de primeira, é mais provável que seja necessários um ou mais ciclos de PDCA. A cada ciclo que se fizer necessário, é necessário que se aprenda onde houve a falha, mesmo que ela tenha sido pequena.

Nos casos em que o desenvolvimento foi orçado, o erro na descrição do requisito que provocou retrabalho é cobrado do responsável pelo requisito, mesmo que ele tenha sido acompanhado por um analista da empresa fornecedora. A empresa fornecedora arca com o custo apenas nos casos em que ficar comprovado que o requisito tinha sido definido mas o desenvolvimento não o atendeu.

Quando o projeto é definido em partes menores, as homologações podem ser feitas em partes menores que são muito mais simples de serem corrigidas.

Publicação do Resultado em Produção

Com certeza esta é a etapa mais esperada por todos, então se as etapas anteriores tiverem sido bem conduzidas, esta etapa será tranquila e sem percalços. Ela depende muito mais da equipe de infraestrutura do que da equipe de desenvolvimento. Vale lembrar que os problemas desta etapa ocorrem devido a diferenças entre ambiente de produção e ambiente de teste.