Os 5 erros mais comuns em Equipes de Desenvolvimento de Software

Código em produção sem testes

É comum criar software a partir de poucas confirmações das operações de listagem, criação, atualização e remoção. O interessante é a velocidade com que se entrega o software, porém não há garantias sobre o que pode acontecer quando algo além desses casos triviais acontece.

É por isso que é necessário criar casos de teste. Com eles, simples comandos verificam a resposta de cada função em casos extremos, para confirmar que a resposta adequada é apresentada ao usuário e que o sistema toma as medidas necessárias para contornar o problema.

Provocação: Faça isso com frequência e veja tudo desmoronar.

Falta de mão de obra qualificada, ou equipe muito pequena para atender o projeto

Parece algo óbvio e até clichê alertar sobre esse erro, mas é mais comum do que imaginamos. Imagine delegar a um pedreiro a construção de um edifício, que requer conhecimentos de solo, engenharia e arquitetura, legislação, design? É o que acontece quando se acredita que um desenvolvedor ou uma pequena equipe dão conta de construir, em pouco tempo, um software robusto e confiável como WhatsApp ou YouTube.

E se o prédio cair? A culpa é do profissional, ou de quem negligenciou todo o processo e delegou uma missão impossível à equipe?

Tenha em mente que é possível publicar o software com funcionalidades limitadas, em pequenas partes. Inclusive gratuitamente. Assim, é possível testar o que ganha adesão do público e obter um feedback.

Não acompanhar com reuniões a cada sprint

A inexistência de uma cultura de planos e métricas faz com que a comunicação seja prejudicada. Com a premissa de que é melhor trabalhar do que ficar fazendo reuniões, os breves momentos tão importantes para ajuste de engrenagens acabam sendo deixados de lado.

Para ter certeza de uma entrega satisfatória, é preciso acompanhar de perto o progresso e alinhar o trabalho de acordo com as expectativas do dono do produto. Delegar criação de funcionalidades e correção de bugs com longa data e sem intervalos com verificações, cria um risco muito maior de frustração na entrega.

Estimar o tempo para entrega sem um histórico de referência

Provocação: Faça isso com frequência e veja tudo desmoronar.

• Quanto vale a hora do desenvolvedor
• Qual complexidade de cada tarefa
• Quanto tempo demanda a complexidade
• Métricas de projetos anteriores – histórico

Uma planilha que contém suas médias de nível Fácil a Complexo nos ultimos projetos é de extrema utilidade nesse momento.

Tabela de Horas/Complicadores/Valor definida

Lista de tarefas definida

Resultado gerado automaticamente via Excel

Código em produção sem auditoria de performance

Com a grande quantidade de plataformas, plugins, bibliotecas, integrações… estamos acostumados a valorizar apenas a produtividade que se consegue com código pronto. E sim, é vantajoso e boa prática contar com ferramentas que acelerem o processo e evitem que se “reinvente a roda”.

No entanto, é possível notar que, quanto mais uma aplicação demora para entregar sua resposta, mais aumenta a a taxa de rejeição de usuários. É por isso que é preciso considerar a criação de funcionalidades por conta própria, ao invés de utilizar código de terceiros.

Ao criar um código próprio, investe-se mais um tempo para trabalhar no código, mas em contrapartida, tem-se a certeza de que não está sobrecarregando o sistema com códigos, estilos, imagens inutilizados e se consegue construir código mais limpo e objetivo, com o mínimo necessário para realização da funcionalidade.

Erros são aprendizados

Ninguém erra de propósito, mas um código com muitos erros significa pouca qualidade de código. É necessário avaliar se o tempo para construção do software foi/está suficiente e a estratégia de testes é consistente. No mais, erros servem de aprendizado e, uma vez identificados, devem ser corrigidos de forma que não aconteçam mais em todas as partes do sistema.

via CHAT ou WhatsApp