Engenharia de Software no dia-dia: 10 dicas fundamentais para equipes de software

Desenvolvedores iniciam seus softwares com ideias geniais, mas não alcançam o sucesso esperado, talvez pela ansiedade em entregar algo ao cliente e não em satisfazer as necessidades do negócio, do mercado, esquecendo-se de gerenciar equipes e principalmente, de utilizar a engenharia de software.

Nesse post são descritas dez dicas que buscam auxiliar equipes de desenvolvimento a utilizar na prática princípios da engenharia de software e terem seus resultados refletidos na sua rotina.

1º - ANÁLISE DE NEGÓCIO – Conheça o negócio

Figura 1: Conheça o negócio

Conheça o mercado e as necessidades que seu software vai suprir – invista tempo em conhecer os processos do negócio que deseja ingressar.

É comum empresários iniciantes focarem em desenvolver ‘adivinhando’ o que o cliente necessita, no erro e acerto.

Organize uma análise de negócio, crie diagramas de estado, requisitos detalhados, entenda os processos e se envolva na rotina dos usuários.

2º - GESTÃO DE CONHECIMENTO - Compartilhar conhecimento na equipe

Figura 2: Compartilhar conhecimento

Quando existir mais de um componente na equipe, todo o conhecimento coletado deve ser compartilhado em reuniões, debates, isso é fundamental para que todos estejam envolvidos.

Hoje a tecnologia nos permite reuniões sem precisar do encontro presencial. É importante que todos conheçam do negócio e não apenas um na equipe, todos devem ter o objetivo comum de suprir a necessidade do cliente, e para isso é preciso saber quais são essas necessidades.

3º - GESTÃO DE PROCESSOS - Defina fases no seu processo

Figura 3: Crie um ciclo

Indiferente do tempo e do tamanho do software, devem ser determinadas as fases do seu processo, conforme características do grupo de desenvolvedores, do cliente e do produto.

Não deve se ater a paradigmas já existentes, deve existir a coerência com a forma que da equipe trabalhar, a sugestão é criar seu próprio ciclo de vida.

4º - ENGENHARIA DE REQUISITOS - Dar importância a fase de análise

Figura 4: Engenharia de requisitos

É comum ouvir: ‘O software é pequeno’, ‘Só estamos iniciando’ e esse é um dos maiores equívocos na hora de desenvolver um produto.

Definir a análise desde o inicio, é fundamental para facilitar o crescimento do software. A falta de métodos de análise acaba tornando impossível de se reverter depois que aumenta o número de rotinas e a complexidade de requisitos.

É fundamental a análise de requisitos, mas destaca-se que a maior dúvida das equipes é quais os diagramas são mais importantes e que realmente são necessários, tendo em vista que a equipe é pequena e o tempo curto.

Para discutirmos esse item retornamos ao 1º item, onde os tipos de diagramas e casos de uso utilizados, devem ser para uso da organização, não adianta gastar tempo realizando análises que não serão utilizadas, por isso é necessário definir o que é fundamental.

Qual a análise que agilizaria o desenvolvimento? Os testes? As manutenções?

Essa definição deve ser realizada pela equipe, buscando suprir necessidades que a própria equipe levantará.

Um exemplo é no inicio do negócio, onde há uma dificuldade maior de entender o negócio, o foco, nesses casos, pode ser em diagramas que facilitem o entendimento do negócio e também o desenvolvimento, destacando que a abordagem de UML é fundamental, pela compreensão universal.

5º TECNOLOGIA – Uma dúvida comum é qual a tecnologia a utilizar no desenvolvimento

Figura 5: Escolher tecnologia

Essa escolha pode engessar ou atrasar o crescimento de um produto e por isso deve ser analisada muito bem.

O desenvolvimento deve ser realizado em tecnologias flexíveis, que possibilitem mudanças.

Indiferente do mercado em que está inserido, a evolução é muito rápida e a concorrência inevitável.

6º GESTÃO DE CONFIGURAÇÃO – Organize seus artefatos

Figura 6: Organize artefatos

Além de artefatos organizados, deve ser criada uma rastreabilidade, não havendo duplicidade de nomenclaturas.

Não deve haver dúvidas dos stakeholders em relação ao que fazer, de como fazer, o que precisa para executar sua tarefa e o que será gerado depois de encerrada sua tarefa.

Existem ferramentas que auxiliam nisso, porém, indiferente das ferramentas, gerencia de configuração é um principio.

7º – TREINAMENTOS – A equipe pode criar e aplicar seus treinamentos

Figura 7: Crie e aplique seus treinamentos

Os treinamentos externos devem ser priorizados para os colaboradores com melhor didática, para que o custo-benefício seja compensado, pois um treinamento pago será compartilhado com todos. Muitas empresas acreditam que se deve investir no colaborador com maior habilidade técnica, mas esse muitas vezes é o responsável por centralizar o conhecimento na organização, engessar o processo.

Os treinamentos externos devem ser documentados, sendo criado treinamento interno com base no conhecimento recebido.

As organizações são ricas em conhecimento, mas isso deve ser formalizado e distribuído, por isso, especialistas devem ser valorizados e estimulados a compartilhar seu conhecimento, assim como os experientes.

Jamais se deve centralizar conhecimento e engavetá-lo.

E as equipes pequenas, com apenas dois sócios, por exemplo, que exercem todos os papéis e ambos compartilham de forma verbal e rápida o conhecimento, nesse caso pra que criar treinamentos?

Mas e o próximo contratado? Ou melhor, os próximos? Vai ser explicado verbalmente tudo? E o tempo para isso? Vai ser lembrado de tudo?

Por isso o conhecimento deve ser documentado formalmente para não se perder e ser utilizado sempre que pertinente.

Vale destacar que esses treinamentos podem ser das próprias rotinas organizacionais, de ferramentas novas que a equipe adota, assim como dos produtos que se desenvolve...

Os treinamentos passam a fazer parte de um banco de conhecimento organizacional, que deve ser atualizado por quem o usa, ou baseado em sugestões desses.

8º GESTÃO DA QUALIDADE – O planejado será entregue?

Figura 8: Qualidade

A qualidade deve responder se o esperado foi realizado e não o cliente.

Cabe à equipe saber em que momento se insere a verificação disso. Um exemplo é antes de começar a modelar ter certeza se é isso que o usuário precisa (validação), antes de desenvolver devem ser realizados testes, para então liberar.

Deve ser destacado que a qualidade esta presente não só no produto final, mas em todos os artefatos gerados, e esses devem ser auditados.

9º FEEDBACK DO USUÁRIO – As organizações crescem e a preocupação com o que o seu usuário pensa sobre o software some

Figura 9: Feedback cliente

É imprescindível que sejam criadas ações fora dos projetos que melhorem a qualidade, uma dessas são as auditorias de qualidade externa, onde se pesquisa problemas apontados pelos usuários no software, as dificuldades que podem ser solucionadas de forma simples, principalmente de layout.

Coletas de requisitos interativas com usuários são fundamentais, isso auxilia o software a estar sempre atualizado e compatível com a realidade do mercado.

10º DEFINA PAPÉIS – Papel é diferente de cargo e diferente de individuo

Figura 10: Papéis definidos

Um indivíduo pode desempenhar mais do que um papel na organização, porém cada papel deve estar definido, (o que o desenvolvedor faz, quando faz, o que o analista faz...). Isso auxiliaria a padronizar tarefas e também a definir perfis, que facilitam na escolha de novos colaboradores.

A utilização da engenharia de software deve ser um hábito, seu leque de possibilidades é vasto, então não copie, utilize a engenharia a seu favor, crie seu processo conforme possa trabalhar e aplique técnicas, metodologias e ferramentas de maneira que facilite e seja usual a equipe. Cada organização, indiferente de tamanho, tem suas características e existem formas gratuitas e fáceis de aplicar a engenharia de software.